Re: Rebasing stgit stacks

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

On 23/01/07, Yann Dirson <ydirson@altern.org> wrote:
> On Mon, Jan 22, 2007 at 10:58:41PM +0000, Catalin Marinas wrote:
> > On 22/01/07, Yann Dirson <ydirson@altern.org> wrote:
> > The unapplied patches can have any commit as a parent, either in the
> > direct history of the current branch or in any other branch, there is
> > no restriction here. They get in line with the current branch's head
> > during the push operation.
>
> Right.  I'm just emphasizing that, since they are (even temporarily)
> not part of the GIT branch from a GIT point of view, but part of the
> stack, the 2 concepts, while closely linked, are not strict subsets of
> each other.  Rather, they share some common points, but neither would
> be parent of the other in a class hierarchy.

Indeed, but my point is that they are really tightly coupled and not
easy to disconnect in the current design. Maybe we could loose the
coupling post 1.0 but I'm not convinced it wouldn't create confusion
among users. I also don't think there would be many users wanting to
move a stack on top of a different branch when some import or multiple
cherry-picking would be enough.

> > >Indeed I was thinking about that today, and thought that maybe it
> > >would make sense not to use a head ref (and thus not using a real
> > >branch), which would minimize the risk of someone committing by error
> > >(and thus minimize the need to use "assimilate"), since porcelainish
> > >commit tools would then refuse to commit there.
> >
> > But isn't this what Quilt already does (i.e. a different mechanism for
> > patches, on top of any SCM)?
>
> I'm not sure wat you mean here.  I'm only talking of StGIT and the GIT
> world here.

I got the (wrong) impression that you'd like to disconnect StGIT
patches from GIT commits which would mean re-writing Quilt or some
other form of patch management.

> > One of the base ideas of StGIT is that the top patch represents the
> > head of the current branch and that the patches applied on the stack
> > always form the recent history of the current branch.
>
> I'm not willing to change the concept.  I'm just wondering whether
> using a non-head reference (eg. stacks/<name> or stacks/<name>/top)
> would not be better.  For this we may need to consider using detached
> HEAD support from 1.5.0, but I'm just thinking loudly, I have not
> looked at what that thing provides exactly yet.

It might be a good idea (probably post 1.0) since we have a 'commit'
command to update the head of the branch already. I'll have to think a
bit more to make sure it doesn't break existing use-cases. I also
haven't followed the detached HEAD support. StGIT currently relies on
the HEAD giving the information about the current branch.

> > As I said, the idea of moving the stack (patches) on top of a
> > different branch should be done as an import (or multiple
> > cherry-pick or clone), otherwise we loose the coupling between
> > branches and stacks.
>
> 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.

StGIT grew up almost (or just 2 months behind) at the same time with
GIT with a lot experimental/prototype features implemented. Now we
probably have a lot more ideas (and users) about how we should use GIT
and StGIT and can re-design parts of StGIT to accommodate the new
use-cases. As I said, I'll first like to get a 1.0 out this spring.

-- 
Catalin