Hi, On Sat, 20 Feb 2021 at 08:46, Junio C Hamano <gitster@xxxxxxxxx> wrote: > > Charvi Mendiratta <charvi077@xxxxxxxxx> writes: > > > For end-users "-m" or "-F" will make it easier to prepare an "amend!" > > commit. Because using the "-m" reduces the cost of opening an editor > > to prepare "amend!" commit and it can be done with command line only. > > Hmph. That is not very convicing to me. The user is motivated > enough to fix a wrong commit log message and replace it with an > improved one by using the "--fixup:amend" feature---why would that > improved message can sufficiently be written with just an "-m > message", which by definition would be much less capable of > preparing a well-thought-out message than with an editor? > > Yes, with "-m", you can add some short string easily at the end of > the existing commit message without opening an editor. But I am > trying to see why it is a good thing to be able to do so in the > first place. It is very easy to make typoes while doing so and it > would be hard to fix these typoes, exactly because you are doing so > without being in an editor. And the whole point of --fixup=amend is > about improving the message (as opposed to --fixup that is to record > the contents that have already been improved in the index). > > This is why I kept asking what the use case would look like. I am > trying to find out if you have a good end-user story in mind that we > can use in the documentation to sell the feature to end-users, but I > am not seeing one. > I was in my mind that, as we can easily prepare the commit using `git commit -m "commit message"`. Similarly, we can extend this working with `git commit --fixup=amend:<commit> -m "new commit message"`. And the difference is that in the later one the goal of changing the commit message will be achieved after `git rebase --autosquash` i.e the later command works with sequencer. This will easily allow us to write a new message for the commit we are fixing up through the command line only similar to `git commit -m` and if we need to fixup the commit msg then it can be done without `-m` and the editor gets open with a seeded commit message we want to fixup. Also the same working applies to `reword` option also and may allow to reword the commit msg from command line only. But I am still doubtful, as I agree with above that the main concern is to only fixup the wrong commit message and in that case the "-m" option can't be that much productive or maybe confusing for users. > Is the combination of "--fixup=amend" and "-m <msg>" meant to be > used primarily "to leave a note to myself" when the user runs > --fixup=amend:<commit>, to just record the points to be elaborated > when the message is written for real much later? E.g. > > ... hack hack hack ... > ... good stopping point, but cannot afford time to write > ... a good log message now > $ git commit --fixup=amend:HEAD~2 -m 'talk about X, Y and Z' -a > ... hack hack hack ... > ... possibly doing something entirely different ... > ... finally comes back to finish cleaning up the branch for real ... > $ git rebase --autosquash -i origin > > And one of the insn created in the todo sheet would be amend!, whose > commit message has the message taken from the original HEAD~2 PLUS the > reminder to the user that s/he needs to talk about X, Y and Z? And > the user at that point writes more comprehensive message about these > three things? > But here in this case, after `git rebase --autosquash -i origin`, it will not open editor again and user is not allowed to write more comprehensive message about these three things, unless the user manually changes from automatically converted `pick` to `fixup -C`, to `fixup -c` command in the rebase todo list that gets opened after `git rebase --autosquash`. And for this case `git commit --squash` is more easy to use. > That is a made-up example of what "appending some short strings > possibly full of typoes without having to open an editor" could be > useful for. I am not sure if it is truly useful, or if it is just a > hand wavy excuse not to mark -m/-F incompatible with --fixup=amend > without a real merit [*]. > > Side note: one reason why I do not find it realistic is that it > is unlikely that the user would use --fixup=amend to slurp in > the original log message when recording "good stopping point, > but cannot afford time" fixup. "--squash HEAD~2 -m <msg>" would > be much faster to record the "note to myself" reminder, and when > the user finally comes back to clean things up, the amount of > work to edit the original's message while looking at the "note > to myself" appended at the end would not be any different in > either workflow. > Yes, I also thought the same and agree with it. > In any case, that was the kind of answer(s) I was looking for when I > asked "what is this good for?" question. > Thanks a lot for explaining each perspective in detail. So, now if we use `-m` as an option to write side-note then `--squash` is already available and for fixing the commit message opening the editor is a must expected option. So shall we remove the `-m` option compatibility if `amend`/ `reword` suboptions are passed to `git commit --fixup` ? Thanks and Regards, Charvi
