Re: Schrödinger's diff

Jeff King [off-list ref] writes:

.... But even that might have holes,
I'm afraid -- we don't always look at all of the config in every
command, though perhaps we do for such core functionality.

I personally do not think it is worth it.  If you change the crlf,
clean/smudge, or anything of that sort, just doing a "rm .git/index"
followed by "git reset --hard" would restore sanity to your work tree, no?

On Tue, Jul 07, 2009 at 12:48:45PM -0700, Junio C Hamano wrote:

Jeff King [off-list ref] writes:

quoted

.... But even that might have holes,
I'm afraid -- we don't always look at all of the config in every
command, though perhaps we do for such core functionality.

I personally do not think it is worth it.  If you change the crlf,
clean/smudge, or anything of that sort, just doing a "rm .git/index"
followed by "git reset --hard" would restore sanity to your work tree, no?

Yes, that works fine, but:

  1. It blows away anything unrelated you might have staged.

  2. You have to know to do it (and you get very confusing results if
     you don't), which makes it very unfriendly for newbies.

  3. You have to know to do it, and it isn't documented. :)

(3) at least is not too hard to address. And perhaps (2) is not a big
enough issue to care about. This is not a problem we have seen on the
list a lot. I suspect it is because most CRLF users are on Windows, and
therefore have it setup before the tree is checked out, and there are
simply not all that many clean/smudge users.

-Peff

On Tue, Jul 7, 2009 at 12:48 PM, Junio C Hamano[off-list ref] wrote:

Jeff King [off-list ref] writes:

quoted

.... But even that might have holes,
I'm afraid -- we don't always look at all of the config in every
command, though perhaps we do for such core functionality.

I personally do not think it is worth it.  If you change the crlf,
clean/smudge, or anything of that sort, just doing a "rm .git/index"
followed by "git reset --hard" would restore sanity to your work tree, no?

Is there any technical reason why "git reset --hard" shouldn't repopulate
the index by doing a "git read-tree" or equivalent [1]?  After all the
docs claim it
"Matches the working tree and index to that of the tree being switched to".

Except in this case it doesn't.  The resulting .index is an invalid
representation
of the tree.  Sanity can be restored with "git read-tree HEAD" (as
Jeff suggested),
but that's hardly intuitive.

- Eric

[1] For instance anything at all (possibly involving time stamps) such that
the index will truly match the tree.

On Tue, Jul 07, 2009 at 01:30:47PM -0700, Eric Raible wrote:

quoted

I personally do not think it is worth it.  If you change the crlf,
clean/smudge, or anything of that sort, just doing a "rm .git/index"
followed by "git reset --hard" would restore sanity to your work tree, no?

Is there any technical reason why "git reset --hard" shouldn't repopulate
the index by doing a "git read-tree" or equivalent [1]?  After all the
docs claim it
"Matches the working tree and index to that of the tree being switched to".

Yes; relying on the stat cache is what makes "git reset --hard" really
fast, instead of having to re-hash each file. The real problem is that
we are invalidating the contents of that cache, but not marking the
entry as dirty.

Right now we don't mark the entries, and you get stale data until you
manually mark them as dirty. But marking them dirty on every reset will
mean that reset can't make use of the cache, which is slow. So ideally
we would have a way of marking them dirty only when necessary. One way
would be a "git reset --hard --reset-me-harder", but that obviously
still involves manual work; you're just making the command a little
easier to find and use.

As I suggested before, you could include the changed bits (i.e., the
attributes and config) as part of the cache validity information.  But I
suspect it would be hard to implement, as it involves new fields in the
index. It also involves arbitrary user commands, so getting it 100%
right would be impossible (e.g., we can record the string
"my-clean-filter" as the filter name, but we can't know when that
filter's behavior has changed); however, in practice, I think we can
assume that a string containing a text command will have stable output.

-Peff