On 2008-06-10 16:43:27 +0100, Catalin Marinas wrote:
> 2008/6/10 Karl Hasselström <kha@xxxxxxxxxxx>:
>
> > 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.
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.
> > > 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.
> > > 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@xxxxxxxxxxx
www.treskal.com/kalle
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
