Re: [RFC] git-sequencer.txt

[Christian Couder <chriscool@tuxfamily.org>]

Le mardi 10 juin 2008, Stephan Beyer a écrit :
> > > SYNOPSIS
> > > --------
> > > [verse]
> > > 'git-sequencer' [-v | --verbose] <file> [<branch>]
> >
> > I think that you should think carefully if there would be no troubles
> > with this way of specifying options.  Perhaps explicit file option
> > (-F/--file=<file>), or optional '--' separating revisions.  But
> > perhaps my fears are for nothing, and current proposal is good
> > solution.
>
> Well, I think we (my mentors and me) had around three different versions
> of a synopsis.

Yes, we discussed:

'git-sequencer' [-v | --verbose] [-b <branch>] [<file>]

that would use stdin if <file> is not provided. If -b <branch> is used and 
<branch> does not already exists, it would create it.

> ATM I think the synopsis is not a very important thing to discuss, as it
> is relatively easy changeable even in the last minute. ;)
>
> But what are your actual fears?  What troubles do you think of?
>
> > > 'git-sequencer' --continue | --skip | --abort | --edit
> >
> > The common '--continue | --skip | --abort' infrastructure is, I think,
> > one of the most important things about this.  I'd like to have
> > '--what' (or '--status') option to tell us if we are in the middle of
> > sequence of oprations, and what this sequence is (rebase, rebase -i,
> > am, revert, cherry-pick, sequencer <file>,...).
>
> I've read the discussion about git-what and I wrote it down on a yellow
> memo sheet *g* (no real TODO list) to have such a thing in git-sequencer.
>
> First I didn't want to have it in the prototype so I didn't add it to
> the spec.
> But it leads me to an open question I've also noticed on testing:
>
> If you currently start a rebase or am and there's a conflict and
> you do
> 	git sequencer --continue
> instead of
> 	git rebase --continue
> or
> 	git am --resolved
> the cleanup code of rebase/am is not executed and thus the job is not
> properly finished.
>
> How to prevent this?
> My first idea is the one I don't really like: the user tools temporarily
> generate some "post-sequencer scripts", that get executed after
> finished sequencing. This way, it doesn't matter if you call git
> sequencer --continue, git rebase --continue or git am --resolved to
> finish the job.
>
> The second idea is that somehow the user tool should set a "CALLER"
> environment variable or tell the caller otherwise (--caller=rebase?)
> and git-sequencer only continues if called by the same caller.

Maybe the sequencer can look at the filename it is passed.
If it is something like "$GIT_DIR/*/git-rebase--interactive-todo" that can 
mean it is called by "git rebase --interactive".

And then maybe when "git sequencer --continue" is called interactively, it 
can say something like:

"This sequencer run was started by 'git rebase --interactive' please 
continue using 'git rebase --continue'."

Thanks,
Christian.