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

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

quoted text
> 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.

quoted text
>> >         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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html