> -----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 <marcn...@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.
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. > > >>> 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 majord...@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 majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
smime.p7s
Description: S/MIME cryptographic signature
