Re: stg pull/rebase

["Catalin Marinas" <catalin.marinas@gmail.com>]

2008/6/11 Karl Hasselström <kha@treskal.com>:
> On 2008-06-10 16:43:27 +0100, Catalin Marinas wrote:
>
>> 2008/6/10 Karl Hasselström <kha@treskal.com>:
>> > 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.
>
> You most definitely can. I've been doing so daily for more than a
> year:
>
>  $ git svn fetch -q
>  $ stg rebase -m svn/branch

Maybe, I haven't tried (I just followed the git-svn documentation). Is
the imported svn history linear? If it works, I no longer have a need
for a rebasecmd option.

> The _advantage_ of having fetch be the only external command (besides
> reducing complexity) is that we can make it all one single StGit
> transaction (since the fetch runs to completion before the transaction
> starts). This means that we don't have to touch files unnecessarily,
> which means less recompilation.

That's a good reason.

>> 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).
>
> Well, the reason I proposed to keep "stg pull" rather than "stg
> rebase" is that I agree with you that "pull" means "fetch _and_
> integrate". (Let's try a new term; "integrate" means either "merge",
> "fast-forward", or "rebase" (none of which implies any fetching, of
> course).) This is how I imagine it working:
[...]
> Any of --no-fetch/--fetch-only can be combined with any of
> --fast-forward/--rebase/--merge.
>
> If stg pull is given a committish argument, this automatically means
> --no-fetch, and causes it to integrate with that committish rather
> than the branch specified in the config. We might want to allow other
> kinds of arguments as well, I don't know.
>
> And of course,
>
>  stg rebase [committish]
>
>    The same as "stg pull --no-fetch --rebase [committish]"; that is,
>    no fetch, just rebase.

I'm OK, as long as we keep a "rebase" alias :-)

>> 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
>> :-)).
>
> Mph, I don't know about me being "closer". I thought you were the one
> living in the UK? ;-)

I was more thinking about the native language roots (Germanic vs Latin
in my case, I've only lived in the UK for 7 years) :-)

> Regardless, I don't think we're actually in disagreement -- as I
> understand it, we both think that pull = fetch + integrate. And
> "rebase" is one possible value of "integrate".

I think the disagreement is that I consider "fetch" in the above
equality to be mandatory. But I think your proposal is OK.

-- 
Catalin