From: Clemens Buchacher <drizzd@aon.at>
To: Avery Pennarun <apenwarr@gmail.com>
Cc: git@vger.kernel.org, Junio C Hamano <gitster@pobox.com>
Subject: Re: update-index --really-refresh unsets assume-unchanged bit
Date: Tue, 4 May 2010 21:41:36 +0200 [thread overview]
Message-ID: <20100504194136.GA19300@localhost> (raw)
In-Reply-To: <z2h32541b131005040941m79724daq4cd8b0c427bb218a@mail.gmail.com>
On Tue, May 04, 2010 at 12:41:22PM -0400, Avery Pennarun wrote:
> On Tue, May 4, 2010 at 4:57 AM, Clemens Buchacher <drizzd@aon.at> wrote:
>
> > Scratch that latter part, please. I just noticed the bit is unset only for
> > modified files. If the file matches the index, or even if it has been
> > deleted in the work tree, the bit is _not_ unset.
> >
> > So the current behavior is quite strange. I see several possible
> > interpretations of --really-refresh:
>
> I don't know, the current behaviour sounds consistent with the name:
> "assume unchanged."
>
> If the index says the file is unmodified, then assume it's unchanged;
> don't check for changes.
This is not about changes with respect to HEAD. The "assume unchanged" flag
is unset if the work tree differs from the index. Whether or not the file
is modified in the index is irrelevant.
> If the index says the file is modified, then clearly it's changed; it
> would be pointless to assume otherwise, so the "assume unchanged" bit
> should probably not be set.
On the contrary. I _want_ git to assume the file is unchanged, even though I
know it changed. This is an intended and documented use case (from the
git-update-index manpage):
This option can be also used as a coarse file-level mechanism
to ignore uncommitted changes in tracked files (akin to what
`.gitignore` does for untracked files).
But even if you look at it from the performance optimization perspective,
the behavior is still inconsistent, because it does not unset the bit for
deleted files.
Furthermore, after update-index --really-refresh --add, the file is in fact
unchanged again and it would make much more sense to keep the
assume-unchanged flag.
> (Plus it's quite possibly dangerous to
> assume the file permissions are the same as they were when you first
> noticed they were changed; imagine if the file has changed twice and
> now has a different length or mode.)
What do you mean, "dangerous"? I tell git to update the index, and then
continue to ignore changes to the work tree, until I explicitly update
again. I can already achieve this behavior using
git ls-files -v | grep ^h | cut -f2 -d' ' >my-ignored-files
git update-index --really-refresh
cat my-ignored-files | xargs git update-index --assume-unchanged
Clemens
next prev parent reply other threads:[~2010-05-04 19:41 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-01 9:25 [PATCH 1/2] do not overwrite files marked "assume unchanged" Clemens Buchacher
2010-05-01 9:27 ` [PATCH 2/2] Documentation: git-add does not update " Clemens Buchacher
2010-05-04 8:57 ` update-index --really-refresh unsets assume-unchanged bit Clemens Buchacher
2010-05-04 16:41 ` Avery Pennarun
2010-05-04 19:41 ` Clemens Buchacher [this message]
2010-05-04 22:45 ` Junio C Hamano
2010-05-05 15:44 ` Clemens Buchacher
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=20100504194136.GA19300@localhost \
--to=drizzd@aon.at \
--cc=apenwarr@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.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).