On 2008-06-07 10:41:41 -0700, Jakub Narebski wrote:
> Karl Hasselström <kha@xxxxxxxxxxx> 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@xxxxxxxxxxx
www.treskal.com/kalle
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
