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
Attachment:
pgpXT1RVMrNzr.pgp
Description: PGP signature