3 ms·
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
by 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 agoJust 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 agoThis 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.