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