One use case is given branch X, tell me what the branch looked like N commits in the past. Git cannot tell you this because all parent commits are equal. DVCS workflows tend towards lots of short-lived branches where it is less useful (which is why hg has bookmarks).
It can also just simplify certain things. I can tell by checking if a commit is reachable from e.g. the v1.2 bugfix branch but not from master that the commit was post the 1.2.0 release to fix a bug.
With hg branches you can just see that the commit was made the the v1.2 bugfix branch. This is very minor, but my experience with hg is that there are dozens of these minor niceties that are why a lot of hg users are still around despite git having clearly won the popularity contest.
>One use case is given branch X, tell me what the branch looked like N commits in the past.
What am I not understanding here? You definitely can go N commits in the past on each branch, and even any commit. And if you rewrite history you can even use the reflog to really tell what the branch was like (as long as it hasn't been cleaned out).
You're right, it's not moved across remotes. I'm just confused to why the information would ever be needed. It seems to not have any real use case. You can recreate a branch any where at any point in the history, why would you care what commit a branch originally came from? It seems like a solution in search of a problem. Or maybe even a solution to a problem that shouldn't need solving in the first place!
>If I make a fresh clone of a repository, that doesn't tell me what the branch was like a year ago.
This isn't true with Mercurial either. A lot can happen in a year, and it might even make the information misleading (having similar named branches, history deletion, etc). It's useless at best and misleading at worst.
"This commit has a bad commit message. Why did I commit it? Oh, it's on the branch add-search-functionality."
I find that having a branch name that was the sole branch name when the code was made gives context to the commit; why it was made and what its purpose was. Being reachable from a branch pointer doesn't give that same context. Yes, commit messages should handle this. But I find they don't.
> It's useless at best and misleading at worst.
This has not been my experience. I haven't found a great need for "what's the whole state a year ago"; more so "what was the context around this commit", which I think a mercurial-style branch name answers.
I'm sorry, in what practice are you in where your commit messages are somehow so lackluster that a branch name (not even a PR!) can give you more information about why something is being done?
And to make sure no one responds with some silly "just because you don't have a use for it, doesn't mean don't have their uses for it": I get what you're trying to say. I'm really just not buying it as an actual use case. If your commit message isn't sufficient enough to explain the purpose of the commit (ticket numbers, explanation, etc), it doesn't get approved. If you're relying on a <20 character branch name to give you sufficient context about a commit a year later, I simply have no words.
>which I think a mercurial-style branch name answers.
> If your commit message isn't sufficient enough to explain the purpose of the commit (ticket numbers, explanation, etc), it doesn't get approved.
I'm glad this is the case where you work and develop. I have never worked at a company where this is the case. I'm also not perfect about commit messages in my personal code. The codebase I'm currently working on has recent commits with description "review", "add addressDto" and "post rebase fix".
> >which I think a mercurial-style branch name answers.
> I find that extremely suspect.
Ok. If I see "add addressDto" as a part of the branch "google-geocoding", that tells me the context. If I see it as part of "refactor-to-use-hibernate", that also tells me something useful.
>The codebase I'm currently working on has recent commits with description "review", "add addressDto" and "post rebase fix".
I guess what I don't get, is that if you have people doing commit messages like that, how can you possibly expect them to appropriately name a branch which most likely stores far less characters.
Far too often the commit message says "what" while the branch name says "why."
Just recently I had to triage a recently discovered bug whose symptoms disappeared about 4 years ago to determine if the bug was fixed or just masked. This was code that I was completely unfamiliar with because the other engineers that might have looked at it were otherwise indisposed working on things that were known for sure to be issues.
The "what" told me the specific change that masked the bug and the "why" informed me of the feature that this supported. That allowed me to generate a new test-case that showed up in the current version. Without both pieces of information I would likely have had to spend a couple of hours inspecting code changes to do the same.
Because you're less in the nitty-gritty when naming a branch, so you're more likely to name it with something referencing the large feature you're working on.
I work with two codebases with over 200k commits and over 10k branches each. Sometimes the branch names are useless.
Sometimes the commit messages are poor. Often knowing one helps provide more context for the other.
Believe it or not, there were times in the last 20 years when there was insufficient review of commit messages!
It's sometimes very useful, but not that often. It's not great for short lived feature branches. It's for long-term branches. If you don't need those (and most often you do not): great, your life is (relatively) simple; don't over-complicate it. You don't buy the use-case, because the situation is not that common or desirable. But once you get in a situation where you really do need multiple long-term branches developed in parallel, you might be happy to have a tool that helps untangle the web of merges somewhat.
Please elaborate how this helps you in long-term branches, instead of just assuming long-term branches aren't something most people deal with on a daily basis.
>you might be happy to have a tool that helps untangle the web of merges somewhat.
This has no relation to long-term branches, this happens with any kind of normal history, and even shared history between repositories (which is a far messier thing to untangle). Yet this feature is unneeded, because the information can be correctly found within git in an accurate and not misleading fashion.
It can also just simplify certain things. I can tell by checking if a commit is reachable from e.g. the v1.2 bugfix branch but not from master that the commit was post the 1.2.0 release to fix a bug.
With hg branches you can just see that the commit was made the the v1.2 bugfix branch. This is very minor, but my experience with hg is that there are dozens of these minor niceties that are why a lot of hg users are still around despite git having clearly won the popularity contest.