Re: StGIT discards local commits on "stg pull"

From: Catalin Marinas <catalin.marinas@gmail.com>
Date: Feb 13, 2007, 22:48 UTC
Message-ID: <b0943d9e0702131448x360018b3w6d1790a84f201710@mail.gmail.com>
In-Reply-To: <1171326011.2326.30.camel@dv>

On 13/02/07, Pavel Roskin <proski@gnu.org> wrote:

Show 13 quoted lines

> On Mon, 2007-02-12 at 09:31 +0000, Catalin Marinas wrote:
> > On 12/02/07, Pavel Roskin <proski@gnu.org> wrote:
>
> > > 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.

Yann can describe the motivation better as he was the one pushing for it. It was mainly to allow different local branches to be based on different remote branches. In the normal case, i.e. using only StGIT commands, there shouldn't be any difference. As I said, the old behaviour is still present and maybe we should do the new one per-branch.

> 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).

Yes, indeed.

Show 11 quoted lines

> 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 probably have another situation - a branch managed partially with StGIT but GIT commits (or 'stg commit') used and pulling would lead to a merge of the base, followed by patch pushing. This would work if we use git-pull rather than git-fetch.

Show 15 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 don't consider this as a backward-compatibility feature. It simply targets a different workflow and it would be even better if we have it per-branch. The default should be the current fetch+rebase (as the most common case would be to use StGIT commands only) but with a warning if stack base fast-forwarding is not possible.

-- 
Catalin