Re: stg pull/rebase

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

Karl Hasselström [off-list ref] writes:

quoted

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

quoted

   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.

quoted

  * 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