On Fri, Mar 27, 2009 at 2:50 AM, Ulrich Windl <ulrich.windl@xxxxxxxxxxxxxxxxxxxx> wrote: > On 27 Mar 2009 at 9:05, H.Merijn Brand wrote: > >> On Fri, 27 Mar 2009 08:21:36 +0100, "Ulrich Windl" >> <ulrich.windl@xxxxxxxxxxxxxxxxxxxx> wrote: >> >> > What I'd like to see in git (My apologies if some were already discussed to >> > death): >> > >> > 1) The ability to use the file's time at the time of add/commit instead of >> > the current time, and the ability tho check outfiles with the times stored >> > in the repository. >> > >> > 2) Keyword substitution. I know it's controverse (dealing with binary files), >> > but I'd like to have some automatic version numbering keyword at least: >> > Initial idea is that every commit with a change increments the number by >> > one, and when merging numbers a and b, the resulting number is max(a, b) + 1. >> >> impossible. Even with checkin- and checkout hooks, you won't get that >> SCCS behaviour. They have to be better in something too :) >> /me still misses that but got used to it > > Hi, > > what made me wonder is this (about item 1): I thought I've read that blobs store > content and attributes, so very obviously I wondered why not store thr "right > attributes" (i.e. the time of the file). My reasoning: You make some changes, then > test them (which might last several hours or days). The if I'm happy I'll > "commit". Naturally I want to see the time of change for each file when the change > had been actually made, not when the change was committed. Likewise when checking > out, I want to be able to see the time of modification, not the time of commit. > I'm aware that many people don't care about such differences... > Ok, so if Nancy did some work on the part number form 6 months ago, but it got merged into master yesterday. What date should the file have? This kind of incremental version number, and trusting of file dates really only matters on a centralized system with a single branch. Not only that, but modification times are much more useful with make. Merging or pulling small changes into a tree shouldn't require a full rebuild of the entire tree which in some cases could take hours. Especially since 'git log <file>', 'gitk <file>', or 'git blame <file>' give much more information anyway. I know some people sort their directory by date to see what kind of stuff happened since they last worked on the repository, but it doesn't scale to a project with many directories and the log is much more useful anyway. -- 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
