Re: Cherry-pick with symlinks fails horribly

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 12, 2010, 05:49 UTC
Message-ID: <7vljdyt7h8.fsf@alter.siamese.dyndns.org>
In-Reply-To: <201003120448.22821.chriscool@tuxfamily.org>

Christian Couder <chriscool@tuxfamily.org> writes:

Show 15 quoted lines

> Anyway when looking at t/t6035-merge-dir-to-symlink.sh, we can see that
> there are still 2 broken tests:
>
> $ ./t6035-merge-dir-to-symlink.sh
> ...
> *   ok 5: do not lose a/b-2/c/d in merge (resolve)
> *   still broken 6: do not lose a/b-2/c/d in merge (recursive)
> *   ok 7: setup a merge where dir a/b-2 changed to symlink
> *   ok 8: merge should not have conflicts (resolve)
> *   still broken 9: merge should not have conflicts (recursive)
> * still have 2 known breakage(s)
> * passed all remaining 7 test(s)
>
> So it looks like breakages in this area are known, though perhaps not your 
> particular breakage.

The above shows that resolve passes the same tests that recursive fails, which means that the breakage is likely to be in recursive, and not in unpack-trees, as you seemt to have guessed earlier. If cherry-pick were still a shell script, we could easily test that conjecture by letting you try running it using resolve instead of recursive, but things like that has got a lot harder to do these days since many things were rewritten in C (sigh).

It might not be a bad idea to teach a hidden primarily-for-debugging option to "cherry-pick" to let it use resolve instead of recursive for cases like this.