"Govind Salinas" <blix@xxxxxxxxxxxxxxxxx> writes: What I forgot to ask: how would you compare Pyrite to similar tool, namely to EasyGit? > 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... >>> 1) Reduce the number of commands. [...] >> 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... >> > > I will just have to do it right then :) Seriously, I am not afraid to > experiment > with this to get the commands right. Perhaps some of these can't be > combined, but that is no reason not to see if it works. Besides, DWIM is > not enough, in needs to be "DWIM Safely". 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. > >> 2) Reduce complexity. [...] >>> 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... >> > > Maybe, I prefer to be explicit and its a little less work for me. Let me > ask you this. Is there a down side to having 2 different names? If I > say "pyt log -r foo" do I mean "..foo" or "foo.."? Ah, yes, good catch. >>> 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. [...] > 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. >>> 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. >> > > Examples won't help too much on windows, partially because its just a pain > in the ass to do, but also because thats not the preferred platform for any > of the tools. I was using cygwin git at the time and it simply did not work. > Perhaps it has gotten better in the last few months particularly with > msysgit. > >> 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). -- 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
