On Mon, Jan 22, 2007 at 10:58:41PM +0000, Catalin Marinas wrote: > On 22/01/07, Yann Dirson <ydirson@xxxxxxxxxx> wrote: > >On Mon, Jan 22, 2007 at 05:54:29PM +0000, Catalin Marinas wrote: > >> Currently, in the StGIT terminology stack and branch are about the > >> same. If you want to move to a different stack, just use the "stg > >> branch" command. > > > >I think you missed the point. StGIT stacks are usually forked off > >another branch. As I understand it, Jakub talks about standard > >rebasing, ie. moving the stack base from its current parent branch to > >a new one. > > StGIT stacks are a series of volatile commits (commits) at the top of > a branch. The idea when I started writing this tool was that a series > of applied patches would lead to the head of the current branch. The > branch and stack are tightly coupled and you cannot simply change the > parent branch the stack is based on (not from a technical point but > rather from conception one). Well, that's now allowed by "rebase". > >> A stack is just a branch with stgit-specific metadata. > > > >I would rather say that an StGIT stacks uses a branch, but the stack > >is not the branch - eg, unapplied patches do not belong to the branch. > > 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 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. > 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. > I added the commit command to have a way to freeze this state into > the current branch and no longer manage them with StGIT. > >> What you'd probably want is a way to import patches from a different > >> branch/stack onto the newly checked out branch. > > > >Sometimes you just want to throw out an obsolete branch and move your > >stack to a new baseline. That said, being able to duplicate a stack > >(and possibly rebasing it afterwards) would be useful as well. > > You have 'branch --clone' (or --rename if you just want a different > name) and now 'rebase'. D'oh. I was probably expecting "stack --clone" or something :) > 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. Best regards, -- Yann. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html