From: Ramkumar Ramachandra <artagnon@gmail.com>
To: Daniel Barkalow <barkalow@iabervon.org>
Cc: Git List <git@vger.kernel.org>, Stephen Beyer <s-beyer@gmx.net>,
Christian Couder <chriscool@tuxfamily.org>,
Sverre Rabbelier <srabbelier@gmail.com>,
Jonathan Nieder <jrnieder@gmail.com>
Subject: Re: [GSoC 2011] Git Sequencer
Date: Wed, 6 Apr 2011 00:29:32 +0530 [thread overview]
Message-ID: <20110405185929.GA25644@kytes> (raw)
In-Reply-To: <alpine.LNX.2.00.1104051354500.14365@iabervon.org>
Hi Daniel,
Daniel Barkalow writes:
> On Tue, 5 Apr 2011, Ramkumar Ramachandra wrote:
> > Excellent. The crux of the idea: The sequencer should serve as the
> > entry/ exit point for Git when any operation requires user
> > intervention to proceed.
>
> I'm a bit surprised by the idea of calling that "the sequencer" (rather
> than having "the sequencer" be a command), but I actually think you're
> entirely right to do so. Be sure to be very explicit about that, though,
> because people will probably start with the wrong idea of what you're
> proposing otherwise.
Ah. I'll make sure to word it unambiguously in the proposal, and link
to this thread :)
> > For this, it should have information about
> > how we got to this point, and how to proceed after the user
> > intervention is complete; this information is contained in:
> >
> > > cherry_pick_conflict = {
> > > "cherry-pick", APPLIES_TO_CURRENT_BRANCH | IN_MIDDLE_OF_COMMIT,
> > > cherry_pick_verify_resolution,
> > > cherry_pick_abort,
> > > cherry_pick_post_resolution
> > > };
> >
> > Wait -- isn't it missing a skip callback?
>
> I think "skip" is actually: abort the lowest-level conflict and continue
> the next-level conflict. If you're doing a rebase, and the rebase is doing
> a "pick", and the pick got a conflict, --skip means that you abort the
> pick (to get back to the state where the earlier commits have been picked
> but this one hasn't been started, followed by having the rebase continue
> with what it was going to do after the pick completed.
>
> So I don't think you need a "skip" callback, as long as you've untangled
> the levels cleanly and get the nesting support right.
Okay. I'm not yet entirely clear about this yet, but I think it
should be sorted out during implementation.
> > cherry_pick_conflict = {
> > "cherry-pick", APPLIES_TO_CURRENT_BRANCH | IN_MIDDLE_OF_COMMIT,
> > cherry_pick_verify_resolution,
> > cherr_pick_skip,
> > cherry_pick_abort,
> > cherry_pick_post_resolution
> > };
> >
> > This information is passed to report_conflict(), which takes care of
> > user intervention. The user can do whatever she wants and then ask
> > the sequencer to "continue", "skip" or "abort":
>
> Right, although I think:
>
> $ git cheery-pick some-sha1
> Conflict needs to be fixed now!
>
> $ git skip
>
> should give an error message about the current conflict not being a step
> of a larger process. That is, you can always "continue" or "abort", but
> you can only "skip" if there's something to skip to, even if it's only the
> higher-order sequence reporting that it's completed successfully.
Right, got it.
-- Ram
next prev parent reply other threads:[~2011-04-05 19:00 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-03 17:20 [GSoC 2011] Git Sequencer Ramkumar Ramachandra
2011-04-03 17:24 ` Sverre Rabbelier
2011-04-03 19:07 ` Stephan Beyer
2011-04-03 20:00 ` Ramkumar Ramachandra
2011-04-03 20:08 ` Jonathan Nieder
2011-04-03 19:49 ` Daniel Barkalow
2011-04-04 4:06 ` Ramkumar Ramachandra
2011-04-04 4:54 ` Ramkumar Ramachandra
2011-04-04 18:59 ` Daniel Barkalow
2011-04-05 17:50 ` Ramkumar Ramachandra
2011-04-05 18:24 ` Daniel Barkalow
2011-04-05 18:59 ` Ramkumar Ramachandra [this message]
2011-04-04 4:43 ` Christian Couder
2011-04-04 5:20 ` Junio C Hamano
2011-04-05 6:23 ` Christian Couder
2011-04-05 6:46 ` Ramkumar Ramachandra
2011-04-04 16:57 ` Ramkumar Ramachandra
2011-04-05 20:00 ` [GSoC 2011 v2] " Ramkumar Ramachandra
2011-04-06 8:11 ` Christian Couder
2011-04-06 9:01 ` Ramkumar Ramachandra
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=20110405185929.GA25644@kytes \
--to=artagnon@gmail.com \
--cc=barkalow@iabervon.org \
--cc=chriscool@tuxfamily.org \
--cc=git@vger.kernel.org \
--cc=jrnieder@gmail.com \
--cc=s-beyer@gmx.net \
--cc=srabbelier@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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.