Junio C Hamano venit, vidit, dixit 14.09.2012 23:23: > Michael J Gruber <git@xxxxxxxxxxxxxxxxxxxx> 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 ;-). It's your favorite feature^Wcheckbox item, I know ;) I wouldn't mind dropping it or making it export-only, but the current state of that item is quite confusing. I seem to remember this has been brought up before. Junio C Hamano venit, vidit, dixit 15.09.2012 00:26: > Junio C Hamano <gitster@xxxxxxxxx> writes: > >> Michael J Gruber <git@xxxxxxxxxxxxxxxxxxxx> 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). > > > [Footnote] > > *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". > You've convinced me not to try this in-core... Maybe a post-commit hook is enough for Id. It's just that we also have no in-core way of doing a forceful enough checkout on those files. But I wouldn't mind making Id export-only (export-subst). Really, most people who look at Id really want something like VERSION_GEN (without having to use a build script/make/...). Michael -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html