Re: StGIT discards local commits on "stg pull"
- From
- Pavel Roskin <proski@gnu.org>
- Date
- Feb 13, 2007, 00:20 UTC
- Message-ID
- <1171326011.2326.30.camel@dv>
- In-Reply-To
- <b0943d9e0702120131r528fb29ete143b8ce5a0a99e9@mail.gmail.com>
On Mon, 2007-02-12 at 09:31 +0000, Catalin Marinas wrote:
> On 12/02/07, Pavel Roskin <proski@gnu.org> wrote:
Show 6 quoted lines
> > 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.
I don't know the original motivation behind effectively reimplementing "git pull" in StGIT, but it's clear that the StGIT's own implementation needs some polish.
I think it's always wrong to lose local commits. I think StGIT should refuse to rebase if a merge would be needed or the rebase would go back in history (in other words, if git-pull would not go to the remote revision).
> 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).
Maybe such assumptions could be enforced? Perhaps we could consider branch specialization. As it stands now, we can have branches where fast-forward is OK and branches where it's not OK.
If we look at it from the user standpoint, the branches could be distinguished by the use model:
1) Tracking branch: pull is OK, commit is not OK, push is not OK. All development is done in StGIT patches and sent to others.
2) Development branch: commit is OK, push is OK, pull is OK but no merges by default.
3) Merge branch: pull is OK, even with automatic merge, commit is OK, merge is OK.
I'm not sure if this belongs to git or StGIT.
Show 10 quoted lines
> 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.
It's actually my deliberate choice to subject myself to the pains of the default configuration. I don't want to live in backwards compatible environment until it rots away. I'll rather eat the dogfood we are offering to others :)
> 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'.
Sounds good to me.
-- Regards, Pavel Roskin