On Sat, May 24, 2008 at 3:41 AM, Jakub Narebski <jnareb@xxxxxxxxx> wrote: > "Govind Salinas" <blix@xxxxxxxxxxxxxxxxx> writes: > > What I forgot to ask: how would you compare Pyrite to similar tool, > namely to EasyGit? > I think the main difference is this, from the first bullet on the eg site http://www.gnome.org/~newren/eg/ "eg focuses on documentation and examples" EasyGit is more or less a thin wrapper over git that is fully compatible (AFAIK). Elijah can correct me where I am wrong, but I see it as git training wheels for the command line. That probably sounds pejorative but I don't mean it that way. I am taking the opportunity to break compatibility in order to see if I can improve usability. Also, I don't want to just focus on the command line, I want to affect all areas. >> On Fri, May 23, 2008 at 8:07 PM, Jakub Narebski <jnareb@xxxxxxxxx> wrote: >>> "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. >> >> That may be true but it is only part of the story. I see plumbing commands >> being given to users all the time on the mailing list. Usually in some >> combination. To make it worse they usually get several sets of commands >> that do something similar but any one may or may not be exactly what >> they want because not everyone who responds fully understands what the >> commands are doing. > > The change to "git help" to show only porcelain commands unless > explicitely requested, and to git(7) manpage to have porcelain first > would help there. > > But I think using plumbing in examples are remainder of git early > days, where it was the only way to work with git. Tools like Pyrite, > or EasyGit, wouldn't change it... > The idea is that there should be one fairly obvious way to do something. If you have that then there is less confusion, especially when someone asks for help. Plus, if there is one fairly obvious way to do something, then people will need to ask for help less often. That is what I hope to accomplish. >>>> 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. stash: What is stash but a temporary commit (not on the branch)? 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. * checkout = checkout + clone + branch + remote * config = config cherry = cherry + cherry-pick * 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. "Clean" seems to me to be the working directory version of 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. mail = format-patch + send-mail move = move * pull = pull, fetch, merge 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. * 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. * status = status submodule tag * track = add/addremove verify = fsck >> >> 2) Reduce complexity. > [...] >>>> 3) Addons. [snip problems with revision numbers] > [...] >> I responded to this in another mail. The other DVCSs don't claim that >> revision numbers are all of those things. It is only necessary that when >> two people say the same thing, it mean the same thing. > >> This doesn't stop them from using these numbers more than the sha1 >> IDs because given a branch, the numbers are solid. Doing things the >> way I propose has the same properties. > > I wonder how useful in practice those revision numbers are in larger > repositories, with nonlinear history, i.e. if -r 6453:master -R 6455:master > (or something like that) is truly easier to use than master~2..master > > I _think_ that sha-1 are largely theoretical scare, as for example I > don't use them much, and if I use them it is in copy'n'paste manner. > They are useful for a different purpose. If I say master~5 today it probably won't yield the same commit tomorrow. while 6450:master would. Honestly, I have absolutely no problem with using sha1s myself, I just put this in because I have seen several people ask for it on the mailing list recently. I thought to myself, that they COULD have it if they really wanted. Also keep in mind that 12345: is usually enough as an empty RHS would default to HEAD, which saves a bit of typing. >>>> 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. 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. Thanks for taking a look and giving me your opinion, I like getting feedback about this. -Govind -- 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
