Re: stg pull/rebase

From: Karl Hasselström <kha@treskal.com>
Date: Jun 10, 2008, 10:42 UTC
Message-ID: <20080610104244.GC30119@diana.vm.bytemark.co.uk>
In-Reply-To: <b0943d9e0806100302j159f5b7fq6d970316b902b39b@mail.gmail.com>

On 2008-06-10 11:02:18 +0100, Catalin Marinas wrote:

Show 7 quoted lines

> 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

Looks useful.

But what exactly is "rebasecmd" useful for, when you already have "fetchcmd" and a built-in rebase?

Show 11 quoted lines

> 2008/6/7 Karl Hasselström <kha@treskal.com>:
>
> > 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.

Yes. We could have "stg rebase" == "stg pull --rebase --no-fetch".

Show 7 quoted lines

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

These two things are orthogonal:

  1. Whether and how to update the branch we're pulling from
     (fetching).

  2. How to do the actual pulling (rebase, fast-forward, or merge).

I envision (1) being controlled by the branch config (and overridable with a --no-fetch option or something), and (2) being controlled by another part of the branch config (and overridable with --fast-forward, --merge, and --rebase).

Show 12 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.

Why? I don't see the difference between rebase and the other two that would motivate such a separation.

-- 
Karl Hasselström, kha@treskal.com
      www.treskal.com/kalle