Marc Branchaud [off-list ref] 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.
quoted
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?
On 12-12-11 05:30 PM, Junio C Hamano wrote:
Marc Branchaud [off-list ref] writes:
quoted
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?
I'm lucky enough to just care about git these days.
Even "tar xf" wouldn't do that, I think.
"tar xf" uses the timestamps that are stored in the tar file. I see this as
an argument against git's exact-current-time-per-file approach: even the tar
guys understand that it's insane.
quoted
quoted
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?
Well, I thought that while I wait for some dozen-or-so projects to accept
changes to their builds, it might be nice for git to solve this problem for
me. It is, after all, an effect of the way git operates.
M.
On 11.12.12 23:30, Junio C Hamano wrote:
Marc Branchaud [off-list ref] writes:
quoted
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.
quoted
quoted
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
-----Original Message-----
From: Torsten Bögershausen
Sent: Wednesday, December 12, 2012 12:19 PM
On 11.12.12 23:30, Junio C Hamano wrote:
quoted
Marc Branchaud [off-list ref] writes:
quoted
My point is that the initial checkout into an empty working
directory should
quoted
quoted
create all files with the same timestamp.
Or, to be a bit more precise, whenever git-checkout *creates* files
in the
quoted
quoted
work dir, *all* the created files should have the *same* timestamp
(i.e. the
quoted
quoted
current time measured at the start of the checkout's execution, not
some
quoted
quoted
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 dont 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.
quoted
quoted
quoted
While not including files that can be rebuilt from the source may
be
quoted
quoted
quoted
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
quoted
quoted
quoted
normal developers do not have any business rebuilding" file (in
your
quoted
quoted
quoted
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
quoted
quoted
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
--
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