From: Linus Torvalds <torvalds@linux-foundation.org>
To: Chris Friesen <cfriesen@nortel.com>
Cc: Brandon Casey <casey@nrlssc.navy.mil>, git@vger.kernel.org
Subject: Re: any way to apply tag across all branches in repository?
Date: Tue, 19 May 2009 13:14:22 -0700 (PDT) [thread overview]
Message-ID: <alpine.LFD.2.01.0905191307320.3301@localhost.localdomain> (raw)
In-Reply-To: <4A13030D.8000000@nortel.com>
On Tue, 19 May 2009, Chris Friesen wrote:
>
> This is all in the same local repository, but with target-specific branches
> containing arch-specific changes on top of a common codebase. The
> arch-specific stuff often comes from board vendors and such, and they're
> never going to be merged back into the common codebase.
>
> I'm looking for some way to conceptually tag the current head of each
> branch to indicate "this commit was used to build product version FOO" so
> that later on when we find a bug in our code we can tell which product
> version(s) contain the bug and need to be patched in the field.
Oh. Yes, in that case, you do need to just tag each head.
> The brute-force way to do this would be to manually loop through each branch
> and create a tag of the form "$branch_$version" to ensure unique tags. But I was
> hoping there was a more elegant way.
Well, I would suggest that you do it fundamentally differently.
Instead of tagging each build, I would suggest just associating each build
with the commit SHA1 of the time. That's what Linux does (if you enable
CONFIG_LOCALVERSION_AUTO), and it's _way_ superior to lots of crazy tags.
So for example, I can do
[torvalds@nehalem ~]$ uname -r
2.6.30-rc6-00302-g72357d5-dirty
and it tells me exactly what kernel version I'm running (well, the "dirty"
part means that it's not exact and has some additional patches that
weren't committed, but that's as close as you can get). It's very useful.
Now, with some other build, you might want to just encode the SHA1
revision in your binary. For example, a simple build-time rule like a
Makefile addition that does something like
version.c:
echo 'const char git_build_version = "'$(git describe)'";" > version.c
and then you just force version.o to be linked into your build.
Trust me, something like the above is _much_ better than tagging each
branchthat you build. Partly because it means that you can do the builds
in a distributed manner, and they'll all get the version built in, rather
than having to rely on everybody tagging everything and then trying to
match up the tag to some random binary.
Linus
next prev parent reply other threads:[~2009-05-19 20:14 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-19 16:26 any way to apply tag across all branches in repository? Chris Friesen
2009-05-19 16:52 ` Tomas Carnecky
2009-05-19 16:59 ` Chris Friesen
2009-05-19 17:05 ` Brandon Casey
2009-05-19 17:48 ` Chris Friesen
2009-05-19 18:33 ` Linus Torvalds
2009-05-19 19:05 ` Chris Friesen
2009-05-19 20:14 ` Linus Torvalds [this message]
2009-05-19 20:56 ` Chris Friesen
2009-05-19 21:06 ` Linus Torvalds
2009-05-19 21:31 ` Chris Friesen
2009-05-19 18:36 ` Brandon Casey
2009-05-19 19:05 ` Chris Friesen
2009-05-19 19:30 ` Brandon Casey
2009-05-19 19:49 ` Chris Friesen
2009-05-19 19:58 ` Brandon Casey
-- strict thread matches above, loose matches on Subject: below --
2009-05-20 8:58 Mark Struberg
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=alpine.LFD.2.01.0905191307320.3301@localhost.localdomain \
--to=torvalds@linux-foundation.org \
--cc=casey@nrlssc.navy.mil \
--cc=cfriesen@nortel.com \
--cc=git@vger.kernel.org \
/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