6

So, yesterday I posted a question regarding some weird conflicts when I tried to rebase an upstream branch into my local topic branch.

In the end I used git rebase --merge upstream and solved a lot of conflicts in files I haven't touched since the previous rebase.

My understanding of rebase in such a case is that it detaches my commits from that topic branch, applies the commits from the upstream branch, and then applies (as patches) my commits on top of those. So, it ends up being a fast-forward operation. What I don't understand is... why would I have merge conflicts with those commits that come from upstream. Are those applied as patches as well? I thought is just... the act of "welding" some commits on top of the previous commit that came from the same branch?

I'm asking this because I had a lot of conflicts in files I haven't touched. Oh, and I do daily rebases with this upstream branch.

UPDATE

I've just noticed that some of the commits brought from the upstream to my topic branch have their SHA-1 id changed. Does anyone know what could cause Git do to this? Could it be the --merge switch?

My git version is 1.5.6.5

Community
  • 1
  • 1
Ionuț G. Stan
  • 176,118
  • 18
  • 189
  • 202
  • Do you have some kind of automatic conversion like in http://stackoverflow.com/questions/1042207/git-svn-rebase-fails? – VonC Aug 12 '10 at 08:45
  • @VonC `core.autocrlf` is blank, which I assume has the default value of "input". Could it be because of this? I'm not sure how I can reproduce the problem now, to see if setting it to false makes any difference. – Ionuț G. Stan Aug 12 '10 at 08:52
  • ț: make sure to set it to false, just to be sure. – VonC Aug 12 '10 at 09:11
  • 1
    I will. Thanks VonC, for generally being around and answering Git questions :) – Ionuț G. Stan Aug 12 '10 at 09:21

1 Answers1

3

Rebase re-writes history. If you rebase commits that have already been pushed to a remote, you are entering a world of hurt. Even worse if you continue to rebase like this. Rebase has it's avantages at times, but it is a specialty tool IMO, not a casual tool, like merge.

and then applies (as patches) my commits on top of those.

Yes, as new commits

So, it ends up being a fast-forward operation

No. A fast-forward is simply moving the pointer HEAD of that branch. You are introducing new objects from remote and then applying patches on top of that.

If your local and remote were last in sync at A1, and say you added (locally) A2 and A3 commits, and found that the remote had added B1 and B2, rebasing will stash A2 and A3, pull down B1 and B2 (should be a fast-forward since they share a common descendant A1), and then apply patches for A2 and A3 as new commits (hence new SHA-1) A2' and A3'.

So now your local history is: A1 - B1 - B2 - A2' - A3' which is not a fast-forward.

catsby
  • 11,276
  • 3
  • 37
  • 37
  • 1
    I know the perils of rebase, and I'm not using rebase like that. For some reason though, when I posted this question I had weird conflicts on files I haven't touched. Rebase is known to produce less conflicts than merge, but it didn't perform like that for me back then. Hence my question. I haven't found the cause, neither reproduce it. – Ionuț G. Stan Jan 08 '11 at 16:31
  • Great answer, particularly the last para! Lesson learned: any of rebase would mean all the rebased commits will have new commit IDs. – legends2k Feb 27 '19 at 14:05