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

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

Reply via email to