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

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



--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html