On Fri, Sep 06, 2019 at 09:07:15PM +0100, Philip Oakley wrote: > Hi Birger, > > 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 > > message. > > 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 <bert.wesarg@xxxxxxxxxxxxxx> 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 > annoying. > > 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 be wrong...) Correct, you're thinking about the subject line -- it has that multi-line behavior. In git-cola we use a separate LineEdit for the "Commit summary" line, which has improved the commit messages users write and is good because the user doesn't need to worry about the "blank line between subject and body" Git commit message convention. When the user presses "enter" in the subject line it jumps to the "Extended description" TextEdit, so it still "feels" like a single widget. Likewise, up-arrow from the first line of the Extended description also jumps to the summary LineEdit. We also have a "Ctrl-L" global hotkey to jump back to the subject line (same hotkey as Web browsers for the "hot" action of focusing the URL). Using two widgets is a bigger rework for git-gui, but should be considered for future enhancement. We also deal with the "Amend a commit" issue through the word-wrap approach. It's actually a paragraph reflow (not a line-by-line wrap) so adding words is fine and easy and does the natural expected thing -- when amending it'll still feel like a long flow line and when committed it'll wrap with newlines at the configured column. > > 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 ;-). > > > > Thoughts? Those are the same controls git-cola has. - Commit message word-wrap can be turned on/off. Defaults to on. - The line length is configurable. Defaults to 72. Regarding, "the user might get frusted when the resulting commit message looks different" -- I don't think that's really a concern in practice but that might be we have a dedicated LineEdit for the subject line. For git-gui, it seems fine since Git already has conventions about how the subject line gets wrapped, so tools will still see the wrapped subject line as a logical "single line". The "Extended description" commit message editor is WYSWIYG, but if the widget is smaller than the configured value then we still wrap the committed message using the configured value, which is what the user would likely expect even though the visual wrapping is smaller. We also special-case trailers like "Signed-off-by:" and other common trailers since user names can get long, and users sometimes use things like "See-also:" and paste a long URL that we don't want to wrap. Lastly, we have a convenient session-only checkbox to temporarily disable wrapping for a commit that does not persist across restarts. The idea is that sometimes you might use the GUI for a one-off commit where you want to disable the wrapping for whatever reason, but don't want to change your configuration. -- David
