list mirror (unofficial, one of many)
 help / color / Atom feed
From: Junio C Hamano <>
To: Alban Gruin <>
Cc: Stephen Boyd <>,, Adrian Johnson <>,
	William Duclot <>,
	Johannes Sixt <>,
	Matthieu Moy <>,, Rob Herring <>
Subject: Re: [PATCH] userdiff: Add a builtin pattern for dts files
Date: Mon, 14 Jan 2019 10:34:07 -0800
Message-ID: <> (raw)
In-Reply-To: <>

Alban Gruin <> writes:

> thank you for your patch.  I left a few comments below.
> Le 11/01/2019 à 22:51, Stephen Boyd a écrit:
>> The Linux kernel receives many patches to the devicetree files each
>> release. The hunk header for those patches typically show nothing,
>> making it difficult to figure out what node is being modified without
>> applying the patch or opening the file and seeking to the context. Let's
>> add a builtin 'dts' pattern to git so that users can get better diff
>> output on dts files when they use the diff=dts driver.

A sort of meta-question.

What is missing in the current git that prevents the folks involved
in device-tree project from achieving what this patch tries to
accomplish without having to wait the Git project to act on it?  To
put it another way, is it a symptom of a bad design that from time
to time the Git project has to add built-in patterns?

Ability to ship arbitrary piece of text that you would normally
place in .git/config is not exactly an answer to the above question,
and will not happen as that has grave security implications.

But perhaps we can start accepting an in-tree config-like file whose
contents are limited to verified-safe settings
(e.g. "diff.*.xfuncname" and nothing else), so that projects can
ship two files in-tree:

 - ".gitattributes" that says "*.dts diff=dts"

 - ".gitpreferences" that says "[diff "dts"] xfuncname=..." to
   define the pattern the patch under review adds.

without waiting for the next release of Git to add one more built-in

Anything that defines executable (e.g. "diff.*.command") should
never be accepted as part of the in-tree config-like file (for two
reasons: security and portability), but there should be some
"obviously safe" subset of config settings that we can allow project
to impose on its users, I hope.

  reply index

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-11 21:51 Stephen Boyd
2019-01-13 21:26 ` Alban Gruin
2019-01-14 18:34   ` Junio C Hamano [this message]
2019-01-17 21:26     ` Alban Gruin
2019-01-14 18:34   ` Stephen Boyd
2019-01-17 21:26     ` Alban Gruin
2019-01-17 22:13   ` Rob Herring

Reply instructions:

You may reply publically 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:

* 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 list mirror (unofficial, one of many)

Archives are clonable:
	git clone --mirror
	git clone --mirror http://ou63pmih66umazou.onion/git
	git clone --mirror http://czquwvybam4bgbro.onion/git
	git clone --mirror http://hjrcffqmbrq6wope.onion/git

Newsgroups are available over NNTP:

 note: .onion URLs require Tor:

AGPL code for this site: git clone public-inbox