Re: On git 1.6 (novice's opinion)

[Andreas Ericsson <ae@op5.se>]

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

You can set the time manually for each commit. I suppose it's not quite the
same as doing it by taking the timestamp of a single file. Personally, I've
never quite understood the point of it, since I always have to do at least
*some* testing (even if it's only a compile-test) after I'm done editing so
I know what I'm committing isn't totally broken.

Can you describe a use-case where this would be handy?

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

This has been discussed to death, and it's much, much harier than just
handling binary files. Browse the list archives for the (many, lengthy and
sometimes heated) discussions on this topic. A quick recap of the outcome
of *ALL* such discussions is as follows, though:
1 It would potentially make git horribly slow at switching branches.
2 It's rarely interesting to version a single file, but always interesting
  to version the entire project (what do I care if README was v1,1 in CVS
  when what I *really* want to know is which version of the program I should
  file my bug-report against).
3 It's far better to set the version number in the release-process. Usually
  this can be done automatically by one invocation of "git describe", just
  as git.git does it.

We've adopted "3" full out at $dayjob. Our build-machinery gets the version
number from the git tag (releases can only be built from signed tags), and
it updates macros and whatnot used for informing the user which version he
or she is running. This makes a lot more sense both from a bug-reporting
and from a release process view than having generated version-numbers in
files. On a side-note; When I told my co-workers I'd like us to switch to
git, two of them asked about autoversioning features. I said there weren't
any and asked them to name a single time when we've actually used them for
anything *at all*. In a team of eight, having been programming for three
years with 12 releases and about 800 bugreports + feature-requests, noone
could mention a single time when the autogenerated version numbers had
actually been used for anything.

Otoh, having the entire repository locally makes it painless to view the
commit-log for an entire project (or parts of it) and see who changed what
when and why, which is information that's actually *useful*.

> 3) "git undo": If possible undo the effects of the last command.
> 

Immensely complex to create, and the command would almost certainly cause
more confusion than order before it can handle every single operation that
a user would want to undo. Instead, the most common operations that require
some form of user-interaction have an "--abort" switch which does roughly
what a "git undo" command would.

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