2 ms·

With mercurial I think is better to abandon the idea of rewriting history to make it look nicer or more linear. The good point is that your history reflects pre

by awt 15y ago

With mercurial I think is better to abandon the idea of rewriting history to make it look nicer or more linear. The good point is that your history reflects precisely what happened and how developers merged the code Rewriting history doesn't just make the git log look nicer. It gives you the ability to more easily create atomic commits, and it ensures that commits in a branch that is later merged back to master are contiguous instead of sprinkled among all of the other commits from all other branches. If you are tracking down a bug, this helps a lot, especially if you use git bisect.

pnathan 15y ago
There are two different philosophies of branches as near as I can make out. * Branches as 'records of effort'/'who did what when on what project'. * Separating lines of development to keep mainline builds from falling over. In a 'audit-thy-process' environment, immutable history and records of projects have a high importance. If the goal is 'simply' to separate lines of development - well then you can squash commits and it doesn't matter.
rlpb 15y ago
Additionally, in open source development, you don't submit your mess. You submit clean patchsets ready for review. I don't see why a private development tree should be any different.
johnm 15y ago
There are multiple approaches to "rewriting history" in a dvcs depending on what your workflow and preferences are. In Hg you can do various forms of rebasing and rewriting history, e.g.: * http://mercurial.selenic.com/wiki/ConcatenatingChangesets http://mercurial.selenic.com/wiki/ConcatenatingChangesets * http://mercurial.selenic.com/wiki/EditingHistory http://mercurial.selenic.com/wiki/EditingHistory * http://mercurial.selenic.com/wiki/RebaseExtension http://mercurial.selenic.com/wiki/RebaseExtension The difference between Hg and Git in this regard is much more a question of what's the basis of their philosophy. Git promotes rewriting & rebasing while Hg is biased towards a more conservative approach.

by awt 15y ago

pnathan 15y ago

There are two different philosophies of branches as near as I can make out. * Branches as 'records of effort'/'who did what when on what project'. * Separating lines of development to keep mainline builds from falling over. In a 'audit-thy-process' environment, immutable history and records of projects have a high importance. If the goal is 'simply' to separate lines of development - well then you can squash commits and it doesn't matter.

rlpb 15y ago

Additionally, in open source development, you don't submit your mess. You submit clean patchsets ready for review. I don't see why a private development tree should be any different.

johnm 15y ago

There are multiple approaches to "rewriting history" in a dvcs depending on what your workflow and preferences are. In Hg you can do various forms of rebasing and rewriting history, e.g.: * http://mercurial.selenic.com/wiki/ConcatenatingChangesets http://mercurial.selenic.com/wiki/ConcatenatingChangesets * http://mercurial.selenic.com/wiki/EditingHistory http://mercurial.selenic.com/wiki/EditingHistory * http://mercurial.selenic.com/wiki/RebaseExtension http://mercurial.selenic.com/wiki/RebaseExtension The difference between Hg and Git in this regard is much more a question of what's the basis of their philosophy. Git promotes rewriting & rebasing while Hg is biased towards a more conservative approach.