Hi Daniel,
Daniel Barkalow writes:
> On Mon, 4 Apr 2011, Ramkumar Ramachandra wrote:
> > Ramkumar Ramachandra writes:
> > > Daniel Barkalow writes:
> > > > I actually think that it would be a worthwhile feature for git's library
> > > > code to have a uniform mechanism for communicating that it is requesting
> > > > human intervention in the middle of a particular operation, where library
> > > > operations which conflict with being able to continue this operation are
> > > > either blocked or abort the operation, and the library is able to be told
> > > > in general that the human intervention is done and the library operation
> > > > should be finished now (or produce complaints about the user's work). That
> > > > is, a library-level, single-interrupted-step "sequencer". For that matter,
> > > > it should also apply to the common '"git merge" gets a conflict' case, and
> > > > it would be useful to get some representational uniformity between that
> > > > and cherry-pick getting a conflict.
> >
> > [...]
Thanks for the detailed response- I've rearragned your response and
added some comments. I initially wanted to design it so that all
state is persisted by the sequencer, but I can clearly see what's
wrong with that approach now.
> I think, ultimately, that with this code structure in place, the
> am/rebase/rebase--interactive/sequencer details of how the multi-step
> process is recorded becomes less important. That way, your project can be
> successful even if you can't find a syntax for the sequencer file that
> meets the needs of all of these use cases. (Which is where I suspect
> you'll get bogged down.) If you can get all of the cases where git exits
> in order to get human intervention to share "everything that matters" and
> the core to "know what's in progress as far as anything else cares", I
> think that would be success, even if the various multi-step programs
> continue using their own state files.
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. 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?
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":
> Where the sequencer-level conflict nests around the cherry-pick-level
> conflict, and the generic "continue" completes things from the inside out.
Right. And then the sequencer fires the appropriate callback and
returns control to the parent command. More notes:
> - cherry-pick can save whatever it needs to in its state file; that's
> its business, and the semantics here don't have to interact with other
> commands, because report_conflict() has taken care of interaction with
> other commands
At the end of a merge for example, the MERGE_MSG needs to be retrieved
to create a new merge commit. The sequencer des not need to know
anything about this, since this is specific to 'merge'.
> - arbitrary code can determine that you're in the middle of resolving
> some conflict, that the resolution of that conflict is about doing
> something to your current branch, and how to abort what you're doing,
> and how to finish it
Any arbitrary code simply has to ask the sequencer about the state of
the intermediate files that report_conflict() uses. They don't have
to worry about command-specific intermediate files.
> - the same code gets run after the conflict has been resolved that would
> have been run immediately if the merge went smoothly
Using these callbacks, there is no need for if-else ugliness inside
the specific command to decide what to do next.
I suppose we can call this idea a "generic conflict handler". I like
it very much, and I'll definitely include this as part of my GSoC
work. Thanks for taking the time to explain it in such detail :)
-- Ram
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html