* Re: The master branch rename, and avoiding another v1.6.0 git-foo fiasco
2020-11-13 4:27 ` Felipe Contreras
@ 2020-11-13 5:14 ` Theodore Y. Ts'o
2020-11-13 6:28 ` Felipe Contreras
2020-11-13 6:09 ` Don Goodman-Wilson
` (2 subsequent siblings)
3 siblings, 1 reply; 25+ messages in thread
From: Theodore Y. Ts'o @ 2020-11-13 5:14 UTC (permalink / raw)
To: Felipe Contreras
Cc: brian m. carlson, Git, Junio C Hamano, Johannes Schindelin,
Don Goodman-Wilson
Maybe I'm missing something, but I'm very confused about what is going
to be changed that you are concerned about. What is it precisely that
going to be happening (or which you think is going to be happening)
which is causing you concern?
Is it changing the default branch name when creating a new repository?
(Which affects only people creating new repositories)
Is it renaming the master branch for the git repo? (which affects
people who are developing or tracking git via the repository, as
opposed to using a pre-packaged git provided by their Linux
Distributions / OS).
Is it improving the tools so that other projects can more easily
rename their primary development branch from master to main? (Which
many projects have been doing *already*, without not a lot of Sturm
und Drang as near as I can tell, at least in many/most cases.)
Is it removing places in the git program where "master" is treated
specially (e.g., in how the default text for merge descrtipion is
worded)?
What, specifically, is the "backwards incompatible change" that you
are most worried about? Because many projects have already been
renaming their primary development branch from master to main
*already*.
- Ted
^ permalink raw reply [flat|nested] 25+ messages in thread* Re: The master branch rename, and avoiding another v1.6.0 git-foo fiasco
2020-11-13 5:14 ` Theodore Y. Ts'o
@ 2020-11-13 6:28 ` Felipe Contreras
2020-11-13 14:58 ` Theodore Y. Ts'o
0 siblings, 1 reply; 25+ messages in thread
From: Felipe Contreras @ 2020-11-13 6:28 UTC (permalink / raw)
To: Theodore Y. Ts'o
Cc: brian m. carlson, Git, Junio C Hamano, Johannes Schindelin,
Don Goodman-Wilson
On Thu, Nov 12, 2020 at 11:14 PM Theodore Y. Ts'o <tytso@mit.edu> wrote:
> Is it changing the default branch name when creating a new repository?
> (Which affects only people creating new repositories)
You may choose to downplay the experience of certain part of the
user-base, because in your experience creating new repositories
doesn't happen often, but that doesn't mean these users don't exist.
Yes, this is the part I'm concerned about.
At this very moment there's people in universities trying to learn Git
and creating repositories, so are people training in companies.
There's a whole industry dedicated to teaching Git, and they rely on
creating repositories.
A simple "git grep master" on the documentation of git.git (without
the release notes) shows at least 800 instances.
This is precisely the part that was neglected in the v1.6.0 release
that I undertook: nobody bothered to change the documentation that was
using git-foo commands.
I find it curious that this is the criticism you choose to give on a
change that is supposed to be making Git more inclusive towards people
with different experiences (potentially non-existent); making light of
the experiences of very real people which we know exist.
Shouldn't we be inclusive towards these very real users as well?
Since this is 2020, and just to be crystal clear: I intend no offense,
I just truly find this argument curious.
Cheers.
--
Felipe Contreras
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: The master branch rename, and avoiding another v1.6.0 git-foo fiasco
2020-11-13 6:28 ` Felipe Contreras
@ 2020-11-13 14:58 ` Theodore Y. Ts'o
2020-11-13 15:37 ` Felipe Contreras
` (2 more replies)
0 siblings, 3 replies; 25+ messages in thread
From: Theodore Y. Ts'o @ 2020-11-13 14:58 UTC (permalink / raw)
To: Felipe Contreras
Cc: brian m. carlson, Git, Junio C Hamano, Johannes Schindelin,
Don Goodman-Wilson
On Fri, Nov 13, 2020 at 12:28:52AM -0600, Felipe Contreras wrote:
> On Thu, Nov 12, 2020 at 11:14 PM Theodore Y. Ts'o <tytso@mit.edu> wrote:
>
> > Is it changing the default branch name when creating a new repository?
> > (Which affects only people creating new repositories)
>
> You may choose to downplay the experience of certain part of the
> user-base, because in your experience creating new repositories
> doesn't happen often, but that doesn't mean these users don't exist.
OK, fine. That wasn't clear in your earlier messages. So this is
*not* like 2008, where we are breaking workflows or finger macros of
*existing* git users.
Instead, we might be causing a certain amount of confusion with
respect to *new* users, especially if some portion of them are using
an older version of git, where the default initial branch name is
"master", or a newer version of git, where the default initial branch
name is "main".
It's important we be specific about the concern, as opposed to using
abstract notions of "backwards compatibility". Because I'll note that
even if we were to release a git 3.0, it's not going to fix the
potential confusion where some students / new users trying to follow a
tutorial are using git 2.x, and some are using git 3.x.
We could delay making the change for years, but that isn't going to
guarantee that all of the various tutorials on the 'net will be
changed, and experience from long deprecation periods (exhibit 1:
Pythonx 2.x vs Python 3) is that people will drag there feet and put
off doing the work to migrate for years and years and years.
So I think it's worth making explicit exact what the nature of the
breakage is: specifically, some confusion for new users following
tutorials that haven't been updated, and to balance that off against
the costs of delaying the change for years and years and years. And
that's because individual projects and individual git repositories are
making that change *already*. So changing what the default "out of
the box" might be in some ways will make it worse for new users who
follow the some random git tutorial or traning on the web and then
then have to interact with some open source community which has
already changed their primary development branch to be "main".
If we know that's the concern, then we can improve the messaging and
documentation, and I appreciate that you have done some work along
those lines already. So let's see how we can address the problem
constructively; maybe that means making the git default trailing edge
as opposed to helping to lead the change. Maybe not.
- Ted
^ permalink raw reply [flat|nested] 25+ messages in thread* Re: The master branch rename, and avoiding another v1.6.0 git-foo fiasco
2020-11-13 14:58 ` Theodore Y. Ts'o
@ 2020-11-13 15:37 ` Felipe Contreras
2020-11-13 16:08 ` Michal Suchánek
2020-11-14 14:19 ` Lukasz Niemier
2 siblings, 0 replies; 25+ messages in thread
From: Felipe Contreras @ 2020-11-13 15:37 UTC (permalink / raw)
To: Theodore Y. Ts'o
Cc: brian m. carlson, Git, Junio C Hamano, Johannes Schindelin,
Don Goodman-Wilson
On Fri, Nov 13, 2020 at 8:58 AM Theodore Y. Ts'o <tytso@mit.edu> wrote:
>
> On Fri, Nov 13, 2020 at 12:28:52AM -0600, Felipe Contreras wrote:
> > On Thu, Nov 12, 2020 at 11:14 PM Theodore Y. Ts'o <tytso@mit.edu> wrote:
> >
> > > Is it changing the default branch name when creating a new repository?
> > > (Which affects only people creating new repositories)
> >
> > You may choose to downplay the experience of certain part of the
> > user-base, because in your experience creating new repositories
> > doesn't happen often, but that doesn't mean these users don't exist.
>
> OK, fine. That wasn't clear in your earlier messages. So this is
> *not* like 2008, where we are breaking workflows or finger macros of
> *existing* git users.
In some ways it's not as bad, but in others it's worse.
I suspect the political nature of the change is not going to be well
received, especially if it's snuck on them.
> Instead, we might be causing a certain amount of confusion with
> respect to *new* users, especially if some portion of them are using
> an older version of git, where the default initial branch name is
> "master", or a newer version of git, where the default initial branch
> name is "main".
It's not just new users. There may be other kinds of users accustomed
to creating repositories. Not all users follow the same kind of
workflows, some may not even use Git for software development.
I don't think we can claim with much certainty how *everyone* uses Git.
> It's important we be specific about the concern, as opposed to using
> abstract notions of "backwards compatibility". Because I'll note that
> even if we were to release a git 3.0, it's not going to fix the
> potential confusion where some students / new users trying to follow a
> tutorial are using git 2.x, and some are using git 3.x.
It's not going to fix them, but it would ameliorate them.
Some people today do know what changed in Bash 4.0, not so much what
changed from 3.1 to 3.2.
This is what major versions are for.
> We could delay making the change for years, but that isn't going to
> guarantee that all of the various tutorials on the 'net will be
> changed, and experience from long deprecation periods (exhibit 1:
> Pythonx 2.x vs Python 3) is that people will drag there feet and put
> off doing the work to migrate for years and years and years.
This is a false equivalence.
Yes, the migration to Python 3 was a problem, the lesson here is:
don't do what Python developers did. Ruby took a completely different
approach, and the move to Ruby 1.x to Ruby 2.0 was basically painless.
The Git project already had one basically painless major version bump,
and in my view it was generally well received. If anything it should
have changed *more* things.
Not all major version bumps are the same, and the Git project can
learn to do them the right way.
> So I think it's worth making explicit exact what the nature of the
> breakage is: specifically, some confusion for new users following
> tutorials that haven't been updated, and to balance that off against
> the costs of delaying the change for years and years and years. And
> that's because individual projects and individual git repositories are
> making that change *already*. So changing what the default "out of
> the box" might be in some ways will make it worse for new users who
> follow the some random git tutorial or traning on the web and then
> then have to interact with some open source community which has
> already changed their primary development branch to be "main".
This is once again a false equivalence.
What other projects did is the equivalent of changing the master brain
in git.git to something else. That's up to Junio and I don't
particularly care one way or another (although I would prefer if he
didn't). That would affect a relatively small number of people: Git
developers.
Changing the default of the tool is an entirely different thing that
will affect thousands of people. Apples and oranges.
Then you say if we delay it would be for "years and years and years".
Who said so? Why can't it be one year? Or six months? If it doesn't
happen tomorrow it will have to happen in 2030? No.
And then you mention other projects. Well, what other projects do is
their prerogative. Nobody forced them to make a premature decision,
and if their users suffer as a result, that's on them.
The Git project should not be held hostage by the decisions of other
projects. If it takes a couple of months, or even a year, for a change
to be done right without breaking user expectations, so be it.
> If we know that's the concern, then we can improve the messaging and
> documentation, and I appreciate that you have done some work along
> those lines already. So let's see how we can address the problem
> constructively; maybe that means making the git default trailing edge
> as opposed to helping to lead the change. Maybe not.
I think you misunderstood. I did the documentation work in 2008, for
the git-foo change, *after* the change was already rolled out, the
users complained, and I noticed the documentation was not updated.
I have not done anything for the master rename, which I believe is a
huge mistake, and has not been discussed properly yet.
That is a separate subject, here I'm just talking about the impact of
the patch that was just sent.
Moreover, none of what you have argued so far has any bearing on my
point about enabling warnings and a deprecation period.
Even if we don't wait for Git 3.0, a warning should be shown at least
a couple of months before the actual switch happens.
To sneak up an entirely political change like this without warning is
disrespecting the user-base, it's what caused the *huge* complaints in
2008, and it's just not cool.
Cheers.
--
Felipe Contreras
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: The master branch rename, and avoiding another v1.6.0 git-foo fiasco
2020-11-13 14:58 ` Theodore Y. Ts'o
2020-11-13 15:37 ` Felipe Contreras
@ 2020-11-13 16:08 ` Michal Suchánek
2020-11-14 14:19 ` Lukasz Niemier
2 siblings, 0 replies; 25+ messages in thread
From: Michal Suchánek @ 2020-11-13 16:08 UTC (permalink / raw)
To: Theodore Y. Ts'o
Cc: Felipe Contreras, brian m. carlson, Git, Junio C Hamano,
Johannes Schindelin, Don Goodman-Wilson
On Fri, Nov 13, 2020 at 09:58:02AM -0500, Theodore Y. Ts'o wrote:
> On Fri, Nov 13, 2020 at 12:28:52AM -0600, Felipe Contreras wrote:
> > On Thu, Nov 12, 2020 at 11:14 PM Theodore Y. Ts'o <tytso@mit.edu> wrote:
> >
> > > Is it changing the default branch name when creating a new repository?
> > > (Which affects only people creating new repositories)
> >
> > You may choose to downplay the experience of certain part of the
> > user-base, because in your experience creating new repositories
> > doesn't happen often, but that doesn't mean these users don't exist.
>
> OK, fine. That wasn't clear in your earlier messages. So this is
> *not* like 2008, where we are breaking workflows or finger macros of
> *existing* git users.
>
> Instead, we might be causing a certain amount of confusion with
> respect to *new* users, especially if some portion of them are using
> an older version of git, where the default initial branch name is
> "master", or a newer version of git, where the default initial branch
> name is "main".
>
> It's important we be specific about the concern, as opposed to using
> abstract notions of "backwards compatibility". Because I'll note that
> even if we were to release a git 3.0, it's not going to fix the
> potential confusion where some students / new users trying to follow a
> tutorial are using git 2.x, and some are using git 3.x.
>
> We could delay making the change for years, but that isn't going to
> guarantee that all of the various tutorials on the 'net will be
> changed, and experience from long deprecation periods (exhibit 1:
> Pythonx 2.x vs Python 3) is that people will drag there feet and put
> off doing the work to migrate for years and years and years.
But we could, for example, provide a way to specify the default branch
when creating the repository, and rewrite the tutorials to advise users
to specify a branch name, at least the ones provided by git project
itself. Then what the default is does not matter.
Thanks
Michal
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: The master branch rename, and avoiding another v1.6.0 git-foo fiasco
2020-11-13 14:58 ` Theodore Y. Ts'o
2020-11-13 15:37 ` Felipe Contreras
2020-11-13 16:08 ` Michal Suchánek
@ 2020-11-14 14:19 ` Lukasz Niemier
2020-11-15 3:46 ` Theodore Y. Ts'o
2 siblings, 1 reply; 25+ messages in thread
From: Lukasz Niemier @ 2020-11-14 14:19 UTC (permalink / raw)
To: Theodore Y. Ts'o
Cc: Felipe Contreras, brian m. carlson, Git, Junio C Hamano,
Johannes Schindelin, Don Goodman-Wilson
> OK, fine. That wasn't clear in your earlier messages. So this is
> *not* like 2008, where we are breaking workflows or finger macros of
> *existing* git users.
>
> Instead, we might be causing a certain amount of confusion with
> respect to *new* users, especially if some portion of them are using
> an older version of git, where the default initial branch name is
> "master", or a newer version of git, where the default initial branch
> name is "main".
I am pretty much **existing** Git user where I am maintaining few repos
yet I am constantly creating new ones for another projects of mine. Such
abrupt change in the default branch name, without any warning, would be
very confusing for me. Not every user is working on a single Git repo
for their whole life.
I feel that our view on who is **new** or **existing** user differs.
--
Łukasz Niemier
lukasz.niemier@kobil.com
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: The master branch rename, and avoiding another v1.6.0 git-foo fiasco
2020-11-14 14:19 ` Lukasz Niemier
@ 2020-11-15 3:46 ` Theodore Y. Ts'o
2020-11-15 4:27 ` Felipe Contreras
2020-11-19 1:02 ` Brandon Casey
0 siblings, 2 replies; 25+ messages in thread
From: Theodore Y. Ts'o @ 2020-11-15 3:46 UTC (permalink / raw)
To: Lukasz Niemier
Cc: Felipe Contreras, brian m. carlson, Git, Junio C Hamano,
Johannes Schindelin, Don Goodman-Wilson
On Sat, Nov 14, 2020 at 02:19:59PM +0000, Lukasz Niemier wrote:
> > OK, fine. That wasn't clear in your earlier messages. So this is
> > *not* like 2008, where we are breaking workflows or finger macros of
> > *existing* git users.
> >
> > Instead, we might be causing a certain amount of confusion with
> > respect to *new* users, especially if some portion of them are using
> > an older version of git, where the default initial branch name is
> > "master", or a newer version of git, where the default initial branch
> > name is "main".
>
> I am pretty much **existing** Git user where I am maintaining few repos
> yet I am constantly creating new ones for another projects of mine. Such
> abrupt change in the default branch name, without any warning, would be
> very confusing for me. Not every user is working on a single Git repo
> for their whole life.
So we need to make sure existing users know that they can add:
[init]
defaultBranch = master
to their ~/.gitconfig if they want the legacy behavior. This could be
done by, in addition to mentioning it in the release notes, or by
adding a comment printed out when "git init" is run and there is not
init.defaultBranch defined in ~/.gitconfig.
We do something similar if merge.ff is not in ~/.gitconfig, and people
run "git merge" without --no-ff or --ff-only specified on the command
line. So there is precedence for this sort of thing.
This *really* is not hard; which is why I am starting to suspect
people are really kvetching because their objections are really more
about the woke/anti-woke aspect of the "master" -> "main" migration
--- and they are using *think* the children^H^H^H^H^H^H^H users as a
rhetorical device.
- Ted
^ permalink raw reply [flat|nested] 25+ messages in thread* Re: The master branch rename, and avoiding another v1.6.0 git-foo fiasco
2020-11-15 3:46 ` Theodore Y. Ts'o
@ 2020-11-15 4:27 ` Felipe Contreras
2020-11-19 1:02 ` Brandon Casey
1 sibling, 0 replies; 25+ messages in thread
From: Felipe Contreras @ 2020-11-15 4:27 UTC (permalink / raw)
To: Theodore Y. Ts'o
Cc: Lukasz Niemier, brian m. carlson, Git, Junio C Hamano,
Johannes Schindelin, Don Goodman-Wilson
On Sat, Nov 14, 2020 at 9:47 PM Theodore Y. Ts'o <tytso@mit.edu> wrote:
> On Sat, Nov 14, 2020 at 02:19:59PM +0000, Lukasz Niemier wrote:
> > I am pretty much **existing** Git user where I am maintaining few repos
> > yet I am constantly creating new ones for another projects of mine. Such
> > abrupt change in the default branch name, without any warning, would be
> > very confusing for me. Not every user is working on a single Git repo
> > for their whole life.
>
> So we need to make sure existing users know that they can add:
>
> [init]
> defaultBranch = master
>
> to their ~/.gitconfig if they want the legacy behavior. This could be
> done by, in addition to mentioning it in the release notes, or by
> adding a comment printed out when "git init" is run and there is not
> init.defaultBranch defined in ~/.gitconfig.
Which is precisely my suggestion: add a warning.
> We do something similar if merge.ff is not in ~/.gitconfig, and people
> run "git merge" without --no-ff or --ff-only specified on the command
> line. So there is precedence for this sort of thing.
And we did precisely the same thing with push.default.
> This *really* is not hard; which is why I am starting to suspect
> people are really kvetching because their objections are really more
> about the woke/anti-woke aspect of the "master" -> "main" migration
> --- and they are using *think* the children^H^H^H^H^H^H^H users as a
> rhetorical device.
Exactly.
There's literally no other reason to change the default branch name
(other than woke reasons), and the people against adding such a
warning would be doing so purely due to their personal agenda, because
they are in a hurry to get the change in, regardless of the
implications towards users.
Putting personal agendas aside... we need to add a warning so that
users get notified of the impending change, and let the chips fall
where they may.
Cheers.
--
Felipe Contreras
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: The master branch rename, and avoiding another v1.6.0 git-foo fiasco
2020-11-15 3:46 ` Theodore Y. Ts'o
2020-11-15 4:27 ` Felipe Contreras
@ 2020-11-19 1:02 ` Brandon Casey
2020-11-19 4:16 ` Peter Hadlaw
2020-11-19 13:37 ` Konstantin Ryabitsev
1 sibling, 2 replies; 25+ messages in thread
From: Brandon Casey @ 2020-11-19 1:02 UTC (permalink / raw)
To: Theodore Y. Ts'o
Cc: Lukasz Niemier, Felipe Contreras, brian m. carlson, Git,
Junio C Hamano, Johannes Schindelin, Don Goodman-Wilson
On Sat, Nov 14, 2020 at 8:23 PM Theodore Y. Ts'o <tytso@mit.edu> wrote:
> This *really* is not hard; which is why I am starting to suspect
> people are really kvetching because their objections are really more
> about the woke/anti-woke aspect of the "master" -> "main" migration
> --- and they are using *think* the children^H^H^H^H^H^H^H users as a
> rhetorical device.
So we're changing the default branch name from "master" to "main"?
For what purpose? What problem are we trying to solve?
Is the word "master" now going to become a taboo word that we're all
afraid to say?
Isn't this all a little silly? What's wrong with the term "master"?
It's a well understood and commonly used term that denotes
"authority", i.e. the master branch is the authoritative branch.
People sleep in master bedrooms. Universities have headmasters and
award master's degrees. Skilled people become master craftsmen and
give master classes (e.g. master plumber, master diver). Recording
artists master a track. Skilled chess players become chess masters
etc.
-Brandon
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: The master branch rename, and avoiding another v1.6.0 git-foo fiasco
2020-11-19 1:02 ` Brandon Casey
@ 2020-11-19 4:16 ` Peter Hadlaw
2020-11-19 13:37 ` Konstantin Ryabitsev
1 sibling, 0 replies; 25+ messages in thread
From: Peter Hadlaw @ 2020-11-19 4:16 UTC (permalink / raw)
To: Brandon Casey
Cc: Theodore Y. Ts'o, Lukasz Niemier, Felipe Contreras,
brian m. carlson, Git, Junio C Hamano, Johannes Schindelin,
Don Goodman-Wilson
Reposting a bit from a side thread, so excuse me. Felt that this is
more of a relevant place to leave these thoughts.
***
If some people or teams would prefer _their_ default branches to be
anything other than `master`, I'm all for giving them the tools to
live out their dreams. That's what `git config` and the new
`defaultBranch` flag are for. There is no need to force these desires
onto _all_ users.
***
It's worth noting that the word "slave" comes from the en_slav_ement
of Slavs (the Slavic people of Eastern Europe). Check "Slav Twitter"
if you must, you'll find nothing but a chuckle at this situation.
I encourage everyone to really think about the changes you are making.
It was just reported to me that a professional friend of mine had
confusion as to why, after initializing a new repository, they
couldn't navigate to the `master` branch of their repository.
I understand this is back-of-the-napkin type math but stay with me for
one moment. I also understand GitHub is not all of git users, but I
just pulled the number to help me out here.
If GitHub has 40 million users but let's say half of them aren't
active, so now we are at 20 million.
(Replace this number with how many actual users of git are out there.)
Let's even say half of them are on board and aware of this "harmless"
change to a more "sensitive" doublespeak representation of the
"master" copy/branch of the repo. That leaves us with 10 million users
of git that are either unaware or are not on board. Let's say it takes
3 minutes for a user to search on the web why exactly they can't
navigate to their "master" branch. That's 30 million minutes wasted,
or about 57 man-YEARs of time wasted.... for what? Oh but you'll ask
them what their default is? Do the same math... better yet realize
this is just a power exercise of one very tiny group over another.
When do we put our foot down and say enough is enough, and not
everything is offensive?
Again, please reconsider making this change towards
doublespeak/Newspeak and consider the ramifications of how much actual
human life & time will be wasted. Ignoring adding on the new
reputation of the git project to kowtow to "current year" politics.
Besides just the annoyance to users in their day to day, yes there is
mention of "just update the tutorials!" but what a way to dishonor the
millions of hours people have put into welcoming other individuals to
the git community. There is no reason to outdate their tutorials and
documentation so prematurely (and yet again exercise power over them
by making them update their content for no real reason).
--
Peter
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: The master branch rename, and avoiding another v1.6.0 git-foo fiasco
2020-11-19 1:02 ` Brandon Casey
2020-11-19 4:16 ` Peter Hadlaw
@ 2020-11-19 13:37 ` Konstantin Ryabitsev
2020-11-19 21:25 ` Junio C Hamano
2020-11-19 21:29 ` Brandon Casey
1 sibling, 2 replies; 25+ messages in thread
From: Konstantin Ryabitsev @ 2020-11-19 13:37 UTC (permalink / raw)
To: Brandon Casey
Cc: Theodore Y. Ts'o, Lukasz Niemier, Felipe Contreras,
brian m. carlson, Git, Junio C Hamano, Johannes Schindelin,
Don Goodman-Wilson
On Wed, Nov 18, 2020 at 05:02:59PM -0800, Brandon Casey wrote:
> > This *really* is not hard; which is why I am starting to suspect
> > people are really kvetching because their objections are really more
> > about the woke/anti-woke aspect of the "master" -> "main" migration
> > --- and they are using *think* the children^H^H^H^H^H^H^H users as a
> > rhetorical device.
>
> So we're changing the default branch name from "master" to "main"?
To my knowledge, there are no concrete plans to change anything at this
time. All recent work was to remove any special-case treatment of
"master" as the default branch name, so people are free to use any
configuration they like.
> For what purpose? What problem are we trying to solve?
People want to be able to use arbitrary branch names.
> Is the word "master" now going to become a taboo word that we're all
> afraid to say?
No, everyone is welcome to use it if they like. It has perfectly
legitimate usage cases -- for example, some of the staunchest opponents
of this terminology continue to list their "Master of Arts" degree on
LinkedIn.
> Isn't this all a little silly? What's wrong with the term "master"?
It is misleading in the context of git, because it implies that a branch
carrying that name is in some way special compared to other branches
(e.g. like "trunk" in the SVN world). In reality, the "master" branch is
just a branch like all others (and can be missing entirely or have junk
in it), so it really shouldn't be called "master".
> It's a well understood and commonly used term that denotes
> "authority", i.e. the master branch is the authoritative branch.
> People sleep in master bedrooms. Universities have headmasters and
> award master's degrees. Skilled people become master craftsmen and
> give master classes (e.g. master plumber, master diver). Recording
> artists master a track. Skilled chess players become chess masters
> etc.
Exactly, thank you for illustrating my point. In all of the above
situations the word "master" is used to indicate some kind of
distinction. If all you have is a single bedroom, it would be kinda
obnoxious to refer to it as "the master bedroom," eh? :)
-K
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: The master branch rename, and avoiding another v1.6.0 git-foo fiasco
2020-11-19 13:37 ` Konstantin Ryabitsev
@ 2020-11-19 21:25 ` Junio C Hamano
2020-11-19 23:29 ` Felipe Contreras
2020-11-20 19:14 ` Konstantin Ryabitsev
2020-11-19 21:29 ` Brandon Casey
1 sibling, 2 replies; 25+ messages in thread
From: Junio C Hamano @ 2020-11-19 21:25 UTC (permalink / raw)
To: Konstantin Ryabitsev
Cc: Brandon Casey, Theodore Y. Ts'o, Lukasz Niemier,
Felipe Contreras, brian m. carlson, Git, Johannes Schindelin,
Don Goodman-Wilson
Konstantin Ryabitsev <konstantin@linuxfoundation.org> writes:
>> So we're changing the default branch name from "master" to "main"?
>
> To my knowledge, there are no concrete plans to change anything at this
> time. All recent work was to remove any special-case treatment of
> "master" as the default branch name, so people are free to use any
> configuration they like.
That is a fair description of one state which is a bit stale.
All recent work has been to make sure our tests will not lose test
coverage when we decide to change the fallback default value for
init.defaultBranch to a value other than 'master'. In other words,
we have been talking about changing (or not changing).
The question most useful to ask at this point are to what name
(fixed? computed?) and what the transition plan would look like.
>> For what purpose? What problem are we trying to solve?
>
> People want to be able to use arbitrary branch names.
What you gave was the purpose of init.defaultBranch we've introduced
in the last release, but that does not answer the question you are
answering.
The discussion thread you posted to, however, is already talking
about changing (or not changing) the fallback default value for that
variable, i.e. what name does the initial branch get upon "git init"
for end-users who do not indicate any preference.
Some understand well that the primary reason to switch to 'main' is
to help people who will need to interact with projects and hosting
providers that have done the same switch already [*1*]. Some do not
buy that reason well and ask "why?". You need to give an answer to
the latter.
>> Is the word "master" now going to become a taboo word that we're all
>> afraid to say?
>
> No, everyone is welcome to use it if they like. It has perfectly
> legitimate usage cases -- for example, some of the staunchest opponents
> of this terminology continue to list their "Master of Arts" degree on
> LinkedIn.
Correct.
>> Isn't this all a little silly? What's wrong with the term "master"?
>
> It is misleading in the context of git, because it implies that a branch
> carrying that name is in some way special compared to other branches
> (e.g. like "trunk" in the SVN world). In reality, the "master" branch is
> just a branch like all others (and can be missing entirely or have junk
> in it), so it really shouldn't be called "master".
I find the above answer even more confusing, in the context of major
projects and hosting sites all moving to 'main'. If 'master' is
misleading for all the reasons stated in the above paragraph, 'main'
would equally be misleading. In other words, "It is just a branch
like all others, so it really shouldn't be 'master'" leads to "it
shouldn't be 'main' or 'primary', either".
I personally am fond of this line of "let's not treat one single
thing any special among others" thinking, but I think the way people
use the initially created branch tends to make it special at the end
of the day.
While the project is still in its infancy, you may use that as the
only branch until the tree of the project starts to take its shape,
perhaps with subdirectories dedicated to sources, documentation, and
overall build procedure, etc. Then you may start to fork different
branches off of it to work on topics that last more than one
commit's worth of time. At that point, it is likely you'd use the
initially created branch as the primary integration branch, until
you start to need the second and third integration branches. Like
it or not, the primary integration branch would inevitably end up
being something more special than others, and it is likely that
using the initially created branch for that purpose would be the
most convenient. There however may exist two or more equally
significant branches, not just one special one, though, but it is
reasonable to have at least one special one.
And for this reason, it does not make much sense to change the
fallback default to "unnamed"---that would force everybody to
immediately rename it (or set init.defaultBranch).
[Footnote]
*1* We expect many projects end users would interact with to be
using 'main' as the branch of primary interest, and cloning from
such a project would give you 'main' (i.e. "git clone" finds
what name the other side users, and uses the same name locally).
If a new user is starting their Git experience from scratch in
such a world, it would be more helpful if their "git init"
placed them on the 'main' branch, and their hello world project
built on that single branch is pushed to the 'main' branch in
their publishing repository at hosting sites'. In such a world,
tutorial books will all be written with 'main' as the initial
branch name, too, even though good ones would mention that
historically 'master' has been used and the readers would see
projects with history longer than readers' Git lifetime may
still use 'master' as the primary branch.
^ permalink raw reply [flat|nested] 25+ messages in thread* Re: The master branch rename, and avoiding another v1.6.0 git-foo fiasco
2020-11-19 21:25 ` Junio C Hamano
@ 2020-11-19 23:29 ` Felipe Contreras
2020-11-20 19:14 ` Konstantin Ryabitsev
1 sibling, 0 replies; 25+ messages in thread
From: Felipe Contreras @ 2020-11-19 23:29 UTC (permalink / raw)
To: Junio C Hamano
Cc: Konstantin Ryabitsev, Brandon Casey, Theodore Y. Ts'o,
Lukasz Niemier, brian m. carlson, Git, Johannes Schindelin,
Don Goodman-Wilson
On Thu, Nov 19, 2020 at 3:25 PM Junio C Hamano <gitster@pobox.com> wrote:
> Some understand well that the primary reason to switch to 'main' is
> to help people who will need to interact with projects and hosting
> providers that have done the same switch already [*1*]. Some do not
> buy that reason well and ask "why?". You need to give an answer to
> the latter.
How exactly does this help people interacting with GitHub?
The main instructions in GitHub while creating a new repository are:
echo "# test" >> README.md
git init
git add README.md
git commit -m "first commit"
git branch -M main
git remote add origin $url
git push -u origin main
Changing the default to "main" would modify the instructions to:
echo "# test" >> README.md
git init
git add README.md
git commit -m "first commit"
git remote add origin $url
git push -u origin main
One line. That's it.
Moreover, they can already get rid of that line, all they have to do
is "git init -b main" instead of "git init".
Why haven't they updated the instructions?
Ahh, that's right... it's because the instructions are meant to work
on older versions of git as well.
Therefore, even if the default was changed in Git 2.30, they will not
change the instructions.
It's very likely that even if Git changes the default in 2020, GitHub
will not change the instructions by 2022, possibly 2024 (if the world
still stands).
So how exactly will this change help GitHub and other hosting providers?
The anti-master camp came here *demanding* a name change, and in the
process of discussing many claims were simply taken for granted, even
though no prima facie was offered.
But no, the claim that this change will "help people who will need to
interact with projects and hosting providers that have done the same
switch already" has not met its burden of proof.
In fact, no attempt has even been made to explain *how* it would help.
Cheers.
--
Felipe Contreras
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: The master branch rename, and avoiding another v1.6.0 git-foo fiasco
2020-11-19 21:25 ` Junio C Hamano
2020-11-19 23:29 ` Felipe Contreras
@ 2020-11-20 19:14 ` Konstantin Ryabitsev
1 sibling, 0 replies; 25+ messages in thread
From: Konstantin Ryabitsev @ 2020-11-20 19:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git
On Thu, Nov 19, 2020 at 01:25:27PM -0800, Junio C Hamano wrote:
> The question most useful to ask at this point are to what name
> (fixed? computed?) and what the transition plan would look like.
Right, hence my statement that there are no "concrete plans." I've
previously suggested that, should this change be implemented, it makes
sense to couple it with another upcoming major compatibility break --
the sha1 deprecation. Perhaps we can start with the following:
Currently:
$ git init
Initialized empty Git repository in /var/home/user/foo/.git/
$
New:
$ git init
Initialized empty Git repository in /var/home/user/foo/.git/
Initial branch: master
Object format: sha1
Use --initial-branch and --object-format flags to specify other values.
$
> > It is misleading in the context of git, because it implies that a
> > branch carrying that name is in some way special compared to other
> > branches (e.g. like "trunk" in the SVN world). In reality, the
> > "master" branch is just a branch like all others (and can be missing
> > entirely or have junk in it), so it really shouldn't be called
> > "master".
>
> I find the above answer even more confusing, in the context of major
> projects and hosting sites all moving to 'main'. If 'master' is
> misleading for all the reasons stated in the above paragraph, 'main'
> would equally be misleading. In other words, "It is just a branch
> like all others, so it really shouldn't be 'master'" leads to "it
> shouldn't be 'main' or 'primary', either".
In my mind, there are important semantic differences between "main" and
"master" that make "main" more acceptable. A town with a single road can
reasonably call it the "main road." Similarly, a "mainstream" movement
does not imply the existence of any other movements. Etc.
-K
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: The master branch rename, and avoiding another v1.6.0 git-foo fiasco
2020-11-19 13:37 ` Konstantin Ryabitsev
2020-11-19 21:25 ` Junio C Hamano
@ 2020-11-19 21:29 ` Brandon Casey
2020-11-20 0:34 ` Felipe Contreras
1 sibling, 1 reply; 25+ messages in thread
From: Brandon Casey @ 2020-11-19 21:29 UTC (permalink / raw)
To: Brandon Casey, Theodore Y. Ts'o, Lukasz Niemier,
Felipe Contreras, brian m. carlson, Git, Junio C Hamano,
Johannes Schindelin, Don Goodman-Wilson
On Thu, Nov 19, 2020 at 5:37 AM Konstantin Ryabitsev
<konstantin@linuxfoundation.org> wrote:
>
> On Wed, Nov 18, 2020 at 05:02:59PM -0800, Brandon Casey wrote:
> > > This *really* is not hard; which is why I am starting to suspect
> > > people are really kvetching because their objections are really more
> > > about the woke/anti-woke aspect of the "master" -> "main" migration
> > > --- and they are using *think* the children^H^H^H^H^H^H^H users as a
> > > rhetorical device.
> >
> > So we're changing the default branch name from "master" to "main"?
>
> To my knowledge, there are no concrete plans to change anything at this
> time. All recent work was to remove any special-case treatment of
> "master" as the default branch name, so people are free to use any
> configuration they like.
Glad to hear that. That doesn't seem to be the perspective that others
have in this discussion thread though, especially since Theodore Ts'o
referred to "...the "master" -> "main" migration" in his comment that
I quoted above.
Thanks for trying to respond to my questions, but I think your
responses are mostly misdirected towards an issue that I was not
referring to. That being the configurability of the default branch
name, which I doubt anyone has a problem with, as opposed to changing
the default branch name for all newly created repositories and
possibly for the git repo itself for some supposed offensiveness of
the word "master". That is what I consider silly.
For example, when I asked "So we're changing the default branch name
from "master" to "main"?" and then followed that up with "For what
purpose?", the latter question was asking "For what purpose are we
changing the default branch name from "master" to "main"?", and then
"What problem are we trying to solve by changing the default branch
name from "master" to "main"?" etc.
-Brandon
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: The master branch rename, and avoiding another v1.6.0 git-foo fiasco
2020-11-19 21:29 ` Brandon Casey
@ 2020-11-20 0:34 ` Felipe Contreras
0 siblings, 0 replies; 25+ messages in thread
From: Felipe Contreras @ 2020-11-20 0:34 UTC (permalink / raw)
To: Brandon Casey
Cc: Theodore Y. Ts'o, Lukasz Niemier, brian m. carlson, Git,
Junio C Hamano, Johannes Schindelin, Don Goodman-Wilson
On Thu, Nov 19, 2020 at 3:29 PM Brandon Casey <drafnel@gmail.com> wrote:
> On Thu, Nov 19, 2020 at 5:37 AM Konstantin Ryabitsev
> <konstantin@linuxfoundation.org> wrote:
> > To my knowledge, there are no concrete plans to change anything at this
> > time. All recent work was to remove any special-case treatment of
> > "master" as the default branch name, so people are free to use any
> > configuration they like.
>
> Glad to hear that. That doesn't seem to be the perspective that others
> have in this discussion thread though, especially since Theodore Ts'o
> referred to "...the "master" -> "main" migration" in his comment that
> I quoted above.
Let me try to clarify to you.
At this precise moment the name of the branch is "master", and will
continue to be until a concrete plan to change it is put forward.
However, the momentum is there to change the default name. So, if the
camp in favor of the change keeps pushing forward, finishes all the
necessary work, and puts a plan in place--which will probably include
a precautionary warning--the name will likely be eventually changed.
It's only a matter of when.
Since there's many agendas: a) get the name changed as soon as
possible, b) change the name, but do it properly and take as long as
is indeed, c) change the name, but not necessarily to "main", and d)
do not change the name; what you are seeing is probably a clash of
many agendas and no clarity from the project.
Moreover, once the plan is set in motion, and many users are notified
of things upcoming change, I suspect there will be a backlash, and the
"decision" might be reconsidered.
So, even though things are not set in stone, and the dust has not yet
settled, the move towards a change away from the default branch name
"master" is currently happening.
Cheers.
--
Felipe Contreras
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: The master branch rename, and avoiding another v1.6.0 git-foo fiasco
2020-11-13 4:27 ` Felipe Contreras
2020-11-13 5:14 ` Theodore Y. Ts'o
@ 2020-11-13 6:09 ` Don Goodman-Wilson
[not found] ` <nbCkLegnP_kb-16UzAuDChE0p68ZtRD_3ZN3o3BJHYBYpUxTWuKjvhCSKT7zRZl_sckHrkyJl2fwePFUBR-HtDcEV0rHuac6Ygg-FrrYsYI=@goodman-wilson.com>
2020-11-20 18:38 ` Ismael Luceno
3 siblings, 0 replies; 25+ messages in thread
From: Don Goodman-Wilson @ 2020-11-13 6:09 UTC (permalink / raw)
To: Felipe Contreras
Cc: brian m. carlson, Git, Junio C Hamano, Johannes Schindelin
> Did we hear the testimony of a single black person that was offended
by the word?
> Nobody affected by this change actually asked for this change
Five minutes searching Twitter will reveal a great number of Black git users championing this change.
How is reopening this discussion anything but a distraction?
Don Goodman-Wilson
> On 13 Nov 2020, at 05:27, Felipe Contreras <felipe.contreras@gmail.com> wrote:
>
>
> On Thu, Nov 12, 2020 at 7:01 PM brian m. carlson
> <sandals@crustytoothpaste.net> wrote:
>>
>> On 2020-11-13 at 00:04:23, Felipe Contreras wrote:
>>> *If* we are going to rename the master branch, it should be with a
>>> good reason, after discussing it appropriately, in a major release
>>> (i.e. Git 3.0), after a period of deprecation, and a big warning to
>>> invite users to provide feedback about the important upcoming change.
>>> We can hedge these types of changes with a "core.mode=next"
>>> configuration, as I argued back in 2013. [3]
>>
>> When the original email that proposed this change came up, I did suggest
>> that this would be suitable for a Git 3.0. I think such a version
>> number bump would be valuable, but I know that Git doesn't follow
>> semantic versioning and I'm happy for Junio to make the call. Git has
>> made incompatible changes in the past in non-major versions, so there is
>> precedent for this, although I agree it has the potential to be
>> surprising. Again, I defer to Junio's judgment here.
>
> I have not been following the Git project for a while, but during the
> Git 2.0 development I proposed considerable drastic changes, which
> Junio said could not fit into v2.0, but perhaps v3.0, which according
> to him: [1]
>
> "Even if we end up having to wait for 3.0, it will happen within two
> years max, if not earlier." -- Junio 2014
>
> There are actual good backwards-incompatible changes that a new major
> release of Git would benefit from, so if Junio changed his mind about
> considering these types of changes, it would be good to know.
>
> I for one haven't noticed a single backwards-incompatible change since v2.0.
>
>> I should point out that there is an option to test or set this already,
>> with init.defaultBranch. I have used this feature for testing in the
>> past, and I use the feature now to set default branches. It's also
>> possible to use the template functionality to set a default branch name
>> for new repositories and I've tested support for this back to at least
>> Git 2.0 (but I believe it goes back even farther). And, of course,
>> either of these options can be used for developers to choose the branch
>> name which meets the needs of the project best.
>
> There was also the option to test the future changes in v1.6.0, that's
> not the point.
>
> The point is that users **must be warned**--and very annoyingly
> so--before obsoleting something.
>
>> As for consultation with users, there was a discussion about this on the
>> list a few months back and we did get a lot of input from various
>> parties. Some of that feedback was hostile and inappropriate and some
>> even violated our code of conduct in my view, as is all too common with
>> potentially controversial topics, and I'm not eager to repeat such a
>> discussion, since I don't think it's going to result in a productive,
>> positive outcome.
>
> I looked for this kind of discussion, but didn't find it. I didn't
> imagine it was as far back as June.
>
> It took a while, but I finally read the whole thread, and I understand
> your unwillingness to repeat such a discussion, but unfortunately it
> will have to happen again, because the people that participated in
> that discussion are but a tiny minority that is not representative of
> all Git users. If not now, it will happen in the future. This is
> exactly what happened in 2008, when the issue was discussed in at
> least three big threads.
>
> Moreover, my point was not discussed in that thread. You mentioned it,
> but everyone focused on tangents, such as the state of the culture
> war, and the etymology of the word "master".
>
> To try to save your sanity I will attempt to be brief (but probably
> not as brief as you would like to).
>
> This is what was discussed:
>
> 1. Adding a configuration (init.defaultbranch)
> 2. Should the name of the master branch be changed?
> 3. Best alternative name for the master branch
> 4. Culture war
> 5. The impact to users
>
> I have a lot to say about 4, 3, and 2, and perhaps I will do so in
> another thread, but that's not important, what is important is the
> thing that was not discussed: the users.
>
> I like to refer to a panel Linus Torvalds participated in regarding
> the importance of users [2]. I consider this an explanation of the
> first principles of software: the main purpose of software is that
> it's useful to users, and that it continues to be useful as it moves
> forward. To quote Torvalds:
>
> "Any time a program breaks the user experience, to me that is the
> absolute worst failure that a software project can make." -- Linus
> Torvalds
>
> This is the first thing the Git project should be worried about, not
> the current state of the culture war, and I didn't see anyone
> championing the users, and how this change will negatively impact
> their experience, which arguably has been pretty stable throughout the
> years (at least since 2008).
>
> That being said, I want to touch on only one point you brought
> forward, that is indirectly relevant to the users.
>
> You mentioned the importance of intent [3], and how we can never be
> certain of the intent of another person, this is true. However, we
> must try to guess what the interlocutor might have meant, otherwise
> there is no point in communication. This is realized in Wikipedia's
> fundamental principle of always assuming good faith [4], Grice's
> philosophical razor: prefer what the speaker meant over what the
> sentence they spoke literally meant [5][6].
>
> You cannot stand in a comedy special without realizing what the comic
> actually means, and it rarely is what he literally says. If I utter
> the phrase "kill me now", you know what I mean, or more importantly;
> what I don't mean.
>
> A lot of people today want to ignore this fundamental aspect of human
> language, and they do so for political reasons. But it doesn't stop it
> from being the case. It's not a coincidence that since 2005 nobody had
> any problem with the word "master", it's only in 2020 that the issue
> "magically" popped up. And it's no coincidence either what kind of
> people are pushing for this change.
>
> This is a solution looking for a problem.
>
> There is a concept called "the silent majority" which applies in
> software. Most Git users are not going to participate in culture war
> debates in the mailing list. It is usually a tiny vociferous minority
> that drives these kinds of discussions (and if it has to be said; I
> don't mean any negative connotation, simply stating that they are the
> opposite of silent). Even the users that are supposedly the target of
> these progressive changes (e.g. black users descendant of slaves) will
> probably not care at all about such changes, because they are part of
> the silent majority that uses common sense and understands that
> nothing ill was intended by the word "master". It is usually white
> people that "defend" these "oppressed minorities" without their
> consent, or need.
>
> Did we hear the testimony of a single black person that was offended
> by the word?
>
> The intellectual Gad Saad wrote about a disorder called Munchausen
> syndrome by proxy, and how it explains what many modern activists do:
> [7]
>
> "Munchausen Syndrome is where a person feigns illness, or medical
> conditions, to garner empathy and sympathy. Munchausen Syndrome by
> proxy is when you take someone who is under your care (your biological
> child, your pet, your elderly parent) and then harm that person or
> entity that’s under your care so that you can then garner the empathy
> and sympathy by proxy."
>
> Nobody affected by this change actually asked for this change, it is
> being done *preemptively* just in case some actual target user might
> find it offensive. The only people actually being offended are
> offended *by proxy*.
>
> I recommend the book The Parasitic Mind: How Infectious Ideas Are
> Killing Common Sense, which explains this and many more problems of
> the current culture war.
>
> I have a lot more to say about this, believe me, and perhaps I will do
> so in another thread, but for now the summary is this:
>
> We are going to *actually* harm true users that understand the intent
> behind the word "master" hoping we might benefit marginally some
> imaginary users.
>
> And if we don't warn them about the upcoming change, before the change
> is actually implemented (as we did with push.default), they will
> complain. Because unlike the users that are descendants of black
> slaves who misinterpret what Git developers meant by the word "master"
> and get offended as result--they are *real*, and they are a lot.
>
> Cheers.
>
> [1] https://lore.kernel.org/git/xmqqioq12eif.fsf@gitster.dls.corp.google.com/
> [2] https://www.youtube.com/watch?v=kzKzUBLEzwk
> [3] https://lore.kernel.org/git/20200614190842.GC6531@camp.crustytoothpaste.net/
> [4] https://en.wikipedia.org/wiki/Wikipedia:Assume_good_faith
> [5] https://rationalwiki.org/wiki/Logical_razor#Grice.27s_razor
> [6] https://plato.stanford.edu/entries/implicature/
> [7] https://thoughteconomics.com/gad-saad/
>
> --
> Felipe Contreras
^ permalink raw reply [flat|nested] 25+ messages in thread[parent not found: <nbCkLegnP_kb-16UzAuDChE0p68ZtRD_3ZN3o3BJHYBYpUxTWuKjvhCSKT7zRZl_sckHrkyJl2fwePFUBR-HtDcEV0rHuac6Ygg-FrrYsYI=@goodman-wilson.com>]
* Re: The master branch rename, and avoiding another v1.6.0 git-foo fiasco
[not found] ` <nbCkLegnP_kb-16UzAuDChE0p68ZtRD_3ZN3o3BJHYBYpUxTWuKjvhCSKT7zRZl_sckHrkyJl2fwePFUBR-HtDcEV0rHuac6Ygg-FrrYsYI=@goodman-wilson.com>
@ 2020-11-13 6:47 ` Felipe Contreras
2020-11-13 13:53 ` Philippe Blain
0 siblings, 1 reply; 25+ messages in thread
From: Felipe Contreras @ 2020-11-13 6:47 UTC (permalink / raw)
To: D.E. Goodman-Wilson
Cc: brian m. carlson, Git, Junio C Hamano, Johannes Schindelin
On Fri, Nov 13, 2020 at 12:02 AM D.E. Goodman-Wilson
<don@goodman-wilson.com> wrote:
> > Did we hear the testimony of a single black person that was offended
> by the word?
>
> > Nobody affected by this change actually asked for this change
>
> Five minutes searching Twitter will reveal a great number of Black git users championing this change.
This is anecdotal evidence.
We all live in our own digital bubble. Every person's Twitter feed is
different, and Google search results depend on where you live, and
your past searches.
You may find "a great number" of users that match that criteria, what
I find is only people criticizing the move, and after five minutes I
haven't found a single black person actually offended by the current
name.
> How is reopening this discussion anything but a distraction?
This discussion never happened.
Everyone in the June thread argued about the different names of the
potential branch, and the culture war implications. Virtually *nobody*
argued about the manner of implementation: deprecation period, clear
warnings, Git 3.0 consideration.
I'd argue *that* was the distraction.
In 2008 people started multiple threads *after* the sudden change to
git-foo without warning happened.
If we do the same, this discussion will happen again. I'm just the
canary in the coal mine giving you a heads up.
Choosing to ignore the very real danger doesn't make the very real
danger go away, you are just delaying it and making it potentially
bigger. You choose to ignore the canary at your own peril. This is
precisely what happened in 2008.
Cheers.
--
Felipe Contreras
^ permalink raw reply [flat|nested] 25+ messages in thread* Re: The master branch rename, and avoiding another v1.6.0 git-foo fiasco
2020-11-13 6:47 ` Felipe Contreras
@ 2020-11-13 13:53 ` Philippe Blain
2020-11-13 15:49 ` Felipe Contreras
2020-11-23 15:39 ` Whinis
0 siblings, 2 replies; 25+ messages in thread
From: Philippe Blain @ 2020-11-13 13:53 UTC (permalink / raw)
To: Felipe Contreras
Cc: D.E. Goodman-Wilson, brian m. carlson, Git mailing list,
Junio C Hamano, Johannes Schindelin
Hi Felipe,
> Le 13 nov. 2020 à 01:47, Felipe Contreras <felipe.contreras@gmail.com> a écrit :
>
> On Fri, Nov 13, 2020 at 12:02 AM D.E. Goodman-Wilson
> <don@goodman-wilson.com> wrote:
>>> Did we hear the testimony of a single black person that was offended
>> by the word?
>>
>>> Nobody affected by this change actually asked for this change
>>
>> Five minutes searching Twitter will reveal a great number of Black git users championing this change.
>
> This is anecdotal evidence.
>
> We all live in our own digital bubble. Every person's Twitter feed is
> different, and Google search results depend on where you live, and
> your past searches.
>
> You may find "a great number" of users that match that criteria, what
> I find is only people criticizing the move, and after five minutes I
> haven't found a single black person actually offended by the current
> name.
>
>> How is reopening this discussion anything but a distraction?
>
> This discussion never happened.
>
> Everyone in the June thread argued about the different names of the
> potential branch, and the culture war implications. Virtually *nobody*
> argued about the manner of implementation: deprecation period, clear
> warnings, Git 3.0 consideration.
I couldn't agree more. We really need to be warning users several versions in advance,
and I mean months or even years. I don't wan't to come up with a number, but I would
guess that maybe 85 %, (or even 95 % ?) of the world-wide Git user base is unaware that any discussion
on that topic ever took place.
Brian mentioned that some people voicing their concern on the list did not abide by the code of conduct.
There was also very vocal disagreement voiced in the Git-for-Windows GitHub project before the
discussion reached the mailing list, of which a lot was also considered to not abide by that project's
code of conduct. While I agree that discussion should be done with respect, and some people that
are driven to react to such important changes might not be aware of any code of conduct they should
follow, because they don't participate in the "day-to-day" life of the project, just the fact that they even
care enough to voice their disagreement should be a big red flag in terms of how this change should be done,
in my opinion.
I had avoided commenting on this whole subject, but the main point you are bringing,
that such a change, if done, should be made with great care to our user base and a lot
more warning, is a very important one.
Thanks for bringing it up.
Philippe.
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: The master branch rename, and avoiding another v1.6.0 git-foo fiasco
2020-11-13 13:53 ` Philippe Blain
@ 2020-11-13 15:49 ` Felipe Contreras
2020-11-23 15:39 ` Whinis
1 sibling, 0 replies; 25+ messages in thread
From: Felipe Contreras @ 2020-11-13 15:49 UTC (permalink / raw)
To: Philippe Blain
Cc: D.E. Goodman-Wilson, brian m. carlson, Git mailing list,
Junio C Hamano, Johannes Schindelin
On Fri, Nov 13, 2020 at 7:53 AM Philippe Blain
<levraiphilippeblain@gmail.com> wrote:
> > This discussion never happened.
> >
> > Everyone in the June thread argued about the different names of the
> > potential branch, and the culture war implications. Virtually *nobody*
> > argued about the manner of implementation: deprecation period, clear
> > warnings, Git 3.0 consideration.
>
> I couldn't agree more. We really need to be warning users several versions in advance,
> and I mean months or even years. I don't wan't to come up with a number, but I would
> guess that maybe 85 %, (or even 95 % ?) of the world-wide Git user base is unaware that any discussion
> on that topic ever took place.
More like 99.9%.
> Brian mentioned that some people voicing their concern on the list did not abide by the code of conduct.
> There was also very vocal disagreement voiced in the Git-for-Windows GitHub project before the
> discussion reached the mailing list, of which a lot was also considered to not abide by that project's
> code of conduct. While I agree that discussion should be done with respect, and some people that
> are driven to react to such important changes might not be aware of any code of conduct they should
> follow, because they don't participate in the "day-to-day" life of the project, just the fact that they even
> care enough to voice their disagreement should be a big red flag in terms of how this change should be done,
> in my opinion.
Yes, the abrasive tone of those users did not help, but neither does
tone policing. At the end of the day they did some valid arguments,
and it will be the users that suffer because the project decided to
focus on the tone, rather than the argument.
> I had avoided commenting on this whole subject, but the main point you are bringing,
> that such a change, if done, should be made with great care to our user base and a lot
> more warning, is a very important one.
Indeed. I am debating whether or not I should bring up the arguments
nobody brought up in that big discussion, because in 2020 the concept
of freedom of speech is lost, and merely stating facts can get you
banned from a community, or worse. But the facts remain true.
For now I think this is the imminent issue, and a warning must be
issued so that users know what is coming. I suspect when they realize
what's coming, they will preemptively complain in the mailing list.
We'll see. But sneaking this change is *definitely* going to upset
many users, making the problem worse.
Cheers.
--
Felipe Contreras
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: The master branch rename, and avoiding another v1.6.0 git-foo fiasco
2020-11-13 13:53 ` Philippe Blain
2020-11-13 15:49 ` Felipe Contreras
@ 2020-11-23 15:39 ` Whinis
1 sibling, 0 replies; 25+ messages in thread
From: Whinis @ 2020-11-23 15:39 UTC (permalink / raw)
To: levraiphilippeblain
Cc: Johannes.Schindelin, don, felipe.contreras, git, gitster, sandals
> I couldn't agree more. We really need to be warning users several versions in advance,
> and I mean months or even years. I don't wan't to come up with a number, but I would
> guess that maybe 85 %, (or even 95 % ?) of the world-wide Git user base is unaware that any discussion
> on that topic ever took place.
>
> Brian mentioned that some people voicing their concern on the list did not abide by the code of conduct.
> There was also very vocal disagreement voiced in the Git-for-Windows GitHub project before the
> discussion reached the mailing list, of which a lot was also considered to not abide by that project's
> code of conduct. While I agree that discussion should be done with respect, and some people that
> are driven to react to such important changes might not be aware of any code of conduct they should
> follow, because they don't participate in the "day-to-day" life of the project, just the fact that they even
> care enough to voice their disagreement should be a big red flag in terms of how this change should be done,
> in my opinion.
>
> I had avoided commenting on this whole subject, but the main point you are bringing,
> that such a change, if done, should be made with great care to our user base and a lot
> more warning, is a very important one.
>
> Thanks for bringing it up.
>
> Philippe.
Not just Git-for-Windows but there is also numerous reddit threads
expressing both disbelief that this would even be considered and anger
at how it might hurt various workflows as well as issues on gitlab and
gitea which were closed as soon as any discussion started normally
citing the code of conduct even if no real violations occurred. The one
exception was gitlab where it was closed, reopened and allowed for long
discussion before being closed again. In the gitlab one certainly user
issues were brought up, even if primarily by me, before being discarded
as those for the change purely on emotional reasoning. What I find sort
of interesting is the constant claim that its a direct reference to
slavery also without any proof.
Overall this is a massive change that will affect users, documentation,
and classes for years to come if made and should only be made with
clear, articulatable, realizable benefits such as the SHA1 change.
Breaking years of documentation and books without that clear and obvious
benefit is a disservice to users and likely to cause significant harm in
the short and long term and a clear tenant of why few projects change
things just to change things. The risk of unintended effects is too
great once something is well recognized as python and others have found
out trying to remove what their perceived as problematic language
leading to multiple incompatible versions.
Whinis
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: The master branch rename, and avoiding another v1.6.0 git-foo fiasco
2020-11-13 4:27 ` Felipe Contreras
` (2 preceding siblings ...)
[not found] ` <nbCkLegnP_kb-16UzAuDChE0p68ZtRD_3ZN3o3BJHYBYpUxTWuKjvhCSKT7zRZl_sckHrkyJl2fwePFUBR-HtDcEV0rHuac6Ygg-FrrYsYI=@goodman-wilson.com>
@ 2020-11-20 18:38 ` Ismael Luceno
3 siblings, 0 replies; 25+ messages in thread
From: Ismael Luceno @ 2020-11-20 18:38 UTC (permalink / raw)
To: Felipe Contreras
Cc: brian m. carlson, Git, Junio C Hamano, Johannes Schindelin,
Don Goodman-Wilson
Hi,
Probably like the overwhelming majority, I don't care about the
default changing, but for the sake of completeness, I must say:
This is a very USA-specific issue, and it's getting blown out of
proportion there, but basically the rest of the world pretty much
doesn't care.
Don't overlook the fact that the discrimination arises not from the
words you choose, but from the ideas and prejudices, embeded in
everything in your culture.
All these movements don't do anything real.
It doesn't fix the problems for those in our community suffering from
very real, intentional, abuse and discrimination, often done in a
soft-spoken manner.
It just makes a very few feel good with themselves because they did
something about a non-existing issue, and over their own
over-sensitive and skewed views of the world.
Moreover, it's just an unhealthy enablement of a bunch of pampered
thin-skinned nutheads nit-picking over language because they have
nothing better to do.
And if there's anyone that truly feels hurt by this kind of words,
they should use a dictionary, and if they still feel that way
afterwards, perhaps they should talk to a professional about their
feelings because what they're experiencing may be psychosis.
Quietly, some of us are trying to make the world a better place by
tackling real discrimination issues, and I can only feel indigtation
over how shallow the community is becoming.
Thanks.
El vie, 13 de nov. de 2020 a la(s) 05:30, Felipe Contreras
(felipe.contreras@gmail.com) escribió:
>
> On Thu, Nov 12, 2020 at 7:01 PM brian m. carlson
> <sandals@crustytoothpaste.net> wrote:
> >
> > On 2020-11-13 at 00:04:23, Felipe Contreras wrote:
> > > *If* we are going to rename the master branch, it should be with a
> > > good reason, after discussing it appropriately, in a major release
> > > (i.e. Git 3.0), after a period of deprecation, and a big warning to
> > > invite users to provide feedback about the important upcoming change.
> > > We can hedge these types of changes with a "core.mode=next"
> > > configuration, as I argued back in 2013. [3]
> >
> > When the original email that proposed this change came up, I did suggest
> > that this would be suitable for a Git 3.0. I think such a version
> > number bump would be valuable, but I know that Git doesn't follow
> > semantic versioning and I'm happy for Junio to make the call. Git has
> > made incompatible changes in the past in non-major versions, so there is
> > precedent for this, although I agree it has the potential to be
> > surprising. Again, I defer to Junio's judgment here.
>
> I have not been following the Git project for a while, but during the
> Git 2.0 development I proposed considerable drastic changes, which
> Junio said could not fit into v2.0, but perhaps v3.0, which according
> to him: [1]
>
> "Even if we end up having to wait for 3.0, it will happen within two
> years max, if not earlier." -- Junio 2014
>
> There are actual good backwards-incompatible changes that a new major
> release of Git would benefit from, so if Junio changed his mind about
> considering these types of changes, it would be good to know.
>
> I for one haven't noticed a single backwards-incompatible change since v2.0.
>
> > I should point out that there is an option to test or set this already,
> > with init.defaultBranch. I have used this feature for testing in the
> > past, and I use the feature now to set default branches. It's also
> > possible to use the template functionality to set a default branch name
> > for new repositories and I've tested support for this back to at least
> > Git 2.0 (but I believe it goes back even farther). And, of course,
> > either of these options can be used for developers to choose the branch
> > name which meets the needs of the project best.
>
> There was also the option to test the future changes in v1.6.0, that's
> not the point.
>
> The point is that users **must be warned**--and very annoyingly
> so--before obsoleting something.
>
> > As for consultation with users, there was a discussion about this on the
> > list a few months back and we did get a lot of input from various
> > parties. Some of that feedback was hostile and inappropriate and some
> > even violated our code of conduct in my view, as is all too common with
> > potentially controversial topics, and I'm not eager to repeat such a
> > discussion, since I don't think it's going to result in a productive,
> > positive outcome.
>
> I looked for this kind of discussion, but didn't find it. I didn't
> imagine it was as far back as June.
>
> It took a while, but I finally read the whole thread, and I understand
> your unwillingness to repeat such a discussion, but unfortunately it
> will have to happen again, because the people that participated in
> that discussion are but a tiny minority that is not representative of
> all Git users. If not now, it will happen in the future. This is
> exactly what happened in 2008, when the issue was discussed in at
> least three big threads.
>
> Moreover, my point was not discussed in that thread. You mentioned it,
> but everyone focused on tangents, such as the state of the culture
> war, and the etymology of the word "master".
>
> To try to save your sanity I will attempt to be brief (but probably
> not as brief as you would like to).
>
> This is what was discussed:
>
> 1. Adding a configuration (init.defaultbranch)
> 2. Should the name of the master branch be changed?
> 3. Best alternative name for the master branch
> 4. Culture war
> 5. The impact to users
>
> I have a lot to say about 4, 3, and 2, and perhaps I will do so in
> another thread, but that's not important, what is important is the
> thing that was not discussed: the users.
>
> I like to refer to a panel Linus Torvalds participated in regarding
> the importance of users [2]. I consider this an explanation of the
> first principles of software: the main purpose of software is that
> it's useful to users, and that it continues to be useful as it moves
> forward. To quote Torvalds:
>
> "Any time a program breaks the user experience, to me that is the
> absolute worst failure that a software project can make." -- Linus
> Torvalds
>
> This is the first thing the Git project should be worried about, not
> the current state of the culture war, and I didn't see anyone
> championing the users, and how this change will negatively impact
> their experience, which arguably has been pretty stable throughout the
> years (at least since 2008).
>
> That being said, I want to touch on only one point you brought
> forward, that is indirectly relevant to the users.
>
> You mentioned the importance of intent [3], and how we can never be
> certain of the intent of another person, this is true. However, we
> must try to guess what the interlocutor might have meant, otherwise
> there is no point in communication. This is realized in Wikipedia's
> fundamental principle of always assuming good faith [4], Grice's
> philosophical razor: prefer what the speaker meant over what the
> sentence they spoke literally meant [5][6].
>
> You cannot stand in a comedy special without realizing what the comic
> actually means, and it rarely is what he literally says. If I utter
> the phrase "kill me now", you know what I mean, or more importantly;
> what I don't mean.
>
> A lot of people today want to ignore this fundamental aspect of human
> language, and they do so for political reasons. But it doesn't stop it
> from being the case. It's not a coincidence that since 2005 nobody had
> any problem with the word "master", it's only in 2020 that the issue
> "magically" popped up. And it's no coincidence either what kind of
> people are pushing for this change.
>
> This is a solution looking for a problem.
>
> There is a concept called "the silent majority" which applies in
> software. Most Git users are not going to participate in culture war
> debates in the mailing list. It is usually a tiny vociferous minority
> that drives these kinds of discussions (and if it has to be said; I
> don't mean any negative connotation, simply stating that they are the
> opposite of silent). Even the users that are supposedly the target of
> these progressive changes (e.g. black users descendant of slaves) will
> probably not care at all about such changes, because they are part of
> the silent majority that uses common sense and understands that
> nothing ill was intended by the word "master". It is usually white
> people that "defend" these "oppressed minorities" without their
> consent, or need.
>
> Did we hear the testimony of a single black person that was offended
> by the word?
>
> The intellectual Gad Saad wrote about a disorder called Munchausen
> syndrome by proxy, and how it explains what many modern activists do:
> [7]
>
> "Munchausen Syndrome is where a person feigns illness, or medical
> conditions, to garner empathy and sympathy. Munchausen Syndrome by
> proxy is when you take someone who is under your care (your biological
> child, your pet, your elderly parent) and then harm that person or
> entity that’s under your care so that you can then garner the empathy
> and sympathy by proxy."
>
> Nobody affected by this change actually asked for this change, it is
> being done *preemptively* just in case some actual target user might
> find it offensive. The only people actually being offended are
> offended *by proxy*.
>
> I recommend the book The Parasitic Mind: How Infectious Ideas Are
> Killing Common Sense, which explains this and many more problems of
> the current culture war.
>
> I have a lot more to say about this, believe me, and perhaps I will do
> so in another thread, but for now the summary is this:
>
> We are going to *actually* harm true users that understand the intent
> behind the word "master" hoping we might benefit marginally some
> imaginary users.
>
> And if we don't warn them about the upcoming change, before the change
> is actually implemented (as we did with push.default), they will
> complain. Because unlike the users that are descendants of black
> slaves who misinterpret what Git developers meant by the word "master"
> and get offended as result--they are *real*, and they are a lot.
>
> Cheers.
>
> [1] https://lore.kernel.org/git/xmqqioq12eif.fsf@gitster.dls.corp.google.com/
> [2] https://www.youtube.com/watch?v=kzKzUBLEzwk
> [3] https://lore.kernel.org/git/20200614190842.GC6531@camp.crustytoothpaste.net/
> [4] https://en.wikipedia.org/wiki/Wikipedia:Assume_good_faith
> [5] https://rationalwiki.org/wiki/Logical_razor#Grice.27s_razor
> [6] https://plato.stanford.edu/entries/implicature/
> [7] https://thoughteconomics.com/gad-saad/
>
> --
> Felipe Contreras
^ permalink raw reply [flat|nested] 25+ messages in thread