[email protected] writes:
>> That said, I'd still be OK with it.
>
> I don't have objection either.
FWIW, I do not even buy the "destructive commands should force
spelling things out even more" argument in the first place.
$ git checkout somelongtopicname
$ work work work
$ git checkout master && git merge -
$ git branch -d -
would be a lot less error-prone than the user being forced to write
last step in longhand
$ git branch -d someotherlongtopicname
and destroying an unrelated but similarly named branch.
So obviously I am OK with it, too.
As long as we do not regress end-user experience, that is. For
example, "git merge @{-1}" in the above sequence would record the
fact that the resulting commit is a merge of 'somelongtopicname',
not literally "@{-1}", in its log message. It would be a sad
regression if it suddenly starts to say "Merge branch '-'" [*1*],
for example.
[Reference]
*1* https://public-inbox.org/git/[email protected]/
