git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Avery Pennarun <apenwarr@gmail.com>
To: Clemens Buchacher <drizzd@aon.at>
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 12:41:22 -0400	[thread overview]
Message-ID: <z2h32541b131005040941m79724daq4cd8b0c427bb218a@mail.gmail.com> (raw)
In-Reply-To: <20100504085722.GA32217@localhost>

On Tue, May 4, 2010 at 4:57 AM, Clemens Buchacher <drizzd@aon.at> wrote:
> On Sat, May 01, 2010 at 11:27:20AM +0200, Clemens Buchacher wrote:
>
>>  --really-refresh::
>>       Like '--refresh', but checks stat information unconditionally,
>> -     without regard to the "assume unchanged" setting.
>> +     without regard to the "assume unchanged" setting. The "assume
>> +     unchanged" bit is unset for all paths.
>
> 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.

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.  (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.)

Since most of the time most of your files won't have changed,
assume-unchanged gets you the optimization without too much danger.
The cost of not assuming a changed file is unchanged is pretty low.

...now if only there was a global "just never check for changes or new
files or anything, even if I run git status" bit, someone could write
a useful git inotify daemon :)

Have fun,

Avery

  reply	other threads:[~2010-05-04 16: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 [this message]
2010-05-04 19:41       ` Clemens Buchacher
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=z2h32541b131005040941m79724daq4cd8b0c427bb218a@mail.gmail.com \
    --to=apenwarr@gmail.com \
    --cc=drizzd@aon.at \
    --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).