> -----Original Message----- > From: Johannes Sixt [mailto:j.sixt@xxxxxxxxxxxxx] > Sent: Friday, September 14, 2012 10:07 AM > To: Michael J Gruber > Cc: Mestnik, Michael J - Eagan, MN - Contractor; git@xxxxxxxxxxxxxxx > Subject: Re: Using Format/export-subst Howto. > > Am 9/14/2012 15:03, schrieb Michael J Gruber: > > "git replaces $Id$... upon checkout. Any byte sequence that begins > > with $Id: and ends with $ in the worktree file is replaced with $Id$ > > upon check-in." > > > > Now, the there are two problems after you add $Id$ and check-in > > (commit): > > > > - commit does not check out, i.e. your work-tree copy is > not updated > > with expanded $Id$ - Not even "git checkout thatFile" updates your > > work-tree copy. > > > > The first one could be considered OK, but at least the second one > > seems to be a bug. Together they create the following problem: Say, > > you've corrected that problem (rm that file and checkout) and then > > update your file, add and commit. It will keeping having > the old (now > > wrong) Id expansion. > > If EOL conversion or a clean filter was applied during 'git > add file', is > the version in the worktree suddenly wrong? Of course, not. > > I would place $Id$ treatment in the same ball park and declare it as a > mistake of the editor that it did not remove the now "wrong" > SHA1 from $Id:$. I think the difference here is that git does not *currently change the OS's LEF. In this case each commit alters the Id and git is the one altering the Id. If git did change the expected/system LEF then it would seam reasonable that it would also be responsible for forward porting files to the new regime. * If git could fix some misguided operating systems into following the correct LEF, that would be great! What I mean is that I agree that git is not the tool to tackle every technical challenge, but I think it should carry though with any decisions it makes and that it should not ignore the effects(or changes) made as a result of **these decisions. ** Any and all, within reason. Cheers! > > > We should do something about this. > > Not necessary, IMHO. > > -- Hannes > 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