On 19/06/07, Catalin Marinas <catalin.marinas@xxxxxxxxx> wrote:
On 14/06/07, Yann Dirson <ydirson@xxxxxxxxxx> wrote: > When the parent branch is a rewinding one (eg. an stgit stack), then > the old version of the patch will be turned to unreachable by > pull/rebase, and we probably have even no way of telling stgit that it > is indeed expected, since the parent stack is a local one. My own > workflow on StGIT is affected by the issue, since my "bugs" stack is > forked off my "master" stack (but hopefully an hydra will help me ;). If I understand correctly, is this the case where you do a 'stg commit'? This command is meant for branches that are never rebased (i.e. my master stgit branch). For this branch one wouldn't have a remote branch configured and hence git fetch shouldn't do anything.
I got confused - you were talking about 'stg rebase' rather than the 'pull' strategy. But the question remains - are you referring to the user running 'stg commit' and losing this commit after a rebase? The rebase should be equivalent to a git-reset but with popping/pushing of the patches one the stack. Once committed, the patch is no longer managed by StGIT and therefore we shouldn't care. -- Catalin - 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
