Re: [PATCH 2/6] commit: add amend suboption to --fixup to create amend! commit
- From
Charvi Mendiratta <charvi077@gmail.com>
- Date
- Feb 23, 2021, 06:05 UTC
- Message-ID
- <CAPSFM5fnxZ+WF9Df-naibeauNq1-e9=E=oh86xb9JOeeuHp3Jg@mail.gmail.com>
- In-Reply-To
- <xmqqft1o80pe.fsf@gitster.g>
On Mon, 22 Feb 2021 at 23:05, Junio C Hamano <gitster@pobox.com> wrote: [...]
Show 37 quoted lines
> If we were to make -m/-F incompatible with these new features, then > sure, we'd notice the combination, show an error message and abort. > > >>than just accepting and doing useless thing, I am OK > >> if we left them as they are. > > > > ....If we allow both `m` and `F` to work with `git commit > > --fixup=amend/reword` with the same working as it is doing now i.e to > > use `m` to write new commit message, upon `--autosquash`, If it is > > okay? then I also agree to update the documentation more precisely and > > include the uses when passed with `m` /`F`(not yet added) option. > > What would that more precise documentation would say, though? > > "'-m message' gets appended to the message taken from the original > commit"? Saying that alone, without explaining why doing such an > appending is useful, would puzzle users and makes them ask "but why > such a useless feature exist?" and that was why I was trying to > figure out what it is useful for with you, which I think we have > failed to do so far. > > My preference at this point is to error out the combination that we > cannot figure out how it could be useful at this moment, so that > users who find how it would be useful to come to us and present a > hopefully good case for using -m <msg> with --fixup=amend:<commit>. > I am assuming that allowing the combination at that point is easy, > and the user request will give us a good use case we can use in the > documentation to explain for what purpose a user may want to use -m > <msg> to append a short string at the end. The end users' use case > we see at that point might even suggest that it would be more useful > to prepend (as opposed to append) the message we get from -m <msg> > to the original log message, and such a change will not be possible > if we just choose to append without thinking through the use case we > intend to support and release "we do not know what good it would do > to append with -m <msg>, but that is what the code happens to do now" > version to the users, as people will depend on the behaviour of any > released versions.
Okay, I admit prepending the msg can be another way. Thanks a lot for clarifying in detail, I completely agree with it and will error out the combination for now.
Thanks and Regards, Charvi