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. >> 2008/6/7 Karl Hasselström <kha@xxxxxxxxxxx>: >> > 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). > 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. >> > 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
