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