3 ms·

Mercurial is a fantastic VCS system that helped me get 'into" DVCS, and for that I am thankful. Even in 2013, it feels like it has the superior windows interfa

by AlexMax 13y ago

Mercurial is a fantastic VCS system that helped me get 'into" DVCS, and for that I am thankful. Even in 2013, it feels like it has the superior windows interface in TortoiseHG and I loved how extensions for Mercurial were usually a lot more cross-platform than git since they were usually just written in Python. That said, once I got my head around the full ramifications of Git's lightweight branching, I still think it was the better choice over named branches and bookmarks. When learning Mercurial, SVN-minded me naturally gravitated towards branches for everything because of the name, and learning the distinction of when to use bookmarks and when to use branches wasn't exactly clear until I finally understood how Git's branches worked - and at that point the thought of enshrining branch names in the history forevermore suddenly turned from an obvious "why not?" to a "why?". Git's interface can always get better, but Mercurial will always have branches that live forever in history and are named "Branches". Still, in Bizarro-2013 where Git never existed or never got the boost from Github, I think Mercurial would have been just as serviceable, and I think that it's a great second option to present if you want to migrate to a DVCS but your teammates can't get their head around Git. Kudos to them on another release.

jordigh 13y ago
There is a good reason to have branch names tattooed on commits: it makes inspecting the history much easier. When you are looking back and history and want to know why you did something, unless you're meticulous about encoding this information in your commit message, it helps a lot to have it encoded in the commit's metadata instead. There are also hg tools that help leverage named branches, e.g. revsets. Just today I wanted to figure out exactly on what commit did we merge the gui branch of Octave into default. I ran the following: hg log -r "children(parents(branch(default) and merge()) and branch(gui))" This told me that the merge happened a year ago, and told me exactly what commit did it. This would not be possible if the history did not record the branch name. I like hg's way: bookmarks for lightweight changes, named branches for long-lived lines of development. Both have their place, and both are useful.
- AlexMax 13y ago
  Just because Git branches are lightweight doesn't mean they MUST be lightweight and thrown away. In your use-case, the `gui` branch ref would point at the merge commit, so you could simply ask for it by name. Being an old branch, however, you could then move the branch into an 'attic' or a different namespace than the active branches so it doesn't come up every time you `git branch`. That sort of flexibility to move branches around when needed was what made me question Mercurial's approach to forever-branches in the first place.
  - jordigh 13y ago
    This is but one example. On git, if there was more back and forth merging between two branches, you can't figure out on which branch a commit was made later by merely inspecting history unless you encode this information in commit messages.

by AlexMax 13y ago

jordigh 13y ago

There is a good reason to have branch names tattooed on commits: it makes inspecting the history much easier. When you are looking back and history and want to know why you did something, unless you're meticulous about encoding this information in your commit message, it helps a lot to have it encoded in the commit's metadata instead. There are also hg tools that help leverage named branches, e.g. revsets. Just today I wanted to figure out exactly on what commit did we merge the gui branch of Octave into default. I ran the following: hg log -r "children(parents(branch(default) and merge()) and branch(gui))" This told me that the merge happened a year ago, and told me exactly what commit did it. This would not be possible if the history did not record the branch name. I like hg's way: bookmarks for lightweight changes, named branches for long-lived lines of development. Both have their place, and both are useful.

AlexMax 13y ago
Just because Git branches are lightweight doesn't mean they MUST be lightweight and thrown away. In your use-case, the `gui` branch ref would point at the merge commit, so you could simply ask for it by name. Being an old branch, however, you could then move the branch into an 'attic' or a different namespace than the active branches so it doesn't come up every time you `git branch`. That sort of flexibility to move branches around when needed was what made me question Mercurial's approach to forever-branches in the first place.
- jordigh 13y ago
  This is but one example. On git, if there was more back and forth merging between two branches, you can't figure out on which branch a commit was made later by merely inspecting history unless you encode this information in commit messages.