Re: Rebasing stgit stacks

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

On 15/01/07, Yann Dirson <ydirson@altern.org> wrote:
> On Mon, Jan 15, 2007 at 10:46:37PM +0000, Catalin Marinas wrote:
> > >I have started work on implementing "stg pull --to <newbase>", but I'm
> > >facing some issues.
> >
> > I think the combination of 'pull' and '--to' is confusing (at least to
> > me) if you think of there English meaning.
>
> That's possible, I'm not a native english speater :)

I'm not either :-)

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

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

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

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

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

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

-- 
Catalin