On Tue, Jun 19, 2007 at 11:18:56PM +0100, Catalin Marinas wrote: > 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? Not at all. I'm talking about an stgit stack, whose base is the head of another stack (eg. a "pu" branch). When you want to rebase, the old heads/pu is only reachable from your stack base. Maybe we can use the parent's reflog, but I'm not sure it would cover all cases, and a reflog can possibly be expired before the information in there gets used. > 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. That is another issue - and I rather believe we should not allow a user to do that without --force, if what he committed will be unreachable after rebasing. If he intended to loose it, he would usually rather have used "stg delete" than such a convoluted sequence of actions :) 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
