-1

When i merge a branch into another, there will be a three-way merge. Git will check the common parent of a file and tries to figure out how to merge. Here conflict is possible.

With a rebase i do not see, that a conflict is possible, because my commits are just dropped upon the existing ones. Is my understanding right?

David
  • 2,926
  • 1
  • 27
  • 61
  • If you search for "git rebase conflict", you'll get a lot of hits (like this: [Why does git rebase trigger a merge conflict?](https://stackoverflow.com/q/63089787/2745495)), which suggests that yes, a conflict is still possible. – Gino Mempin Jul 10 '22 at 11:56
  • 1
    .... and no, it's not right. You might do a merge without conflicts and try a rebase and get conflicts (because the conflicting block was modified in later revisions so that the merge does not conflict but a rebase has to go revision by revision which a merge does not). – eftshift0 Jul 10 '22 at 12:00
  • Yes, conflicts are possible. You can't "drop" commits onto other ones, each diff requires certain preconditions to even make sense. – mousetail Jul 10 '22 at 12:04
  • @mousetail But why? Is a rebase not just like a new commit, that offers a new change and that change can be anything? Why does it have to make sense? When the file changes to something, it just changes to a new state, right? – David Jul 10 '22 at 12:33
  • 2
    A commit is basically a set of instructions like "replace some lines that look like X to lines that look like Y". However, if the lines that look like X have been changed/modified the commit makes no sense – mousetail Jul 10 '22 at 12:35
  • @mousetail i thought i commit is just a new blob, if only one character changes. What am i confusing? – David Jul 10 '22 at 12:36
  • 1
    No, while a commit is kind of like a blob a rebase doesn't re-use the blobs of the commits but generates new snapshots based on the diffs of each commit and the previous. – mousetail Jul 10 '22 at 12:39
  • 1
    Actually, it is not dropping the commits upon the existing ones but applying the changes introduced by those commits. Merges, rebases and cherry-picks can produce conflicts because, under the scene, they mean combining the changes from the merged/rebase/cherry-picked commits with the code of the target commit that, most probably, differs from the code in the parent of the merged/rebase/cherry-picked commit. – axiac Jul 10 '22 at 18:14
  • 3
    A rebase _is_ a merge. (Actually, a rebase is a series of cherry-picks, and a cherry-pick is a merge.) Therefore a merge conflict is possible. – matt Jul 10 '22 at 18:15

1 Answers1

1

The recommended way to think of a commit is as a snapshot of all the files. Of course, internally, git stores diffs and the like, but conceptually, each commit is a full snapshot of the repo at that time.

Suppose the common parent branch is B1. And the other two branches involved in the rebase are B2 and B3.

Now suppose on B1 there is no file called abc.c. Branch B2 adds this file and writes some code for the sales engine there, while branch B3 adds a file with the same name and writes some code for the reporting engine. Which one shout Git keep?

Understandably, the developers of git have chosen to declare a conflict here and let the user decide.

Gec
  • 428
  • 2
  • 10
  • Since it is a rebase i would say, keep the last one, but i now get, that it is a merge just with a clean commit order. Right @Gec? – David Jul 10 '22 at 18:14
  • Yes, it's sort of a special way of merging. If Git decided to keep the last one, all sorts of weird situations can happen, as I'm sure you can think of. – Gec Jul 10 '22 at 18:37