6 ms·

You can really have two "species" of commits: One of them is the "published, shared" kind; for this one, I can agree with you, that they should be self-contain

by akavel 12y ago

You can really have two "species" of commits: One of them is the "published, shared" kind; for this one, I can agree with you, that they should be self-contained and complete, especially when there many devs on the project, and/or you'd like to be able to use bisect. The second kind, and for me actually a very important one, is more of a "local backup, dirty hacking" one. Those shouldn't probably be published (unless a private/one-guy repo), but allow for easy hacking, developing, testing, experimenting. The "commit often, whatever you have, however broken or non-ideal" approach provides safe lightweight backup, and allows for easy switching between various paths/approaches. Now, after you design stabilizes, dust settles down, and you are completing the work, you can (and probably should) eventually either just squash everything into one final feature commit (the end result will be indistinguishable to what you'd deliver if not committing in the meantime), or remodel the intermediary commits to whatever ideal shape you like them to have retroactively (with "git rebase -i", including patch editing etc.) Knowing the benefits of this approach, I don't understand why anyone would want to reject it. edit: Also, with many small, dirty commits, it's sometimes possible to fairly quickly do stuff like carving out some subfeature into a separate branch (with judicious use of rebases, cherrypicking and some occasional small edits). Or, remove/revert commits marked earlier as DEBUG. Seems useful to me, as a means to somewhat speed up such operations and decrease the possibility of manual error at the same time.

vertex-four 12y ago
Shouldn't we then have a tool which separates out "published, shared" commits from WIP commits, if they're different "types"?
- blablabla123 12y ago
  It's more of a workflow thing. When working on a difficult feature, or rather difficult ticket, that cannot reasonably split into 2, it makes sense to work on a separate feature branch. This branch is just for yourself and can be polluted with dirty commits. Once your done, your can git rebase the thing into one, beautiful commit.
  - SargoDarya 12y ago
    If you're working in a feature branch I don't think it would be that much of a problem to be honest. Just be sure to squash the commits before writing the pull request later on.
    - megablast 12y ago
      What do you mean by squashing the commits? Why would it matter if you do a pull request after committing a lot?
      - ulisesrmzroche 12y ago
        You can squash or rebase history in Git, which basically means you compress all your changes into a single one. People use this to keep a clean history.
- jordigh 12y ago
  Yeah, Mercurial phases handles this: http://mercurial.selenic.com/wiki/Phases http://mercurial.selenic.com/wiki/Phases
- exDM69 12y ago
  Why would this be advantageous? If you're using Git or another version control that can do squash/rebase, what would be the advantage of having a separate concept of "temporary commits" or something? In addition, git has a staging area (git add), which I use to stage intermediate steps of work. It's a good idea to have only "clean" commits in your master branch (to allow for easy blame/bisect) but you can easily do feature branches that can remain "dirty" before squashing and merging to master.
  - lmm 12y ago
    > If you're using Git or another version control that can do squash/rebase, what would be the advantage of having a separate concept of "temporary commits" or something? It'd be nice to be able to mark commits as "squashable" as I went along (without actually squashing them yet), rather than finishing my feature branch and then have to go back and remember which commits were the "good" ones.
    - krupan 12y ago
      As another poster pointed out, Mercurial phases are the answer to this. I don't know if very many mercurial users actually use them this way consciously or not. Most mercurial people that are deliberately and intensely into this workflow learned to use mercurial patch queues before phases existed (patch queues are basically the git staging area on steroids).
    - micampe 12y ago
      You can do that with autosquash https://coderwall.com/p/hh-4ea https://coderwall.com/p/hh-4ea
      - lmm 12y ago
        Is there an equivalent with a looser match? Half the time I don't remember what my last commit message was.
        micampe 12y ago
mcherm 12y ago
Interestingly, I have two different version control systems for doing these two different species of commit. The published kind, I do in my regular team version control system, complete with commit comments that explain the meaning of the complete thought that is being committed. The other kind (bookmarking my state before messing around with things I may want to cleanly revert) I do using the version control that is built into IntelliJ IDEA. It is completely orthogonal to the one used by my team. Other IDEs should offer this feature... it turns out to be quite useful in practice.
- visural 12y ago
  Netbeans also has a local history recording feature which is integrated pretty well alongside the git/vcs features (just hit history on any file and see a log of all your local changes intermingled with the committed versions).
- coob 12y ago
  Xcode offers this feature: http://tewha.net/2012/01/ive-changed-my-mind-about-xcode-snapshots/ http://tewha.net/2012/01/ive-changed-my-mind-about-xcode-sna...
- Retric 12y ago
  I really like this approach, you can take it one step further. Set up an automatic independent (aka private) commit after every successful compile.
  - mcherm 12y ago
    IntelliJ, when you combine the internal version control and the undo log, manages it so that effectively there is a commit after each piece of typing -- without any need to save or even compile. That turns out to be a nice way of working.
- Maken 12y ago
  I think most IDEs nowadays have a local history. The Eclipse one let you compare between revisions like if it were a local git repo, which is useful sometimes.
olau 12y ago
"Knowing the benefits of this approach, I don't understand why anyone would want to reject it." It's always difficult to have these kinds of conversations in the abstract, but for me it's a slightly cumbersome distraction (unless you don't write commit messages). But if it works for you, you should certainly keep doing it. I tend to divide stuff into small chunks so never work on something for long without something that can be committed.
- akavel 12y ago
  Most usually I still do write commit messages, and that's actually an important additional value of this workflow for me. That said, the commit message is again often a quick and raw: usually a quick in-progress summary of the most important work in the commit, but not perfected at all - just quick something, can have errors, ignores all Commit Message Guidelines like length or whatever. One benefit is, as well noted in other post in the thread, that it will remind me "what the hell was I thinking doing that" when I look at it tomorrow. Second one, obviously, is to help distinguish those commits when doing any sculpting/molding later (i.e. "git rebase -i" & "git cherry-pick" & "git merge --squash"). But that, as I said, is most usually. Sometimes, as you considered, I do write just "WIP" or "dump of current state". The second one, mostly when I already don't remember WTF was I doing here... (i.e. when I forgot to commit month ago and left some stuff on the table). The first one... I'm not sure now. But I know I sometimes do; with some guilt too; but usually the need for having that particular stuff committed is stronger than the guilt... So, still can't really understand why anyone would want to reject it :) but that said, thanks a lot for expressing your approach. As much as it still puzzles me :)
jordigh 12y ago
> You can really have two "species" of commits: That's what Mercurial phases are: http://mercurial.selenic.com/wiki/Phases http://mercurial.selenic.com/wiki/Phases
nhance 12y ago
This is the workflow we've adopted at my company. There are 2 types of commits, you either want to release some new feature or bit of work and do it atomically, or you want to develop the feature, fix typos and throw it between machines without a care. Is it ever going to help anyone to `git blame` a line of a file and see a commit message like "Whoops, fixed a typo!"? No. But you can't avoid those types of commits. What you can do is prevent those commits from going into the released history of the product. We develop all new features in feature branches (made _very_ easy with the commandline tool we built for it) and only after code review and acceptance testing do we squash merge it to master. This lets us put together all of the commits, typo commits, WIP commits and whatever else into a combined commit that contains all of the changes that make up that feature. We even enforce a special syntax on the commit so when you look back in the history, you can trace it back to the code review and to the actual ticket that requested the work. This means we keep all of our dirty backup commits until release time when we throw them all away in favor of the squashed commit. It makes git blame on any line of any file a sexy experience that provides accountability and an easy way to figure out why the code is the way it is. Our commandline tool automates a lot of this for us. It's biggest benefit is the tie in with github (and this week bitbucket) to create pull requests and the "deliver" command that handles squash merging and providing the structure for the final commit. It's all open source and available here: http://github.com/reenhanced/gitreflow/ http://github.com/reenhanced/gitreflow/
- Myrmornis 12y ago
  We prevent force pushes to the remote, so if you need to rebase commits that are on the remote already, you'd have to delete the branch from the remote and re-push, and that closes the PR, which confuses reviewers and causes spurious notifications. Do you merge master into feature branches between the time the feature branch is first pushed to the remote and when they are reviewed and ready to merge? Can your command line tool handle creating a squashed commit when master has been merged into the feature branch a few times?
  - zethraeus 12y ago
    git diff?
jules 12y ago
I would like to commit on every keystroke + a mechanism to hierarchically group commits.
novaleaf 12y ago
this is what I use a "$YOURNAME$-dev" branch for. all my hacks / etc go there and only "proper" work gets merged upstream.

by akavel 12y ago

vertex-four 12y ago

Shouldn't we then have a tool which separates out "published, shared" commits from WIP commits, if they're different "types"?

blablabla123 12y ago
It's more of a workflow thing. When working on a difficult feature, or rather difficult ticket, that cannot reasonably split into 2, it makes sense to work on a separate feature branch. This branch is just for yourself and can be polluted with dirty commits. Once your done, your can git rebase the thing into one, beautiful commit.
- SargoDarya 12y ago
  If you're working in a feature branch I don't think it would be that much of a problem to be honest. Just be sure to squash the commits before writing the pull request later on.
  - megablast 12y ago
    What do you mean by squashing the commits? Why would it matter if you do a pull request after committing a lot?
    - ulisesrmzroche 12y ago
      You can squash or rebase history in Git, which basically means you compress all your changes into a single one. People use this to keep a clean history.
jordigh 12y ago
Yeah, Mercurial phases handles this: http://mercurial.selenic.com/wiki/Phases http://mercurial.selenic.com/wiki/Phases
exDM69 12y ago
Why would this be advantageous? If you're using Git or another version control that can do squash/rebase, what would be the advantage of having a separate concept of "temporary commits" or something? In addition, git has a staging area (git add), which I use to stage intermediate steps of work. It's a good idea to have only "clean" commits in your master branch (to allow for easy blame/bisect) but you can easily do feature branches that can remain "dirty" before squashing and merging to master.
- lmm 12y ago
  > If you're using Git or another version control that can do squash/rebase, what would be the advantage of having a separate concept of "temporary commits" or something? It'd be nice to be able to mark commits as "squashable" as I went along (without actually squashing them yet), rather than finishing my feature branch and then have to go back and remember which commits were the "good" ones.
  - krupan 12y ago
    As another poster pointed out, Mercurial phases are the answer to this. I don't know if very many mercurial users actually use them this way consciously or not. Most mercurial people that are deliberately and intensely into this workflow learned to use mercurial patch queues before phases existed (patch queues are basically the git staging area on steroids).
  - micampe 12y ago
    You can do that with autosquash https://coderwall.com/p/hh-4ea https://coderwall.com/p/hh-4ea
    - lmm 12y ago
      Is there an equivalent with a looser match? Half the time I don't remember what my last commit message was.
      - micampe 12y ago

mcherm 12y ago

Interestingly, I have two different version control systems for doing these two different species of commit. The published kind, I do in my regular team version control system, complete with commit comments that explain the meaning of the complete thought that is being committed. The other kind (bookmarking my state before messing around with things I may want to cleanly revert) I do using the version control that is built into IntelliJ IDEA. It is completely orthogonal to the one used by my team. Other IDEs should offer this feature... it turns out to be quite useful in practice.

visural 12y ago
Netbeans also has a local history recording feature which is integrated pretty well alongside the git/vcs features (just hit history on any file and see a log of all your local changes intermingled with the committed versions).
coob 12y ago
Xcode offers this feature: http://tewha.net/2012/01/ive-changed-my-mind-about-xcode-snapshots/ http://tewha.net/2012/01/ive-changed-my-mind-about-xcode-sna...
Retric 12y ago
I really like this approach, you can take it one step further. Set up an automatic independent (aka private) commit after every successful compile.
- mcherm 12y ago
  IntelliJ, when you combine the internal version control and the undo log, manages it so that effectively there is a commit after each piece of typing -- without any need to save or even compile. That turns out to be a nice way of working.
Maken 12y ago
I think most IDEs nowadays have a local history. The Eclipse one let you compare between revisions like if it were a local git repo, which is useful sometimes.

olau 12y ago

"Knowing the benefits of this approach, I don't understand why anyone would want to reject it." It's always difficult to have these kinds of conversations in the abstract, but for me it's a slightly cumbersome distraction (unless you don't write commit messages). But if it works for you, you should certainly keep doing it. I tend to divide stuff into small chunks so never work on something for long without something that can be committed.

akavel 12y ago
Most usually I still do write commit messages, and that's actually an important additional value of this workflow for me. That said, the commit message is again often a quick and raw: usually a quick in-progress summary of the most important work in the commit, but not perfected at all - just quick something, can have errors, ignores all Commit Message Guidelines like length or whatever. One benefit is, as well noted in other post in the thread, that it will remind me "what the hell was I thinking doing that" when I look at it tomorrow. Second one, obviously, is to help distinguish those commits when doing any sculpting/molding later (i.e. "git rebase -i" & "git cherry-pick" & "git merge --squash"). But that, as I said, is most usually. Sometimes, as you considered, I do write just "WIP" or "dump of current state". The second one, mostly when I already don't remember WTF was I doing here... (i.e. when I forgot to commit month ago and left some stuff on the table). The first one... I'm not sure now. But I know I sometimes do; with some guilt too; but usually the need for having that particular stuff committed is stronger than the guilt... So, still can't really understand why anyone would want to reject it :) but that said, thanks a lot for expressing your approach. As much as it still puzzles me :)

jordigh 12y ago

> You can really have two "species" of commits: That's what Mercurial phases are: http://mercurial.selenic.com/wiki/Phases http://mercurial.selenic.com/wiki/Phases

nhance 12y ago

This is the workflow we've adopted at my company. There are 2 types of commits, you either want to release some new feature or bit of work and do it atomically, or you want to develop the feature, fix typos and throw it between machines without a care. Is it ever going to help anyone to `git blame` a line of a file and see a commit message like "Whoops, fixed a typo!"? No. But you can't avoid those types of commits. What you can do is prevent those commits from going into the released history of the product. We develop all new features in feature branches (made _very_ easy with the commandline tool we built for it) and only after code review and acceptance testing do we squash merge it to master. This lets us put together all of the commits, typo commits, WIP commits and whatever else into a combined commit that contains all of the changes that make up that feature. We even enforce a special syntax on the commit so when you look back in the history, you can trace it back to the code review and to the actual ticket that requested the work. This means we keep all of our dirty backup commits until release time when we throw them all away in favor of the squashed commit. It makes git blame on any line of any file a sexy experience that provides accountability and an easy way to figure out why the code is the way it is. Our commandline tool automates a lot of this for us. It's biggest benefit is the tie in with github (and this week bitbucket) to create pull requests and the "deliver" command that handles squash merging and providing the structure for the final commit. It's all open source and available here: http://github.com/reenhanced/gitreflow/ http://github.com/reenhanced/gitreflow/

Myrmornis 12y ago
We prevent force pushes to the remote, so if you need to rebase commits that are on the remote already, you'd have to delete the branch from the remote and re-push, and that closes the PR, which confuses reviewers and causes spurious notifications. Do you merge master into feature branches between the time the feature branch is first pushed to the remote and when they are reviewed and ready to merge? Can your command line tool handle creating a squashed commit when master has been merged into the feature branch a few times?
- zethraeus 12y ago
  git diff?

jules 12y ago

I would like to commit on every keystroke + a mechanism to hierarchically group commits.

novaleaf 12y ago

this is what I use a "$YOURNAME$-dev" branch for. all my hacks / etc go there and only "proper" work gets merged upstream.