From: Jonathan Nieder <jrnieder@gmail.com>
To: Ramkumar Ramachandra <artagnon@gmail.com>
Cc: Git List <git@vger.kernel.org>,
Christian Couder <chriscool@tuxfamily.org>,
Daniel Barkalow <barkalow@iabervon.org>,
Junio C Hamano <gitster@pobox.com>
Subject: Re: [PATCH 0/8] Sequencer Foundations
Date: Wed, 11 May 2011 08:14:26 -0500 [thread overview]
Message-ID: <20110511131356.GI2676@elie> (raw)
In-Reply-To: <1305100822-20470-1-git-send-email-artagnon@gmail.com>
Ramkumar Ramachandra wrote:
> I've not attempted to add anything new in this series -- It merely
> fixes all the mistakes in the previous iteration. I've tried to
> integrate the improvements suggested by all the previous reviews.
Thanks! This is much more readable, probably because of the commit
messages. ;-)
> All tests pass in all patches, and I hope no
> stray lines have travelled b/w the patches during the rebase.
Speaking of which, some tests and documentation would be nice as icing
on the cake.
> Ramkumar Ramachandra (8):
> revert: Improve error handling by cascading errors upwards
> revert: Make "commit" and "me" local variables
> revert: Introduce a struct to parse command-line options into
> revert: Separate cmdline argument handling from the functional code
> revert: Catch incompatible command-line options early
> revert: Introduce head, todo, done files to persist state
> revert: Implement parsing --continue, --abort and --skip
> revert: Implement --abort processing
The heart is patch 6/8. I have not thought about this deeply yet, but
I wonder if it would be simpler if the behavior of "git cherry-pick
1..10" looked like this:
. if there is state in .git/sequencer already, error out
. lock .git/sequencer/head with the lockfile API to prevent
concurrent access
. write current state, including remaining commits to cherry-pick
. unlock .git/sequencer/head
. cherry-pick commit #1
. lock sequencer, check state, update state, unlock
. cherry-pick commit #2
...
This way, even if cherry-picking causes git to segfault, the sequencer
state is in good order and we know where to pick up. More
importantly, massive refactoring of the merge_recursive API would not
be needed to keep everything in working order. An atexit and sigchain
handler could be added to print advice for the reader about how to
resume, but that's just an extra hint and it's okay if it sometimes
doesn't happen sometimes.
What do you think?
Ciao,
Jonathan
next prev parent reply other threads:[~2011-05-11 16:04 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-11 8:00 [PATCH 0/8] Sequencer Foundations Ramkumar Ramachandra
2011-05-11 8:00 ` [PATCH 1/8] revert: Improve error handling by cascading errors upwards Ramkumar Ramachandra
2011-05-11 9:59 ` Jonathan Nieder
2011-05-13 10:30 ` Ramkumar Ramachandra
2011-05-19 10:39 ` Ramkumar Ramachandra
[not found] ` <20110519091831.GA28723@ramkum.desktop.amazon.com>
2011-05-19 18:03 ` Jonathan Nieder
2011-05-20 6:39 ` Ramkumar Ramachandra
2011-05-11 8:00 ` [PATCH 2/8] revert: Make "commit" and "me" local variables Ramkumar Ramachandra
2011-05-11 10:37 ` Jonathan Nieder
2011-05-13 10:02 ` Ramkumar Ramachandra
2011-05-13 21:40 ` Daniel Barkalow
2011-05-11 8:00 ` [PATCH 3/8] revert: Introduce a struct to parse command-line options into Ramkumar Ramachandra
2011-05-11 11:24 ` Jonathan Nieder
2011-05-13 9:32 ` Ramkumar Ramachandra
2011-05-13 10:07 ` Jonathan Nieder
2011-05-13 10:22 ` Ramkumar Ramachandra
2011-05-11 8:00 ` [PATCH 4/8] revert: Separate cmdline argument handling from the functional code Ramkumar Ramachandra
2011-05-11 11:49 ` Jonathan Nieder
2011-05-13 9:09 ` Ramkumar Ramachandra
2011-05-13 9:35 ` Ramkumar Ramachandra
2011-05-13 9:44 ` Jonathan Nieder
2011-05-11 8:00 ` [PATCH 5/8] revert: Catch incompatible command-line options early Ramkumar Ramachandra
2011-05-11 12:06 ` Jonathan Nieder
2011-05-13 10:07 ` Ramkumar Ramachandra
2011-05-11 8:00 ` [PATCH 6/8] revert: Introduce head, todo, done files to persist state Ramkumar Ramachandra
2011-05-11 12:47 ` Jonathan Nieder
2011-05-13 10:21 ` Ramkumar Ramachandra
2011-05-11 8:00 ` [PATCH 7/8] revert: Implement parsing --continue, --abort and --skip Ramkumar Ramachandra
2011-05-11 12:59 ` Jonathan Nieder
2011-05-13 9:16 ` Ramkumar Ramachandra
2011-05-13 9:40 ` Jonathan Nieder
2011-05-11 8:00 ` [PATCH 8/8] revert: Implement --abort processing Ramkumar Ramachandra
2011-05-11 13:14 ` Jonathan Nieder [this message]
2011-05-12 8:19 ` [PATCH 0/8] Sequencer Foundations Christian Couder
2011-05-12 8:41 ` Jonathan Nieder
2011-05-12 11:44 ` Jonathan Nieder
2011-05-13 9:11 ` Christian Couder
2011-05-13 10:37 ` Jonathan Nieder
2011-05-16 4:14 ` Christian Couder
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110511131356.GI2676@elie \
--to=jrnieder@gmail.com \
--cc=artagnon@gmail.com \
--cc=barkalow@iabervon.org \
--cc=chriscool@tuxfamily.org \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.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.
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 NNTP newsgroup(s).