4 ms·

Okay, so you have to think about repository state in order to understand rebasing. You share some common history with your remote repository (for the sake of a

Okay, so you have to think about repository state in order to understand rebasing. You share some common history with your remote repository (for the sake of argument lets assume you've got a single remote repo that you and your friends push to). When you make changes and commit them locally, what you're doing is adding new commit nodes to the history tree of your local repository. When you push to the remote repo, the chain/branch of commit nodes from your local repository gets added on to the remote repository's history. BUT, if, while you were working and committing, someone else adds commits to the remote repository... There is now new history in the remote repository that you do not share. What rebasing does, is say "take all the commit nodes from my local branch (remember them), and rewind the history back to the point where my repository was in synch with the remote repository. THEN update my repository with the remote changes, and try and apply all my local commits on top of my newly synched tree." TL;DR: if your commit tree looks like this (where 'H' are commits which you share with the remote repository. 'L' are local commits and 'R' are new commits to the remote repo, which you don't have): H-H-H-H-H-L-L-L-L Your friend pushes his changes so the remote repository now looks like H-H-H-H-H-R-R-R-R Rebasing does this: 1) H-H-H-H-H [snip] L-L-L-L 2) H-H-H-H-H << R-R-R-R 3) H-H-H-H-H-R-R-R-R << L-L-L-L If there are conflicts, Git steps through each of your commits and lets you fix the problems and merge. If there are no conflicts, it just seamlessly merges.

acqq 16y ago
Thanks knowtheory, that's exactly what I wanted to read, that git pull --rebase is "take all the commit nodes from my local branch (remember them), and rewind the history back to the point where my repository was in synch with the remote repository. THEN update my repository with the remote changes, and try and apply all my local commits on top of my newly synched tree."" Now what's "git pull" explained in the same terms? Is it "produce errors as if remote were in sync with local even if it's obvious it isn't"? Who needs that? If it's not, then what is a proper description? And is there any scenario in which remote was changed, you want to push there your changes and you wouldn't want "git pull --rebase"? Thanks!
- lincolnq 16y ago
  "Normal" git development (without rebasing) naturally creates a branching history when two people make changes based off a common root. As was explained above, rebasing causes this branching history to be rewritten into a linear one. The alternative is merging, where you cause Git to record what actually happened -- which is that two changes occurred simultaneously and you explicitly brought them in sync again. Sometimes (often) this is what you want -- it's especially useful for longer-lived branches of work, where having the history of the branch can be valuable in itself. Also, if you share a commit with someone, you can no longer safely rebase it! The reason is that part of the definition of a commit is its set of parents -- the commits it depends on (usually 1, but can be 2 or more for a merge commit). When you rebase, you are rewriting all the parents, so you end up creating a whole stream of new commits and discarding the old ones. If you then attempt to share history with someone who has the old ones, presumably Git will become confused. (I've never actually run into this problem, but I don't use rebasing much.)
  - acqq 16y ago
    Those are good arguments why "pull --rebase" is not a default action, thank you. Now I don't understand why either "pull" or "pull --rebase" is supposed to have any different behaviour when somebody does it! As far as I undestand git has enough information not to complain more in one case and less in another, and as far as I understood, the main argument of the main article was that "--rebase" somehow "eases some pain"!? How come?
deleted 16y ago
[deleted]

acqq 16y ago

Thanks knowtheory, that's exactly what I wanted to read, that git pull --rebase is "take all the commit nodes from my local branch (remember them), and rewind the history back to the point where my repository was in synch with the remote repository. THEN update my repository with the remote changes, and try and apply all my local commits on top of my newly synched tree."" Now what's "git pull" explained in the same terms? Is it "produce errors as if remote were in sync with local even if it's obvious it isn't"? Who needs that? If it's not, then what is a proper description? And is there any scenario in which remote was changed, you want to push there your changes and you wouldn't want "git pull --rebase"? Thanks!

lincolnq 16y ago
"Normal" git development (without rebasing) naturally creates a branching history when two people make changes based off a common root. As was explained above, rebasing causes this branching history to be rewritten into a linear one. The alternative is merging, where you cause Git to record what actually happened -- which is that two changes occurred simultaneously and you explicitly brought them in sync again. Sometimes (often) this is what you want -- it's especially useful for longer-lived branches of work, where having the history of the branch can be valuable in itself. Also, if you share a commit with someone, you can no longer safely rebase it! The reason is that part of the definition of a commit is its set of parents -- the commits it depends on (usually 1, but can be 2 or more for a merge commit). When you rebase, you are rewriting all the parents, so you end up creating a whole stream of new commits and discarding the old ones. If you then attempt to share history with someone who has the old ones, presumably Git will become confused. (I've never actually run into this problem, but I don't use rebasing much.)
- acqq 16y ago
  Those are good arguments why "pull --rebase" is not a default action, thank you. Now I don't understand why either "pull" or "pull --rebase" is supposed to have any different behaviour when somebody does it! As far as I undestand git has enough information not to complain more in one case and less in another, and as far as I understood, the main argument of the main article was that "--rebase" somehow "eases some pain"!? How come?

deleted 16y ago

[deleted]