On Thu, 8 Sep 2005, Fredrik Kuivinen wrote:
> The first one agrees with what was actually committed. For the second
> one the difference between the tree produced by the algorithm and what
> was committed is:
>
> diff --git a/include/net/ieee80211.h b/include/net/ieee80211.h
> --- a/include/net/ieee80211.h
> +++ b/include/net/ieee80211.h
> @@ -425,9 +425,7 @@ struct ieee80211_stats {
>
> struct ieee80211_device;
>
> -#if 0 /* for later */
> #include "ieee80211_crypt.h"
> -#endif
>
> #define SEC_KEY_1 (1<<0)
> #define SEC_KEY_2 (1<<1)
>
>
> I have looked at the files and common ancestors involved and I think
> that this change have been introduced manually. I may have missed
> something when I analysed it though...
Certainly possible that it was done manually.
> > > The merge cases reported by Tony Luck and Len Brown are both cleanly
> > > merged by my code.
> >
> > Do they come out correctly? Both of those have cases which cannot be
> > decided correctly with only the ancestor trees, due to one branch
> > reverting a patch that was only in one ancestor. The correct result is to
> > revert that patch, but figuring out that requires looking at more trees. I
> > think your algorithm should work for this case, but it would be good to
> > have verification. (IIRC, Len got the correct result while Tony got the
> > wrong result and then corrected it later.)
>
> Len's merge case come out identically to the tree he committed. I have
> described what I got for Tony's case in
> <[EMAIL PROTECTED]> (my merge algorithm
> produces the result Tony expected to get, but he didn't get that from
> git-resolve-script).
Good. It looks to me like this is a good algorithm in practice, then.
-Daniel
*This .sig left intentionally blank*
-
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
