--
2.43.0
--
* <https://www.facebook.com/symbiosis.official/>*
<https://www.instagram.com/symbiosis.official/>
<https://www.linkedin.com/school/symbiosis-international-university/>
<https://x.com/symbiosistweets>
**Disclaimer:* This email is
governed by the Disclaimer Terms of SIU, which may be viewed at
http://siu.edu.in/disclaimer.php <http://siu.edu.in/disclaimer.php>*
--
2.43.0
--
* <https://www.facebook.com/symbiosis.official/>*
<https://www.instagram.com/symbiosis.official/>
<https://www.linkedin.com/school/symbiosis-international-university/>
<https://x.com/symbiosistweets>
**Disclaimer:* This email is
governed by the Disclaimer Terms of SIU, which may be viewed at
http://siu.edu.in/disclaimer.php <http://siu.edu.in/disclaimer.php>*
>
> Add a brief description of the bugreport command to improve
> clarity of the usage message.
>
The git command adds command description to the 'NAME' header within the documentation. For 'git-bugreport(1)' you can find this in 'Documentation/git-bugreport.adoc'.
This is wrong. The usage string is to show "usage". Unless your users type
$ git bugreport -create a bug ...
from their command line, the first line that you added does not belong there.
In general, these should match what is in the synopsis section of the manpage (i.e., "git help bugreport" output), and there is even a test to ensure they do not diverge from each other (iirc, t0450).
The usage string is intended to reflect command syntax rather than describe functionality. Revert the previous change to keep it consistent with documentation.
Signed-off-by: Smaran Jaianand <24070721037@sithyd.siu.edu.in>
---
v3: Revert previous change after feedback that usage strings should reflect command syntax rather than description.
--
2.43.0
--
* <https://www.facebook.com/symbiosis.official/>*
<https://www.instagram.com/symbiosis.official/>
<https://www.linkedin.com/school/symbiosis-international-university/>
<https://x.com/symbiosistweets>
**Disclaimer:* This email is
governed by the Disclaimer Terms of SIU, which may be viewed at
http://siu.edu.in/disclaimer.php <http://siu.edu.in/disclaimer.php>*
Revert the previous change to keep it consistent with documentation. Based on the feedback, the usage string is intended to represent command syntax rather than provide a description.
--
2.43.0
--
* <https://www.facebook.com/symbiosis.official/>*
<https://www.instagram.com/symbiosis.official/>
<https://www.linkedin.com/school/symbiosis-international-university/>
<https://x.com/symbiosistweets>
**Disclaimer:* This email is
governed by the Disclaimer Terms of SIU, which may be viewed at
http://siu.edu.in/disclaimer.php <http://siu.edu.in/disclaimer.php>*
> Revert the previous change to keep it consistent with documentation.
> Based on the feedback, the usage string is intended to represent command syntax rather than provide a description.
You really do not have to post a patch to revert something that was rejected and did not get applied anywhere to our tree.
We frown upon a patch series that makes mistakes in an earlier step, only to fix them in a later step. The "git rebase -i" command helps us pretend to be more perfect developers than we actually are, whipping your patch series into a shape that builds one small step on top of another in a logical succession. Such a patch series is easier to understand than a history that faithfully records all the stumbles the developer made until they reached the final solution.
If you rebuilt your changes, while removing any parts that shouldn't be there, in an effort to pretend to be a more perfect developer, sometimes you might end up with an empty patch, and that is OK. You can just send a message that you are retracting the earlier patch and everybody would understand.