Re: On git 1.6 (novice's opinion)

[Andreas Ericsson <exon@op5.com>]

Ulrich Windl wrote:
> On 1 Apr 2009 at 10:41, Andreas Ericsson wrote:
> 
>> 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).
> 
> OK, that's what I did with CVS also, but with "CVS diff" I see the revision 
> numbers (old and new) for every single file in a patch, while Git just uses "a" 
> and "b". There I'd still prefer what CVS does.
> 
>>>> 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.
> 
> What I don't understand here is: Why wouldn't the $Id$ be updated upon upgrade? 
> Because it's a manual process?
> 

It MAY not get updated, since $Id$ tags are per-file instead of per-project.
Any sane project will have more than one file, and the file listing the
$Id$ that the end-user sees may not have changed since the last release.

Per-file revision tags are stupid and useless for anything but a one-file
project.

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