Re: squashing patches

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 9, 2008, 19:34 UTC
Message-ID: <7vprqqh06j.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <20080609114550.GA8079@leksak.fem-net>

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

Show 13 quoted lines

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