From: Catalin Marinas Date: Thu, 18 Jan 2007 09:05:47 GMT Subject: Re: Rebasing stgit stacks Message-ID: In-Reply-To: <20070116231735.GF7029@nan92-1-81-57-214-146.fbx.proxad.net> On 16/01/07, Yann Dirson wrote: > My example is quite similar to the one given by Guilhem: I had a git > branch coming from git-cvsimport, and my stgit stack forked atop that > branch. At some point git-cvsimport fucked something, and I > regenerated a new mirror branch using it in a fresh repo. Then I > wanted to rebase my stack on that new branch. As Jakub said, I would also call this command 'rebase' instead of 'pull --to', even if we duplicate a bit of code. It would make the implementation even simpler as you won't break other people's workflows using git-pull or cg-pull. The main feature of the 'pull' command is to fetch the latest changes from a remote repository and merge (fast-forward) them into current base. > > But you want to replace the call to 'git pull' with 'git fetch'. I > > think this is fine with my workflow but some people might actually > > rely on calling 'git pull' (or cg-pull). > > Right, it may be possible (and I'd be interested in seeing such a > workflow). Maybe we could keep support for git-pull as an > alternative. As I said, I use this myself on an exported branch. > This could be done, eg. by letting the user use "pullcmd=git-pull" and > introduce a new option like "fastforward=" triggering the > fast-forward needed after git-fetch, with the default being "true", > and the current behaviour being obtained by changing it to "false". But isn't this too complicated when all you need is a 'rebase'-like command? > That would not add too much complexity, while setting the default to > what I believe to match the most common workflows, and allow anyone > relying on the current behaviour to get it back. The problem is that I may use different workflows in the same repository (but on different branches). Any new config options would have to be per branch. -- Catalin