Re: stg pull/rebase

On 2008-06-10 16:43:27 +0100, Catalin Marinas wrote:

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

quoted

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

quoted

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.

You most definitely can. I've been doing so daily for more than a
year:

  $ git svn fetch -q
  $ stg rebase -m svn/branch

I _think_ what git svn rebase does is look at the git-svn commit
metadata to determine how many commits to rebase. But stg already has
this information, so we don't need it. (I haven't actually looked into
exactly what git svn rebase does, so it might turn out it's doing
something else too, but I can't think of anything that would be
necessary. As I said, I've been using this workflow for a long time,
and it works.)

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.

quoted

quoted

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

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:

  stg pull

    Do a default fetch (that is, fetch according to the branch
    config), followed by a default integrate.

  stg pull --no-fetch

    Just a default integrate, no fetch.

  stg pull --fetch-only

    Just a default fetch, no integrate.

  stg pull --fast-forward

    Default fetch, followed by a "fast-forward" integrate.

  stg pull --rebase

    Default fetch, followed by a "rebase" integrate.

  stg pull --merge

    Default fetch, followed by a "merge" integrate.

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.

quoted

quoted

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

Mph, I don't know about me being "closer". I thought you were the one
living in the UK? ;-)

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". (Holler if you disagree
with either of the views I've attributed to you.)

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