Re: bug/defaults: COMMIT_EDITMSG not reused after a failed commit

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Jul 24, 2024 at 09:37:01AM GMT, Junio C Hamano wrote:
> > 1. delete COMMIT_EDITMSG on success
> >
> > 2. reopen COMMIT_EDITMSG on commit if it exists. Maybe logging something like
> >    "Restoring previous in-progress commit message..." might explain what's
> >    happening.
> > 3. if COMMIT_EDITMSG doesn't exist, re-populate from the template before opening
> >    the editor. We could also do this for "parsed-as-empty" commit messages.
> 
> Unconditionally doing this change would be disruptive to workflows
> of existing users.  To them, Git left COMMIT_EDITMSG available even
> after the commit to them almost forever, but suddenly it stops doing
> so.  Like "git cherry-pick|rebase|revert" that got stopped can be
> restarted _with_ some state information with "--continue", offering
> this as an optional feature might be a possibility, but I haven't
> thought things through.
> 
> An obvious and a lot more lightweight first step is to make it clear
> (perhaps in the error message after a failed commit---after all,
> such a failure from "git commit" should be a rare event) where you
> can resurrect the draft commit message from.  That is independent
> and orthogonal to the "let's reuse COMMIT_EDITMSG file" change.

Yes, I would say even doing the following would result in a better experience
for users who don't know about .git/COMMIT_EDITMSG:

1. when git-commit fails, save the message as .git/FAILED_COMMIT_MSG
2. output "Commit message saved as .git/FAILED_COMMIT_MSG"

(exact wording/naming up for debate)

-K




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux