{"thread":{"id":"22196","subject":"What to do with patches that should go upstream?","startedAt":"2010-01-13T09:51:11Z","lastAt":"2010-01-13T10:34:33Z","messageCount":3,"participants":["Jeenu V","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"131456","messageId":"5195c8761001130151q12ac636cnc69513087320195@mail.gmail.com","threadId":"22196","inReplyTo":null,"subject":"What to do with patches that should go upstream?","fromName":"Jeenu V","fromEmail":"jeenuv@gmail.com","sentAt":"2010-01-13T09:51:11Z","receivedAt":"2010-01-13T09:51:11Z","isPatch":false,"sender":{"key":"jeenuv@gmail.com","avatar":"https://gravatar.com/avatar/0fae51e727209ba442f53fbab775dec62add0884f7a1bf1eb9fee94fb876f2b0?d=mp&s=160"},"body":"Hi,\n\nI'd like to know what's the best practice to follow when one discovers\nthat a change that's been applied on the current branch, has to\nactually go upstream. For example, in the following figure,\n\n A\n-O---O-+\n \\ A' B'\n-O---O---O---O---O---O---O W\n /\n -O----O--+\n\nW is the current working branch. But there are commits A' and B' which\nshould go upstream. What I wanted to know is the next step from here.\n\n1) Do I switch to A and B, and then cherry pick the commits A' and B'?\n2) If I send the patch out to include in upstream, wouldn't it\nconflict the next time I happen to merge from A or B?\n\nPlease suggest.\n\n-- \n:J\n"},{"id":"131457","messageId":"7vzl4inwh1.fsf@alter.siamese.dyndns.org","threadId":"22196","inReplyTo":"5195c8761001130151q12ac636cnc69513087320195@mail.gmail.com","subject":"Re: What to do with patches that should go upstream?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-01-13T10:13:46Z","receivedAt":"2010-01-13T10:13:46Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeenu V writes:\n\n> For example, in the following figure,\n>\n> A\n> -O---O-+\n> \\ A' B'\n> -O---O---O---O---O---O---O W\n> /\n> -O----O--+\n>\n> W is the current working branch. But there are commits A' and B' which\n> should go upstream. What I wanted to know is the next step from here.\n>\n> 1) Do I switch to A and B, and then cherry pick the commits A' and B'?\n> 2) If I send the patch out to include in upstream, wouldn't it\n> conflict the next time I happen to merge from A or B?\n\nI don't see B in your picture, so I may not be answering the question you\nwanted to ask, or you perhaps asked something other than the question you\nwanted to ask. Having said that, I think you are asking two more-or-less\nindependent questions.\n\nWhether you interact with your upstream by sending patches, asking them to\npull, or directly pushing into them, from your problem description, it is\nclear that you _only_ want to give change contained in A' and B'. So\nthere is no room for \"how do I\" involved in it.\n\n (1) First check out a pristine copy of your upstream, and cherry-pick A'\n and B'\n\n\t$ git checkout upstream ;# or whatever\n $ git cherry-pick A'\n $ git cherry-pick B'\n\n (2-a) If you are sending patches to interact with your upstream, then\n format-patch the two [*1*]\n\n\t$ git format-patch -2\n\n and send them out.\n\n (2-b) If you are asking for them to pull, publish that to your public\n repository and ask. Perhaps...\n\n\t$ git push $publicURL HEAD:for-upstream\n\n\t$ mail integrator@upstream.com\n Subject: please pull\n\n\tPlease find my two changes at\n $publicURL for-upstream\n\n (2-c) If you can push, you push it to whichever branch the others are\n expecting you to push to. Perhaps...\n\n\t$ git push $upstreamURL HEAD:$branch\n \nNow, how to deal with the duplicate copies A' and B' in your private\nhistory is your problem, and it is largely independent from the above.\n\nIf your branch W is private and you haven't published, then you would want\nto drop the now-obsolete two commits that do not belong to what you wanted\nto achieve in that branch by running \"rebase -i\", perhaps...\n\n\t$ git rebase -i A'^\n\t... delete lines that correspond to A' and B' and save ...\n\nIf your branch W has been published (iow, other people have seen the\ncommits on it), then you shouldn't be doing rebase. When you merge\nupstream to W (but why would you do that in the first place? You\nshouldn't be working directly on a branch that you merge random changes\nfrom other people), you _will_ end up having A and A' (and B and B') as\nduplicates in your history. You'll need to live with it.\n\nA good news is that git was designed for the Linux kernel community where\npatch duplication is the norm, not exception. Over there, it is not\nuncommon for a subsystem maintainer to pick up a patch from the mailing\nlist that falls within his area, while the maintainer at the higher level\nthan the subsystem maintainer picks up the same patch (perhaps because it\ntrivially fixes a rather urgent issue) and then later ends up merging with\nthe subsystem maintainer. When this happens, git notices that the two\nsides made exactly the same change and resolves it as a non-conflicting\nevent when able (and it often is).\n\n\n[Footnote]\n\n*1* cherry-pick may not seem useful in this case, but it is a courtesy\nto your upstream to give them a clean patch; cherry-picking and adjusting\nfor potential conflicts on top of the pristine upstream before running\nformat-patch will ensure this.\n"},{"id":"131458","messageId":"5195c8761001130234u59d7694bh699de788251f6764@mail.gmail.com","threadId":"22196","inReplyTo":"7vzl4inwh1.fsf@alter.siamese.dyndns.org","subject":"Re: What to do with patches that should go upstream?","fromName":"Jeenu V","fromEmail":"jeenuv@gmail.com","sentAt":"2010-01-13T10:34:33Z","receivedAt":"2010-01-13T10:34:33Z","isPatch":false,"sender":{"key":"jeenuv@gmail.com","avatar":"https://gravatar.com/avatar/0fae51e727209ba442f53fbab775dec62add0884f7a1bf1eb9fee94fb876f2b0?d=mp&s=160"},"body":"On Wed, Jan 13, 2010 at 3:43 PM, Junio C Hamano wrote:\n> Jeenu V writes:\n>\n>> For example, in the following figure,\n>>\n>>      A\n>> -O---O-+\n>>         \\        A'  B'\n>> -O---O---O---O---O---O---O W\n>>             /\n>>   -O----O--+\n>>\n>> W is the current working branch. But there are commits A' and B' which\n>> should go upstream. What I wanted to know is the next step from here.\n>>\n>> 1) Do I switch to A and B, and then cherry pick the commits A' and B'?\n>> 2) If I send the patch out to include in upstream, wouldn't it\n>> conflict the next time I happen to merge from A or B?\n>\n> I don't see B in your picture, so I may not be answering the question you\n> wanted to ask, or you perhaps asked something other than the question you\n> wanted to ask.  Having said that, I think you are asking two more-or-less\n> independent questions.\n\nSorry, B was meant to be the branch at the bottom. But anyway I think\nI got hints on what I needed. Thank you for your descriptive reply.\n\n-- \n:J\n"}]}