Carl Worth <cworth@xxxxxxxxxx> writes:
> On Tue, 14 Nov 2006 20:47:07 +0100, Petr Baudis wrote:
>> Hmm, did they (not) consider Cogito? They wouldn't have those issues.
>
> I didn't ask.
>
> Frankly, I don't see a lot of value in the git/cogito split right now.
> ...
> It's great that git is written in a script-friendly way so that new
> interfaces can be built on top of it. And I think the benefits of new
> user interfaces are clear when they work in fundamentally different
> ways, (say, being operated through a GUI). But where git and cogito
> are both command-line utilities and have the same basic functionality,
> ...
> There are some things that cogito does that git does not that I would
> like to have in git.
> ...
> I don't see any defining difference that justifies cogito's
> existence ("hide the index" maybe? let's just hide it a tiny bit more
> in git). And I would like to help work to get the remaining good
> stuff that has been proven in cogito---to get it pushed down into git
> itself.
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.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html