Re: StGIT rebasing safeguard
- From
- Catalin Marinas <catalin.marinas@gmail.com>
- Date
- Jun 19, 2007, 22:18 UTC
- Message-ID
- <b0943d9e0706191518o6396a2c5u1fb4f0953dc85aa@mail.gmail.com>
- In-Reply-To
- <b0943d9e0706191512l5f19b80v5b5be9151be13025@mail.gmail.com>
On 19/06/07, Catalin Marinas <catalin.marinas@gmail.com> wrote:
Show 12 quoted lines
> On 14/06/07, Yann Dirson <ydirson@altern.org> 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