Re: is there a reason pre-commit.sample uses "git diff-index"?
On Thu, May 31, 2018 at 4:09 PM, Robert P. J. Day <rpjday@crashcourse.ca> wrote:
Show 30 quoted lines
> On Fri, 1 Jun 2018, Johannes Sixt wrote:
>
>> Am 31.05.2018 um 19:27 schrieb Robert P. J. Day:
>> > On Thu, 31 May 2018, Duy Nguyen wrote:
>> >> git diff-index is "plumbing", designed for writing scripts. "git
>> >> diff" on the other hand is for users and its behavior may change
>> >> even if it breaks backward compatibility.
>> >
>> > ah, this was a philosophical underpinning i was unaware of. i
>> > see occasional explanations of git porcelain versus plumbing, but
>> > i don't recall anyone simply stating that the plumbing is meant to
>> > have a long-term stability that is not guaranteed for the
>> > porcelain.
>>
>> So, there you have it. ;) Plumbing commands offer long-term
>> stability. That is not just philosophical, but practically relevant.
>>
>> > in any event, this does mean that, stability issues aside, "git
>> > diff" would apparently have worked just fine for that hook.
>>
>> It may have worked just fine. You should still not use it.
>>
>> Didn't you say that you are teaching git and hooks? Then you should
>> teach the right thing, and the right thing is to use plumbing for
>> scripts.
>
> sure, i agree, but i don't recall *ever* running across the claim
> that the "plumbing" commands had a long-term stability and backward
> compatibility that the porcelain commands did not. is that mentioned
> anywhere?
`man git`
LOW-LEVEL COMMANDS (PLUMBING)
Although Git includes its own porcelain layer, its low-level commands
are sufficient to support development of alternative porcelains.
Developers of such porcelains might start by reading about git-update-
index(1) and git-read-tree(1). The interface (input, output, set of options and the semantics) to
these low-level commands are meant to be a lot more stable than
Porcelain level commands, because these commands are primarily for
scripted use. The interface to Porcelain commands on the other hand are
subject to change in order to improve the end user experience.One example that Junio seemed to worry about was 940a911f8ec (log: if --decorate is not given, default to --decorate=auto, 2017-03-23), as git log seems to be used pseudo-plumbing-ly as there is no good and equally powerful plumbing command, so the likelihood of git-log calls in scripts out there is high.
So maybe the community should strive to be more aggressive about changing the porcelain interface for the better.
One thing that we discussed internally for example is changing the output of the porcelain output of fetch, pull and push to give less cryptic output, but rather a one line progress bar (and only show errors when they occur). I think that would be an improvement, as I don't think many people care about the exact numbers of objects transferred in a push/fetch, but rather want to have an estimate of the time left for example. Also a one line progress bar might save some precious screen real estate.
Stefan
Robert P. J. Day
