Welcome to the Git community! On Wed, Mar 8, 2017 at 7:31 PM, Shuyang Shi <shuyang790@xxxxxxxxx> wrote: > The "-" shorthand that stands for "the branch we were previously on", > like we did for "git merge -" sometime after we introduced "git checkout -". > Now I am introducing this shorthand to branch delete, i.e. > "git branch -d -". > > More reference: > https://public-inbox.org/git/7vppuewl6h.fsf@xxxxxxxxxxxxxxxxxxxxxxxx/ Following that link: > But there is a very commonly accepted long tradition for "-" to mean > "read from the standard input", so we cannot reuse it to mean "the > branch I was previously on" for every command without first making > sure the command will never want to use "-" for the other common > purpose. This contradicts the introduction of "git branch -d -" to mean to delete the last branch, but rather could mean "read from stdin which branches to delete"? It would be nice if you could clarify in your commit message which of both this is and how this fits into the big picture of "design cleanliness". > > And this has been tested: > > Ivan:git Ivan$ (cd t; prove --timer --jobs 1 ./t3200-branch.sh) > [00:21:26] ./t3200-branch.sh .. ok 12293 ms ( 0.04 usr 0.01 sys + > 5.97 cusr 2.52 csys = 8.54 CPU) > [00:21:39] > All tests successful. > Files=1, Tests=113, 13 wallclock secs ( 0.07 usr 0.02 sys + > 5.97 cusr 2.52 csys = 8.58 CPU) > Result: PASS Thanks for being cautious when developing on Git. However this part of the email would end up as part of the commit message. And as we expect all commits that land eventually to not break tests, this information is better put at a more non-permanent place, such as below the '---' line (where there is also the built stat. For example see [1] how to have different message parts (one permanent section and some chatter that is relevant for the process at the moment) Also for testing, the tests only ensure that the old behavior does not break; but we'd want to make sure the new functionality doesn't break in the future either, which can be done best by writing a test as well for this functionality. [1] https://public-inbox.org/git/xmqqvarj1kix.fsf_-_@xxxxxxxxxxxxxxxxxxxxxxxxxxx/ and as a commit: https://github.com/gitster/git/commit/83218867fbf6d27c78efe3cfba01790b2f1d15d4 > https://github.com/git/git/pull/337 Oh I see, you're using submitgit to communicate the patch to the mailing list. I am not sure if it supports splitting up the message as I eluded to above. IIRC some people use submitgit for the patch and then use a webmailer (e.g. gmail) to send followup messages such as successful tests or what changed to prior versions. Thanks, Stefan