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