git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Derrick Stolee <derrickstolee@github.com>
To: Victoria Dye via GitGitGadget <gitgitgadget@gmail.com>,
	git@vger.kernel.org
Cc: reichemn@icloud.com, gitster@pobox.com, Victoria Dye <vdye@github.com>
Subject: Re: [PATCH v2] mv: refresh stat info for moved entry
Date: Tue, 29 Mar 2022 09:19:29 -0400	[thread overview]
Message-ID: <5ca04e86-6c61-3d4e-88a0-a3c827e19e13@github.com> (raw)
In-Reply-To: <pull.1187.v2.git.1648516027925.gitgitgadget@gmail.com>

On 3/28/2022 9:07 PM, Victoria Dye via GitGitGadget wrote:
> From: Victoria Dye <vdye@github.com>
> 
> Update the stat info of the moved index entry in 'rename_index_entry_at()'
> if the entry is up-to-date with the index. Internally, 'git mv' uses
> 'rename_index_entry_at()' to move the source index entry to the destination.
> However, it directly copies the stat info of the original cache entry, which
> will not reflect the 'ctime' of the file renaming operation that happened as
> part of the move. If a file is otherwise up-to-date with the index, that
> difference in 'ctime' will make the entry appear out-of-date until the next
> index-refreshing operation (e.g., 'git status').
> 
> Some commands, such as 'git reset', use the cached stat information to
> determine whether a file is up-to-date; if this information is incorrect,
> the command will fail when it should pass. In order to ensure a moved entry
> is evaluated as 'up-to-date' when appropriate, refresh the destination index
> entry's stat info in 'git mv' if and only if the file is up-to-date.
> 
> Note that the test added in 't7001-mv.sh' requires a "sleep 1" to ensure the
> 'ctime' of the file creation will be definitively older than the 'ctime' of
> the renamed file in 'git mv'.

Unfortunate that this is necessary, but it seems to be the only way
to handle this because of the interaction with the system clock and
the filesystem. There are several sleeps like this in
t1701-racy-split-index.sh, for example.

>  void rename_index_entry_at(struct index_state *istate, int nr, const char *new_name)
>  {
> -	struct cache_entry *old_entry = istate->cache[nr], *new_entry;
> +	struct cache_entry *old_entry = istate->cache[nr], *new_entry, *refreshed;
>  	int namelen = strlen(new_name);
>  
>  	new_entry = make_empty_cache_entry(istate, namelen);
> @@ -147,7 +147,20 @@ void rename_index_entry_at(struct index_state *istate, int nr, const char *new_n
>  	cache_tree_invalidate_path(istate, old_entry->name);
>  	untracked_cache_remove_from_index(istate, old_entry->name);
>  	remove_index_entry_at(istate, nr);
> -	add_index_entry(istate, new_entry, ADD_CACHE_OK_TO_ADD|ADD_CACHE_OK_TO_REPLACE);
> +
> +	/*
> +	 * Refresh the new index entry. Using 'refresh_cache_entry' ensures
> +	 * we only update stat info if the entry is otherwise up-to-date (i.e.,
> +	 * the contents/mode haven't changed). This ensures that we reflect the
> +	 * 'ctime' of the rename in the index without (incorrectly) updating
> +	 * the cached stat info to reflect unstaged changes on disk.
> +	 */
> +	refreshed = refresh_cache_entry(istate, new_entry, CE_MATCH_REFRESH);
> +	if (refreshed && refreshed != new_entry) {
> +		add_index_entry(istate, refreshed, ADD_CACHE_OK_TO_ADD|ADD_CACHE_OK_TO_REPLACE);
> +		discard_cache_entry(new_entry);

I'm glad you're checking that both refreshed is non-NULL and not equal
to new_entry. Both are possible results from refresh_cache_entry().

> +test_expect_success 'mv -f refreshes updated index entry' '
> +	echo test >bar &&
> +	git add bar &&
> +	git commit -m test &&
> +
> +	echo foo >foo &&
> +	git add foo &&
> +
> +	# Wait one second to ensure ctime of rename will differ from original
> +	# file creation ctime.
> +	sleep 1 &&
> +	git mv -f foo bar &&
> +	git reset --merge HEAD &&
> +
> +	# Verify the index has been reset
> +	git diff-files >out &&
> +	test_must_be_empty out
> +'
> +

New test looks good.

Thanks,
-Stolee

  reply	other threads:[~2022-03-29 13:19 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-25  1:56 [PATCH] mv: refresh stat info for moved entry Victoria Dye via GitGitGadget
2022-03-25 14:31 ` Derrick Stolee
2022-03-25 22:37   ` Victoria Dye
2022-03-25 23:29 ` Junio C Hamano
2022-03-26  1:23   ` Victoria Dye
2022-03-29  1:07 ` [PATCH v2] " Victoria Dye via GitGitGadget
2022-03-29 13:19   ` Derrick Stolee [this message]
2022-03-29 16:44     ` Junio C Hamano
2022-03-29 18:54       ` Derrick Stolee
2022-03-29 19:05         ` Junio C Hamano

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=5ca04e86-6c61-3d4e-88a0-a3c827e19e13@github.com \
    --to=derrickstolee@github.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=gitster@pobox.com \
    --cc=reichemn@icloud.com \
    --cc=vdye@github.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).