Re: On git 1.6 (novice's opinion)

From: Russ Dill <russ.dill@gmail.com>
Date: Mar 30, 2009, 06:18 UTC
Message-ID: <f9d2a5e10903292318w6108bc50u2ddc830a6d9d85df@mail.gmail.com>
In-Reply-To: <49CCAF5D.21814.24B4DE63@Ulrich.Windl.rkdvmks1.ngate.uni-regensburg.de>

On Fri, Mar 27, 2009 at 2:50 AM, Ulrich Windl <ulrich.windl@rz.uni-regensburg.de> wrote:

Show 32 quoted lines

> On 27 Mar 2009 at 9:05, H.Merijn Brand wrote:
>
>> On Fri, 27 Mar 2009 08:21:36 +0100, "Ulrich Windl"
>> <ulrich.windl@rz.uni-regensburg.de> 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.