Ramkumar Ramachandra [off-list ref] writes:
A few small personal itches off the top of my head:
- Make git status -s show "state status" as well: this essentially
requires writing an equivalent of wt_status_print_state() for use in
wt_shortstatus_print().
Do you mean, showing it in a natural language form, or machine-parsable?
If the later, there was a patch series doing essentially this:
http://thread.gmane.org/gmane.comp.version-control.git/209240
It doesn't seem to have been merged. Phil, what happened to it?
- Make the -s and -b switches in git status configuration variables.
I currently have status aliased to status -sb, and this is less than
ideal.
- Make the -3 and -c switches in git am configuration variables. I
have an alias.
Seems reasonable. Should be good technical warm-ups if people agree this
is a good idea.
- Create an advice.ui (like color.ui) to turn off all advice. I don't
need advice.
I tend to agree with you, but the idea has explicitly been rejected in
the past. The problem with an option like this is that it would also
disable the advices that may be added in the future. By letting people
disable the advices one by one, people see new advices as they arrive.
You may think of it like "do not show this message again" tickboxes in
some graphical user interfaces.
Too controversial area for newcommers I guess ;-).
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
On Mon, Apr 15, 2013 at 06:32:49PM +0200, Matthieu Moy wrote:
quoted
- Create an advice.ui (like color.ui) to turn off all advice. I don't
need advice.
I tend to agree with you, but the idea has explicitly been rejected in
the past. The problem with an option like this is that it would also
disable the advices that may be added in the future. By letting people
disable the advices one by one, people see new advices as they arrive.
You may think of it like "do not show this message again" tickboxes in
some graphical user interfaces.
FWIW, I do not think it was so much rejected as that I had initially
planned to implement it, then decided against it. Mostly because I
wanted to actually get annoyed with each piece of advice before
disabling it. Because sometimes the right answer is actually "make the
advice better".
But I do not mind somebody adding it if it is a burning desire.
-Peff
Matthieu Moy wrote:
I tend to agree with you, but the idea has explicitly been rejected in
the past. The problem with an option like this is that it would also
disable the advices that may be added in the future. By letting people
disable the advices one by one, people see new advices as they arrive.
You may think of it like "do not show this message again" tickboxes in
some graphical user interfaces.
Too controversial area for newcommers I guess ;-).
This is the kind of nonsense that I absolutely won't stand for. Am I
a less important customer than a newcomer? Hell, if anything, I'm the
_more_ important customer because I spend time improving git while a
newcomer makes no contribution whatsoever. In my opinion, the most
important customers of git are (in this order of precedence):
1. Developers who hack on git to make it better. This means that the
implementation must have a pleasing consistency, and end-user
expectations of UI are secondary. For some reason, Junio seems to
disagree with this.
2. Advanced users hacking on projects that demand effective use of git
like linux.git and git.git, as opposed to some little project on
GitHub that just accepts pull requests.
3. Newcomers.
I don't develop git for newcomers. I develop git for myself, and
scratch my personal itches. The most important customer to me is
myself, and everyone else is secondary.
That said, I don't feel strongly about this particular advice.ui
issue, and Jeff/ Junio have presented a reasonably cogent argument.