Hi Daniel, 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. [...] > int sequencer_handle_conflict(); /* Returns ABORT (1) or RESOLVED (0) */ > > /** > * The sequencer_handle_conflict function essentially starts with a > * working tree with unmerged files and results in either a working > * tree without unmerged files (in which case it returns 0), or simply > * returns 1. Advantage: Consistency. Each individual script will not > * have to maintain its own temporary files. > */ Uh, no. I wrote this part in too quickly. Clearly needs more thought. -- 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