Re: RFD: best way to automatically rewrite a git DAG as a linear history?

From: Avery Pennarun <apenwarr@gmail.com>
Date: Feb 19, 2010, 20:20 UTC
Message-ID: <32541b131002191220q5a0eae6dk304173418f818ff3@mail.gmail.com>
In-Reply-To: <2cfc40321002182329q7b8c5b90nbd77a4e0678cd9c8@mail.gmail.com>

On Fri, Feb 19, 2010 at 2:29 AM, Jon Seymour <jon.seymour@gmail.com> wrote:

> If there are no merge conflicts in the original history, then there
> will be no merge conflicts in the rewritten history, and therefore no
> error deltas.

I'm just worried that this is a bit misleading. Just because there are no conflicts at the end doesn't mean these generated interim versions ever compiled or worked, does it?

Imagine that I have some code:

        f(a);
        g(x);

I change it so that f takes an extra parameter

        f(a, b);
        g(x);

Then I merge in someone else's branch that adds an extra parameter to function g, but hasn't changed f:

        f(a);
        g(x, y);

The merge causes a conflict, which I resolve in the obvious way:

        f(a, b);
        g(x, y)

Now I linearize it in the way you propose, removing the "unnecessary" merges but keeping the developer's conflict resolutions. What I end up with is the last code segment above - but I *don't* have the rest of the patch that added the extra parameter to g. So my conflict resolution is wrong for the code that remains. And the delta fixup doesn't show that there was anything weird.

Unless I've misunderstood something, you've thrown away the *advantage* that was autodetection of conflicts, in favour of having to eyeball it. I'm not sure there's an advantage there.

Show 5 quoted lines

> In the no  conflict case, it is not clear to me that the history
> resulting from your script is immediately rebaseable, precisely
> because of the presence of the merge commits [ feel free to correct me
> if I am wrong about that ] . With my approach, the merge commits
> dissolve away - there is nothing to edit.

I'm pretty sure that in the absence of conflicts, you could rebase -i my linearization and just remove the merge commits by hand, and things should go pretty smoothly. Or in the simplest cases (ie. the merged code is identical), rebase would notice that the merge patches have already been applied, and simply throw them away.

In any case, I guess if what you're doing works for you, then go for it. But in that case I'm not sure why you asked your original question; what about your current method *doesn't* do what you want?

If it's just a question of always auto-resolving conflicts using the local merge resolution, you might be interested in -Xours and -Xtheirs: http://n2.nabble.com/PATCH-0-8-The-return-of-Xours-Xtheirs-Xsubtree-dir-td4069081.html

If you're looking for more general suggestions about what to do when untangling a developer's horribly over-merged tree, you may want to consider a simple but inelegant solution that I've used myself sometimes: just squash the entire diff from upstream to developer's version into a single commit, then rip it apart again by hand. In my experience, developers who make messes of merges also don't divide their commits into sensible fragments in the first place, so re-dividing them yourself afterward is actually the fastest route to sanity.

Hope this helps.

Have fun,

Avery