threads / patch / 9872

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

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

## tl;dr

4 messages between Sep 15, 2007 and Sep 17, 2007. Diffs are folded; open one to read it.

replies: 3people: 3as markdown or json

Karl Hasselström· Sep 15, 2007, 23:22 UTC · lore

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

Show 14 quoted lines

> 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

David Kågedal· Sep 16, 2007, 21:20 UTC · re: Karl Hasselström · lore

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

Karl Hasselström· Sep 17, 2007, 09:49 UTC · re: David Kågedal · lore

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

Show 9 quoted lines

> 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

Jon Smirl· Sep 16, 2007, 21:41 UTC · re: Karl Hasselström · lore

On 9/15/07, Karl Hasselström <kha@treskal.com> wrote:

Show 10 quoted lines

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

Show 9 quoted lines

> 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