RE: Using Format/export-subst Howto.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> -----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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]