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 20:20:50 +0530 [thread overview]
Message-ID: <1498661450.10011.3.camel@gmail.com> (raw)
In-Reply-To: <1498655062.1935.2.camel@gmail.com>
I might have been ignorant about something about git in my reply in the
previous email (found below). In that case, please enlighten me.
On Wed, 2017-06-28 at 18:34 +0530, Kaartic Sivaraam wrote:
> 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.
>
next prev parent reply other threads:[~2017-06-28 14:50 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
2017-06-28 14:50 ` Kaartic Sivaraam [this message]
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=1498661450.10011.3.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).