[RFC] git-sequencer.txt

[RFC] git-sequencer.txt

[Stephan Beyer]

Hi,

I inline-attached the documentation (and somehow specification)
for git-sequencer (my GSoC'08 project) for you to comment on.

git-sequencer wants to become the common backend for git-am and 
git-rebase(--interactive) and perhaps some other git commands.
But, if git-sequencer.txt is good enough, you should be able to figure
out yourself, what it can actually be used for :-)

Some background on the project status:
There is already a working (shell) implementation of the following 
specification (90% finished), but we thought that it is useful to 
first give you only a spec without implementation details to comment on.

Note, that there is also a git-am and git-rebase--interactive that use
git-sequencer directly and ... all test cases of the test suite (in "next")
are passed.  So imho a first reality-check is passed, too.

But the second (and perhaps much harder) stage to pass is your 
point of view.
So I hope you will have some good ideas and strong opinions ;-)

Regards,
  Stephan

------------------------------ git-sequencer.txt ------------------------------
git-sequencer(1)
================

NAME
----
git-sequencer - Execute a sequence of git instructions

SYNOPSIS
--------
[verse]
'git-sequencer' [-v | --verbose] <file> [<branch>]
'git-sequencer' --continue | --skip | --abort | --edit


DESCRIPTION
-----------
Executes a sequence of git instructions to HEAD or `<branch>`.
The sequence is given by `<file>` or standard input.
Also see 'TODO FILE FORMAT' below.

Before doing anything, the TODO file is checked for correct syntax 
and sanity.

In case of a conflict or request in the TODO file, git-sequencer will
pause. On conflict you can use git-diff to locate the markers (`<<<<<<`) 
and make edits to resolve the conflict.

For each file you edit, you need to tell git the changes by doing

    git add <file>

After resolving the conflict manually and updating the index with the
desired resolution, you can continue the sequencing process with

    git sequencer --continue

Alternatively, you can undo the git-sequencer progress with

    git sequencer --abort

or skip the current instruction with

    git sequencer --skip

or correct the TODO file with

    git sequencer --edit

During pauses or when finished with the sequencing task, the current
HEAD will always be the result of the last processed instruction.


OPTIONS
-------
<file>::
	Filename of the TODO file.  Use `-` to read from standard input.
	See 'TODO FILE FORMAT' below.

<branch>::
	Working branch; defaults to HEAD.

--continue::
	Restart the sequencing process after having resolved a merge conflict.

--abort::
	Restore the original branch and abort the sequence operation.

--skip::
	Restart the sequencing process by skipping the current patch.

--edit::
	Invoke editor to edit the undone rest of the TODO file.
+
The file is syntax- and sanity-checked afterwards, so that you can 
safely run `git sequencer --skip` or `--continue` after editing.
If you nonetheless noticed that you made a mistake, you can 
overwrite `.git/sequencer/todo` with `.git/sequencer/todo.old` and
rerun `git sequencer --edit`.
+
If the check fails you are prompted if you want to correct your 
changes, edit again, cancel editing or really want to save.

-v, \--verbose::
	Be more verbose. [XXX: to be defined more accurately, i.e. print diffstat]


NOTES
-----

When sequencing, it is possible, that you are changing the history of
a branch in a way that can cause problems for anyone who already has 
a copy of the branch in their repository and tries to pull updates from
you.  You should understand the implications of using git-sequencer on
a repository that you share.

git-sequencer will usually be called by another git porcelain, like
linkgit:git-am[1] or linkgit:git-rebase[1].


TODO FILE FORMAT
----------------

The TODO file contains basically one instruction per line.

Blank lines will be ignored. 
All characters after a `#` character will be ignored until the end of a line.

The following instructions can be used:


edit <commit>::
	Picks a commit and pauses the sequencer process to let you
	make changes.
+
After you have finished your changes, invoke `git-sequencer --continue`.
If you only want to edit the commit message with an editor,
run `git-commit --amend` (see linkgit:git-commit[1]) before.
+
Note, that `edit <commit>` is a short form for `pick --edit <commit>`.


file [<options>] <file>::
	If file `<file>` is a pure (diff) patch, then apply the patch.
	If no `--message` option is given, an editor will
	be invoked to enter a commit message.
+
If `<file>` is a linkgit:git-format-patch[1]-formatted patch,
then the patch will be commited.
+
See the following list and 'GENERAL OPTIONS' for values of `<option>`:

	-3, --3way;;
		When the patch does not apply cleanly, fall back on
		3-way merge, if the patch records the identity of blobs
		it is supposed to apply to, and we have those blobs
		available locally.

	-k;;
		Pass `-k` flag to `git-mailinfo` (see linkgit:git-mailinfo[1]).

	-n;;
		Pass `-n` flag to `git-mailinfo` (see
		linkgit:git-mailinfo[1]).

	-u;;
		Pass `-u` flag to `git-mailinfo` (see linkgit:git-mailinfo[1]).
		The proposed commit log message taken from the e-mail
		is re-coded into UTF-8 encoding (configuration variable
		`i18n.commitencoding` can be used to specify project's
		preferred encoding if it is not UTF-8).
+
This was optional in prior versions of git, but now it is the
default. You could use `-n` to override this.

	-*;;
		Any other dash-prefixed option is passed to
		linkgit:git-apply[1].
		This is especially useful for flags like
		`--reverse`, `-C<n>`, `-p<n>` or `--whitespace=<action>`.


mark <mark>::
	Set a symbolic mark for the last commit.
	`<mark>` is an unsigned integer starting at 1 and
	prefixed with a colon, e.g. `:1`.
+
The marks can help if you want to refer to commits that you
created during the sequencer process, e.g. if you want to
merge such a commit.
+
The set marks are removed after the sequencer has completed.


merge [<options>] <commit-ish1> <commit-ish2> ... <commit-ishN>::
	Merge commits into HEAD.
+
A commit can also be given by a mark, if prefixed with a colon.
+
If you do not provide a commit message (using `-F`, `-m`, `--reference` 
or `--standard`), an editor will be invoked.
+
See the following list and 'GENERAL OPTIONS' for values of `<option>`:

	--reference=<commit-ish>;;
		Take author and commit message of <commit-ish>.
	
	--standard;;
		Generates a commit message like 'Merge ... into HEAD'.
		See also linkgit:git-fmt-merge-msg[1].
	
	-s <strategy>;;
	--strategy=<strategy>;;
		Use the given merge strategy.
		See also linkgit:git-merge[1].


pick [<options>] <commit>::
	Pick (see linkgit:git-cherry-pick[1]) a commit.
	Sequencer will pause on conflicts.
+
See 'GENERAL OPTIONS' for values of `<option>`.


reset <commit-ish>::
	Go back (see linkgit:git-reset[1] `--hard`) to commit `<commit-ish>`.
	`<commit-ish>` can also be given by a mark, if prefixed with a colon.


squash [<options>] <commit>::
	Add the changes introduced by `<commit>` to the last commit.
+
See 'GENERAL OPTIONS' for values of `<option>`.


tag <tag>::
	Set tag `<tag>` to the current HEAD,
	see also linkgit:git-tag[1].
	If another commit is tagged `<tag>`, it will lose this tag,
	i.e. the tag will be reset to HEAD.



GENERAL OPTIONS
---------------

Besides some special options, the instructions
`file`, `merge`, `pick`, `squash` take the following general options:

--edit::
	Allows you to re-edit the done commit. For example, you can change
	the commit message in an editor, or fix even bugs or typos.
	Lets you also manually make further commits on top of the
	current commit before continuing.
+
You will have to invoke `git-sequencer --continue` (or `--edit` or `--abort`),
when finished.

--author=<author>::
	Override the author name and e-mail address used in the commit.
	Use `A U Thor <author@example.com>` format.

-F <file>::
--file=<file>::
	Take the commit message from the given file.

-m <msg>::
--message=<msg>::
	Use the given `<msg>` as the commit message.

-s::
--signoff::
	Add `Signed-off-by:` line to the commit message (if not yet there),
	using the committer identity of yourself.


RETURN VALUES
-------------

git-sequencer returns:

* `0`, if git-sequencer successfully completed all the instructions
       in the TODO file or successfully aborted after
       `git-sequencer --abort`,
* `2`, on user-requested pausing, e.g.
       when using the `edit` instruction.
* `3`, on pauses that are not requested, e.g.
       when there are conflicts to resolve.
* any other value on error, e.g.
  syntax errors in the TODO file or
  running git-sequencer on a bare repository.


EXAMPLES
--------

XXX [Here the usage of all commands should become clear,
but it's braindamaged to write this section as long as the file format
is in discussion.]


SEE ALSO
--------
linkgit:git-add[1],
linkgit:git-am[1],
linkgit:git-cherry-pick[1],
linkgit:git-commit[1],
linkgit:git-format-patch[1],
linkgit:git-rebase[1],
linkgit:git-reset[1],
linkgit:git-tag[1]


Authors
-------
XXX

Documentation
-------------
Documentation by Stephan Beyer and the git-list <git@vger.kernel.org>.

GIT
---
Part of the linkgit:git[1] suite

-- 
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F

squashing patches (was: Re: [RFC] git-sequencer.txt)

[Stephan Beyer]

Wow,

I didn't expect *that much* feedback :-)
I think I begin slowly to comment some things, and/or tell you
some things that are still open.
Then, maybe, someone of you swoops in :)

> TODO FILE FORMAT
> ----------------

First to say, I tried to be (backwards-)compatible to the 
rebase--interactive TODO file format in "master".
It became incompatible to the one in "next" in one point 
only (-> merge). But if I understood "next" right, this is
not bad, since Joerg Sommers rebase-i patchset is still
open for discussion (i.e. mark).

Well, now I come to the subject's topic.


I've noticed that one thing is *obviously* missing:

There's a slight asymmetry between
> file [<options>] <file>::
and
> pick [<options>] <commit>::
> edit <commit>::
> squash [<options>] <commit>::

"edit" is kept for backwards compatibility. It's a short form for and
internally `expanded' to "pick --edit".
As --edit is a general option, there is also "file --edit".
So there's no functional asymmetry in this case.

If you want to pick several commits and squash them together, there is
"squash".  BUT there is no equivalent for "file" currently.
The only way to squash several patches together is with an external tool
like your favourite text editor, which is not fun but error-prone.
And there is no way to squash a commit (in the repo) and a patch (as file)
together (in exactly this order). The only thing is that you could run
sequencer twice and squash in the second move.

So I wonder if file --squash is useful, too, or even --squash as an
general option. The latter means that you could squash merge commits
into other commits, too.

We've also discussed the non-atomic approach of doing something like
	pick ( a b c d )	# or another syntax for that
for picking multiple commits into one.
In my current point of view, this does not seem right, as it:
 - is not atomic ;), and...
 - Well, the approach could be used for "file ( a b c d )", too,
   but it doesn't help for squashing commits AND patches.

Comments? Opinions? Ideas?

A first try to prod,
  Stephan.

-- 
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F

Re: squashing patches (was: Re: [RFC] git-sequencer.txt)

[Johannes Schindelin]

Hi,

On Mon, 9 Jun 2008, Stephan Beyer wrote:

> Wow,
> 
> I didn't expect *that much* feedback :-)

Hey, that's a real long document, and some of us have a real job! ;-)

Ciao,
Dscho

Re: squashing patches

[Paolo Bonzini]

> If you want to pick several commits and squash them together, there is
> "squash".  BUT there is no equivalent for "file" currently.
> The only way to squash several patches together is with an external tool
> like your favourite text editor, which is not fun but error-prone.
> And there is no way to squash a commit (in the repo) and a patch (as file)
> together (in exactly this order). The only thing is that you could run
> sequencer twice and squash in the second move.

My feedback is in the message from the "-s theirs" thread that I CCed 
you on.

Basic points:

1) I would like a "--strategy" option for cherry-pick and for the 
sequencer's "pick";

2) What about

   mark :1
   pick a
   file b
   pick c
   squash --up-to :1

or, to specify a commit message

   mark :1
   file a
   pick b
   squash --up-to :1 -C HEAD^

or also

   mark :1
   file a
   pick b
   squash --up-to :1 -C HEAD^ -s

to merge all signoffs.  This could be done by providing a stand-alone 
git-squash command; or alternatively, it could be done in the sequencer 
and the git-squash command would simply do

   (echo 'mark :1'
    git-rev-list --reverse $1.. | sed 's,^,pick '
    echo "squash --up-to :1 $*") | git-sequencer

after some option parsing.

3) I would like a totally batch mode-of-operation, which would fail if 
user intervention was needed (the user could choose whether to not edit 
the editor, or whether to use a no-op for GIT_EDITOR).

4) I think the sequencer is an opportunity to improve some commands, 
e.g. git-cherry-pick should grow more or less the same options as 
git-sequencer's pick.

Paolo

Re: squashing patches

[Paolo Bonzini]

Paolo Bonzini wrote:
> the git-squash command would simply do
> 
>   (echo 'mark :1'
>    git-rev-list --reverse $1.. | sed 's,^,pick '
>    echo "squash --up-to :1 $*") | git-sequencer

Nah this makes no sense, sorry.

Paolo

Re: squashing patches

[Stephan Beyer]

Hi,

> My feedback is in the message from the "-s theirs" thread that I CCed  
> you on.

Well, I've noticed and read it, but haven't knowm what I wanted to 
reply. :)

> Basic points:
>
> 1) I would like a "--strategy" option for cherry-pick and for the  
> sequencer's "pick";

If somebody adds a --strategy option to cherry-pick and it gets
into "next", I have no problem to let sequencer pass the option to
cherry-pick ;)

Btw, I like the idea of cherry-pick --strategy=theirs (though I don't
know if I'd ever use it), but this is currently beyond my task ;-)

> 2) What about
>
>   mark :1
>   pick a
>   file b
>   pick c
>   squash --up-to :1

I like the idea.  And the others?

--- a/Documentation/git-sequencer.txt
+++ b/Documentation/git-sequencer.txt
@@ -212,6 +216,12 @@ squash [<options>] <commit>::
 +
 See 'GENERAL OPTIONS' for values of `<option>`.
 
+squash [<options>] --up-to <mark>::
+	Squash all commits up to the given mark into one commit.
+	There must not be any merge commits in between.
++
+See 'GENERAL OPTIONS' for values of `<option>`.
+
 
 tag <tag>::
 	Set tag `<tag>` to the current HEAD,

> or, to specify a commit message
>
>   mark :1
>   file a
>   pick b
>   squash --up-to :1 -C HEAD^

Reusing the commit message may be useful, too, agreed.
I think that this is something that can be put to the 
"GENERAL OPTIONS" section:

--- a/Documentation/git-sequencer.txt
+++ b/Documentation/git-sequencer.txt
@@ -240,6 +250,12 @@ when finished.
 	Override the author name and e-mail address used in the commit.
 	Use `A U Thor <author@example.com>` format.
 
+-C <commit-ish>::
+--reuse-message=<commit-ish>::
+	Reuse message from specified commit.
+	Note, that only the commit message is reused
+	and not the authorship information.
+
 -F <file>::
 --file=<file>::
 	Take the commit message from the given file.
--

Ok?


If you want also the authorship information, there's the --reference
which is atm only available for the "merge" insn.
Currently I also wonder, why only merge has this option ;-)

Should this be a General Option, too?

--- a/Documentation/git-sequencer.txt
+++ b/Documentation/git-sequencer.txt
@@ -182,9 +189,6 @@ or `--standard`), an editor will be invoked.
 +
 See the following list and 'GENERAL OPTIONS' for values of `<option>`:
 
-	--reference=<commit-ish>;;
-		Take author and commit message of <commit-ish>.
-	
 	--standard;;
 		Generates a commit message like 'Merge ... into HEAD'.
 		See also linkgit:git-fmt-merge-msg[1].
@@ -247,6 +263,10 @@ when finished.
 -m <msg>::
 --message=<msg>::
 	Use the given `<msg>` as the commit message.
+	
+--reference=<commit-ish>::
+	Take author and commit message of <commit-ish>.
+	
 
 -s::
 --signoff::
--

> or also
>
>   mark :1
>   file a
>   pick b
>   squash --up-to :1 -C HEAD^ -s
>
> to merge all signoffs.

Hm, this is a bit too specific I think.
Do I interpret your example right, that you want to 
squash "a" and "b", reuse the commit message of the
newly commited patch "a", but also add the signoff of
"b"? (And perhaps, if not set, the own signoff?)

If I put this into sequencer, I'd like to name
that --squash-signoffs (or --merge-signoffs) or something,
because -s/--signoff is a general option atm, that adds
your signoff.

What do the others think? (Sorry for my questions to "the others", 
but I need some input. *grin*)

> This could be done by providing a stand-alone  
> git-squash command; or alternatively, it could be done in the sequencer  

The git-squash approach looks clean to me.

>   (echo 'mark :1'
>    git-rev-list --reverse $1.. | sed 's,^,pick '
>    echo "squash --up-to :1 $*") | git-sequencer

I notice that you indirectly changed the synopsis, intuitively.
This shows me, that we should change it ;-)
According to the current SYNOPSIS you have to do "git-sequencer -"
to read from stdin.

> 3) I would like a totally batch mode-of-operation, which would fail if  
> user intervention was needed

I like the idea.

--- a/Documentation/git-sequencer.txt
+++ b/Documentation/git-sequencer.txt
@@ -8,7 +8,7 @@ git-sequencer - Execute a sequence of git instructions
 SYNOPSIS
 --------
 [verse]
-'git-sequencer' [-v | --verbose] <file> [<branch>]
+'git-sequencer' [--batch] [-v | --verbose] <file> [<branch>]
 'git-sequencer' --continue | --skip | --abort | --edit

@@ -59,6 +59,13 @@ OPTIONS
 <branch>::
 	Working branch; defaults to HEAD.
 
+--batch::
+	Run in batch mode. If unexpected user intervention is needed
+	(e.g. a conflict or the need to run an editor), git-sequencer fails.
++
+Note that the sanity check fails, if you use this option
+and an instruction like `edit` or the `--edit` option.
+
 --continue::
 	Restart the sequencing process after having resolved a merge conflict.
 
--

Ok?

> (the user could choose whether to not edit the editor,
> or whether to use a no-op for GIT_EDITOR).

I don't understand ;-)

> 4) I think the sequencer is an opportunity to improve some commands,  
> e.g. git-cherry-pick should grow more or less the same options as  
> git-sequencer's pick.

Hmmmmm, basically I like this approach.
Let's for example take the "merge --reference=<commit>" option.
It fetches the information from a former commit, and then does
git merge with different authorship information and -m "message bla".
So the basics are there, they just have to be put together.
Do you think it's useful to add something like --reference (or -C,
or however it is called) to git-merge?

Thanks and regards,
  Stephan

-- 
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F

Re: squashing patches

[Paolo Bonzini]

>> (the user could choose whether to not edit the editor,
>> or whether to use a no-op for GIT_EDITOR).

Right now, doing

pick a
squash b

will always invoke the editor.  It could be possible to have two 
operation modes.  One in which the sanity check fails, one in which the 
automatic concatenation of two commit messages is used.

> Do you think it's useful to add something like --reference (or -C,
> or however it is called) to git-merge?

Maybe it's not useful, but I think it's cleaner than adding the option 
only to git-sequencer.

Paolo

ps: sure you should ask "the others" (who are more knowledgeable than me 
BTW) for opinions about what I proposed.

[RFC/PATCH] Add git-squash tool and tests

[Stephan Beyer]

git-squash is a simple command that, given the parent commit of X,
squashes the commits X..HEAD into one.

Signed-off-by: Stephan Beyer <s-beyer@gmx.net>
---
Hi,

perhaps this is a little surprising, but because of:
> This could be done by providing a stand-alone git-squash command;
I thought it could be right to quickly write this as a script.

Here it is as RFC, yet without documentation.

Junio, this could be a backend for the zucchini instruction, by just
 zucchini <n>  =>  git-squash "HEAD~$(expr $n + 1)"   ;-)

 Makefile          |    1 +
 command-list.txt  |    1 +
 git-squash.sh     |   77 +++++++++++++++++++++++++++++++++++++++++++++++++++++
 t/t3150-squash.sh |   66 +++++++++++++++++++++++++++++++++++++++++++++
 4 files changed, 145 insertions(+), 0 deletions(-)
 create mode 100755 git-squash.sh
 create mode 100755 t/t3150-squash.sh

diff --git a/Makefile b/Makefile
index 1937507..863004b 100644
--- a/Makefile
+++ b/Makefile
@@ -251,6 +251,7 @@ SCRIPT_SH += git-rebase.sh
 SCRIPT_SH += git-repack.sh
 SCRIPT_SH += git-request-pull.sh
 SCRIPT_SH += git-sh-setup.sh
+SCRIPT_SH += git-squash.sh
 SCRIPT_SH += git-stash.sh
 SCRIPT_SH += git-submodule.sh
 SCRIPT_SH += git-web--browse.sh
diff --git a/command-list.txt b/command-list.txt
index 3583a33..e342da3 100644
--- a/command-list.txt
+++ b/command-list.txt
@@ -108,6 +108,7 @@ git-show-branch                         ancillaryinterrogators
 git-show-index                          plumbinginterrogators
 git-show-ref                            plumbinginterrogators
 git-sh-setup                            purehelpers
+git-squash                              mainporcelain
 git-stash                               mainporcelain
 git-status                              mainporcelain common
 git-stripspace                          purehelpers
diff --git a/git-squash.sh b/git-squash.sh
new file mode 100755
index 0000000..64b5949
--- /dev/null
+++ b/git-squash.sh
@@ -0,0 +1,77 @@
+#!/bin/sh
+#
+# Squash commits from HEAD up to ... into one commit.
+
+SUBDIRECTORY_OK=Yes
+OPTIONS_KEEPDASHDASH=
+OPTIONS_SPEC="\
+git-squash [options] <commit-ish>
+--
+author=           use author <author>
+C,reuse-message=  use commit data from <commit-ish>
+F,file=           use commit message in <file>
+m,message=        use commit message <msg>
+e,edit            force edit of commit message
+s,signoff         add Signed-off-by:
+include-merges    don't fail if merge is in between
+"
+
+. git-sh-setup
+require_work_tree
+
+# test if working tree is clean
+git rev-parse --verify HEAD >/dev/null &&
+git update-index --refresh &&
+git diff-files --quiet &&
+git diff-index --cached --quiet HEAD -- ||
+	die "Working tree is dirty"
+
+git var GIT_COMMITTER_IDENT >/dev/null ||
+	die "You need to set your committer info first"
+
+HEAD=$(git rev-parse --verify HEAD) ||
+	die "No HEAD?"
+
+commitstr="git commit "
+merges=
+while test $# -gt 1
+do
+	case "$1" in
+	-m|-F|-C|--author)
+		commitstr="$commitstr $1 '$2'"
+		shift
+		;;
+	-e|-s)
+		commitstr="$commitstr $1"
+		;;
+	--include-merges)
+		merges=y
+		;;
+	--)
+		break
+		;;
+	esac
+	shift
+done
+
+test $# -gt 2 &&
+	die "Wrong number of arguments."
+test $# -lt 2 &&
+	die "No commit given."
+shift
+
+commit="$1"
+git rev-parse --verify "$commit" >/dev/null ||
+	die "$commit is no valid commit."
+
+# check for merges if no --include-merges given
+test -z "$merges" &&
+git log "$commit.." | grep -q "^Merge:" &&
+	die "$commit..HEAD contains a merge commit. You may try --include-merges."
+
+# reset and commit
+git reset --soft "$commit"
+eval "$commitstr" || {
+	git reset --hard $HEAD
+	die "Commit failed"
+}
diff --git a/t/t3150-squash.sh b/t/t3150-squash.sh
new file mode 100755
index 0000000..9f18995
--- /dev/null
+++ b/t/t3150-squash.sh
@@ -0,0 +1,66 @@
+#!/bin/sh
+
+test_description='git-squash'
+
+. ./test-lib.sh
+
+test_expect_success setup '
+	: >file1 &&
+	: >file2 &&
+	: >file3 &&
+	: >file4 &&
+	: >file5 &&
+	: >file6 &&
+	git add file1 &&
+	git commit -m file1 &&
+	git add file2 &&
+	git commit -m file2 &&
+	git checkout -b master2 HEAD^ &&
+	git add file3 &&
+	git commit -m file3 &&
+	git checkout master &&
+	git merge master2 &&
+	git add file4 &&
+	git commit -m file4 &&
+	git add file5 &&
+	git commit -m file5 &&
+	git add file6 &&
+	git commit -m file6
+'
+
+test_expect_success 'git-squash HEAD^ is a nop and fails' '
+	git checkout -b first master &&
+	! git squash HEAD^ &&
+	test "$(git rev-parse HEAD)" = "$(git rev-parse first)" &&
+	test "$(git rev-parse master)" = "$(git rev-parse first)"
+'
+
+test_expect_success 'git-squash works' '
+	git checkout -b second master &&
+	git squash -m "file5 and file6" --signoff HEAD^^ &&
+	test "$(git rev-parse HEAD)" = "$(git rev-parse second)" &&
+	test -f file1 -a -f file2 -a -f file3 -a \
+	     -f file4 -a -f file5 -a -f file6
+'
+
+test_expect_success 'git-squash fails if merge in between' '
+	git checkout -b third master &&
+	! git squash -C master master2^ &&
+	test "$(git rev-parse HEAD)" = "$(git rev-parse third)" &&
+	test "$(git rev-parse master)" = "$(git rev-parse third)"
+'
+
+test_expect_success 'git-squash works with --include-merges if merge in between' '
+	git checkout -b fourth master &&
+	git squash -C master --include-merges master2^ &&
+	test "$(git rev-parse HEAD)" = "$(git rev-parse fourth)"
+'
+
+test_expect_success 'git-squash aborts correctly if no commit message given' '
+	git checkout -b fifth master &&
+	! git squash HEAD~2 &&
+	test "$(git rev-parse HEAD)" = "$(git rev-parse fifth)" &&
+	test "$(git rev-parse master)" = "$(git rev-parse fifth)"
+'
+
+test_done
-- 
1.5.5.3

Re: [RFC/PATCH] Add git-squash tool and tests

[Johannes Schindelin]

Hi,

On Mon, 9 Jun 2008, Stephan Beyer wrote:

> git-squash is a simple command that, given the parent commit of X,
> squashes the commits X..HEAD into one.

Isn't it possible to do this with something like

	$ git reset --hard X^ &&
	  git merge --no-ff --squash HEAD@{1}

?

Ciao,
Dscho

Re: [RFC/PATCH] Add git-squash tool and tests

[Paolo Bonzini]

> Isn't it possible to do this with something like
> 
> 	$ git reset --hard X^ &&
> 	  git merge --no-ff --squash HEAD@{1}

Yes, that's true!  And very cool.

In turn, ...

> Junio, this could be a backend for the zucchini instruction, by just
>  zucchini <n>  =>  git-squash "HEAD~$(expr $n + 1)"    ;-) 

... zucchini becomes

   git reset --hard HEAD~$(expr $n)
   git merge --no-ff --squash HEAD@{1}

Paolo

Re: [RFC/PATCH] Add git-squash tool and tests

[Johannes Schindelin]

Hi,

On Mon, 9 Jun 2008, Paolo Bonzini wrote:

> > Junio, this could be a backend for the zucchini instruction, by just
> >  zucchini <n>  =>  git-squash "HEAD~$(expr $n + 1)"    ;-) 
> 
> ... zucchini becomes
> 
>   git reset --hard HEAD~$(expr $n)
>   git merge --no-ff --squash HEAD@{1}

Except that zucchini is meant for the sequencer, which can implement it 
much more efficiently (i.e. it does not have to check out HEAD~$n).  Also, 
it must not rely on reflogs being enabled.

sequencer is plumbing, while the reset mantra is porcelain.

Ciao,
Dscho

Re: [RFC/PATCH] Add git-squash tool and tests

[Stephan Beyer]

> Except that zucchini is meant for the sequencer, which can implement it 
> much more efficiently (i.e. it does not have to check out HEAD~$n).  Also, 
> it must not rely on reflogs being enabled.
> 
> sequencer is plumbing, while the reset mantra is porcelain.

Do I get you right, that the builtin sequencer must not use any of the
porcelain like cherry-pick, reset and even commit?

(Perhaps I got it wrong, but it doesn't seem "right" to me, if a
plumbing uses porcelain.)

Currently my prototype *uses* these porcelain, so is it a porcelain in
its current state? ;)

Regards,
  Stephan

-- 
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F

Re: [RFC/PATCH] Add git-squash tool and tests

[Johannes Schindelin]

Hi,

On Tue, 10 Jun 2008, Stephan Beyer wrote:

> > Except that zucchini is meant for the sequencer, which can implement it 
> > much more efficiently (i.e. it does not have to check out HEAD~$n).  Also, 
> > it must not rely on reflogs being enabled.
> > 
> > sequencer is plumbing, while the reset mantra is porcelain.
> 
> Do I get you right, that the builtin sequencer must not use any of the 
> porcelain like cherry-pick, reset and even commit?

AFAIAC cherry-pick and reset, and even commit, are not "pure" porcelain: 
you can rely on their exit code and to a certain extent on their output.  
Although I would rather use commit-tree from a script than commit.

I'd probably even use git update-ref instead of reset --soft, but then, I 
_would_ use cherry-pick.

So there is a lot of gray.

> (Perhaps I got it wrong, but it doesn't seem "right" to me, if a 
> plumbing uses porcelain.)
> 
> Currently my prototype *uses* these porcelain, so is it a porcelain in 
> its current state? ;)

I would say as long as it is meant to be used by a human, it is porcelain.  
And I do not think that git-sequencer falls into that category.

So it should avoid pure porcelains, such as "git show", and use the 
(robust) low-level tools instead.

But I feel quite silly talking about that at length; I think that you can 
use whatever gets a prototype done, and then go on and make it a builtin.

Ciao,
Dscho

Re: [RFC/PATCH] Add git-squash tool and tests

[Stephan Beyer]

Hi,

> Isn't it possible to do this with something like
> 
> 	$ git reset --hard X^ &&
> 	  git merge --no-ff --squash HEAD@{1}

$ git merge --no-ff --squash HEAD@{1}
You cannot combine --squash with --no-ff.

But without --no-ff it somehow squashes to the index, I just have to
commit ;-)


Btw,
if you husk and boil git-squash.sh a while, you get down to
  git reset --soft X^
  git commit {options}
which is way simpler.

The rest is just usage-blabla, option passing and checking for merges
that should result in an error if no --include-merges is provided.

(But, yes, as git-squash is porcelain this doesn't matter at all.)

Regards,
  Stephan

-- 
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F

Re: squashing patches

[Junio C Hamano]

Stephan Beyer <s-beyer@gmx.net> writes:

> So I wonder if file --squash is useful, too, or even --squash as an
> general option. The latter means that you could squash merge commits
> into other commits, too.
>
> We've also discussed the non-atomic approach of doing something like
> 	pick ( a b c d )	# or another syntax for that
> for picking multiple commits into one.
> In my current point of view, this does not seem right, as it:
>  - is not atomic ;), and...
>  - Well, the approach could be used for "file ( a b c d )", too,
>    but it doesn't help for squashing commits AND patches.
>
> Comments? Opinions? Ideas?

I actually expected that the primitive command sequence the backward
compatible "edit" would expand to would be a pair, "pick" followed by
"pause".  Whenever the sequencer sees "pause", it does not do anything but
reports the current HEAD and gives the control back to the user, so that
the user can do amend or whatever before telling you to --continue.

Similarly, I expected the backward-compatible "squash" to expand to a
pair, "pick" followed by "zucchini 2".  Whenever the sequencer sees
"zucchini <n>", it prepares a commit log to describe the top <n> commits,
resets HEAD back by <n> commits, and gives control to your editor.

About the other parts in your original message:

 - The "tag" command looked a little out of place;

 - I would have called your "file" command "patch" (we might want to have
   another file related operation later).

 - The --author option presumably would be to lie about the authorship but
   without taking it from an existing commit.  (1) Don't you need to have
   an option similar to -C option of "git-commit"?  (2) Don't you need to
   also be able to lie about the author timestamp?

Re: squashing patches

[Stephan Beyer]

> > Comments? Opinions? Ideas?
> 
> I actually expected that the primitive command sequence the backward
> compatible "edit" would expand to would be a pair, "pick" followed by
> "pause".

Something "like" this was my veeeery first approach: "edit" with commit
was the backwards-compatible "edit" and without arguments was your
"pause".
Example:
	pick ea7beef
	edit		# or "pause" as you suggested
After a little discussion this became:
	pick --edit ea7beef

And I can't objectively say what's better

> Whenever the sequencer sees "pause", it does not do anything but
> reports the current HEAD and gives the control back to the user, so that
> the user can do amend or whatever before telling you to --continue.

Yes.

> Similarly, I expected the backward-compatible "squash" to expand to a
> pair, "pick" followed by "zucchini 2".  Whenever the sequencer sees
> "zucchini <n>", it prepares a commit log to describe the top <n> commits,
> resets HEAD back by <n> commits, and gives control to your editor.

That's right.  See the RFC/PATCH about git-squash mail or its parent
mail[1] ;-)

 1. http://article.gmane.org/gmane.comp.version-control.git/84391 2) ff.
    and
    http://article.gmane.org/gmane.comp.version-control.git/84420

The open question is, if we should do this by a natural number <n> or
by a commit.
The natural number approach seems easier, but imagine someone pauses
and does some commits (not --amend)... Here the behavior of these
approaches differs. ;-)

> About the other parts in your original message:
> 
>  - The "tag" command looked a little out of place;

Eh, why?

>  - I would have called your "file" command "patch" (we might want to have
>    another file related operation later).

Ok. "file" and "patch" were both choices to me. Don't know, why I
decided for "file".

>  - The --author option presumably would be to lie about the authorship but
>    without taking it from an existing commit.  (1) Don't you need to have
>    an option similar to -C option of "git-commit"?  (2) Don't you need to
>    also be able to lie about the author timestamp?

Right. ;)

Regards and thanks,
  Stephan

-- 
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F

Re: squashing patches

[Jeff King]

On Mon, Jun 09, 2008 at 10:43:27PM +0200, Stephan Beyer wrote:

> Something "like" this was my veeeery first approach: "edit" with commit
> was the backwards-compatible "edit" and without arguments was your
> "pause".
> Example:
> 	pick ea7beef
> 	edit		# or "pause" as you suggested
> After a little discussion this became:
> 	pick --edit ea7beef
> 
> And I can't objectively say what's better

I am just watching this from the sidelines, but it seems to me that you
are best off creating the directives as modular and orthogonal as
possible.  It is very simple to create "pick $1; edit" from "pick --edit
$1" later, but it is more difficult to go the other way around.

IOW, worry early about flexibility, and later you can build syntactic
sugar if you need to.

-Peff

Re: squashing patches

[Stephan Beyer]

Hi,

> I am just watching this from the sidelines, but it seems to me that you
> are best off creating the directives as modular and orthogonal as
> possible.  It is very simple to create "pick $1; edit" from "pick --edit
> $1" later, but it is more difficult to go the other way around.

Perhaps it is just me, but isn't "pick X ; edit"
more modular and orthogonal than "pick --edit X"? ;-)

But yes, the "pick --edit X" => "pick X ; edit" conversion seems easier.

And I'm slightly confused which solution seems better to you for now ;)

Regards,
  Stephan

-- 
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F

Re: squashing patches

[Jeff King]

On Tue, Jun 10, 2008 at 01:57:33AM +0200, Stephan Beyer wrote:

> > I am just watching this from the sidelines, but it seems to me that you
> > are best off creating the directives as modular and orthogonal as
> > possible.  It is very simple to create "pick $1; edit" from "pick --edit
> > $1" later, but it is more difficult to go the other way around.
> 
> Perhaps it is just me, but isn't "pick X ; edit"
> more modular and orthogonal than "pick --edit X"? ;-)

Sorry, I chose a bad phrase. When I said "create X from Y", I meant
"when the user gives you Y, you can produce the canonical X". Not "once
we have the canonical Y, you can create X out of it."

So I appear to have said the exact opposite of what I meant. :)

> But yes, the "pick --edit X" => "pick X ; edit" conversion seems easier.

Exactly.

-Peff

Re: squashing patches

[Junio C Hamano]

Stephan Beyer <s-beyer@gmx.net> writes:

>> > Comments? Opinions? Ideas?
>> 
>> I actually expected that the primitive command sequence the backward
>> compatible "edit" would expand to would be a pair, "pick" followed by
>> "pause".
>
> Something "like" this was my veeeery first approach: "edit" with commit
> was the backwards-compatible "edit" and without arguments was your
> "pause".
> Example:
> 	pick ea7beef
> 	edit		# or "pause" as you suggested
> After a little discussion this became:
> 	pick --edit ea7beef
>
> And I can't objectively say what's better

Me neither.  My "expectation" came primarily from what I understood,
namely you seemt to prefer atomism, and not from "I want things to be this
way".

If we think any proposed and future instruction would be reasonable to
have --edit option, then all insn implementation would need to support
"edit" option anyway, and the users do not have to remember which insn
does and does not support --edit so both forms would work equally well
(and "--edit option" would make the insn stream shorter, which may be
good).  But probably "mark --edit" and "reset --edit" would not make
sense, so a separate "edit" insn may be more generic and useful.

> The open question is, if we should do this by a natural number <n> or
> by a commit.
> The natural number approach seems easier, but imagine someone pauses
> and does some commits (not --amend)... Here the behavior of these
> approaches differs. ;-)

I see.  Not using count but setting an explicit mark and using that commit
sounds more robust, considering that use case.

>> About the other parts in your original message:
>> 
>>  - The "tag" command looked a little out of place;
>
> Eh, why?

Why not?

I just wondered why there was a support only for lightweight tag there.
You do not have "branch" command, and your "tag" command does not seem to
support things like -a, -s, -m<msg>, etc.  Not that I think you should
support full "tag" and "branch" command set, but it seemed a bit odd.

Re: squashing patches

[Stephan Beyer]

Hi,

> > Example:
> > 	pick ea7beef
> > 	edit		# or "pause" as you suggested
> > After a little discussion this became:
> > 	pick --edit ea7beef
> >
> > And I can't objectively say what's better
> 
> Me neither.  My "expectation" came primarily from what I understood,
> namely you seemt to prefer atomism, and not from "I want things to be this
> way".

Yes I prefer atomism, because it helps to keep things simple and stupid.

> If we think any proposed and future instruction would be reasonable to
> have --edit option, then all insn implementation would need to support
> "edit" option anyway, and the users do not have to remember which insn
> does and does not support --edit

Currently every insn where it makes sense (indeed, this may be
subjective) does support --edit.  So currently "file" (or "patch"),
"pick", "merge" and "squash" do, because they commit something.

But you are right (and I think Peff meant the same), that the separate
insn is more generic and thus it's more flexible.

So would you prefer a)"pause" or b)"edit"?
Or as text:
a)
edit [<commit>]::
	Pauses the sequencer process to let you manually make changes.
+
After you have finished your changes and added them to the index,
invoke `git-sequencer --continue`.
If you only want to edit the last commit message with an editor,
run `git commit --amend` (see linkgit:git-commit[1]) before.
+
If `<commit>` is given, pick `<commit>` first. This is a short form for
`pick <commit>` and `edit` on separate lines.)

b)
edit <commit>::
	Picks a commit and pauses the sequencer process to let you
	make changes.
+
This is a short form for `pick <commit> and `pause` on separate lines.

pause::		# (perhaps options may occur later, if they make sense)
	Pauses the sequencer process to let you manually make changes.
+
After you have finished your changes and added them to the index, 
invoke `git-sequencer --continue`.
If you only want to edit the last commit message with an editor,
run `git commit --amend` (see linkgit:git-commit[1]) before.


More flexible and modular seems to be the approach b).
But I want your opinion to go sure. ;-)

> I see.  Not using count but setting an explicit mark and using that commit
> sounds more robust, considering that use case.

So I take the --up-to syntax from Paolo?
Seemed right to me.

> >>  - The "tag" command looked a little out of place;
> >
> > Eh, why?
> 
> Why not?

Because it's practical.
The marks are only available during sequencer process and it's just
useful to tag something that you can reach by that name afterwards
(or during sequencing, too).
The user could use tag instead of mark if he wants to keep the ref
after sequencing.
I also can imagine sequencer-using scripts, that want to tag a version
release or something.

> I just wondered why there was a support only for lightweight tag there.

Basically because it's in next :)
And then I thought "Ok, nice. Let's keep it.".

> You do not have "branch" command, and your "tag" command does not seem to
> support things like -a, -s, -m<msg>, etc.

Hmmm, -a, -s and -m could even be useful.

Regards,
  Stephan

-- 
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F

Re: [RFC] git-sequencer.txt

[Jakub Narebski]

Stephan Beyer <s-beyer@gmx.net> writes:

> ------------------------------ git-sequencer.txt ------------------------------
> git-sequencer(1)
> ================
> 
> NAME
> ----
> git-sequencer - Execute a sequence of git instructions
> 
> 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.

> '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>,...).

> TODO FILE FORMAT
> ----------------
> edit <commit>::
> file [<options>] <file>::
> mark <mark>::
> merge [<options>] <commit-ish1> <commit-ish2> ... <commit-ishN>::

> pick [<options>] <commit>::
> 	Pick (see linkgit:git-cherry-pick[1]) a commit.
> 	Sequencer will pause on conflicts.

Two comments (as I don't use "git rebase -i", preferring to work with
StGIT, Quilt-like patch management interface).

First, if git-sequencer is to become backbone for cherry-pick,
allowing for example long requested cherry-picking multiple commits
(squasing them or not into single commit), is should be able to use it
also for git-revert.  Thus I'd like to have either "pick -R" or
"revert" command.

Second, about "pick" accepring (I guess) git-cherry-pick options: I
would like to have documentation on '--mainline <parent-number>'
option in git-sequencer manpage, or at lest explicitely mentioned that
it can be used to pick merge commits.  BTW, is "pick --no-commit"
symmetric equivalent^W alternative to "squash"?

-- 
Jakub Narebski
Poland
ShadeHawk on #git

Re: [RFC] git-sequencer.txt

[Stephan Beyer]

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

The workflow is like this:
 $ git rebase -i
 ...
 Sequencing (3/5)
 Conflict!
 Fix and do git-rebase --continue
 $
 $ # fix
 $
 $ git sequencer --continue
 Use git-rebase --continue.
 $ git-rebase --continue
 ...
 Sequencing finished.
 Succesfully rebased foo bar blub.

The string "git-rebase --continue" (or "git-am --resolved") must also be
-- somehow (environment?) -- transferred to git...
The same for --abort and --skip.

Ideas for a clean solution?

> > TODO FILE FORMAT
> > ----------------
> > edit <commit>::
> > file [<options>] <file>::
> > mark <mark>::
> > merge [<options>] <commit-ish1> <commit-ish2> ... <commit-ishN>::
> 
> > pick [<options>] <commit>::
> > 	Pick (see linkgit:git-cherry-pick[1]) a commit.
> > 	Sequencer will pause on conflicts.
> 
> Two comments (as I don't use "git rebase -i", preferring to work with
> StGIT, Quilt-like patch management interface).

Oh, I've neither experienced stgit nor quilt, but I can imagine that it
is some stack-(or push/pop)-based patch management.

> Thus I'd like to have either "pick -R" or "revert" command.

Ok ;-)

> Second, about "pick" accepring (I guess) git-cherry-pick options: I
> would like to have documentation on '--mainline <parent-number>'
> option in git-sequencer manpage, or at lest explicitely mentioned that
> it can be used to pick merge commits.

Btw it is currently pretty stupid and doesn't accept any git-cherry-pick
options.

And I didn't know that --mainline exists. I've always thought the first
parent in the parent list is the "mainline".
Well, seems to be an easier-to-use alternative to the "merge" insn if you 
want to keep the non-mainline parents, commit message and authorship.
So I think, it's ok to support it ;)

> BTW, is "pick --no-commit"  symmetric equivalent^W alternative to "squash"?

Seems that it's yet another variant to realize squash, but less generic
than the reset --soft ; commit approach.

Regards,
  Stephan

-- 
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F

Re: [RFC] git-sequencer.txt

[Christian Couder]

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.

Re: [RFC] git-sequencer.txt

[Stephan Beyer]

Hi,

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

It's another variant, but then with every new sequencer-user you have to
add another entry to the "sequencer caller database".

That means: if a user writes a script that uses sequencer he has to make
changes to sequencer itself. Baaad for extensibility.

Regards,
  Stephan

-- 
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F

Re: [RFC] git-sequencer.txt

[Christian Couder]

Hi,

Le mardi 10 juin 2008, Stephan Beyer a écrit :
> Hi,
>
> > 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".
>
> It's another variant, but then with every new sequencer-user you have to
> add another entry to the "sequencer caller database".
>
> That means: if a user writes a script that uses sequencer he has to make
> changes to sequencer itself. Baaad for extensibility.

We could have config options for that. For example:

[sequenceruser "user_script1"]
	filename = user-script1-todo
	continuecall = user_script1.sh --continue

Regards,
Christian.

Re: [RFC] git-sequencer.txt

[Daniel Barkalow]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2181 bytes --]

On Tue, 10 Jun 2008, Christian Couder wrote:

> Le mardi 10 juin 2008, Stephan Beyer a écrit :

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

I expect that most script users will do something like:

  generate-todo-file | git-sequencer

So, if there's anything to do to clean up after the outer script, the file 
git-sequencer gets is probably stdin.

One solution would be to have a "caller" option to sequencer, and when 
sequencer finishes, it runs "git $caller --cleanup". That way, you can use 
"git sequencer --continue", and it will do the caller-specific cleanup 
(also, don't forget the --abort case).

It might also be good to have options for some generic stuff, like "remove 
a particular directory" for callers that can just put all their temporary 
stuff in a single directory and don't have anything to clean up other than 
getting rid of it.

	-Daniel
*This .sig left intentionally blank*

Re: [RFC] git-sequencer.txt

[Jakub Narebski]

On Wed, 10 Jun 2008, Stephan Beyer wrote:

Could you please try not to cut (remove) quotes attributions? It is harder to follow discussion without them...

> Jakub Narebski wrote:

>> Second, about "pick" accepring (I guess) git-cherry-pick options: I
>> would like to have documentation on '--mainline <parent-number>'
>> option in git-sequencer manpage, or at lest explicitely mentioned that
>> it can be used to pick merge commits.
> 
> Btw it is currently pretty stupid and doesn't accept any git-cherry-pick
> options.
> 
> And I didn't know that --mainline exists. I've always thought the first
> parent in the parent list is the "mainline".

It depends on the workflow.  Git tries to not make first parent all
that special.  Due to using fast-forward yourline can actually be
second parent.

Probably better name would be --pick-parent.  Note that without this
option there is no way to "pick", as in pick changes brought by commit,
merge commit (unless you default to first-parent...).

> Well, seems to be an easier-to-use alternative to the "merge" insn if you 
> want to keep the non-mainline parents, commit message and authorship.
> So I think, it's ok to support it ;)

They are two opposite sides of spectrum.  "pick --mainline" is to pick
a merge, "merge" is to create merge commit.  You might want to make
merge into ordinary commit, make ordinary commit into merge, make merge
into merge preserving other parents, make merge into merge rewriting all
parents.

> > BTW, is "pick --no-commit"  symmetric equivalent^W alternative to "squash"?
> 
> Seems that it's yet another variant to realize squash, but less generic
> than the reset --soft ; commit approach.

I'm not sure if less generic.  You can use "pick; squash; squash" or 
"no-commit; no-commit; pick".
-- 
Jakub Narebski
Poland

[RFCv2/FYI] git-sequencer.txt

[Stephan Beyer]

Hi,

> I inline-attached the documentation (and somehow specification)
> for git-sequencer (my GSoC'08 project) for you to comment on.

Here's the second and - if there are no big protests - last attempt
before I send the prototype RFC/PATCH patchset to the list.

Note that I didn't add the "comment" (or "amend") insn[1] proposed by
Pierre Habouzit currently, but this is no problem.

 1. http://thread.gmane.org/gmane.comp.version-control.git/84616

There's also an undocumented --caller option.
I mean, it is as undocumented as "git-am --rebasing",
because it should only be used by sequencer user scripts.

Regards,
  Stephan

------------------------------ git-sequencer.txt ------------------------------
git-sequencer(1)
================

NAME
----
git-sequencer - Execute a sequence of git instructions

SYNOPSIS
--------
[verse]
'git-sequencer' [--batch] [--onto=<base>] [--verbose] [<file>]
'git-sequencer' --continue | --skip | --abort | --edit | --status


DESCRIPTION
-----------
Executes a sequence of git instructions to HEAD or `<base>`.
The sequence is given by `<file>` or standard input.
Also see 'TODO FILE FORMAT' below.

Before doing anything, the TODO file is checked for correct syntax 
and sanity.

In case of a conflict or request in the TODO file, git-sequencer will
pause. On conflict you can use git-diff to locate the markers (`<<<<<<`) 
and make edits to resolve the conflict.

For each file you edit, you need to tell git the changes by doing

    git add <file>

After resolving the conflict manually and updating the index with the
desired resolution, you can continue the sequencing process with

    git sequencer --continue

Alternatively, you can undo the git-sequencer progress with

    git sequencer --abort

or skip the current instruction with

    git sequencer --skip

or correct the TODO file with

    git sequencer --edit

During pauses or when finished with the sequencing task, the current
HEAD will always be the result of the last processed instruction.


OPTIONS
-------
<file>::
	Filename of the TODO file.  If omitted, standard input is used.
	See 'TODO FILE FORMAT' below.

-B::
--batch::
	Run in batch mode. If unexpected user intervention is needed
	(e.g. a conflict or the need to run an editor), git-sequencer fails.
+
Note that the sanity check fails, if you use this option
and an instruction like `edit` or `pause`.

--onto=<base>::
	Checkout given commit or branch before sequencing.
	If you provide a branch, sequencer will make the provided
	changes on the branch, i.e. the branch will be changed.

--continue::
	Restart the sequencing process after having resolved a merge conflict.

--abort::
	Restore the original branch and abort the sequence operation.

--skip::
	Restart the sequencing process by skipping the current patch.

--status::
	Show the current status of git-sequencer and what
	operations can be done to change that status.

--edit::
	Invoke editor to edit the undone rest of the TODO file.
+
The file is syntax- and sanity-checked afterwards, so that you can 
safely run `git sequencer --skip` or `--continue` after editing.
If you nonetheless noticed that you made a mistake, you can 
overwrite `.git/sequencer/todo` with `.git/sequencer/todo.old` and
rerun `git sequencer --edit`.
+
If the check fails you are prompted if you want to correct your 
changes, edit again, cancel editing or really want to save.

-v::
--verbose::
	Be more verbose. [XXX: to be defined more accurately, i.e. print diffstat]


NOTES
-----

When sequencing, it is possible, that you are changing the history of
a branch in a way that can cause problems for anyone who already has 
a copy of the branch in their repository and tries to pull updates from
you.  You should understand the implications of using git-sequencer on
a repository that you share.

git-sequencer will usually be called by another git porcelain, like
linkgit:git-am[1] or linkgit:git-rebase[1].


TODO FILE FORMAT
----------------

The TODO file contains basically one instruction per line.

Blank lines will be ignored. 
All characters after a `#` character will be ignored until the end of a line.

The following instructions can be used:


edit <commit>::
	Picks a commit and pauses the sequencer process to let you
	make changes.
+
This is a short form for `pick <commit> and `pause` on separate lines.


mark <mark>::
	Set a symbolic mark for the last commit.
	`<mark>` is an unsigned integer starting at 1 and
	prefixed with a colon, e.g. `:1`.
+
The marks can help if you want to refer to commits that you
created during the sequencer process, e.g. if you want to
merge such a commit.
+
The set marks are removed after the sequencer has completed.


merge [<options>] <commit-ish1> <commit-ish2> ... <commit-ishN>::
	Merge commits into HEAD.
+
A commit can also be given by a mark, if prefixed with a colon.
+
If you do not provide a commit message (using `-F`, `-m`, `--reference` 
or `--standard`), an editor will be invoked.
+
See the following list and 'GENERAL OPTIONS' for values of `<option>`:

	--standard;;
		Generates a commit message like 'Merge ... into HEAD'.
		See also linkgit:git-fmt-merge-msg[1].
	
	-s <strategy>;;
	--strategy=<strategy>;;
		Use the given merge strategy.
		See also linkgit:git-merge[1].


pick [<options>] <commit>::
	Pick (see linkgit:git-cherry-pick[1]) a commit.
	Sequencer will pause on conflicts.
+
See the following list and 'GENERAL OPTIONS' for values of `<option>`:

	-R;;
	--revert;;
		Revert the changes introduced by pick <commit>.
	
	--mainline=<n>;;
	--pick-parent=<n>;;
		Allows you to pick merge commits by specifying the
		parent number (beginning from 1) to let sequencer
		replay the changes relative to the specified parent.


patch [<options>] <file>::
	If file `<file>` is a pure (diff) patch, then apply the patch.
	If no `--message` option is given, an editor will
	be invoked to enter a commit message.
+
If `<file>` is a linkgit:git-format-patch[1]-formatted patch,
then the patch will be commited.
+
See the following list and 'GENERAL OPTIONS' for values of `<option>`:

	-3;;
	--3way;;
		When the patch does not apply cleanly, fall back on
		3-way merge, if the patch records the identity of blobs
		it is supposed to apply to, and we have those blobs
		available locally.

	-k;;
		Pass `-k` flag to `git-mailinfo` (see linkgit:git-mailinfo[1]).

	-n;;
		Pass `-n` flag to `git-mailinfo` (see
		linkgit:git-mailinfo[1]).

	-u;;
		Pass `-u` flag to `git-mailinfo` (see linkgit:git-mailinfo[1]).
		The proposed commit log message taken from the e-mail
		is re-coded into UTF-8 encoding (configuration variable
		`i18n.commitencoding` can be used to specify project's
		preferred encoding if it is not UTF-8).
+
This was optional in prior versions of git, but now it is the
default. You could use `-n` to override this.

	-*;;
		Any other dash-prefixed option is passed to
		linkgit:git-apply[1].
		This is especially useful for flags like
		`--reverse`, `-C<n>`, `-p<n>` or `--whitespace=<action>`.


pause::
	Pauses the sequencer process to let you manually make changes.
	For example, you can re-edit the done commit, fix bugs or typos,
	or you can make further commits on top of HEAD before continuing.
+
After you have finished your changes and added them to the index,
invoke `git-sequencer --continue`.
If you only want to edit the last commit message with an editor,
run `git commit --amend` (see linkgit:git-commit[1]) before.


reset <commit-ish>::
	Go back (see linkgit:git-reset[1] `--hard`) to commit `<commit-ish>`.
	`<commit-ish>` can also be given by a mark, if prefixed with a colon.


squash [<options>] <commit>::
	Add the changes introduced by `<commit>` to the last commit.
+
See 'GENERAL OPTIONS' for values of `<option>`.

squash [<options>] --up-to <mark>::
	Squash all commits up to the given mark into one commit.
	There must not be any merge commits in between.
+
See the following list and 'GENERAL OPTIONS' for values of `<option>`:

	--collect-signoffs;;
		Collect the Signed-by-off: lines of each commit and
		add them to the squashed commit message.
	
	--include-merges;;
		Sanity check does not fail if you have merges
		between HEAD and <mark>.


tag <tag>::
	Set tag `<tag>` to the current HEAD,
	see also linkgit:git-tag[1].
	If another commit is tagged `<tag>`, it will lose this tag,
	i.e. the tag will be reset to HEAD.



GENERAL OPTIONS
---------------

Besides some special options, the instructions
`patch`, `merge`, `pick`, `squash` take the following general options:

--author=<author>::
	Override the author name and e-mail address used in the commit.
	Use `A U Thor <author@example.com>` format.

-C <commit-ish>::
--reuse-commit=<commit-ish>::
--reference=<commit-ish>::
	Reuse message and authorship data from specified commit.

-M <commit-ish>
--reuse-message=<commit-ish>::
	Reuse message from specified commit.
	Note, that only the commit message is reused
	and not the authorship information.

-F <file>::
--file=<file>::
	Take the commit message from the given file.

-m <msg>::
--message=<msg>::
	Use the given `<msg>` as the commit message.

-s::
--signoff::
	Add `Signed-off-by:` line to the commit message (if not yet there),
	using the committer identity of yourself.


RETURN VALUES
-------------

git-sequencer returns:

* `0`, if git-sequencer successfully completed all the instructions
       in the TODO file or successfully aborted after
       `git-sequencer --abort`,
* `2`, on user-requested pausing, e.g.
       when using the `edit` instruction.
* `3`, on pauses that are not requested, e.g.
       when there are conflicts to resolve.
* any other value on error, e.g.
  syntax errors in the TODO file or
  running git-sequencer on a bare repository.


EXAMPLES
--------

XXX [Here the usage of all commands should become clear,
but it's braindamaged to write this section as long as the file format
is in discussion.]


SEE ALSO
--------
linkgit:git-add[1],
linkgit:git-am[1],
linkgit:git-cherry-pick[1],
linkgit:git-commit[1],
linkgit:git-fmt-merge-msg[1],
linkgit:git-format-patch[1],
linkgit:git-rebase[1],
linkgit:git-reset[1],
linkgit:git-tag[1]


Authors
-------
XXX

Documentation
-------------
Documentation by Stephan Beyer and the git-list <git@vger.kernel.org>.

GIT
---
Part of the linkgit:git[1] suite

-- 
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F

Re: [RFCv2/FYI] git-sequencer.txt

[Paolo Bonzini]

> 	--collect-signoffs;;
> 		Collect the Signed-by-off: lines of each commit and
> 		add them to the squashed commit message.

I think this makes sense only if -m/-F/-C/-c (see later) is used, 
because otherwise the default behavior would be to concatenate all 
messages and call the editor, right?  Would it be a no-op if those 
options are not given?

> tag <tag>::
> 	Set tag `<tag>` to the current HEAD,
> 	see also linkgit:git-tag[1].
> 	If another commit is tagged `<tag>`, it will lose this tag,
> 	i.e. the tag will be reset to HEAD.

Is this a lightweight or a heavyweight tag?  I guess lightweight -- the 
tag command should probably support -a, -s and -u like git-tag does. 
Unless -c/-C/-F/-m is given, the sequencer will then run the editor.

> -C <commit-ish>::
> --reuse-commit=<commit-ish>::
> --reference=<commit-ish>::
> 	Reuse message and authorship data from specified commit.

Why --reference?  Also,

> -M <commit-ish>
> --reuse-message=<commit-ish>::
> 	Reuse message from specified commit.
> 	Note, that only the commit message is reused
> 	and not the authorship information.

For consistency with git-commit I would think it's better to have

   -c <commit-ish>::
   -C <commit-ish>::
   --reedit-message=<commit-ish>::
   --reuse-message=<commit-ish>::
	Take existing commit object, and reuse the log message and the
         authorship information (including the timestamp) when creating
         the commit. With -C (or --reuse-message), the editor is not
	invoked; with -c (or --reedit-message) the user can further edit
	the commit message.

(I know it's confusing that it's reusing the message too, but...) and 
then a separate option:

   -A
   --author-override::
	Force authorship information for commits created by the command
	to be the data in git's configuration files.

... if it is not too complicated to implement.

To satisfy Pierre's comment, you might also add a "-e" general option, 
which forces an invocation of the editor -- even if -C/-m/-F are given, 
and even if the command is pick/patch/merge.  I guess that in order to 
support -C/-m/-F you already have to use git-cherry-pick and git-merge's 
--no-commit options, so it should not be hard to implement.

Paolo

Re: [RFCv2/FYI] git-sequencer.txt

[Stephan Beyer]

Hi,

On Wed, Jun 11, 2008 at 06:31:28PM -0700,
Paolo Bonzini <bonzini@gnu.org> wrote to git@vger.kernel.org:
>> 	--collect-signoffs;;
>> 		Collect the Signed-by-off: lines of each commit and
>> 		add them to the squashed commit message.
>
> I think this makes sense only if -m/-F/-C/-c (see later) is used,  
> because otherwise the default behavior would be to concatenate all  
> messages and call the editor, right?  Would it be a no-op if those  
> options are not given?

No, because the default behavior is cat it all together and call the
editor, the user sees in the editor:

	Message of commit 1

	Signed-off-by: A

	Message of commit 2

	Signed-off-by: B

	Message of commit 3

	Signed-off-by: A
	Signed-off-by: C

And with --collect-signoffs this could be like:

	Message of commit 1

	Message of commit 2

	Message of commit 3

	Signed-off-by: A
	Signed-off-by: B
	Signed-off-by: C

>> tag <tag>::
>> 	Set tag `<tag>` to the current HEAD,
>> 	see also linkgit:git-tag[1].
>> 	If another commit is tagged `<tag>`, it will lose this tag,
>> 	i.e. the tag will be reset to HEAD.
>
> Is this a lightweight or a heavyweight tag?  I guess lightweight -- the  
> tag command should probably support -a, -s and -u like git-tag does.  
> Unless -c/-C/-F/-m is given, the sequencer will then run the editor.

It is a lightweight tag currently.
Well, I've taken it because it was in rebase-i of "next" and currently
I use it because it makes one merge test case really simple by tagging
the parents of the planned merge.

I don't know if it is really useful to sequencer users and I don't know
if its better to drop from the documentation but keep it for my test 
case ;-)

Because I'm pretty unsure about it, I didn't change anything on "tag" 
after Junio's complaints about it.

>> -C <commit-ish>::
>> --reuse-commit=<commit-ish>::
>> --reference=<commit-ish>::
>> 	Reuse message and authorship data from specified commit.
>
> Why --reference?

I know that it's inconsistent to git-commit and I hoped nobody would
notice. ;-)

The reason why I didn't want `-C' to be `--reuse-message' is:
 1. it is a misleading long option name, and
 2. some days ago the long option was not really documented,
    so everyone and everything is using -C.
    (See
	git show bc47c29
     and/or
	git grep -e reuse-message
     in git.git)

I think that --reuse-commit is much less misleading, since 
--reuse-message-and-authorship is too long ;-)
And Joerg Sommer's patchset which migrated to next introduced the
term "reference merge" (see "git show d9711a80", the first "die" in the
first hunk), and I thought the term "reference" is nicer than
"reuse message and authorship". But, of course, I also see the
disadvantage that it can be mixed up with refs.

I still vote for "-C/--reuse-commit" and because nobody and
nothing uses --reuse-message in git-commit I even dare propose
to change it to --reuse-commit there.

>> -M <commit-ish>
>> --reuse-message=<commit-ish>::
>> 	Reuse message from specified commit.
>> 	Note, that only the commit message is reused
>> 	and not the authorship information.

This is something I'd like to keep.

> For consistency with git-commit I would think it's better to have
>
>   -c <commit-ish>::
>   -C <commit-ish>::
>   --reedit-message=<commit-ish>::
>   --reuse-message=<commit-ish>::
> 	Take existing commit object, and reuse the log message and the
>         authorship information (including the timestamp) when creating
>         the commit. With -C (or --reuse-message), the editor is not
> 	invoked; with -c (or --reedit-message) the user can further edit
> 	the commit message.
>
> (I know it's confusing that it's reusing the message too, but...)

Later you speak of using the -e option to force edit of the message.
I think that "-c" is not needed if you can use "-C f00babe -e".

> and then a separate option:
>
>   -A
>   --author-override::
> 	Force authorship information for commits created by the command
> 	to be the data in git's configuration files.
>
> ... if it is not too complicated to implement.

Currently you can pass --author as a general option.
Perhaps this is not as easy to handle for the user, but if we
really really really want the -A/--author-override, we can add it later.

> To satisfy Pierre's comment, you might also add a "-e" general option,  
> which forces an invocation of the editor -- even if -C/-m/-F are given,  
> and even if the command is pick/patch/merge.  I guess that in order to  
> support -C/-m/-F you already have to use git-cherry-pick and git-merge's  
> --no-commit options, so it should not be hard to implement.

I hoped someone will come up with -e ;-)
So "reinvent" a general option -e/--edit that just goes sure to invoke
an editor should be fine.

Regards,
  Stephan

-- 
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F

[RFC/PATCH] git-commit: Change --reuse-message to --reuse-commit.

[Stephan Beyer]

The reason for the change is, that --reuse-message is
misleading, because the long option name does not tell
the user, that the authorship information is kept.
---
Hi,

I can imagine the negative feedback as
 * don't change long-time-used options
 * --reuse-commit, but --reedit-message?
 * ...

But I want to give it a try ;-)
 1. I think that the --reuse-message long option 
    is not used by anyone, but you can quickly generate
    a counterexample :)
    
    Why not used? Because it was not documented in 
    git-commit.txt until "Sun Jun 8 03:36:08 2008 +0200"
    (git show bc47c29).
 2. Later we could add something like -M/--reuse-message
    that just reuses the message and not the authorship.

See also the parent mail.
  http://article.gmane.org/gmane.comp.version-control.git/84760

Regards,
  Stephan

 Documentation/git-commit.txt |    2 +-
 builtin-commit.c             |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index 7e8b4ff..f713f40 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -59,7 +59,7 @@ OPTIONS
 	told git about are not affected.
 
 -C <commit>::
---reuse-message=<commit>::
+--reuse-commit=<commit>::
 	Take an existing commit object, and reuse the log message
 	and the authorship information (including the timestamp)
 	when creating the commit.
diff --git a/builtin-commit.c b/builtin-commit.c
index 90200ed..9c0b2da 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -90,7 +90,7 @@ static struct option builtin_commit_options[] = {
 	OPT_STRING(0, "author", &force_author, "AUTHOR", "override author for commit"),
 	OPT_CALLBACK('m', "message", &message, "MESSAGE", "specify commit message", opt_parse_m),
 	OPT_STRING('c', "reedit-message", &edit_message, "COMMIT", "reuse and edit message from specified commit "),
-	OPT_STRING('C', "reuse-message", &use_message, "COMMIT", "reuse message from specified commit"),
+	OPT_STRING('C', "reuse-commit", &use_message, "COMMIT", "reuse message from specified commit"),
 	OPT_BOOLEAN('s', "signoff", &signoff, "add Signed-off-by:"),
 	OPT_STRING('t', "template", &template_file, "FILE", "use specified template file"),
 	OPT_BOOLEAN('e', "edit", &edit_flag, "force edit of commit"),
-- 
1.5.5.3

Re: [RFCv2/FYI] git-sequencer.txt

[Paolo Bonzini]

> The reason why I didn't want `-C' to be `--reuse-message' is:
>  1. it is a misleading long option name, and
>  2. some days ago the long option was not really documented,
>     so everyone and everything is using -C.
>     (See
> 	git show bc47c29
>      and/or
> 	git grep -e reuse-message
>      in git.git)

Yes, I agree (though I still maintain that --reuse-message is better if 
only because it is more consistent).

>>> -M <commit-ish>
>>> --reuse-message=<commit-ish>::
>>> 	Reuse message from specified commit.
>>> 	Note, that only the commit message is reused
>>> 	and not the authorship information.
> 
> This is something I'd like to keep.

Do you have a use case?

> Later you speak of using the -e option to force edit of the message.
> I think that "-c" is not needed if you can use "-C f00babe -e".

Well, so is for git-commit but...

> Currently you can pass --author as a general option.
> Perhaps this is not as easy to handle for the user, but if we
> really really really want the -A/--author-override, we can add it later.

The idea is that -M = "-A -C ba123"...

Paolo

Re: [RFCv2/FYI] git-sequencer.txt

[Junio C Hamano]

Stephan Beyer <s-beyer@gmx.net> writes:

> Note that the sanity check fails, if you use this option
> and an instruction like `edit` or `pause`.
>
> --onto=<base>::
> 	Checkout given commit or branch before sequencing.
> 	If you provide a branch, sequencer will make the provided
> 	changes on the branch, i.e. the branch will be changed.

I think you called this --onto by modeling after rebase, but I am not sure
if that is a good generic naming.  Worse, "a branch that is not the
current one that is rebased" in rebase is not specified with "--onto" but
with the extra argument.

Is checking out that <base> branch considered as part of the sequencing
operation, or it is something that happens before the sequencing?  In
other words, if a sequencing stops and the user says "sequencer --abort",
where does it take the user back to?  The state the <base> is checked out,
or the state before that checkout happened?  Can't the front-end emit an
insn to checkout or detach as the first insn?

By the way, is it specified if sequencer will always work by:

 (1) remember the initial branch;

 (2) detach the HEAD;

 (3) run the operation;

 (4) and finally (unless the user says --abort) reattaching the original
     branch to the resulting HEAD?

That would mean the sequencer would essentially munge only one branch
(unless started from a detached HEAD state).  I think this is a reasonable
design decision (and a limitation) for the currently expected front-ends,
but I think this is a perfectly sane backend for filter-branch (without
any tree or content munging), and this limitation might later come back
and bite us.

> --skip::
> 	Restart the sequencing process by skipping the current patch.

"patch"?

What is the set of insn that can possibly give control back and give
you a chance to say "--skip"?

 - pick can conflict and --skip would mean "reset to the tree before the
   pick and continue on to the next insn";

 - Same goes for merge and patch (the semantics of "squash <commit>" is
   fuzzy to me);

 - pause can give control back to you.  What should --skip do?  I guess
   "no-op" is the right answer.

> --status::
> 	Show the current status of git-sequencer and what
> 	operations can be done to change that status.

Meaning "what insns have we done, what insn were we in the middle of
executing, and what insns are still remaining"?

> merge [<options>] <commit-ish1> <commit-ish2> ... <commit-ishN>::
> 	Merge commits into HEAD.
> +
> A commit can also be given by a mark, if prefixed with a colon.
> +
> If you do not provide a commit message (using `-F`, `-m`, `--reference` 
> or `--standard`), an editor will be invoked.
> +
> See the following list and 'GENERAL OPTIONS' for values of `<option>`:
>
> 	--standard;;
> 		Generates a commit message like 'Merge ... into HEAD'.
> 		See also linkgit:git-fmt-merge-msg[1].

It seems you are assuming (and I am not saying it is a bad assumption)
that sequencer first detached the HEAD and operates on that state until it
is done.  Perhaps we would want to reword "into HEAD" somehow?  If we are
rebasing branch "main", even if sequencer internally detaches the HEAD to
carry out individual steps, we would want to see the resulting history to
say "into main", wouldn't we?

> patch [<options>] <file>::
> 	If file `<file>` is a pure (diff) patch, then apply the patch.
> 	If no `--message` option is given, an editor will
> 	be invoked to enter a commit message.

Hmm.  Are there cases where you might want to feed more than one patches
and then finally make the commit?  You could emulate it with

	mark :1
	patch --message=dummy file1
        patch --message=dummy file2
	squash --upto :1

but it might make sense to allow more than one files for this use case,
like

	patch file1 file2

Although that would introduce another issue, which is what to do if file1
is a naked diff and file2 is a mbox (with possibly more than one patches),
or vice versa.

>...
> 	-u;;
> 		Pass `-u` flag to `git-mailinfo` (see linkgit:git-mailinfo[1]).
>...
> This was optional in prior versions of git, but now it is the
> default. You could use `-n` to override this.

I personally do not think it is worth supporting this b/c compatibility
option in a new command "sequencer".

> pause::
> 	Pauses the sequencer process to let you manually make changes.
> 	For example, you can re-edit the done commit, fix bugs or typos,
> 	or you can make further commits on top of HEAD before continuing.
> +
> After you have finished your changes and added them to the index,
> invoke `git-sequencer --continue`.
> If you only want to edit the last commit message with an editor,
> run `git commit --amend` (see linkgit:git-commit[1]) before.

before "saying --continue"?

> reset <commit-ish>::
> 	Go back (see linkgit:git-reset[1] `--hard`) to commit `<commit-ish>`.
> 	`<commit-ish>` can also be given by a mark, if prefixed with a colon.
>
> squash [<options>] <commit>::
> 	Add the changes introduced by `<commit>` to the last commit.

Just like you explained "edit <commit>" in terms of "pick" and "pause", we
might want to explain that this is "pick" and "squash --up-to HEAD^" (or
is it HEAD^^"?).

> +
> See 'GENERAL OPTIONS' for values of `<option>`.
>
> squash [<options>] --up-to <mark>::
> 	Squash all commits up to the given mark into one commit.
> 	There must not be any merge commits in between.

"In between" in "inclusive" sense, that is, neither <mark> nor HEAD cannot
be a merge?  Also --up-to feels somewhat wrong.  It is more like down-to
but perhaps "from" would be a better wording.

> 	--include-merges;;
> 		Sanity check does not fail if you have merges
> 		between HEAD and <mark>.

And what gets recorded?  A squashed merge?

A "squash --up-to <mark>" (modulo off-by-one I can never get straight X-<)
essentially:

	log --reverse <mark>.. >msg
	reset --soft <mark>
        commit --amend -F msg

so recording this result, when there is a merge in between, is like
running "merge --squash".

> tag <tag>::
> 	Set tag `<tag>` to the current HEAD,
> 	see also linkgit:git-tag[1].
> 	If another commit is tagged `<tag>`, it will lose this tag,
> 	i.e. the tag will be reset to HEAD.

Hmm.  It is hard to judge this without seeing how the front-ends use it.
It might make sense to give lower-level access to update-ref instead, so
that more than one branches can be updated as well, but I am not sure.
How would this interact with "--abort"?

Re: [RFCv2/FYI] git-sequencer.txt

[Stephan Beyer]

Hi,

Junio C Hamano wrote:
> > Note that the sanity check fails, if you use this option
> > and an instruction like `edit` or `pause`.
> >
> > --onto=<base>::
> > 	Checkout given commit or branch before sequencing.
> > 	If you provide a branch, sequencer will make the provided
> > 	changes on the branch, i.e. the branch will be changed.
> 
> I think you called this --onto by modeling after rebase, but I am not sure
> if that is a good generic naming.

First it was called --branch=<branch>, but I considered this to be wrong, 
because it's also possible to work on a detached tree.

Then I thought, that the rebase name is somehow right.

> Worse, "a branch that is not the current one that is rebased" in rebase is
> not specified with "--onto" but with the extra argument.
> 
> Is checking out that <base> branch considered as part of the sequencing
> operation, or it is something that happens before the sequencing?  In
> other words, if a sequencing stops and the user says "sequencer --abort",
> where does it take the user back to?  The state the <base> is checked out,
> or the state before that checkout happened?  Can't the front-end emit an
> insn to checkout or detach as the first insn?

Using git-sequencer --onto you specify the commit (or branch) where
the TODO insns are executed on.
(If you provide a branch, the branch ref points to the result of the 
sequencing process. If not, the sequencer process finishes on a detached
HEAD, just as it started.)

If you are on master and do
	git sequencer --onto foo todo-file
and later do a
	git sequencer --abort
then you are back on master "as if nothing happened".

If the process finishes successfully, you are on "foo".

I think this is quite handy and intuitive.

Btw, I didn't include the --onto stuff into the test suite of
my prototype branch yet, so the only thing that currently tests
this is git-rebase --interactive, that does a
	git-sequencer --onto "$ONTO" "$TODO"
and this works well.

I didn't include it yet, because the questions you addressed were
somehow still open to me.


If you don't provide --onto, it works on the current HEAD,
may it be a branch or detached HEAD.

> By the way, is it specified if sequencer will always work by:

Currently nothing of that is *specified*, but I can tell what the
prototype currently does.

> 
>  (1) remember the initial branch;

It saves the initial branch and commit, yes.

>  (2) detach the HEAD;

It currently does not detach the HEAD if a branch is given in --onto.
Imho this is a bug -- thanks -- but the fix is easy ;-)

>  (3) run the operation;
> 
>  (4) and finally (unless the user says --abort) reattaching the original
>      branch to the resulting HEAD?

Yes. (Currently the reattaching is done "automagically" because of the
bug it doesn't detach the head.)

> That would mean the sequencer would essentially munge only one branch
> (unless started from a detached HEAD state).  I think this is a reasonable
> design decision (and a limitation) for the currently expected front-ends,
> but I think this is a perfectly sane backend for filter-branch (without
> any tree or content munging), and this limitation might later come back
> and bite us.

Sorry, I currently don't understand you. ;-)
I've never used filter-branch so I'm a bit out of background here.

I currently wonder if it's better to remove --onto and let the 
sequencer users do that.
So that, for example, the rebase-i has to checkout the detached $ONTO
and then just call git-sequencer "$TODO".
(If we do it this way... Daniel, you were right *grin*)

What do you think?

> > --skip::
> > 	Restart the sequencing process by skipping the current patch.
> 
> "patch"?

"instruction". Thanks.

> What is the set of insn that can possibly give control back and give
> you a chance to say "--skip"?
> 
>  - pick can conflict and --skip would mean "reset to the tree before the
>    pick and continue on to the next insn";

Right.

>  - Same goes for merge and patch (the semantics of "squash <commit>" is
>    fuzzy to me);

Right.

I've already considered squash, I c&p a comment from the prototype:
 # Hm, somehow I don't think --skip on a conflicting squash
 # may be useful, but if someone wants to do it, it should 
 # do the obvious: skip what squash would do.

This means, if you do
	squash --up-to :1
it will just not squash all the commits from :1 to HEAD.
If you do
	squash <commit>
it will not pick <commit> and squash it with the last.

>  - pause can give control back to you.  What should --skip do?  I guess
>    "no-op" is the right answer.

Right. In other words: --skip equals --continue.
I've already considered this and when in "pause", git --status does not
tell the user that he can do --skip, although he can.

> > --status::
> > 	Show the current status of git-sequencer and what
> > 	operations can be done to change that status.
> 
> Meaning "what insns have we done, what insn were we in the middle of
> executing, and what insns are still remaining"?

If sequencer is paused somewhere:
 - what insns have we done
 - are we in a conflict or pause?
 - what insns are still remaining
 - what options does sequencer run with?
   (The only option that can be reported is currently
    --verbose)
 - what can the user run to abort/continue/skip?

And "Sequencer not running" if sequencer is not started
or has finished or whatever.

> > merge [<options>] <commit-ish1> <commit-ish2> ... <commit-ishN>::
> > 	Merge commits into HEAD.
> > +
> > A commit can also be given by a mark, if prefixed with a colon.
> > +
> > If you do not provide a commit message (using `-F`, `-m`, `--reference` 
> > or `--standard`), an editor will be invoked.
> > +
> > See the following list and 'GENERAL OPTIONS' for values of `<option>`:
> >
> > 	--standard;;
> > 		Generates a commit message like 'Merge ... into HEAD'.
> > 		See also linkgit:git-fmt-merge-msg[1].
> 
> It seems you are assuming (and I am not saying it is a bad assumption)
> that sequencer first detached the HEAD and operates on that state until it
> is done.  Perhaps we would want to reword "into HEAD" somehow?

I'd also prefer something different, but currently this is what
git-fmt-merge-msg provides in the way I use it.

> If we are rebasing branch "main", even if sequencer internally detaches the HEAD to
> carry out individual steps, we would want to see the resulting history to
> say "into main", wouldn't we?

Yes, that's right. (Well, I wouldn't even care if the "into ..." is
omitted at all because in a graph log you usually can see what is merged
into what.)

I currently keep this.
But I'm open for code suggestions to solve this when I have posted the
prototype.

> > patch [<options>] <file>::
> > 	If file `<file>` is a pure (diff) patch, then apply the patch.
> > 	If no `--message` option is given, an editor will
> > 	be invoked to enter a commit message.
> 
> Hmm.  Are there cases where you might want to feed more than one patches
> and then finally make the commit?  You could emulate it with
> 
> 	mark :1
> 	patch --message=dummy file1
>         patch --message=dummy file2
> 	squash --upto :1
> 
> but it might make sense to allow more than one files for this use case,
> like
> 
> 	patch file1 file2
> 
> Although that would introduce another issue, which is what to do if file1
> is a naked diff and file2 is a mbox (with possibly more than one patches),
> or vice versa.

Or what to do if file1 introduces a conflict.

We've (my mentors and me) started such a discussion several times and
always said "Ok, let's keep this for later.". Now that we have the
squash --up-to solution, I think we should stick with it. 
And when we have the code base, we can add features. 

> >...
> > 	-u;;
> > 		Pass `-u` flag to `git-mailinfo` (see linkgit:git-mailinfo[1]).
> >...
> > This was optional in prior versions of git, but now it is the
> > default. You could use `-n` to override this.
> 
> I personally do not think it is worth supporting this b/c compatibility
> option in a new command "sequencer".

Thanks!

The same for --binary?  Oh, I haven't even included it... :)

> > pause::
> > 	Pauses the sequencer process to let you manually make changes.
> > 	For example, you can re-edit the done commit, fix bugs or typos,
> > 	or you can make further commits on top of HEAD before continuing.
> > +
> > After you have finished your changes and added them to the index,
> > invoke `git-sequencer --continue`.
> > If you only want to edit the last commit message with an editor,
> > run `git commit --amend` (see linkgit:git-commit[1]) before.
> 
> before "saying --continue"?

Is it really not clear? (What else?)
Ok, I add it.

Perhaps it's also better to announce the `-e/--edit` option here (see 
Paolo's reply) for users who just want to change the commit message.

> > reset <commit-ish>::
> > 	Go back (see linkgit:git-reset[1] `--hard`) to commit `<commit-ish>`.
> > 	`<commit-ish>` can also be given by a mark, if prefixed with a colon.
> >
> > squash [<options>] <commit>::
> > 	Add the changes introduced by `<commit>` to the last commit.
> 
> Just like you explained "edit <commit>" in terms of "pick" and "pause", we
> might want to explain that this is "pick" and "squash --up-to HEAD^" (or
> is it HEAD^^"?).

It is HEAD^^, but squash --up-to does only accept marks, so:

	This is a short form for `mark :10`, `pick <commit> and
	`squash --up-to :10` on separate lines.

would be more accurate, but isn't really true, since no mark is
generated, the --skip behavior is a different, etc.
I think I don't like to include such a note.

> > squash [<options>] --up-to <mark>::
> > 	Squash all commits up to the given mark into one commit.
> > 	There must not be any merge commits in between.
> 
> "In between" in "inclusive" sense, that is, neither <mark> nor HEAD cannot
> be a merge?

Assuming that <mark> is a mark for HEAD~N, then
HEAD~0, HEAD~1, HEAD~2, ..., HEAD~(N+1) must not be a merge commit.

Example:
	merge ...
	mark :3
	pick ...
	patch ...
	squash --up-to :3
works.
This will result in a merge and a squashed pick/patch commit.

See a perhaps better description below.

> Also --up-to feels somewhat wrong.  It is more like down-to
> but perhaps "from" would be a better wording.

Should we also use --from instead of --up-to then?
I have no "feeling" about that, because "to squash" is a new word in my
English vocabulary since I've first used git-rebase -i ;)

squash [<options>] --from <mark>::
	Squash all commits from the given mark into one commit.
	There must not be any `merge` instructions between the
	`mark` instruction and this `squash --from` instruction.

Does this make more sense to you?

> > 	--include-merges;;
> > 		Sanity check does not fail if you have merges
> > 		between HEAD and <mark>.
> 
> And what gets recorded?  A squashed merge?

Well, I have a test case for that but haven't yet looked what the result
is. (It just checks, that it works.) ;-)
For me, such an operation does not make sense (since I currently don't
know every detail of git), but if there is somebody who wants that,
he or she should get it.

> A "squash --up-to <mark>" (modulo off-by-one I can never get straight X-<)
> essentially:
> 
> 	log --reverse <mark>.. >msg
> 	reset --soft <mark>
>         commit --amend -F msg
> 
> so recording this result, when there is a merge in between, is like
> running "merge --squash".

Aha.

> > tag <tag>::
> > 	Set tag `<tag>` to the current HEAD,
> > 	see also linkgit:git-tag[1].
> > 	If another commit is tagged `<tag>`, it will lose this tag,
> > 	i.e. the tag will be reset to HEAD.
> 
> Hmm.  It is hard to judge this without seeing how the front-ends use it.

Right :)

> It might make sense to give lower-level access to update-ref instead, so
> that more than one branches can be updated as well, but I am not sure.

Like
 ref refs/heads/new_branch
or
 ref refs/tags/foo

That sounds like a good idea. (And is written to the todo list.)
How should the insn be called? "ref"?

> How would this interact with "--abort"?

Nice question.
Currently all tags are kept on --abort.
Sequencer could keep a list of generated tags (refs) and remove it 
on --abort (or tell the user to remove them if she likes.)

But... I think I currently just keep it.

Regards,
  Stephan

-- 
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F

Re: [RFCv2/FYI] git-sequencer.txt

[Paolo Bonzini]

> squash [<options>] --from <mark>::
> 	Squash all commits from the given mark into one commit.
> 	There must not be any `merge` instructions between the
> 	`mark` instruction and this `squash --from` instruction.

--after maybe?

Paolo

Re: [RFCv2/FYI] git-sequencer.txt

[Stephan Beyer]

>> squash [<options>] --from <mark>::
>> 	Squash all commits from the given mark into one commit.
>> 	There must not be any `merge` instructions between the
>> 	`mark` instruction and this `squash --from` instruction.
>
> --after maybe?

I have no idea what is best here ;-)
Something that seems intuitive when you see:

	merge ...
	mark :5
	pick 666babe
	patch foo.patch
	pick fa1afe1

Now?
1)  squash --up-to :5
2)  squash --from :5
3)  squash --after :5

(1) suggests the wrong direction...
My English feeling says that (2) "squash from" is better than 
(3) "squash after", but I'm not a native speaker ;-)

Regards,
  Stephan

-- 
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F

Re: [RFCv2/FYI] git-sequencer.txt

[Paolo Bonzini]

> Now?
> 1)  squash --up-to :5
> 2)  squash --from :5
> 3)  squash --after :5
> 
> (1) suggests the wrong direction...
> My English feeling says that (2) "squash from" is better than 
> (3) "squash after", but I'm not a native speaker ;-)

Yes, it would be squash "everything after" X.  --from sounds good enough.

Paolo

Re: [RFCv2/FYI] git-sequencer.txt

[Olivier Marin]

Stephan Beyer a écrit :
> Junio C Hamano wrote:
>> How would [tag] interact with "--abort"?
> 
> Nice question.
> Currently all tags are kept on --abort.
> Sequencer could keep a list of generated tags (refs) and remove it 
> on --abort (or tell the user to remove them if she likes.)

What about tags that have been overwritten?

And why the tag instruction replace an existing tag by default? Would
not be better to exit with an error during the sanity check if the tag
already exists? Perhaps it make sens to accept -f and -d options.

What do you think?

Olivier.

Re: [RFCv2/FYI] git-sequencer.txt

[Jakub Narebski]

Stephan Beyer wrote:
>
> git-sequencer(1)
> ================
> 
> NAME
> ----
> git-sequencer - Execute a sequence of git instructions
> 
> SYNOPSIS
> --------
> [verse]
> 'git-sequencer' [--batch] [--onto=<base>] [--verbose] [<file>]
> 'git-sequencer' --continue | --skip | --abort | --edit | --status

I'm not sure if --edit should be mentioned in line with "processing"
commands: --continue, --skip, --abort and related --status.
 
I'm not sure if it is necessary at all, but if we want to have this
equivalent to "git rebase --interactive" it should be, I think, put
separately.

> Alternatively, you can [...] correct the TODO file with
> 
>     git sequencer --edit

Can you ensure that editor would be invoked with current line
at the current action (isns?)?  Or will you be presenting only
with not performed yet actions?  If not, what would happen if
user modifies actions which had been done already?

In short, this is difficult thing to implement... besides of
course initial edit, with series file seeded by current history
"replay" description.
 
> OPTIONS
> -------
> <file>::
> 	Filename of the TODO file.  If omitted, standard input is used.
> 	See 'TODO FILE FORMAT' below.

Omitted for standard input, --stdin for standard imput, or special
filename of '-' for standard input?
 
> --onto=<base>::
> 	Checkout given commit or branch before sequencing.
> 	If you provide a branch, sequencer will make the provided
> 	changes on the branch, i.e. the branch will be changed.

I'm not sure if repeating rebase design is best idea.  But this
ferature is certainly necessary...
 
> --status::
> 	Show the current status of git-sequencer and what
> 	operations can be done to change that status.

How it would look like?  Current caller, current operation, progress
report (action n/m), status (e.g. CONFLICT or edit, or amend),
suggested actions (--continue, sometimes --skip, --abort)?
 
> --edit::
> 	Invoke editor to edit the undone rest of the TODO file.

Ahh... only the rest of the file...

> -v::
> --verbose::
> 	Be more verbose. [XXX: to be defined more accurately, i.e. print diffstat]

I think it would be nice to have --quiet mode (which perhaps --batch
would imply, or perhaps not), which would make git-sequencer to not
report progress report (i.e. which actions are being done).
 
> git-sequencer will usually be called by another git porcelain, like
> linkgit:git-am[1] or linkgit:git-rebase[1].

Or git-cherry-pick, or git-revert.

-- 
Jakub Narebski
Poland

Re: [RFCv2/FYI] git-sequencer.txt

[Stephan Beyer]

Hi,

On Thu, Jun 12, 2008 at 04:10:42PM +0200,
Jakub Narebski <jnareb@gmail.com> wrote to git@vger.kernel.org:
> > SYNOPSIS
> > --------
> > [verse]
> > 'git-sequencer' [--batch] [--onto=<base>] [--verbose] [<file>]
> > 'git-sequencer' --continue | --skip | --abort | --edit | --status
> 
> I'm not sure if --edit should be mentioned in line with "processing"
> commands: --continue, --skip, --abort and related --status.

Hm I've put it in this line, because it's also an option that is rather
than a command and that takes no other options, as --continue, --skip,
--abort, --status are.

For more information, everybody can scroll down and read the
description.

> > OPTIONS
> > -------
> > <file>::
> > 	Filename of the TODO file.  If omitted, standard input is used.
> > 	See 'TODO FILE FORMAT' below.
> 
> Omitted for standard input, --stdin for standard imput, or special
> filename of '-' for standard input?

In the current spec it is omitted.
In the last one, it was '-'.
My mentors and me discussed also the --stdin/--file approach but put
that down.

> > --onto=<base>::
> > 	Checkout given commit or branch before sequencing.
> > 	If you provide a branch, sequencer will make the provided
> > 	changes on the branch, i.e. the branch will be changed.
> 
> I'm not sure if repeating rebase design is best idea.  But this
> ferature is certainly necessary...

Ok, you say that it's necessary.
I thought this, too, up to Junio's mail I just replied to.

Now I think I can get along without that and let the sequencer user
tools prepare and finish that.
This *could* mean duplicated code, but currently the only tool
that would use this feature is rebase-i.

> > -v::
> > --verbose::
> > 	Be more verbose. [XXX: to be defined more accurately, i.e. print diffstat]
> 
> I think it would be nice to have --quiet mode (which perhaps --batch
> would imply, or perhaps not), which would make git-sequencer to not
> report progress report (i.e. which actions are being done).

Currently I have no idea what should be outputted and what not.
I think I won't care about that for the prototypem but for the builtin
sequencer.

But I add -q/--quiet to the spec, but --batch does not imply it ;)

> > git-sequencer will usually be called by another git porcelain, like
> > linkgit:git-am[1] or linkgit:git-rebase[1].
> 
> Or git-cherry-pick, or git-revert.

Well, I don't know about the others, but for me this is currently not
clear ;-)
The prototype uses git-cherry-pick and I think the first versions of my
builtin will also use it.

Regards,
  Stephan

-- 
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F