From: Catalin Marinas Date: Mon, 12 Feb 2007 09:31:28 GMT Subject: Re: StGIT discards local commits on "stg pull" Message-ID: In-Reply-To: <20070212022625.rvyyo0kc0wowgogc@webmail.spamcop.net> On 12/02/07, Pavel Roskin 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" but we should've probably leave the original behaviour as the default. Maybe we should also have this per-branch rather than per-repository. In StGIT 0.12, git-fetch is used by default rather than git-pull and StGIT performs the rebasing. We had some discussions on whether this would break existing workflows and we thought it wouldn't (I don't usually mix git-commit with stg commands). The solution would be to define the following in your gitconfig file (either ~/.gitconfig or .git/config; a full example in StGIT's examples/gitconfig): [stgit] pullcmd = git-pull pull-does-rebase = no The last line would tell StGIT not to do the rebasing and let git-pull handle it. 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'. -- Catalin