RE: (bug?) Inconsistent workdir file timestamps after initial clone.

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

 



> -----Original Message-----
> From: Torsten Bögershausen
> Sent: Wednesday, December 12, 2012 12:19 PM
> 
> 
> 
> On 11.12.12 23:30, Junio C Hamano wrote:
> > Marc Branchaud <marcnarc@xxxxxxxxxxx> writes:
> >
> >> My point is that the initial checkout into an empty working
> directory should
> >> create all files with the same timestamp.
> >>
> >> Or, to be a bit more precise, whenever git-checkout *creates* files
> in the
> >> work dir, *all* the created files should have the *same* timestamp
> (i.e. the
> >> current time measured at the start of the checkout's execution, not
> some
> >> bizarro other time specified by some arcane heuristic).
> >
> > My knee-jerk reaction is that it is insane to do so, but what other
> > SCM does such a thing? Even "tar xf" wouldn't do that, I think.
> >
> 
> 
> ClearCase is doing such a thing.
> 
> You need to check out a file to make it writable:
> "cleartool checkout main.c"
> [hack hack]
> If you after some hacking don't like your changes at all,
> you run
> "cleartool unco main.c" (Undo checkout)
> (In git we just use "git checkout")
> 
> While in ClearCase the timestamp of your file jumps back to where
> it was before the checkout, it gets the current timestamp in git.

I do think that a user preference should decide if git uses metadata timestamps or current timestamp on file operations. I don?t think that the current time is proper as a default operation.

> 
> One consequence is that ClearCase users may wish to use "ClearMake"
> rather then make.
> 
> A better make (which records all timestamps somewhere) would be
> helpful.

That is why I always do "make clean" after a rollback. Do you really expect build managers to handle a bi-directional, with regards to time, SDLC? Build managers have worked hard to ensure incremental builds, it is silly to think that they should be re worked.


> 
> >>> While not including files that can be rebuilt from the source may
> be
> >>> the ideal solution, I've seen projects hide rules to rebuild such a
> >>> "generated but needs special tools to build" and/or a "generated
> but
> >>> normal developers do not have any business rebuilding" file (in
> your
> >>> case, Makefile.in) in their Makefiles from the normal targets (like
> >>> "make all") for this exact reason, when they choose to distribute
> >>> such files by including in their commits.
> >>
> >> I prefer to use the third-party code as-is, without hacking it, to
> have
> >> smooth upgrades in the future.
> >
> > Then perhaps take the complaints to that third-party upstream, not
> > here?
> > --
> > 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
> >
> 
> --
> 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

<<attachment: smime.p7s>>


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