Subject: Re: On git 1.6 (novice's opinion)

From: Andreas Ericsson <[email-masked]>
Date: Wed, 01 Apr 2009 10:41:38 +0200

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                   [email-masked]
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.