Re: Two crazy proposals for changing git's diff commands

From: Junio C Hamano <junkio@cox.net>
Date: Feb 10, 2006, 00:13 UTC
Message-ID: <7vr76c5avd.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <87bqxgxfl7.wl%cworth@cworth.org>

Carl Worth <cworth@cworth.org> writes:

Show 16 quoted lines

> So, what I'm trying to work towards is a situtation where those
> workflows are captured through obviously-correlated command
> subsets. This is what I was getting at in the PS. of my previous
> post. For example, the above could be, (ignoring the clash with
> existing core commands), something like:
>
> Index-lover:
>
> 	update-index
> 	diff-index
> 	commit-index
>
> Index-ignorer:
>
> 	diff-files
> 	commit-files

I see where you are coming from and I personally kind of like this consistency. But I am hesitant to declare these two workflows as the _only_ ones officially supported by the tool at this moment. The collective use pattern of git is still young and leaving the door open would help us to evolve more useful workflows around the core in the future. One of our first goals would be to have good set of introductory documentations for best current practices -- if the project you work on fits this workflow, here is a way to do it. With that workflow, there is this way. By that time, hopefully many useless workflows (my "constantly rewinding pu branch" pattern _could_ fall into that category) would be withered away and it would be a good time to streamline the tool around officially supported workflows.

My feeling is that it is a bit premature to do that right now; I do not think we are there yet.

Show 8 quoted lines

> Sure. In that light, try to conceive as my proposed "diff-files" and
> "diff-index" commands as two new highlevel commands. They would be
> useful in day-to-day operation, and most commonly without any need for
> command-line arguments. Those two operations exist today within the
> git-diff wrapper already as "diff HEAD" and "diff --cached HEAD" (or
> "diff --cached). But as described above, I think it would be better to
> put these operations on separate command names, and get them down to
> not requiring any command-line arguments in their common usage.

Sorry, I am not convinced about separate command names, but in the meantime you could have small wrappers around "git diff": "cw-diff-files" and "cw-diff-index" would be one liner each, wouldn't they?

And that is a _good_ thing about git. If the sample set of barebone Porcelains do not fit your needs, you can mix and match using lowlevel commands to quickly script your customized ones. If that is useful in general, that would become one of the best current practices.

> If you compare my above two chunks of example commands, there's nothing
> like a low-level vs. high-level distinction between them. It's more
> about separate command names being uses for different use cases and
> consistent naming used to group related commands within a use case.

I think that is where we differ. I think even for index-lover "diff HEAD" is useful in certain cases (obviously index-ignorer would not see much useful output from "diff --cached", though). In fact, I fall into "index-lover" camp but I use both depending on occasion. And as I said, I do not think "index-lover" and "index-ignorer" distinction above would be the only two valid workflows anyway, so I feel partitioning the command set along those lines is at least premature if not wrong.