{"thread":{"id":"13630","subject":"[PYRITE] Status update and call for information.","startedAt":"2008-05-23T06:18:42Z","lastAt":"2008-05-25T19:03:37Z","messageCount":18,"participants":["Govind Salinas","Karl Hasselström","Jakub Narebski","Dmitry Potapov","Jan Krueger"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"77525","messageId":"5d46db230805222318j25657c10t2955fbdf1aa5c003@mail.gmail.com","threadId":"13630","inReplyTo":null,"subject":"[PYRITE] Status update and call for information.","fromName":"Govind Salinas","fromEmail":"blix@sophiasuchtig.com","sentAt":"2008-05-23T06:18:42Z","receivedAt":"2008-05-23T06:18:42Z","isPatch":false,"sender":{"key":"blix@sophiasuchtig.com","avatar":null},"body":"Hey Folks,\n\nI am still around working on Pyrite. Which is both a porcelain and a\ngit/Python library. I have been making some good progress recently\non my way to my alpha release and I thought I would share my progress\nand get some feedback.\n\nStatus:\n\nAlthough work and life keep me pretty busy, I have made good progress\non rounding out the use cases for Pyrite. I can do most of my day's\nSCM work in pyrite and it really just lacks a couple features before\nI can, theoretically, use it all the time. Hopefully I will be able\nto tag alpha in a couple weeks.\n\nInterface:\n\nI have been doing a lot of thinking about what kind of interface\nwould make this easily accessable to new and casual users and I have\nsome ideas where I want to go. Actually, I have taken most of the\nideas from other SCMs such as Mercurial and Bazaar in addition to git.\n\nOne of the things that has been commented on by almost any review of\ngit are the large numbers of commands that are present and the\nendless stream of flags, options, configuration variables and\nsyntaxes that are present in git. They certainly serve a purpose\nand I probably would not be able to do this without all those things\nbut it can get in a normal users way some times. Here are some of\nthe steps I have and will be taking.\n\n1) Reduce the number of commands.\n\nI am currently at 30 total commands, and while I have some more to go, I\nthink there are some ways that I can get rid of some of them by\ncombining them. Do we really need a clone, branch and checkout? Don't\nthese all mean the same thing in the end? They mean get me a working\ndirectory of the repository starting at X. For clone, you start\nwith 'master'. For checkout, you tell it what to get you. Branch\nwill help you manage things you can locally get. So perhaps we can\ndo something like the following...\n\nClone a new repo\npyt checkout http://foo.com/bar/baz.git mybaz\n\nIt's a URL, I know that I can clone that and I know I am not inside\na repository.\n\nFetch\npyt co # or remote:origin\n\nIt's a URL, but I am inside the repo, I should tell the user that\nthey are about to fetch something.\n\nPull\npyt co -m remote:origin:branch\n\nPull is just fetch/merge anyway -m tells it to merge, perhaps a flag -u\nto do it all in one step.\n\nMerge\npyt co -m localbranchhead\n\nCheckout a branch\npyt co localbranchead # or remote:origin:branch, tag:tagname etc\n\nCreate/switch to new local branch (this should look familiar)\npyt co -c -b \n\nThe list goes on.\n\n\n2) Reduce complexity.\n\nThis one is easy, not because there are commands in git that don't\nhave a use, but because we can usually spell stuff in a simpler way.\nTake for example master@{100}. If I see someone on the list use that\non I might expect that that is master 100 commits ago, rather than what\nHEAD was pointing at 100 operations ago. Furthermore, if I have just\ncloned, that won't work because I have no reflog. So what if we\nspelled that reflog:100:master? Well now at least I know that I\nam dealing with the reflog. Perhaps a more refined spelling could\ngive the user more information.\n\nTake \":/message\" I didn't even know that existed until I was looking\nfor nifty things to spell, but wouldn't \"subject:my subject\" work just\nas well? Thats a little friendlier.\n\nHow about not using the \"..\" and \"...\" since it can be surprising to\nusers what they actually do without understanding how git works.\nPerhaps something like --revision-start (-r) and --revision-end(-R)\nwould help them out. Add a --symmetric or something for \"...\".\n\nYou get the idea.\n\n3) Addons.\n\nSome functionality isn't for everyone. I have just put into my\nnext branch an addon that gives git revision numbers. Why, because\nother SCMs that are supposed to be more user friendly have them.\nBecause people have been asking for them. Because they are easier\nto remember. The concept is this. A given commit encapsulates its\nparantage, so if I have commit XYZ, I can always say that XYZ is\nso-many commits away from the first commit. The question is how\nyou determine that number and that you always do it the same. If\nwe just define the revision number to be the place of the commit\nin the list of \"git rev-list --topo-order --reverse SHA1\" then\nwe can get a consistant number semi-meaningful number, which is all\npeople really want.\n\nSo why isn't this for everyone? Because its a little slow and some\npeople on the list HATE anything that takes more than half a\nsecond. I won't name names but he has an OS named after him. So for\na git repo on decent hardware, this adds .5-1 seconds to look something\nup and find out its revision. Painful to some, but others would\nrather wait than have to try and remember a SHA1 or even just the\nfirst 8 chars of a SHA1.\n\n4) GUI.\n\nI have a GUI in mind, I haven't had time to work on it, but I have\nstarted it and the idea is that it should be able to completely\nreplace the command line. Why? because some people hate command lines\nand more importantly, because I want a GUI that will look like it\nfits into my Gnome desktop and looks decent on my Windows machine\n(which I use because I have to).\n\n5) One stop shop.\n\nI tried setting up Apache, lighttpd etc on Windows to do some ad-hoc\nserving of a git repo. I was painful. I want my webserver, gui,\ncommand line, diff tool, merge tool to all come in one package. And\nI DON'T want it to need a cygwin or msys installation to work.\n\nThat just makes life easier. And I am all about the not expending\neffort.\n\n\nWell, this mail is long enough, hopefully I will get some feedback\non this, some more ideas for things that can be simplified or\nenhanced or whatever. Please feel free to drop me a line and/or\ncheck out my public repo at http://gitorious.org/projects/pyrite.\n\nThanks,\nGovind.\n"},{"id":"77528","messageId":"20080523064541.GA31315@diana.vm.bytemark.co.uk","threadId":"13630","inReplyTo":"5d46db230805222318j25657c10t2955fbdf1aa5c003@mail.gmail.com","subject":"Re: [PYRITE] Status update and call for information.","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2008-05-23T06:45:41Z","receivedAt":"2008-05-23T06:45:41Z","isPatch":false,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2008-05-23 01:18:42 -0500, Govind Salinas wrote:\n\n> Some functionality isn't for everyone. I have just put into my next\n> branch an addon that gives git revision numbers. Why, because other\n> SCMs that are supposed to be more user friendly have them. Because\n> people have been asking for them. Because they are easier to\n> remember. The concept is this. A given commit encapsulates its\n> parantage, so if I have commit XYZ, I can always say that XYZ is\n> so-many commits away from the first commit. The question is how you\n> determine that number and that you always do it the same. If we just\n> define the revision number to be the place of the commit in the list\n> of \"git rev-list --topo-order --reverse SHA1\" then we can get a\n> consistant number semi-meaningful number, which is all people really\n> want.\n\nYou do realize that no matter how you define your sequential numbers,\nthey can't be both globally consistent and unique? (That is, either\ndifferent repositories will assign different numbers to the same\ncommit, or the same number could be assigned to more than one commit.)\n\nFor a simple reason: A numbering that's both globally consistent and\nunique can only look at a commit's ancestry (and the commit itself)\nwhen assigning a number to a commit. But in order to get _sequential_\nnumbers, you need to look at the commit's siblings as well, and the\nset of siblings can be different from repository to repository.\n\nThis has already been discussed to death elsewhere in this list at\nleast once (see the list archives), but your next paragraph suggests\nyou think it's only a performance issue, which is why I brought it up:\n\n> So why isn't this for everyone? Because its a little slow and some\n> people on the list HATE anything that takes more than half a second.\n> I won't name names but he has an OS named after him. So for a git\n> repo on decent hardware, this adds .5-1 seconds to look something up\n> and find out its revision. Painful to some, but others would rather\n> wait than have to try and remember a SHA1 or even just the first 8\n> chars of a SHA1.\n\n> Well, this mail is long enough, hopefully I will get some feedback\n> on this, some more ideas for things that can be simplified or\n> enhanced or whatever. Please feel free to drop me a line and/or\n> check out my public repo at http://gitorious.org/projects/pyrite.\n\nGood luck with your work!\n\n-- \nKarl Hasselström, kha@treskal.com\n www.treskal.com/kalle\n"},{"id":"77540","messageId":"5d46db230805230536r18ac606j93a210d0b2864719@mail.gmail.com","threadId":"13630","inReplyTo":"20080523064541.GA31315@diana.vm.bytemark.co.uk","subject":"Re: [PYRITE] Status update and call for information.","fromName":"Govind Salinas","fromEmail":"blix@sophiasuchtig.com","sentAt":"2008-05-23T12:36:25Z","receivedAt":"2008-05-23T12:36:25Z","isPatch":false,"sender":{"key":"blix@sophiasuchtig.com","avatar":null},"body":"On Fri, May 23, 2008 at 1:45 AM, Karl Hasselström wrote:\n> On 2008-05-23 01:18:42 -0500, Govind Salinas wrote:\n>\n>> Some functionality isn't for everyone. I have just put into my next\n>> branch an addon that gives git revision numbers. Why, because other\n>> SCMs that are supposed to be more user friendly have them. Because\n>> people have been asking for them. Because they are easier to\n>> remember. The concept is this. A given commit encapsulates its\n>> parantage, so if I have commit XYZ, I can always say that XYZ is\n>> so-many commits away from the first commit. The question is how you\n>> determine that number and that you always do it the same. If we just\n>> define the revision number to be the place of the commit in the list\n>> of \"git rev-list --topo-order --reverse SHA1\" then we can get a\n>> consistant number semi-meaningful number, which is all people really\n>> want.\n>\n> You do realize that no matter how you define your sequential numbers,\n> they can't be both globally consistent and unique? (That is, either\n> different repositories will assign different numbers to the same\n> commit, or the same number could be assigned to more than one commit.)\n>\n> For a simple reason: A numbering that's both globally consistent and\n> unique can only look at a commit's ancestry (and the commit itself)\n> when assigning a number to a commit. But in order to get _sequential_\n> numbers, you need to look at the commit's siblings as well, and the\n> set of siblings can be different from repository to repository.\n>\n> This has already been discussed to death elsewhere in this list at\n> least once (see the list archives), but your next paragraph suggests\n> you think it's only a performance issue, which is why I brought it up:\n>\n\nOf course, no one makes the claim that rev numbers are unique or\neven that a commit has the same revision number between branches\nin the same repository. Hg states that flat out and I believe bzr says\nthe same, although I am pretty sure they determine their numbers some\nother way. I make no such claim. What I do claim is that for a given\nbranch, a commit should always have the same revision number. Sure,\nIf you merge a commit from another branch, it's revnum might change,\nbut that is ok. As long as, assuming you have not re-written master,\n10:master will always point to the same commit I think I am providing\nsomething worth while. Also, AFAIK the order of parentage is part of\nthe hash that makes a commit ID, so if my master is a clone of your\nmaster, it should share revision numbers.\n\nThanks,\nGovind.\n"},{"id":"77541","messageId":"20080523131228.GA4292@diana.vm.bytemark.co.uk","threadId":"13630","inReplyTo":"5d46db230805230536r18ac606j93a210d0b2864719@mail.gmail.com","subject":"Re: [PYRITE] Status update and call for information.","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2008-05-23T13:12:28Z","receivedAt":"2008-05-23T13:12:28Z","isPatch":false,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2008-05-23 07:36:25 -0500, Govind Salinas wrote:\n\n> On Fri, May 23, 2008 at 1:45 AM, Karl Hasselström \n> wrote:\n>\n> > You do realize that no matter how you define your sequential\n> > numbers, they can't be both globally consistent and unique? (That\n> > is, either different repositories will assign different numbers to\n> > the same commit, or the same number could be assigned to more than\n> > one commit.)\n>\n> Of course, no one makes the claim that rev numbers are unique or\n> even that a commit has the same revision number between branches in\n> the same repository. Hg states that flat out and I believe bzr says\n> the same, although I am pretty sure they determine their numbers\n> some other way. I make no such claim. What I do claim is that for a\n> given branch, a commit should always have the same revision number.\n> Sure, If you merge a commit from another branch, it's revnum might\n> change, but that is ok. As long as, assuming you have not re-written\n> master, 10:master will always point to the same commit I think I am\n> providing something worth while. Also, AFAIK the order of parentage\n> is part of the hash that makes a commit ID, so if my master is a\n> clone of your master, it should share revision numbers.\n\nYes, with those restrictions it can be made to work. (What confused me\nwas that you brought up performance as the only reason to prefer\nhashes to your rev numbers. But hashes also have the advantage that\nthey're immutable, whereas your rev numbers are not.)\n\n-- \nKarl Hasselström, kha@treskal.com\n www.treskal.com/kalle\n"},{"id":"77626","messageId":"m34p8o4ijg.fsf@localhost.localdomain","threadId":"13630","inReplyTo":"5d46db230805222318j25657c10t2955fbdf1aa5c003@mail.gmail.com","subject":"Re: [PYRITE] Status update and call for information.","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-05-24T01:07:34Z","receivedAt":"2008-05-24T01:07:34Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"\"Govind Salinas\" writes:\n\n> One of the things that has been commented on by almost any review of\n> git are the large numbers of commands that are present and the\n> endless stream of flags, options, configuration variables and\n> syntaxes that are present in git. They certainly serve a purpose\n> and I probably would not be able to do this without all those things\n> but it can get in a normal users way some times. Here are some of\n> the steps I have and will be taking.\n\nWhich is bogus, because most of those commands are plumbing, [almost]\nnever to be used by user directly.\n\nIf I understand correctly in next major git release those commands are\nto be hidden and not present in PATH anymore.\n \n> 1) Reduce the number of commands.\n> \n> I am currently at 30 total commands, and while I have some more to go, I\n> think there are some ways that I can get rid of some of them by\n> combining them. Do we really need a clone, branch and checkout? Don't\n> these all mean the same thing in the end? They mean get me a working\n> directory of the repository starting at X. For clone, you start\n> with 'master'. For checkout, you tell it what to get you. Branch\n> will help you manage things you can locally get. So perhaps we can\n> do something like the following...\n\nNote that you sometimes want to make a branch without checking it out.\nAlso note that git-branch is overloaded to get a list of branches\navailable.\n\n> Clone a new repo\n> pyt checkout http://foo.com/bar/baz.git mybaz\n> \n> It's a URL, I know that I can clone that and I know I am not inside\n> a repository.\n> \n> Fetch\n> pyt co # or remote:origin\n> \n> It's a URL, but I am inside the repo, I should tell the user that\n> they are about to fetch something.\n\nNot necessary, you might have wanted to have repository inside\nrepository, either managed using submodules, or ignored, etc.\n\n> Pull\n> pyt co -m remote:origin:branch\n> \n> Pull is just fetch/merge anyway -m tells it to merge, perhaps a flag -u\n> to do it all in one step.\n> \n> Merge\n> pyt co -m localbranchhead\n> \n> Checkout a branch\n> pyt co localbranchead # or remote:origin:branch, tag:tagname etc\n> \n> Create/switch to new local branch (this should look familiar)\n> pyt co -c -b \n> \n> The list goes on.\n\nNote also that if you make all those unrelated (at least a bit) things\ninto one command you would lose some of error detection. For example\nyou want to clone, but due to typo and DWIM-mery of \"pyt co\" command\nit would silently fetch/merge/branch/whatever. Not good...\n\nNote also that another complaint is that git commands do many fairly\nindependent things... and you would want to escalate it even\nfurther...\n\n> 2) Reduce complexity.\n> \n> This one is easy, not because there are commands in git that don't\n> have a use, but because we can usually spell stuff in a simpler way.\n> Take for example master@{100}. If I see someone on the list use that\n> on I might expect that that is master 100 commits ago, rather than what\n> HEAD was pointing at 100 operations ago.\n\nErrr... master 100 commits ago (in first-parent line) is master~100.\nAnd that it is not where HEAD was (indirectly or directly) pointing,\nbut where 'master' ref was pointing.\n\nThe ref@{n} notation is very, very useful when you want to correct\nmistakes such as errorneous rewind (\"git reset --hard HEAD^\" for\nexample), or botched rebase, or to view pre-rebase version to compare,\netc.\n\n> Furthermore, if I have just\n> cloned, that won't work because I have no reflog. So what if we\n> spelled that reflog:100:master? Well now at least I know that I\n> am dealing with the reflog. Perhaps a more refined spelling could\n> give the user more information.\n> \n> Take \":/message\" I didn't even know that existed until I was looking\n> for nifty things to spell, but wouldn't \"subject:my subject\" work just\n> as well? Thats a little friendlier.\n> \n> How about not using the \"..\" and \"...\" since it can be surprising to\n> users what they actually do without understanding how git works.\n> Perhaps something like --revision-start (-r) and --revision-end(-R)\n> would help them out. Add a --symmetric or something for \"...\".\n\nYou don't need two options; first -r is start, second -r is end...\n \n> You get the idea.\n\nTrue, the fact that revisions are non-option parameters, and that\npathspecs are also non-option parameters might be a bit confusing to\nnewbie.\n\nOn the other hand the a..b and a...b notation is matter of convenience\n(it is easier to use than \"b ^a\" or \"a b --not $(git merge-base a\nb)\"); perhaps allowing a..b and a...b notation for git-diff was an\nerror... but it makes copy'n'paste easier...\n\n> 3) Addons.\n> \n> Some functionality isn't for everyone. I have just put into my\n> next branch an addon that gives git revision numbers. Why, because\n> other SCMs that are supposed to be more user friendly have them.\n> Because people have been asking for them. Because they are easier\n> to remember. \n\nBecause people does not understand the concept and constraints of\ndistributed version control system (with implied multiple branches and\nnonlinear history).\n\nRevision numbers cannot be all of: decentralized, global, unchanging,\nencompassing. \n\n(Decentralized means no single authority assigning numbers, and no\nrepositories which are special in any case for example using\nmerge/pull with different options than other repositories. Global\nmeans that all repositories have the same numbers for the same\nrevisions; the opposite is local, that numbers are relevant only in\nyour local repository (and you cannot say: in revision 'n' to someone\nelse). Unchanging means that revsision numbers don't change on pull\nfor example. Encompassing means that all revisions are given number.)\n\n> 4) GUI.\n> \n> I have a GUI in mind, I haven't had time to work on it, but I have\n> started it and the idea is that it should be able to completely\n> replace the command line. Why? because some people hate command lines\n> and more importantly, because I want a GUI that will look like it\n> fits into my Gnome desktop and looks decent on my Windows machine\n> (which I use because I have to).\n\nHave you checked existing git GUIs, both history viewers and commit\ntools? Gitk, git-gui, QGit, Giggle, ugit, tig,...\n \n> 5) One stop shop.\n> \n> I tried setting up Apache, lighttpd etc on Windows to do some ad-hoc\n> serving of a git repo. I was painful. I want my webserver, gui,\n> command line, diff tool, merge tool to all come in one package. And\n> I DON'T want it to need a cygwin or msys installation to work.\n> \n> That just makes life easier. And I am all about the not expending\n> effort.\n\nPerhaps we could just get more examples in gitweb/README and perhaps\nin user's manual.\n\nBTW. there always is git-instaweb.\n\nBut having git-serve would be nice...\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"77637","messageId":"5d46db230805232216p7936e5dex3aa3ff0e1e0dce06@mail.gmail.com","threadId":"13630","inReplyTo":"m34p8o4ijg.fsf@localhost.localdomain","subject":"Re: [PYRITE] Status update and call for information.","fromName":"Govind Salinas","fromEmail":"blix@sophiasuchtig.com","sentAt":"2008-05-24T05:16:17Z","receivedAt":"2008-05-24T05:16:17Z","isPatch":false,"sender":{"key":"blix@sophiasuchtig.com","avatar":null},"body":"On Fri, May 23, 2008 at 8:07 PM, Jakub Narebski wrote:\n> \"Govind Salinas\" writes:\n>\n>> One of the things that has been commented on by almost any review of\n>> git are the large numbers of commands that are present and the\n>> endless stream of flags, options, configuration variables and\n>> syntaxes that are present in git. They certainly serve a purpose\n>> and I probably would not be able to do this without all those things\n>> but it can get in a normal users way some times. Here are some of\n>> the steps I have and will be taking.\n>\n> Which is bogus, because most of those commands are plumbing, [almost]\n> never to be used by user directly.\n>\n> If I understand correctly in next major git release those commands are\n> to be hidden and not present in PATH anymore.\n>\n\nThat may be true but it is only part of the story. I see plumbing commands\nbeing given to users all the time on the mailing list. Usually in some\ncombination. To make it worse they usually get several sets of commands\nthat do something similar but any one may or may not be exactly what\nthey want because not everyone who responds fully understands what the\ncommands are doing.\n\nI think I can reduce the number of commands to around 25 total with 10 or\nso that a user might use regularly. But it is an experiment, we will see\nwhere it goes.\n\n>> 1) Reduce the number of commands.\n>>\n>> I am currently at 30 total commands, and while I have some more to go, I\n>> think there are some ways that I can get rid of some of them by\n>> combining them. Do we really need a clone, branch and checkout? Don't\n>> these all mean the same thing in the end? They mean get me a working\n>> directory of the repository starting at X. For clone, you start\n>> with 'master'. For checkout, you tell it what to get you. Branch\n>> will help you manage things you can locally get. So perhaps we can\n>> do something like the following...\n>\n> Note that you sometimes want to make a branch without checking it out.\n> Also note that git-branch is overloaded to get a list of branches\n> available.\n>\n\nSure, removing commands is not about removing features, its about\nreducing the learning curve and reducing confusion. Its about the\ncommands doing what I want without me having to research it.\n\n>> Fetch\n>> pyt co # or remote:origin\n>>\n>> It's a URL, but I am inside the repo, I should tell the user that\n>> they are about to fetch something.\n>\n> Not necessary, you might have wanted to have repository inside\n> repository, either managed using submodules, or ignored, etc.\n>\n\nGood point. But that could be done with a submodule command or\nby following the create with the ignore, say..\n\npyt config ignore \npyt co \n\n is not in this repo, therefore we are cloning to it. Worst case\nthere would be a flag for it in the command, since this is the\nunusual case, it would be ok to force the user to do a little more\ntyping.\n\n>> Pull\n>> pyt co -m remote:origin:branch\n>>\n>> Pull is just fetch/merge anyway -m tells it to merge, perhaps a flag -u\n>> to do it all in one step.\n>>\n>> Merge\n>> pyt co -m localbranchhead\n>>\n>> Checkout a branch\n>> pyt co localbranchead # or remote:origin:branch, tag:tagname etc\n>>\n>> Create/switch to new local branch (this should look familiar)\n>> pyt co -c -b \n>>\n>> The list goes on.\n>\n> Note also that if you make all those unrelated (at least a bit) things\n> into one command you would lose some of error detection. For example\n> you want to clone, but due to typo and DWIM-mery of \"pyt co\" command\n> it would silently fetch/merge/branch/whatever. Not good...\n>\n> Note also that another complaint is that git commands do many fairly\n> independent things... and you would want to escalate it even\n> further...\n>\n\nI will just have to do it right then :) Seriously, I am not afraid to\nexperiment\nwith this to get the commands right. Perhaps some of these can't be\ncombined, but that is no reason not to see if it works. Besides, DWIM is\nnot enough, in needs to be \"DWIM Safely\".\n\n>> 2) Reduce complexity.\n>>\n>> This one is easy, not because there are commands in git that don't\n>> have a use, but because we can usually spell stuff in a simpler way.\n>> Take for example master@{100}. If I see someone on the list use that\n>> on I might expect that that is master 100 commits ago, rather than what\n>> HEAD was pointing at 100 operations ago.\n>\n> Errr... master 100 commits ago (in first-parent line) is master~100.\n> And that it is not where HEAD was (indirectly or directly) pointing,\n> but where 'master' ref was pointing.\n>\n> The ref@{n} notation is very, very useful when you want to correct\n> mistakes such as errorneous rewind (\"git reset --hard HEAD^\" for\n> example), or botched rebase, or to view pre-rebase version to compare,\n> etc.\n>\n\nI know that, and you know that, but the command and the syntax don't\ntell you that. I only know that because I spent a night[1] going over the\ndocs and making sure I had it right, before that I had seen the notation\non the mailing list several times but never really understood it.\n\n>>\n>> How about not using the \"..\" and \"...\" since it can be surprising to\n>> users what they actually do without understanding how git works.\n>> Perhaps something like --revision-start (-r) and --revision-end(-R)\n>> would help them out. Add a --symmetric or something for \"...\".\n>\n> You don't need two options; first -r is start, second -r is end...\n>\n\nMaybe, I prefer to be explicit and its a little less work for me. Let me\nask you this. Is there a down side to having 2 different names? If I\nsay \"pyt log -r foo\" do I mean \"..foo\" or \"foo..\"?\n\n>> 3) Addons.\n>>\n>> Some functionality isn't for everyone. I have just put into my\n>> next branch an addon that gives git revision numbers. Why, because\n>> other SCMs that are supposed to be more user friendly have them.\n>> Because people have been asking for them. Because they are easier\n>> to remember.\n>\n> Because people does not understand the concept and constraints of\n> distributed version control system (with implied multiple branches and\n> nonlinear history).\n>\n> Revision numbers cannot be all of: decentralized, global, unchanging,\n> encompassing.\n>\n> (Decentralized means no single authority assigning numbers, and no\n> repositories which are special in any case for example using\n> merge/pull with different options than other repositories. Global\n> means that all repositories have the same numbers for the same\n> revisions; the opposite is local, that numbers are relevant only in\n> your local repository (and you cannot say: in revision 'n' to someone\n> else). Unchanging means that revsision numbers don't change on pull\n> for example. Encompassing means that all revisions are given number.)\n>\n\nI responded to this in another mail. The other DVCSs don't claim that\nrevision numbers are all of those things. It is only necessary that when\ntwo people say the same thing, it mean the same thing.\n\nTo quote the Hg wiki at\nhttp://www.selenic.com/mercurial/wiki/index.cgi/RevisionNumber?highlight=(rev)\n\n\"Revision numbers referring to changesets are very likely to be\ndifferent in another copy of a repository. Do not use them to talk about\nchangesets with other people. Use the changeset ID instead.\"\n\nThis doesn't stop them from using these numbers more than the sha1\nIDs because given a branch, the numbers are solid. Doing things the\nway I propose has the same properties.\n\n>> 4) GUI.\n>>\n>> I have a GUI in mind, I haven't had time to work on it, but I have\n>> started it and the idea is that it should be able to completely\n>> replace the command line. Why? because some people hate command lines\n>> and more importantly, because I want a GUI that will look like it\n>> fits into my Gnome desktop and looks decent on my Windows machine\n>> (which I use because I have to).\n>\n> Have you checked existing git GUIs, both history viewers and commit\n> tools? Gitk, git-gui, QGit, Giggle, ugit, tig,...\n>\n\nYes I have looked at most of them, and all of them have something (or\neven many things) I want but none of them have everything. Giggle\nhas the UI I want, gitk and git-gui have most of the functionality. ugit\nhas some nice features that the others don't.\n\n>> 5) One stop shop.\n>>\n>> I tried setting up Apache, lighttpd etc on Windows to do some ad-hoc\n>> serving of a git repo. I was painful. I want my webserver, gui,\n>> command line, diff tool, merge tool to all come in one package. And\n>> I DON'T want it to need a cygwin or msys installation to work.\n>>\n>> That just makes life easier. And I am all about the not expending\n>> effort.\n>\n> Perhaps we could just get more examples in gitweb/README and perhaps\n> in user's manual.\n>\n\nExamples won't help too much on windows, partially because its just a pain\nin the ass to do, but also because thats not the preferred platform for any\nof the tools. I was using cygwin git at the time and it simply did not work.\nPerhaps it has gotten better in the last few months particularly with\nmsysgit.\n\n> BTW. there always is git-instaweb.\n>\n\nYeah, but I still need the webserver, thats what I want to get rid of. If you\nwant to do some ad-hoc sharing it is a huge problem and you may not\nhave permissions/time to install software.\n\n> But having git-serve would be nice...\n>\n\nIndeed.\n\n-Govind\n\n[1] Ok, a couple of hours anyway.\n"},{"id":"77646","messageId":"m3r6bs2ixn.fsf@localhost.localdomain","threadId":"13630","inReplyTo":"5d46db230805232216p7936e5dex3aa3ff0e1e0dce06@mail.gmail.com","subject":"Re: [PYRITE] Status update and call for information.","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-05-24T08:41:58Z","receivedAt":"2008-05-24T08:41:58Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"\"Govind Salinas\" writes:\n\nWhat I forgot to ask: how would you compare Pyrite to similar tool,\nnamely to EasyGit?\n\n> On Fri, May 23, 2008 at 8:07 PM, Jakub Narebski wrote:\n>> \"Govind Salinas\" writes:\n>>\n>>> One of the things that has been commented on by almost any review of\n>>> git are the large numbers of commands that are present and the\n>>> endless stream of flags, options, configuration variables and\n>>> syntaxes that are present in git. They certainly serve a purpose\n>>> and I probably would not be able to do this without all those things\n>>> but it can get in a normal users way some times. Here are some of\n>>> the steps I have and will be taking.\n>>\n>> Which is bogus, because most of those commands are plumbing, [almost]\n>> never to be used by user directly.\n>>\n>> If I understand correctly in next major git release those commands are\n>> to be hidden and not present in PATH anymore.\n> \n> That may be true but it is only part of the story. I see plumbing commands\n> being given to users all the time on the mailing list. Usually in some\n> combination. To make it worse they usually get several sets of commands\n> that do something similar but any one may or may not be exactly what\n> they want because not everyone who responds fully understands what the\n> commands are doing.\n\nThe change to \"git help\" to show only porcelain commands unless\nexplicitely requested, and to git(7) manpage to have porcelain first\nwould help there.\n\nBut I think using plumbing in examples are remainder of git early\ndays, where it was the only way to work with git. Tools like Pyrite,\nor EasyGit, wouldn't change it...\n\n>>> 1) Reduce the number of commands.\n[...]\n>> Note also that if you make all those unrelated (at least a bit) things\n>> into one command you would lose some of error detection. For example\n>> you want to clone, but due to typo and DWIM-mery of \"pyt co\" command\n>> it would silently fetch/merge/branch/whatever. Not good...\n>>\n>> Note also that another complaint is that git commands do many fairly\n>> independent things... and you would want to escalate it even\n>> further...\n>>\n> \n> I will just have to do it right then :) Seriously, I am not afraid to\n> experiment\n> with this to get the commands right. Perhaps some of these can't be\n> combined, but that is no reason not to see if it works. Besides, DWIM is\n> not enough, in needs to be \"DWIM Safely\".\n\nI think you should start not with \"minimal number of commands\" as a\ngoal, but rather with set of distinct tasks ordinary (not scripting)\nuser might need, and how to map them into commands.\n \nTo heavily overloaded commands are as much if not worse than having\ntoo many commands to choose from.\n\n> >> 2) Reduce complexity.\n[...]\n>>> How about not using the \"..\" and \"...\" since it can be surprising to\n>>> users what they actually do without understanding how git works.\n>>> Perhaps something like --revision-start (-r) and --revision-end(-R)\n>>> would help them out. Add a --symmetric or something for \"...\".\n>>\n>> You don't need two options; first -r is start, second -r is end...\n>>\n> \n> Maybe, I prefer to be explicit and its a little less work for me. Let me\n> ask you this. Is there a down side to having 2 different names? If I\n> say \"pyt log -r foo\" do I mean \"..foo\" or \"foo..\"?\n\nAh, yes, good catch.\n \n>>> 3) Addons.\n>>>\n>>> Some functionality isn't for everyone. I have just put into my\n>>> next branch an addon that gives git revision numbers. Why, because\n>>> other SCMs that are supposed to be more user friendly have them.\n>>> Because people have been asking for them. Because they are easier\n>>> to remember.\n>>\n>> Because people does not understand the concept and constraints of\n>> distributed version control system (with implied multiple branches and\n>> nonlinear history).\n>>\n>> Revision numbers cannot be all of: decentralized, global, unchanging,\n>> encompassing.\n[...] \n> I responded to this in another mail. The other DVCSs don't claim that\n> revision numbers are all of those things. It is only necessary that when\n> two people say the same thing, it mean the same thing.\n\n> This doesn't stop them from using these numbers more than the sha1\n> IDs because given a branch, the numbers are solid. Doing things the\n> way I propose has the same properties.\n\nI wonder how useful in practice those revision numbers are in larger\nrepositories, with nonlinear history, i.e. if -r 6453:master -R 6455:master\n(or something like that) is truly easier to use than master~2..master \n\nI _think_ that sha-1 are largely theoretical scare, as for example I\ndon't use them much, and if I use them it is in copy'n'paste manner.\n\n>>> 5) One stop shop.\n>>>\n>>> I tried setting up Apache, lighttpd etc on Windows to do some ad-hoc\n>>> serving of a git repo. I was painful. I want my webserver, gui,\n>>> command line, diff tool, merge tool to all come in one package. And\n>>> I DON'T want it to need a cygwin or msys installation to work.\n>>>\n>>> That just makes life easier. And I am all about the not expending\n>>> effort.\n>>\n>> Perhaps we could just get more examples in gitweb/README and perhaps\n>> in user's manual.\n>>\n> \n> Examples won't help too much on windows, partially because its just a pain\n> in the ass to do, but also because thats not the preferred platform for any\n> of the tools. I was using cygwin git at the time and it simply did not work.\n> Perhaps it has gotten better in the last few months particularly with\n> msysgit.\n> \n>> BTW. there always is git-instaweb.\n>>\n> \n> Yeah, but I still need the webserver, thats what I want to get rid of. If you\n> want to do some ad-hoc sharing it is a huge problem and you may not\n> have permissions/time to install software.\n> \n>> But having git-serve would be nice...\n>>\n> \n> Indeed.\n\nAnd with Python AFAIK you can quite easily set up _simple_ web server\nfor HTTP access and browsing repository...\n\nBTW. there was at some time git web interface in Python (old wit), but\nit lost to gitweb; nowadays Ruby, eRuby or Ruby on Rails seems to be\nthe rage (new Wit (from XMMS2), Gitarella, Gitorious, GitHub).\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"77662","messageId":"5d46db230805241043u7222be34w7dd8cfcb188ef005@mail.gmail.com","threadId":"13630","inReplyTo":"m3r6bs2ixn.fsf@localhost.localdomain","subject":"Re: [PYRITE] Status update and call for information.","fromName":"Govind Salinas","fromEmail":"blix@sophiasuchtig.com","sentAt":"2008-05-24T17:43:19Z","receivedAt":"2008-05-24T17:43:19Z","isPatch":false,"sender":{"key":"blix@sophiasuchtig.com","avatar":null},"body":"On Sat, May 24, 2008 at 3:41 AM, Jakub Narebski wrote:\n> \"Govind Salinas\" writes:\n>\n> What I forgot to ask: how would you compare Pyrite to similar tool,\n> namely to EasyGit?\n>\n\nI think the main difference is this, from the first bullet on the eg site\nhttp://www.gnome.org/~newren/eg/\n\n\"eg focuses on documentation and examples\"\n\nEasyGit is more or less a thin wrapper over git that is fully compatible\n(AFAIK). Elijah can correct me where I am wrong, but I see it as git\ntraining wheels for the command line. That probably sounds\npejorative but I don't mean it that way. I am taking the opportunity\nto break compatibility in order to see if I can improve usability. Also, I\ndon't want to just focus on the command line, I want to affect all areas.\n\n>> On Fri, May 23, 2008 at 8:07 PM, Jakub Narebski wrote:\n>>> \"Govind Salinas\" writes:\n>>>\n>>>> One of the things that has been commented on by almost any review of\n>>>> git are the large numbers of commands that are present and the\n>>>> endless stream of flags, options, configuration variables and\n>>>> syntaxes that are present in git. They certainly serve a purpose\n>>>> and I probably would not be able to do this without all those things\n>>>> but it can get in a normal users way some times. Here are some of\n>>>> the steps I have and will be taking.\n>>>\n>>> Which is bogus, because most of those commands are plumbing, [almost]\n>>> never to be used by user directly.\n>>>\n>>> If I understand correctly in next major git release those commands are\n>>> to be hidden and not present in PATH anymore.\n>>\n>> That may be true but it is only part of the story. I see plumbing commands\n>> being given to users all the time on the mailing list. Usually in some\n>> combination. To make it worse they usually get several sets of commands\n>> that do something similar but any one may or may not be exactly what\n>> they want because not everyone who responds fully understands what the\n>> commands are doing.\n>\n> The change to \"git help\" to show only porcelain commands unless\n> explicitely requested, and to git(7) manpage to have porcelain first\n> would help there.\n>\n> But I think using plumbing in examples are remainder of git early\n> days, where it was the only way to work with git. Tools like Pyrite,\n> or EasyGit, wouldn't change it...\n>\n\nThe idea is that there should be one fairly obvious way to do something.\nIf you have that then there is less confusion, especially when someone\nasks for help. Plus, if there is one fairly obvious way to do something,\nthen people will need to ask for help less often. That is what I hope to\naccomplish.\n\n>>>> 1) Reduce the number of commands.\n> [...]\n> I think you should start not with \"minimal number of commands\" as a\n> goal, but rather with set of distinct tasks ordinary (not scripting)\n> user might need, and how to map them into commands.\n>\n> To heavily overloaded commands are as much if not worse than having\n> too many commands to choose from.\n>\n\nThis is true. This idea is fairly new and I am still deciding exactly\nhow things\nwould get broken up. After thinking about it, \"checkout\" probably should\nnot be combined with the fetch/pull/merge command because they are\ntoo different. Here is how I am thinking of combining things, perhaps you\nand others can give some pointers on what is crazy and what might work.\n\nThe ones prefixed with * are the ones that would show up in the short\nhelp, the ones that would be the most typically used.\n\n bisect = bisect\n blame = blame\n* commit = commit + push + stash + init\n push: This is here because it fits the traditional notion of what a\n commit does, which is to send a commit to the central\n server. I think of it as \"I am committing my changes to\n the remote repository.\n stash: What is stash but a temporary commit (not on the branch)?\n init: This can be done a couple of ways, either your initial\n commit is combined with the init or --init is a flag\n passed to commit to set up the NULL commit. At least\n thats how I think of it conceptually.\n* checkout = checkout + clone + branch + remote\n* config = config\n cherry = cherry + cherry-pick\n* diff = diff\n gc = clean + gc + prune + repack\n I plan to make full use of gc --auto to avoid having the\n user run this command, but everyone knows there\n are reasons to run these commands even with --auto.\n \"Clean\" seems to me to be the working directory version\n of gc.\n* gui = gui\n* help = help\n import = apply + cvsimport + import + am\n Here the import strategies would be provided by addons\n and such with apply/am as standard.\n mail = format-patch + send-mail\n move = move\n* pull = pull, fetch, merge\n rebase = rebase\n remove = remove\n* resolve = mergetool\n revert = reset + reflog\n I was thinking of calling this command \"recover\" instead of\n revert, which I still think might describe what I want to do\n and might tell you why I think that reflog is something to\n combine here. \"revert --what-can-i-revert-to\" would show\n the output of reflog. That wouldn't be the actual name\n of the flag, but it gives you the idea.\n* serve\n* show = show + ls + log + grep + rev-list + rev-parse + describe\n Combining all this may raise a few eye-brows, but I think\n it makes sense. Really this command is git log + ls-files +\n describe and the ability of showing files from other revisions\n from git show, the rest can be reduced to functionality already\n available in git log.\n* status = status\n submodule\n tag\n* track = add/addremove\n verify = fsck\n\n>> >> 2) Reduce complexity.\n> [...]\n>>>> 3) Addons.\n[snip problems with revision numbers]\n> [...]\n>> I responded to this in another mail. The other DVCSs don't claim that\n>> revision numbers are all of those things. It is only necessary that when\n>> two people say the same thing, it mean the same thing.\n>\n>> This doesn't stop them from using these numbers more than the sha1\n>> IDs because given a branch, the numbers are solid. Doing things the\n>> way I propose has the same properties.\n>\n> I wonder how useful in practice those revision numbers are in larger\n> repositories, with nonlinear history, i.e. if -r 6453:master -R 6455:master\n> (or something like that) is truly easier to use than master~2..master\n>\n> I _think_ that sha-1 are largely theoretical scare, as for example I\n> don't use them much, and if I use them it is in copy'n'paste manner.\n>\n\nThey are useful for a different purpose. If I say master~5 today it\nprobably won't yield the same commit tomorrow. while 6450:master would.\nHonestly, I have absolutely no problem with using sha1s myself, I just put\nthis in because I have seen several people ask for it on the mailing list\nrecently. I thought to myself, that they COULD have it if they really wanted.\nAlso keep in mind that 12345: is usually enough as an empty RHS would\ndefault to HEAD, which saves a bit of typing.\n\n>>>> 5) One stop shop.\n[snip windows + webserver headaches]\n>>> BTW. there always is git-instaweb.\n>>>\n>>\n>> Yeah, but I still need the webserver, thats what I want to get rid of. If you\n>> want to do some ad-hoc sharing it is a huge problem and you may not\n>> have permissions/time to install software.\n>>\n>>> But having git-serve would be nice...\n>>>\n>>\n>> Indeed.\n>\n> And with Python AFAIK you can quite easily set up _simple_ web server\n> for HTTP access and browsing repository...\n>\n> BTW. there was at some time git web interface in Python (old wit), but\n> it lost to gitweb; nowadays Ruby, eRuby or Ruby on Rails seems to be\n> the rage (new Wit (from XMMS2), Gitarella, Gitorious, GitHub).\n>\nI was thinking of using Django so that I could reuse the stuff that the\nreview-board folks are doing. I like their side-by-side diffs etc. But here\nis the kicker, I want to use this to do what the hg people have done.\nThey built their remote push-pull functionality into their built-in webserver.\nIf we do this then the pyrite http protocol can be a smart transport. I\nbelieve that bzr has a similar feature in theirs.\n\nThanks for taking a look and giving me your opinion, I like getting\nfeedback about this.\n\n-Govind\n"},{"id":"77666","messageId":"20080524195753.GB3745@dpotapov.dyndns.org","threadId":"13630","inReplyTo":"m34p8o4ijg.fsf@localhost.localdomain","subject":"Re: [PYRITE] Status update and call for information.","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2008-05-24T19:57:53Z","receivedAt":"2008-05-24T19:57:53Z","isPatch":false,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"On Fri, May 23, 2008 at 06:07:34PM -0700, Jakub Narebski wrote:\n> \n> On the other hand the a..b and a...b notation is matter of convenience\n> (it is easier to use than \"b ^a\" or \"a b --not $(git merge-base a\n> b)\"); perhaps allowing a..b and a...b notation for git-diff was an\n> error... but it makes copy'n'paste easier...\n\nI believe that the error was how these operations were defined for diff.\nI would rather expect to 'git diff a..b' to produce the accumulative\npatch of 'git log -p a..b', but currently 'git diff a..b' is equivalent\nof 'git diff a b', and this is redundant and confusing. As to 'git diff\na...b', it would be nice if it showed three way diff. At least, it is\nhow I would define them if I were writing some front-end.\n\nDmitry\n"},{"id":"77667","messageId":"20080524195957.GC3745@dpotapov.dyndns.org","threadId":"13630","inReplyTo":"5d46db230805232216p7936e5dex3aa3ff0e1e0dce06@mail.gmail.com","subject":"Re: [PYRITE] Status update and call for information.","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2008-05-24T19:59:57Z","receivedAt":"2008-05-24T19:59:57Z","isPatch":false,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"On Sat, May 24, 2008 at 12:16:17AM -0500, Govind Salinas wrote:\n> On Fri, May 23, 2008 at 8:07 PM, Jakub Narebski wrote:\n> > \"Govind Salinas\" writes:\n> >\n> >> 1) Reduce the number of commands.\n> >>\n> >> I am currently at 30 total commands, and while I have some more to go, I\n> >> think there are some ways that I can get rid of some of them by\n> >> combining them. Do we really need a clone, branch and checkout? Don't\n> >> these all mean the same thing in the end? They mean get me a working\n> >> directory of the repository starting at X. For clone, you start\n> >> with 'master'. For checkout, you tell it what to get you. Branch\n> >> will help you manage things you can locally get. So perhaps we can\n> >> do something like the following...\n> >\n> > Note that you sometimes want to make a branch without checking it out.\n> > Also note that git-branch is overloaded to get a list of branches\n> > available.\n> >\n> \n> Sure, removing commands is not about removing features, its about\n> reducing the learning curve and reducing confusion.\n\nI don't see how hiding creating branch functionality behind some other\ncommand will help with learning curve or reduce confusion. If I started\nto use any new SCM and had to create a new branch, I would look for the\n\"branch\" command. If there is something wrong with the git-branch then\nit is that this command does not checkout the newly created branch by\ndefault. So, I usually create branches using git-checkout, which is\ncounterintuitive.\n\nI don't think any commonly used SCM unites 'clone', 'branch', and\n'checkout' functionality under the same name. This approach seems\nto be more confusing than helpful.\n\nDmitry\n"},{"id":"77669","messageId":"200805242247.07565.jnareb@gmail.com","threadId":"13630","inReplyTo":"20080524195957.GC3745@dpotapov.dyndns.org","subject":"Re: [PYRITE] Status update and call for information.","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-05-24T20:47:06Z","receivedAt":"2008-05-24T20:47:06Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Sat, 24 May 2008, Dmitry Potapov wrote:\n> On Sat, May 24, 2008 at 12:16:17AM -0500, Govind Salinas wrote:\n>> On Fri, May 23, 2008 at 8:07 PM, Jakub Narebski wrote:\n>>> \"Govind Salinas\" writes:\n>>>\n>>>> 1) Reduce the number of commands.\n>>>>\n>>>> I am currently at 30 total commands, and while I have some more to go, I\n>>>> think there are some ways that I can get rid of some of them by\n>>>> combining them. Do we really need a clone, branch and checkout? Don't\n>>>> these all mean the same thing in the end? They mean get me a working\n>>>> directory of the repository starting at X. For clone, you start\n>>>> with 'master'. For checkout, you tell it what to get you. Branch\n>>>> will help you manage things you can locally get. So perhaps we can\n>>>> do something like the following...\n>>>\n>>> Note that you sometimes want to make a branch without checking it out.\n>>> Also note that git-branch is overloaded to get a list of branches\n>>> available.\n>>>\n>> \n>> Sure, removing commands is not about removing features, its about\n>> reducing the learning curve and reducing confusion.\n> \n> I don't see how hiding creating branch functionality behind some other\n> command will help with learning curve or reduce confusion. If I started\n> to use any new SCM and had to create a new branch, I would look for the\n> \"branch\" command. If there is something wrong with the git-branch then\n> it is that this command does not checkout the newly created branch by\n> default. So, I usually create branches using git-checkout, which is\n> counterintuitive.\n\nThat of course depends on the point of view [1]. Branches in git\nare \"growth point\" pointers to DAG of revisions. git-branch lists\nand creates branches, and can be used to rename and delete branches\nas well, and to enable reflog for branch. It does not touch working\narea; separation of domains. (Note that sometimes you want to create\nbranch without checking it out).\n\ngit-checkout on the other hand is used to bring working area to given\nstate, usually from given branch (switching branches) or arbitrary\nrevision (detaching HEAD), but in some cases (with filename/pathspec)\nfrom index.\n\nNow, the seqence of\n $ git branch \n $ git checkout \ncould be written as\n $ git checkout -b \nbut could have been done as\n $ git branch -c \ninstead. I think it is largely matter of priorities, taste... and\nof course historical reasons and backwards compatibility.\n \n> I don't think any commonly used SCM unites 'clone', 'branch', and\n> 'checkout' functionality under the same name. This approach seems\n> to be more confusing than helpful.\n\nThis is also my opinion. Perhaps 'clone' and 'init', or 'clone' and\n'import' could be the same command... hat might make sense...\n\nFootnotes:\n==========\n[1] \"The only intuitive interface is the nipple; everything else is\n learned.\" (attribution, anyone?)\n-- \nJakub Narebski\nPoland\n"},{"id":"77674","messageId":"5d46db230805241450w71b0c587o4767becc0058ee0a@mail.gmail.com","threadId":"13630","inReplyTo":"200805242247.07565.jnareb@gmail.com","subject":"Re: [PYRITE] Status update and call for information.","fromName":"Govind Salinas","fromEmail":"blix@sophiasuchtig.com","sentAt":"2008-05-24T21:50:24Z","receivedAt":"2008-05-24T21:50:24Z","isPatch":false,"sender":{"key":"blix@sophiasuchtig.com","avatar":null},"body":"On Sat, May 24, 2008 at 3:47 PM, Jakub Narebski wrote:\n> On Sat, 24 May 2008, Dmitry Potapov wrote:\n>> On Sat, May 24, 2008 at 12:16:17AM -0500, Govind Salinas wrote:\n>>> On Fri, May 23, 2008 at 8:07 PM, Jakub Narebski wrote:\n>>>> \"Govind Salinas\" writes:\n>>>>\n>>>>> 1) Reduce the number of commands.\n>>>>>\n>>>>> I am currently at 30 total commands, and while I have some more to go, I\n>>>>> think there are some ways that I can get rid of some of them by\n>>>>> combining them. Do we really need a clone, branch and checkout? Don't\n>>>>> these all mean the same thing in the end? They mean get me a working\n>>>>> directory of the repository starting at X. For clone, you start\n>>>>> with 'master'. For checkout, you tell it what to get you. Branch\n>>>>> will help you manage things you can locally get. So perhaps we can\n>>>>> do something like the following...\n>>>>\n>>>> Note that you sometimes want to make a branch without checking it out.\n>>>> Also note that git-branch is overloaded to get a list of branches\n>>>> available.\n>>>>\n>>>\n>>> Sure, removing commands is not about removing features, its about\n>>> reducing the learning curve and reducing confusion.\n>>\n>> I don't see how hiding creating branch functionality behind some other\n>> command will help with learning curve or reduce confusion. If I started\n>> to use any new SCM and had to create a new branch, I would look for the\n>> \"branch\" command. If there is something wrong with the git-branch then\n>> it is that this command does not checkout the newly created branch by\n>> default. So, I usually create branches using git-checkout, which is\n>> counterintuitive.\n>\n\nIf you will allow me to respond to both items in this mail...\n\nIn bzr both clone and branch are in the 'branch' command because every\nbranch is its own clone. Hg defaults to a similar way of doing things and\nYou clone into a new directory to get a new branch.\n\n>From the bzr user reference:\n\nBranch:\n...\n\n Aliases:\n get, clone\n...\n\n\nIn truth, the git notion of a branch is pretty unique among SMCs. In old\nsystems a branch was just a copy of a set of files at a certain point. In\nother DSCMs it is more likely to be a new copy of the repo.\n\nTo answer your question a little better, I am looking at it like this:\nThe predominant action is, as you say, going to be \"I want to create a\nbranch so that I can start working on something.\" While I respect that\nyou might want to create a branch and not start doing something\n*right away*, I think this is less likely. So...\n\npyt co\n this lists stuff you can checkout by which we mean local branches.\n\npyt co -r\n this lists remote stuff you can check out, such as remote tracking\n branches and the remotes themselves.\n\npyt co -a\n lists both of the above, maybe tags too.\n\npyt co \n checkout the branch, looking at refs\n\npyr co \n the user wants to checkout something that isn't local. So we do\n a git remote add -t -f followed by\n checkout /\n There would probably be variations/flags to get different functionality.\n\npyt co -n mynewbranch [start=HEAD]\n creates and checks out a new branch.\n\npyt co [something=HEAD] [--] ...\n should be obvious\n\nThe following are a little less intuitive, because they don't actually\nresult in new stuff being put in the working directory. These things are\nnot really a checkout activity, I will stipulate that. However, I don't think\nwe need one interface to do stuff with branches and remotes, one to\nmanage branches and one to mange remotes. And I think that users\nwill be able to grasp this pretty quickly.\n\npyt co --create-only mynewbranch\n just creates without switching, it is a long option because this is not\n a normal function and the user needs to understand what they are\n doing.\n\npyt co -d [-f] | | \n delete a branch or stop tracking a remote.\n\n> That of course depends on the point of view [1]. Branches in git\n> are \"growth point\" pointers to DAG of revisions. git-branch lists\n> and creates branches, and can be used to rename and delete branches\n> as well, and to enable reflog for branch. It does not touch working\n> area; separation of domains. (Note that sometimes you want to create\n> branch without checking it out).\n>\n> git-checkout on the other hand is used to bring working area to given\n> state, usually from given branch (switching branches) or arbitrary\n> revision (detaching HEAD), but in some cases (with filename/pathspec)\n> from index.\n>\n> Now, the seqence of\n> $ git branch \n> $ git checkout \n> could be written as\n> $ git checkout -b \n> but could have been done as\n> $ git branch -c \n\nExactly! My first draft of the pyt branch command had a -c option\njust like that.\n\n> instead. I think it is largely matter of priorities, taste... and\n> of course historical reasons and backwards compatibility.\n>\n>> I don't think any commonly used SCM unites 'clone', 'branch', and\n>> 'checkout' functionality under the same name. This approach seems\n>> to be more confusing than helpful.\n>\n> This is also my opinion. Perhaps 'clone' and 'init', or 'clone' and\n> 'import' could be the same command... hat might make sense...\n>\nSee above, they in fact do. It struck me as odd too, because I had\nstarted with git. After thinking about it for a while, I saw advantages\nto it.\n\n-Govind\n"},{"id":"77678","messageId":"200805250023.27440.jnareb@gmail.com","threadId":"13630","inReplyTo":"20080524195753.GB3745@dpotapov.dyndns.org","subject":"Re: [PYRITE] Status update and call for information.","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-05-24T22:23:27Z","receivedAt":"2008-05-24T22:23:27Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Sat, 24 May 2008, Dmitry Potapov wrote:\n> On Fri, May 23, 2008 at 06:07:34PM -0700, Jakub Narebski wrote:\n>> \n>> On the other hand the a..b and a...b notation is matter of convenience\n>> (it is easier to use than \"b ^a\" or \"a b --not $(git merge-base a\n>> b)\"); perhaps allowing a..b and a...b notation for git-diff was an\n>> error... but it makes copy'n'paste easier...\n> \n> I believe that the error was how these operations were defined for diff.\n> I would rather expect to 'git diff a..b' to produce the accumulative\n> patch of 'git log -p a..b', but currently 'git diff a..b' is equivalent\n> of 'git diff a b', and this is redundant and confusing. \n\nI think \"git diff a..b\" and \"git diff a...b\" (which is cute hack) were\ncreated to allow copy'n'paste from git-fetch result messages, not only\nto git-log but also for git-diff; note that in case of git-fetch\nmessages a..b is always fast-forward (a = merge-base a b).\n\nI think that both solutions for \"git diff a..b\", be it \"git diff a b\"\nor \"git diff $(git merge-base a b) b\" can be argued for, soe historical\nreasons (a...b was added later) and backward compatibility wins.\n\n> As to 'git diff a...b', it would be nice if it showed three way diff.\n> At least, it is how I would define them if I were writing some\n> front-end. \n\nAt least \"git diff --cc a...b\" and \"git diff -c a...b\", i.e. diff as\nif there were a merge... although now that I look at it it seems to\nbe more difficult than on first glance.\n\n-- \nJakub Narebski\nPoland\n"},{"id":"77683","messageId":"200805250127.09506.jnareb@gmail.com","threadId":"13630","inReplyTo":"5d46db230805241043u7222be34w7dd8cfcb188ef005@mail.gmail.com","subject":"Re: [PYRITE] Status update and call for information.","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-05-24T23:27:09Z","receivedAt":"2008-05-24T23:27:09Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Sat, 24 May 2008, Govind Salinas wrote:\n> On Sat, May 24, 2008 at 3:41 AM, Jakub Narebski wrote:\n>> \"Govind Salinas\" writes:\n\n>>>>> 1) Reduce the number of commands.\n>> [...]\n>> I think you should start not with \"minimal number of commands\" as a\n>> goal, but rather with set of distinct tasks ordinary (not scripting)\n>> user might need, and how to map them into commands.\n>>\n>> To heavily overloaded commands are as much if not worse than having\n>> too many commands to choose from.\n> \n> This is true. This idea is fairly new and I am still deciding exactly\n> how things would get broken up. After thinking about it, \"checkout\"\n> probably should not be combined with the fetch/pull/merge command\n> because they are too different. Here is how I am thinking of\n> combining things, perhaps you and others can give some pointers on\n> what is crazy and what might work. \n> \n> The ones prefixed with * are the ones that would show up in the short\n> help, the ones that would be the most typically used.\n> \n> bisect = bisect\n> blame = blame\n> * commit = commit + push + stash + init\n> push: This is here because it fits the traditional notion\n> of what a commit does, which is to send a commit to the\n> central server. I think of it as \"I am committing my\n> changes to the remote repository.\n\nThat I'm not sure about. One of advantages of _distributed_ SCM is\nseparation of the act of committing (saving state to repository) and \npublishing (making those changes public, which stops changing history).\nSo I'd rather left commit and push separate, although I can agree that\nlocal / public commit would be not so bad alternate interface.\n\n> stash: What is stash but a temporary commit (not on the\n> branch)?\n\nI think that is (might be) a good idea, _BUT_ with the caveat that after \nstash working repository is in state _before_ changes. But that might \nwork.\n\n> init: This can be done a couple of ways, either your initial\n> commit is combined with the init or --init is a flag\n> passed to commit to set up the NULL commit. At\n> least thats how I think of it conceptually.\n\nBad, bad idea. First, init is _very_ separate thing from commit. \nSecond, you would lose I think much of error detection. And last, \nsometimes yoy initialize repository (usually bare repository) to \npropagate changes not using commit (local commit), but using push \n(remote commit).\n\n> * checkout = checkout + clone + branch + remote\n\nNo. 'clone' = 'init' + 'remote', or 'clone' ~= 'import'.\nOverloading 'checkout' to do all the work of 'branch' is\nIMHO not a good idea.\n\nHere it looks like you want to cram too much into single command.\nYou have fewer commands, but only superficially; you have actually have \nthem, but disguised as options and special cases and DWIM-mery.\n\n> * config = config\n> cherry = cherry + cherry-pick\n\nErrr... cherry has nothing to do with cherry-pick. I'd think\nthat cherry could be an option to git-log instead, and cherry-pick\nbe joined with revert.\n\n> * diff = diff\n\n> gc = clean + gc + prune + repack\n> I plan to make full use of gc --auto to avoid having the\n> user run this command, but everyone knows there\n> are reasons to run these commands even with --auto.\n\ngit-gc already is meant to be porcelain for prune and repack,\nso you should need run only this command.\n\n> \"Clean\" seems to me to be the working directory version\n> of gc.\n\ngit-clean is potentially dangerous. It is _not_ garbage collecting.\nBesides \"git-clean\" apes \"make clean\"... actually this (the possibility \nof mistake) migh be a good argument for making git-clean to be special \ncase of git-gc.\n\n> * gui = gui\n> * help = help\n\n> import = apply + cvsimport + import + am\n> Here the import strategies would be provided by addons\n> and such with apply/am as standard.\n\nIt is one on wishlist from some time to be able to fetch / clone from \nother SCMs just by providing URL to foreign SCM, i.e. unified foreign \nSCM import and foreign SCM interaction support.\n\n> mail = format-patch + send-mail\n\nI'm not that sure. Perhaps. Or perhaps format-patch should be special \ncase of git-log (or option to git-log).\n\n> move = move\n\n> * pull = pull, fetch, merge\n\nMerge is separate from pull because it is inherently local. Pull might \nget data from remote repository. And I guess it would play merry hell \nwith remotes (shortcuts for remote repositories URLs and refspecs), and \nremote branches names.\n\n> rebase = rebase\n> remove = remove\n\n> * resolve = mergetool\n\n> revert = reset + reflog\n> I was thinking of calling this command \"recover\" instead of\n> revert, which I still think might describe what I want to do\n> and might tell you why I think that reflog is something to\n> combine here. \"revert --what-can-i-revert-to\" would show\n> the output of reflog. That wouldn't be the actual name\n> of the flag, but it gives you the idea.\n\nMercurial if I remember correctly uses \"backout\" for git-revert \nequivalent. Perhaps \"rewind\" would be better name for git-reset.\n\n> * serve\n\n> * show = show + ls + log + grep + rev-list + rev-parse + describe\n> Combining all this may raise a few eye-brows, but I think\n> it makes sense. Really this command is git log + ls-files +\n> describe and the ability of showing files from other\n> revisions from git show, the rest can be reduced to\n> functionality already available in git log.\n\nI think that having git-log to show series of commits, and git-show for \nindividual, _single_ objects (be it tree, working area, blob, commit, \ntag, current revision name = git-describe) would be better idea.\n\ngit-rev-list and git-rev-parse are deep plumbing, not usually to be used \nby end user.\n\n> * status = status \n> submodule\n> tag\n\n> * track = add/addremove\n\nEhhh? I'd leave add/rm/mv/cp as is. Having those commands do not add\n(much) to complexity.\n\n> verify = fsck\n[...]\n\n>>>>> 5) One stop shop.\n> [snip windows + webserver headaches]\n>>>> BTW. there always is git-instaweb.\n>>>\n>>> Yeah, but I still need the webserver, thats what I want to get rid\n>>> of. If you want to do some ad-hoc sharing it is a huge problem and\n>>> you may not have permissions/time to install software.\n>>>\n>>>> But having git-serve would be nice...\n>>>>\n>>>\n>>> Indeed.\n>>\n>> And with Python AFAIK you can quite easily set up _simple_ web server\n>> for HTTP access and browsing repository...\n>>\n>> BTW. there was at some time git web interface in Python (old wit),\n>> but it lost to gitweb; nowadays Ruby, eRuby or Ruby on Rails seems to\n>> be the rage (new Wit (from XMMS2), Gitarella, Gitorious, GitHub).\n>>\n> I was thinking of using Django so that I could reuse the stuff that\n> the review-board folks are doing. I like their side-by-side diffs\n> etc. \n\nIt would be nice to have yet another web interface...\n\n> But here is the kicker, I want to use this to do what the hg \n> people have done. They built their remote push-pull functionality\n> into their built-in webserver. If we do this then the pyrite http\n> protocol can be a smart transport. I believe that bzr has a similar\n> feature in theirs. \n\nI think that git dumb HTTP/HTTPS transport would conflict with pyt-serve \nsmart http transport / tunnelling of git protocol over http.\n\nBesides, HTTP as protocol has its disadvantages, for example it is \nsessionless if I remember correctly...\n\n-- \nJakub Narebski\nPoland\n"},{"id":"77701","messageId":"20080525112332.52de8270@perceptron","threadId":"13630","inReplyTo":"5d46db230805241043u7222be34w7dd8cfcb188ef005@mail.gmail.com","subject":"Re: [PYRITE] Status update and call for information.","fromName":"Jan Krueger","fromEmail":"jk@jk.gs","sentAt":"2008-05-25T09:23:32Z","receivedAt":"2008-05-25T09:23:32Z","isPatch":false,"sender":{"key":"jk@jk.gs","avatar":"https://avatars.githubusercontent.com/u/1774?v=4"},"body":"Hi,\n\nallow me to play the devil's advocate here.\n\nYour approach is to combine different concepts that are similar and can\nbe used to do the same thing but in completely different ways. Wouldn't\nthis actually create more confusion than keeping these concepts\nseparate? Examples follow.\n\n> The idea is that there should be one fairly obvious way to do\n> something. If you have that then there is less confusion, especially\n> when someone asks for help. Plus, if there is one fairly obvious way\n> to do something, then people will need to ask for help less often.\n\nIf people didn't ask things like \"how do I delete a file\", I'd be more\ninclined to believe that. ;)\n\nNow, on to the fun part.\n\n> * commit = commit + push + stash + init\n> push: This is here because it fits the traditional notion\n> of what a commit does, which is to send a commit to the central\n> server. I think of it as \"I am committing my\n> changes to the remote repository.\n\nThe problem I see there is that it will be difficult to include the\npart of push that sends several commits at once. It is a very common\nworkflow to create a series of local commits, test them, possibly\nrewrite them in several ways, and finally push the entire set. To have\nyour combined command do that, you'd need something like \"pyt commit\n--to-remote --use-new-local-commits\". Is that better than \"pyt\npush\" (and does describing this as \"committing\" actually make sense)? I\nthink not. It's sacrificing convenience and sense for reducing the\nvisible number of commands.\n\n> stash: What is stash but a temporary commit (not on the\n> branch)?\n\nThis is correct, but only technically. In fact, a commit is something\nthat you'll typically share with others, whereas a stash is not. This\nmakes me doubt it's helpful to combine both.\n\n> * checkout = checkout + clone + branch + remote\n\nCheckout already has a doubtful duality: it can either switch branches\nor check out a specific version of a single file. I don't think\ncapitalizing on the 'switch branches' concept while keeping the other\nfunction is a good idea. At the very least, consider splitting \"fetch\nother version of this file\" into a separate command.\n\nI can see another source of confusion here: with this, checkout can\neither create a new repo or a new branch in the same repo. In other\nwords, what it does depends on the context you call it in. This is a\nno-no in interface design.\n\nFinally, \"remote\" could just as well go with pull or push (which is\nwhat it's actually used for in practice). The act of defining or\nremoving a remote is misplaced here since it has nothing to do with\nchecking anything out.\n\n> gc = clean + gc + prune + repack\n\nSee Jakub's comment about that. I strongly agree with him.\n\n> * pull = pull, fetch, merge\n\nUnlike what Jakub says, I can imagine this working well in the\ndistributed case. It could be a command that does both fetch and merge\nby default and you can switch off either. It would make little sense\nwhen merging a number of local branches, however.\n\n> revert = reset + reflog\n\nKeep in mind that you need to stick git-revert somewhere, too.\n\n> (still revert)\n> I was thinking of calling this command \"recover\" instead of\n> revert, which I still think might describe what I want to do\n> and might tell you why I think that reflog is something to\n> combine here. \"revert --what-can-i-revert-to\" would show\n> the output of reflog.\n\nAnother source of confusion, since I almost never use the reflog for\ngit-reset. I almost always use a commit ID or something like HEAD^, or\nno argument at all (mostly for reset --hard).\n\n> * track = add/addremove\n\nThat would only make sense if you hide the index completely. I think\nthat's a bad idea, because the index is a really powerful thing. At the\nvery least, add -i gets impossible if there's no way of influencing the\nindex directly.\n\nIt would be a lot better to keep commit -a (and perhaps hint at it if\ncommit is called with an unchanged index) and define something like the\nfollowing:\n\n* stage (or record, take, use) -- same as git-add.\n* remove (rm) -- same as git-rm. Probably good to rename --cached.\n* unstage (or unrecord) -- revert index to version in last commit.\n\n> They are useful for a different purpose. If I say master~5 today it\n> probably won't yield the same commit tomorrow. while 6450:master\n> would.\n\nThat's right, but keep in mind that revision numbers will probably make\npeople think revision numbers are global, e.g. \"hey Bill, check out\nrevision 3488 I committed today\" (and Bill gets it as 3754). The\nbackground of either CVS or SVN would encourage this.\n\nAlso, 6450:master, as a syntax, doesn't cut it. What if in the past of\nmaster, a merge commit with seven parents happened? It's impossible to\nfigure out which parent to follow. You'd have to write something like\n45;1:357,4:774 (go back 45 commits, take parent 1, go back 357 commits,\netc.). Just numbering all commits in master's past according to\ndepth-first search, on the other hand, will just make revision numbers\nvery confusing.\n\nSomething else to consider is that revision numbers are hardly better\nto remember than (abbreviated) commit IDs. Consider KDE's SVN repository\nwith (currently) 812270 revisions...\n\n> I just put this in because I have seen several people ask for it on\n> the mailing list recently. I thought to myself, that they COULD have\n> it if they really wanted.\n\nBut with a number of important disadvantages. Sometimes it really is\nbetter not to have everything you want.\n\nIn conclusion, your goal is a good one, but it's something that\nrequires a lot of very careful consideration. To name just one thing,\nyou need to make it consistent, clean, and still powerful enough to not\nstand in the way of moderately (un)common tasks.\n\nI believe there is a bit of a tendency in your approach to emulate\ncommands of other VCS, and that's not the right way to go if you ask me.\nIf I did something like pyt (and I won't lie, I have put some thought\ninto it, including writing down a couple of ideas), I would start with a\nclean slate and design something that really makes sense (which neither\nthe current git nor any other existing interface stacked on top of it\ncan really deliver). David Roundy did this well for darcs, I think: a\ngreat number of commands have different names than in the classic VCS,\nbut they all make a lot of sense. Still, again, darcs's commands\nwouldn't work that well for git; both systems are just too different.\n\nSomething else that's worth considering is that an interface to git is\nnot just about reshuffling commands; it's also about behaviour. For\nexample, submodules as they currently are are a bit hard to use\ncorrectly (from what I've read on IRC; I haven't used them myself yet),\nand refspecs are rather non-intuitive to use (especially push :foo).\n\nIt'll be interesting to see how the various existing alternative\ninterfaces to git will address all these problems.\n\n-- \nBest regards\nJan Krueger\nAachen, Germany\n"},{"id":"77702","messageId":"200805251335.36530.jnareb@gmail.com","threadId":"13630","inReplyTo":"5d46db230805241450w71b0c587o4767becc0058ee0a@mail.gmail.com","subject":"Re: [PYRITE] Status update and call for information.","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-05-25T11:35:35Z","receivedAt":"2008-05-25T11:35:35Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Dnia sobota 24. maja 2008 23:50, Govind Salinas napisał:\n> On Sat, May 24, 2008 at 3:47 PM, Jakub Narebski wrote:\n>> On Sat, 24 May 2008, Dmitry Potapov wrote:\n>>> On Sat, May 24, 2008 at 12:16:17AM -0500, Govind Salinas wrote:\n>>>> On Fri, May 23, 2008 at 8:07 PM, Jakub Narebski wrote:\n>>>>> \"Govind Salinas\" writes:\n>>>>>\n>>>>>> 1) Reduce the number of commands.\n[...]\n>>>>\n>>>> Sure, removing commands is not about removing features, its about\n>>>> reducing the learning curve and reducing confusion.\n\nIMHO pushing too much into single commands do not reduce confusion\nbut increases it.\n\n[Searching for a good example...] For example 'mv' could be modified\nto include functionality of 'rm' in the form of 'mv file-to-delete',\nbut nobody sane would think of doing it. Another example: you can\nuse 'less' to view contents of directory, but you usually use 'ls'\nto do that; and nobody sane would think of extending 'less' to accept\nall 'ls' switches, to have all 'ls' functionality.\n\n\n\nI also think that having 30+ commands does not steep learning curve\nmake. For example GNU coreutils only consist of 90 commands, but base\nCLI is not that hard to use.\n\n>>> I don't see how hiding creating branch functionality behind some other\n>>> command will help with learning curve or reduce confusion. If I started\n>>> to use any new SCM and had to create a new branch, I would look for the\n>>> \"branch\" command. If there is something wrong with the git-branch then\n>>> it is that this command does not checkout the newly created branch by\n>>> default. So, I usually create branches using git-checkout, which is\n>>> counterintuitive.\n> \n> If you will allow me to respond to both items in this mail...\n> \n> In bzr both clone and branch are in the 'branch' command because every\n> branch is its own clone. Hg defaults to a similar way of doing things and\n> You clone into a new directory to get a new branch.\n> \n> From the bzr user reference:\n> \n> Branch:\n> ...\n> \n> Aliases:\n> get, clone\n> ...\n\nDo not cater to least common denominator, please. \n\n> In truth, the git notion of a branch is pretty unique among SMCs. In old\n> systems a branch was just a copy of a set of files at a certain point. In\n> other DSCMs it is more likely to be a new copy of the repo.\n\nI think git notion of branch is clean, and clearly superior to the crap\nothe SCMs use ;-P. I'd like to remind you that multiple branches in\nsingle repository were something added at user request, at least\naccording to Junio's FLOSS weekly #19 follow-up in his blog\n http://gitster.livejournal.com/9970.html\n\n> To answer your question a little better, I am looking at it like this:\n> The predominant action is, as you say, going to be \"I want to create a\n> branch so that I can start working on something.\" While I respect that\n> you might want to create a branch and not start doing something\n> *right away*, I think this is less likely. So...\n> \n> pyt co\n> this lists stuff you can checkout by which we mean local branches.\n\nNote that \"git checkout\" defaults to HEAD.\n\n> pyt co -r\n> this lists remote stuff you can check out, such as remote tracking\n> branches and the remotes themselves.\n> \n> pyt co -a\n> lists both of the above, maybe tags too.\n\nThese three are all about listing metadata, refs to be more exact.\n'checkout' is IMHO all about getting given state recorded in repository\n(or, in git case, also from index) into working area, i.e. in a way\nopposite to 'commit' or 'checkin', at least as far as it is possible.\nSo I think this is in the same league as using 'less' to view contents\n(listing) of a directory. This IMHO does not reduce confusion, but\nadds to it.\n\nAlso note that git-branch is used to create and list branches\n(unfortunately it uses -l for --enable-reflog and not for --list as\nother commands like git-tag do), but can be also used to delete and\nrename branches. Do you want to stuff this functionality in \"pyt co\"?\n\n> pyt co \n> checkout the branch, looking at refs\n\nIt is the default.\n\n> pyr co \n> the user wants to checkout something that isn't local. So we do\n> a git remote add -t -f followed by\n> checkout /\n> There would probably be variations/flags to get different functionality.\n\nPlease note that result of this is very, very different from ordinary\ncheckout. Either it doesn't touch working area if it is equivalent\nof git-fetch, or can result in conflicts and not a clean state if\nit is equivalent of git-pull.\n\n> pyt co -n mynewbranch [start=HEAD]\n> creates and checks out a new branch.\n\nSimply different name for option, I think.\n\n> pyt co [something=HEAD] [--] ...\n> should be obvious\n\nBut it isn't obvious. \n\nLet me explain. Because in git commits are always whole-tree\nsnapshots, and usually (read: almost always) it makes sense to have\nwhole-tree commits in an SCM, this cannot switch branches. So for\nexample there is a question if it is a separate mode (yet another\noveloading of 'pyt co' operator) of checkout changing working area\nwithout changing current branch (something like svn-revert,\nor hg-undo), or would it make HEAD detached and result in something\nlike not yet implemented \"git cherry-pick -- \".\n\n> The following are a little less intuitive, because they don't actually\n> result in new stuff being put in the working directory. These things are\n> not really a checkout activity, I will stipulate that. However, I don't think\n> we need one interface to do stuff with branches and remotes, one to\n> manage branches and one to mange remotes. And I think that users\n> will be able to grasp this pretty quickly.\n> \n> pyt co --create-only mynewbranch\n> just creates without switching, it is a long option because this is not\n> a normal function and the user needs to understand what they are\n> doing.\n\nThis is not 'checkout', mind you.\n\n> pyt co -d [-f] | | \n> delete a branch or stop tracking a remote.\n\nOh, so you do plan to stuff at least deleting branches and remotes\nin 'pyt co'?\n\nWhat was the UNIX motto: do one thing, and do it well?\n\n\n>>> I don't think any commonly used SCM unites 'clone', 'branch', and\n>>> 'checkout' functionality under the same name. This approach seems\n>>> to be more confusing than helpful.\n[...]\n> See above, they in fact do. It struck me as odd too, because I had\n> started with git. After thinking about it for a while, I saw advantages\n> to it.\n\nAnd it looks like you gone to far in the reducing number of commands\ndirection and do not see disadvantages of heavily overloaded, DWIM-ming,\ndoing multiple different things depending on options commands. If you\ndon't like large number of commands (is 30+ large number?), use GUI!\n\n\nWhat you need is to have some _users_ to tell you if you do with\nPyrite in good direction. Or at least analysis of common git workflows\nand how they could be improved...\n\n-- \nJakub Narebski\nPoland\n"},{"id":"77712","messageId":"5d46db230805251122k322647eeif1e23c5a1eccca59@mail.gmail.com","threadId":"13630","inReplyTo":"20080525112332.52de8270@perceptron","subject":"Re: [PYRITE] Status update and call for information.","fromName":"Govind Salinas","fromEmail":"blix@sophiasuchtig.com","sentAt":"2008-05-25T18:22:56Z","receivedAt":"2008-05-25T18:22:56Z","isPatch":false,"sender":{"key":"blix@sophiasuchtig.com","avatar":null},"body":"On Sun, May 25, 2008 at 4:23 AM, Jan Krueger wrote:\n> Hi,\n>\n\nHey.\n> allow me to play the devil's advocate here.\n>\n> Your approach is to combine different concepts that are similar and can\n> be used to do the same thing but in completely different ways. Wouldn't\n> this actually create more confusion than keeping these concepts\n> separate? Examples follow.\n\nI think it is highly dependent on how you organize it.\n\n>> The idea is that there should be one fairly obvious way to do\n>> something. If you have that then there is less confusion, especially\n>> when someone asks for help. Plus, if there is one fairly obvious way\n>> to do something, then people will need to ask for help less often.\n>\n> If people didn't ask things like \"how do I delete a file\", I'd be more\n> inclined to believe that. ;)\n>\n> Now, on to the fun part.\n>\n>> * commit = commit + push + stash + init\n>> push: This is here because it fits the traditional notion\n>> of what a commit does, which is to send a commit to the central\n>> server. I think of it as \"I am committing my\n>> changes to the remote repository.\n>\n> The problem I see there is that it will be difficult to include the\n> part of push that sends several commits at once. It is a very common\n> workflow to create a series of local commits, test them, possibly\n> rewrite them in several ways, and finally push the entire set. To have\n> your combined command do that, you'd need something like \"pyt commit\n> --to-remote --use-new-local-commits\". Is that better than \"pyt\n> push\" (and does describing this as \"committing\" actually make sense)? I\n> think not. It's sacrificing convenience and sense for reducing the\n> visible number of commands.\n\nI have responded to most of this in other mails, but I think it bears\nrepeating. In most cases, when combining commands, it should be\npossible to do so without adding a ton of flags. Otherwise, you are correct,\nit would not help anything. In some cases it does make sense to add a flag\nto mimic another command.\n\nTake cherry/cherry-pick for example. These commands are related even\nthough they don't do the same thing. Because they are useful in combination\nit makes some sense (to me) that I would ask the cherry command both for\n\"what is pickable\" and to actually do the picking. Does that make sense?\nOf course you would do this with a flag.\n\nBut onto the current example. Try and the command working like this...\n\npyt ci [what to checkin] [where to checkin to]\n\n[what to commit] defaults to the changes in your working directory. It can\nalso be a subset of these. In this case [where to checkin to] would most\nlikely be the local branch. Whether it is allowed to checkin directly to a\nremote repository is not something I am convinced about one way or the\nother.\n\nNow if you look at at that it is possible to write.\n\npyt ci branch:foo remote:origin:foo\n\nNo flags are needed, and it could probably be simplified to\n\npyt ci foo remote:origin:foo\n\nor even\n\npyt ci foo origin:foo\n\ndepending on how much mind reading we want to do. Personally\nI see that as just as simple as the git equivalent without the need of\nan added command.\n\n>> stash: What is stash but a temporary commit (not on the\n>> branch)?\n>\n> This is correct, but only technically. In fact, a commit is something\n> that you'll typically share with others, whereas a stash is not. This\n> makes me doubt it's helpful to combine both.\n\nAgain let us think of this as\n\npyt ci [what to checkin] [where to checkin to]\n\nif I then say\n\npyt ci stash:[name]\n\nI am saying [what to checkin] is the default (changes in the working set)\nand [where to checkin to] is the stash. This, again makes sense to me\nand you would later\n\npyt co stash:\n\nto get it back.\n\nIt seems to be nicely symmetric.\n\n>> * checkout = checkout + clone + branch + remote\n>\n> Checkout already has a doubtful duality: it can either switch branches\n> or check out a specific version of a single file. I don't think\n> capitalizing on the 'switch branches' concept while keeping the other\n> function is a good idea. At the very least, consider splitting \"fetch\n> other version of this file\" into a separate command.\n\nYou could be right about that, the checkout files functionality might\nfit better in the \"recover\" command. It makes language sense as\nwell, if you catch my meaning. Meaning that when I checkout a file\nI could say to myself \"i want to recover the version of the file from\nX commit.\"\n\n> I can see another source of confusion here: with this, checkout can\n> either create a new repo or a new branch in the same repo. In other\n> words, what it does depends on the context you call it in. This is a\n> no-no in interface design.\n\nActually, I was suggesting that \"checkin\" would incorporate the init\ncommand, not \"checkout.\" The idea being that you can just skip\nthe init step. I don't see this as being much different from\n\"git clone\" which could be seen as short for\n\ngit init && git pull \n\nexcept now it would be\n\ngit init && git commit ...\n\n> Finally, \"remote\" could just as well go with pull or push (which is\n> what it's actually used for in practice). The act of defining or\n> removing a remote is misplaced here since it has nothing to do with\n> checking anything out.\n\nPlease look at the following example and tell me if it makes more\nsense.\n\nAgain, we define checkout as...\n\npyt co [what do i want to checkout] [where do i want to checkout to]\n\nso if I say\n\npyt co git://foo.com/bar.git mybar\n\nthis would translate to\n\ngit remote add -f mybar git://foo.com/bar.git\ngit fetch mybar\n\nI have checked git://foo.com/bar.git to refs/remotes/mybar and as a\nconvenience I have set up tracking for you.\n\nAny pull/fetch/merge done after this could take advantage of the\nremote having been set up.\n\n>> gc = clean + gc + prune + repack\n>\n> See Jakub's comment about that. I strongly agree with him.\n\nEr, ok. I am actually not sure that Jakub and I disagree on this point.\nHe says prune and repack are already absorbed by gc and he says\nthat clean could be seen as a special case of gc. Perhaps I\nmisunderstood him?\n\n>> * pull = pull, fetch, merge\n>\n> Unlike what Jakub says, I can imagine this working well in the\n> distributed case. It could be a command that does both fetch and merge\n> by default and you can switch off either. It would make little sense\n> when merging a number of local branches, however.\n>\n>> revert = reset + reflog\n>\n> Keep in mind that you need to stick git-revert somewhere, too.\n>\n>> (still revert)\n>> I was thinking of calling this command \"recover\" instead of\n>> revert, which I still think might describe what I want to do\n>> and might tell you why I think that reflog is something to\n>> combine here. \"revert --what-can-i-revert-to\" would show\n>> the output of reflog.\n>\n> Another source of confusion, since I almost never use the reflog for\n> git-reset. I almost always use a commit ID or something like HEAD^, or\n> no argument at all (mostly for reset --hard).\n\nI have decided on --show-reflog to try and reduce any potential confusion.\nDoes that sound better? Please look at the help from the following\nfile and let me know if you think that is still confusing.\n\nhttp://gitorious.org/projects/pyrite/repos/blixs-clone/blobs/wip/pyrite/standard/recover.py\n\nAll that aside, how does this sound? A revert/recover command that\ndoes the following, it can do a \"git reset --hard\" to revert your current\nchanges. If you want to revert just one or more files then it would\nevaluate out to be \"git checkout HEAD -- ...\" But it could\nrecover to a previous state by giving it a commit id. Then have a\nseparate reverse-commit command that does what git-revert does.\nPart of the reason I think this is useful is that \"revert\" means different\nthings to different people, but using \"recover\" and \"reverse-commit\"\nmake more sense. Also, it avoids the confusion you were talking about\nearlier with checkout being too overloaded with the file stuff and the\nbranch stuff.\n\n>> * track = add/addremove\n>\n> That would only make sense if you hide the index completely. I think\n> that's a bad idea, because the index is a really powerful thing. At the\n> very least, add -i gets impossible if there's no way of influencing the\n> index directly.\n\nI like having my cake and eating it too. I intend to hide the index AND\nlet the user take advantage of it. I intend to do this by postponing\nits use until commit time, at which point the user would have the\noption of being --picky about what they want to commit. At that point\nI would do something like \"git add -i\" or \"git add -p\" to let them\nchoose. This lets them do partial commits while never having to\nthink about whether they have staged the right information (in the\nnormal case).\n\n> It would be a lot better to keep commit -a (and perhaps hint at it if\n> commit is called with an unchanged index) and define something like the\n> following:\n>\n> * stage (or record, take, use) -- same as git-add.\n> * remove (rm) -- same as git-rm. Probably good to rename --cached.\n> * unstage (or unrecord) -- revert index to version in last commit.\n\nI don't quite follow, perhaps an example would make things clearer?\n\n[regarding revision number]\n>> They are useful for a different purpose. If I say master~5 today it\n>> probably won't yield the same commit tomorrow. while 6450:master\n>> would.\n>\n> That's right, but keep in mind that revision numbers will probably make\n> people think revision numbers are global, e.g. \"hey Bill, check out\n> revision 3488 I committed today\" (and Bill gets it as 3754). The\n> background of either CVS or SVN would encourage this.\n\nPlease read my other mails, I address this a couple times. Other\nDVCSs make great use of revision numbers without the property you\ntalk about. They understand that these numbers aren't necessarily\nportable like that. However, once a commit is in a branch, it will\nalways have the same position in *that* branch.\n\n> Also, 6450:master, as a syntax, doesn't cut it. What if in the past of\n> master, a merge commit with seven parents happened? It's impossible to\n> figure out which parent to follow. You'd have to write something like\n> 45;1:357,4:774 (go back 45 commits, take parent 1, go back 357 commits,\n> etc.). Just numbering all commits in master's past according to\n> depth-first search, on the other hand, will just make revision numbers\n> very confusing.\n\nThis is just the current git syntax back to front. If you read my mail you\nsee that I define it according to --topo-order which makes a consistent\nordering of the parents.\n\n> Something else to consider is that revision numbers are hardly better\n> to remember than (abbreviated) commit IDs. Consider KDE's SVN repository\n> with (currently) 812270 revisions...\n\nHeh, like I said, *I* don't need them, *I* like sha1s just fine. For whatever\nreason, other people are scared of the sha1s, so lets give them some\ntraining wheels until they are more comfortable.\n\n>> I just put this in because I have seen several people ask for it on\n>> the mailing list recently. I thought to myself, that they COULD have\n>> it if they really wanted.\n>\n> But with a number of important disadvantages. Sometimes it really is\n> better not to have everything you want.\n>\n> In conclusion, your goal is a good one, but it's something that\n> requires a lot of very careful consideration. To name just one thing,\n> you need to make it consistent, clean, and still powerful enough to not\n> stand in the way of moderately (un)common tasks.\n\nI agree completely. This thread has been good on many levels, I has\ngiven me a lot to think about and I have refined my ideas quite a bit\nand got some very helpful suggestions. All the things you state\nhere are goals of mine.\n\n> I believe there is a bit of a tendency in your approach to emulate\n> commands of other VCS, and that's not the right way to go if you ask me.\n> If I did something like pyt (and I won't lie, I have put some thought\n> into it, including writing down a couple of ideas), I would start with a\n> clean slate and design something that really makes sense (which neither\n> the current git nor any other existing interface stacked on top of it\n> can really deliver). David Roundy did this well for darcs, I think: a\n> great number of commands have different names than in the classic VCS,\n> but they all make a lot of sense. Still, again, darcs's commands\n> wouldn't work that well for git; both systems are just too different.\n\nTo be honest, my creativity is limited. I am good at taking an existing\nidea and making a new (possibly improved) application/implementation\nof it. If you have *new* ideas about this I will be happy to hear them.\n\n> Something else that's worth considering is that an interface to git is\n> not just about reshuffling commands; it's also about behaviour. For\n> example, submodules as they currently are are a bit hard to use\n> correctly (from what I've read on IRC; I haven't used them myself yet),\n> and refspecs are rather non-intuitive to use (especially push :foo).\n>\n> It'll be interesting to see how the various existing alternative\n> interfaces to git will address all these problems.\n\nI really haven't thought about submodules yet. If you have some\ninterface ideas I would love to hear them. One think I would like\nfrom submodules is for them to remember where they were on a\nspecific branch/commit. So if I check out X, the submodules are\nchecked out to wherever they were when X was checked in. I\ndon't use submodules (although I plan to) but I hear that is a\nproblem.\n\nThanks for the input.\n\n-Govind\n"},{"id":"77716","messageId":"5d46db230805251203y6208198dldcaf2c4e7d973a3c@mail.gmail.com","threadId":"13630","inReplyTo":"200805251335.36530.jnareb@gmail.com","subject":"Re: [PYRITE] Status update and call for information.","fromName":"Govind Salinas","fromEmail":"blix@sophiasuchtig.com","sentAt":"2008-05-25T19:03:37Z","receivedAt":"2008-05-25T19:03:37Z","isPatch":false,"sender":{"key":"blix@sophiasuchtig.com","avatar":null},"body":"Trimming attributions, as they are getting hairy.\n\n2008/5/25 Jakub Narebski :\n> \"Govind Salinas\" writes:\n>>\n>> 1) Reduce the number of commands.\n[snip]\n>> To answer your question a little better, I am looking at it like this:\n>> The predominant action is, as you say, going to be \"I want to create a\n>> branch so that I can start working on something.\" While I respect that\n>> you might want to create a branch and not start doing something\n>> *right away*, I think this is less likely. So...\n>>\n>> pyt co\n>> this lists stuff you can checkout by which we mean local branches.\n>\n> Note that \"git checkout\" defaults to HEAD.\n\nI do not see that as an issue. I do not intend to have command\ncomputability in that fashion. However, if there is a good reason\nfor the default to be HEAD, then I would like to know.\n\n>> pyt co -r\n>> this lists remote stuff you can check out, such as remote tracking\n>> branches and the remotes themselves.\n>>\n>> pyt co -a\n>> lists both of the above, maybe tags too.\n>\n> These three are all about listing metadata, refs to be more exact.\n> 'checkout' is IMHO all about getting given state recorded in repository\n> (or, in git case, also from index) into working area, i.e. in a way\n> opposite to 'commit' or 'checkin', at least as far as it is possible.\n> So I think this is in the same league as using 'less' to view contents\n> (listing) of a directory. This IMHO does not reduce confusion, but\n> adds to it.\n\nI have a theme in my commands, it is one that is in git too to some\nextent. The theme is that a command should provide both the\naction and the information needed to carry out that action, making\nit self contained. Your argument could be used to argue that\n\"git branch\" needs to be split up into \"git list-branch\" and\n\"git branch.\" Now if you are saying that I should make it\n\"pyt co -l\" to list what can be checked out, then I would think about\nthat, but I kind-of like the \"git branch\" way of doing it over the\n\"git-tag\" way. More a matter of taste in my opinion.\n\n> Also note that git-branch is used to create and list branches\n> (unfortunately it uses -l for --enable-reflog and not for --list as\n> other commands like git-tag do), but can be also used to delete and\n> rename branches. Do you want to stuff this functionality in \"pyt co\"?\n\nYes and no, in that order. Delete should be handled, rename is rare\nenough that I would ask people to spell it\n\npyt co -n newname oldname\npyt co -d oldname\n\n>> pyr co \n>> the user wants to checkout something that isn't local. So we do\n>> a git remote add -t -f followed by\n>> checkout /\n>> There would probably be variations/flags to get different functionality.\n>\n> Please note that result of this is very, very different from ordinary\n> checkout. Either it doesn't touch working area if it is equivalent\n> of git-fetch, or can result in conflicts and not a clean state if\n> it is equivalent of git-pull.\n\nMy meme for checkout/checkin is..\n\npyt checkout/in [what to checkout/in] [where to checkout/in to]\n\nThis would be a \"set up remote & fetch\", which means to me\n\"check out the to this remote tracking branch\". It is hopefully\na bit clearer since I have decided on making pull/fetch/merge into\na separate command following some of the earlier comments\nin this thread.\n\n>> pyt co [something=HEAD] [--] ...\n>> should be obvious\n>\n> But it isn't obvious.\n>\n> Let me explain. Because in git commits are always whole-tree\n> snapshots, and usually (read: almost always) it makes sense to have\n> whole-tree commits in an SCM, this cannot switch branches. So for\n> example there is a question if it is a separate mode (yet another\n> oveloading of 'pyt co' operator) of checkout changing working area\n> without changing current branch (something like svn-revert,\n> or hg-undo), or would it make HEAD detached and result in something\n> like not yet implemented \"git cherry-pick -- \".\n\nit is \"git checkout [somthing=HEAD] -- ...\" thats why I thought it\nwould be obvious. Having said that, the other option is to put this in the\nrecover/revert command which I have outlined in another mail. Basically\nthe recover command would be \"git reset --hard [somecommit=HEAD]\"\nwith the ability to specify files rather. Specifying files would mean to\n\"git checkout\" the *just* files instead of the reset. Does that sound\nbetter?\n\n>>>> I don't think any commonly used SCM unites 'clone', 'branch', and\n>>>> 'checkout' functionality under the same name. This approach seems\n>>>> to be more confusing than helpful.\n> [...]\n>> See above, they in fact do. It struck me as odd too, because I had\n>> started with git. After thinking about it for a while, I saw advantages\n>> to it.\n>\n> And it looks like you gone to far in the reducing number of commands\n> direction and do not see disadvantages of heavily overloaded, DWIM-ming,\n> doing multiple different things depending on options commands. If you\n> don't like large number of commands (is 30+ large number?), use GUI!\n\nIt isn't set in stone, when I started this thread, I was thinking about 24 total\ncommands. Based on feedback it is 26. Also, using a gui only reduces\ntyping, the gui needs to carry forward the concepts of the underlying\nsystem or things *really* won't make sense.\n\n> What you need is to have some _users_ to tell you if you do with\n> Pyrite in good direction. Or at least analysis of common git workflows\n> and how they could be improved...\n\nI agree 100%. I currently am basing this on the comments that I have\nheard/read from people just starting to use git and other systems as\nwell as reviews I have seen posted. I would very much like it if people\nwould send me comments on their experiences, both negative and\npositive, while starting to use git and other DSCMs and why they\ndecided to stick with their result.\n\nPeople seem to *like* the bzr and hg interfaces, they seem to\ntolerate the git one because git has better features. That is the\nimpression I get from doing my reading.\n\n-Govind\n"}]}