Re: Rebasing stgit stacks

From: Catalin Marinas <catalin.marinas@gmail.com>
Date: Jan 18, 2007, 09:05 UTC
Message-ID: <b0943d9e0701180105t7b01cb4di43b4db1fdc314bb7@mail.gmail.com>
In-Reply-To: <20070116231735.GF7029@nan92-1-81-57-214-146.fbx.proxad.net>

On 16/01/07, Yann Dirson <ydirson@altern.org> wrote:

Show 5 quoted lines

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

Show 7 quoted lines

> > 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=<bool>" 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