From: Andreas Ericsson Date: Wed, 01 Apr 2009 08:41:38 GMT Subject: Re: On git 1.6 (novice's opinion) Message-ID: <49D328C2.4000006@op5.se> In-Reply-To: <49D33EC0.29775.7EDC13@Ulrich.Windl.rkdvmks1.ngate.uni-regensburg.de> Ulrich Windl wrote: > On 30 Mar 2009 at 11:06, Andreas Ericsson wrote: > > [...] >> 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. > > However if you put a version number into every file and THEN commit, it's somewhat > ridiculous (I'll have to learn about "git describe"). But for configuration > management you want to have exactly that (find exactly the file that was shipped > (or used to build)). > >> 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 > > So your "release commits" are outside GIT? (see above) > They aren't release commits. Just a script that creates a tarball and an RPM (in our case). >> 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. > > Hmm: Were they visible to customers? > Ofcourse they were, but they were rather useless even there, as a customer could upgrade and the $Id$ tag still wouldn't get updated. It caused a lot of confusion for our not-so-techsavvy users and customers. >> 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*. > > [Big meals need time to digest: Just give me more time to do so (getting into > git). As with vi and Emacs (usualy I prefer Emacs), there will be situations when > I won't use Git however] > Take all the time you need. It's a paradigm-shift, because the information you thought you needed is made obsolete by the information you *actually* need. Wrapping ones head around the fact that one's been wrong for several years takes a little time ;-) -- 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.