From: Kristoffer Haugsbakk <code@xxxxxxxxxxxxxxx>
Give the user a list of suggestions for what to do when they run a
deprecated command.
The first order of action will be to check the breaking changes
document;[1] this short error message says nothing about why this
command is deprecated, and in any case going into any kind of detail
might overwhelm the user.
Then they can find out if this has been discussed on the mailing list.
Then users who e.g. are using git-whatchanged(1) can learn that this is
arguably a plug-in replacement:
git log <opts> --raw --no-merges
Finally they are invited to send an email to the mailing list.
Also drop the “please add” part in favor of just using the “refusing”
die-message; these two would have been right after each other in this
new version.
Also drop “Thanks” since it now would require a new paragraph.
[1]: www.git-scm.com has a disclaimer for these internal documents that
says that “This information is specific to the Git project”. That’s
misleading in this particular case. But users are unlikely to get
discouraged from reading about why they (or their programs) cannot run a
command any more; it clearly concerns them.
Helped-by: Eric Sunshine <sunshine@xxxxxxxxxxxxxx>
Signed-off-by: Kristoffer Haugsbakk <code@xxxxxxxxxxxxxxx>
---
Notes (series):
v2:
I had second thoughts about the bullet point about send-an-email.
Change it to the one Eric Sunshine proposed;[1] make sure to spell
out that you can send an email conditioned on not finding a suitable
replacement.
Also change the area to something more pointed.
And also use a clear URL to refer to www.git-scm.com.
[1]: https://lore.kernel.org/git/CAPig+cQkVP57n_FE6dJ0uxvai-J7usxKFp8gzfEbPY=Ytsd6=Q@xxxxxxxxxxxxxx/
• Change send-an-email bullet point
• Change the area
• Use www.git-scm.com, not simply git-scm
v1:
An alternative to linking to www.git-scm.com is to move this document to
a regular installed man page:
gitbreaking-changes(7)
What do you think?
I would then have to base my topic on the in-flight
pw/3.0-commentchar-auto-deprecation, which in turn depends on
ps/config-wo-the-repository.
Or just wait a bit for these to settle in.
usage.c | 23 ++++++++++++++++++-----
1 file changed, 18 insertions(+), 5 deletions(-)
diff --git a/usage.c b/usage.c
index 81913236a4a..35dc57eb07e 100644
--- a/usage.c
+++ b/usage.c
@@ -7,6 +7,7 @@
#include "git-compat-util.h"
#include "gettext.h"
#include "trace2.h"
+#include "strbuf.h"
static void vfreportf(FILE *f, const char *prefix, const char *err, va_list params)
{
@@ -377,12 +378,24 @@ void bug_fl(const char *file, int line, const char *fmt, ...)
NORETURN void you_still_use_that(const char *command_name)
{
+ struct strbuf percent_encoded = STRBUF_INIT;
+ strbuf_add_percentencode(&percent_encoded,
+ command_name,
+ STRBUF_ENCODE_SLASH);
+
fprintf(stderr,
_("'%s' is nominated for removal.\n"
- "If you still use this command, please add an extra\n"
- "option, '--i-still-use-this', on the command line\n"
- "and let us know you still use it by sending an e-mail\n"
- "to <git@xxxxxxxxxxxxxxx>. Thanks.\n"),
- command_name);
+ "If you still use this command, here's what you can do:\n"
+ "\n"
+ "- read https://git-scm.com/docs/BreakingChanges.html\n";
+ "- check if anyone has discussed this on the mailing\n"
+ " list and if they came up with something that can\n"
+ " help you: https://lore.kernel.org/git/?q=%s\n";
+ "- send an email to <git@xxxxxxxxxxxxxxx> to let us\n"
+ " know that you still use this command and were unable\n"
+ " to determine a suitable replacement\n"
+ "\n"),
+ command_name, percent_encoded.buf);
+ strbuf_release(&percent_encoded);
die(_("refusing to run without --i-still-use-this"));
}
--
2.51.0.16.gcd94ab5bf81
