> -----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; git@vger.kernel.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 
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.mest...@usps.gov
itenterprisesystemsmonitor...@usps.gov
 --
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