Re: On git 1.6 (novice's opinion)

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