Tony Luck <[EMAIL PROTECTED]> wrote:
> > * Even if it does always choose the nicer choice of the two,
> > Tony was lucky (no pun intended). Rather, we were lucky that
> > Tony was observant. A careless merger may well have easily
> > missed this mismerge (from the human point of view).
> Actually I can't take credit here. This was a case of the "many-eyes" of
> open source working at its finest ... someone e-mailed me and told me
> that I should have backed out the old patch before applying the new one.
> While typing the e-mail to say that I already had in the release branch,
> I found the problem that it had been "lost" in the merge into the test
> But this is a good reminder that merging is not a precise science, and
> there is more than one plausible merge in many situations ... and while
> GIT will pick the one that you want far more often than not, there is
> the possibility that it will surprise you. Maybe there should be a note
> to this effect in the tutorial. Git is not magic, nor is it imbued with
> DWIM technology.
I have to disagree. If in some corner case it can do the wrong thing, no
amount of "I told you so in the docu!" will save the day. People /will/
overlook it, or be bitten when they have all but forgotten about it.
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html