1

I know that baseless merges in Team Foundation Version Control are dangerous. I was wondering if it was also dangerous with Git.

If you are unfamiliar with a baseless merge, here's an example. The red dotted line is a baseless rebase/merge.

Is it safe to do this with Git?

Edward Thomson
  • 74,857
  • 14
  • 158
  • 187
christo8989
  • 6,442
  • 5
  • 37
  • 43

4 Answers4

10

Well, yes and no. Team Foundation Version Control (TFVC) enforces a branch hierarchy, and it has a rule that you can only merge from a branch to its parent or a child. In the image you provide, you can merge B to C and that is not a baseless merge. Merging B into C will use B3 as the common ancestor and produce a nice, easy to deal with three-way merge.

However, TFVC does not allow you to merge A directly into C. You are expected to merge A into B, then merge the result into C. If you want to go around this workflow, you're stuck doing a baseless merge, which skips common ancestor computation. The result is that you're doing a three-way merge without a common ancestor - both files look like new additions and any differences between them will be treated as conflicts.

It's a giant pain.

Git doesn't try to enforce any branch hierarchies, so in your illustration, you can merge from C to A without penalty. A3 would be the common ancestor in this case, and you would have the following graph:

                C  1--2--3----M
                  /          /
        B  1--2--3--4--5    /
          /                /
A  1--2--3--4--5-----------

So this scenario is not a baseless merge in Git, however you can still have a baseless merge in Git. If you try to merge two branches that have no common ancestor (no merge base) then this would be a baseless merge and it would have all the problems that occur when you do a baseless merge in TFVC.

You can try this by creating a new branch with no parents (via git checkout --orphan).

Edward Thomson
  • 74,857
  • 14
  • 158
  • 187
0

You can use git cherry-pick to apply arbitrary commits to any branch.

Daiku
  • 1,237
  • 11
  • 20
0

What you show in red is a perfectly normal merge with git and you won't have difficulties except some 'normal' merge conflicts if you change things in the 2 branches at the same place in the same files. Otherwise, no problems!

But if you don't need to materialise the merge, indeed, you could cherrypick.

But what is good with git is that you could try and undo (a merge is really easy to undo!). So without too much difficulties, you could try the merge and see what happens, answer your own question ;-) and undo if you are not satisfied!!

Welcome away of tfs ;-)

Philippe
  • 28,207
  • 6
  • 54
  • 78
0

"Does it" is already answered, but I got here asking "How to do it". That may have an answer elsewhere, but to perform a baseless merge in git you can follow these commands. I am

  • Trying to get all of main into stage and ignore history
    • Files deleted in stage only should be re-added
    • Changes made in stage only should be reverted to match main
    • Files added in stage only should be deleted but are not - This solution does not delete extra files. This answer about reparenting may address that.
  • Creating a temporary branch called orphan-main
  • Creating a branch called my-pr-branch that contains the changes I want on stage
git checkout --orphan orphan-main main
git commit --allow-empty -m 'orphan initial commit'
git checkout -b my-pr-branch --no-track stage        # or w/o my-pr-branch: git checkout stage
git merge orphan-main --allow-unrelated-histories
git branch -D orphan-main                            # optional
mlhDev
  • 2,235
  • 1
  • 22
  • 43