5 ms·

> Git doesnt keep the name of a branch after it's merged... Eh? This is trivial to change by specifying the "--no-ff" option to `git merge`, or by setting the

• doubleunplussed 7y ago
  That's not what I'm talking about - after a no-ff merge, sure you can tell that there were two branches, but how can you tell which was which? Which was master and which was the feature branch? You can use convention to store this information, e.g. the first parent is always master, or you can put the info in the merge commit message. But it's hacky. In mercurial the branch name lives on forever, attached to those commits whether they are merged or not. "Closing" a branch in mercurial is just a hint that it isn't going to be used for the time being and so shouldn't be listed in tools that list branches, but doesn't actually remove the label from previous commits. So the commit history has the branch names still after a merge. This way you can say "show me all commits in the master branch" (as distinct from "show me all ancestors of the tip of the master branch") and this will exclude feature branches, and is ideal for bisecting.
  • ilikepi 7y ago
    I mean...ok, I guess if you allow committing directly to master, and you allow merging in both directions...sure, I see your point. In our repos, we allow neither, so all non-merge commits are, by definition, on a feature branch on the right-hand-side. I guess one person's hacky convention is another's primary workflow. ¯\_(ツ)_/¯
    • doubleunplussed 7y ago
      Does this mean you can't have merge commits in feature branches? And what about maintaining a release branch? There are good reasons to be merging in both directions sometimes, even if you never commit directly to master.