Re: Rebasing stgit stacks

["Catalin Marinas" <catalin.marinas@gmail.com>]

On 16/01/07, Yann Dirson <ydirson@altern.org> 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=<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