Re: StGIT discards local commits on "stg pull"

["Catalin Marinas" <catalin.marinas@gmail.com>]

On 13/02/07, Pavel Roskin <proski@gnu.org> wrote:
> 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.

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

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