All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Clemens Buchacher <drizzd@aon.at>
Cc: Johannes Sixt <j6t@kdbg.org>, git@vger.kernel.org
Subject: Re: [PATCH] do not overwrite untracked symlinks
Date: Sun, 20 Feb 2011 23:15:26 -0800	[thread overview]
Message-ID: <7vaahpluy9.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <20110220121343.GA21514@localhost> (Clemens Buchacher's message of "Sun\, 20 Feb 2011 13\:13\:43 +0100")

Clemens Buchacher <drizzd@aon.at> writes:

> Git traditionally overwrites untracked symlinks silently. This will
> generally not cause massive data loss, but it is inconsistent with
> the behavior for regular files, which are not silently overwritten.
>
> With this change, git refuses to overwrite untracked symlinks by
> default. If the user really wants to overwrite the untracked
> symlink, he has git-clean and git-checkout -f at his disposal.
>
> Signed-off-by: Clemens Buchacher <drizzd@aon.at>
> ---
>
> I checked and there are no undesireable side-effects. One test had
> to be modified slightly because it does overwrite an untracked
> symlink.
>
>  symlinks.c                      |    2 +-
>  t/t6035-merge-dir-to-symlink.sh |    2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/symlinks.c b/symlinks.c
> index 3cacebd..034943b 100644
> --- a/symlinks.c
> +++ b/symlinks.c
> @@ -223,7 +223,7 @@ int check_leading_path(const char *name, int len)
>  	int flags;
>  	int match_len = lstat_cache_matchlen(cache, name, len, &flags,
>  			   FL_SYMLINK|FL_NOENT|FL_DIR, USE_ONLY_LSTAT);
> -	if (flags & (FL_SYMLINK|FL_NOENT))
> +	if (flags & FL_NOENT)
>  		return 0;
>  	else if (flags & FL_DIR)
>  		return -1;

> diff --git a/t/t6035-merge-dir-to-symlink.sh b/t/t6035-merge-dir-to-symlink.sh
> index 92e02d5..1de285b 100755
> --- a/t/t6035-merge-dir-to-symlink.sh
> +++ b/t/t6035-merge-dir-to-symlink.sh
> @@ -22,7 +22,7 @@ test_expect_success SYMLINKS 'keep a/b-2/c/d across checkout' '
>  	git reset --hard master &&
>  	git rm --cached a/b &&
>  	git commit -m "untracked symlink remains" &&
> -	 git checkout start^0 &&
> +	 git checkout -f start^0 &&
>  	 test -f a/b-2/c/d
>  '

The title of the test says that checkout must keep a/b-2/c/d; if "git
checkout" without "-f" doesn't do so and you had to change it to "git
checkout -f", it would mean one of two things: (1) you broke "checkout",
or (2) the behaviour the test wanted to keep working turned out to be
unwanted (iow, "git checkout" without "-f" should fail under the initial
condition this test sets up).

I suspect the situation is the latter.

What this test in 6035 does before your patch is:

 0. Prepare a tree with the following path (no intermediate symlinks)

	a/b/c/d
        a/b-2/c/d
        a/x

    and call that "start";

    prepare another tree with the following path

	a/b -> b-2 (symlink)
        a/b-2/c/d
        a/x

    make it a child of the "start".

 1. Detach the head at the second commit (i.e. a/b symlink pointing at
    b-2), and then remove a/b symlink from the index.  Make a commit with
    that index.

    The index at that point has:

	a/b-2/c/d
        a/x

    and in the working tree there is an untracked a/b symlink that point
    at b-2.

 2. Try to switch to "start"'s tree.  To be able to check it out, a
    directory needs to be created at a/b (as we need c/d underneath it),
    but untracked symbolic link in the working tree a/b interferes with
    it, and it _should_ fail.


So instead of testing "with -f, the untracked path is nuked" and still
calling the test to "preserve a/b-2/c/d", shouldn't you rename the test to
make sure the untracked symlink is preserved, and make sure checkout
without "-f" fails?

Of course, in addition to the above, it would be a good idea to add
another test that makes sure that with "checkout -f" the user can get rid
of the untracked symlink and check out what he wanted to check out.

Hmm?

  reply	other threads:[~2011-02-21  7:15 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-02 19:25 untracked symlinks are less precious than untracked files? Johannes Sixt
2011-02-02 20:03 ` Junio C Hamano
2011-02-02 22:24   ` Johannes Sixt
2011-02-05 18:18     ` [PATCH] Demonstrate breakage: checkout overwrites untracked symlink with directory Johannes Sixt
2011-02-05 18:33       ` Clemens Buchacher
2011-02-09 23:48         ` Junio C Hamano
2011-02-10 21:49           ` Clemens Buchacher
2011-02-20 12:13         ` [PATCH] do not overwrite untracked symlinks Clemens Buchacher
2011-02-21  7:15           ` Junio C Hamano [this message]
2011-02-21 19:46             ` Clemens Buchacher
2011-02-22  6:54               ` Junio C Hamano
2011-02-22 19:26                 ` Clemens Buchacher
2011-02-22 20:01                   ` Junio C Hamano
2011-02-15  7:24       ` [PATCH] Demonstrate breakage: checkout overwrites untracked symlink with directory Johannes Sixt

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=7vaahpluy9.fsf@alter.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=drizzd@aon.at \
    --cc=git@vger.kernel.org \
    --cc=j6t@kdbg.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.