3 ms·

From what I've seen, few people use Mercurial's heavy branches, except for things like release and maintenance branches, where it makes a certain amount of sens

by sfink 7y ago

From what I've seen, few people use Mercurial's heavy branches, except for things like release and maintenance branches, where it makes a certain amount of sense. Some do, but most people seem to use bookmarks, topics, or multiple heads. Everything else you're talking about sounds like ancient history to me. `hg record` is now `hg commit -i`, so it's back to one command. `hg histedit` intersects with rebase, in that you can do some types of rebasing with it, but you tend to use them in different scenarios.

cryptonector 7y ago
> `hg histedit` intersects with rebase, in that you can do some types of rebasing with it, but you tend to use them in different scenarios. I don't tend to use them in different scenarios. I routinely `git rebase -i origin/master`. Sometimes from detached-HEAD mode. > `hg record` is now `hg commit -i`, so it's back to one command. So Mercurial has an index? Or is that something else? Looks like roughly the same thing as `hg record -p`. An index is much easier to use. `git add -e` is simply amazing. I've tried to use "bookmarks" in hg or whatever they were calling light-weight branches, but I've had trouble with it. Git won. I'm not saying Git is perfect. It's missing a few things, but it's better than all open source VCSes so far. And the work MSFT is doing is really helping too.
- sfink 7y ago
  > So Mercurial has an index? Or is that something else? Something else. i for interactive. > Looks like roughly the same thing as `hg record -p` Do you mean git commit -p? (Or is it git add -p? I can't check right now, and I can't even predict which one git would pick.) Anyway, yes, it's exactly that. > An index is much easier to use. Why? I don't miss it in hg. I use it in git, but it mostly feels like it's an extra thing to remember. Yet most git users agree with you, so I'd like to understand why. > `git add -e` is simply amazing. I wonder what you'd think of `hg absorb`.
  - cryptonector 7y ago
    > > An index is much easier to use. > > Why? I don't miss it in hg. I use it in git, but it mostly feels like it's an extra thing to remember. Yet most git users agree with you, so I'd like to understand why. With `hg record`, if anything goes wrong, I have to start over. That can be extremely frustrating. With `git add -e/-p` I can quit at any time and leave the things that were OK in the index while I take time to think about how to "absorb" the rest, or even commit what I have now and then go about dealing with the rest. The index not only gives me the ability to do that sort of thing, but it also lets me get atomicity -- no matter what happens in the workspace, the index stays as I left it until I either add more to it or commit it or reset it.
- sfink 7y ago
  > I routinely `git rebase -i origin/master`. Sometimes from detached-HEAD mode. Which would both use `hg rebase`, so I'm not sure what you mean. Histedit is for reordering commits, or dropping some from the middle of a stack, and/or folding adjacent commits together. All in one go, if you so choose. All of which you could do with multiple rebase invocations, but histedit is an easier declarative interface to multiple rebase operations. On the flip side, it's limited to operating on linear chunks of the dag.
  - cryptonector 7y ago
    But I also then choose to squash/fixup/edit/reorder commits. Mercurial insists I do that in two steps. WHY?

by sfink 7y ago

cryptonector 7y ago

> `hg histedit` intersects with rebase, in that you can do some types of rebasing with it, but you tend to use them in different scenarios. I don't tend to use them in different scenarios. I routinely `git rebase -i origin/master`. Sometimes from detached-HEAD mode. > `hg record` is now `hg commit -i`, so it's back to one command. So Mercurial has an index? Or is that something else? Looks like roughly the same thing as `hg record -p`. An index is much easier to use. `git add -e` is simply amazing. I've tried to use "bookmarks" in hg or whatever they were calling light-weight branches, but I've had trouble with it. Git won. I'm not saying Git is perfect. It's missing a few things, but it's better than all open source VCSes so far. And the work MSFT is doing is really helping too.

sfink 7y ago
> So Mercurial has an index? Or is that something else? Something else. i for interactive. > Looks like roughly the same thing as `hg record -p` Do you mean git commit -p? (Or is it git add -p? I can't check right now, and I can't even predict which one git would pick.) Anyway, yes, it's exactly that. > An index is much easier to use. Why? I don't miss it in hg. I use it in git, but it mostly feels like it's an extra thing to remember. Yet most git users agree with you, so I'd like to understand why. > `git add -e` is simply amazing. I wonder what you'd think of `hg absorb`.
- cryptonector 7y ago
  > > An index is much easier to use. > > Why? I don't miss it in hg. I use it in git, but it mostly feels like it's an extra thing to remember. Yet most git users agree with you, so I'd like to understand why. With `hg record`, if anything goes wrong, I have to start over. That can be extremely frustrating. With `git add -e/-p` I can quit at any time and leave the things that were OK in the index while I take time to think about how to "absorb" the rest, or even commit what I have now and then go about dealing with the rest. The index not only gives me the ability to do that sort of thing, but it also lets me get atomicity -- no matter what happens in the workspace, the index stays as I left it until I either add more to it or commit it or reset it.
sfink 7y ago
> I routinely `git rebase -i origin/master`. Sometimes from detached-HEAD mode. Which would both use `hg rebase`, so I'm not sure what you mean. Histedit is for reordering commits, or dropping some from the middle of a stack, and/or folding adjacent commits together. All in one go, if you so choose. All of which you could do with multiple rebase invocations, but histedit is an easier declarative interface to multiple rebase operations. On the flip side, it's limited to operating on linear chunks of the dag.
- cryptonector 7y ago
  But I also then choose to squash/fixup/edit/reorder commits. Mercurial insists I do that in two steps. WHY?