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

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 :)

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

and

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