git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Jacob Keller <jacob.keller@gmail.com>
Cc: Stefan Beller <sbeller@google.com>,
	Jacob Keller <jacob.e.keller@intel.com>,
	"git\@vger.kernel.org" <git@vger.kernel.org>,
	Jeff King <peff@peff.net>, Jens Lehmann <Jens.Lehmann@web.de>,
	Davide Libenzi <davidel@xmailserver.org>
Subject: Re: [RFC PATCH, WAS: "weird diff output?" 2/2] xdiff: implement empty line chunk heuristic
Date: Fri, 15 Apr 2016 14:44:51 -0700	[thread overview]
Message-ID: <xmqqzisu8s30.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <CA+P7+xp7oJoOXBhexe9zhrG1dMkz8jA3yQLzyTiqMwNQ1AQVdg@mail.gmail.com> (Jacob Keller's message of "Fri, 15 Apr 2016 14:22:48 -0700")

Jacob Keller <jacob.keller@gmail.com> writes:

>>> What you have is a pure developer support; aim to come up with "good
>>> enough" way, giving developers an easier way to experiment with, and
>>> remove it before the feature is shipped to the end user.
>
> What are your thoughts on adding this do the gitattributes diff
> section? Ie: modifications to the diff driver.

I do try to foresee the future needs but I try to limit the forecast
to "just enough so that we won't waste engineering effort on a wrong
thing".  "It may need to be turned off conditionally" suggests we
would want attributes added per path, and that is sufficient to make
me say "don't waste time on bikeshedding configuration variable
names, it will not be in the final product".

We do not need yet to know what the final name of the attributes
are, or how exactly the bit to affect the low level mechanism will
be set by the attribute mechanism.  I do not think this topic is
there yet, and it is a waste of engineering effort to prematurely
trying to make things too flexible and customizable, when the thing
that will eventually become flexible by conditionally enabled is not
even there yet.

As long as the low-level thing has a knob, set of internal bits, to
enable and disable it, that is all that is necessary to know at this
point.

Having said all that, I'd expect we'd compute the right bit to use
in the same place where we currently pick the custom textconv
driver, diff backend, etc., by consulting the attribute system
before running the diff.

But again, I'd think it would be waste of time to think beyond that
at this point, identifying exactly at which line of which source
file the new code would go and what that new code would look like,
until we are ready to start integrating it.

  reply	other threads:[~2016-04-15 21:45 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-15 16:51 [RFC PATCH, WAS: "weird diff output?" 0/2] implement better chunk heuristics Jacob Keller
2016-04-15 16:51 ` [RFC PATCH, WAS: "weird diff output?" 1/2] xdiff: add xdl_hash_and_recmatch helper function Jacob Keller
2016-04-15 17:25   ` Junio C Hamano
2016-04-15 19:09     ` Jacob Keller
2016-04-15 16:51 ` [RFC PATCH, WAS: "weird diff output?" 2/2] xdiff: implement empty line chunk heuristic Jacob Keller
2016-04-15 19:57   ` Stefan Beller
2016-04-15 20:06     ` Junio C Hamano
2016-04-15 20:17       ` Jacob Keller
2016-04-15 20:30         ` Junio C Hamano
2016-04-15 21:15           ` Jacob Keller
2016-04-15 21:22             ` Jacob Keller
2016-04-15 21:44               ` Junio C Hamano [this message]
2016-04-15 21:56                 ` Jacob Keller
2016-04-15 20:06     ` Jacob Keller
2016-04-15 17:02 ` [RFC PATCH, WAS: "weird diff output?" 0/2] implement better chunk heuristics Stefan Beller
2016-04-15 17:10   ` Stefan Beller
2016-04-15 17:27     ` Junio C Hamano
2016-04-15 17:33       ` Stefan Beller
2016-04-15 17:48         ` Junio C Hamano
2016-04-15 19:09         ` Jacob Keller
2016-04-15 19:08     ` Jacob Keller
2016-04-15 19:07   ` Jacob Keller

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=xmqqzisu8s30.fsf@gitster.mtv.corp.google.com \
    --to=gitster@pobox.com \
    --cc=Jens.Lehmann@web.de \
    --cc=davidel@xmailserver.org \
    --cc=git@vger.kernel.org \
    --cc=jacob.e.keller@intel.com \
    --cc=jacob.keller@gmail.com \
    --cc=peff@peff.net \
    --cc=sbeller@google.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).