From: "Andreas Herrmann" <andreas.herrmann3@amd.com>
To: "Guennadi Liakhovetski" <g.liakhovetski@gmx.de>
Cc: "J. Bruce Fields" <bfields@fieldses.org>,
"Junio C Hamano" <junkio@cox.net>,
git@vger.kernel.org
Subject: Re: basics... when reading docs doesn't help
Date: Fri, 30 Mar 2007 20:02:11 +0200 [thread overview]
Message-ID: <20070330180211.GI16087@alberich.amd.com> (raw)
In-Reply-To: <Pine.LNX.4.60.0703292354100.10351@poirot.grange>
On Fri, Mar 30, 2007 at 12:13:02AM +0200, Guennadi Liakhovetski wrote:
> On Thu, 29 Mar 2007, J. Bruce Fields wrote:
>
> > On Thu, Mar 29, 2007 at 02:26:10PM -0700, Junio C Hamano wrote:
> > >
> > > How about suggesting "clone -l -s"?
>
> Yes, but how do "advanced git users" kernel developers work? Do they just
> do 1 clone and build / clean every time they want to test another
> configuration / arch, or do they clone -l or what? Do they create branches
> for each development thread, then pull / push between trees?...
>
> > If you really want to share as much as possible, then I guess you want
> > to share the working trees too, since (as evidenced above), they're at
> > least as large as the compressed history.
>
> But I don't want to re-build. Apart from i386 I build for a couple of ARM
> and PPC targets too...
Seems to be trivial but:
Why don't you use "make O=/foo/bar/arch<x>-config<y>" to put output
files into separate directories? So you can have one source tree and
put each different kernel config and arch into a separate output
directory.
And if you have different sources for you trees put them into branches.
When switching between branches, atime of files are updated accordingly.
So even make should be happy with that.
Just one drawback:
Switching back and forth between two branches will cause
recompilation of sources that differ between that branches -
although nothing might have changed within a branch in the meantime.
(Not that I have used such an setup, yet.
But I think that should work.)
Regards,
Andreas
next prev parent reply other threads:[~2007-03-30 18:02 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-29 20:50 basics... when reading docs doesn't help Guennadi Liakhovetski
2007-03-29 21:16 ` J. Bruce Fields
2007-03-29 21:26 ` Junio C Hamano
2007-03-29 21:46 ` J. Bruce Fields
2007-03-29 22:13 ` Guennadi Liakhovetski
2007-03-29 22:35 ` Linus Torvalds
2007-03-30 18:16 ` Guennadi Liakhovetski
2007-03-30 18:48 ` Linus Torvalds
2007-03-30 19:49 ` Guennadi Liakhovetski
2007-03-30 20:06 ` Linus Torvalds
2007-03-30 20:23 ` Theodore Tso
2007-03-30 20:39 ` Junio C Hamano
2007-03-30 21:11 ` Guennadi Liakhovetski
2007-03-30 2:43 ` Theodore Tso
2007-03-30 14:49 ` J. Bruce Fields
2007-03-30 18:02 ` Andreas Herrmann [this message]
2007-03-30 18:24 ` Guennadi Liakhovetski
2007-03-29 22:27 ` Matthieu Moy
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=20070330180211.GI16087@alberich.amd.com \
--to=andreas.herrmann3@amd.com \
--cc=bfields@fieldses.org \
--cc=g.liakhovetski@gmx.de \
--cc=git@vger.kernel.org \
--cc=junkio@cox.net \
/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).