Re: is rebase the same as merging every commit?

From: Matthieu Moy <matthieu.moy@imag.fr>
Date: Jun 27, 2008, 07:34 UTC
Message-ID: <vpqd4m349hk.fsf@bauges.imag.fr>
In-Reply-To: <willow-jeske-01l7GhRWFEDjChtB>

"David Jeske" <jeske@willowmail.com> writes:

> However, when considering an SCM perspective, I don't understand why I have to
> make a tradeoff between personal reproducibility (which I get from the original
> changes), and upstream readability (which the community gets from my rebase).

Well, look at the [PATCH] messages on this list, and how they evolve. Patch series give a clean way to go from a point to another. That's what you want to see in upstream history.

Then, patch series usually get reviewed, and the patches themselves are modified. There's a kind of meta-history: the changes you make to your own changes.

Suppose I send a patch containing

+	int * x = malloc(sizeof(char));

and someone notices how wrong it is. I send another patch with

+	int * x = malloc(sizeof(int));

The first version was basicaly a mistake, and if it hasn't been released, no one want to bother with it longer that the time to resend the patch. No one want to be hit by the bug while using bisect later on the upstream repository. And no one wants to see both patches when reviewing or "git blame"-ing.

Things you rebase in Git are just like things for which you don't make intermediate commits in SVN.

Show 18 quoted lines

>>From all I've read about rebase, bisect, and the big tree management, it seems
> like the three steps are Reorder, combine, rebase.  (In a more complicated
> situation, i'd want to split a commit into pieces)
>
> (1'')
> 0' - feature A
> 1' - bugfix a
> 2' - bugfix a2
> (2'')
> 3' - feature b
> 4' - bugfix b
> (3'')
> 5' - feature c (split)
> (4'')
> 6' - feature d (split)
>
> Frankly, I'm super impressed, because I can imagine how I might do
> this in git.

git rebase -i will help you to do that painlessly.

> I want to mess around and try this stuff out, but I'm scared of doing bad
> things to the tree and them being unrecoverable

They won't. The reflog is still there. Try it, an cancel it if you don't like.

The huge difference between the reflog and the history is that the reflog is local, it's your own mess, other people won't get disturbed by how messy it can be.

> (other than the fact that the current dag
> link propagation model would force others to get these changes if
> they remained connected together. Something easily remidied by out
> of band metadata, or different link types)

No. One fundamental principle of Git is that objects are immutable. If your objects have a link, of whatever kind, then the same object moved in another repository have the same link.

But what's wrong with the reflog?

-- 
Matthieu