On 1 February 2011 11:08, Erik Carstensen <[email protected]> wrote: >> The base of the stack is no longer maintained by StGit but determined >> as the common ancestor between the current branch and a >> parent/upstream branch (maybe defaulting to origin/master). All the >> commits from the common ancestor to HEAD are considered applied >> patches. > > This criterion allows that merge commits can be stgit patches. I think > it's possible to manage this: If a commit is a merge from a third > branch, we could either remove the extra parent or try to maintain it > when moving the patch around. If a branch/merge pair is contained > entirely within the stack, we could make the commits between the > branch/merge pair untouchable for most commands, but provide a way to > linearize the commit DAG (e.g., atomically pop all patches from one of > the branches).
I have a similar feature in my private patches to allow multiple parents to a commit representing a patch. This allowed "stg uncommit" to go through merges. I thought about maintaining the extra parent when moving the patch around. Anyway, this would need experimenting for a while to find corner cases. > Another problematic use case is when the user selected the wrong > upstream branch, and this gives a huge stack. This should be fairly > easy to solve though; e.g., stg could give up if the stack grows above > some configurable threshold. We could also store the base of a series in the git config and update it via "stg rebase" if we don't have a parent/tracking branch. -- Catalin _______________________________________________ stgit-users mailing list [email protected] https://mail.gna.org/listinfo/stgit-users
