Re: Rebasing stgit stacks

From: Yann Dirson <ydirson@altern.org>
Date: Jan 18, 2007, 20:52 UTC
Message-ID: <20070118205233.GK9761@nan92-1-81-57-214-146.fbx.proxad.net>
In-Reply-To: <b0943d9e0701180105t7b01cb4di43b4db1fdc314bb7@mail.gmail.com>

On Thu, Jan 18, 2007 at 09:05:47AM +0000, Catalin Marinas wrote:

> But isn't this too complicated when all you need is a 'rebase'-like command?

Well, I realize that I was not very clear in all this stuff. There are indeed 3 things I'm working on, but which are closely related to each other. One is rebasing to an arbitrary point; the second is forking an stgit stack out of another (possibly remote) stgit stack; the third is that having "stg pull" use git-pull results for my workflow in a purely broken situation.

Since the 2nd is merely "git-fetch then rebase to new head of remote", and the 3rd is 100% fixed for me by using git-fetch instead of git-pull, I tend to somewhat mix all those concepts and that surely shows in my mails.

That said, let me try to detangle all this :)

Show 10 quoted lines

> 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

A new command is fine with me, it's just that I feel "rebase <target>" may be confusing to beginners. I'd rather say "rebase [<stack>] --to <target>", but it's just that I don't see the case for specifying a different stack than the current one.

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

However, this relates to the 2nd and 3rd items in my list, sorry to have brought confusion here.

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

I've heard that, but I had understood that you used this because there was nothing better available now, and that my second item (forking off a public stgit-managed branch) would address your needs. If not, I may have missed something.

Show 12 quoted lines

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

That can be a serious point. But I fear we would start to seriously over-enginneer things here - unless the workflows that really require the current behaviour are really widespread (again this assume I've correctly understood yours), wouldn't it be better to require the user to use one workflow per checkout, at least until such workflows are explicited so we can support them at best ?

BTW, I have started a couple of weeks ago to write things about patch management and associated workflows in the GIT wiki [1]. This has a wider scope than just StGIT, and I have not finished to write down everything I wanted to, but that could be a place to start from. Especially, I only listed a couple of workflows without extended description, and it would be great to have a page for each, with several ways to put them in action, with different sets of tools.

[1] http://git.or.cz/gitwiki/PatchManagement

Best regards,

-- 
Yann.