stg pull/rebase

stg pull/rebase

[Karl Hasselström]

As I said, I've been thinking a bit about stg pull and stg rebase
recently (though I haven't written any code; I don't want to be
juggling too many balls at once).

Currently, there's stg rebase which only does rebasing, and stg pull
which does either rebase or merge depending on a config option. And on
top of that there's config stuff like stgit.pullcmd that is invoked in
some cases but not others.

What I think I'd like is the following:

  * Just one command, stg pull. stg rebase is removed.

  * When pull is invoked, the following happens:

      1. The branch we pull from may be updated, depending on the
         configuration. (e.g. git fetch or git svn fetch)

      2. Depending on the configuration (overridable by the
      --fast-forward, --rebase, and --merge options), one of these
      three things happen:

         1. We pop all patches, fast-forward to the new base, and push
            them back. If it's not a fast-forward, we error out.

         2. We pop all patches, reset to the new base, and push them
            back.

         3. We pop all patches, merge with the other branch, then push
            the patches back.

      Fast-forward is the default if no configuration or command-line
      flag is given.

I've personally never had a need for the merge case, but I recall you
arguing to keep it, Catalin?

The benefits of this organisation are

  * Configuration of how to update the remote prior to pulling and
    ff/rebase/merge configuration are orthogonal.

  * The default action is to fast-forward, which is probably what most
    users want -- merge is very likely to do the wrong thing, and
    rebase can lose changes.

  * The remote updating is entirely separated from the actual pushing
    and popping of patches, since it runs to completion before we do
    anything else. This means that we can pop, change the base and
    push in a single transaction.

-- 
Karl Hasselström, kha@treskal.com
      www.treskal.com/kalle

Re: stg pull/rebase

[Jakub Narebski]

Karl Hasselström <kha@treskal.com> writes:

> Currently, there's stg rebase which only does rebasing, and stg pull
> which does either rebase or merge depending on a config option. And on
> top of that there's config stuff like stgit.pullcmd that is invoked in
> some cases but not others.
> 
> What I think I'd like is the following:
> 
>   * Just one command, stg pull. stg rebase is removed.

And I would have to learn to use other command (I use very frequently
the following sequence: git remote update && stg rebase <branch>)?
Not nice.
 
I already have to use two commands: "stg refresh && stg edit" to make
a change which affects how commit message is written, instead of
simplier "stg refresh --edit".

>   * When pull is invoked, the following happens:
> 
>       1. The branch we pull from may be updated, depending on the
>          configuration. (e.g. git fetch or git svn fetch)
> 
>       2. Depending on the configuration (overridable by the
>       --fast-forward, --rebase, and --merge options), one of these
>       three things happen:

Couldn't then "stg rebase" be 'internal alias' to "git pull --rebase"?

[...]
>   * The default action is to fast-forward, which is probably what most
>     users want -- merge is very likely to do the wrong thing, and
>     rebase can lose changes.

Unless you want to rebase on top of different branch, for example
moving stack from 'master' to 'next', or when you work on top of
branch which doesn't fast-forward, like 'pu' in git repository.
 
-- 
Jakub Narebski
Poland
ShadeHawk on #git

Re: stg pull/rebase

[Karl Hasselström]

On 2008-06-07 10:41:41 -0700, Jakub Narebski wrote:

> Karl Hasselström <kha@treskal.com> writes:
>
> >   * Just one command, stg pull. stg rebase is removed.
>
> And I would have to learn to use other command (I use very
> frequently the following sequence: git remote update && stg rebase
> <branch>)? Not nice.

Right. We could keep "stg rebase" for backwards compatibility. (It
would mean stg pull --rebase.) I like to complain about the too-large
number of stg subcommands, but upset users are even less desirable ...
:-)

> I already have to use two commands: "stg refresh && stg edit" to
> make a change which affects how commit message is written, instead
> of simplier "stg refresh --edit".

Yes, sorry about that. You have pointed it out before, and I've been
meaning to fix it.

> >    2. Depending on the configuration (overridable by the
> >       --fast-forward, --rebase, and --merge options), one of these
> >       three things happen:
>
> Couldn't then "stg rebase" be 'internal alias' to "git pull
> --rebase"?

Absolutely.

> >   * The default action is to fast-forward, which is probably what
> >     most users want -- merge is very likely to do the wrong thing,
> >     and rebase can lose changes.
>
> Unless you want to rebase on top of different branch, for example
> moving stack from 'master' to 'next', or when you work on top of
> branch which doesn't fast-forward, like 'pu' in git repository.

Yes, definitely. rebase would stay a "first-class citizen". But I
really do think that having fast-forward as an option is nice; in many
cases you build on top of a non-rebasing branch, and having the tool
verify that you don't lose commits is a good thing.

And when the user says just "stg pull" (having configured nothing)
it's probably best to default to the simplest and safest of the three:
fast-forward. If the user wants "rebase", it'd be available either
with the command-line option or with a (per-branch) config file
setting.

-- 
Karl Hasselström, kha@treskal.com
      www.treskal.com/kalle

Re: stg pull/rebase

[Catalin Marinas]

2008/6/7 Karl Hasselström <kha@treskal.com>:
> As I said, I've been thinking a bit about stg pull and stg rebase
> recently (though I haven't written any code; I don't want to be
> juggling too many balls at once).
>
> Currently, there's stg rebase which only does rebasing, and stg pull
> which does either rebase or merge depending on a config option. And on
> top of that there's config stuff like stgit.pullcmd that is invoked in
> some cases but not others.

This would need some clean-up indeed or maybe better documentation.
They might be a bit difficult and I have to look at the code from time
to time. However, I found some these policies useful. For example, I
just do a "stg pull" from a Subversion repository with the config
below:

[stgit]
        pull-policy = fetch-rebase
        fetchcmd = git svn fetch
        rebasecmd = git svn rebase

> What I think I'd like is the following:
>
>  * Just one command, stg pull. stg rebase is removed.

I still find "rebase" useful and use it in some situations when I
don't need a pull. As Jakub mentioned, maybe we could keep the
"rebase" functionality outside of the "pull" command (make it part of
Stack with a corresponding Branch.rebase?) and have "rebase" use it.

>  * When pull is invoked, the following happens:
>
>      1. The branch we pull from may be updated, depending on the
>         configuration. (e.g. git fetch or git svn fetch)

OK.

>      2. Depending on the configuration (overridable by the
>      --fast-forward, --rebase, and --merge options), one of these
>      three things happen:

But "pull" always suggests fetching something. Adding "--rebase" would
mean that it doesn't fetch. Shouldn't we leave this functionality to
"rebase" only?

>         1. We pop all patches, fast-forward to the new base, and push
>            them back. If it's not a fast-forward, we error out.
>
>         2. We pop all patches, reset to the new base, and push them
>            back.
>
>         3. We pop all patches, merge with the other branch, then push
>            the patches back.

These are OK, with the comment on have rebase functionality in "rebase" only.

>      Fast-forward is the default if no configuration or command-line
>      flag is given.

OK.

> I've personally never had a need for the merge case, but I recall you
> arguing to keep it, Catalin?

I don't use it either but there might be people that have complicated
configurations and they mix Git commits with StGIT patches. Not sure
though.

-- 
Catalin

Re: stg pull/rebase

[Karl Hasselström]

On 2008-06-10 11:02:18 +0100, Catalin Marinas wrote:

> However, I found some these policies useful. For example, I just do
> a "stg pull" from a Subversion repository with the config below:
>
> [stgit]
>         pull-policy = fetch-rebase
>         fetchcmd = git svn fetch
>         rebasecmd = git svn rebase

Looks useful.

But what exactly is "rebasecmd" useful for, when you already have
"fetchcmd" and a built-in rebase?

> 2008/6/7 Karl Hasselström <kha@treskal.com>:
>
> > What I think I'd like is the following:
> >
> >  * Just one command, stg pull. stg rebase is removed.
>
> I still find "rebase" useful and use it in some situations when I
> don't need a pull. As Jakub mentioned, maybe we could keep the
> "rebase" functionality outside of the "pull" command (make it part
> of Stack with a corresponding Branch.rebase?) and have "rebase" use
> it.

Yes. We could have "stg rebase" == "stg pull --rebase --no-fetch".

> >      2. Depending on the configuration (overridable by the
> >      --fast-forward, --rebase, and --merge options), one of these
> >      three things happen:
>
> But "pull" always suggests fetching something. Adding "--rebase"
> would mean that it doesn't fetch. Shouldn't we leave this
> functionality to "rebase" only?

These two things are orthogonal:

  1. Whether and how to update the branch we're pulling from
     (fetching).

  2. How to do the actual pulling (rebase, fast-forward, or merge).

I envision (1) being controlled by the branch config (and overridable
with a --no-fetch option or something), and (2) being controlled by
another part of the branch config (and overridable with
--fast-forward, --merge, and --rebase).

> >         1. We pop all patches, fast-forward to the new base, and
> >            push them back. If it's not a fast-forward, we error
> >            out.
> >
> >         2. We pop all patches, reset to the new base, and push
> >            them back.
> >
> >         3. We pop all patches, merge with the other branch, then
> >            push the patches back.
>
> These are OK, with the comment on have rebase functionality in
> "rebase" only.

Why? I don't see the difference between rebase and the other two that
would motivate such a separation.

-- 
Karl Hasselström, kha@treskal.com
      www.treskal.com/kalle

Re: stg pull/rebase

[Catalin Marinas]

2008/6/10 Karl Hasselström <kha@treskal.com>:
> On 2008-06-10 11:02:18 +0100, Catalin Marinas wrote:
>
>> However, I found some these policies useful. For example, I just do
>> a "stg pull" from a Subversion repository with the config below:
>>
>> [stgit]
>>         pull-policy = fetch-rebase
>>         fetchcmd = git svn fetch
>>         rebasecmd = git svn rebase
>
> Looks useful.
>
> But what exactly is "rebasecmd" useful for, when you already have
> "fetchcmd" and a built-in rebase?

In case the built-in rebase is not enough. Can you use "git svn fetch"
followed by plain "git rebase"? There are some comments in git-svn.txt
that recommend to use "git svn rebase" to preserve linear history.

>> 2008/6/7 Karl Hasselström <kha@treskal.com>:
>> >      2. Depending on the configuration (overridable by the
>> >      --fast-forward, --rebase, and --merge options), one of these
>> >      three things happen:
>>
>> But "pull" always suggests fetching something. Adding "--rebase"
>> would mean that it doesn't fetch. Shouldn't we leave this
>> functionality to "rebase" only?
>
> These two things are orthogonal:
>
>  1. Whether and how to update the branch we're pulling from
>     (fetching).
>
>  2. How to do the actual pulling (rebase, fast-forward, or merge).

I think it's more of an language interpretation issue (I'm not a
native English speaker). I see the "pull" action as pulling (can't
find meaningful synonyms) remote changes into the current branch (i.e.
fetch + merge). I think you see it as pulling the current stack onto a
new base (i.e. rebase).

> I envision (1) being controlled by the branch config (and overridable
> with a --no-fetch option or something), and (2) being controlled by
> another part of the branch config (and overridable with
> --fast-forward, --merge, and --rebase).

OK.

>> >         1. We pop all patches, fast-forward to the new base, and
>> >            push them back. If it's not a fast-forward, we error
>> >            out.
>> >
>> >         2. We pop all patches, reset to the new base, and push
>> >            them back.
>> >
>> >         3. We pop all patches, merge with the other branch, then
>> >            push the patches back.
>>
>> These are OK, with the comment on have rebase functionality in
>> "rebase" only.
>
> Why? I don't see the difference between rebase and the other two that
> would motivate such a separation.

See my interpretation of the word "pull". I can change my mind, no
problem, but it would be interesting to see what a native English
speaker says (though you are probably closer to English than me :-)).

-- 
Catalin

Re: stg pull/rebase

[Karl Hasselström]

On 2008-06-10 16:43:27 +0100, Catalin Marinas wrote:

> 2008/6/10 Karl Hasselström <kha@treskal.com>:
>
> > On 2008-06-10 11:02:18 +0100, Catalin Marinas wrote:
> >
> > > However, I found some these policies useful. For example, I just
> > > do a "stg pull" from a Subversion repository with the config
> > > below:
> > >
> > > [stgit]
> > >         pull-policy = fetch-rebase
> > >         fetchcmd = git svn fetch
> > >         rebasecmd = git svn rebase
> >
> > Looks useful.
> >
> > But what exactly is "rebasecmd" useful for, when you already have
> > "fetchcmd" and a built-in rebase?
>
> In case the built-in rebase is not enough. Can you use "git svn
> fetch" followed by plain "git rebase"? There are some comments in
> git-svn.txt that recommend to use "git svn rebase" to preserve
> linear history.

You most definitely can. I've been doing so daily for more than a
year:

  $ git svn fetch -q
  $ stg rebase -m svn/branch

I _think_ what git svn rebase does is look at the git-svn commit
metadata to determine how many commits to rebase. But stg already has
this information, so we don't need it. (I haven't actually looked into
exactly what git svn rebase does, so it might turn out it's doing
something else too, but I can't think of anything that would be
necessary. As I said, I've been using this workflow for a long time,
and it works.)

The _advantage_ of having fetch be the only external command (besides
reducing complexity) is that we can make it all one single StGit
transaction (since the fetch runs to completion before the transaction
starts). This means that we don't have to touch files unnecessarily,
which means less recompilation.

> > > But "pull" always suggests fetching something. Adding "--rebase"
> > > would mean that it doesn't fetch. Shouldn't we leave this
> > > functionality to "rebase" only?
> >
> > These two things are orthogonal:
> >
> >  1. Whether and how to update the branch we're pulling from
> >     (fetching).
> >
> >  2. How to do the actual pulling (rebase, fast-forward, or merge).
>
> I think it's more of an language interpretation issue (I'm not a
> native English speaker). I see the "pull" action as pulling (can't
> find meaningful synonyms) remote changes into the current branch
> (i.e. fetch + merge). I think you see it as pulling the current
> stack onto a new base (i.e. rebase).

Well, the reason I proposed to keep "stg pull" rather than "stg
rebase" is that I agree with you that "pull" means "fetch _and_
integrate". (Let's try a new term; "integrate" means either "merge",
"fast-forward", or "rebase" (none of which implies any fetching, of
course).) This is how I imagine it working:

  stg pull

    Do a default fetch (that is, fetch according to the branch
    config), followed by a default integrate.

  stg pull --no-fetch

    Just a default integrate, no fetch.

  stg pull --fetch-only

    Just a default fetch, no integrate.

  stg pull --fast-forward

    Default fetch, followed by a "fast-forward" integrate.

  stg pull --rebase

    Default fetch, followed by a "rebase" integrate.

  stg pull --merge

    Default fetch, followed by a "merge" integrate.

Any of --no-fetch/--fetch-only can be combined with any of
--fast-forward/--rebase/--merge.

If stg pull is given a committish argument, this automatically means
--no-fetch, and causes it to integrate with that committish rather
than the branch specified in the config. We might want to allow other
kinds of arguments as well, I don't know.

And of course,

  stg rebase [committish]

    The same as "stg pull --no-fetch --rebase [committish]"; that is,
    no fetch, just rebase.

> > > These are OK, with the comment on have rebase functionality in
> > > "rebase" only.
> >
> > Why? I don't see the difference between rebase and the other two
> > that would motivate such a separation.
>
> See my interpretation of the word "pull". I can change my mind, no
> problem, but it would be interesting to see what a native English
> speaker says (though you are probably closer to English than me
> :-)).

Mph, I don't know about me being "closer". I thought you were the one
living in the UK? ;-)

Regardless, I don't think we're actually in disagreement -- as I
understand it, we both think that pull = fetch + integrate. And
"rebase" is one possible value of "integrate". (Holler if you disagree
with either of the views I've attributed to you.)

-- 
Karl Hasselström, kha@treskal.com
      www.treskal.com/kalle

Re: stg pull/rebase

[Catalin Marinas]

2008/6/11 Karl Hasselström <kha@treskal.com>:
> On 2008-06-10 16:43:27 +0100, Catalin Marinas wrote:
>
>> 2008/6/10 Karl Hasselström <kha@treskal.com>:
>> > But what exactly is "rebasecmd" useful for, when you already have
>> > "fetchcmd" and a built-in rebase?
>>
>> In case the built-in rebase is not enough. Can you use "git svn
>> fetch" followed by plain "git rebase"? There are some comments in
>> git-svn.txt that recommend to use "git svn rebase" to preserve
>> linear history.
>
> You most definitely can. I've been doing so daily for more than a
> year:
>
>  $ git svn fetch -q
>  $ stg rebase -m svn/branch

Maybe, I haven't tried (I just followed the git-svn documentation). Is
the imported svn history linear? If it works, I no longer have a need
for a rebasecmd option.

> The _advantage_ of having fetch be the only external command (besides
> reducing complexity) is that we can make it all one single StGit
> transaction (since the fetch runs to completion before the transaction
> starts). This means that we don't have to touch files unnecessarily,
> which means less recompilation.

That's a good reason.

>> I think it's more of an language interpretation issue (I'm not a
>> native English speaker). I see the "pull" action as pulling (can't
>> find meaningful synonyms) remote changes into the current branch
>> (i.e. fetch + merge). I think you see it as pulling the current
>> stack onto a new base (i.e. rebase).
>
> Well, the reason I proposed to keep "stg pull" rather than "stg
> rebase" is that I agree with you that "pull" means "fetch _and_
> integrate". (Let's try a new term; "integrate" means either "merge",
> "fast-forward", or "rebase" (none of which implies any fetching, of
> course).) This is how I imagine it working:
[...]
> Any of --no-fetch/--fetch-only can be combined with any of
> --fast-forward/--rebase/--merge.
>
> If stg pull is given a committish argument, this automatically means
> --no-fetch, and causes it to integrate with that committish rather
> than the branch specified in the config. We might want to allow other
> kinds of arguments as well, I don't know.
>
> And of course,
>
>  stg rebase [committish]
>
>    The same as "stg pull --no-fetch --rebase [committish]"; that is,
>    no fetch, just rebase.

I'm OK, as long as we keep a "rebase" alias :-)

>> See my interpretation of the word "pull". I can change my mind, no
>> problem, but it would be interesting to see what a native English
>> speaker says (though you are probably closer to English than me
>> :-)).
>
> Mph, I don't know about me being "closer". I thought you were the one
> living in the UK? ;-)

I was more thinking about the native language roots (Germanic vs Latin
in my case, I've only lived in the UK for 7 years) :-)

> Regardless, I don't think we're actually in disagreement -- as I
> understand it, we both think that pull = fetch + integrate. And
> "rebase" is one possible value of "integrate".

I think the disagreement is that I consider "fetch" in the above
equality to be mandatory. But I think your proposal is OK.

-- 
Catalin

Re: stg pull/rebase

[Karl Hasselström]

On 2008-06-11 18:00:25 +0100, Catalin Marinas wrote:

> 2008/6/11 Karl Hasselström <kha@treskal.com>:
>
> > On 2008-06-10 16:43:27 +0100, Catalin Marinas wrote:
> >
> > > 2008/6/10 Karl Hasselström <kha@treskal.com>:
> > >
> > > > But what exactly is "rebasecmd" useful for, when you already
> > > > have "fetchcmd" and a built-in rebase?
> > >
> > > In case the built-in rebase is not enough. Can you use "git svn
> > > fetch" followed by plain "git rebase"? There are some comments
> > > in git-svn.txt that recommend to use "git svn rebase" to
> > > preserve linear history.
> >
> > You most definitely can. I've been doing so daily for more than a
> > year:
> >
> >  $ git svn fetch -q
> >  $ stg rebase -m svn/branch
>
> Maybe, I haven't tried (I just followed the git-svn documentation).
> Is the imported svn history linear?

Yes, it's linear. (Can git-svn do anything else?)

> If it works, I no longer have a need for a rebasecmd option.

As I said, it works for me. And I can't really think of a case where
it wouldn't work. Try it and see!

> > And of course,
> >
> >  stg rebase [committish]
> >
> >    The same as "stg pull --no-fetch --rebase [committish]"; that
> >    is, no fetch, just rebase.
>
> I'm OK, as long as we keep a "rebase" alias :-)

I guess you and Jakub have me cornered here. ;-)

> > > See my interpretation of the word "pull". I can change my mind,
> > > no problem, but it would be interesting to see what a native
> > > English speaker says (though you are probably closer to English
> > > than me :-)).
> >
> > Mph, I don't know about me being "closer". I thought you were the
> > one living in the UK? ;-)
>
> I was more thinking about the native language roots (Germanic vs
> Latin in my case, I've only lived in the UK for 7 years) :-)

English is too far from Swedish in this case. My guideline in these
matters is my overconfidence in my own English skills. (And in this
particular case, having followed a mailing list where every month a
new unsuspecting user is taught that pull = fetch + merge.)

> > Regardless, I don't think we're actually in disagreement -- as I
> > understand it, we both think that pull = fetch + integrate. And
> > "rebase" is one possible value of "integrate".
>
> I think the disagreement is that I consider "fetch" in the above
> equality to be mandatory.

Well, I too consider "pull" to imply "fetch", so I don't see a
disagreement. I only called it "stg pull --no-fetch" instead of "stg
integrate" or whatever because (1) users will have an easier time
finding it that way, and (2) we have too many stg subcommands already.

> But I think your proposal is OK.

Yay!

-- 
Karl Hasselström, kha@treskal.com
      www.treskal.com/kalle