git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Kaartic Sivaraam <kaarticsivaraam91196@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH/RFC] commit-template: improve readability of commit template
Date: Wed, 28 Jun 2017 18:34:22 +0530	[thread overview]
Message-ID: <1498655062.1935.2.camel@gmail.com> (raw)
In-Reply-To: <xmqqwp7x1fie.fsf@gitster.mtv.corp.google.com>

On Tue, 2017-06-27 at 10:56 -0700, Junio C Hamano wrote:
> Kaartic Sivaraam <kaarticsivaraam91196@gmail.com> writes:
> > I thought it's not good to trade-off readability for vertical space
> > as
> > the ultimate aim of the commit template (at least to me) is to
> > convey
> > information to the user about the commit that he's going to make.
> > For
> > which, I thought it made more sense to improve it's readability by
> > adding new lines between different sections rather than constrain
> > the
> > output within a few lines.
> 
> You have to be careful when making a trade-off argument.  It depends
> on how familiar you already are with the presentation.  Those who
> are/got used to the order of things that come, they will know there
> is extra information when the block of lines are longer than usual
> without reading every character and then their eyes are guided to
> read what is extra, without having to waste precious screen real
> estate.  Nobody will _stay_ a new user who is not yet familiar with
> the everyday output.
> 
You're right. I didn't consider the fact that experienced users would
be affected as a result of this change, sorry about that. I thought,
making this change would help the new users who would possibly find the
commit template to be congested and let experienced users to get
accustomed to this new output format. I thought this change would be a
win-win (at least after people get accustomed to the new formatting). 

In case screen real estate is considered more important here, no
issues. I'll drop that part of the change, happily.

> > I actually didn't think of modifying that in order to keep it in
> > line
> > with the output of `git status`.
> 
> I was (and still am) assuming that if we make this change to "git
> commit", we should make matching change to "git status" as a given.
I get it now. In that case, I don't think making the change would be a
good choice for the following reasons,

    * I think vertical spacing matters more in the output printed to a
    console.
    * I myself find it odd to add a new line below the branch
    information possibly because I'm too accustomed to it's current
    output.

I tried adding the new line, it seemed to be too spacious. It might be
just me in this case.

> > Further, to me, adding *this* new line
> > before the "Changes not staged for commit" (or something in it's
> > place)
> > seems to be wasting some vertical space ...
> 
> I think it is in line with your original reasoning why you wanted
> these extra blank lines to separate blocks of different kinds of
> information:
> 
>  - "Please do this" instruction at the beginning
>  - Make sure you know the default is --only, not --include
>  - By the way you are committing for that person, not you
>  - This change is being committed on that branch
>  - Here are the changes that are already in the index
>  - Here are the changes that are not in the index
>  - Here are untracked files
> 
> Lack of a blank between the fourth block and the fifth block [*1*]
> makes it somewhat inconsistent, doesn't it?
> 
It does, for the given set of blocks. I didn't find it inconsistent as
I thought the separate blocks as follows,

 - "Please do this" instruction at the beginning
 - Make sure you know the default is --only, not --include
 - By the way you are committing for that person, not you
 - Status of repository (git status)

> [Footnote]
> 
> *1* Yes, we should think about removing the optional second block,
>     as I think that it outlived its usefulness; if we are to do so,
>     these become the third and the fourth blocks.
If I interpreted your previous email correctly, I thought we were doing
it!

I'll send a "typical" patch as a follow-up of this mail.

-- 
Regards,
Kaartic Sivaraam <kaarticsivaraam91196@gmail.com>

  reply	other threads:[~2017-06-28 13:04 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-26 17:24 [PATCH/RFC] commit-template: improve readability of commit template Kaartic Sivaraam
2017-06-26 21:59 ` Junio C Hamano
2017-06-27 17:22   ` Kaartic Sivaraam
2017-06-27 17:56     ` Junio C Hamano
2017-06-28 13:04       ` Kaartic Sivaraam [this message]
2017-06-28 14:50         ` Kaartic Sivaraam
2017-06-28 13:29       ` [PATCH] " Kaartic Sivaraam
2017-06-28 14:47         ` Kaartic Sivaraam
2017-06-28 16:48         ` Junio C Hamano
2017-06-29 17:01           ` [PATCH 1/2] commit-template: remove outdated notice about explicit paths Kaartic Sivaraam
2017-06-29 17:01             ` [PATCH 2/2] commit-template: add new line before status information Kaartic Sivaraam
2017-06-29 17:51               ` Junio C Hamano
2017-06-29 18:17               ` Junio C Hamano
2017-06-30  3:19                 ` Kaartic Sivaraam
2017-06-29 17:56             ` [PATCH 1/2] commit-template: remove outdated notice about explicit paths Junio C Hamano
2017-06-30  3:18               ` Kaartic Sivaraam
2017-06-30 12:12                 ` Kaartic Sivaraam
2017-06-30 12:12                   ` [PATCH 2/2] commit-template: distinguish status information unconditionally Kaartic Sivaraam
2017-06-30 14:52                     ` Junio C Hamano
2017-07-01  1:59                       ` Kaartic Sivaraam
2017-07-01 11:44                         ` Ævar Arnfjörð Bjarmason
2017-07-01 12:08                           ` Kaartic Sivaraam
2017-07-01 17:21                           ` Junio C Hamano
2017-07-09 17:54                   ` [PATCH 1/2] commit-template: remove outdated notice about explicit paths Kaartic Sivaraam
2017-07-09 18:54                     ` Junio C Hamano

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

  List information: http://vger.kernel.org/majordomo-info.html

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

  git send-email \
    --in-reply-to=1498655062.1935.2.camel@gmail.com \
    --to=kaarticsivaraam91196@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).