From: Philip Oakley <firstname.lastname@example.org>
To: Birger Skogeng Pedersen <email@example.com>,
Bert Wesarg <firstname.lastname@example.org>
Cc: Git List <email@example.com>, Pratyush Yadav <firstname.lastname@example.org>
Subject: Re: [PATCH 1/2] git-gui: warn if the commit message contains lines longer than the set limit
Date: Fri, 6 Sep 2019 21:07:15 +0100 [thread overview]
Message-ID: <email@example.com> (raw)
On 06/09/2019 15:08, Birger Skogeng Pedersen wrote:
> Hi Bert,
> We should probably distinguish between what is wrapped in git-gui
> (i.e. purely visual), and what is actually wrapped in the commit
> I believe the former is referred to as "soft wrap", while the latter
> is "hard wrap".
> On Thu, Sep 5, 2019 at 7:46 PM Bert Wesarg <firstname.lastname@example.org> wrote:
>> Please exclude the first line, i.e., the subject. This should not be
>> wrapped at all.
> I think all lines should be soft wrapped. Scrolling sideways is just
> not something I'd want to do in the gui.
> How about we soft wrap all lines (in gui). But when the commit is
> created, the actual hard wrap (newline characters) happens only on
> lines other than the first one?
Not sure if I parsed this correctly, but I'd want a WYSIWYG approach
that if we wrap on the display it will be wrapped (newline char) in the
commit. It sounded as if you were proposing a soft wrap visually, but
not doing the same for the commit.
Personally, I've had both feelings with the gui. I like that the 'hard'
visual char limit is there that encourages me to wrap my messages.
But at the same time if I'm typing on a flow then it's annoying that
there wasn't any auto wrap.
The other problem is if one is amending a commit and I need to add a few
word mid paragraph, the manual re-flowing and manual wrapping can be
I suspect there is a moderately happy medium between the two, perhaps
with an autowrap key (per paragraph) being available.
I also had it in my head that some parts of Git do allow more than a
single line headers, or at least can cope with a run-on second line
before the blank line that flags the start of the message proper. (I may
> But then again, the user might get frustrated when the resulting
> commit message looks different than what it appeared in git-gui.
> Honestly I'd prefer just wrap the first line as well. If the user gets
> frustrated that the first line gets wrapped there are two options:
> - Refrain from writing such a long line
> - Disable word wrapping (it should be configurable, like you said)
Configurable wrapping point - yes, would be nice (a feeling of control,
that I'd probably never change ;-).
next prev parent reply other threads:[~2019-09-06 20:07 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-04 20:10 [PATCH 1/2] git-gui: warn if the commit message contains lines longer than the set limit Bert Wesarg
2019-09-04 20:10 ` [PATCH 2/2] git-gui: add horizontal scrollbar to commit buffer Bert Wesarg
2019-09-04 20:31 ` Eric Sunshine
2019-09-04 20:46 ` Bert Wesarg
2019-09-10 20:28 ` Pratyush Yadav
2019-09-12 19:10 ` Bert Wesarg
2019-09-04 20:29 ` [PATCH 1/2] git-gui: warn if the commit message contains lines longer than the set limit Eric Sunshine
2019-09-04 20:43 ` Bert Wesarg
2019-09-04 22:48 ` Pratyush Yadav
2019-09-05 6:48 ` Birger Skogeng Pedersen
2019-09-05 17:46 ` Bert Wesarg
2019-09-06 14:08 ` Birger Skogeng Pedersen
2019-09-06 20:07 ` Philip Oakley [this message]
2019-09-10 8:04 ` David Aguilar
2019-09-10 19:42 ` Pratyush Yadav
2019-09-05 6:21 ` Johannes Sixt
2019-09-05 17:43 ` Bert Wesarg
2019-09-10 16:50 ` Johannes Sixt
2019-09-12 19:26 ` Bert Wesarg
2019-09-10 20:34 ` Pratyush Yadav
2019-09-12 19:13 ` Bert Wesarg
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:
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 \
* 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
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).