Re: Rebasing stgit stacks

["Catalin Marinas" <catalin.marinas@gmail.com>]

On 24/01/07, Yann Dirson <ydirson@altern.org> wrote:
> On Tue, Jan 23, 2007 at 10:03:26PM +0000, Catalin Marinas wrote:
> > >I'll have to think more about that - I'm not sure I get you point.  By
> > >moving/cloning we keep (or could keep) the patches' history.  By
> > >importing we cannot do that.
> >
> > The 'pick' command could be (easily) fixed to preserve the history of
> > a patch (I'll add this to the todo list). The log commit would have
> > the picked patch's log as a parent rather than none.
>
> 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). 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.

> > As I said, I'll first like to get a 1.0 out this spring.
>
> Yes.  Maybe we should get 0.12 out of the door soon, with some more
> bugs fixed.  I'm trying to finish putting out in a decent shape stuff
> about parent branches, git-fetch use and the other related issues
> mentionned those last days.  Maybe that will be ready before enough
> bugs are squashed for 0.12, but maybe not :)

Maybe I'll manage to get a new release out in about a week or so.

-- 
Catalin