> -----Original Message----- > From: Michael J Gruber [mailto:git@xxxxxxxxxxxxxxxxxxxx] > Sent: Monday, September 17, 2012 8:17 AM > To: Junio C Hamano > Cc: Johannes Sixt; Mestnik, Michael J - Eagan, MN - > Contractor; git@xxxxxxxxxxxxxxx > Subject: Re: Using Format/export-subst Howto. > > 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 I'm just reporting that I didn't think Id was behaving as it should in my working folder, this is of no consequence for me. After git pull, AFAIK, the Id has the correct/new value if the file has changed. > (without having to > use a build script/make/...). > > Michael > I would not be opposed to going the build script/make route, if I could do it in a hook. I'm using git to produce the final product in my case, I don't want this live folder to be used as a temporary place for doing builds. I guess I'm looking for behavior similar to install. Cheers. Mike Mestnik, Michael J The ESM Tools Enterprise Systems Monitoring United States Postal Service O: (651) 406-2048 Michael.J.Mestnik@xxxxxxxx ITEnterpriseSystemsMonitoring@xxxxxxxx -- 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