Howto use StGit and git-svn at same time

Howto use StGit and git-svn at same time

[Guilhem Bonnefille]

Hi,

I'm a newbie and I'm using:
- git-svn to connect to a public SVN repo,
- StGit to manage my patches for the project hosted by this repo.

The current GIT repo was previously cloned from a GIT repo made with
git-cvsimport. But the project moved to SVN, so I removed the GIT repo
connected to the CVS.

I succesfully fetch the SVN, create a "work" local branch (connected
to remotes/trunk), and create some patches.
As the SVN evolved, I wish to retrieve info and update my patches.

So I tried a "stg pull" whihc failed because "origin" no more exists.
So, I tried a "git-rebase remotes/trunk".
Is it correct?

I'm actually unable to conclude, as the maintainer apply my patches
with some improves, so I have to solve lots of conflicts. But I would
appreciate if you can confirm me that the git-rebase is the good way
to update a "workspace" managed both by git-svn and StGit.

-- 
Guilhem BONNEFILLE
-=- #UIN: 15146515 JID: guyou@im.apinc.org MSN: guilhem_bonnefille@hotmail.com
-=- mailto:guilhem.bonnefille@gmail.com
-=- http://nathguil.free.fr/

Re: Howto use StGit and git-svn at same time

[Guilhem Bonnefille]

Humh...
I finished the conflicts solving game. I think the way I choosed is
incorrect. Following gitk, it is now a big big bazaar in my commits
history.

Can you give me some tips about using both git-svn and stgit please?

On 1/9/07, Guilhem Bonnefille <guilhem.bonnefille@gmail.com> wrote:
> Hi,
>
> I'm a newbie and I'm using:
> - git-svn to connect to a public SVN repo,
> - StGit to manage my patches for the project hosted by this repo.
>
> The current GIT repo was previously cloned from a GIT repo made with
> git-cvsimport. But the project moved to SVN, so I removed the GIT repo
> connected to the CVS.
>
> I succesfully fetch the SVN, create a "work" local branch (connected
> to remotes/trunk), and create some patches.
> As the SVN evolved, I wish to retrieve info and update my patches.
>
> So I tried a "stg pull" whihc failed because "origin" no more exists.
> So, I tried a "git-rebase remotes/trunk".
> Is it correct?
>
> I'm actually unable to conclude, as the maintainer apply my patches
> with some improves, so I have to solve lots of conflicts. But I would
> appreciate if you can confirm me that the git-rebase is the good way
> to update a "workspace" managed both by git-svn and StGit.
>
> --
> Guilhem BONNEFILLE
> -=- #UIN: 15146515 JID: guyou@im.apinc.org MSN: guilhem_bonnefille@hotmail.com
> -=- mailto:guilhem.bonnefille@gmail.com
> -=- http://nathguil.free.fr/
>


-- 
Guilhem BONNEFILLE
-=- #UIN: 15146515 JID: guyou@im.apinc.org MSN: guilhem_bonnefille@hotmail.com
-=- mailto:guilhem.bonnefille@gmail.com
-=- http://nathguil.free.fr/

Re: Howto use StGit and git-svn at same time

[Yann Dirson]

On Tue, Jan 09, 2007 at 10:41:20PM +0100, Guilhem Bonnefille wrote:
> Humh...
> I finished the conflicts solving game. I think the way I choosed is
> incorrect. Following gitk, it is now a big big bazaar in my commits
> history.

Right, you should not use git-rebase on a StGIT branch :)

What you should have done is moving your stack base from your old
origin branch to remotes/trunk - something that StGIT does not support
yet from command-line, but I've done this manually in the past
(migrating an StGIT stack after re-running a full git-cvsimport after
the original cvs branch got corrupted).

Something along the line of (untested, off the top of my head):

$ stg pop -a
$ echo <TARGET-SHA1>  >  .git/refs/heads/<BRANCH>
$ echo <TARGET-SHA1>  >  .git/refs/bases/<BRANCH>

And then use "stg push" and "stg resolved -i" to resolve the conflicts.

But always be sure of backing up your .git before doing such by-hand
experiments.

Best regards,
-- 
Yann.

Re: Howto use StGit and git-svn at same time

[Guilhem Bonnefille]

Ok, thanks for the reminder: I forgot "stg pop/push".

I redo whole job as this:
- git-svn -i trunk fetch
- stg pop -a
- git-rebase remotes/trunk # as recommended by git-svn manual
- stg push -a
- playing another merging game as my patches submissions were modified
since archived

Thanks.

On 1/9/07, Yann Dirson <ydirson@altern.org> wrote:
> On Tue, Jan 09, 2007 at 10:41:20PM +0100, Guilhem Bonnefille wrote:
> > Humh...
> > I finished the conflicts solving game. I think the way I choosed is
> > incorrect. Following gitk, it is now a big big bazaar in my commits
> > history.
>
> Right, you should not use git-rebase on a StGIT branch :)
>
> What you should have done is moving your stack base from your old
> origin branch to remotes/trunk - something that StGIT does not support
> yet from command-line, but I've done this manually in the past
> (migrating an StGIT stack after re-running a full git-cvsimport after
> the original cvs branch got corrupted).
>
> Something along the line of (untested, off the top of my head):
>
> $ stg pop -a
> $ echo <TARGET-SHA1>  >  .git/refs/heads/<BRANCH>
> $ echo <TARGET-SHA1>  >  .git/refs/bases/<BRANCH>
>
> And then use "stg push" and "stg resolved -i" to resolve the conflicts.
>
> But always be sure of backing up your .git before doing such by-hand
> experiments.
>
> Best regards,
> --
> Yann.
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>


-- 
Guilhem BONNEFILLE
-=- #UIN: 15146515 JID: guyou@im.apinc.org MSN: guilhem_bonnefille@hotmail.com
-=- mailto:guilhem.bonnefille@gmail.com
-=- http://nathguil.free.fr/

Rebasing stgit stacks

[Yann Dirson]

On Mon, Jan 15, 2007 at 02:26:36PM +0100, Guilhem Bonnefille wrote:
> >What you should have done is moving your stack base from your old
> >origin branch to remotes/trunk - something that StGIT does not support
> >yet from command-line, but I've done this manually in the past
> >(migrating an StGIT stack after re-running a full git-cvsimport after
> >the original cvs branch got corrupted).

I have started work on implementing "stg pull --to <newbase>", but I'm
facing some issues.

 "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

The latter is, unless I miss something:

- overkill when what we want is just to move the head to another place

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

What my implementation of "pull --to" does is just moving the head
with the following code added to git.py:

def move_branch(tree_id):
    """Move HEAD to another commit
    """
    __set_head(tree_id)
    switch(tree_id)

    if os.path.isfile(os.path.join(basedir.get(), 'MERGE_HEAD')):
        os.remove(os.path.join(basedir.get(), 'MERGE_HEAD'))


That only partly works - that is, it works if I add the expected "+"
in the remote refspec line (or if I add an explicit refspec on
command-line).  There is surely a way for "stg clone" to detect the
parent is an stgit stack, and we can possibly have the clone operation
setup things right from the start.  I remember someone suggesting that
such branches advertise their status so git-clone itself would add
this - not sure this is planned for 1.5.0, though.

Even when this fully works, I'm reluctant to leave things that way,
because would be easy to forget the --to, and get a broken stack, with
"stg diff" being confused enough to happily show this:

|bar$ stg diff; echo $?
|* Unmerged path file
|0


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.

Best regards,
-- 
Yann.

Re: Rebasing stgit stacks

[Catalin Marinas]

On 15/01/07, Yann Dirson <ydirson@altern.org> wrote:
> On Mon, Jan 15, 2007 at 02:26:36PM +0100, Guilhem Bonnefille wrote:
> > >What you should have done is moving your stack base from your old
> > >origin branch to remotes/trunk - something that StGIT does not support
> > >yet from command-line, but I've done this manually in the past
> > >(migrating an StGIT stack after re-running a full git-cvsimport after
> > >the original cvs branch got corrupted).
>
> 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.

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

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

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

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

> What my implementation of "pull --to" does is just moving the head
> with the following code added to git.py:
>
> def move_branch(tree_id):
>     """Move HEAD to another commit
>     """
>     __set_head(tree_id)
>     switch(tree_id)

The switch() function already calls __set_head()

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

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

-- 
Catalin

Re: Rebasing stgit stacks

[Yann Dirson]

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.

Re: Rebasing stgit stacks

[Catalin Marinas]

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

Re: Rebasing stgit stacks

[Yann Dirson]

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.

Re: Rebasing stgit stacks

[Jakub Narebski]

Yann Dirson wrote:

> 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'm all for calling this command "stg rebase". Currently you can do
"stg push -a; stg commit -a; git rebase; stg uncommit -n <n>"...
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: Rebasing stgit stacks

[Karl Hasselström]

On 2007-01-17 00:30:18 +0100, Jakub Narebski wrote:

> Yann Dirson wrote:
>
> > 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'm all for calling this command "stg rebase". Currently you can do
> "stg push -a; stg commit -a; git rebase; stg uncommit -n <n>"...

Or simpler,

  stg pop -a
  git reset --hard <new_base>
  stg push -n <n>

This uses stgit for all operations that can conflict.

(BTW, I've never seriously tried git rebase; does anyone have an
opinion of how convenient its conflict handling is, compared to
stgit's?)

-- 
Karl Hasselström, kha@treskal.com
      www.treskal.com/kalle

Re: Rebasing stgit stacks

[David Kågedal]

Karl Hasselström <kha@treskal.com> writes:

> On 2007-01-17 00:30:18 +0100, Jakub Narebski wrote:
>
>> Yann Dirson wrote:
>>
>> > 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'm all for calling this command "stg rebase". Currently you can do
>> "stg push -a; stg commit -a; git rebase; stg uncommit -n <n>"...
>
> Or simpler,
>
>   stg pop -a
>   git reset --hard <new_base>
>   stg push -n <n>
>
> This uses stgit for all operations that can conflict.
>
> (BTW, I've never seriously tried git rebase; does anyone have an
> opinion of how convenient its conflict handling is, compared to
> stgit's?)

I have used it a little (together with git-svn), and one thing that
confused me was that when I got a conflict to resolve, it looked like
this:

    ...
    <<<<<<
    base version
    ======
    my version
    >>>>>>
    ...

Where "my version" is the code in the branch I'm rebasing, and
"base version" is the code in the branch I'm rebasing on.

This is kind of opposite of how e.g. "git pull" works, where the first
alternative is "my version".  I guess it is an effect of the fact that
you are actually merging your branch into another, instead of the
other way around.

-- 
David Kågedal

Re: Rebasing stgit stacks

[Yann Dirson]

On Wed, Jan 17, 2007 at 10:03:13AM +0100, Karl Hasselström wrote:
> (BTW, I've never seriously tried git rebase; does anyone have an
> opinion of how convenient its conflict handling is, compared to
> stgit's?)

When I was using it, it was much less convenient than stgit - required
to forge a git-am command-line to continue after a conflict
(--continue was added in April '06 - I had switched to StGIT before
implementing it myself ;).  My evaluation at that point was that it
required too much understanding of the plumbing issues to be shown to
a newbie - a problem which StGIT does not have.  But I have not used
it any more since then, and did not follow any improvements in this
field.

StGIT features like "push --undo" also make it much easier to delay
merge of a given patch, and stack handling makes it easier to continue
your work after a night-break.  Not to mention all goodies like patch
reordering.

Best regards,
-- 
Yann.

Re: Rebasing stgit stacks

[Yann Dirson]

On Wed, Jan 17, 2007 at 12:30:18AM +0100, Jakub Narebski wrote:
> I'm all for calling this command "stg rebase".

After all, my current implementation as "pull --to" mostly bypasses
the fetch, so it probably makes sense to use a new command.

However, "stg rebase <target>" does not sound right.  I'm not very
happy with "stg rebaseto <target>" (or rebase-to) either.
"stg rebase --to <target>" may feel strange too (command without
non-option arg), but may finally a good choice after all ?  What do
others think ?

Best regards,
-- 
Yann.

Re: Rebasing stgit stacks

[Yann Dirson]

On Tue, Jan 16, 2007 at 12:39:58AM +0100, Yann Dirson wrote:
> > >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.
[...]
> 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.

Unfortunately, using "reset('FETCH_HEAD')" or similar would not work.
Eg, in the case we have cloned an stgit branch as "origin", and the
revspec does not have a "+", git-fetch after a patch refresh in the
remote repo still updates FETCH_HEAD even if it notices it cannot then
fast-forward.  With this we would end up with the "origin" branch not
being changed, and our stack still being rebased as if we had a "+"
refspec, which would be quite inconsistent.

Best regards,
-- 
Yann.

Re: Rebasing stgit stacks

[Catalin Marinas]

On 16/01/07, Yann Dirson <ydirson@altern.org> wrote:
> 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.

As Jakub said, I would also call this command 'rebase' instead of
'pull --to', even if we duplicate a bit of code. It would make the
implementation even simpler as you won't break other people's
workflows using git-pull or cg-pull. The main feature of the 'pull'
command is to fetch the latest changes from a remote repository and
merge (fast-forward) them into current base.

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

As I said, I use this myself on an exported branch.

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

But isn't this too complicated when all you need is a 'rebase'-like command?

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

The problem is that I may use different workflows in the same
repository (but on different branches). Any new config options would
have to be per branch.

-- 
Catalin

Re: Rebasing stgit stacks

[Catalin Marinas]

Yann Dirson <ydirson@altern.org> wrote:
> On Wed, Jan 17, 2007 at 12:30:18AM +0100, Jakub Narebski wrote:
>> I'm all for calling this command "stg rebase".
>
> After all, my current implementation as "pull --to" mostly bypasses
> the fetch, so it probably makes sense to use a new command.
>
> However, "stg rebase <target>" does not sound right.  I'm not very
> happy with "stg rebaseto <target>" (or rebase-to) either.

I think something 'stg rebase <newbase>' sounds OK.

-- 
Catalin

Re: Rebasing stgit stacks

[Yann Dirson]

On Thu, Jan 18, 2007 at 12:06:20PM +0000, Catalin Marinas wrote:
> Yann Dirson <ydirson@altern.org> wrote:
> > On Wed, Jan 17, 2007 at 12:30:18AM +0100, Jakub Narebski wrote:
> >> I'm all for calling this command "stg rebase".
> >
> > After all, my current implementation as "pull --to" mostly bypasses
> > the fetch, so it probably makes sense to use a new command.
> >
> > However, "stg rebase <target>" does not sound right.  I'm not very
> > happy with "stg rebaseto <target>" (or rebase-to) either.
> 
> I think something 'stg rebase <newbase>' sounds OK.

It's just that it sounds more natural to me to give as instruction "do
rebase (current stack) to that point" than "do rebase that point",
which "rebase <newbase>" would seem to imply.

Best reagards,
-- 
Yann.

Re: Rebasing stgit stacks

[Yann Dirson]

On Thu, Jan 18, 2007 at 09:05:47AM +0000, Catalin Marinas wrote:
> But isn't this too complicated when all you need is a 'rebase'-like command?

Well, I realize that I was not very clear in all this stuff.  There
are indeed 3 things I'm working on, but which are closely related to
each other.  One is rebasing to an arbitrary point; the second is
forking an stgit stack out of another (possibly remote) stgit stack;
the third is that having "stg pull" use git-pull results for my
workflow in a purely broken situation.

Since the 2nd is merely "git-fetch then rebase to new head of remote",
and the 3rd is 100% fixed for me by using git-fetch instead of
git-pull, I tend to somewhat mix all those concepts and that surely
shows in my mails.

That said, let me try to detangle all this :)

> On 16/01/07, Yann Dirson <ydirson@altern.org> wrote:
> >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.
> 
> As Jakub said, I would also call this command 'rebase' instead of
> 'pull --to', even if we duplicate a bit of code.
> It would make the implementation even simpler

A new command is fine with me, it's just that I feel "rebase <target>"
may be confusing to beginners.  I'd rather say "rebase [<stack>] --to
<target>", but it's just that I don't see the case for specifying a
different stack than the current one.


> as you won't break other people's workflows using git-pull or
> cg-pull. The main feature of the 'pull' command is to fetch the
> latest changes from a remote repository and merge (fast-forward)
> them into current base.

However, this relates to the 2nd and 3rd items in my list, sorry to
have brought confusion here.


> >> 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.
> 
> As I said, I use this myself on an exported branch.

I've heard that, but I had understood that you used this because there
was nothing better available now, and that my second item (forking off
a public stgit-managed branch) would address your needs.  If not, I
may have missed something.


> >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.
> 
> The problem is that I may use different workflows in the same
> repository (but on different branches). Any new config options would
> have to be per branch.

That can be a serious point.  But I fear we would start to seriously
over-enginneer things here - unless the workflows that really require
the current behaviour are really widespread (again this assume I've
correctly understood yours), wouldn't it be better to require the user
to use one workflow per checkout, at least until such workflows are
explicited so we can support them at best ?

BTW, I have started a couple of weeks ago to write things about patch
management and associated workflows in the GIT wiki [1].  This has a
wider scope than just StGIT, and I have not finished to write down
everything I wanted to, but that could be a place to start from.
Especially, I only listed a couple of workflows without extended
description, and it would be great to have a page for each, with
several ways to put them in action, with different sets of tools.

[1] http://git.or.cz/gitwiki/PatchManagement

Best regards,
-- 
Yann.

Re: Rebasing stgit stacks

[Jakub Narebski]

On Wed, Jan 17, 2007 Yann Dirson wrote:
> On Wed, Jan 17, 2007 at 12:30:18AM +0100, Jakub Narebski wrote:

>> I'm all for calling this command "stg rebase".
> 
> After all, my current implementation as "pull --to" mostly bypasses
> the fetch, so it probably makes sense to use a new command.
> 
> However, "stg rebase <target>" does not sound right.  I'm not very
> happy with "stg rebaseto <target>" (or rebase-to) either.
> "stg rebase --to <target>" may feel strange too (command without
> non-option arg), but may finally a good choice after all ?  What do
> others think ?

First, "stg rebase" when on some git branch might mean rebase StGIT
stack to head of current branch (because there were some git commits
on top of this branch). So it would be "stg rebase [--onto <target>]";
it would be command without non-option arg, but this arg would be
optional.

Second, if you were to implement separating commands into subcommands
(perhaps just as alternative names) depending on what they act on:
"stg stack <subcommand>", "stg patch <subcommand>" etc., this would
I think belong to "stg base <subcommand>".
-- 
Jakub Narebski
Poland

Re: Rebasing stgit stacks

[Jakub Narebski]

Yann Dirson wrote:
> On Thu, Jan 18, 2007 at 09:05:47AM +0000, Catalin Marinas wrote:

>> As Jakub said, I would also call this command 'rebase' instead of
>> 'pull --to', even if we duplicate a bit of code.
>> It would make the implementation even simpler
> 
> A new command is fine with me, it's just that I feel "rebase <target>"
> may be confusing to beginners.  I'd rather say "rebase [<stack>] --to
> <target>", but it's just that I don't see the case for specifying a
> different stack than the current one.

If you want to move some stack from one branch to other, for example
from 'next' or next-based branch to 'origin'/'master' or origin-based
branch you could do either:

  $ git checkout <newbase>
  $ stg rebase <stack>

or

  $ git checkout <oldbase>
  $ stg rebase --onto <newbase>

(or even "stg rebase <stack> --onto <newbase>" or "stg rebase 
--onto <newbase> <stack>").

Although usually you have separate branch as StGIT stack "base", and
you can simply rebase git branch, then do

  $ stg rebase

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: Rebasing stgit stacks

[Yann Dirson]

On Fri, Jan 19, 2007 at 10:40:16AM +0100, Jakub Narebski wrote:
> First, "stg rebase" when on some git branch might mean rebase StGIT
> stack to head of current branch (because there were some git commits
> on top of this branch). So it would be "stg rebase [--onto <target>]";
> it would be command without non-option arg, but this arg would be
> optional.

I'm not sure I understand.  Since the "current StGIT stack" is the one
pointed to by HEAD, how do you specify, when HEAD points to the target
branch, which stack to rebase ?

> Second, if you were to implement separating commands into subcommands
> (perhaps just as alternative names) depending on what they act on:
> "stg stack <subcommand>", "stg patch <subcommand>" etc., this would
> I think belong to "stg base <subcommand>".

Hm, the operation is not just about moving the stack base, it also has
to reapply patches, so, whereas the central concept is about moving
the base, the whole operation is indeed about the rebaseing the whole
stack.

I'm not sure we need to expose the "stack base" to the user as an
object she could manipulate all alone, I'd rather think it should only
be kept a read-only attribute of the stack, which gets changed when
the user rebases the stack.

IOW, the conceptual base object is private to the stack object, (it is
indeed just a simple text attribute) and only stack methods are
allowed to call base.move(), when they have ensured it can be done
safely (ie. popping all patches first).

Best regards,
-- 
Yann.

Re: Rebasing stgit stacks

[Jakub Narebski]

Yann Dirson wrote:
> On Fri, Jan 19, 2007 at 10:40:16AM +0100, Jakub Narebski wrote:

>> First, "stg rebase" when on some git branch might mean rebase StGIT
>> stack to head of current branch (because there were some git commits
>> on top of this branch). So it would be "stg rebase [--onto <target>]";
>> it would be command without non-option arg, but this arg would be
>> optional.
> 
> I'm not sure I understand.  Since the "current StGIT stack" is the one
> pointed to by HEAD, how do you specify, when HEAD points to the target
> branch, which stack to rebase ?

Well, I haven't thought this through. I was thinking about situation
where there are no applied patches, and some commits were done without
StGIT (pure git), i.e. we had

                  ..1...2...3  <-- unapplied (deck) [ branch ]
                 /
    a---b---c---d   <-- HEAD [ branch ]

There were some git commits (for example fetch, or cherry-pick, or ...)


                  ..1...2...3  <-- unapplied (deck) [ branch ]
                 /
    a---b---c---d---e---f   <-- HEAD [ branch ]

And after "stg rebase" I want to have:


                          ..1...2...3  <-- unapplied (deck) [ branch ]
                         /
    a---b---c---d---e---f   <-- HEAD [ branch ]


I'm not sure how should the above work with applied patches
(non-empty stack), i.e. with the following:

                          ..3...4...5  <-- unapplied (deck) [ branch ]
                         /
    a---b---c---d-.-1-.-2   <-- HEAD [ branch ]
                  \--v--/

                  (stack)  

Or for example git branch got rebased, and I want to move also deck
(unapplied patches), because "git rebase" don't move them... unless
this is not needed. Probably it is not needed.

-- 
Jakub Narebski
Poland

Re: Rebasing stgit stacks

[Yann Dirson]

On Sat, Jan 20, 2007 at 08:16:15PM +0100, Jakub Narebski wrote:
> Yann Dirson wrote:
> > On Fri, Jan 19, 2007 at 10:40:16AM +0100, Jakub Narebski wrote:
> 
> >> First, "stg rebase" when on some git branch might mean rebase StGIT
> >> stack to head of current branch (because there were some git commits
> >> on top of this branch). So it would be "stg rebase [--onto <target>]";
> >> it would be command without non-option arg, but this arg would be
> >> optional.
> > 
> > I'm not sure I understand.  Since the "current StGIT stack" is the one
> > pointed to by HEAD, how do you specify, when HEAD points to the target
> > branch, which stack to rebase ?
> 
> Well, I haven't thought this through. I was thinking about situation
> where there are no applied patches, and some commits were done without
> StGIT (pure git), i.e. we had
> 
>                   ..1...2...3  <-- unapplied (deck) [ branch ]
>                  /
>     a---b---c---d   <-- HEAD [ branch ]
> 
> There were some git commits (for example fetch, or cherry-pick, or ...)
> 
> 
>                   ..1...2...3  <-- unapplied (deck) [ branch ]
>                  /
>     a---b---c---d---e---f   <-- HEAD [ branch ]
> 
> And after "stg rebase" I want to have:
> 
> 
>                           ..1...2...3  <-- unapplied (deck) [ branch ]
>                          /
>     a---b---c---d---e---f   <-- HEAD [ branch ]

So this what we typically currently get by using "stg pull
. branchname", when HEAD is the stack branch.

I can easily see that called as "stg rebase", with --to argument
defaulting to parent branch (as given by branch.<name>.merge) when the
HEAD is the stack branch.  That would be a neat replacement for "stg
pull . <name>".

Calling 'stg rebase' from the branch to rebase onto, however, can't
guess which stack to rebase - there are possibly many stacks forked
off your branch.  In that case, you will need to ask "stg rebase
<mystack>".

But this will mean that "stg rebase <mystack>" will have --to default
to HEAD, whereas "stg rebase" will have --to default to the stack's
parent branch.  Not sure, but that looks a bit inconsistent, and may
be confusing.  But probably we can implement things this way, and wait
for the user feedback to see if some restructuration is called,
post-1.0, when we move to subcommands.


> I'm not sure how should the above work with applied patches
> (non-empty stack), i.e. with the following:
> 
>                           ..3...4...5  <-- unapplied (deck) [ branch ]
>                          /
>     a---b---c---d-.-1-.-2   <-- HEAD [ branch ]
>                   \--v--/
> 
>                   (stack)  

As long as commits occured as children of 'd', 'rebase' will take care
of applied patches (it pops all patches first).

> Or for example git branch got rebased, and I want to move also deck
> (unapplied patches), because "git rebase" don't move them... unless
> this is not needed. Probably it is not needed.

This is a typical ouse for "stg rebase", it should just work.

Best regards,
-- 
Yann.

Re: Rebasing stgit stacks

[Catalin Marinas]

Jakub Narebski <jnareb@gmail.com> wrote:
> Yann Dirson wrote:
>> On Thu, Jan 18, 2007 at 09:05:47AM +0000, Catalin Marinas wrote:
>
>>> As Jakub said, I would also call this command 'rebase' instead of
>>> 'pull --to', even if we duplicate a bit of code.
>>> It would make the implementation even simpler
>> 
>> A new command is fine with me, it's just that I feel "rebase <target>"
>> may be confusing to beginners.  I'd rather say "rebase [<stack>] --to
>> <target>", but it's just that I don't see the case for specifying a
>> different stack than the current one.
>
> If you want to move some stack from one branch to other, for example
> from 'next' or next-based branch to 'origin'/'master' or origin-based
> branch you could do either:
>
>   $ git checkout <newbase>
>   $ stg rebase <stack>

Currently, in the StGIT terminology stack and branch are about the
same. If you want to move to a different stack, just use the "stg
branch" command.

I think this should stay as it is since it gets confusing to have a
name for a stack and a different name for a branch. A stack is just a
branch with stgit-specific metadata.

If <newbase> is a branch and 'git checkout' causing to switch
branches, you end up on a different stack.

What you'd probably want is a way to import patches from a different
branch/stack onto the newly checked out branch.

> Although usually you have separate branch as StGIT stack "base", and
> you can simply rebase git branch, then do
>
>   $ stg rebase

I only see the 'rebase' command as a shortcut for:

stg pop -a
git reset --hard <newbase>
stg push -a (or just push the previously popped patches)

-- 
Catalin

P.S. could you cc me to your replies as I only read the GIT mailing
list via gmane and only when I'm at work (and usually work on StGIT at
home)

Re: Rebasing stgit stacks

[Yann Dirson]

On Mon, Jan 22, 2007 at 05:54:29PM +0000, Catalin Marinas wrote:
> Jakub Narebski <jnareb@gmail.com> wrote:
> > Yann Dirson wrote:
> >> On Thu, Jan 18, 2007 at 09:05:47AM +0000, Catalin Marinas wrote:
> >
> >>> As Jakub said, I would also call this command 'rebase' instead of
> >>> 'pull --to', even if we duplicate a bit of code.
> >>> It would make the implementation even simpler
> >> 
> >> A new command is fine with me, it's just that I feel "rebase <target>"
> >> may be confusing to beginners.  I'd rather say "rebase [<stack>] --to
> >> <target>", but it's just that I don't see the case for specifying a
> >> different stack than the current one.
> >
> > If you want to move some stack from one branch to other, for example
> > from 'next' or next-based branch to 'origin'/'master' or origin-based
> > branch you could do either:
> >
> >   $ git checkout <newbase>
> >   $ stg rebase <stack>
> 
> Currently, in the StGIT terminology stack and branch are about the
> same. If you want to move to a different stack, just use the "stg
> branch" command.

I think you missed the point.  StGIT stacks are usually forked off
another branch.  As I understand it, Jakub talks about standard
rebasing, ie. moving the stack base from its current parent branch to
a new one.


> A stack is just a branch with stgit-specific metadata.

I would rather say that an StGIT stacks uses a branch, but the stack
is not the branch - eg, unapplied patches do not belong to the branch.

Indeed I was thinking about that today, and thought that maybe it
would make sense not to use a head ref (and thus not using a real
branch), which would minimize the risk of someone committing by error
(and thus minimize the need to use "assimilate"), since porcelainish
commit tools would then refuse to commit there.


> What you'd probably want is a way to import patches from a different
> branch/stack onto the newly checked out branch.

Sometimes you just want to throw out an obsolete branch and move your
stack to a new baseline.  That said, being able to duplicate a stack
(and possibly rebasing it afterwards) would be useful as well.


> > Although usually you have separate branch as StGIT stack "base", and
> > you can simply rebase git branch, then do
> >
> >   $ stg rebase

Oh, I think I understand - he probably uses "base" to refer to what I
call "parent branch", and not to the refs/bases/<branch> reference...

Best regards,
-- 
yann.

Re: Rebasing stgit stacks

[Catalin Marinas]

On 22/01/07, Yann Dirson <ydirson@altern.org> wrote:
> On Mon, Jan 22, 2007 at 05:54:29PM +0000, Catalin Marinas wrote:
> > Currently, in the StGIT terminology stack and branch are about the
> > same. If you want to move to a different stack, just use the "stg
> > branch" command.
>
> I think you missed the point.  StGIT stacks are usually forked off
> another branch.  As I understand it, Jakub talks about standard
> rebasing, ie. moving the stack base from its current parent branch to
> a new one.

StGIT stacks are a series of volatile commits (commits) at the top of
a branch. The idea when I started writing this tool was that a series
of applied patches would lead to the head of the current branch. The
branch and stack are tightly coupled and you cannot simply change the
parent branch the stack is based on (not from a technical point but
rather from conception one).

> > A stack is just a branch with stgit-specific metadata.
>
> I would rather say that an StGIT stacks uses a branch, but the stack
> is not the branch - eg, unapplied patches do not belong to the branch.

The unapplied patches can have any commit as a parent, either in the
direct history of the current branch or in any other branch, there is
no restriction here. They get in line with the current branch's head
during the push operation.

> Indeed I was thinking about that today, and thought that maybe it
> would make sense not to use a head ref (and thus not using a real
> branch), which would minimize the risk of someone committing by error
> (and thus minimize the need to use "assimilate"), since porcelainish
> commit tools would then refuse to commit there.

But isn't this what Quilt already does (i.e. a different mechanism for
patches, on top of any SCM)?

One of the base ideas of StGIT is that the top patch represents the
head of the current branch and that the patches applied on the stack
always form the recent history of the current branch. I added the
commit command to have a way to freeze this state into the current
branch and no longer manage them with StGIT.

> > What you'd probably want is a way to import patches from a different
> > branch/stack onto the newly checked out branch.
>
> Sometimes you just want to throw out an obsolete branch and move your
> stack to a new baseline.  That said, being able to duplicate a stack
> (and possibly rebasing it afterwards) would be useful as well.

You have 'branch --clone' (or --rename if you just want a different
name) and now 'rebase'. As I said, the idea of moving the stack
(patches) on top of a different branch should be done as an import (or
multiple cherry-pick or clone), otherwise we loose the coupling
between branches and stacks.

> > > Although usually you have separate branch as StGIT stack "base", and
> > > you can simply rebase git branch, then do
> > >
> > >   $ stg rebase
>
> Oh, I think I understand - he probably uses "base" to refer to what I
> call "parent branch", and not to the refs/bases/<branch> reference...

The ref/bases/<branch> is not used much in StGIT. I initially added it
as a way to see the base of a stack in gitk but that's probably the
only usecase.

-- 
Catalin

Re: Rebasing stgit stacks

[Catalin Marinas]

On 20/01/07, Jakub Narebski <jnareb@gmail.com> wrote:
> Well, I haven't thought this through. I was thinking about situation
> where there are no applied patches, and some commits were done without
> StGIT (pure git), i.e. we had
>
>                   ..1...2...3  <-- unapplied (deck) [ branch ]
>                  /
>     a---b---c---d   <-- HEAD [ branch ]
>
> There were some git commits (for example fetch, or cherry-pick, or ...)
>
>
>                   ..1...2...3  <-- unapplied (deck) [ branch ]
>                  /
>     a---b---c---d---e---f   <-- HEAD [ branch ]
>
> And after "stg rebase" I want to have:
>
>
>                           ..1...2...3  <-- unapplied (deck) [ branch ]
>                          /
>     a---b---c---d---e---f   <-- HEAD [ branch ]

StGIT currently doesn't care whether the base of an empty stack has
changed. To get to the above graph, just use "stg push 1..3" and "stg
pop 1..3".

The unapplied patches may be disconnected from the current graph and
StGIT doesn't care about them until pushed (applied) on top of the
stack when they become part of the linear history graph. I'm not good
at ASCII graphics to show an example but, for example, as long as they
are unapplied, 1 above can have b as a parent and 2 can have e as a
parent (it all depends on when they were last pushed).

-- 
Catalin

Re: Rebasing stgit stacks

[Yann Dirson]

On Mon, Jan 22, 2007 at 10:58:41PM +0000, Catalin Marinas wrote:
> On 22/01/07, Yann Dirson <ydirson@altern.org> wrote:
> >On Mon, Jan 22, 2007 at 05:54:29PM +0000, Catalin Marinas wrote:
> >> Currently, in the StGIT terminology stack and branch are about the
> >> same. If you want to move to a different stack, just use the "stg
> >> branch" command.
> >
> >I think you missed the point.  StGIT stacks are usually forked off
> >another branch.  As I understand it, Jakub talks about standard
> >rebasing, ie. moving the stack base from its current parent branch to
> >a new one.
> 
> StGIT stacks are a series of volatile commits (commits) at the top of
> a branch. The idea when I started writing this tool was that a series
> of applied patches would lead to the head of the current branch. The
> branch and stack are tightly coupled and you cannot simply change the
> parent branch the stack is based on (not from a technical point but
> rather from conception one).

Well, that's now allowed by "rebase".

> >> A stack is just a branch with stgit-specific metadata.
> >
> >I would rather say that an StGIT stacks uses a branch, but the stack
> >is not the branch - eg, unapplied patches do not belong to the branch.
> 
> The unapplied patches can have any commit as a parent, either in the
> direct history of the current branch or in any other branch, there is
> no restriction here. They get in line with the current branch's head
> during the push operation.

Right.  I'm just emphasizing that, since they are (even temporarily)
not part of the GIT branch from a GIT point of view, but part of the
stack, the 2 concepts, while closely linked, are not strict subsets of
each other.  Rather, they share some common points, but neither would
be parent of the other in a class hierarchy.

> >Indeed I was thinking about that today, and thought that maybe it
> >would make sense not to use a head ref (and thus not using a real
> >branch), which would minimize the risk of someone committing by error
> >(and thus minimize the need to use "assimilate"), since porcelainish
> >commit tools would then refuse to commit there.
> 
> But isn't this what Quilt already does (i.e. a different mechanism for
> patches, on top of any SCM)?

I'm not sure wat you mean here.  I'm only talking of StGIT and the GIT
world here.

> One of the base ideas of StGIT is that the top patch represents the
> head of the current branch and that the patches applied on the stack
> always form the recent history of the current branch.

I'm not willing to change the concept.  I'm just wondering whether
using a non-head reference (eg. stacks/<name> or stacks/<name>/top)
would not be better.  For this we may need to consider using detached
HEAD support from 1.5.0, but I'm just thinking loudly, I have not
looked at what that thing provides exactly yet.

> I added the commit command to have a way to freeze this state into
> the current branch and no longer manage them with StGIT.


> >> What you'd probably want is a way to import patches from a different
> >> branch/stack onto the newly checked out branch.
> >
> >Sometimes you just want to throw out an obsolete branch and move your
> >stack to a new baseline.  That said, being able to duplicate a stack
> >(and possibly rebasing it afterwards) would be useful as well.
> 
> You have 'branch --clone' (or --rename if you just want a different
> name) and now 'rebase'.

D'oh.  I was probably expecting "stack --clone" or something :)

> As I said, the idea of moving the stack (patches) on top of a
> different branch should be done as an import (or multiple
> cherry-pick or clone), otherwise we loose the coupling between
> branches and stacks.

I'll have to think more about that - I'm not sure I get you point.  By
moving/cloning we keep (or could keep) the patches' history.  By
importing we cannot do that.

Best regards,
-- 
Yann.

Re: Rebasing stgit stacks

[Catalin Marinas]

On 23/01/07, Yann Dirson <ydirson@altern.org> wrote:
> On Mon, Jan 22, 2007 at 10:58:41PM +0000, Catalin Marinas wrote:
> > On 22/01/07, Yann Dirson <ydirson@altern.org> wrote:
> > The unapplied patches can have any commit as a parent, either in the
> > direct history of the current branch or in any other branch, there is
> > no restriction here. They get in line with the current branch's head
> > during the push operation.
>
> Right.  I'm just emphasizing that, since they are (even temporarily)
> not part of the GIT branch from a GIT point of view, but part of the
> stack, the 2 concepts, while closely linked, are not strict subsets of
> each other.  Rather, they share some common points, but neither would
> be parent of the other in a class hierarchy.

Indeed, but my point is that they are really tightly coupled and not
easy to disconnect in the current design. Maybe we could loose the
coupling post 1.0 but I'm not convinced it wouldn't create confusion
among users. I also don't think there would be many users wanting to
move a stack on top of a different branch when some import or multiple
cherry-picking would be enough.

> > >Indeed I was thinking about that today, and thought that maybe it
> > >would make sense not to use a head ref (and thus not using a real
> > >branch), which would minimize the risk of someone committing by error
> > >(and thus minimize the need to use "assimilate"), since porcelainish
> > >commit tools would then refuse to commit there.
> >
> > But isn't this what Quilt already does (i.e. a different mechanism for
> > patches, on top of any SCM)?
>
> I'm not sure wat you mean here.  I'm only talking of StGIT and the GIT
> world here.

I got the (wrong) impression that you'd like to disconnect StGIT
patches from GIT commits which would mean re-writing Quilt or some
other form of patch management.

> > One of the base ideas of StGIT is that the top patch represents the
> > head of the current branch and that the patches applied on the stack
> > always form the recent history of the current branch.
>
> I'm not willing to change the concept.  I'm just wondering whether
> using a non-head reference (eg. stacks/<name> or stacks/<name>/top)
> would not be better.  For this we may need to consider using detached
> HEAD support from 1.5.0, but I'm just thinking loudly, I have not
> looked at what that thing provides exactly yet.

It might be a good idea (probably post 1.0) since we have a 'commit'
command to update the head of the branch already. I'll have to think a
bit more to make sure it doesn't break existing use-cases. I also
haven't followed the detached HEAD support. StGIT currently relies on
the HEAD giving the information about the current branch.

> > As I said, the idea of moving the stack (patches) on top of a
> > different branch should be done as an import (or multiple
> > cherry-pick or clone), otherwise we loose the coupling between
> > branches and stacks.
>
> I'll have to think more about that - I'm not sure I get you point.  By
> moving/cloning we keep (or could keep) the patches' history.  By
> importing we cannot do that.

The 'pick' command could be (easily) fixed to preserve the history of
a patch (I'll add this to the todo list). The log commit would have
the picked patch's log as a parent rather than none.

StGIT grew up almost (or just 2 months behind) at the same time with
GIT with a lot experimental/prototype features implemented. Now we
probably have a lot more ideas (and users) about how we should use GIT
and StGIT and can re-design parts of StGIT to accommodate the new
use-cases. As I said, I'll first like to get a 1.0 out this spring.

-- 
Catalin

Re: Rebasing stgit stacks

[Yann Dirson]

On Tue, Jan 23, 2007 at 10:03:26PM +0000, Catalin Marinas wrote:
> >I'll have to think more about that - I'm not sure I get you point.  By
> >moving/cloning we keep (or could keep) the patches' history.  By
> >importing we cannot do that.
> 
> The 'pick' command could be (easily) fixed to preserve the history of
> a patch (I'll add this to the todo list). The log commit would have
> the picked patch's log as a parent rather than none.

Right - "branch --clone" could also use that (or maybe it does already
by design).  Together with this, "pick --fold" and possibly "sync"
(although I never used the latter so I'm not 100% sure how it works)
could register a merge, and sometime in the future we could use this
information to be able to do some merging.  I'm not going to look
into this soon, but I have this popping out regularly in my head ;)


> As I said, I'll first like to get a 1.0 out this spring.

Yes.  Maybe we should get 0.12 out of the door soon, with some more
bugs fixed.  I'm trying to finish putting out in a decent shape stuff
about parent branches, git-fetch use and the other related issues
mentionned those last days.  Maybe that will be ready before enough
bugs are squashed for 0.12, but maybe not :)

Best regards,
-- 
yann.

Re: Rebasing stgit stacks

[Catalin Marinas]

On 24/01/07, Yann Dirson <ydirson@altern.org> wrote:
> On Tue, Jan 23, 2007 at 10:03:26PM +0000, Catalin Marinas wrote:
> > >I'll have to think more about that - I'm not sure I get you point.  By
> > >moving/cloning we keep (or could keep) the patches' history.  By
> > >importing we cannot do that.
> >
> > The 'pick' command could be (easily) fixed to preserve the history of
> > a patch (I'll add this to the todo list). The log commit would have
> > the picked patch's log as a parent rather than none.
>
> Right - "branch --clone" could also use that (or maybe it does already
> by design).  Together with this, "pick --fold" and possibly "sync"
> (although I never used the latter so I'm not 100% sure how it works)
> could register a merge, and sometime in the future we could use this
> information to be able to do some merging.  I'm not going to look
> into this soon, but I have this popping out regularly in my head ;)

'sync' is still experimental. I usually have the same patches on
different branches (i.e. a stable kernel branch for customers and a
more up-to-date branch for pushing patches upstream). I wanted a way
to automatically synchronise the changes made to some patches found in
both branches. This command folds the remote patch onto the current
one using a three-way merge. If they are identical, the current patch
shouldn't change. If they are not identical, it leads to conflicts
that have to be manually solved.

> > As I said, I'll first like to get a 1.0 out this spring.
>
> Yes.  Maybe we should get 0.12 out of the door soon, with some more
> bugs fixed.  I'm trying to finish putting out in a decent shape stuff
> about parent branches, git-fetch use and the other related issues
> mentionned those last days.  Maybe that will be ready before enough
> bugs are squashed for 0.12, but maybe not :)

Maybe I'll manage to get a new release out in about a week or so.

-- 
Catalin

Re: Rebasing stgit stacks

[Yann Dirson]

On Wed, Jan 24, 2007 at 12:37:15PM +0000, Catalin Marinas wrote:
> >Right - "branch --clone" could also use that (or maybe it does already
> >by design).  Together with this, "pick --fold" and possibly "sync"
> >(although I never used the latter so I'm not 100% sure how it works)
> >could register a merge, and sometime in the future we could use this
> >information to be able to do some merging.  I'm not going to look
> >into this soon, but I have this popping out regularly in my head ;)
> 
> 'sync' is still experimental. I usually have the same patches on
> different branches (i.e. a stable kernel branch for customers and a
> more up-to-date branch for pushing patches upstream).

That sounds like a typical usecase we should document :)

> I wanted a way to automatically synchronise the changes made to some
> patches found in both branches. This command folds the remote patch
> onto the current one using a three-way merge. If they are identical,
> the current patch shouldn't change. If they are not identical, it
> leads to conflicts that have to be manually solved.

So, indeed "sync" is a kind of merge tool already.  It could be a good
start to implement merging of forked patches.  But going further would
probably require to further develop the technics to work with patches
of patches.

best regards,
-- 
Yann.

Re: Rebasing stgit stacks

[Theodore Tso]

On Mon, Jan 22, 2007 at 10:58:41PM +0000, Catalin Marinas wrote:
> StGIT stacks are a series of volatile commits (commits) at the top of
> a branch. The idea when I started writing this tool was that a series
> of applied patches would lead to the head of the current branch. The
> branch and stack are tightly coupled and you cannot simply change the
> parent branch the stack is based on (not from a technical point but
> rather from conception one).

Well, a typical use case for me is:

	stg branch master
	git pull .
	stg branch 2.6.20-rc5
	stg export -d /tmp/temp-stack
	stg branch master
	stg branch -C 2.6.20-rc6
	stg import -s /tmp/temp-stack/series 

That's because I want to keep the original patch series for
2.6.20-rc5, but I also want rebase the patch set to 2.6.20-rc6.  Is
there a better way of doing this?  

						- Ted

Re: Rebasing stgit stacks

[Yann Dirson]

On Sat, Jan 27, 2007 at 11:33:12PM -0500, Theodore Tso wrote:
> On Mon, Jan 22, 2007 at 10:58:41PM +0000, Catalin Marinas wrote:
> > StGIT stacks are a series of volatile commits (commits) at the top of
> > a branch. The idea when I started writing this tool was that a series
> > of applied patches would lead to the head of the current branch. The
> > branch and stack are tightly coupled and you cannot simply change the
> > parent branch the stack is based on (not from a technical point but
> > rather from conception one).
> 
> Well, a typical use case for me is:
> 
> 	stg branch master
> 	git pull .
> 	stg branch 2.6.20-rc5
> 	stg export -d /tmp/temp-stack
> 	stg branch master
> 	stg branch -C 2.6.20-rc6

You mean lowercase "-c", right ?

> 	stg import -s /tmp/temp-stack/series 
> 
> That's because I want to keep the original patch series for
> 2.6.20-rc5, but I also want rebase the patch set to 2.6.20-rc6.  Is
> there a better way of doing this?  

Yes.  First, you can clone your stack:

stgit$ stg branch --clone copy
Cloning current branch to "copy"... done
stgit$ stg branch -l
Available branches:
> s     copy    | clone of "master"
  s     master  | 
        origin  | 

And then you can rebase the clone, either with "stg rebase" (in stg
HEAD only), or use the small tip described at
http://git.or.cz/gitwiki/GitTips#head-8e71c3bdda0c372b79e33f5a3fedaf22c4c6f944

Best regards,
-- 
Yann.

Re: Rebasing stgit stacks

[Catalin Marinas]

On 28/01/07, Theodore Tso <tytso@mit.edu> wrote:
> Well, a typical use case for me is:
>
>         stg branch master
>         git pull .
>         stg branch 2.6.20-rc5
>         stg export -d /tmp/temp-stack
>         stg branch master
>         stg branch -C 2.6.20-rc6
>         stg import -s /tmp/temp-stack/series
>
> That's because I want to keep the original patch series for
> 2.6.20-rc5, but I also want rebase the patch set to 2.6.20-rc6.  Is
> there a better way of doing this?

As Yann pointed out, you could just clone 2.6.20-rc5 into 2.6.20-rc6
and rebase the latter (currently with 'stg rebase v2.6.20-rc6').

If you have the branches already created, you can avoid the
export/import with a cherry-pick (with better merging than just
applying a patch). The 'pick' command only takes an argument (I'd like
to extend it to accept multiple or patch ranges) but you can use it
with 'series':

stg branch 2.6.20-rc6
stg series -b 2.6.20-rc5 --noprefix --showbranch [patches...] \
  | xargs -rn1 stg pick

You could even use the --missing instead of -b for the series command.
This option shows the patches on the remote branch which are missing
in current. Pretty useful if you want to continue importing after
fixing a conflict for example (that's a reason why I haven't extended
'pick' yet, 'series -m' seemed pretty powerful).

Another trick if you modify some patches in one branch (i.e.
2.6.20-rc5) is to use 'stg sync -b 2.6.20-rc5 [patches]' in the other
branch. It tries a three-way merge of each individual patch with the
corresponding one in the other branch, showing you any possible
conflicts (I usually have 'imerger' set to emacs... and 'autoimerge'
to 'yes' in the config file so that emacs' ediff is automatically
invoked for every conflict).

-- 
Catalin