0

Let's say I have

main - 1 - 2 - 3 (A)
    \
     4 - 5 - 6 (B)

The remote repo's manager wants to merge A to main (ff) first, then merge B to main. Thus, he wants me to merge A into B first so there won't be issues later on:

              (A)
main - 1 - 2 - 3
    \           \ 
     4 - 5 - 6 - 7 (B)

           (A)
0 - 1 - 2 - 3
 \           \
  4 - 5 - 6 - 7 (B, main)

(an 8th commit isn't needed, right? Just ff main twice?)

My question is: would I get the exact same result (including git history or any other factors I don't know about) if I did this instead:

(I'll explain why I want to later on)

Create a copy of A, A', then merge B into A',

              (A)
main - 1 - 2 - 3 - 7 (A')
    \             /
     4 - 5 ----- 6
                (B)

Then fast-forward B into A', deleting A' after,

              (A)
main - 1 - 2 - 3 - 7 (B)
    \             /
     4 - 5 ----- 6

Finally ff main.

           (A)             
0 - 1 - 2 - 3 - 7 (B, main)
 \             /           
  4 - 5 ----- 6

Are there any reasons to avoid my second method?

Why I want to do this:

B contains some wrong changes from main that I don't want/is wrong. I don't remember what those changes are. If I merge A into B, these changes would still be there.

Therefore, I would like to manually vet through all changes made by B.

I could do an interactive rebase, but B has many commits. I don't want to go through all of them, and I also don't remember which commits introduced the wrong changes. Also, A made some renames that affected many files, which would cause conflicts I'd have to fix on every commit.

I also saw a three-way merge tool as option but I've never used that before and found this way easier.

Merging B into A' instead of A into B puts all the changes B has with respect to A in the working tree, allowing me to vet through all of them at once.

Nathan Tew
  • 432
  • 1
  • 5
  • 21

2 Answers2

1

Git doesn't care about branches... here's the gist of it: to git, branches are pointers to commits. So, if you create a new branch over a commit, it's not like there's any change in history.... you are just creating a new pointer to the same commit.

Having said that, what you should do is track down where the broken change came from, then git rebase -i to edit the broken commit and remove the broken changes from that commit (or even remove the whole commit from history if needed).

Now, how can you easily know where the broken change came from? Normally, it's about running git blame or git annotate on the broken file to see where the broken lines where introduced. The other technique you can use is using git bisect which is a very handy tool that should be in the toolbox of developers who prides themselves of being such.

eftshift0
  • 26,375
  • 3
  • 36
  • 60
  • 1. I get that creating a new branch doesn't affect anything but I was more of asking whether merging B into A instead of A into B will cause any unwanted effects on the history. 2. are you talking about rebasing B onto A, or rebasing B onto itself to edit out the broken change, before merging A into B? – Nathan Tew Sep 03 '23 at 03:30
0

The file content will be the same (assuming the conflicts are resolved in the same way), but the order of the parents in the resulting merge commit will be different. This affects notations like HEAD~3 and commands like git log --first-parent. It is usually best to merge a side/feature branch into a "main line" branch and not the other way around, so that the first parent will be the history of the main line.

This might also be a reason not to use a fast-forward merge into main to bring in a sequence of commits that ends with a merge commit.

See https://stackoverflow.com/a/7645143/298656 and https://stackoverflow.com/a/7645133/298656 for more details.

jilles
  • 10,509
  • 2
  • 26
  • 39