Re: What to do with patches that should go upstream?

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 13, 2010, 10:13 UTC
Message-ID: <7vzl4inwh1.fsf@alter.siamese.dyndns.org>
In-Reply-To: <5195c8761001130151q12ac636cnc69513087320195@mail.gmail.com>

Jeenu V <jeenuv@gmail.com> writes:

Show 15 quoted lines

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