RE: Using Format/export-subst Howto.
Show 34 quoted lines
> -----Original Message-----
> From: Johannes Sixt [mailto:j.sixt@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!
Show 7 quoted lines
>
> > 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@usps.gov
ITEnterpriseSystemsMonitoring@usps.gov