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. That makes me think that in most cases, an "stg commit" is done to be pushed to a remote repo, as symetric operation to "stg pull". Probably we could add support for this sort of operation (similar to "stg-cvs commit" from my script). > but we should've probably leave the > original behaviour as the default. Maybe we should also have this > per-branch rather than per-repository. Right, having it per-branch would allow, eg. to declare something like git-svn as the way to pull from a given branch, while using different backends for other branches. > I agree that for the rebasing case, we should have some warning if > fast-forwarding of the stack's base is not possible so that you could > run 'stg uncommit'. Right. "rebase --undo" could help too. 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