Re: stg pull/rebase

["Karl Hasselström" <kha@treskal.com>]

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