Re: [RFC PATCH] merge-recursive: symlink's descendants not in way

2019-09-17 Thread Elijah Newren
Hi Jonathan, On Tue, Sep 17, 2019 at 2:50 PM Jonathan Tan wrote: > > When the working tree has: > - foo (symlink) > - foo/bar (directory) > > and the user merges a commit that deletes the foo symlink and instead > contains: > - foo (directory) > - foo/bar (file) > > the merge should happen wi

Re: [RFC PATCH] merge-recursive: symlink's descendants not in way

2019-09-17 Thread SZEDER Gábor
On Tue, Sep 17, 2019 at 02:50:40PM -0700, Jonathan Tan wrote: > diff --git a/t/t3030-merge-recursive.sh b/t/t3030-merge-recursive.sh > index ff641b348a..dfd617a845 100755 > --- a/t/t3030-merge-recursive.sh > +++ b/t/t3030-merge-recursive.sh > @@ -452,6 +452,33 @@ test_expect_success 'merge-recursiv

Re: [RFC PATCH] merge-recursive: symlink's descendants not in way

2019-09-17 Thread Jonathan Tan
> Yeah, I recall having to add has_symlink_leading_path() long time > ago in different codepaths (including "apply"). It is not surprising > to see a similar glitch remaining in merge-recursive (it's a tricky > issue, and it's a tricky code). Thanks for the pointer to has_symlink_leading_path() -

Re: [RFC PATCH] merge-recursive: symlink's descendants not in way

2019-09-17 Thread Junio C Hamano
Jonathan Tan writes: >> In any case, if the working tree has 'foo' as a symlink, Git should >> not look at or get affected by what 'foo' points at. > > Git should not, but it does - there is a call in process_entry() that calls > lstat() on "foo/bar", which indeed reports that "foo/bar" is a dire

Re: [RFC PATCH] merge-recursive: symlink's descendants not in way

2019-09-17 Thread Jonathan Tan
> Jonathan Tan writes: > > > When the working tree has: > > - foo (symlink) > > - foo/bar (directory) > > Whoa, wait. I assume, since this is about merge, the assumption is > that the working tree is clean with respect to the index, so 'foo' > is a symbolic link that is in the index. Now, if

Re: [RFC PATCH] merge-recursive: symlink's descendants not in way

2019-09-17 Thread Junio C Hamano
Jonathan Tan writes: > When the working tree has: > - foo (symlink) > - foo/bar (directory) Whoa, wait. I assume, since this is about merge, the assumption is that the working tree is clean with respect to the index, so 'foo' is a symbolic link that is in the index. Now, if foo is a symlink,

[RFC PATCH] merge-recursive: symlink's descendants not in way

2019-09-17 Thread Jonathan Tan
When the working tree has: - foo (symlink) - foo/bar (directory) and the user merges a commit that deletes the foo symlink and instead contains: - foo (directory) - foo/bar (file) the merge should happen without requiring user intervention. However, this does not happen. In merge_trees(), pr