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. -- 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
