I like the change. I always create my commits using git commands, so I need to use stg repair all the time. I also use git-svn a lot, which doesn't integrate well with stgit. I think your suggestions would improve the situation a lot.
> 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). 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. Erik _______________________________________________ stgit-users mailing list [email protected] https://mail.gna.org/listinfo/stgit-users
