Re: StGIT discards local commits on "stg pull"

From: Yann Dirson <ydirson@altern.org>
Date: Feb 12, 2007, 21:47 UTC
Message-ID: <20070212214704.GS5362@nan92-1-81-57-214-146.fbx.proxad.net>
In-Reply-To: <20070212202634.GX4266@nan92-1-81-57-214-146.fbx.proxad.net>

On Mon, Feb 12, 2007 at 09:26:34PM +0100, Yann Dirson wrote:

Show 23 quoted lines

> 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.