On 29 Mar 2009 at 23:18, Russ Dill wrote: > 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 If Nancy committed it with my semantics, the file's date would be 6 months old before the merge. If the merge would not require any change, the file's date would still be six months old. If a change was required, the file's date would be the time of change. That sounds quite logical to me. > 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. Git is not a build system, and I really dislike "full rebuilds", but for stability, before releasing anything, one should test it with a full rebuild. I think that's what configuration management systems are about. So for a merge or checkout of any make source object (opposed to: make target object), an automated cleanup of the corresponding target objects should be made. I know that you don't like it, but for RCS you have the couce whether to check-in with "-d", or check out with "-M". If it's optional in GIT also, you shouldn't be unhappy. > 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. I agree. Regards, Ulrich -- 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
