Re: Cherry-pick with symlinks fails horribly

On Friday 12 March 2010 06:49:23 Junio C Hamano wrote:

Christian Couder [off-list ref] writes:

quoted

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.  

Yes, you are right the breakage is in recursive as it works with resolve.

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.

I will send an RFC patch series to do that. I used it to check that the test 
case works with the resolve strategy.

Best regards,
Christian.