"Govind Salinas" <blix@xxxxxxxxxxxxxxxxx> writes: > One of the things that has been commented on by almost any review of > git are the large numbers of commands that are present and the > endless stream of flags, options, configuration variables and > syntaxes that are present in git. They certainly serve a purpose > and I probably would not be able to do this without all those things > but it can get in a normal users way some times. Here are some of > the steps I have and will be taking. Which is bogus, because most of those commands are plumbing, [almost] never to be used by user directly. If I understand correctly in next major git release those commands are to be hidden and not present in PATH anymore. > 1) Reduce the number of commands. > > I am currently at 30 total commands, and while I have some more to go, I > think there are some ways that I can get rid of some of them by > combining them. Do we really need a clone, branch and checkout? Don't > these all mean the same thing in the end? They mean get me a working > directory of the repository starting at X. For clone, you start > with 'master'. For checkout, you tell it what to get you. Branch > will help you manage things you can locally get. So perhaps we can > do something like the following... Note that you sometimes want to make a branch without checking it out. Also note that git-branch is overloaded to get a list of branches available. > Clone a new repo > pyt checkout http://foo.com/bar/baz.git mybaz > > It's a URL, I know that I can clone that and I know I am not inside > a repository. > > Fetch > pyt co <url> # or remote:origin > > It's a URL, but I am inside the repo, I should tell the user that > they are about to fetch something. Not necessary, you might have wanted to have repository inside repository, either managed using submodules, or ignored, etc. > Pull > pyt co -m remote:origin:branch > > Pull is just fetch/merge anyway -m tells it to merge, perhaps a flag -u > to do it all in one step. > > Merge > pyt co -m localbranchhead > > Checkout a branch > pyt co localbranchead # or remote:origin:branch, tag:tagname etc > > Create/switch to new local branch (this should look familiar) > pyt co -c <newbranch> -b <base> > > The list goes on. Note also that if you make all those unrelated (at least a bit) things into one command you would lose some of error detection. For example you want to clone, but due to typo and DWIM-mery of "pyt co" command it would silently fetch/merge/branch/whatever. Not good... Note also that another complaint is that git commands do many fairly independent things... and you would want to escalate it even further... > 2) Reduce complexity. > > This one is easy, not because there are commands in git that don't > have a use, but because we can usually spell stuff in a simpler way. > Take for example master@{100}. If I see someone on the list use that > on I might expect that that is master 100 commits ago, rather than what > HEAD was pointing at 100 operations ago. Errr... master 100 commits ago (in first-parent line) is master~100. And that it is not where HEAD was (indirectly or directly) pointing, but where 'master' ref was pointing. The ref@{n} notation is very, very useful when you want to correct mistakes such as errorneous rewind ("git reset --hard HEAD^" for example), or botched rebase, or to view pre-rebase version to compare, etc. > Furthermore, if I have just > cloned, that won't work because I have no reflog. So what if we > spelled that reflog:100:master? Well now at least I know that I > am dealing with the reflog. Perhaps a more refined spelling could > give the user more information. > > Take ":/message" I didn't even know that existed until I was looking > for nifty things to spell, but wouldn't "subject:my subject" work just > as well? Thats a little friendlier. > > How about not using the ".." and "..." since it can be surprising to > users what they actually do without understanding how git works. > Perhaps something like --revision-start (-r) and --revision-end(-R) > would help them out. Add a --symmetric or something for "...". You don't need two options; first -r is start, second -r is end... > You get the idea. True, the fact that revisions are non-option parameters, and that pathspecs are also non-option parameters might be a bit confusing to newbie. On the other hand the a..b and a...b notation is matter of convenience (it is easier to use than "b ^a" or "a b --not $(git merge-base a b)"); perhaps allowing a..b and a...b notation for git-diff was an error... but it makes copy'n'paste easier... > 3) Addons. > > Some functionality isn't for everyone. I have just put into my > next branch an addon that gives git revision numbers. Why, because > other SCMs that are supposed to be more user friendly have them. > Because people have been asking for them. Because they are easier > to remember. Because people does not understand the concept and constraints of distributed version control system (with implied multiple branches and nonlinear history). Revision numbers cannot be all of: decentralized, global, unchanging, encompassing. (Decentralized means no single authority assigning numbers, and no repositories which are special in any case for example using merge/pull with different options than other repositories. Global means that all repositories have the same numbers for the same revisions; the opposite is local, that numbers are relevant only in your local repository (and you cannot say: in revision 'n' to someone else). Unchanging means that revsision numbers don't change on pull for example. Encompassing means that all revisions are given number.) > 4) GUI. > > I have a GUI in mind, I haven't had time to work on it, but I have > started it and the idea is that it should be able to completely > replace the command line. Why? because some people hate command lines > and more importantly, because I want a GUI that will look like it > fits into my Gnome desktop and looks decent on my Windows machine > (which I use because I have to). Have you checked existing git GUIs, both history viewers and commit tools? Gitk, git-gui, QGit, Giggle, ugit, tig,... > 5) One stop shop. > > I tried setting up Apache, lighttpd etc on Windows to do some ad-hoc > serving of a git repo. I was painful. I want my webserver, gui, > command line, diff tool, merge tool to all come in one package. And > I DON'T want it to need a cygwin or msys installation to work. > > That just makes life easier. And I am all about the not expending > effort. Perhaps we could just get more examples in gitweb/README and perhaps in user's manual. BTW. there always is git-instaweb. But having git-serve would be nice... -- Jakub Narebski Poland ShadeHawk on #git -- 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
