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

["Torsten Bögershausen" <tboegi@web.de>]

 
On 11.12.12 23:30, Junio C Hamano wrote:
> Marc Branchaud <marcnarc@xiplink.com> 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.

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.

>>> 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@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>