Re: On git 1.6 (novice's opinion)

From: Andreas Ericsson <ae@op5.se>
Date: Apr 1, 2009, 08:41 UTC
Message-ID: <49D328C2.4000006@op5.se>
In-Reply-To: <49D33EC0.29775.7EDC13@Ulrich.Windl.rkdvmks1.ngate.uni-regensburg.de>

Ulrich Windl wrote:

Show 20 quoted lines

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

Show 10 quoted lines

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

Show 8 quoted lines

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