Re: On git 1.6 (novice's opinion)

[Andreas Ericsson <ae@op5.se>]

Ulrich Windl wrote:
> 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.
> 

But if you built the old source before you merged but after Nancy made her
changes, make wouldn't grok that the file is actually changed. Trust me,
the current semantics are far better.

>> 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 build all the time. Before and after every commit (merges are one type of
commit). I rely on file timestamps to be an accurate indicator of when the
file last changed *on my disk*.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.