Re: stg pull/rebase

["Catalin Marinas" <catalin.marinas@gmail.com>]

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