Re: stg pull/rebase

From: Catalin Marinas <catalin.marinas@gmail.com>
Date: Jun 10, 2008, 15:43 UTC
Message-ID: <b0943d9e0806100843j28bb3353y5889a50712377959@mail.gmail.com>
In-Reply-To: <20080610104244.GC30119@diana.vm.bytemark.co.uk>

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

Show 14 quoted lines

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

In case the built-in rebase is not enough. Can you use "git svn fetch" followed by plain "git rebase"? There are some comments in git-svn.txt that recommend to use "git svn rebase" to preserve linear history.

Show 15 quoted lines

>> 2008/6/7 Karl Hasselström <kha@treskal.com>:
>> >      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 think it's more of an language interpretation issue (I'm not a native English speaker). I see the "pull" action as pulling (can't find meaningful synonyms) remote changes into the current branch (i.e. fetch + merge). I think you see it as pulling the current stack onto a new base (i.e. rebase).

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

OK.

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

See my interpretation of the word "pull". I can change my mind, no problem, but it would be interesting to see what a native English speaker says (though you are probably closer to English than me :-)).

-- 
Catalin