Junio C Hamano <gits...@pobox.com> writes:

> Michael J Gruber <g...@drmicha.warpmail.net> writes:
>> you need to "rm file && git checkout file"). If the user has to update
>> $Id$ to match the current sha1
>> (by remembering to do a more forceful checkout than checkout -f) then
>> one half of that feature is useless. 
> As if there is any value in "$Id$" _feature_.  It's a checkbox item,
> nothing more ;-).

Having said that, I think you could do something along this line (I
am thinking aloud, so there may be leaps in the logic below).

 * Introduce a new on-disk flag in the index.  Call it X.  After
   entry.c:write_entry() writes it out to the working tree, this
   flag is cleared.  And this codepath is the only place that clears
   this flag.

 * When applying a clean filter (from here on, everything that
   breaks byte-for-byte identity between the copy on the working
   tree and the contents that is hashed and stored in the object
   store are considered "clean filter", including CRLF->LF and
   ident), internally apply the corresponding smudge filter to the
   cleaned result and compare it with the original input we obtained
   from the working tree.  If they differ, flip the X bit on for the
   path in the index.

 * When "checkout" and any potential callers of write_entry() decide
   whether it is worth calling write_entry() [*1*], consider any
   path with the X bit on as "dirty" and call write_entry().

You have to be very careful when designing the third point, though.
There will now be two kinds of "the working tree file is different
from the version registerd in the index" once you do the above.
Different only because of "clean->smudge" roundtrip comparison, and
different because it does have a real local modification.  The
former must be considered "no local modification" for the purpose of
merges and branch switching (otherwise you will get "cannot merge,
you have local modifications" error).


*1* This currently is done primarily with ie_match_stat(), that 
essentially is "Does the result of applying 'clean' to the working
tree contents match what is registered to the index?  Do not bother
doing this check over and over again once you checked this until
the file in the working tree is modified again".
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to