Thread (14 messages) 14 messages, 10 authors, 2023-01-12

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

From: Ævar Arnfjörð Bjarmason <hidden>
Date: 2023-01-12 09:45:32

On Tue, Jan 03 2023, demerphq wrote:
On Sat, 31 Dec 2022 at 19:52, Filip Lipien [off-list ref] wrote:
quoted
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.
quoted
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.
quoted
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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help