3 ms·

If you don't like losing branch names then I'm genuinely curious what you think is wrong with Mercurial's solution?

• o11c 3y ago
  Mercurial branches get in the way. Branches should be recorded in commits, not contain or constrain commits. `git` records one side's branch name for merge commits, which is great ... except it doesn't record the other, or record anything for fast-forward or rebase. And what it does record isn't directly machine-readable.
  • krupan 3y ago
    Hmm. Are we both talking about Mercurial branches and not maybe bookmarks or something different? It's been a while since I've used mercurial but from what I remember the branch name is recorded as part of the commit? I'm not sure I understand what you mean by containing or constraining or being in the way, either, sorry. If you are rebasing you are modifying history generally to purposefully remove a branch in the DAG. I'm not sure you'd want to keep a branch name in that case?
  • chthonicdaemon 3y ago
    I cannot find any reference for "`git` records one side's branch name for merge commits". From what I understand a merge commit just has two parent references (commit hashes) instead of one.
    • o11c 3y ago
      It sets the commit message to: Merge branch 'feature' (several variations exist) and when people add a real commit message, they generally preserve that much at least. With certain reasonable git workflows this technically does preserve sufficient metadata, but there are far too many edge cases for completeness.