Re: StGIT discards local commits on "stg pull"

[Yann Dirson <ydirson@altern.org>]

On Mon, Feb 12, 2007 at 09:26:34PM +0100, Yann Dirson wrote:
> On Mon, Feb 12, 2007 at 09:31:28AM +0000, Catalin Marinas wrote:
> > On 12/02/07, Pavel Roskin <proski@gnu.org> wrote:
> > >I have been bitten by a strange bug/feature of StGIT, and it looks like
> > >it's not only counterintuitive, but also inconsistent with git.
> > >
> > >I have a repository available over ssh and I push to it from several
> > >places. Sometimes I make a commit and forget to push it.  Then I run "stg
> > >pull" to make sure my repository is up to date.
> > >
> > >The result is that the repository is rebased back to the last remote
> > >commit. It's very easy to miss.  There is no warning.  Everything looks
> > >just like an update from the remote.
> > >
> > >The example below shows that git-pull keeps my commit, but "stg pull"
> > >discards it by rebasing back to the remote ID.
> > 
> > I think this is a "feature"
> 
> No, I agree it's a bug.  Rebasing after a fetch should allow this
> workflow to work as well.  If the parent branch is not a rewinding
> one, we should ensure there is nothing lost.  And even for rewinding
> branches, we should probably keep track of the existence of commits,
> so we can warn and nothing gets lost without knowing.

Thinking about it, detecting whether we're going to lose a commit is
just checking *before pulling* whether the current base is reachable
from the parent's current head.

In git-fetch-based workflows, proceeding further should be simply
refused.  I'm not sure about the git-pull-based workflows; here is at
least one problem with git-pull I can think of:

AFAICT, someone using git-pull would in this case get a merge commit,
so under 0.11 (or with the compat settings outlined by Catalin) you
should now have your stack based on a merge commit, with as parents
the new parent-branch head and the commits you did not push yet, right ?
So how did you proceed from there using 0.11 ?

I'd think you still want to push your patch into the parent repo, but
the situtation is cumbersome: it would have been far easier IMHO to
"stg pull" first, in which case the fetch-and-rebase model is what you
wanted, and then do a "stg commit && git push".

That makes me think that indeed we should have an stgit command doing
precisely this "stg commit && git push" (suggested in previous mail)
as an atomic operation, rolling back the commit if the push failed
because you were out of date.


Since that looks like a pathological case, I suppose this may not be
what you were trying to do.  Can you please give more information if
that is the case ?

Best regards,
-- 
Yann.