No, git has labels on heads of branches. Once the head moves you loose the information. It also makes for a more messy history, which I believe created the whole “rebase everything” philosophy to cope.
If I hand you a commit, you cannot tell which ‘branch’ it is on without searching the git history and hoping that you only get one answer. That’s a bummer if, for instance, you’re a github action and only get handed the commit. If it’s on the master branch, I want to do different things than if it’s a dev branch.
Care to explain your comment for a layman?
From my limited experience mercurial is way more intuitive than git. The big one is named branches are a thing instead of an abstraction.
What do you mean by “are a thing?” Git has branches.
No, git has labels on heads of branches. Once the head moves you loose the information. It also makes for a more messy history, which I believe created the whole “rebase everything” philosophy to cope.
What information is “loosed” when another commit is made to the branch?
If I hand you a commit, you cannot tell which ‘branch’ it is on without searching the git history and hoping that you only get one answer. That’s a bummer if, for instance, you’re a github action and only get handed the commit. If it’s on the master branch, I want to do different things than if it’s a dev branch.
A commit all by itself doesn’t mean as much without context.
Why would I not want to be able to apply a commit to any arbitrary branch?
Also, GitHub is not git - it’s based on git. Any shortcomings it may have aren’t necessarily due to a flaw in git.
Luckily a commit points to its parent, which means the context is inherently present. What’s your point?
Nobody said that.
True enough.
Your claim appears to be that Mercurial binds commits to branches, and I’m explaining how I fail to see the advantage.
It makes the history clearer.