From: Junio C Hamano <email@example.com> To: Firmin Martin <firstname.lastname@example.org> Cc: email@example.com, Jeff King <firstname.lastname@example.org>, Johannes Schindelin <email@example.com>, Erik Faye-Lund <firstname.lastname@example.org>, Denton Liu <email@example.com> Subject: Re: [PATCH v1 0/8] format-patch: introduce --confirm-overwrite Date: Fri, 07 May 2021 07:33:31 +0900 [thread overview] Message-ID: <firstname.lastname@example.org> (raw) In-Reply-To: <email@example.com> (Firmin Martin's message of "Thu, 6 May 2021 18:50:54 +0200") Firmin Martin <firstname.lastname@example.org> writes: > Particulary, this behaviour could be awkward in the following > hypothetical situations: > > * The user can easily erase a cover letter coming from prior versions or > another patch series by reusing an old command line (e.g. autocompleted > from the shell history). "prior versions" implies that the user is better off using -v$n where $n is the number greater than the one used for the prior iteration by one, and there won't be any overwriting, so this is not a very compelling use case. But the next one is real. > * Assuming that the user is writing a cover letter and realizes that > small changes should be made. They make the change, amend and > format-patch again to regenerate patches. If it happens that they use > the same command again (e.g. with --cover-letter), the cover letter > being written is gone. Yes, after preparing, say, -v2, but before sending them out, it is very plausible that proofreading of your own patches may make you realize more issues in the series, which may make you go back to your commits, "rebase -i" to improve them and re-run "format-patch -v2". We do want to encourage such careful preparation of your patch series before sending it out, and we want to support it well with our tools. Preventing overwriting of the cover (which will have the same filename, with the same v2- prefix) is very valuable here. There is another thing that I suspect people may find irritating in the same workflow. If you fix the commit title while "rebase -i" to polish your v2 patch, it would result in a different filename from the original v2, so you'd end up with something like v2-0000-cover-letter.patch v2-0001-thes-forny-change.patch v2-0001-this-phoney-change.patch v2-0002-another-sample-change.patch while redoing a two-patch series. The "thes-forny" thing is a leftover from the first "format-patch -v2" run, you fixed typoes with "rebase -i" after a self-review and other three files have the result of the second "format-patch -v2" run. You need a way to somehow exclude that stale file when driving send-email; in other words, before running git send-email v2-*.patch you would want to move away v2-0001-thes-forny-change.patch that no longer is part of the series. I wonder if format-patch can help by looking at the output directory before writing its output and move the old files away, say, to "old-v2-*.patch" or something? That incidentally would solve your "files getting overwritten is irritating" issue at the same time. Coming back to the topic of cover letter, even when there is no risk of ovetwriting, there is another thing we may want to improve to help our users. Suppose you are preparing your v2 patch after sending out the v1. The cover letter we generate for v2 will have the same **BOILERPLATE** placeholders that need to be filled from scratch. As many things you wrote for the cover letter in the previous round should be reusable, even though the list of titles of the patch should be generated afresh, it would be nice if format-patch can carry forward what you wrote in the cover letter for the v1 iteration to the cover letter for this v2 iteration. And when we have such a "reuse description in the existing cover letter" support, the value of "don't overwrite" knob will mostly go away. Instead of failing the command by refusing to overwrite, you can read what is in the existing cover-letter that is about to be overwritten, combine the hand-written description with the material automatically generated, and ovewrite the existing file, and as long as you do a good job of preserving, nobody would complain that you overwrote the file.
next prev parent reply other threads:[~2021-05-06 22:33 UTC|newest] Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-05-06 16:50 Firmin Martin 2021-05-06 16:50 ` [PATCH v1 1/8] compat/terminal: let prompt accept input from pipe Firmin Martin 2021-05-06 23:37 ` Junio C Hamano 2021-05-07 4:54 ` Jeff King 2021-05-07 5:25 ` Junio C Hamano 2021-05-10 4:18 ` Firmin Martin 2021-05-10 21:32 ` Jeff King 2021-05-11 3:38 ` Junio C Hamano 2021-05-11 6:10 ` Jeff King 2021-05-11 6:17 ` Junio C Hamano 2021-05-11 6:37 ` Jeff King 2021-05-06 16:50 ` [PATCH v1 2/8] format-patch: confirmation whenever patches exist Firmin Martin 2021-05-06 23:48 ` Junio C Hamano 2021-05-10 3:30 ` Firmin Martin 2021-05-10 7:32 ` Junio C Hamano 2021-05-11 3:17 ` Firmin Martin 2021-05-06 16:50 ` [PATCH v1 3/8] format-patch: add config option confirmOverwrite Firmin Martin 2021-05-06 16:50 ` [PATCH v1 4/8] format-patch: add the option --confirm-overwrite Firmin Martin 2021-05-06 16:50 ` [PATCH v1 5/8] t4014: test patches overwrite confirmation Firmin Martin 2021-05-06 16:51 ` [PATCH v1 6/8] t4014: fix tests overwriting cover letter in silent Firmin Martin 2021-05-06 16:51 ` [PATCH v1 7/8] doc/format-patch: describe --confirm-overwrite Firmin Martin 2021-05-07 3:32 ` Bagas Sanjaya 2021-05-10 4:22 ` Firmin Martin 2021-05-06 16:51 ` [PATCH v1 8/8] config/format: describe format.confirmOverwrite Firmin Martin 2021-05-06 22:33 ` Junio C Hamano [this message] 2021-05-11 0:18 ` [PATCH v1 0/8] format-patch: introduce --confirm-overwrite Firmin Martin 2021-05-07 1:46 ` Felipe Contreras 2021-05-07 8:55 ` Denton Liu 2021-05-11 1:09 ` Firmin Martin 2021-05-11 5:12 ` Felipe Contreras 2021-05-11 5:03 ` Felipe Contreras 2021-05-07 14:02 ` Sergey Organov 2021-05-11 0:46 ` Firmin Martin 2021-05-10 12:02 ` Ævar Arnfjörð Bjarmason
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style List information: http://vger.kernel.org/majordomo-info.html * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: [PATCH v1 0/8] format-patch: introduce --confirm-overwrite' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Code repositories for project(s) associated with this inbox: https://80x24.org/mirrors/git.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).