Re: squashing patches

[Stephan Beyer <s-beyer@gmx.net>]

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