5 ms·

So it definitely keeps history nice and pretty, and I use it for simple commits all the time. However, sometimes I do 'git pull --no-ff' explicitly, because I

by pcl 14y ago

So it definitely keeps history nice and pretty, and I use it for simple commits all the time. However, sometimes I do 'git pull --no-ff' explicitly, because I want a more-complex multi-commit sequence of operations to stand out as a unit of work. I really wish git had a primary concept of such a thing. I understand that hg might, but haven't had an opportunity to get that far into an hg project yet.

kibibu 14y ago
I've been burned a number of times by hg rebase, losing work in each case. Given that our team only has 3 committers, I'd rather deal with the messy tree than lost work.
- ngoldbaum 14y ago
  The rebase extension for hg is still a bit experimental, at least as I understand it. It will be much better once changeset evolution [1] is turned on by default in a stable release. [1] http://mercurial.selenic.com/wiki/ChangesetEvolution http://mercurial.selenic.com/wiki/ChangesetEvolution
  - kibibu 14y ago
    That looks nice; in particular `hg fold` solves the "messy local, clean remote" problem nicely.
X-Istence 14y ago
What do you mean a primary concept?
- pcl 14y ago
  The use case that comes to mind first is 'git bisect'. I love that feature, but I also love to leave a messy trail of commits in my history. In other words, I expect that there will be commits in my history where a full test run might not work, or maybe even things might not compile. Of course, that sort of thing royally messes with 'git bisect'. If git had a primary concept of "here's a synchronization point", then it'd be much easier to build tools like 'git bisect' (and even 'git log' etc.) around those sorts of paradigms. That'd offer the best of both worlds -- rich, detailed history showing how something got done, but also points at which it was believed that all was good in the world. A push is (should be?) a natural synchronization point, for example.
  - to3m 14y ago
    Some form of nested commit would be useful for this I suppose - it would be arranged with something like an interactive rebase, that would squash a sequence of commits into one (for the purposes of log and bisect and the like), while leaving the original ones still accessible. This would give you your neat history for most purposes without losing the original commit comments and original sets of individual changes. This is of course a bit like how branches are merged together ordinarily, at least if you don't go around deleting them the moment you're done with them. And sure enough it looks like you can sort of persuade git bisect to treat ordinary branch merges like this: http://stackoverflow.com/questions/5638211/how-do-you-get-git-bisect-to-ignore-merged-branches http://stackoverflow.com/questions/5638211/how-do-you-get-gi...
- eru 14y ago
  Probably the same thing as `first class' in `first class functions'. See https://en.wikipedia.org/wiki/First-class_function https://en.wikipedia.org/wiki/First-class_function

by pcl 14y ago

kibibu 14y ago

I've been burned a number of times by hg rebase, losing work in each case. Given that our team only has 3 committers, I'd rather deal with the messy tree than lost work.

ngoldbaum 14y ago
The rebase extension for hg is still a bit experimental, at least as I understand it. It will be much better once changeset evolution [1] is turned on by default in a stable release. [1] http://mercurial.selenic.com/wiki/ChangesetEvolution http://mercurial.selenic.com/wiki/ChangesetEvolution
- kibibu 14y ago
  That looks nice; in particular `hg fold` solves the "messy local, clean remote" problem nicely.

X-Istence 14y ago

What do you mean a primary concept?

pcl 14y ago
The use case that comes to mind first is 'git bisect'. I love that feature, but I also love to leave a messy trail of commits in my history. In other words, I expect that there will be commits in my history where a full test run might not work, or maybe even things might not compile. Of course, that sort of thing royally messes with 'git bisect'. If git had a primary concept of "here's a synchronization point", then it'd be much easier to build tools like 'git bisect' (and even 'git log' etc.) around those sorts of paradigms. That'd offer the best of both worlds -- rich, detailed history showing how something got done, but also points at which it was believed that all was good in the world. A push is (should be?) a natural synchronization point, for example.
- to3m 14y ago
  Some form of nested commit would be useful for this I suppose - it would be arranged with something like an interactive rebase, that would squash a sequence of commits into one (for the purposes of log and bisect and the like), while leaving the original ones still accessible. This would give you your neat history for most purposes without losing the original commit comments and original sets of individual changes. This is of course a bit like how branches are merged together ordinarily, at least if you don't go around deleting them the moment you're done with them. And sure enough it looks like you can sort of persuade git bisect to treat ordinary branch merges like this: http://stackoverflow.com/questions/5638211/how-do-you-get-git-bisect-to-ignore-merged-branches http://stackoverflow.com/questions/5638211/how-do-you-get-gi...
eru 14y ago
Probably the same thing as `first class' in `first class functions'. See https://en.wikipedia.org/wiki/First-class_function https://en.wikipedia.org/wiki/First-class_function