Re: is rebase the same as merging every commit?

From: David Jeske <jeske@willowmail.com>
Date: Aug 14, 2016, 00:43 UTC
Message-ID: <willow-jeske-01l7T9zdFEDjCigG>
In-Reply-To: <vpqd4m349hk.fsf@bauges.imag.fr>

This example you provided Matthieu is exactly my confusion with rebase..

If I want to bring a 'broken feature-a' branch into my topic branch to build on it, one commit of which is this:

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

if I merge, my tree looks like:

: /<--G<--H<--Qj jeske/topic1 : / / : /<--P<------Q feature-a : / : -----A<---B<---C master

or if I rebase, it looks like:

: /<--G'<--H' jeske/topic1 : / : /<--P<---Q feature-a : / : -----A<---B<---C master

-----

..and then through 'fixing' the patch, it ends up rebased and accepted onto the mainline origin/master, as a single patch, which (among other things) changed this line to:

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

...if I merged above, it will look like,

: /<--G<--H<--Qj jeske/topic1 : / / : /<--P<------Q feature-a : / : -----A<---B<---C<---Q' master

...if I rebased above, it will look like:

: /<--G'<--H' jeske/topic1 : / : /<--P<---Q feature-a : / : -----A<---B<---C<---Q' master

However, in both cases, because Q' is not connected to Q, I don't see how git will do anything sane to help me accept Q' correctly.

If I rebased my merge-q-branch against the master, I would expect to get this (which will cause a conflict I have to resolve):

: /<--G<--H<--Qj jeske/topic1 : / : <--C<---Q' master

If I rebased my rebase-q-branch against master, I would expect to get this (which will cause a conflict I have to resolve):

: /<--G'<--H' jeske/topic1 : / : /<--P<---Q feature-a : / : --C<---Q' master

However, if that Q' rebase contained a link back to (P,Q), it would know that the Q' rebase was replacing (P,Q), and would know to back them out of my tree when I rebased back onto the head, producing this in BOTH cases above (whether I rebased or merged from the feature-a branch):

: /<--G'<--H' jeske/topic1 : / : --C<---Q' master

This operation above of "working will pulling uncompleted patches into my tree" seems like a fairly common thing for developers. I've never provided any patches to linux-kernel, but when I did try hacking on it years ago, I was doing exactly this. (pulling unaccepted patches into my kernel, then building on those patches). When I read about the DAG and its universal naming, I always assumed that the above workflow was what it was DESIGNED to make automatic. I'm confused, how does this work in git?

-- Matthieu Moy wrote:

Show 21 quoted lines

> 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.