Re: Rebasing stgit stacks

From: Catalin Marinas <catalin.marinas@gmail.com>
Date: Jan 16, 2007, 22:42 UTC
Message-ID: <b0943d9e0701161442t6b93e0d6nd88364600f2809ee@mail.gmail.com>
In-Reply-To: <20070115233958.GF9761@nan92-1-81-57-214-146.fbx.proxad.net>

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

Show 8 quoted lines

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

Show 7 quoted lines

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

Show 8 quoted lines

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

Show 5 quoted lines

> 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