Re: On git 1.6 (novice's opinion)

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