Re: On git 1.6 (novice's opinion)

> On 29 Mar 2009 at 23:18, Russ Dill wrote:
> 
>> On Fri, Mar 27, 2009 at 2:50 AM, Ulrich Windl
>> <ulrich.windl@rz.uni-regensburg.de> 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@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
> 
> 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.