git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Daniel Barkalow <barkalow@iabervon.org>
To: Jonathan Nieder <jrnieder@gmail.com>
Cc: Ramkumar Ramachandra <artagnon@gmail.com>,
	Git List <git@vger.kernel.org>,
	Christian Couder <chriscool@tuxfamily.org>
Subject: Re: [RFC PATCH 00/11] Sequencer Foundations
Date: Sun, 10 Apr 2011 21:16:44 -0400 (EDT)	[thread overview]
Message-ID: <alpine.LNX.2.00.1104102028240.14365@iabervon.org> (raw)
In-Reply-To: <20110410194739.GC28163@elie>

On Sun, 10 Apr 2011, Jonathan Nieder wrote:

> > 3. From the format of the TODO and DONE files, one more thing should
> > be clear- I'm trying to stick to a slight variation of the 'rebase -i'
> > format.  This part will go into the sequencer.  Then I'll use a
> > cherry-pick specific file to keep the command-line options.  Yes, I'm
> > trying to work on Daniel's idea [3] from the very start.  Is this a
> > good idea?
> 
> This is still bouncing in my head.  I think I like it --- is the idea
> that some day you could put commands like
> 
> 	am topic.mbox
> 
> in your insn sheet, or do nested rebases with a --force-nested option?
> That does sound useful.  How would one request "skip to the next
> operation in the outer rebase" on the command line?  This is starting
> to feel like a debugger.

The most basic idea is that, in the case of a rebase where a patch fails 
to apply, there are actually two levels of operation that have to be 
deferred until after the human intervention: making the commit where the 
pick failed, and applying further patches. If there are going to be 
multiple higher-level operations (e.g., rebase and rebase -i), they should 
be able to share the completion of the pick operation, and a basic "git 
cherry-pick <sha1>" ought to be able to share it, too, so you can finish 
that up without having to remember what the command is. People should be 
able to implement custom higher-level operations (e.g., "cherry-pick all 
the commits attached to bugs in bugzilla that block the release tracker" 
or something), they should be able to rely on library code that knows how 
to finish the conflicted cherry-pick. (Another interesting example might 
be "reconstruct the linux-next tree", which is a series of merges, and 
which should have --continue share the post-intervention code from the 
single merge process before going on to do the custom higher-level thing.)

My feeling is that "--skip" is actually "abort the pick, but continue the 
rebase". I suppose there could be more than two levels, and people could 
want to skip a higher-level chunk, but that's something to get to when 
someone actually wants it; we've obviously already got the two-level 
situation now, so we can implement that.

	-Daniel
*This .sig left intentionally blank*

  reply	other threads:[~2011-04-11  1:16 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-10 15:11 [RFC PATCH 00/11] Sequencer Foundations Ramkumar Ramachandra
2011-04-10 15:11 ` [PATCH 01/11] revert: Avoid calling die; return error instead Ramkumar Ramachandra
2011-04-10 19:14   ` Jonathan Nieder
2011-05-08 12:04     ` Ramkumar Ramachandra
2011-04-11 20:26   ` Junio C Hamano
2011-04-10 15:11 ` [PATCH 02/11] revert: Lose global variables "commit" and "me" Ramkumar Ramachandra
2011-04-11  3:24   ` Christian Couder
2011-04-11  8:57     ` Ramkumar Ramachandra
2011-04-10 15:11 ` [PATCH 03/11] revert: Introduce a struct to parse command-line options into Ramkumar Ramachandra
2011-04-10 19:21   ` Jonathan Nieder
2011-05-08 12:18     ` Ramkumar Ramachandra
2011-04-11 21:41   ` Junio C Hamano
2011-05-08 12:09     ` Ramkumar Ramachandra
2011-04-10 15:11 ` [PATCH 04/11] revert: Separate cmdline argument handling from the functional code Ramkumar Ramachandra
2011-04-10 15:11 ` [PATCH 05/11] revert: Catch incompatible command-line options early Ramkumar Ramachandra
2011-04-11 21:44   ` Junio C Hamano
2011-05-08 11:47     ` Ramkumar Ramachandra
2011-04-10 15:11 ` [PATCH 06/11] revert: Implement parsing --continue, --abort and --skip Ramkumar Ramachandra
2011-04-10 15:11 ` [PATCH 07/11] revert: Handle conflict resolutions more elegantly Ramkumar Ramachandra
2011-04-10 15:11 ` [PATCH 08/11] usage: Introduce error_errno correspoding to die_errno Ramkumar Ramachandra
2011-04-10 15:11 ` [PATCH 09/11] revert: Write head, todo, done files Ramkumar Ramachandra
2011-04-10 15:11 ` [PATCH 10/11] revert: Give noop a default value while argument parsing Ramkumar Ramachandra
2011-04-10 15:11 ` [PATCH 11/11] revert: Implement --abort processing Ramkumar Ramachandra
2011-04-10 19:33 ` [RFC PATCH 00/11] Sequencer Foundations Daniel Barkalow
2011-04-11  8:55   ` Ramkumar Ramachandra
2011-04-10 19:47 ` Jonathan Nieder
2011-04-11  1:16   ` Daniel Barkalow [this message]
2011-04-11  6:42     ` Jonathan Nieder
2011-04-11  9:07   ` Ramkumar Ramachandra
2011-04-11  3:18 ` Christian Couder
2011-04-11  4:49   ` Ramkumar Ramachandra
2011-04-11  6:20     ` Christian Couder
2011-04-11 10:48       ` Ramkumar Ramachandra
2011-04-11  5:30   ` Daniel Barkalow
2011-04-11  5:38     ` Jonathan Nieder
2011-04-11  6:34       ` Daniel Barkalow

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.LNX.2.00.1104102028240.14365@iabervon.org \
    --to=barkalow@iabervon.org \
    --cc=artagnon@gmail.com \
    --cc=chriscool@tuxfamily.org \
    --cc=git@vger.kernel.org \
    --cc=jrnieder@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).