Re: [Core GIT] Long-term cherrypicking

From: Catalin Marinas <catalin.marinas@gmail.com>
Date: Sep 22, 2005, 10:17 UTC
Message-ID: <tnxll1p2yqb.fsf@arm.com>
In-Reply-To: <20050922095845.GE21019@pasky.or.cz>

Petr Baudis <pasky@suse.cz> wrote:

Show 10 quoted lines

> Dear diary, on Thu, Sep 22, 2005 at 11:53:27AM CEST, I got a letter
> where Catalin Marinas <catalin.marinas@gmail.com> told me that...
>> 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