Thread (1 message) 1 message, 1 author, 2016-06-15

Re: [Core GIT] Long-term cherrypicking

From: Catalin Marinas <hidden>
Date: 2016-06-15 22:42:07

Petr Baudis [off-list ref] wrote:
Dear diary, on Thu, Sep 22, 2005 at 11:53:27AM CEST, I got a letter
where Catalin Marinas [off-list ref] told me that...
quoted
But what I understand from Petr's e-mail is that re-basing the patches
is not acceptable for a repository which is public. One option would
be to keep a private tree where the patches are re-based and a public
one which periodically pulls from Linus' tree and your private
one. Not sure how complicated the commit graph would look.
It would be pretty ugly since the same patches would re-appear in the
commit graph in another incarnations many times.
True. And re-basing patches in the public branch would generate the
same complicated graph in people's repositories which were pulling
from it. If this is not desirable, StGIT on the public branch wouldn't
help much (and neither quilt since quilt patches are not visible via
GIT anyway).

As Junio said, using 'git cherry-pick' (or 'stg import --commit') on a
private branch would help organising the patches to be sent
upstream. One problem with this approach is that the conflicts
generated by merging with Linus in the public branch (and already
fixed there) would need to be re-solved in the private one after
cherry-picking.

-- 
Catalin
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help