Re: Avoiding 'master' nomenclature

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Linus,

Linus Torvalds wrote:
> On Wed, Jul 29, 2020 at 1:05 PM Junio C Hamano <gitster@xxxxxxxxx> wrote:

>> The intent was to stop treating 'master' as some kind of 'special'
>> word, since it is no longer special after init.defaultBranchName was
>> invented.
>
> I understand it happened.
>
> I just think it's simplistic and wrong, and outright stupid, exactly
> because it effectively does the exact opposite of what you should do
> if you feel that "master" is a bad default.

I know that "on the internet no one can hear you being subtle", but the
following is not about subtlety:

Repeatedly describing this change as wrong, stupid, simple-minded,
pointless, etc is not making your point any more clearly than if you
were to describe how this change is affecting your workflow.

In fact, in this thread you haven't described it yet.  I assume your
point is that you find the message it writes to be ugly?  If so, why not
say that, instead of describing how the change doesn't do what you
believe it should do?

The commit message describes its intent

  commit 489947cee5095b168cbac111ff7bd1eadbbd90dd
  Author: Johannes Schindelin <Johannes.Schindelin@xxxxxx>
  Date:   Tue Jun 23 22:33:23 2020 +0000

      fmt-merge-msg: stop treating `master` specially

      In the context of many projects renaming their primary branch names away
      from `master`, Git wants to stop treating the `master` branch specially.

which is *not* about treating "master" as a forbidden word.  All that
said, I do think it can make sense to make these merge messages less
noisy, for example by keying on a setting like init.defaultBranchName
as Junio suggested.

What would help in figuring out how to do that is, instead of more
reminders of how stupid we are, some more information about what would
be useful for you (both directly in your use of git and indirectly in
the history you would like to have available to you for pulling).

Thanks,
Jonathan



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux