git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Felipe Contreras <felipe.contreras@gmail.com>
To: Jonathan Nieder <jrnieder@gmail.com>
Cc: Junio C Hamano <gitster@pobox.com>,
	git@vger.kernel.org, Michael J Gruber <git@drmicha.warpmail.net>,
	"J. Bruce Fields" <bfields@fieldses.org>,
	Hannu Koivisto <azure@iki.fi>, Jeff King <peff@peff.net>,
	Wincent Colaiuta <win@wincent.com>,
	Matthias Lederhofer <matled@gmx.net>
Subject: Re: [PATCH v2 0/2] user-manual: new "getting started" section
Date: Thu, 12 Nov 2009 01:15:11 +0200	[thread overview]
Message-ID: <94a0d4530911111515q643e263bn3adc6b47cd968d3d@mail.gmail.com> (raw)
In-Reply-To: <20091025111438.GA11252@progeny.tock>

On Sun, Oct 25, 2009 at 1:14 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Felipe Contreras wrote:
>> Supposing that color.ui is 'auto' by default,
>
> Should it be?  I think it would not be too hard to detect a color
> terminal by checking $TERM.  Are many people bothered by color?  Do we
> need some way to make it more obvious how to turn color _off_?

I think it should be.

>> No, but "improving" needs "changing", and the discussion I see is
>> biased towards "not changing".
> [...]
>> I don't think the user manual is achieving that purpose. I don't know
>> if it's the user manual's fault, or git's UI. Both areas need a lot of
>> improvement (as the git user survey suggests), and I've tried to
>> improve both with a lot resistance in both. So I'm not very hopeful
>> anymore.
>
> I hope you have not misunderstood.  I cannot speak for everyone else
> here, but I know I am happier when (1) fixes match problems to be
> solved in a documented way and (2) fixes do not unnecessarily break
> unrelated habits.  One way to bring this about is to justify each
> change by explaining what real problem it will solve and how it avoids
> collateral damage.  Without that justification, a change is indeed
> dangerous and might be worth resisting until it gets clarified.  But
> this is not meant to prevent fixes from occuring at all.

Well. I've sent many patches, and gone through several iterations.
After fixing all outstanding issues, addressing all the comments, and
getting several "I like this" votes, Junio suddenly decides he doesn't
like the initial changes at all and doesn't provide any way forward.

I don't see how that's an environment that fosters changes.

> Could you list some UI patches that were overlooked or not properly
> addressed?  Maybe people just forgot about them or were waiting for an
> updated version, or maybe the problems some solve weren’t articulated
> clearly yet.  I would be glad to help out in any way I can.

For example there have been many attempts to bring the 'git stage' to
foreground of the UI; right now it's kind of hidden and many people
don't even realize it's there. Even simplistic attempts as
standardizing --index, --cache and so on into --stage have failed
miserably.

Again, there doesn't seem to be a path forward. Perhaps the git's
stage will remain an obscure feature of git forever. (all the input
from git user's survey points out that people are not really using it)

>> Judging from the luck I've had pushing even the simplest
>> changes I don't think it will improve much more, unfortunately.
>
> Even the simplest changes can be hard.  But I hope they do not amount
> to nothing.  I hope at the very least the git-config manual page will
> improve...

What I mean is: if the simplest changes are *impossible*, then there's
barely any hope of progress.

Cheers.

-- 
Felipe Contreras

  reply	other threads:[~2009-11-11 23:15 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-24  9:44 [PATCH v2 0/2] user-manual: new "getting started" section Felipe Contreras
2009-10-24  9:44 ` [PATCH v2 1/2] user-manual: add global config section Felipe Contreras
2009-10-24  9:44 ` [PATCH v2 2/2] user-manual: simplify the user configuration Felipe Contreras
2009-10-24 13:06 ` [PATCH v2 0/2] user-manual: new "getting started" section Nanako Shiraishi
2009-10-24 14:08   ` Felipe Contreras
2009-10-24 14:14     ` Björn Steinbrink
2009-10-24 14:22       ` Felipe Contreras
2009-10-24 17:51 ` Junio C Hamano
2009-10-24 18:19   ` Junio C Hamano
2009-10-24 20:16     ` Felipe Contreras
2009-10-25  0:26       ` J. Bruce Fields
2009-10-25  3:08       ` Junio C Hamano
2009-10-25  9:43         ` Felipe Contreras
2009-10-25 11:14           ` Jonathan Nieder
2009-11-11 23:15             ` Felipe Contreras [this message]
2009-11-12 11:29               ` Michael J Gruber
2009-11-12 20:04                 ` Felipe Contreras
2009-11-13 21:06                 ` Nanako Shiraishi
2009-11-16 22:52                   ` Felipe Contreras
2009-11-17 12:06                     ` Nanako Shiraishi
2009-11-17 17:28                       ` J. Bruce Fields
2009-11-17 18:25                         ` Junio C Hamano
2009-11-17 22:00                           ` Felipe Contreras
2009-11-17 22:19                             ` Junio C Hamano
2009-11-17 23:06                               ` Felipe Contreras
2009-11-17 23:13                                 ` Junio C Hamano
2009-11-18  0:05                                   ` Felipe Contreras
2009-11-17 17:53                       ` Matthieu Moy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=94a0d4530911111515q643e263bn3adc6b47cd968d3d@mail.gmail.com \
    --to=felipe.contreras@gmail.com \
    --cc=azure@iki.fi \
    --cc=bfields@fieldses.org \
    --cc=git@drmicha.warpmail.net \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jrnieder@gmail.com \
    --cc=matled@gmx.net \
    --cc=peff@peff.net \
    --cc=win@wincent.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).