Re: Rebasing stgit stacks

From: Yann Dirson <ydirson@altern.org>
Date: Jan 24, 2007, 20:03 UTC
Message-ID: <20070124200339.GA4036@nan92-1-81-57-214-146.fbx.proxad.net>
In-Reply-To: <b0943d9e0701240437l33a53f64tfea8267b78bff421@mail.gmail.com>

On Wed, Jan 24, 2007 at 12:37:15PM +0000, Catalin Marinas wrote:

Show 10 quoted lines

> >Right - "branch --clone" could also use that (or maybe it does already
> >by design).  Together with this, "pick --fold" and possibly "sync"
> >(although I never used the latter so I'm not 100% sure how it works)
> >could register a merge, and sometime in the future we could use this
> >information to be able to do some merging.  I'm not going to look
> >into this soon, but I have this popping out regularly in my head ;)
> 
> 'sync' is still experimental. I usually have the same patches on
> different branches (i.e. a stable kernel branch for customers and a
> more up-to-date branch for pushing patches upstream).

That sounds like a typical usecase we should document :)

Show 5 quoted lines

> I wanted a way to automatically synchronise the changes made to some
> patches found in both branches. This command folds the remote patch
> onto the current one using a three-way merge. If they are identical,
> the current patch shouldn't change. If they are not identical, it
> leads to conflicts that have to be manually solved.

So, indeed "sync" is a kind of merge tool already. It could be a good start to implement merging of forked patches. But going further would probably require to further develop the technics to work with patches of patches.

best regards,

-- 
Yann.