Re: Rebasing stgit stacks

[Yann Dirson <ydirson@altern.org>]

On Tue, Jan 16, 2007 at 10:42:17PM +0000, Catalin Marinas wrote:
> >The idea is that we pull our stack from one place (current base) to
> >another.  Another possiblity would have been "stg rebase", but I'm not
> >very keen on adding another command to do a very similar job.
> 
> Can you give a typical example of what <newbase> argument for --to is
> and what you repository looks like? I just want make sure I correctly
> understand the problem.

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.


> I see the 'pull' command as a way to fetch the latest remote changes
> and merge them into the current branch (which would usually be a
> fast-forward). This command was meant as a stgit-aware 'git pull'.

Do you have an example of use where we would need a non-fast-forward
pull (supposing we have the "pull --to" functionality already, since I
shall find time to finish soon).


> >> As Petr suggested at the OLS last year, I added the possibility to
> >> configure the 'git pull' command so that people use whatever script
> >> they like.
> >
> >Right.  Maybe different workflows should have this option set to
> >different values in different repos ?  I'm merely trying to get the
> >best default :)
> 
> 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.

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.


> >> I was working on a set of patches (mainly picking from other
> >> branches and minor modifications) and just committing them when
> >> finishing. Further updates from kernel.org triggered full merges
> >> with the base.
> >
> >But doing this means that you can end with a base that is not any more
> >on the parent branch, but on a local merge, right ?  I'm not sure it
> >is an easy thing to work with.
> 
> Yes, indeed, but this is probably the only way you can publish a
> branch and still partially manage it with StGIT.

Well, I'd think that automatic rebasing would be a more elegant
solution.

> >On the StGIT front, we could have "stg clone" look at
> >patches/<branch>/current or so, and then modify the
> >remote.<name>.fetch entry accordingly.  Or do you think of any
> >workflow that would break under this change ?
> 
> Currently, 'stg clone' just calls 'git clone' and initializes the
> master branch. There is no patches/<branch>/current file as there is
> no current patch.

I meant, the patches/<branch>/current in the remote repo.  If that one
exist, then we should pull it with "+" as we should do for any
rebasing remote branch.

> >Even if we would not need it here, it would be good to have those 2
> >parameters set when we can infer them.  That reminds me that "stg
> >clone" does not appear to allow selecting a specific branch in the
> >parent repo (which explains why the .merge parameter is not so
> >crucially needed yet: we always clone the main branch).
> 
> I haven't looked at 'git clone' recently, can you select a specific branch?

I had assumed so without looking, but it looks like you cannot select
much.  When using separate remotes, the HEAD in the clone is taken
from the HEAD in the remote, and bears the same name.  It is the only
ref created under heads/.

Would there be some missing functionnality in git-clone, or am I just
missing something obvious ?

Best regards,
-- 
Yann.