I have introduced an interactive option `--allow-empty` in a new independent commit, and it is not the synonym of the `--empty` option because it is only for the case in a middle am session where users can resolve "died" problems by choosing whether to record current empty patch. The `--empty` option acts like a strategy option to tell `git-am` how to handle when meeting any empty patches. > On Mon, Nov 29, 2021 at 2:00 AM Aleen 徐沛文 <pwxu@xxxxxxxxxxx> wrote: > > > > It is quite complicated to support 'git commit --allow-empty' extracting messages > > from an empty patch, because 'git am' has to find somewhere to store the parsed state > > for 'git commit' to read. > > .git/COMMIT_EDITMSG is such a place that already exists, assuming you > are just extracting a commit message. > > > How about directly supporting another interactive option > > '--allow-empty' for 'git am' to keep recording? > > --empty=keep was already part of your patch series; I don't see why > you'd need to add a synonym (--allow-empty) for it. > > I think you were trying to ask if you could just leave out the > implementation of --empty=ask (or --empty=die) from your patches. > That's usually fine, but there is a small wrinkle here since it was > your chosen default. You'll have to pick a different default, and > possibly alert users in the documentation that the default may change > in the future if/when the other option is implemented. > > > > Dears Hamano, > > > > > > Elijah Newren has given two better suggestions: > > > > > > 1. Use 'ask' rather than 'die' > > > 2. When erroring out 'Patch is empty', print out a tutorial information > > > to help users using 'git commit --allow-empty' to keep recording as > > > an empty commit. > > > > > > Should we continue to implement these features in current PR? > > > > > > Aleen
