Hi Stefan, Really appreciate your help on this, but I guess I am cancelling this patch for Siddharth's. Thanks, Shuyang 史舒扬 Shuyang Shi Undergraduate Department of CS, School of EECS, Peking University Email: shuyang790@xxxxxxxxx Mobile: +86-18301336991 On Fri, Mar 10, 2017 at 1:47 AM, Stefan Beller <sbeller@xxxxxxxxxx> wrote: > 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