Re: stg pull/rebase

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

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?

2008/6/7 Karl Hasselström [off-list ref]:

quoted

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".

quoted

     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).

quoted

        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