* Re: What to do with patches that should go upstream?
2010-01-13 9:51 What to do with patches that should go upstream? Jeenu V
@ 2010-01-13 10:13 ` Junio C Hamano
2010-01-13 10:34 ` Jeenu V
0 siblings, 1 reply; 3+ messages in thread
From: Junio C Hamano @ 2010-01-13 10:13 UTC (permalink / raw)
To: Jeenu V; +Cc: git
Jeenu V <jeenuv@gmail.com> writes:
> For example, in the following figure,
>
> A
> -O---O-+
> \ A' B'
> -O---O---O---O---O---O---O W
> /
> -O----O--+
>
> W is the current working branch. But there are commits A' and B' which
> should go upstream. What I wanted to know is the next step from here.
>
> 1) Do I switch to A and B, and then cherry pick the commits A' and B'?
> 2) If I send the patch out to include in upstream, wouldn't it
> conflict the next time I happen to merge from A or B?
I don't see B in your picture, so I may not be answering the question you
wanted to ask, or you perhaps asked something other than the question you
wanted to ask. Having said that, I think you are asking two more-or-less
independent questions.
Whether you interact with your upstream by sending patches, asking them to
pull, or directly pushing into them, from your problem description, it is
clear that you _only_ want to give change contained in A' and B'. So
there is no room for "how do I" involved in it.
(1) First check out a pristine copy of your upstream, and cherry-pick A'
and B'
$ git checkout upstream ;# or whatever
$ git cherry-pick A'
$ git cherry-pick B'
(2-a) If you are sending patches to interact with your upstream, then
format-patch the two [*1*]
$ git format-patch -2
and send them out.
(2-b) If you are asking for them to pull, publish that to your public
repository and ask. Perhaps...
$ git push $publicURL HEAD:for-upstream
$ mail integrator@upstream.com
Subject: please pull
Please find my two changes at
$publicURL for-upstream
(2-c) If you can push, you push it to whichever branch the others are
expecting you to push to. Perhaps...
$ git push $upstreamURL HEAD:$branch
Now, how to deal with the duplicate copies A' and B' in your private
history is your problem, and it is largely independent from the above.
If your branch W is private and you haven't published, then you would want
to drop the now-obsolete two commits that do not belong to what you wanted
to achieve in that branch by running "rebase -i", perhaps...
$ git rebase -i A'^
... delete lines that correspond to A' and B' and save ...
If your branch W has been published (iow, other people have seen the
commits on it), then you shouldn't be doing rebase. When you merge
upstream to W (but why would you do that in the first place? You
shouldn't be working directly on a branch that you merge random changes
from other people), you _will_ end up having A and A' (and B and B') as
duplicates in your history. You'll need to live with it.
A good news is that git was designed for the Linux kernel community where
patch duplication is the norm, not exception. Over there, it is not
uncommon for a subsystem maintainer to pick up a patch from the mailing
list that falls within his area, while the maintainer at the higher level
than the subsystem maintainer picks up the same patch (perhaps because it
trivially fixes a rather urgent issue) and then later ends up merging with
the subsystem maintainer. When this happens, git notices that the two
sides made exactly the same change and resolves it as a non-conflicting
event when able (and it often is).
[Footnote]
*1* cherry-pick may not seem useful in this case, but it is a courtesy
to your upstream to give them a clean patch; cherry-picking and adjusting
for potential conflicts on top of the pristine upstream before running
format-patch will ensure this.
^ permalink raw reply [flat|nested] 3+ messages in thread