Stephan Beyer <s-beyer@xxxxxxx> 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? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
