git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andreas Ericsson <ae@op5.se>
To: Ulrich Windl <ulrich.windl@rz.uni-regensburg.de>
Cc: Andreas Ericsson <ae@op5.se>, git@vger.kernel.org
Subject: Re: On git 1.6 (novice's opinion)
Date: Wed, 01 Apr 2009 10:41:38 +0200	[thread overview]
Message-ID: <49D328C2.4000006@op5.se> (raw)
In-Reply-To: <49D33EC0.29775.7EDC13@Ulrich.Windl.rkdvmks1.ngate.uni-regensburg.de>

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

  reply	other threads:[~2009-04-01  8:43 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-27  7:21 On git 1.6 (novice's opinion) Ulrich Windl
2009-03-27  8:05 ` H.Merijn Brand
2009-03-27  9:50   ` Ulrich Windl
2009-03-27 10:57     ` Etienne Vallette d'Osia
2009-03-27 11:30       ` Etienne Vallette d'Osia
2009-03-27 12:24     ` Dmitry Potapov
2009-03-27 13:39       ` Ulrich Windl
2009-03-27 13:45         ` Matthieu Moy
2009-03-27 13:47         ` Etienne Vallette d'Osia
2009-04-01  6:50           ` Ulrich Windl
2009-04-01  7:41             ` Matthieu Moy
2009-03-28  1:30         ` Junio C Hamano
2009-03-28  1:30       ` Junio C Hamano
2009-03-28  9:53         ` Dmitry Potapov
2009-03-30  6:18     ` Russ Dill
2009-04-01  7:53       ` Ulrich Windl
2009-04-01  8:37         ` Andreas Ericsson
2009-04-01  9:47           ` Ulrich Windl
2009-04-01 10:17             ` Andreas Ericsson
2009-04-01 20:37             ` Heiko Voigt
2009-03-27 12:24 ` Dmitry Potapov
2009-03-27 13:35   ` Ulrich Windl
2009-03-27 13:44     ` Matthieu Moy
2009-04-01  6:45       ` Ulrich Windl
2009-04-01  7:42         ` Matthieu Moy
2009-03-27 12:49 ` Michael J Gruber
2009-03-27 13:48   ` Ulrich Windl
2009-03-27 14:09     ` Jakub Narebski
2009-04-01  6:59       ` Ulrich Windl
2009-04-01  7:29         ` Andreas Ericsson
2009-04-01  7:54         ` Matthieu Moy
2009-04-01  9:38           ` Ulrich Windl
2009-04-01 10:10             ` Andreas Ericsson
2009-04-02  2:17         ` Jakub Narebski
2009-03-28 10:33     ` demerphq
2009-03-28  1:30 ` Junio C Hamano
2009-04-01  7:35   ` Ulrich Windl
2009-03-29  5:41 ` Bryan Donlan
2009-03-29  9:50   ` Johannes Schindelin
2009-04-01  7:42     ` Ulrich Windl
2009-04-01  7:40   ` Ulrich Windl
2009-03-30  9:06 ` Andreas Ericsson
2009-04-01  8:15   ` Ulrich Windl
2009-04-01  8:41     ` Andreas Ericsson [this message]
2009-04-01  9:55       ` Ulrich Windl
2009-04-01 10:21         ` Andreas Ericsson
2009-04-01 11:52           ` Ulrich Windl
2009-04-01 12:40             ` Andreas Ericsson
2009-04-01  2:32 ` Kris Shannon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=49D328C2.4000006@op5.se \
    --to=ae@op5.se \
    --cc=git@vger.kernel.org \
    --cc=ulrich.windl@rz.uni-regensburg.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).