Carl Worth [off-list ref] writes:
On Tue, 14 Nov 2006 20:47:07 +0100, Petr Baudis wrote:
quoted
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.
On Tue, 14 Nov 2006 16:31:50 -0800, Junio C Hamano wrote:
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.
I think we should fix this. "This is great technology with a crap
interface on top" really isn't a good story. I don't actually agree
with that---I don't think the git interface is really all that bad,
it's just got a few little things that tend to trip up new users in my
experience.
And what git does really well, (history exploring, allowing for
pipeline on-liners to iterate over revisions in A..B), are things that
don't even exist in other tools, nor even in the "alternate"
porcelains for git. This stuff is where git's interface is really
fantastic, and it would be a shame to write it off.
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.
Yes, there are some specific workflow-oriented operations that git
doesn't handle as well as it could. Things like commit --amend are
certainly improvements. One that is still totally broken is "follow
all the development in another repository" where clone followed by
repeated fetch doesn't do the job as soon as the remote adds or
deletes a branch.
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.
I strongly disagree. Or at least, I don't think we've tried hard
enough yet that we should give up on this.
I do agree that people in different roles will have different lists of
"most used operations" and that some operations won't appear on some
users lists at all, (someone who's just "watching" development won't
commit or merge, for example---[or so they thing when they start]).
But I really don't think that for any given operation that different
roles impose a different desire on the behavior of the operation. We
have different people with different background and disagreement on
names and silly things like that, but I don't think that's related to
the roles in which they are working with the tool.
For example, fetching and merging from many places without
necessarily having corresponding tracking branches is a great
...
I don't think we've ever had this right in git. The new
--use-separate-remotes stuff or similar will start to help as it
becomes the default. I don't see how this won't benefit everybody.
For another example, having a commit command to commit
everything by default is disastrous for people who allow their
workflows to often be interrupted.
Workflow-interruption is an important thing to support, but separating
update-index and commit really doesn't address it nearly as much as I
would like. The lack of really good workflow-interruption support has
been one of my longest-running annoyances with git, (perhaps because I
have a problem with trying to do too many things at once). Git can
create and change branches fast enough that it really should be able
to help me better with this. The only missing piece is being able to
stash the dirty stuff on the current branch, to be able to come back
to it later. I've talked a bit about what I would like in this area
before, and I really just need to code it up.
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, ...
Again, I think it's more that the specific operations bring in
concepts, (merge bringing in the index here). As such, someone never
doing a merge could easily get by not having to understand 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.
But even here, there's a bunch of waste in StGit. For example, there
are a lot of commands in StGit whose only purpose is to translate back
and forth between the StGit and non-StGit views of the world, (init,
assimilate, commit, uncommit). Those could all be discarded if the
functionality of StGit were brought down into git itself. Then there
are a myriad of StGit commands which are basically just the same as
their git counterparts.
Now, StGit is a great tool, and I know that it works really well for
some people in the role of just maintaining a stack of changes against
some upstream, and can use StGit alone and never touch "git" the
command-line.
But for someone like me who already uses git regularly, and
occasionally just wants to pop back a few commits, amend it, and then
push again, StGit is not helpful, (the series of init, assimilate, and
uncommits just to get started is prohibitive compared to just working
out the awkward steps needed to make a temporary branch and
rebase). So I'd love to see just a couple of commands added to "git"
to support these kinds of operations more smoothly.
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.
I don't think "hide or not-to-hide" is the right way to frame the
discussion about the index. I regularly use update-index to stage
partial commits, and I find that very useful. And obviously the index
is involved in resolving merge conflicts.
But I don't think the user-interface for either of those operations
(partial commit, resolve conflicts), is ideal, and the current
requirement to use either "update-index <paths>" or "commit -a" after
modifying a file for the first time is demonstrably a hangup for a lot
of new users. So I really think it's possible to address both of these
at once.
Anyone, that's enough generic rambling from me without any specific
content. I'll try to keep future messages focused on specific
desirable operations that have problematic interfaces in git right
now, along with proposals for improving them.
-Carl
On Wed, Nov 15, 2006 at 01:31:50AM CET, Junio C Hamano wrote:
Carl Worth [off-list ref] writes:
quoted
On Tue, 14 Nov 2006 20:47:07 +0100, Petr Baudis wrote:
quoted
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.
..snip passage about workflows..
Controversy's fun, so...
<Cogito maintainer hat _off_> (But yeah, it still looks silly that I'm
saying this.)
From the current perspective, I think it has been a mistake that the
porcelain and plumbing was not kept separate in independent packages,
and perhaps even maintained separately (and perhaps not; at least having
a single tree with plumbing/ and porcelain/ directories and separate
packages in distributions might already help something), so that "git"
would be kept as a kind of library and then there would be a separate
package providing an interface to it. Or you could select one of several
packages. Not only would that make Cogito prevail in the world and bring
me a flood of marriage proposals, but look at how would it help the
general public:
(i) Clearly divided porcelain/plumbing interface, so that you can
really isolate the two UI-wise; endless confusion reigns there now. Is
git-update-index porcelain or plumbing? _You_ call git-merge a proper
porcelain? From my perspective, git-update-ref is as plumbing as it
gets, but it's classified as porcelain. Etc, etc. This would be by far
the most important advantage.
(ii) The plumbing and porcelain would not share the same namespace,
leading to clearer UI. (I'm just inflating (i).)
(iii) The documentation would not be a strange mix of porcelain and
plumbing. (More (i) inflation.)
(iv) (i) is troublesome because I have a feeling that Junio declared
several times that he doesn't care that much about stable API for
porcelain compared to the plumbing. But with the current mix it's
desirable to use some porcelain even in other porcelains and in scripts.
(v) Git would be properly libified by now. If you wanted to convert
bits of porcelain to C, it would be at least much higher priority.
(vi) You wouldn't need to make the gruesome choice on what is the
canonical workflow the _the_ Git porcelain supports (see the snipped
passage). Or you would, but it would have less impact.
(vii) The world would be a happier place.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
On Wed, 15 Nov 2006 17:00:54 -0500, Shawn Pearce wrote:
quoted
There is git-stash/git-unstash floating somewhere in the archive.
Yes, I did write those once upon a time. ;-)
It's the manual stash/unstash that I don't want though. I want to be
able to make this happen automatically when switching branches.
I find that a "git commit -a -m parked; git checkout -b ..." works
well to stash my current stuff off. Then I just amend the commit
when I come back to that branch.
Yes, I do stuff like that as well. And often "reset HEAD~" instead of
amend, (always with a moment's pause as reset justly deserves).
The problem I just ran into today was "git checkout" doesn't double
check the file stat data against the index before switching branches.
If the file is unchanged between the two branches there's no error.
So I switched branches with dirty files that I forgot to park on
the old branch.
Right, so that's just more evidence that this approach is a little
awkward.
Anyway, the stashing thing I want is a minor thing that should be easy
to fix in git, (as is everything we're talking about here I think).
-Carl