6 ms·

Svn does do three-way merges, see the section "External diff" in the svn book. One thing I found in svn but couldn't find in git is merge tracking: you can mer

Svn does do three-way merges, see the section "External diff" in the svn book. One thing I found in svn but couldn't find in git is merge tracking: you can merge individual commits and svn records which commits have been merged. The equivalent operation in git would be cherry-picking, and I believe git does not track metadata on cherry-picked commits. Example: I have a branch A, and I've branched B off from A. B has extra commits x, y, z (in that order). I merge commit y into branch A. (In git, I would have to cherry-pick that commit.) Then I merge the whole branch into A. Now svn knows that y has already been merged, so it only tries x and z. But git (AFAIK!) attempts to apply all three changes, and then detects based on the file content that change y was already present. In svn, due to merge tracking, I can merge commit y into branch A and also make changes to the code in the process, and svn still knows to skip y on the final "full" merge.

WorldMaker 5y ago
git plumbing I believe can represent such merge DAGs (though possibly not with guaranteed semantics and in the category of "not well enough defined if you attempt it") but I don't think there's ever been a porcelain command in existence that can build/execute such merges. It's long been a complaint I have that cherry-pick is too rebase oriented. As someone who prefers "rebase never" approaches to git it irritates me that there isn't a non-rebase cherry-pick. Probably going even further off topic, in general I find it irritating with git that there's so much vocal "the DAG is aesthetically displeasing when used as a DAG" support that it seems tough for git to realize the power of its own DAG and/or better encode things that should be encoded in the DAG such as partial merges (versus today just throwing away partial merge information in rebases and cherry-picks) just because it "looks ugly" when actually used as such. Aesthetics should be the last concern over beneficial behavior? Aesthetics can be bolted on with cleaner user interfaces but lost data is always lost data?
- hibbelig 5y ago
  The very concept of the DAG makes it impossible to represent this situation. Am I overlooking something? On branch B, we have this chain: [x]-->[y]-->[z] And because x is a parent of y, if we record y as merged, then we also record x as merged. But the change wasn't in fact merged. In order for the DAG to represent this correctly, we need a commit y' that doesn't have x as a parent. Then y' can be merged. I don't believe that git tracks such relationships between commits y and y'.
  - WorldMaker 5y ago
    The DAG is labelled. Most labels are boringly "parent: commithash". In the raw plumbing you can build other labels, a "cherry-picks: commithash" or a "replaces: commithash" or all sorts of things. git log won't follow such edges today, but it doesn't need to, and a lot of the folks that don't like the DAG aesthetically might prefer that anyway, but the assumptions that "parent: commithash" are the "only" edges in the DAG aren't baked in as much as people assume. For instance, think about git notes, they can have some pretty exotic edges. Again, not many people use that power today and most of the git "porcelain" has no idea what to do with it, but the DAG as a raw data-structure absolutely supports it.
    - hibbelig 5y ago
      Very interesting. Thank you so much for teaching me. I guess it would be possible to create a git plugin that tracks such picked cherries and that provides changed merge and rebase commands. (The plugin would use the existing plumbing to provide new porcelain.) My current team relies on manual tracking: if there is a bug that needs to be fixed on a release branch and on the main branch, then the developer is responsible for adding commits to both branches. (Whether that is by making the commit on one branch and cherry-picking it to another, or by just making the change twice, is up to each developer.). I'm glad that everyone is so detail-oriented; normally we don't forget. But better support for cherry-picking would be quite useful imho.

WorldMaker 5y ago

git plumbing I believe can represent such merge DAGs (though possibly not with guaranteed semantics and in the category of "not well enough defined if you attempt it") but I don't think there's ever been a porcelain command in existence that can build/execute such merges. It's long been a complaint I have that cherry-pick is too rebase oriented. As someone who prefers "rebase never" approaches to git it irritates me that there isn't a non-rebase cherry-pick. Probably going even further off topic, in general I find it irritating with git that there's so much vocal "the DAG is aesthetically displeasing when used as a DAG" support that it seems tough for git to realize the power of its own DAG and/or better encode things that should be encoded in the DAG such as partial merges (versus today just throwing away partial merge information in rebases and cherry-picks) just because it "looks ugly" when actually used as such. Aesthetics should be the last concern over beneficial behavior? Aesthetics can be bolted on with cleaner user interfaces but lost data is always lost data?

hibbelig 5y ago
The very concept of the DAG makes it impossible to represent this situation. Am I overlooking something? On branch B, we have this chain: [x]-->[y]-->[z] And because x is a parent of y, if we record y as merged, then we also record x as merged. But the change wasn't in fact merged. In order for the DAG to represent this correctly, we need a commit y' that doesn't have x as a parent. Then y' can be merged. I don't believe that git tracks such relationships between commits y and y'.
- WorldMaker 5y ago
  The DAG is labelled. Most labels are boringly "parent: commithash". In the raw plumbing you can build other labels, a "cherry-picks: commithash" or a "replaces: commithash" or all sorts of things. git log won't follow such edges today, but it doesn't need to, and a lot of the folks that don't like the DAG aesthetically might prefer that anyway, but the assumptions that "parent: commithash" are the "only" edges in the DAG aren't baked in as much as people assume. For instance, think about git notes, they can have some pretty exotic edges. Again, not many people use that power today and most of the git "porcelain" has no idea what to do with it, but the DAG as a raw data-structure absolutely supports it.
  - hibbelig 5y ago
    Very interesting. Thank you so much for teaching me. I guess it would be possible to create a git plugin that tracks such picked cherries and that provides changed merge and rebase commands. (The plugin would use the existing plumbing to provide new porcelain.) My current team relies on manual tracking: if there is a bug that needs to be fixed on a release branch and on the main branch, then the developer is responsible for adding commits to both branches. (Whether that is by making the commit on one branch and cherry-picking it to another, or by just making the change twice, is up to each developer.). I'm glad that everyone is so detail-oriented; normally we don't forget. But better support for cherry-picking would be quite useful imho.