Carl Worth <cworth@cworth.org> writes:

quoted text
> 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.

quoted text
> 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.

quoted text
> 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.


-
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