Re: Rebasing stgit stacks

From: Yann Dirson <ydirson@altern.org>
Date: Jan 15, 2007, 23:39 UTC
Message-ID: <20070115233958.GF9761@nan92-1-81-57-214-146.fbx.proxad.net>
In-Reply-To: <b0943d9e0701151446l45eff9dbgcae718c1461d0725@mail.gmail.com>

On Mon, Jan 15, 2007 at 10:46:37PM +0000, Catalin Marinas wrote:

Show 5 quoted lines

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

Show 11 quoted lines

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

Show 6 quoted lines

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

Show 7 quoted lines

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

Show 10 quoted lines

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

Show 5 quoted lines

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

Show 7 quoted lines

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