Re: Cleaning up git user-interface warts

On Tue, Nov 14, 2006 at 11:36:19PM CET, Junio C Hamano wrote:

Well that's what "resolved" is saying. But speaking of which, it took me _weeks_ of regular (though not extensive) usage to train my fingers to write "stg resolved" and not "stg resolve".

It's too long. :-(

I think if some people have a real problem with something it's "pull", not push or fetch. Without "pull" name, there's no confusion about merging or not merging; and without it, there's also no confusion about "push" and the fetch/push duality. I'm not saying that this is enough an argument to ditch pull from Git at this point.

Hmm, wait. I didn't start using refs/remotes/ yet for obvious reasons, but wasn't it generally agreed when implementing them that what you wrote above would work? (That a ref not found in refs/{heads,tags}/ is looked up in remotes and if it's a directory, /HEAD is appended.) So it doesn't for some reason?

Yes, that little syntax extension would be cute to have.

So, here is an arbitrary list of random reasons why cg commands are not part of git yet:

(i) Naming issues. Example: "pull" vs. "update".

(ii) Namespace issues. Big selling point of Cogito is that it's _simple_. A very important part of that is that your command set is limited, so that even someone who wants to fully grok Cogito is not overwhelmed and has just few commands in front of him. I think we're doing pretty good here, and I very carefully weight adding another command to the set (I'm actually pondering removing some now). The similar applies to actual commands' usage, though certainly not so heavily; and there are few warts here.

But overally, I think this point is pretty much unsolvable and this is where I actually think the main "incompatibleness" of Cogito and Git with its free mix of high- and mid- and low- level commands lies. I don't think the thread provided any solution to this either.

(ii) Behaviour issues. Example: Cogito tries to deal with uncommitted local changes in your repository when doing stuff. It didn't shine at it before recent improvements (post-v0.18), but it tried to preserve your local uncommitted changes during various operations (merging, fast-forwarding, switching branches, seeking, ...). I think historically Git's stance to this was negative (it'd rather block the operation), I'm not sure what the current situation is, though.

(iii) Output format issues. Example: "status" in Git and Cogito has a completely different format in both. I'm a die-hard fan of Cogito's format but there're surely die-hard fans of Git's.

(iv) Control issues. I'm reluctant to give up a final word on how the UI looks like, mostly for the reason of enforcing (ii) and proper documentation. But this is not a blocker point.

(v) Library issues. Cogito has a pretty neat shell library which it prices; but that could be carried around. Also, Cogito requires /bin/bash, but mostly for performance reasons (using builtins instead of forking for external commands at some points); Git has the advantage of simply putting that part in C, which is though something I should've been doing more frequently too.

(vi) Coding issues. This is probably very subjective, but a blocker for me. I have no issues about C here, but about the shell part of Git. Well, how to say it... It's just fundamentally incompatible with me. I *could* do things in/with it, but it's certainly something I wouldn't _enjoy_ doing _at all_, on a deep level. I think the current shell code is really hard to read, the ancient constructs are frequently strange at best, etc. It's surely fine code at functional level and there'll be people who hate _my_ style of coding and my shell code which isn't perfect either, but it's just how it is with me.

Now, it would be absolutely awesome if we could start to bridge at least some of these points, shuffle some functionality around and overally reduce the code duplication, increase features count and improve general level of world happiness.