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