> -----Original Message-----
> From: Johannes Sixt [mailto:j.s...@viscovery.net]
> Sent: Friday, September 14, 2012 10:07 AM
> To: Michael J Gruber
> Cc: Mestnik, Michael J - Eagan, MN - Contractor; firstname.lastname@example.org
> 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
** Any and all, within reason.
> > 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
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