Git Tricks: Avoiding merge when dealing with remote conflicts

Re:Git Tricks: Avoiding merge when dealing with remote confl... by bob1029 on Monday October 21, 2019 @07:56PM (#21318919)

We have been struggling between the merge/rebase approaches with no clear winner in our minds so far. In principle the rebase seems to be superior, but I can certainly see arguments for using merge if it satisfies downstream concerns like traceability (I am still not clear on this stated benefit).

Perhaps someone has a list of criteria that can help you pick between the 2 approaches, or perhaps both merge/rebase are valid at all times, but there is a certain set of rules to evaluate when choosing which to use?

[ Parent | on HN ]

Re:Git Tricks: Avoiding merge when dealing with remote confl... by kazinator on Monday October 21, 2019 @08:53PM (#21319285)

rebase has good traceability, if you retain the original artifacts.

When we rebase a public feature branch and merge it into a mainline, we nicely have two versions of that.

Basically, rebase and merge could be reconciled like this: we could merge a feature branch by iterating over it, and invidiually doing a git merge for every commit. Then that would be a rebase. Except that every commit would have an additional parent pointer which cross-references it to the original branch.

I.e. good rebase:

                   B0---B1---B2
                  /
       --- A --- B ---- C --- D --- B0' --- B1' --- B2'

good merge (exact same thing, just with parent pointers):

                   ---------------B0-----B1-----B2
                  /                 \      \      \
       --- A --- B ---- C --- D --- B0' --- B1' --- B2' ---

typical silly git merge:

                   --B0-----B1-----B2
                  /                 \
       --- A --- B ---- C --- D --- B{0+1+2}

still, that cross-referencing parent info in the second example above is not that useful. It's still making a salad out of the git graph. And is not two-way navigable, either. (Say I'm looking at B1 and want to locate B1'.)

It's better to have something in the commit messages to track changes that get cherry picked in multiple places. The Gerrit review system has a Change-ID: line with a 160 bit random ID, for instance. All rebases/picks of the same change carry the same ID, which correlates them to the same review item.

[ Parent | on HN ]