Carl Worth <cworth@xxxxxxxxxx> writes: > On Tue, 14 Nov 2006 15:52:47 -0500 (EST), Nicolas Pitre wrote: >> Even if I have a clear preference for GIT's _technology_, I still think >> that the HG user interface is more convivial. I even been thinking >> about writing something like an hg-like frontend to GIT from time to >> time just so that GIT could then be better compared to (and actually >> just used like) HG. > > I've actually been tempted to do the same myself. I really think that > the technology is a more important criterion than the UI so the > imagined hg-on-git interface would be an attempt to get people to look > past the interface differences and look at the technology when > deciding. >... >> I still think that the GIT user interface sucks in many ways. The >... I've actually been tempted to do that too, and my earlier "if I were to redo git from scratch" message was the beginning of it to summarize my preference about some of the issues raised in this thread. Commenting on the messages in this thread: - "resolve / resolved" are both confusing, when you are talking about "mark-resolved" operation. - "pull/push/fetch" have undesired confusion depending on where people learned the term. I'd perhaps vote for replacing fetch with download and push with upload. - I think it would be sensible to make remote tracking branches less visible. For example: git diff origin where origin is the shorthand for your upstream (e.g. you have .git/remotes/origin that records the URL and the branch you are tracking) should be easier to understand than git diff remotes/origin/HEAD The latter is an implementation detail. I could imagine we might even want to allow git diff origin#next to name the branch of the remote repository. The notion of "where the tips of remote repository's branches are" is probably be updated by "git download" (in other words, the above "git diff" does not automatically initiate network transfer). - "git merge" to merge another branch into the current would make sense. "git pull . remotes/origin/next" is showing too much implementation detail. It should just be: git merge origin#next And I agree with Pasky that fixing UI is hard unless you are willing to get rid of historical warts. Syntax of the command line arguments the current set of Porcelain-ish takes are sometimes just horrible. It may not be a bad idea to start building the fixed UI from scratch, using different prefix than "git" (say "gu" that stands for "git UI" or "gh" that stands for "git for humans"). Of course, it could even be "cg" ;-). - 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