2008/6/11 Karl Hasselström <kha@xxxxxxxxxxx>: > On 2008-06-10 16:43:27 +0100, Catalin Marinas wrote: > >> 2008/6/10 Karl Hasselström <kha@xxxxxxxxxxx>: >> > 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 -- 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
