Re: stg pull/rebase

From: Catalin Marinas <catalin.marinas@gmail.com>
Date: Jun 10, 2008, 10:02 UTC
Message-ID: <b0943d9e0806100302j159f5b7fq6d970316b902b39b@mail.gmail.com>
In-Reply-To: <20080607172202.GA5179@diana.vm.bytemark.co.uk>

2008/6/7 Karl Hasselström <kha@treskal.com>:

Show 8 quoted lines

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

Show 8 quoted lines

>         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