All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, "Beat Bolli" <dev+git@drbeat.li>,
	"Jeff King" <peff@peff.net>,
	"Eric Sunshine" <sunshine@sunshineco.com>,
	"Torsten Bögershausen" <tboegi@web.de>
Subject: Re: [PATCH v4 1/2] merge-file: let conflict markers match end-of-line style of the context
Date: Thu, 28 Jan 2016 08:55:21 +0100 (CET)	[thread overview]
Message-ID: <alpine.DEB.2.20.1601280851470.2964@virtualbox> (raw)
In-Reply-To: <xmqq8u3a95st.fsf@gitster.mtv.corp.google.com>

Hi Junio,

On Wed, 27 Jan 2016, Junio C Hamano wrote:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> [administrivia: I finally managed to correct e-mail address of peff@,
> which has been giving me bounces for all the previous messages in
> the thread]

Oops! I got those bounces myself, but wrote them off to Eric's account
without checking (because I consistently had problems sending emails to
him in the past). Sorry about that.

> > Your response is also an indicator to me that future myself will find the
> > same code just as confusing as you did, though.
> >
> > Maybe need_cr -> eol_is_crlf?
> 
> The crucial question is how well the variable conveys its meaning
> when it has -1 as its value.  "need_cr? -- I don't know yet" is as
> clear as "eol_is_crlf? -- I don't know yet", if not clearer.  I
> personally do not think "eol_is_crlf" is an improvement.

Okay, then. Let's keep the "needs_cr" name.

Ciao,
Dscho
> it unclear _whose_ eol the variable is talking about.  It can be
> misread as talking about one or more of the files that are being
> merged and mistaken as a statement of a fact (i.e. "we inspected
> and know the input file's eol is CRLF").
> 
> Compared to that, it is clear that "need_cr" is talking about what
> the EOL convention the resulting file should be.
> 
> I briefly wondered if the if/if (need_cr)/... cascade that inspects
> (conditionally up to) three variants might become cleaner if the
> polarity of that variable is flipped (we are allowed to use CRLF
> only when we know that among all of the three variants that we can
> determine the line termination convention used, all of them use
> CRLF), but I didn't think it through seriously.
> 
> 
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

  reply	other threads:[~2016-01-28  7:56 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-22 17:01 [PATCH 0/2] Let merge-file write out conflict markers with correct EOLs Johannes Schindelin
2016-01-22 17:01 ` [PATCH 1/2] convert: add a helper to determine the correct EOL for a given path Johannes Schindelin
2016-01-22 18:47   ` Junio C Hamano
2016-01-22 19:04     ` Johannes Schindelin
2016-01-23  7:05       ` Torsten Bögershausen
2016-01-24 10:42       ` Johannes Schindelin
2016-01-23  6:12   ` Torsten Bögershausen
2016-01-24 10:41     ` Johannes Schindelin
2016-01-22 17:01 ` [PATCH 2/2] merge-file: consider core.crlf when writing merge markers Johannes Schindelin
2016-01-22 18:15   ` Junio C Hamano
2016-01-22 18:47     ` Johannes Schindelin
2016-01-22 19:08       ` Junio C Hamano
2016-01-24 10:44         ` Johannes Schindelin
2016-01-22 19:50   ` Eric Sunshine
2016-01-22 19:52     ` Eric Sunshine
2016-01-24 10:37       ` Johannes Schindelin
2016-01-24 18:26         ` Eric Sunshine
2016-01-25  7:02           ` Johannes Schindelin
2016-01-23  6:31   ` Torsten Bögershausen
2016-01-24 10:39     ` Johannes Schindelin
2016-01-22 17:52 ` [PATCH 0/2] Let merge-file write out conflict markers with correct EOLs Beat Bolli
2016-01-24 10:48 ` [PATCH v2 0/1] " Johannes Schindelin
2016-01-24 10:48   ` [PATCH v2 1/1] merge-file: let conflict markers match end-of-line style of the context Johannes Schindelin
2016-01-24 16:27     ` Torsten Bögershausen
2016-01-24 16:36       ` Torsten Bögershausen
2016-01-25  6:53       ` Johannes Schindelin
2016-01-25 19:45         ` Ramsay Jones
2016-01-26  8:54           ` Johannes Schindelin
2016-01-26 16:43             ` Ramsay Jones
2016-01-26 16:49               ` Johannes Schindelin
2016-01-24 22:09   ` [PATCH v2 0/1] Let merge-file write out conflict markers with correct EOLs Junio C Hamano
2016-01-25  7:25     ` Johannes Schindelin
2016-01-25  8:06   ` [PATCH v3 0/2] " Johannes Schindelin
2016-01-25  8:07     ` [PATCH v3 1/2] merge-file: let conflict markers match end-of-line style of the context Johannes Schindelin
2016-01-25  8:32       ` Torsten Bögershausen
2016-01-25  8:59         ` Johannes Schindelin
2016-01-25 20:12       ` Junio C Hamano
2016-01-26  9:04         ` Johannes Schindelin
2016-01-26 17:22           ` Junio C Hamano
2016-01-25  8:07     ` [PATCH v3 2/2] merge-file: ensure that conflict sections match eol style Johannes Schindelin
2016-01-25  9:20       ` Johannes Schindelin
2016-01-26 14:42     ` [PATCH v4 0/2] Let merge-file write out conflict markers with correct EOLs Johannes Schindelin
2016-01-26 14:42       ` [PATCH v4 1/2] merge-file: let conflict markers match end-of-line style of the context Johannes Schindelin
2016-01-26 18:23         ` Junio C Hamano
2016-01-26 21:14           ` Junio C Hamano
2016-01-27  7:58             ` Johannes Schindelin
2016-01-27 18:19               ` Junio C Hamano
2016-01-27 19:12                 ` Johannes Schindelin
2016-01-27 19:32                   ` Junio C Hamano
2016-01-28  7:55                     ` Johannes Schindelin [this message]
2016-01-26 14:42       ` [PATCH v4 2/2] merge-file: ensure that conflict sections match eol style Johannes Schindelin
2016-01-27 16:37       ` [PATCH v5 0/2] Let merge-file write out conflict markers with correct EOLs Johannes Schindelin
2016-01-27 16:37         ` [PATCH v5 1/2] merge-file: let conflict markers match end-of-line style of the context Johannes Schindelin
2016-01-27 16:37         ` [PATCH v5 2/2] merge-file: ensure that conflict sections match eol style Johannes Schindelin
2016-01-27 20:22         ` [PATCH v5 0/2] Let merge-file write out conflict markers with correct EOLs 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

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

  git send-email \
    --in-reply-to=alpine.DEB.2.20.1601280851470.2964@virtualbox \
    --to=johannes.schindelin@gmx.de \
    --cc=dev+git@drbeat.li \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=peff@peff.net \
    --cc=sunshine@sunshineco.com \
    --cc=tboegi@web.de \
    /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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.