From: "SZEDER Gábor" <szeder.dev@gmail.com>
To: Jonathan Tan <jonathantanmy@google.com>
Cc: git@vger.kernel.org, Elijah Newren <newren@gmail.com>
Subject: Re: merge-recursive thinks symlink's child dirs are "real"
Date: Tue, 17 Sep 2019 00:15:01 +0200 [thread overview]
Message-ID: <20190916221501.GD6190@szeder.dev> (raw)
In-Reply-To: <20190916214707.190171-1-jonathantanmy@google.com>
On Mon, Sep 16, 2019 at 02:47:07PM -0700, Jonathan Tan wrote:
> This was raised by a coworker at $DAYJOB. I run the following script:
>
> $GIT init test && cd test
> ln -s . foo
> mkdir bar && touch bar/file
> $GIT add foo bar/file
> $GIT commit -m "foo symlink"
>
> $GIT checkout -b branch1
> $GIT commit --allow-empty -m "empty commit"
>
> $GIT checkout master
> $GIT rm foo
> mkdir foo
> (cd foo; ln -s ../bar bar)
> $GIT add foo/bar
> $GIT commit -m "replace foo symlink with real foo dir and foo/bar symlink"
>
> $GIT checkout branch1
> $GIT cherry-pick master
>
> The cherry-pick must be manually resolved, when I would expect it to
> happen without needing user intervention.
>
> You can see that at the point of the cherry-pick, in the working
> directory, ./foo is a symlink and ./foo/bar is a directory. I traced the
> code that ran during the cherry-pick to process_entry() in
> merge-recursive.c. When processing "foo/bar", control flow correctly
> reaches "Case B: Added in one", but the dir_in_way() invocation returns
> true, since lstat() indeed reveals that "foo/bar" is a directory. If I
> hardcode dir_in_way() to return false, then the cherry-pick happens
> without needing user intervention. I checked with "ls-tree -r" and the
> resulting tree is as I expect (foo is a real dir, foo/bar is a symlink).
>
> Is this use case something that Git should be able to handle,
FWIW, Git used to handle this case, but it broke with edd2faf52e
(merge-recursive: Consolidate process_entry() and process_df_entry(),
2011-08-11).
Cc-ing Elijah for insights...
> and if
> yes, is the correct solution to teach dir_in_way() that dirs reachable
> from symlinks are not really in the way (presumably the implementation
> would climb directories until we reach the root or we reach a filesystem
> boundary, similar to what we do when we search for the .git directory)?
> Also, my proposed solution would work in the specific use case outlined
> in the script above, but can anyone think offhand of a case that it
> would make worse?
next prev parent reply other threads:[~2019-09-16 22:15 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-16 21:47 merge-recursive thinks symlink's child dirs are "real" Jonathan Tan
2019-09-16 22:15 ` SZEDER Gábor [this message]
2019-09-17 15:54 ` Elijah Newren
2019-09-17 0:09 ` Jonathan Nieder
2019-09-17 16:02 ` Elijah Newren
2019-09-17 15:48 ` Elijah Newren
2019-09-17 21:50 ` [RFC PATCH] merge-recursive: symlink's descendants not in way Jonathan Tan
2019-09-17 22:23 ` Junio C Hamano
2019-09-17 22:32 ` Jonathan Tan
2019-09-17 22:37 ` Junio C Hamano
2019-09-17 22:49 ` Jonathan Tan
2019-09-17 23:02 ` SZEDER Gábor
2019-09-18 0:35 ` Elijah Newren
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190916221501.GD6190@szeder.dev \
--to=szeder.dev@gmail.com \
--cc=git@vger.kernel.org \
--cc=jonathantanmy@google.com \
--cc=newren@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).