Re: [PATCH GSoC] Allow "-" as a short-hand for "@{-1}" in branch deletions

[Stefan Beller <sbeller@google.com>]

Welcome to the Git community!

On Wed, Mar 8, 2017 at 7:31 PM, Shuyang Shi <shuyang790@gmail.com> 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@alter.siamese.dyndns.org/

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_-_@gitster.mtv.corp.google.com/
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