On Sat, 24 May 2008, Govind Salinas wrote: > On Sat, May 24, 2008 at 3:41 AM, Jakub Narebski wrote: >> "Govind Salinas" <blix@xxxxxxxxxxxxxxxxx> writes: >>>>> 1) Reduce the number of commands. >> [...] >> I think you should start not with "minimal number of commands" as a >> goal, but rather with set of distinct tasks ordinary (not scripting) >> user might need, and how to map them into commands. >> >> To heavily overloaded commands are as much if not worse than having >> too many commands to choose from. > > This is true. This idea is fairly new and I am still deciding exactly > how things would get broken up. After thinking about it, "checkout" > probably should not be combined with the fetch/pull/merge command > because they are too different. Here is how I am thinking of > combining things, perhaps you and others can give some pointers on > what is crazy and what might work. > > The ones prefixed with * are the ones that would show up in the short > help, the ones that would be the most typically used. > > bisect = bisect > blame = blame > * commit = commit + push + stash + init > push: This is here because it fits the traditional notion > of what a commit does, which is to send a commit to the > central server. I think of it as "I am committing my > changes to the remote repository. That I'm not sure about. One of advantages of _distributed_ SCM is separation of the act of committing (saving state to repository) and publishing (making those changes public, which stops changing history). So I'd rather left commit and push separate, although I can agree that local / public commit would be not so bad alternate interface. > stash: What is stash but a temporary commit (not on the > branch)? I think that is (might be) a good idea, _BUT_ with the caveat that after stash working repository is in state _before_ changes. But that might work. > init: This can be done a couple of ways, either your initial > commit is combined with the init or --init is a flag > passed to commit to set up the NULL commit. At > least thats how I think of it conceptually. Bad, bad idea. First, init is _very_ separate thing from commit. Second, you would lose I think much of error detection. And last, sometimes yoy initialize repository (usually bare repository) to propagate changes not using commit (local commit), but using push (remote commit). > * checkout = checkout + clone + branch + remote No. 'clone' = 'init' + 'remote', or 'clone' ~= 'import'. Overloading 'checkout' to do all the work of 'branch' is IMHO not a good idea. Here it looks like you want to cram too much into single command. You have fewer commands, but only superficially; you have actually have them, but disguised as options and special cases and DWIM-mery. > * config = config > cherry = cherry + cherry-pick Errr... cherry has nothing to do with cherry-pick. I'd think that cherry could be an option to git-log instead, and cherry-pick be joined with revert. > * diff = diff > gc = clean + gc + prune + repack > I plan to make full use of gc --auto to avoid having the > user run this command, but everyone knows there > are reasons to run these commands even with --auto. git-gc already is meant to be porcelain for prune and repack, so you should need run only this command. > "Clean" seems to me to be the working directory version > of gc. git-clean is potentially dangerous. It is _not_ garbage collecting. Besides "git-clean" apes "make clean"... actually this (the possibility of mistake) migh be a good argument for making git-clean to be special case of git-gc. > * gui = gui > * help = help > import = apply + cvsimport + <scm>import + am > Here the import strategies would be provided by addons > and such with apply/am as standard. It is one on wishlist from some time to be able to fetch / clone from other SCMs just by providing URL to foreign SCM, i.e. unified foreign SCM import and foreign SCM interaction support. > mail = format-patch + send-mail I'm not that sure. Perhaps. Or perhaps format-patch should be special case of git-log (or option to git-log). > move = move > * pull = pull, fetch, merge Merge is separate from pull because it is inherently local. Pull might get data from remote repository. And I guess it would play merry hell with remotes (shortcuts for remote repositories URLs and refspecs), and remote branches names. > rebase = rebase > remove = remove > * resolve = mergetool > revert = reset + reflog > I was thinking of calling this command "recover" instead of > revert, which I still think might describe what I want to do > and might tell you why I think that reflog is something to > combine here. "revert --what-can-i-revert-to" would show > the output of reflog. That wouldn't be the actual name > of the flag, but it gives you the idea. Mercurial if I remember correctly uses "backout" for git-revert equivalent. Perhaps "rewind" would be better name for git-reset. > * serve > * show = show + ls + log + grep + rev-list + rev-parse + describe > Combining all this may raise a few eye-brows, but I think > it makes sense. Really this command is git log + ls-files + > describe and the ability of showing files from other > revisions from git show, the rest can be reduced to > functionality already available in git log. I think that having git-log to show series of commits, and git-show for individual, _single_ objects (be it tree, working area, blob, commit, tag, current revision name = git-describe) would be better idea. git-rev-list and git-rev-parse are deep plumbing, not usually to be used by end user. > * status = status > submodule > tag > * track = add/addremove Ehhh? I'd leave add/rm/mv/cp as is. Having those commands do not add (much) to complexity. > verify = fsck [...] >>>>> 5) One stop shop. > [snip windows + webserver headaches] >>>> BTW. there always is git-instaweb. >>> >>> Yeah, but I still need the webserver, thats what I want to get rid >>> of. If you want to do some ad-hoc sharing it is a huge problem and >>> you may not have permissions/time to install software. >>> >>>> But having git-serve would be nice... >>>> >>> >>> Indeed. >> >> And with Python AFAIK you can quite easily set up _simple_ web server >> for HTTP access and browsing repository... >> >> BTW. there was at some time git web interface in Python (old wit), >> but it lost to gitweb; nowadays Ruby, eRuby or Ruby on Rails seems to >> be the rage (new Wit (from XMMS2), Gitarella, Gitorious, GitHub). >> > I was thinking of using Django so that I could reuse the stuff that > the review-board folks are doing. I like their side-by-side diffs > etc. It would be nice to have yet another web interface... > But here is the kicker, I want to use this to do what the hg > people have done. They built their remote push-pull functionality > into their built-in webserver. If we do this then the pyrite http > protocol can be a smart transport. I believe that bzr has a similar > feature in theirs. I think that git dumb HTTP/HTTPS transport would conflict with pyt-serve smart http transport / tunnelling of git protocol over http. Besides, HTTP as protocol has its disadvantages, for example it is sessionless if I remember correctly... -- Jakub Narebski Poland -- 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
