Re: [StGit PATCH] It doesn't make sense to sink below an unapplied patch

Re: [StGit PATCH] It doesn't make sense to sink below an unapplied patch

[Karl Hasselström]

On 2007-09-14 12:18:17 -0400, Jon Smirl wrote:

> On 9/14/07, Karl Hasselström <kha@treskal.com> wrote:
>
> >   $ stg pop p2 p3
> >   $ stg push p3 p2
> >
> > Does this cover what you had in mind?
>
> Sure this works. I'm just wondering if it is a good idea to have
> separate reordering commands for patches that are applied vs
> unapplied. The separate commands confused me.
>
> Would it be better to simply prohibit reordering of apply patches
> and require that they be popped before they can be reordered? A
> sink/float that causes merge errors must be a mess to sort out.

It's not a mess, actually -- it's implemented in terms of push and pop
of single patches, so the theory is dead simple. (The push and pop
commands are also implemented in terms of push and pop of single
patches.)

> If you prohibit reordering of applied patches sink/float can be
> eliminated.

But they're useful! Though as I said earlier, they're implemented in
terms of push and pop, so they're technically redundant. But "sink p5
--to p2" would be "pop p3..p5 && push p5 p3 p4", which is more typing
(starting with applied patches p1, p2, p3, p4, p5).

> Another way to handle this would be to eliminate the ability of
> pop/push to reorder and extend sink/float to handle unapplied
> patches.

I think that I'd like the latter without the former -- that is,
teaching sink/float how to handle unapplied patches, and leaving
push/pop as is. That'll let you do what you tried to do in the first
place, and will leave us with a more redundant command set, but I
don't think that's bad.

Another idea that's been kicked around is to have a general reorder
command, that spawns an editor and lets you move around (and delete)
patch names until you're satisfied. (This too would be implemented in
terms of push and pop of single patches.)

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

Re: [StGit PATCH] It doesn't make sense to sink below an unapplied patch

[David Kågedal]

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

> Another idea that's been kicked around is to have a general reorder
> command, that spawns an editor and lets you move around (and delete)
> patch names until you're satisfied. (This too would be implemented in
> terms of push and pop of single patches.)

This of course sounds very much like "git rebase -i", but the
semantics would maybe not be identical.

One feature from rebase I'd like to see if this was implemented is the
"squash" option to join two patches.  But it would probably be called
"fold" to keep with stgit terminology.

Another way of doing this editing is to do it interactively,
interacting with the patches directly using a UI, such as an Emacs
editing mode, or a custom text or graphical UI. As you might guess,
I've been thinking a little of an Emacs interface, but nothing has
been written yet.

-- 
David Kågedal

Re: [StGit PATCH] It doesn't make sense to sink below an unapplied patch

[Karl Hasselström]

On 2007-09-16 23:20:36 +0200, David Kågedal wrote:

> Karl Hasselström <kha@treskal.com> writes:
>
> > Another idea that's been kicked around is to have a general
> > reorder command, that spawns an editor and lets you move around
> > (and delete) patch names until you're satisfied. (This too would
> > be implemented in terms of push and pop of single patches.)
>
> This of course sounds very much like "git rebase -i", but the
> semantics would maybe not be identical.

For one, the StGit version would have to update StGit's metadata. :-)

> One feature from rebase I'd like to see if this was implemented is
> the "squash" option to join two patches. But it would probably be
> called "fold" to keep with stgit terminology.

I actually started to write such a command this weekend, but I didn't
have time to finish it. I did however come to the conclusion that I'd
want to refactor the relationship between patches and commits first.
(Which was why I was so pleasantly surprised that you spent part of
the weekend doing precisely that!)

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

Re: [StGit PATCH] It doesn't make sense to sink below an unapplied patch

[Jon Smirl]

On 9/15/07, Karl Hasselström <kha@treskal.com> wrote:
> On 2007-09-14 12:18:17 -0400, Jon Smirl wrote:
> > Another way to handle this would be to eliminate the ability of
> > pop/push to reorder and extend sink/float to handle unapplied
> > patches.
>
> I think that I'd like the latter without the former -- that is,
> teaching sink/float how to handle unapplied patches, and leaving
> push/pop as is. That'll let you do what you tried to do in the first
> place, and will leave us with a more redundant command set, but I
> don't think that's bad.

The stack model may be too simplistic. My current patches involve four
groups, there is ordering in the group but the groups can be applied
independently. Patches could be marked as depending on another
patch/group. You could then mark patches applied/unapplied and stg
would sort out the order. Allowing group names would make this easier.

The mm kernel has 1,500 patches. It must be a pain trying to keep
these in a linear order.

The git diff output format could be extended with
Depends-on/Group-name lines. That would let Andrew import the
dependencies.


> Another idea that's been kicked around is to have a general reorder
> command, that spawns an editor and lets you move around (and delete)
> patch names until you're satisfied. (This too would be implemented in
> terms of push and pop of single patches.)
>
> --
> Karl Hasselström, kha@treskal.com
>       www.treskal.com/kalle
>


-- 
Jon Smirl
jonsmirl@gmail.com