Hi Daniel,
Daniel Barkalow writes:
> On Sun, 3 Apr 2011, Ramkumar Ramachandra wrote:
> > To write git-sequencer, a new builtin command, and implement existing
> > commands on top of that. This should give the commands more
> > functionality, improve their error handling, and make them faster.
> > The project can only be considered successful if all (or most) of the
> > code written gets merged into upstream.
> >
> > The Git Sequencer was a 2008 GSoC project as well; unfortunately most
> > of the code did not get merged into git.git. The learning from all
> > that work should serve as a huge headstart this year.
>
> One of the things that is hard about sequencer is that it is ultimately a
> complete replacement for several differently-implemented programs in
> different languages, with different temporary file formats and differrent
> supported operations. As such, you could probably spend an entire summer
> just getting it reviewed, revised, and accepted, starting with a working
> implementation.
Agreed. I've chosen to use the same commands and temporary files as
'git-rebase--interactive.sh', because I think those commands are
sufficient to implement everything else.
> So I think your proposal is good in how [1/5] includes getting something
> useful merged. My suspicion is that the outcome will be something like
> that you implemented all 7 tasks and got 4 of them merged, assuming that
> you really push getting things merged as soon as they're ready, without
> spending too much time porting other things to use the core and getting
> the ports reviewed before the core is accepted.
Hm. In that case, we'll just have a sequencer that can cherry-pick --
I personally wouldn't be too happy with this outcome either.
> 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.
Until 4/7, I'd only planned to make the 'git-sequencer' binary like
the 'git-rebase--interactive.sh' script, except that it would accept a
TODO file on stdin, instead of interactively opening up an editor.
Your idea is a slightly more ambitious version of what I'd planned for
6/7, especially since 'merge' contains a lot of cruft like MERGE_HEAD
and CHERRY_PICK_HEAD. I can shift my focus after 4/7 though -- here's
what I have in mind. Do you have something similar in mind?
enum commit_todo_action {
ACTION_PICK;
ACTION_REWORD;
ACTION_EDIT;
ACTION_SQUASH;
ACTION_FIXUP;
ACTION_EXEC;
};
struct commit_todo_list {
struct commit *item;
enum commit_todo_action action;
struct commit_todo_list *next;
};
int sequencer_cherry_pick(struct commit *base, struct commit_list *list);
int sequncer_rebase(struct commit *base, struct commit_todo_list *list);
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.
*/
> I think replacing existing multi-step processes is going to be a lot more
> contentious and involve user-visible changes which involve matters of
> taste and such. But I think you can make a valuable contribution in how a
> single current step is handled before getting tangled in that, and be much
> more likely to get a useful outcome than if you try to tackle the whole
> problem.
Okay. I'll replace 5/7 - 7/7 in my proposal with an alternative as
soon as I sketch out the details more clearly.
Thanks for your suggestions!
-- 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