Re: Cleaning up git user-interface warts

Carl Worth <cworth@cworth.org> writes:

I am of two minds here.

I do not think the Porcelain-ish UI that is shipped with git should be taken with the same degree of "authority" as git Plumbing. The plumbing needed to have something that worked for one particular workflow (namely, workflow of the people in the integrator role of kernel-style project) and that is where the current set of Porcelain-ish originates. Linus works primarily as an integrator so the toolsets he did tend to be more pleasant to use for integrators and less so for contributors. I started as a contributor and added some commands like format-patch and rebase that Linus never would have felt the need for. I think single isolated developers, contributors and CVS style shared repository usage could be a lot improved because neither of us were concentrating in their workflows. This needs somebody motivated enough to improve things in that area. For example, StGIT with its 'float' command is a great improvement over what rebase does for people in the contributor role.

By now, perhaps git may be good enough for the kernel folks, even for those not in the integrator role, but I have no doubt that they have many dislikes to the way some commands work. They and X.org folks are using git primarily because Linus and Keith forced them to ;-), and being interoperable is more important than having to tolerate sucky UI here and there. Everybody knows that git Porcelain-ish sucks, and making it more usable is a worthy goal.

But making it more usable for whom is a big question.  

Quite frankly, I do not think there can be _the_ single UI that would satisfy different types of workflows for some of the commands. The commands related to software archaeology, in which my main interest and strength lie, would easily be usable across workflows, but commands to build commits locally and propagate them to and from other repositories would be affected by the workflow.

For example, fetching and merging from many places without necessarily having corresponding tracking branches is a great thing for people in the integrator role. On the other hand, for people doing CVS-style centralized repository interaction, it is often more useful to have tracking branches. You could support both but it has been painful.

For another example, having a commit command to commit everything by default is disastrous for people who allow their workflows to often be interrupted. When I respond to a message from the list with an example patch, my repository is often in the middle of doing something completely unrelated, and I edit and make diff to send the message out and I do not necessarily revert that change afterwards immediately. For more organized people it may not be a problem so you either support both types of workflows or do a specialized toolset.

It is not just command line syntax and the defaults, but concepts as well. People in the integrator role often need to deal with merges and you would need to be aware of the role of the index and need to be able to manipulate the index, a lot more often than people in the contributor role. To satisify both kinds of workflows, you would either have switches, or do a specialized toolset, like Cogito, that tries to hide the index.

A Porcelain that does a very similar thing in slightly different way is obviously a waste, but otherwise I do not think it is a problem to have different Porcelains. StGIT does not compete with the "sucky" Porcelain-ish shipped with git but makes the user's life a lot more pleasant by complementing what the sucky one does not do well. It is not very useful while I am playing the integrator role, but when I am doing my own thing it is a great addition to my toolchest.

I am from the camp that does _not_ want to hide the index, so obviously I do not see any value in its effort to hide the index. But other aspects of it, most notably being friendly to simpler workflows, is a very good thing.