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@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.
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@xxxxxx
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.
--
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
