On Mon, Feb 01, 2010 at 05:44:25PM -0500, Eugene Sajine wrote: > > > > I imagine that this case is useful because of usual work interruptions > > > > in software development. A developer tries to bring various tasks > > > > forward in parallel. Branches will be switched often with unfinished > > > > work that needs to be kept before the reactivation of another task. > > > > Aren't this and similar statements based on a general problem of > people being afraid to commit, because CVS/SVN taught them to be > affraid? We are in progress of migrating from CVS to GIT and this is > one of the things i'm desperately fighting with. > In Git Commit doesn't equal Share (it does in CVS), so why not to > commit and save your work in progress and switch branches painlessly? There are various pressures pushing against each other and the balance will be different for each individual and each project. One aspect is that committing often is encouraged. However, greatly contradicting force is the pressure to have "clean history" - that is, self-contained, clearly separated cnd bisectable ommits which introduce independent changes and are pretty to look at, frequently quite different to chronological log of the performed work. Of course you can ignore that and just commit away, or build up large changes "in advance", then split them up at once. The resulting number of commits will be about the same, but their quality _and_ the spent effort will be quite different. Optimum lies in appropriate balance of the processes, as usual. There are several ways to achieve the latter process, moreover. One possibility is to do all changes in the working tree, then carefulling factoring out various aspects to separate commits using index manipulation and heavy `git add -p` usage; you would then certainly need `git stash` in case you wanted to switch the branch. The other way is to commit regularly creating a history structure similar to the "careless committer", _however_ before pushing out and publishing the commits, the history gets cleaned up and rewritten by `git rebase -i`. Choosing the appropriate method involves all kinds of subtle tradeoffs and I wonder whether there is a single good answer, it is a matter of taste. I do the former, but maybe that's because I just dislike rebase for different reasons. ;-) One natural way would be to hack in the working tree, splitting up your work to 1-3 commits in the index, then reviewing your complete local changeset and tweaking it by rebase -i before finally publishing your self-contained masterpiece. For better or worse, There Is More Than One Way To Do It in Git. ;-) -- Petr "Pasky" Baudis If you can't see the value in jet powered ants you should turn in your nerd card. -- Dunbal (464142) -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html