Re: Rebasing stgit stacks

[Yann Dirson <ydirson@altern.org>]

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

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.


> > "stg pull", after popping all patches, currently calls "git pull",
> > which indeed has 2 roles:
> >
> >- running "git fetch" on the parent branch
> >- updating the head of the stack (which matches the base since
> >  no patch is applied), by relying on git-pull to fast-forward the
> >  stack head
> 
> 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 :)

> >The latter is, unless I miss something:
> >
> >- overkill when what we want is just to move the head to another place
> 
> Doesn't git automatically detect that it can do a fast forward? A
> fetch is still necessary anyway.

Yes, it detects it when it is one.  The problem is merely that it
can break things (for stgit's purpose) when it isn't.

> I'm not sure how people intend to use StGIT. Some might have their own
> changes to the base of the stack (maybe caused by 'stg commit') and
> would want 'git pull' to do a proper merge and not just fast-forward.
> 
> I actually did the above when maintaining a public (well, ARM internal
> only currently) kernel branch for other people to pull from. Since
> StGIT is not public branch friendly,

Making StGIT public-branch friendly is indeed the primary goal for
this set of patches - it is much less important to me to be able to
base my stack on GIT's "pu" or "next".

The idea is that, once we have are able to rebase a stack anyway,
rebasing to the new tip of a branch that is an StGIT stack is in many
aspects only a particular case (modulo any unapplied patches).


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


> >- problematic when the parent branch is one that would be tracker with
> >"+" in the remote pull line (eg. "next", "pu", or an stgit stack).  In
> >that case, although "git fetch" refuses to update the parent head
> >because it would not be a fast-forward, git-pull then attempt to do a
> >merge, which completely breaks expectations.
> 
> Is there any way to configure git (via gitconfig) to behave
> differently? You can add some per-branch options with the parent to
> pull from but this would require separate .git/remotes/ files for each
> branch.

I'm not sure there is anything currently.  The solution which I
remember was proposed was that such a branch "advertises" its status
in some way, so that the creator of the remote.<name>.fetch config
entry can indeed insert the "+" itself automatically.

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 ?


> The switch() function already calls __set_head()

Yup, noticed that when running the testsuite - I meant to run switch
then reset instead.


> >    if os.path.isfile(os.path.join(basedir.get(), 'MERGE_HEAD')):
> >        os.remove(os.path.join(basedir.get(), 'MERGE_HEAD'))
> 
> When is the MERGE_HEAD file generated? Is there any harm in leaving this 
> file?

This is a leftover from sources of inspiration that create_branch and
switch_branch were.  I'm not 100% sure of why we want to get rid of
it, but it looked like the situation was similar enough.

It is apparently generated by git-merge (and git-resolve), and
currently out of the scope of stgit anyway.  If we're moving our
stack, it is probable it will loose any sort of accurateness.

Maybe instead we would want to block stgit operations if we see it,
because there certainly have been (illegal ?) operations done outside
of StGIT.


> >I would be of the opinion to stop calling "git pull" entirely, and use
> >"git fetch and the git.move_branch show above.  Unless I hear about
> >better ideas, my next patch set will be along those lines.
> 
> Or replace the 'git pull' in the config file with 'git fetch && git
> reset --hard MERGE_HEAD'? I might be wrong though as I almost never
> use git directly :-).

Hm.  Probably rather FETCH_HEAD.  Will have to look at that - but see
above.

FWIW, I now mostly have a patch to change from git-pull to git-fetch,
which finally passes the current testsuite.

Note that I did not think of using FETCH_HEAD, I was rather thinking
of using information about the parent branch (which I had worked on
recently), with the idea that this info probably belongs to
branch.<name>.merge - which would complement Pavel's 87c69539 about
branch.<name>.remote.

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

Best regards,
-- 
Yann.