On Fri, Feb 19, 2010 at 2:29 AM, Jon Seymour <jon.seymour@xxxxxxxxx> 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.
> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html