Re: On git 1.6 (novice's opinion)

Ulrich Windl wrote:

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?

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

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.