Request to remove Junio C Hamano as the Git Maintainer

Request to remove Junio C Hamano as the Git Maintainer

[Filip Lipien]

There are more than one million questions on Stackoverflow related to the usage of Git.
This is not normal. 

Git is in its current state not a tool that's made for humans.

It's realistic to assume, that millions of working hours were wasted due to his ignorance of developer experience.
The financial damage goes into the billions.

I hereby request the removal of Junio C Hamano 濱野純 as the Git Maintainer.

Re: Request to remove Junio C Hamano as the Git Maintainer

[Theodore Ts'o]

On Sat, Dec 31, 2022 at 06:11:17PM +0000, Filip Lipien wrote:
> There are more than one million questions on Stackoverflow related to the usage of Git.
> This is not normal.

Incorrect.  As of this writing, there are 146,090 quetions[1] tagged
[git] on stackoverflow.  Compare that to the 161,963 questions[2]
tagged [windows], or the 2,084,537 questions[3] tagged [python].

[1] https://stackoverflow.com/questions/tagged/git
[2] https://stackoverflow.com/questions/tagged/windows
[3] https://stackoverflow.com/questions/tagged/python

The fact that there are a large number of questions in stackoverflow
is more a measure of a tool's popularity than anything else.  And if
it's popular, it's probably because a large number of developers have
found it to be *useful*.

> Git is in its current state not a tool that's made for humans.

It's made for developers like me, and last I checked, I'm human.  :-)
It may not be made for you, but that's OK; you don't have to use it.

My personal opinion is that it has probably *saved* a net total of
billions of dollars of developer time, for those who know how to use
it.

Best regards,

						- Ted

P.S.  I would commend to you Neal Stephenson's essay, "In the
beginning was the command line".  It was available for sale as a book,
but as it was published a while back in 1999, it's since been made
available for free download[4].  Unfortunately, because it was so
popular, the resulting download traffic crashed his publisher's
website, and it's no longer available there.  The best place to get it
is here[5].

[4] https://www.nealstephenson.com/in-the-beginning-was-the-command-line.html
[5] https://github.com/danielmkarlsson/library/blob/master/Neal%20Stephenson%20-%20In%20the%20Beginning%20was%20the%20Command%20Line.pdf

It's a short read; only 60 pages in the PDF.  About midway through the
essay, in section 11, there is a comparison made between Linux and the
Hole Hawg, an industrial drill made by the Milwaukee Tool Company.  If
Linux is the Hole Hawg of Operating Systems, then perhaps git is the
Hole Hawg of Source Code Management systems.  If it's too much SCM for
you; there's no shame --- you can always choose to use lesser SCM's
for your own personal projects.  :-)

RE: Request to remove Junio C Hamano as the Git Maintainer

[rsbecker]

On December 31, 2022 1:11 PM, Filip Lipien wrote:
>There are more than one million questions on Stackoverflow related to the usage
>of Git.
>This is not normal.
>
>Git is in its current state not a tool that's made for humans.

Git is used by hundreds of thousands to millions of humans on a daily basis. It manages most of the popular operating system code and compilers and without git, CI/CD would (arguably) be where it was 20 years ago. Git is part of a critical supply chain, including automation, to deliver software to production servers and edge devices.

>It's realistic to assume, that millions of working hours were wasted due to his
>ignorance of developer experience.
>The financial damage goes into the billions.

Claims like this require extraordinary evidence; rather like claiming aliens are hacking our git repositories (they are not).

>I hereby request the removal of Junio C Hamano 濱野純 as the Git Maintainer.

I hereby strongly support Junio's continued participation and hope he is not disheartened by the OP request.

Randall

--
Brief whoami: NonStop&UNIX developer since approximately
UNIX(421664400)
NonStop(211288444200000000)
-- In real life, I talk too much.

Re: Request to remove Junio C Hamano as the Git Maintainer

[Filip Lipien]

> Incorrect. As of this writing, there are 146,090 quetions[1] tagged
> [git] on stackoverflow. Compare that to the 161,963 questions[2]
> tagged [windows], or the 2,084,537 questions[3] tagged [python].

Please remain on the topic. Read my initial sentence again. What has "tagged" to do with related? And even if, the amount of 146,090 "tagged" questions is absolute madness. This is insane. Just look at the ratio in comparison to Python, a programming language. It is crazy to assume that this is fine and only proves my point. No, Git is not a complex programming language like Python, nor is it a Kernel API. It is supposed to be a user-facing tool made for humans.

The fact is, that Junio C Hamano is doing a terrible job as a product manager. Because apparently, most users seem to have a problem with it. Why can this not be pointed out?

------- Original Message -------
On Saturday, December 31st, 2022 at 8:19 PM, Theodore Ts'o <tytso@mit.edu> wrote:


> 
> 
> On Sat, Dec 31, 2022 at 06:11:17PM +0000, Filip Lipien wrote:
> 
> > There are more than one million questions on Stackoverflow related to the usage of Git.
> > This is not normal.
> 
> 
> Incorrect. As of this writing, there are 146,090 quetions[1] tagged
> [git] on stackoverflow. Compare that to the 161,963 questions[2]
> tagged [windows], or the 2,084,537 questions[3] tagged [python].
> 
> [1] https://stackoverflow.com/questions/tagged/git
> [2] https://stackoverflow.com/questions/tagged/windows
> [3] https://stackoverflow.com/questions/tagged/python
> 
> The fact that there are a large number of questions in stackoverflow
> is more a measure of a tool's popularity than anything else. And if
> it's popular, it's probably because a large number of developers have
> found it to be useful.
> 
> > Git is in its current state not a tool that's made for humans.
> 
> 
> It's made for developers like me, and last I checked, I'm human. :-)
> It may not be made for you, but that's OK; you don't have to use it.
> 
> My personal opinion is that it has probably saved a net total of
> billions of dollars of developer time, for those who know how to use
> it.
> 
> Best regards,
> 
> - Ted
> 
> P.S. I would commend to you Neal Stephenson's essay, "In the
> beginning was the command line". It was available for sale as a book,
> but as it was published a while back in 1999, it's since been made
> available for free download[4]. Unfortunately, because it was so
> popular, the resulting download traffic crashed his publisher's
> website, and it's no longer available there. The best place to get it
> is here[5].
> 
> [4] https://www.nealstephenson.com/in-the-beginning-was-the-command-line.html
> [5] https://github.com/danielmkarlsson/library/blob/master/Neal Stephenson - In the Beginning was the Command Line.pdf
> 
> It's a short read; only 60 pages in the PDF. About midway through the
> essay, in section 11, there is a comparison made between Linux and the
> Hole Hawg, an industrial drill made by the Milwaukee Tool Company. If
> Linux is the Hole Hawg of Operating Systems, then perhaps git is the
> Hole Hawg of Source Code Management systems. If it's too much SCM for
> you; there's no shame --- you can always choose to use lesser SCM's
> for your own personal projects. :-)

Re: Request to remove Junio C Hamano as the Git Maintainer

[Philip Oakley]

On 31/12/2022 23:23, Filip Lipien wrote:
>> Incorrect. As of this writing, there are 146,090 quetions[1] tagged
>> [git] on stackoverflow. Compare that to the 161,963 questions[2]
>> tagged [windows], or the 2,084,537 questions[3] tagged [python].
> Please remain on the topic. Read my initial sentence again. What has "tagged" to do with related? And even if, the amount of 146,090 "tagged" questions is absolute madness. This is insane. Just look at the ratio in comparison to Python, a programming language. It is crazy to assume that this is fine and only proves my point. No, Git is not a complex programming language like Python, nor is it a Kernel API. It is supposed to be a user-facing tool made for humans.

The purpose of Git is to provide a Source Code Management system for
Linux. Linux development is *distributed*, and Linux is command line
orientated.

The need for a distributed SCM required a significant shift in mind set
compared to previous *control* systems that were historically based on
drawing and physical part management systems [1].
 
The ability to 'manufacture' duplicate copies of code, and then modify
them, at speed, makes those historical methods essentially impractical /
unworkable. Hence Git, with all it's foibles, has been widely adopted,
as control now lies with the user. Management can still be responsible
for 'authentication/designation' of specific revisions.

Git generally offers two world views, one that roughly matches the old
'change control' methods (diffs), and true 'local state' view. It is
easy to miss the subtle shift in world views.
>
> The fact is, that Junio C Hamano is doing a terrible job as a product manager. Because apparently, most users seem to have a problem with it. Why can this not be pointed out?

Junio is not a "product manager". He is not 'selling' to the wider user
base. He is maintaining a core element of the Linux ecosystem. I doubt
it's an easy job, balancing backward compatibility, future capability,
and broad usability, along with code quality, security and all the rest.

Learning Git is like learning Quantum Mechanics, it's just a few simple
rules, but the mind set shift is difficult. It has action at a distance,
and is amazingly effective.

In many ways it's the confusion between 'developer' facing, and 'user'
facing tooling. The nuances are different.

>
> ------- Original Message -------
> On Saturday, December 31st, 2022 at 8:19 PM, Theodore Ts'o <tytso@mit.edu> wrote:
>
>
>>
>> On Sat, Dec 31, 2022 at 06:11:17PM +0000, Filip Lipien wrote:
>>
>>> There are more than one million questions on Stackoverflow related to the usage of Git.
>>> This is not normal.
>>
>> Incorrect. As of this writing, there are 146,090 quetions[1] tagged
>> [git] on stackoverflow. Compare that to the 161,963 questions[2]
>> tagged [windows], or the 2,084,537 questions[3] tagged [python].
>>
>> [1] https://stackoverflow.com/questions/tagged/git
>> [2] https://stackoverflow.com/questions/tagged/windows
>> [3] https://stackoverflow.com/questions/tagged/python
>>
>> The fact that there are a large number of questions in stackoverflow
>> is more a measure of a tool's popularity than anything else. And if
>> it's popular, it's probably because a large number of developers have
>> found it to be useful.
>>
>>> Git is in its current state not a tool that's made for humans.
>>
>> It's made for developers like me, and last I checked, I'm human. :-)
>> It may not be made for you, but that's OK; you don't have to use it.
>>
>> My personal opinion is that it has probably saved a net total of
>> billions of dollars of developer time, for those who know how to use
>> it.
>>
>> Best regards,
>>
>> - Ted
>>
>> P.S. I would commend to you Neal Stephenson's essay, "In the
>> beginning was the command line". 

In the beginning was Jacquard looms and Hollerith cards ;-)

>> It was available for sale as a book,
>> but as it was published a while back in 1999, it's since been made
>> available for free download[4]. Unfortunately, because it was so
>> popular, the resulting download traffic crashed his publisher's
>> website, and it's no longer available there. The best place to get it
>> is here[5].
>>
>> [4] https://www.nealstephenson.com/in-the-beginning-was-the-command-line.html
>> [5] https://github.com/danielmkarlsson/library/blob/master/Neal Stephenson - In the Beginning was the Command Line.pdf
>>
>> It's a short read; only 60 pages in the PDF. About midway through the
>> essay, in section 11, there is a comparison made between Linux and the
>> Hole Hawg, an industrial drill made by the Milwaukee Tool Company. If
>> Linux is the Hole Hawg of Operating Systems, then perhaps git is the
>> Hole Hawg of Source Code Management systems. If it's too much SCM for
>> you; there's no shame --- you can always choose to use lesser SCM's
>> for your own personal projects. :-)
--
Philip

[1] Mil Std 483, Def Stan 05-57, etc.

note, https://en.wikipedia.org/wiki/Configuration_management#Software
doesn't yet mention Git ;-)

Re: Request to remove Junio C Hamano as the Git Maintainer

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 3561 bytes --]

On 2022-12-31 at 18:11:17, Filip Lipien wrote:
> There are more than one million questions on Stackoverflow related to the usage of Git.
> This is not normal. 
>
> Git is in its current state not a tool that's made for humans.

There are also many questions related to Windows and Linux.  It is
unsurprising that software that is flexible is also very complicated and
that many people may have questions about how it works or the best way
to work with it.  Git is also extremely portable and popular and as such
there are many people who use it or want to use it, and therefore people
asking many questions.

As I mentioned above, many people have questions about the best way to
accomplish a task on Linux, which is also very popular.  We should not
force Linus Torvalds to step down because Linux is complex or because
people have many questions about it because it may differ from other
software they've used.

> It's realistic to assume, that millions of working hours were wasted due to his ignorance of developer experience.
> The financial damage goes into the billions.

Do I think Git could benefit from improved developer experience?
Certainly.  I think there would be substantial value in doing that, and
such topics have been discussed at contributor summits in the past.  I
was left with the impression that most contributors would like to see
this kind of work done.

However, I think you misunderstand how Junio acts as the maintainer
here.  This is not a corporation where Junio tells people what to do and
how to do it.

Instead, this is an open-source project, and it's my impression that
Junio spends most of his time shepherding other people's patches and
making sure that the project and contributions are in a good state.  He
sends relatively few patches himself, and while he might make a
suggestion on what he'd like to see out of a series or project, he
doesn't really tell people what to do because people don't have to
do what he says.

As a result, it's not really fair to blame him for a poor developer
experience.  If that's valuable to someone, then someone will send
patches to work on it, and I'm confident that Junio would accept those
once they were suitable for merging.  If nobody has sent such patches,
then the presumption is that nobody is interested in doing the work for
that at this point, and Junio isn't going to be able to just tell people
to work on it, since people work on what they want or what their
employers want (if they're working on Git in their professional
capacity).

In my role as a contributor, I've sent and reviewed patches that
correspond to my areas of interests and expertise.  While I think a
better developer experience would be valuable, I lack the experience to
contribute meaningfully in this regard, and as a consequence, I've sent
no patches here.  I welcome contributions from others in this area who
are more familiar with the work that needs to be done.

> I hereby request the removal of Junio C Hamano 濱野純 as the Git Maintainer.

I think, given my explanation above, that this is completely
unwarranted.  The maintainer of this project has no authority over
participants to force them to address developer experience here.

While I don't always agree with him on everything, I think Junio is
doing a fine job as maintainer, and assuming things stay as they are, I
would be happy with him remaining as maintainer for the indefinite
future.
-- 
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 263 bytes --]

Re: Request to remove Junio C Hamano as the Git Maintainer

[Theodore Ts'o]

On Sun, Jan 01, 2023 at 09:10:08PM +0000, brian m. carlson wrote:
> Instead, this is an open-source project, and it's my impression that
> Junio spends most of his time shepherding other people's patches and
> making sure that the project and contributions are in a good state.  He
> sends relatively few patches himself, and while he might make a
> suggestion on what he'd like to see out of a series or project, he
> doesn't really tell people what to do because people don't have to
> do what he says.

Another way of putting this is that git is perfectly usable for
intermediate to expert developers.  As a long-time Linux
developer/maintainer, my opinion is that git developer experience is
just *fine*.  I like how powerful it it is; I like how it improves my
productivity; and I don't have any problems using git.

One of the ways this can be seen is that we haven't see a huge amount
of contributions trying to make git more novice-firendly.  The fact
that we haven't seen those contributions is a strong indication that
it's not really a problem for git development community.  And given
that git developers are humans, there is very clearly a set of humans
who find their experience of git sufficiently convivial that it's not
worth their time to make it better.

So the claim that git has a poor developer experience is not accurate.
It may be that the experience for novice / beginner developers could
be improved, sure.  Unfortunately for novice / beginner developers,
they generally do not have the expertise to contribute those sorts of
patches to git.  They can send petulant messages to the git mailing
list, not understanding the difference between an open source
maintainer and a "product manager", but that's not going to be
effective.

And by the time that they do become experienced git developers, they
understand why things are the way things are, and very often, they
will find better things to do with their time.  For those that do
become experienced git contributors and who continue to be passionate
about making git easier for novice users, the challenge is how to make
git more friendly to novices while not compromising backwards
compatibilty or the power that expert users are happily using every
day.

And of course, if they are contributing to git on company time, their
company has to be willing invest their engineers' times on making git
easier for novices, which implies that most companies will want a
valid business case for making git more friendly more users for
developers like (presumably), Filip.  And if we aren't seeing those
contributions from corporately funded git developers, perhaps that is
a strong suggestion that the business case simply doesn't exist.

						- Ted

RE: Request to remove Junio C Hamano as the Git Maintainer

[_g e r r y _ _l o w r y _]

Filip, maintaining software is a big responsibility; 
       if Git were easy, maintaining would still be work.

is it Junio's fault that there a so many questions on SO?

Git stands head and shoulders above other versioning software products;
the reason is that Linus designed a superior system.

You might find Git easier to use from these links:

whether first learning Git, or reviewing what one already knows, I very strongly recommends that one starts here:
Git :: 4 short introductory videos from https://git-scm.com/doc
Total running time c. 25'
https://git-scm.com/video/what-is-version-control
https://git-scm.com/video/what-is-git
https://git-scm.com/video/get-going
https://git-scm.com/video/quick-wins
4 short introductory videos from https://git-scm.com/doc"
Note:  imho, the 4 short videos above, although limited in content, set the tone and spirit for beginning a friendship with Git; links below actually teach you Git.
"Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency."
https://git-scm.com/


free via Amazon (Kindle Edition):
Ry's Git Tutorial
 By: Ryan Hodson
https://www.amazon.ca/dp/B00QFIA5OC/


21'30"
https://youtu.be/FdZecVxzJbk      Corey Schafer
"Git Tutorial: Fixing Common Mistakes and Undoing Bad Commits"
-- watch this once for an initial overview of what one can do to dig oneself out of a hole.
-- watch this multiple times to become competent


30'32"
https://youtu.be/HVsySz-h9r4      Corey Schafer
"Git Tutorial for Beginners: Command-Line Fundamentals"
BOTTOM LINE:  the command line is a powerful way to use Git.


imho, Git is to version control as Tesla is to VW Beetle.

Filip, sounds to me like you make stuff up, like when you write:
  "The financial damage goes into the billions."


i stay neutral regarding Junio because unless you prove
otherwise, i imagine that Junio is both doing a decent job
and likely not even getting paid for it.

~~Gerry

-----Original Message-----
From: Filip Lipien <aaa@164.ooo> 
Sent: Saturday, December 31, 2022 13:11
To: git@vger.kernel.org
Cc: torvalds@linux-foundation.org
Subject: Request to remove Junio C Hamano as the Git Maintainer

There are more than one million questions on Stackoverflow related to the usage of Git.
This is not normal. 

Git is in its current state not a tool that's made for humans.

It's realistic to assume, that millions of working hours were wasted due to his ignorance of developer experience.
The financial damage goes into the billions.

I hereby request the removal of Junio C Hamano 濱野純 as the Git Maintainer.

Re: Request to remove Junio C Hamano as the Git Maintainer

[demerphq]

On Sat, 31 Dec 2022 at 19:52, Filip Lipien <aaa@164.ooo> wrote:
>
> There are more than one million questions on Stackoverflow related to the usage of Git.
> This is not normal.
>
> Git is in its current state not a tool that's made for humans.

Any tool sufficiently advanced to be useful to experts will from time
to time surprise beginners who lack context knowledge. That is normal.
Designing tools to be unsurprising for beginners usually just ends up
limiting, frustrating or surprising the experts.

> It's realistic to assume, that millions of working hours were wasted due to his ignorance of developer experience.
> The financial damage goes into the billions.

Yeah, business has adopted it wholesale because it loses them
billions. That makes sense. Not.

>
> I hereby request the removal of Junio C Hamano 濱野純 as the Git Maintainer.

That is just rude. Having a free meal in a restaurant does not give
you the right to demand the head-cook steps down because you didn't
like the way it was laid out on the plate.  Whatever it was you
intended to achieve with this post, this is not the way to go about
it.

Normally I would ignore a post like this as trolling, but others have
engaged, and I wanted to express some support for Junio as I know
these kind of things can get even the thickest skinned hacker down.

So to Junio: Thank you for your contributions. I give you strength to
ignore the trolls.  I have stated this previously, but thanks again
for add --interactive, that is a super useful tool which I use and
appreciate pretty much every single day.

cheers,
Yves

-- 
perl -Mre=debug -e "/just|another|perl|hacker/"

Re: Request to remove Junio C Hamano as the Git Maintainer

[Philip Oakley]

On 03/01/2023 00:59, _g e r r y _ _l o w r y _ wrote:
> Git stands head and shoulders above other versioning software products;
> the reason is that Linus designed a superior system.

I don't think that ("superior") is quite true, in the same way that
'world class' and 'best practice' don't have the meaning they hope to
convey ;-)

However, what Linus managed to do was to cut the Gordian Knot of the
historical versioning systems that had their original designs created in
the quill pen era, and are totally unsuited for the modern, high speed
computation and perfect replication digital age. Finally, I have control
over my versioning system (at least for software)!

In some ways, Git is like the 'Coming of the Railways'. It has brought
radical change, but at the same time, confusion, reorganisation and new
ways of thinking and working.


*Filip* has accidentally fallen into the attribution trap of blaming the
maintainer, rather than having an analysis and reflection on how Git is
being used in different user contexts. His user context may have
alternate expectations to that of the Linux eco-system, but that doesn't
excuse the lack of self reflection.

--
Philip

Re: Request to remove Junio C Hamano as the Git Maintainer

[Konstantin Khomoutov]

On Tue, Jan 03, 2023 at 01:25:12PM +0000, Philip Oakley wrote:

[...]
> However, what Linus managed to do was to cut the Gordian Knot of the
> historical versioning systems that had their original designs created in
> the quill pen era, and are totally unsuited for the modern, high speed
> computation and perfect replication digital age. Finally, I have control
> over my versioning system (at least for software)!
[...]

Being pedantinc, Git was reasonably late to the party of the distributed VC
systems, and if not for that BitKeeper controversy, who knows whether we would
have Git at all ;-)

Still, while I do not think that Git is where it is today only due to its
technical properties, these properties are what made it got its initial
traction, I suppose. The design is sound and is appealing as that of Unix.

Re: Request to remove Junio C Hamano as the Git Maintainer

[Rudy Rigot]

> Because apparently, most users seem to have a problem with it.

I apologize for reopening a conversation that probably has already
gone on too long already (I won't particularly comment on the
misguided attempt this thread was initially started for), but I
actually have some limited data points about perception of Git that
could interest people.

I'm on the project at Salesforce to move our thousand+ of developers
on our 1-million-file monolith, from ~20 years of using Perforce, to
using Git. Obviously it's a legitimately painful move for some, so
when the project got funded as a top priority, there was a decent
amount of concerns expressed by people about Git's reputation of being
complicated to use. We noted it as an adoption risk of the project,
and we were sufficiently funded to drill into understanding that risk
for our user base, so we did.

For additional context, our user base is made of very diverse
technical comfort levels. We have interns whose knowledge of Git is
one chapter of one class they had last year; we have people who have
been working with Git at Salesforce on smaller projects for years; we
have people who joined recently and have been working with Git outside
of Salesforce for years; and we have people who have been working on
the monolith at Salesforce for 20 years and never had to get into Git.

Here are some interesting data points:
- Our beta went live in November, and we now have 600+ users who
onboarded. The perforce route is still being supported for now, and
there is no incentive to switch, so it's all organic adoption.
- We do most of our support on an internal StackOverflow instance, and
move the conversation to Slack when the conversation needs to be more
synchronous. We braced for having to support people through struggling
with Git situations, but that never really happened. We currently have
200+ StackOverflow questions from people using our product; but only
~5 of them are about struggles with Git itself. All others are about
the infrastructure and tooling we built around it to mitigate our
scale, or issues using our app's build tools, that people mistakenly
thought were related to Git because they happened to have recently
switched, but were not. The wave of supporting people out of Git
struggles hasn't meaningfully happened so far.
- We sat down with the customers with the loudest concerns to build
understanding, and so far my read is:
  a- A lot of concerns we've heard that can be legitimately attributed
to something that has usability downsides with Git related to
Perforce, also offer compelling upsides that seem to make them worth
the downside so far. For instance, Perforce versions per file so
people could "get latest version" on any file separately without
impacting their other files and their "status"; but when we explain
people the upsides of Git versioning the entire codebase at once,
particularly how the top root cause of local build errors have been
due to the perforce sync having silently failed on some files, which
can't happen with Git's approach, this kind of usability downside gets
really easy to justify.
  b- Most users we've heard strong concerns from are people with a lot
of seniority on core at Salesforce. A lot of their concern seems to
boil down to the legitimate loss of value of the perforce expertise
they've built over the years. It is a very legitimate concern, but
it's a concern we have chosen to disregard because we feel it ties too
strongly with reasons companies sometimes don't adapt, and the dangers
that come with it. In fact, the fact that the concerns are limited to
this kind of user profile tracks well with our initial feeling that
this move to Git would allow us to better include newcomers and
leverage industry-wide skills.

Obviously this is somewhat anecdotal, our user base is basing
comparative judgement on one alternative only (perforce), they have
other common needs related to the app itself being managed, and we
haven't yet issued a mandate for people to switch so a lot of
concerned people are probably hiding a bit until then. So, I'm not
sure how representative of the broader Git user base ours is. But if
one would consider that it is reasonably representative, then it would
fairly strongly disprove the notion that people have legitimate
systemic problems with Git itself.

Still, I hope those data points are interesting to some. They
definitely have been fascinating and surprising to me!

Re: Request to remove Junio C Hamano as the Git Maintainer

[Ævar Arnfjörð Bjarmason]

On Tue, Jan 03 2023, demerphq wrote:

> On Sat, 31 Dec 2022 at 19:52, Filip Lipien <aaa@164.ooo> wrote:
>>
>> There are more than one million questions on Stackoverflow related to the usage of Git.
>> This is not normal.
>>
>> Git is in its current state not a tool that's made for humans.
>
> Any tool sufficiently advanced to be useful to experts will from time
> to time surprise beginners who lack context knowledge. That is normal.
> Designing tools to be unsurprising for beginners usually just ends up
> limiting, frustrating or surprising the experts.
>
>> It's realistic to assume, that millions of working hours were wasted due to his ignorance of developer experience.
>> The financial damage goes into the billions.
>
> Yeah, business has adopted it wholesale because it loses them
> billions. That makes sense. Not.
>
>>
>> I hereby request the removal of Junio C Hamano 濱野純 as the Git Maintainer.
>
> That is just rude. Having a free meal in a restaurant does not give
> you the right to demand the head-cook steps down because you didn't
> like the way it was laid out on the plate.  Whatever it was you
> intended to achieve with this post, this is not the way to go about
> it.
>
> Normally I would ignore a post like this as trolling, but others have
> engaged, and I wanted to express some support for Junio as I know
> these kind of things can get even the thickest skinned hacker down.
>
> So to Junio: Thank you for your contributions. I give you strength to
> ignore the trolls.  I have stated this previously, but thanks again
> for add --interactive, that is a super useful tool which I use and
> appreciate pretty much every single day.

Yes, thanks Junio!

I agree on the "trolling" front, and just to concede part of that
ill-phrased point: As a long-term user & contributor of git I agree that
there's lots of cases where git's UX is bad.

Some have noted in this thread that it's partially inherent complexity,
that's also true. Any tool supporting a DVCS workflow will probably
always be more complex than a CVCS (although I'd argue that's largely an
illusion, as it just pushes complexity for e.g. conflicts outside of the
system).

But part of it is just that git's UX is crappy in places. Often there's
a good reason (e.g. backwards compatibility), but often there isn't.

Now, is that the fault of Junio or this development community? I don't
think so. I think it would be possible to have a maintainer (e.g. with
some BOFH attitude) that would be unreasonably hostile to user
friendlyness.

But it's really not that, it's just more mundane reasons.

E.g.:

* Much of the interface being organically grown (and some committee
  design would have had its own issues, or never gotten off the
  ground).

  Fixing inconsistencies is possible, but runs into backwards
  compatibility, creating more confusion by change etc.

* Lots of cases where the UX could be improved, even trivially. Some
  places where we could add advise(), or otherwise improve/fix messaging
  come to mind (those almost never impact backwards compatibility). But
  working on all of those requires volunteer time etc.

I'd also like Git's UX improved, and don't want anyone to get the
impression that such changes aren't welcome here.

As someone who's pushed for much of that (from the i18n subsystem, to
various new advise() etc.) my experience is that Junio's been very
receptive to those sort of changes, and helpful in getting them accepted
& released.

Re: Request to remove Junio C Hamano as the Git Maintainer

[Rudy Rigot]

Oh, I know your email was not in response to mine Ævar, but I feel I
should clarify anyway.

We're glad that our data points about our internal adoption are
looking good about Git itself, but that is absolutely not to say that
there isn't a lot of room for improvement on Git's UX. I fully agree
with how Ævar put it. If anybody had in mind to do work to improve UX,
please don't read my previous message as meaning that such
improvements would be pointless.

I've been lurking through a number of threads of the mailing list for
the past few months, and it doesn't seem to me that UX-related patches
aren't getting attention, quite the opposite. That is a great thing,
because UX is hard to get right (particularly for powerful tools), and
obviously that kind of work doesn't have a finish line. I'd argue
those are some of the most interesting threads on here, and I hope
people feel reassured that they will be supported through those.