* git an patches: Some questions
@ 2009-10-02 20:21 Christian Gagneraud
2009-10-03 19:19 ` Christian Gagneraud
2009-10-05 9:37 ` Catalin Marinas
0 siblings, 2 replies; 3+ messages in thread
From: Christian Gagneraud @ 2009-10-02 20:21 UTC (permalink / raw)
To: linux-arm-kernel
Hi all,
I would like to have some advice on how to manage my git tree, patches
that I pick on this list (EP93XX related) and patches that I would
like to submit (TS-72XX related).
First of all I would like to know what tools people are using, I've
read about stg [1][2] and it looks to me that it fits well my needs.
Next, I'm would like to know the best strategy to track the latest
patches from linux-arm and at the same time work on my own patches.
Should I create a branch, say ep93xx, that track linux tree and on
which i apply the EP93xx patches, and set up another branch, say
ts72xx, that track the ep93xx branch? Or should i use only one branch
and use "stg import" for patches I'm not the author and "stg new" for
my own work.
Using stg import/new looks interesting, but then if I want to submit
my patches by email, stg will send all the patch part of the series
including the one that I've imported but that's not what I'm looking for.
Any help, advice or point-out appreciated.
Thanks,
Chris
[1] http://wiki.openmoko.org/wiki/Hints_on_using_GIT_and_stgit
[2] http://www.procode.org/stgit/doc/tutorial.html
^ permalink raw reply [flat|nested] 3+ messages in thread
* git an patches: Some questions
2009-10-02 20:21 git an patches: Some questions Christian Gagneraud
@ 2009-10-03 19:19 ` Christian Gagneraud
2009-10-05 9:37 ` Catalin Marinas
1 sibling, 0 replies; 3+ messages in thread
From: Christian Gagneraud @ 2009-10-03 19:19 UTC (permalink / raw)
To: linux-arm-kernel
Christian Gagneraud wrote:
> Hi all,
>
> I would like to have some advice on how to manage my git tree, patches
> that I pick on this list (EP93XX related) and patches that I would like
> to submit (TS-72XX related).
>
> First of all I would like to know what tools people are using, I've read
> about stg [1][2] and it looks to me that it fits well my needs.
>
> Next, I'm would like to know the best strategy to track the latest
> patches from linux-arm and at the same time work on my own patches.
> Should I create a branch, say ep93xx, that track linux tree and on which
> i apply the EP93xx patches, and set up another branch, say ts72xx, that
> track the ep93xx branch? Or should i use only one branch and use "stg
> import" for patches I'm not the author and "stg new" for my own work.
>
> Using stg import/new looks interesting, but then if I want to submit my
> patches by email, stg will send all the patch part of the series
> including the one that I've imported but that's not what I'm looking for.
>
> Any help, advice or point-out appreciated.
Actually stg is really a great tool, very easy to use!
Their tutorial was of a great help to get up to speed quickly.
Chris
> Thanks,
> Chris
>
> [1] http://wiki.openmoko.org/wiki/Hints_on_using_GIT_and_stgit
> [2] http://www.procode.org/stgit/doc/tutorial.html
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 3+ messages in thread
* git an patches: Some questions
2009-10-02 20:21 git an patches: Some questions Christian Gagneraud
2009-10-03 19:19 ` Christian Gagneraud
@ 2009-10-05 9:37 ` Catalin Marinas
1 sibling, 0 replies; 3+ messages in thread
From: Catalin Marinas @ 2009-10-05 9:37 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, 2009-10-02 at 21:21 +0100, Christian Gagneraud wrote:
> I would like to have some advice on how to manage my git tree, patches
> that I pick on this list (EP93XX related) and patches that I would
> like to submit (TS-72XX related).
>
> First of all I would like to know what tools people are using, I've
> read about stg [1][2] and it looks to me that it fits well my needs.
Apart from stgit you can use plain git (maybe in combination with
cherry-picking and amending the top commit), guilt or topgit (see
http://git-scm.com/tools).
> Next, I'm would like to know the best strategy to track the latest
> patches from linux-arm and at the same time work on my own patches.
> Should I create a branch, say ep93xx, that track linux tree and on
> which i apply the EP93xx patches, and set up another branch, say
> ts72xx, that track the ep93xx branch? Or should i use only one branch
> and use "stg import" for patches I'm not the author and "stg new" for
> my own work.
I think the best workflow comes with individual's experience. I'm can't
say if my workflow would work for you.
I would say your patches should be based against Linus' tree, especially
if you send a git pull request to Russell. I usually only rebase the
patches on top of Russell's arm devel tree if asked explicitly (i.e.
merge conflict is not trivial).
It also depends on the number of patches you have and whether you want
to keep separate branches. If you don't have a huge number of patches,
just use a single branch which you can rebase on whatever you want to
test (Linus' tree or Russell's tree).
Another strategy is to keep your patches on top of Linus' tree and use a
separate (temporary maybe) branch to merge Russell's tree with your
stgit-managed branch for testing. You can also enabled git-rerere in
your .git/config to avoid solving the same conflict next time you want
to test.
If you want to make your stgit branch public, the rebasing workflow may
cause conflicts for people periodically pulling your tree. To avoid
this, stgit (latest versions) has a command called "publish" which
creates and maintains a branch with linear history but with the same
tree as your stgit branch.
>
> Using stg import/new looks interesting, but then if I want to submit
> my patches by email, stg will send all the patch part of the series
> including the one that I've imported but that's not what I'm looking
> for.
You can submit only the patches you want - "stg mail patch1..patchN".
But to reduce problems with merging or patches depending on others which
are not submitted, I would recommend to create a separate branch (e.g.
"for-rmk") based on latest mainline and only pick import the patches
meant for upstream from your other branches. Something like:
stg branch -c for-rmk origin/master
stg pick devel:patch1
stg pick -B devel patch2..patchN
... test ...
stg mail --to=linux-arm-kernel -a
(you can put e-mail aliases in the .git/config or ~/.gitconfig files,
see the example giconfig that comes with stgit)
For submitting patches, you can either publish your git tree and send a
pull request for your "for-rmk" branch or just send the patches to
Russell's patch system.
You can also automate the sending to the patch system with stgit but
make sure that you either use long delays between each patch (mail
--sleep or send them one by one waiting for the patch system reply) or
add some numbering to each patch so that Russell know the order. The stg
mail command allows custom templates, so for the patch system I use:
From: %(sender)s
To: patches at arm.linux.org.uk
Subject: %(prefix)s%(shortdescr)s
%(longdescr)s
PATCH FOLLOWS
KernelVersion:%(version)s
%(diff)s
and the stgit command:
stg mail -t .git/patchmail.tmpl -v 2.6.32-rc1 <patch>
(the -v/--version option is important otherwise the patch system rejects
your patch)
I also thought about using a subject line like below to add a counter to
each patch but I haven't sent any patches like this yet (pull requests
are easier):
Subject: (patch%(number)s) %(prefix)s%(shortdescr)s
--
Catalin
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2009-10-05 9:37 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-10-02 20:21 git an patches: Some questions Christian Gagneraud
2009-10-03 19:19 ` Christian Gagneraud
2009-10-05 9:37 ` Catalin Marinas
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).