From: Michael J Gruber <git@drmicha•warpmail.net>
To: Junio C Hamano <gitster@pobox•com>
Cc: Marc Strapetz <marc.strapetz@syntevo•com>, git@vger•kernel.org
Subject: Re: Applying .gitattributes text/eol changes
Date: Fri, 14 Jan 2011 09:31:15 +0100 [thread overview]
Message-ID: <4D3009D3.3050403@drmicha.warpmail.net> (raw)
In-Reply-To: <7vd3o01iw9.fsf@alter.siamese.dyndns.org>
Junio C Hamano venit, vidit, dixit 14.01.2011 00:30:
> Marc Strapetz <marc.strapetz@syntevo•com> writes:
>
>> So your suggestion is to fix "git update-index --really-refresh", so
>
> The option is about telling git: "Earlier I promised I wouldn't touch
> these paths by setting their assume-unchanged bit, but I touched them.
> Please refresh the cached stat information in the index, ignoring the
> promise I didn't keep."
>
> I do not think it is a good idea to conflate your "Everything is suspect
> because smudge filter has changed; please recompute all" request into the
> same option. People who use assume-unchanged would probably want "Please
> rescan because I changed smudge filter" request to be carried out while
> still honoring the assume-unchanged bit they set earlier.
What I meant was to introduce a new option --refresh-stat or something.
We have solved the "stale stat info problem" (changed dev nums after
reboot) in a different way meanwhile, but I think there was a different
case (can't come up with the thread right now) where something like this
could have helped.
>
>> Anyway, I'm still wondering if it will resolve the "git reset --hard"
>> problem of re-checking out every file, even if content is already
>> identical in the working tree. I think that part has to be fixed, too.
>
> There is not much to fix there. If you removed the index, then there is no
> information to tell you that "content is already identical" unless you
> actually check things out and compare. By the time you found it out, you
> already have done the checkout.
>
> IOW, the current code does:
>
> open object
> read from the object
> deflate and write to the destination file
>
> while your "fix" needs to look like this:
>
> open object
> read from the object
> deflate and write to a temporary file
> open the existing file
> read from the file and compare it to the temporary we just wrote
> if same, delete, otherwise rename the temporary file.
>
> just for the rare case where there is an untracked file that the user is
> willing to overwrite (we are discussing "rm .git/index && reset --hard"
> here) happens to have the same contents. Not a good enough reason to add
> unwelcome complexity to the codepath.
>
>> What do you think about "git checkout --fix-eols" option as an
>> alternative? Its uses cases are more limited, though.
>
> What does it do? "git checkout --fix-eols $path" will overwrite $path
> with the data at $path in the index? Perhaps you can use the "-f" option.
>
> Adding an option to "checkout" might be better than update-index from the
> UI point of view, but the issue is not just "eols". "eol" is a mere
> special case of smudge filter that controls how the contents from the
> repository are modified before getting written out to the working tree.
Exactly, this is a more general issue. The typical answer to these
issues is that you change attributes and filters only occasionally, so
the cost of a rm .git/index && git reset --hard is irrelevant. But still
there should be a less scary way of (really) refreshing the index. Also
note that the cost of the command itself is only a part of the picture -
in the OP's case (which is a bit convoluted, of course) "cost" is really
command execution + the cost of the consequences (rebuilding triggered
by unnecessary touches). For the typical use cases, the existing options
and command paths do the perfectly sane and efficient thing.
Michael
next prev parent reply other threads:[~2011-01-14 8:34 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-03 17:18 Applying .gitattributes text/eol changes Marc Strapetz
2011-01-11 9:29 ` Marc Strapetz
2011-01-11 12:11 ` Michael J Gruber
2011-01-11 14:02 ` Marc Strapetz
2011-01-13 13:23 ` Michael J Gruber
2011-01-13 14:28 ` Marc Strapetz
2011-01-13 14:37 ` Michael J Gruber
2011-01-13 14:57 ` Marc Strapetz
2011-01-13 23:30 ` Junio C Hamano
2011-01-14 8:31 ` Michael J Gruber [this message]
2011-01-14 9:05 ` Marc Strapetz
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=4D3009D3.3050403@drmicha.warpmail.net \
--to=git@drmicha$(echo .)warpmail.net \
--cc=git@vger$(echo .)kernel.org \
--cc=gitster@pobox$(echo .)com \
--cc=marc.strapetz@syntevo$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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