{"thread":{"id":"11016","subject":"If you would write git from scratch now, what would you change?","startedAt":"2007-11-25T21:48:27Z","lastAt":"2007-12-04T11:00:42Z","messageCount":83,"participants":["Jakub Narebski","Pierre Habouzit","Steven Walter","Junio C Hamano","Adam Roben","Carlos Rica","Daniel Barkalow","Andy Parkins","Jon Smirl","Benoit Sigoure","David Kastrup","Jan Hudec","Dana How","Marco Costalba","Nicolas Pitre","Michael Poole","Wincent Colaiuta","Johannes Schindelin","Shawn O. Pearce","Steven Grimm","Andreas Ericsson","Linus Torvalds","Jing Xue","Sergei Organov","Jason Sewall"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"60875","messageId":"200711252248.27904.jnareb@gmail.com","threadId":"11016","inReplyTo":null,"subject":"If you would write git from scratch now, what would you change?","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-11-25T21:48:27Z","receivedAt":"2007-11-25T21:48:27Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"If you would write git from scratch now, from the beginning, without \nconcerns for backwards compatibility, what would you change, or what \nwould you want to have changed?\n\n\nYes, I know, I know. \"Worse is better\". It is better to release early \nand get feedback what is really needed, as opposed to what do you think \nis needed.\n\nI think git is a wonderful example of \"evolved\" software, evolving \npractically from the very beginnings.\n\n-- \nJakub Narebski\nPoland\n"},{"id":"60879","messageId":"20071125222314.GC21121@artemis.corp","threadId":"11016","inReplyTo":"200711252248.27904.jnareb@gmail.com","subject":"Re: If you would write git from scratch now, what would you change?","fromName":"Pierre Habouzit","fromEmail":"madcoder@debian.org","sentAt":"2007-11-25T22:23:14Z","receivedAt":"2007-11-25T22:23:14Z","isPatch":false,"sender":{"key":"madcoder@debian.org","avatar":"https://avatars.githubusercontent.com/u/44708?v=4"},"body":"On Sun, Nov 25, 2007 at 09:48:27PM +0000, Jakub Narebski wrote:\n> If you would write git from scratch now, from the beginning, without \n> concerns for backwards compatibility, what would you change, or what \n> would you want to have changed?\n\n * reset/checkout/revert. The commands to wonderful things, but this UI\n is a mess for the newcomer.\n\n * pull/fetch/push: I would have had pull being what fetch is, and\n added some --merge option to actually \"do the obvious merge\". But\n pull encourage \"bad\" behavior from the user, and confuses newcomers\n a lot.\n\n * I would have hidden plumbing more, using a really distinguished\n namespace (stupid example, there are probably better ways, but we\n could have git-_rev-parse or git-plumbing-rev-parse instead of\n git-rev-parse) so that it's clear to the user that those are really\n internal commands, and that he doesn't need to understand them.\n\n This is a big issue with git: the list of commands of git is the top\n of the iceberg from the UI point of view. People _feel_ they are\n comfortable with a tool if they get say 75% of the UI. I don't say\n it's true that understanding 75% of the UI makes you a $tool expert,\n but it's how people feel it. With git, 75% of the commands (and\n don't get me started with the options ;P) is a _lot_. bzr is way\n better at that game: there are at least as many commands, but those\n are completely hidden to the user.\n\n Of course having our guts easy to grok and find is a big advantage\n for the git gurus. But for the newcomer it's a disconcerting.\n\n There is probably more things I'd change, but those were the first UI\nrumblings from me :)\n-- \n·O· Pierre Habouzit\n··O madcoder@debian.org\nOOO http://www.madism.org\n"},{"id":"60896","messageId":"20071126012837.GA5402@dervierte","threadId":"11016","inReplyTo":"20071125222314.GC21121@artemis.corp","subject":"Re: If you would write git from scratch now, what would you change?","fromName":"Steven Walter","fromEmail":"stevenrwalter@gmail.com","sentAt":"2007-11-26T01:28:37Z","receivedAt":"2007-11-26T01:28:37Z","isPatch":false,"sender":{"key":"stevenrwalter@gmail.com","avatar":"https://avatars.githubusercontent.com/u/79127?v=4"},"body":"On Sun, Nov 25, 2007 at 11:23:14PM +0100, Pierre Habouzit wrote:\n> On Sun, Nov 25, 2007 at 09:48:27PM +0000, Jakub Narebski wrote:\n> > If you would write git from scratch now, from the beginning, without \n> > concerns for backwards compatibility, what would you change, or what \n> > would you want to have changed?\n> \n> * reset/checkout/revert. The commands to wonderful things, but this UI\n> is a mess for the newcomer.\n\nHeartily seconded. I think checkout is the most egregrious of the\nthree. git-checkout can be used to:\n\n * Switch branches\n * Create a branch\n * Change the state of all files to a particular commit\n * Change the state of a particular file to that of the index\n * Change the state of a particular file (and index) to a particular\n commit\n\nTo makes things more complicated, several of these tasks can be done\nwith other commands. Short of rewriting git from scratch, what can be\ndone to simplify the many-to-many mapping of tasks to commands?\n-- \n-Steven Walter \nFreedom is the freedom to say that 2 + 2 = 4\nB2F1 0ECC E605 7321 E818 7A65 FC81 9777 DC28 9E8F \n"},{"id":"60908","messageId":"7vejedh6xl.fsf@gitster.siamese.dyndns.org","threadId":"11016","inReplyTo":"20071126012837.GA5402@dervierte","subject":"Re: If you would write git from scratch now, what would you change?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-26T06:11:50Z","receivedAt":"2007-11-26T06:11:50Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Steven Walter writes:\n\n> Heartily seconded. I think checkout is the most egregrious of the\n> three. git-checkout can be used to:\n>\n> * Switch branches\n> * Create a branch\n> * Change the state of all files to a particular commit\n> * Change the state of a particular file to that of the index\n> * Change the state of a particular file (and index) to a particular\n> commit\n\nCome on. The second one is just to give a short-hand side-effet for\ncommonly used operation and you do not have to use it nor learn it.\n\nAlso, you have written the last three in a more confusing way than it is\nnecessary. They are all the same thing but with variations --- your way\nof writing them is like enumerating \"change the state of files whose\nname starts with A\", \"change the state of files whose name starts with\nB\", etc. as if they are distinctly different and confusing operations.\n\nLet's clear the confusion. Although it is not bad like the above\n\"random 5 different operations\", checkout does serve 2 quite different\npurposes:\n\n (1) checkout a revision.\n\n This primarily affects the notion of where your HEAD is. Is it\n pointing at a branch, or detached at a particular commit? In\n either case, the objective from the user's point of view here is \"I\n want to change on which commit and/or branch I'd build the next\n commit, if I were to issue git-commit command\".\n\n \"I started modifying but realized that I wanted to build not on top\n of master but a separate topic\", is a typical use case, and this\n form will let you take your local changes with you exactly for this\n reason.\n\n Obviously when people say \"I checkout this commit\", they mean the\n state of the work tree and they mean the whole tree. It is\n hopefully clear that is what you are doing from the fact that you\n do not give any pathspec to the command to trigger this mode of\n operation.\n\n (2) checkout selected paths out of a commit (or the index).\n\n \"I screwed up. I want to start over modifications to these files\n from the state of the previous commit (or the last state I\n staged).\" is a typical use case for this mode. For this reason,\n the named paths are updated in the work tree and the work tree and\n the index are made to match.\n\n Again, it hopefully is clear enough that you need to give some\n pathspec to it for the operation to make sense, if you understand\n the purpose of the command. Like \".\" to mean the whole tree, \"*.c\"\n to mean all C files, or \"directory/\" to mean everything underneath\n it.\n\nSo yes, it does two quite different things, and that's mostly because\nthe verb \"to check out\" has overloaded meanings.\n\nHopefully it is clear which one you are using by thinking about the\nreason WHY you are \"checking out\", and by looking at the way you form\nthe command line.\n"},{"id":"60910","messageId":"474A698A.70100@apple.com","threadId":"11016","inReplyTo":"7vejedh6xl.fsf@gitster.siamese.dyndns.org","subject":"Re: If you would write git from scratch now, what would you change?","fromName":"Adam Roben","fromEmail":"aroben@apple.com","sentAt":"2007-11-26T06:36:58Z","receivedAt":"2007-11-26T06:36:58Z","isPatch":false,"sender":{"key":"aroben@apple.com","avatar":"https://gravatar.com/avatar/9d3697e1de53890adf241331f4b970bdd2b18962b2ff0b8028ebb00e085807f8?d=mp&s=160"},"body":"Junio C Hamano wrote:\n> Steven Walter writes:\n> \n>> Heartily seconded. I think checkout is the most egregrious of the\n>> three. git-checkout can be used to:\n>>\n>> * Switch branches\n>> * Create a branch\n>> * Change the state of all files to a particular commit\n>> * Change the state of a particular file to that of the index\n>> * Change the state of a particular file (and index) to a particular\n>> commit\n>> \n>\n> Come on. The second one is just to give a short-hand side-effet for\n> commonly used operation and you do not have to use it nor learn it.\n> \n\nI think the overwhelming majority of git users learn `git checkout -b`. \nThe cases where you do want to switch to a branch you just created seem \nfar more common than the cases where you don't (particularly for new \nusers), which is the whole reason the -b option exists in the first \nplace. So I don't think it's reasonable to say \"you can choose not to be \nconfused by ignoring this incredibly useful command.\"\n\n> Let's clear the confusion. Although it is not bad like the above\n> \"random 5 different operations\", checkout does serve 2 quite different\n> purposes:\n>\n> (1) checkout a revision.\n> (2) checkout selected paths out of a commit (or the index).\n> \n\nGiven the above, I'd argue that it serves 3 purposes:\n\n (1) check out a revision\n (2) check out selected paths out of a commit (or the index)\n (3) start working on a new branch\n\nIt's true that (1) and (3) are very closely related, but I think in the \nminds of many git users (particularly new ones) they are distinct. (2) \nreally seems the most out of place here, and has the most potential for \nfinding a new home (perhaps within git-reset).\n\n-Adam\n"},{"id":"60939","messageId":"1b46aba20711260732v297c5c35kbd007b9f13f351ff@mail.gmail.com","threadId":"11016","inReplyTo":"474A698A.70100@apple.com","subject":"Re: If you would write git from scratch now, what would you change?","fromName":"Carlos Rica","fromEmail":"jasampler@gmail.com","sentAt":"2007-11-26T15:32:29Z","receivedAt":"2007-11-26T15:32:29Z","isPatch":false,"sender":{"key":"jasampler@gmail.com","avatar":null},"body":"On Nov 26, 2007 7:36 AM, Adam Roben wrote:\n> Junio C Hamano wrote:\n> > Steven Walter writes:\n> > Let's clear the confusion. Although it is not bad like the above\n> > \"random 5 different operations\", checkout does serve 2 quite different\n> > purposes:\n> >\n> > (1) checkout a revision.\n> > (2) checkout selected paths out of a commit (or the index).\n> >\n>\n> Given the above, I'd argue that it serves 3 purposes:\n>\n> (1) check out a revision\n> (2) check out selected paths out of a commit (or the index)\n> (3) start working on a new branch\n>\n> It's true that (1) and (3) are very closely related, but I think in the\n> minds of many git users (particularly new ones) they are distinct.\n\nI think this is mostly due to the idea of a branch as a separated box\n(like a directory) instead of a line of development like the notion which\ncomes from thinking in a branch as the place where HEAD is pointing to.\n\nPersonally, it is always difficult for me to understand git as a whole,\nbecause I'm not sure what is the common use case for each command in\nthe most-usual-way-of-doing-the-things when using git, despite of having\nlong and complete documentation for each individual command. The question\nis if we can give the power of git to their users in the same way they think,\nor how git could be able to teach their users to think in the way it works.\n\nAn idea would be to study (and document) the most successful\nuse cases that git supports and check if it is already providing\nunique and/or clear commands for them.\n\n--Carlos\n"},{"id":"60941","messageId":"Pine.LNX.4.64.0711261111260.32410@iabervon.org","threadId":"11016","inReplyTo":"1b46aba20711260732v297c5c35kbd007b9f13f351ff@mail.gmail.com","subject":"Re: If you would write git from scratch now, what would you change?","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2007-11-26T16:40:08Z","receivedAt":"2007-11-26T16:40:08Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Mon, 26 Nov 2007, Carlos Rica wrote:\n\n> On Nov 26, 2007 7:36 AM, Adam Roben wrote:\n> > Junio C Hamano wrote:\n> > > Steven Walter writes:\n> > > Let's clear the confusion. Although it is not bad like the above\n> > > \"random 5 different operations\", checkout does serve 2 quite different\n> > > purposes:\n> > >\n> > > (1) checkout a revision.\n> > > (2) checkout selected paths out of a commit (or the index).\n> > >\n> >\n> > Given the above, I'd argue that it serves 3 purposes:\n> >\n> > (1) check out a revision\n> > (2) check out selected paths out of a commit (or the index)\n> > (3) start working on a new branch\n> >\n> > It's true that (1) and (3) are very closely related, but I think in the\n> > minds of many git users (particularly new ones) they are distinct.\n> \n> I think this is mostly due to the idea of a branch as a separated box\n> (like a directory) instead of a line of development like the notion which\n> comes from thinking in a branch as the place where HEAD is pointing to.\n> \n> Personally, it is always difficult for me to understand git as a whole,\n> because I'm not sure what is the common use case for each command in\n> the most-usual-way-of-doing-the-things when using git, despite of having\n> long and complete documentation for each individual command. The question\n> is if we can give the power of git to their users in the same way they think,\n> or how git could be able to teach their users to think in the way it works.\n> \n> An idea would be to study (and document) the most successful\n> use cases that git supports and check if it is already providing\n> unique and/or clear commands for them.\n\nI think that part of git's oddity comes from the fact that the UI is \norganized around use cases rather than commands. That is, for each thing \nthat people commonly do, the sequence of commands is as short as possible \nand each of the names makes sense in the context of this sequence. But \nthen the commands and options, in the list of commands and options outside \nof the context of a use case, don't make any sense as a whole.\n\nIt's like trying to document the \"take\" command in a text adventure, where \n\"take [noun]\" means to pick it up, \"take off [noun]\" means to remove it as \nclothing, and \"take off\" means to leave.\n\nThere's a set of primitive git operations, but the git commands aren't \nthose; the git command schemas (not just the \"command\" part, but the type \nof arguments following it) are semi-natural-language interfaces to \ncollections of primitive operations, and are set up to have a core \"what \nthe user is saying to do\" and all of the reasonable analogous extensions \nto that. This means that the very same result can often be reached with \nmultiple entirely different commands, because there are different ways of \nconceptualizing what you're doing that overlap. (E.g., \"git checkout HEAD \n.\" will check out the current directory from the current branch, \ndiscarding local changes; \"git reset --hard HEAD\" will move the current \nbranch to its current state, bringing the working copy in line with it as \nwell; both of these have the effect of discarding all local changes while \nkeeping the branch state the same, but that's just because the aspects of \nthe two operations which are different don't matter with those particular \narguments)\n\nI think git's UI design is, by and large, very good, but I'm not sure how \nto document it so as to make it easy to learn, aside from giving a quick \nexplanation of how to use reflogs to recover from mistakes and telling \nusers to just try stuff in their local repository.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"60942","messageId":"fiet88$68n$1@ger.gmane.org","threadId":"11016","inReplyTo":"200711252248.27904.jnareb@gmail.com","subject":"Re: If you would write git from scratch now, what would you change?","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-11-26T16:46:00Z","receivedAt":"2007-11-26T16:46:00Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"Jakub Narebski wrote:\n\n> If you would write git from scratch now, from the beginning, without\n> concerns for backwards compatibility, what would you change, or what\n> would you want to have changed?\n\nErm... (it's much harder to come with lists like these lately :-))\n\n - \"index\", \"cached\" and \"stage\" are a definite source of confusion\n - \"git add\" and \"git rm\" would be nicer as \"git stage\" and \"git unstage\"\n (or something similar)\n - libgit would have come first\n - \"git revert\" should be called \"git invert\"\n - \"git revert\" would (maybe) be \"git reset\"\n - \"git clone\" wouldn't exist\n - \"git-gui\" would be written in Qt (ducks)\n - git-apply et al wouldn't be a disaster when the log message contains a \n diff (change to git diff format?)\n - empty directories in the repository (ducks again)\n\n\n\nAndy\n\n-- \nDr Andy Parkins, M Eng (hons), MIET\nandyparkins@gmail.com\n"},{"id":"60945","messageId":"9e4733910711260848h29bf96c0x961c09cbe600936b@mail.gmail.com","threadId":"11016","inReplyTo":"200711252248.27904.jnareb@gmail.com","subject":"Re: If you would write git from scratch now, what would you change?","fromName":"Jon Smirl","fromEmail":"jonsmirl@gmail.com","sentAt":"2007-11-26T16:48:20Z","receivedAt":"2007-11-26T16:48:20Z","isPatch":false,"sender":{"key":"jonsmirl@gmail.com","avatar":"https://gravatar.com/avatar/cff3bf5bfdfa6708b905712ff91f0f9b8aaca161659f38c02b787920d5d28b7e?d=mp&s=160"},"body":"On 11/25/07, Jakub Narebski wrote:\n> If you would write git from scratch now, from the beginning, without\n> concerns for backwards compatibility, what would you change, or what\n> would you want to have changed?\n\nI would sit down and carefully design the command syntax. git's\nbiggest criticism is that it is hard to use and this is mainly caused\nby the seemingly very complex commands. Much of this complexity could\nbe hidden from the user.\n\nI'd also integrated a patch management system like stgit. I'm using\nstgit commands for 90% of my tasks and it has a different syntax than\ngit (its trying to fix some of the problems).\n\nMost current git users are knowledgeable programmers and could handle\na rework of the git command syntax. The sooner the syntax is reworked\nthe better in my opinion. The current syntax grew organically as we\nlearned what git needed. Now's the time to use this knowledge and\ndesign an optimal command structure.\n\n-- \nJon Smirl\njonsmirl@gmail.com\n"},{"id":"60947","messageId":"2A34D324-48A4-49EF-9D4E-5B9469A0791D@lrde.epita.fr","threadId":"11016","inReplyTo":"fiet88$68n$1@ger.gmane.org","subject":"Re: If you would write git from scratch now, what would you change?","fromName":"Benoit Sigoure","fromEmail":"tsuna@lrde.epita.fr","sentAt":"2007-11-26T17:10:10Z","receivedAt":"2007-11-26T17:10:10Z","isPatch":false,"sender":{"key":"tsunanet@gmail.com","avatar":"https://avatars.githubusercontent.com/u/128281?v=4"},"body":"On Nov 26, 2007, at 5:46 PM, Andy Parkins wrote:\n\n> - libgit would have come first\n\nI warmly second that.\n\n> - \"git revert\" should be called \"git invert\"\n> - \"git revert\" would (maybe) be \"git reset\"\n\nBut here, I have to disagree. Why would you want to call \"git- \nrevert\" \"git-reset\"?\n\nI know it's annoying that commands with the same name do different \nthings in SVN/CVS but I don't think it's a reason to necessarily \nadapt to them. There are plenty of misnomers already anyway \n(checkout, commit, add).\n\nWhile we're discussing bad names, as someone already pointed out, I \nagree it's sad that \"git push\" is almost always understood as being \nthe opposite of \"git pull\".\n\n-- \nBenoit Sigoure aka Tsuna\nEPITA Research and Development Laboratory\n"},{"id":"60948","messageId":"858x4l2apc.fsf@lola.goethe.zz","threadId":"11016","inReplyTo":"200711252248.27904.jnareb@gmail.com","subject":"Re: If you would write git from scratch now, what would you change?","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-11-26T17:11:43Z","receivedAt":"2007-11-26T17:11:43Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Jakub Narebski writes:\n\n> If you would write git from scratch now, from the beginning, without\n> concerns for backwards compatibility, what would you change, or what\n> would you want to have changed?\n\nGet rid of plumbing at the command line level. It is confusing to\nusers, and command line arguments, exec calls and I/O streams are not\nefficient and reasonably typed mechanisms for the kind of operations\ndone in plumbing. Instead using a good extensible portable scripting\nlanguage (I consider Lua quite suitable in that regard, but it is\nconceivable that something with a native list type supporting easy\nsorts, merges and selections could be more efficient) and implementing\nplumbing in that or in C would have been preferable for creating the\nporcelain.\n\nThat would keep plumbing out of the hair of users and make it easier to\ncobble together extensions and variations with non-trivial internal\ndataflow.\n\nShell scripts have also proven to be a constant hassle with regard to\nportability and bugs (like underquoting).\n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"},{"id":"60952","messageId":"20071126185600.GA25784@efreet.light.src","threadId":"11016","inReplyTo":"2A34D324-48A4-49EF-9D4E-5B9469A0791D@lrde.epita.fr","subject":"Re: If you would write git from scratch now, what would you change?","fromName":"Jan Hudec","fromEmail":"bulb@ucw.cz","sentAt":"2007-11-26T18:56:00Z","receivedAt":"2007-11-26T18:56:00Z","isPatch":false,"sender":{"key":"bulb@ucw.cz","avatar":null},"body":"On Mon, Nov 26, 2007 at 18:10:10 +0100, Benoit Sigoure wrote:\n> On Nov 26, 2007, at 5:46 PM, Andy Parkins wrote:\n> While we're discussing bad names, as someone already pointed out, I agree \n> it's sad that \"git push\" is almost always understood as being the opposite \n> of \"git pull\".\n\nWell, it is an oposite of pull. Compared to it, it is limited in that it will\nnot do a merge and on the other hand extended to *also* be an oposite of\nfetch, but still oposite of pull is push.\n\n-- \n\t\t\t\t\t\t Jan 'Bulb' Hudec \n"},{"id":"60954","messageId":"85prxw253u.fsf@lola.goethe.zz","threadId":"11016","inReplyTo":"20071126185600.GA25784@efreet.light.src","subject":"Re: If you would write git from scratch now, what would you change?","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-11-26T19:12:37Z","receivedAt":"2007-11-26T19:12:37Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Jan Hudec writes:\n\n> On Mon, Nov 26, 2007 at 18:10:10 +0100, Benoit Sigoure wrote:\n>> On Nov 26, 2007, at 5:46 PM, Andy Parkins wrote:\n>> While we're discussing bad names, as someone already pointed out, I agree \n>> it's sad that \"git push\" is almost always understood as being the opposite \n>> of \"git pull\".\n>\n> Well, it is an oposite of pull. Compared to it, it is limited in that it will\n> not do a merge and on the other hand extended to *also* be an oposite of\n> fetch, but still oposite of pull is push.\n\nWith the same reasoning the opposite of a duck is a lobster, since a\nlobster has not only fewer wings, but also more legs.\n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"},{"id":"60956","messageId":"56b7f5510711261118m7a402beah5d9cb75c1ad10b43@mail.gmail.com","threadId":"11016","inReplyTo":"200711252248.27904.jnareb@gmail.com","subject":"Re: If you would write git from scratch now, what would you change?","fromName":"Dana How","fromEmail":"danahow@gmail.com","sentAt":"2007-11-26T19:18:41Z","receivedAt":"2007-11-26T19:18:41Z","isPatch":false,"sender":{"key":"danahow@gmail.com","avatar":null},"body":"On Nov 25, 2007 1:48 PM, Jakub Narebski wrote:\n> If you would write git from scratch now, from the beginning, without\n> concerns for backwards compatibility, what would you change, or what\n> would you want to have changed?\n\nCurrently data can be quickly copied from pack to pack,\nbut data cannot be quickly copied blob->pack or pack->blob\n(there was an alternate blob format that supported this,\n but it was deprecated). Using the pack format for blobs\nwould fix this. It would also mean blobs wouldn't need to\nbe uncompressed to get the blob type or size I believe.\n\nSo far this has prevented me from deploying git here\n(and is half the reason I have not been active recently).\nCurrently we use p4 and we have large files.\nWhen a large file is checked in (submitted),\nit is compressed *once* and sent over the network --\nthese are the only delays that end-users experience.\n\nThe equivalent operation in git would require the creation of\nthe blob, and then of a temporary pack to send to the server.\nThis requires 3 calls to zlib for each blob, which for very\nlarge files is not acceptable at my site.\n\nYes, git has much better features.\nBut 80%+ of my workgroup will not use them,\nand only notice that git is \"slower\".\n\nThanks,\n-- \nDana L. How danahow@gmail.com +1 650 804 5991 cell\n"},{"id":"60958","messageId":"e5bfff550711261125i92fb057i85d7217b18cd495d@mail.gmail.com","threadId":"11016","inReplyTo":"fiet88$68n$1@ger.gmane.org","subject":"Re: If you would write git from scratch now, what would you change?","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2007-11-26T19:25:07Z","receivedAt":"2007-11-26T19:25:07Z","isPatch":false,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On Nov 26, 2007 5:46 PM, Andy Parkins wrote:\n> Jakub Narebski wrote:\n>\n> > If you would write git from scratch now, from the beginning, without\n> > concerns for backwards compatibility, what would you change, or what\n> > would you want to have changed?\n>\n> Erm... (it's much harder to come with lists like these lately :-))\n>\n> - \"git-gui\" would be written in Qt (ducks)\n\nBut...wait...Qt would require...(I'm scared to say!)... that awful,\npainful, hopeless thing called C++. Probably you didn't mean what you\nsaid ;-)\n\n\nMarco\n"},{"id":"60959","messageId":"20071126192703.GB25784@efreet.light.src","threadId":"11016","inReplyTo":"858x4l2apc.fsf@lola.goethe.zz","subject":"Re: If you would write git from scratch now, what would you change?","fromName":"Jan Hudec","fromEmail":"bulb@ucw.cz","sentAt":"2007-11-26T19:27:03Z","receivedAt":"2007-11-26T19:27:03Z","isPatch":false,"sender":{"key":"bulb@ucw.cz","avatar":null},"body":"On Mon, Nov 26, 2007 at 18:11:43 +0100, David Kastrup wrote:\n> Jakub Narebski writes:\n> \n> > If you would write git from scratch now, from the beginning, without\n> > concerns for backwards compatibility, what would you change, or what\n> > would you want to have changed?\n> \n> Get rid of plumbing at the command line level. It is confusing to\n\nNo, please. It's extremely useful. It should be a bit more hidden, but it's\na big advantage of git that the plumbing is available.\n\n> users, and command line arguments, exec calls and I/O streams are not\n> efficient and reasonably typed mechanisms for the kind of operations\n> done in plumbing. Instead using a good extensible portable scripting\n> language (I consider Lua quite suitable in that regard, but it is\n> conceivable that something with a native list type supporting easy\n> sorts, merges and selections could be more efficient) and implementing\n> plumbing in that or in C would have been preferable for creating the\n> porcelain.\n\nPOSIX shell is really the best extensible portable scripting language\navailable for the job. Because the whipuptitude is the most important\nproperty and shell is simply best at one-liners. And since you use it\nfor regular work (running editor, compiler, git porcelain), it is the\nobvious choice for whiping up a short function.\n\n> That would keep plumbing out of the hair of users and make it easier to\n> cobble together extensions and variations with non-trivial internal\n> dataflow.\n> \n> Shell scripts have also proven to be a constant hassle with regard to\n> portability and bugs (like underquoting).\n\n-- \n\t\t\t\t\t\t Jan 'Bulb' Hudec \n"},{"id":"60960","messageId":"alpine.LFD.0.99999.0711261417580.9605@xanadu.home","threadId":"11016","inReplyTo":"858x4l2apc.fsf@lola.goethe.zz","subject":"Re: If you would write git from scratch now, what would you change?","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-11-26T19:30:19Z","receivedAt":"2007-11-26T19:30:19Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Mon, 26 Nov 2007, David Kastrup wrote:\n\n> Get rid of plumbing at the command line level.\n\nWe can't get rid of plumbing. It is part of Git probably forever and is \nreally really convenient for scripting in any language you want. \n\nThe only valid argument IMHO is the way too large number of Git commands \ndirectly available from the cmdline.\n\nThe solution: make purely plumbing commands _not_ directly available \nfrom the command line. Instead, they can be available through 'git \nlowlevel ' instead of 'git ' and only 'git lowlevel' would \nstand in your shell default path.\n\nSuch a scheme can be implemented in parallel with the current one for a \nrelease while the direct plumbing commands are deprecated in order to \ngive script authors a transition period to fix their code.\n\n\nNicolas\n"},{"id":"60961","messageId":"854pf8243i.fsf@lola.goethe.zz","threadId":"11016","inReplyTo":"alpine.LFD.0.99999.0711261417580.9605@xanadu.home","subject":"Re: If you would write git from scratch now, what would you change?","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-11-26T19:34:25Z","receivedAt":"2007-11-26T19:34:25Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Nicolas Pitre writes:\n\n> On Mon, 26 Nov 2007, David Kastrup wrote:\n>\n>> Get rid of plumbing at the command line level.\n>\n> We can't get rid of plumbing.\n\nWhat about \"at the command line level\" did you not understand?\n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"},{"id":"60962","messageId":"20071126193455.GC25784@efreet.light.src","threadId":"11016","inReplyTo":"85prxw253u.fsf@lola.goethe.zz","subject":"Re: If you would write git from scratch now, what would you change?","fromName":"Jan Hudec","fromEmail":"bulb@ucw.cz","sentAt":"2007-11-26T19:34:55Z","receivedAt":"2007-11-26T19:34:55Z","isPatch":false,"sender":{"key":"bulb@ucw.cz","avatar":null},"body":"On Mon, Nov 26, 2007 at 20:12:37 +0100, David Kastrup wrote:\n> Jan Hudec writes:\n> \n> > On Mon, Nov 26, 2007 at 18:10:10 +0100, Benoit Sigoure wrote:\n> >> On Nov 26, 2007, at 5:46 PM, Andy Parkins wrote:\n> >> While we're discussing bad names, as someone already pointed out, I agree \n> >> it's sad that \"git push\" is almost always understood as being the opposite \n> >> of \"git pull\".\n> >\n> > Well, it is an oposite of pull. Compared to it, it is limited in that it will\n> > not do a merge and on the other hand extended to *also* be an oposite of\n> > fetch, but still oposite of pull is push.\n> \n> With the same reasoning the opposite of a duck is a lobster, since a\n> lobster has not only fewer wings, but also more legs.\n\nNo.\n\nThe basic pull/push actions are:\n\ngit pull: Bring the remote ref value here.\ngit push: Put the local ref value there.\n\nAre those not oposites?\n\nThan each command has it's different features on top of this -- pull merges\nand push can push multiple refs -- but in the basic operation they are\noposites.\n\n-- \n\t\t\t\t\t\t Jan 'Bulb' Hudec \n"},{"id":"60964","messageId":"87ve7ozsz8.fsf@graviton.dyn.troilus.org","threadId":"11016","inReplyTo":"20071126193455.GC25784@efreet.light.src","subject":"Re: If you would write git from scratch now, what would you change?","fromName":"Michael Poole","fromEmail":"mdpoole@troilus.org","sentAt":"2007-11-26T19:50:35Z","receivedAt":"2007-11-26T19:50:35Z","isPatch":false,"sender":{"key":"mdpoole@troilus.org","avatar":null},"body":"Jan Hudec writes:\n\n> The basic pull/push actions are:\n>\n> git pull: Bring the remote ref value here.\n> git push: Put the local ref value there.\n>\n> Are those not oposites?\n>\n> Than each command has it's different features on top of this -- pull merges\n> and push can push multiple refs -- but in the basic operation they are\n> oposites.\n\nI think that is in absolute agreement with David: Ducks swim on the\nsurface of the water and lobsters swim underneath. Why consider the\ndifferent features on top of where they swim?\n\nThe thing about git-pull that surprises so many users is the merge.\nThere's a separate command to do that step, and git-pull had a fairly\ngood excuse to do the merge before git's 1.5.x remote system was in\nplace, but now the only really defensible reason for its behavior is\nhistory.\n\nMichael Poole\n"},{"id":"60965","messageId":"alpine.LFD.0.99999.0711261433210.9605@xanadu.home","threadId":"11016","inReplyTo":"56b7f5510711261118m7a402beah5d9cb75c1ad10b43@mail.gmail.com","subject":"Re: If you would write git from scratch now, what would you change?","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-11-26T19:52:05Z","receivedAt":"2007-11-26T19:52:05Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Mon, 26 Nov 2007, Dana How wrote:\n\n> Currently data can be quickly copied from pack to pack,\n> but data cannot be quickly copied blob->pack or pack->blob\n\nI don't see why you would need the pack->blob copy normally.\n\n> (there was an alternate blob format that supported this,\n> but it was deprecated). Using the pack format for blobs\n> would fix this.\n\nThen you can do just that for big enough blobs where \"big enough\" is \nconfigurable: encapsulate them in a pack instead of a loose object. \nProblem solved. Sure you'll end up with a bunch of packs containing \nonly one blob object, but given that those blobs are so large to be a \nproblem in your work flow when written out as loose objects, then they \ncertainly must be few enough not to cause an explosion in the number of \npacks.\n\n> It would also mean blobs wouldn't need to\n> be uncompressed to get the blob type or size I believe.\n\nThey already don't.\n\n> So far this has prevented me from deploying git here\n> (and is half the reason I have not been active recently).\n> Currently we use p4 and we have large files.\n> When a large file is checked in (submitted),\n> it is compressed *once* and sent over the network --\n> these are the only delays that end-users experience.\n> \n> The equivalent operation in git would require the creation of\n> the blob, and then of a temporary pack to send to the server.\n> This requires 3 calls to zlib for each blob, which for very\n> large files is not acceptable at my site.\n\nI currently count 2 calls to zlib, not 3. And with big blobs as packs, \nas suggested above then you'd have only one call when actually staging \ntheir content. This should be really straight forward to implement \ngiven that pack-objects is already a built-in.\n\n\nNicolas\n"},{"id":"60967","messageId":"20071126195750.GD25784@efreet.light.src","threadId":"11016","inReplyTo":"854pf8243i.fsf@lola.goethe.zz","subject":"Re: If you would write git from scratch now, what would you change?","fromName":"Jan Hudec","fromEmail":"bulb@ucw.cz","sentAt":"2007-11-26T19:57:50Z","receivedAt":"2007-11-26T19:57:50Z","isPatch":false,"sender":{"key":"bulb@ucw.cz","avatar":null},"body":"On Mon, Nov 26, 2007 at 20:34:25 +0100, David Kastrup wrote:\n> Nicolas Pitre writes:\n> > On Mon, 26 Nov 2007, David Kastrup wrote:\n> >> Get rid of plumbing at the command line level.\n> >\n> > We can't get rid of plumbing.\n> \n> What about \"at the command line level\" did you not understand?\n\nWhich part of we neither can nor want did you not understant?\n\nThe availability of plumbing is really big part of a reason why git is so\ngood and has so many scripts and tool built on top of it. Bzr and hg boast\nwith their ability to add plugins, but git ability to use plumbing simply\nbeats that hands down, because the plugins are python-only and writing them\nrequires understanding the internal API, while git plumbing can be used from\nany language and can usually be understood by running it interactively a few\ntimes.\n\nThat's why we don't want (and really can't because there is a huge amount of\ncode in various languages using it) to get rid of plumbing at the command\nlevel. What we may do is hide it from the casual user.\n\nTo do that, we'd want to get rid of the git-* commands and links in bin\n(remove the builtins altogether and move the non-builtin to libexec -- that\nseems to be the plan for 1.6 or 1.7 already) and than hiding the plumbing\nfrom --help and completion hides it from the user.\n\n-- \n\t\t\t\t\t\t Jan 'Bulb' Hudec \n"},{"id":"60969","messageId":"20071126200913.GE25784@efreet.light.src","threadId":"11016","inReplyTo":"87ve7ozsz8.fsf@graviton.dyn.troilus.org","subject":"Re: If you would write git from scratch now, what would you change?","fromName":"Jan Hudec","fromEmail":"bulb@ucw.cz","sentAt":"2007-11-26T20:09:13Z","receivedAt":"2007-11-26T20:09:13Z","isPatch":false,"sender":{"key":"bulb@ucw.cz","avatar":null},"body":"On Mon, Nov 26, 2007 at 14:50:35 -0500, Michael Poole wrote:\n> Jan Hudec writes:\n> \n> > The basic pull/push actions are:\n> >\n> > git pull: Bring the remote ref value here.\n> > git push: Put the local ref value there.\n> >\n> > Are those not oposites?\n> >\n> > Than each command has it's different features on top of this -- pull merges\n> > and push can push multiple refs -- but in the basic operation they are\n> > oposites.\n> \n> I think that is in absolute agreement with David: Ducks swim on the\n> surface of the water and lobsters swim underneath. Why consider the\n> different features on top of where they swim?\n> \n> The thing about git-pull that surprises so many users is the merge.\n> There's a separate command to do that step, and git-pull had a fairly\n> good excuse to do the merge before git's 1.5.x remote system was in\n> place, but now the only really defensible reason for its behavior is\n> history.\n\nWhen I first looked at hg -- and that was long before I looked at git --\nI was surprised that their pull did NOT merge and you had to do a separate\nstep. Partly because doing those two steps is quite common.\n\n-- \n\t\t\t\t\t\t Jan 'Bulb' Hudec \n"},{"id":"60970","messageId":"200711262011.02689.andyparkins@gmail.com","threadId":"11016","inReplyTo":"2A34D324-48A4-49EF-9D4E-5B9469A0791D@lrde.epita.fr","subject":"Re: If you would write git from scratch now, what would you change?","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-11-26T20:11:02Z","receivedAt":"2007-11-26T20:11:02Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Monday 2007, November 26, Benoit Sigoure wrote:\n> On Nov 26, 2007, at 5:46 PM, Andy Parkins wrote:\n> > - libgit would have come first\n>\n> I warmly second that.\n>\n> > - \"git revert\" should be called \"git invert\"\n> > - \"git revert\" would (maybe) be \"git reset\"\n>\n> But here, I have to disagree. Why would you want to call \"git-\n> revert\" \"git-reset\"?\n\nI don't; you're reading it the wrong way around. I think current revert \nshould actually be called invert. \"revert\" means to move back to a \nprevious point. That is not at all what git-revert does, what it actually \ndoes is to apply the opposite of the given commit - i.e. an inversion.\n\nRevert on the other hand would be the perfect name for current git-reset.\n\n> I know it's annoying that commands with the same name do different\n> things in SVN/CVS but I don't think it's a reason to necessarily\n\nI know that very well; nor did I pick any of those suggestions based on what \nsvn does. There is no other VCS that uses \"invert\" as far as I know. Nor \ndoes any other VCS use \"revert\" the way I'd like; so I'm really not sure \nwhere you're getting the idea that I chose those as a copy of another VCS. \nWhat I would like (ideally, with a time machine) is those words, which have \na well defined meaning in English, to match more closely with their \nfunction in the VCS. \"revert\" is definitely not right.\n\n> adapt to them. There are plenty of misnomers already anyway\n> (checkout, commit, add).\n\nI know; but the question was \"what if we could start again\". I don't see \ntoo many problems with checkout and commit as it happens. They both seem \nlike adequate verbs to describe the operations they perform. We could \nperhaps quibble about the extra functionality that they've both gained, but \nthat isn't a naming fault, and the extensions are natural extensions for \nusers of git.\n\n\n\nAndy\n-- \nDr Andy Parkins, M Eng (hons), MIET\nandyparkins@gmail.com\n"},{"id":"60971","messageId":"FF804F69-3EEC-4FED-AE92-18C4F5B3645F@lrde.epita.fr","threadId":"11016","inReplyTo":"20071126192703.GB25784@efreet.light.src","subject":"Re: If you would write git from scratch now, what would you change?","fromName":"Benoit Sigoure","fromEmail":"tsuna@lrde.epita.fr","sentAt":"2007-11-26T20:11:41Z","receivedAt":"2007-11-26T20:11:41Z","isPatch":false,"sender":{"key":"tsunanet@gmail.com","avatar":"https://avatars.githubusercontent.com/u/128281?v=4"},"body":"On Nov 26, 2007, at 8:27 PM, Jan Hudec wrote:\n\n> On Mon, Nov 26, 2007 at 18:11:43 +0100, David Kastrup wrote:\n>> Jakub Narebski writes:\n>>\n>>> If you would write git from scratch now, from the beginning, without\n>>> concerns for backwards compatibility, what would you change, or what\n>>> would you want to have changed?\n>>\n>> Get rid of plumbing at the command line level. It is confusing to\n>\n> No, please. It's extremely useful. It should be a bit more hidden, \n> but it's\n> a big advantage of git that the plumbing is available.\n>\n>> users, and command line arguments, exec calls and I/O streams are not\n>> efficient and reasonably typed mechanisms for the kind of operations\n>> done in plumbing. Instead using a good extensible portable scripting\n>> language (I consider Lua quite suitable in that regard, but it is\n>> conceivable that something with a native list type supporting easy\n>> sorts, merges and selections could be more efficient) and \n>> implementing\n>> plumbing in that or in C would have been preferable for creating the\n>> porcelain.\n>\n> POSIX shell is really the best extensible portable scripting language\n> available for the job. Because the whipuptitude is the most important\n> property and shell is simply best at one-liners. And since you use it\n> for regular work (running editor, compiler, git porcelain), it is the\n> obvious choice for whiping up a short function.\n\n\nPerl seems pretty portable. If we had a decent, complete libgit, it \nwould be easy to create bindings for various languages and script Git \nin other languages than Shell script.\n\n-- \nBenoit Sigoure aka Tsuna\nEPITA Research and Development Laboratory\n"},{"id":"60973","messageId":"56b7f5510711261217h56214321xb7acd9851b677dd6@mail.gmail.com","threadId":"11016","inReplyTo":"alpine.LFD.0.99999.0711261433210.9605@xanadu.home","subject":"Re: If you would write git from scratch now, what would you change?","fromName":"Dana How","fromEmail":"danahow@gmail.com","sentAt":"2007-11-26T20:17:21Z","receivedAt":"2007-11-26T20:17:21Z","isPatch":false,"sender":{"key":"danahow@gmail.com","avatar":null},"body":"On Nov 26, 2007 11:52 AM, Nicolas Pitre wrote:\n> On Mon, 26 Nov 2007, Dana How wrote:\n> > Currently data can be quickly copied from pack to pack,\n> > but data cannot be quickly copied blob->pack or pack->blob\n> I don't see why you would need the pack->blob copy normally.\nTrue, but that doesn't change the main point.\n\n> > (there was an alternate blob format that supported this,\n> > but it was deprecated). Using the pack format for blobs\n> > would fix this.\n>\n> Then you can do just that for big enough blobs where \"big enough\" is\n> configurable: encapsulate them in a pack instead of a loose object.\n> Problem solved. Sure you'll end up with a bunch of packs containing\n> only one blob object, but given that those blobs are so large to be a\n> problem in your work flow when written out as loose objects, then they\n> certainly must be few enough not to cause an explosion in the number of\n> packs.\nAre you suggesting that \"git add\" create a new pack containing\none blob when the blob is big enough? Re-using (part of) the pack format\nin a blob (or maybe only some blobs) seems like less code change.\n\n> > It would also mean blobs wouldn't need to\n> > be uncompressed to get the blob type or size I believe.\n>\n> They already don't.\nIt looks like sha1_file.c:parse_sha1_header() works on a buffer\nfilled in by sha1_file.c:unpack_sha1_header() by calling inflate(), right?\n\nIt is true you don't have to uncompress the *entire* blob.\n\n> > The equivalent operation in git would require the creation of\n> > the blob, and then of a temporary pack to send to the server.\n> > This requires 3 calls to zlib for each blob, which for very\n> > large files is not acceptable at my site.\n>\n> I currently count 2 calls to zlib, not 3.\nI count 3:\n\nCall 1: git-add calls zlib to make the blob.\n\nCall 2: builtin-pack-objects.c:write_one() calls sha1_file.c:read_sha1_file()\ncalls :unpack_sha1_file() calls :unpack_sha1_{header,rest}() calls\ninflate() to get the data from the blob into a buffer.\n\nCall 3: Then write_one() calls deflate to make the new buffer\nto write into the pack. This is all under the \"if (!to_reuse) {\" path,\nwhich is active when packing a blob.\n\nRemember, I'm comparing \"p4 submit file\" to\n\"git add file\"/\"git commit\"/\"git push\", which is the comparison\nthe users will be making.\n\nOn the other hand, I'm looking at code from June;\nbut I haven't noticed big changes since then on the list.\n\nCalls 2 and 3 go away if the blob and pack formats were more similar.\n-- \nDana L. How danahow@gmail.com +1 650 804 5991 cell\n"},{"id":"60972","messageId":"200711262117.56326.jnareb@gmail.com","threadId":"11016","inReplyTo":"56b7f5510711261118m7a402beah5d9cb75c1ad10b43@mail.gmail.com","subject":"Re: If you would write git from scratch now, what would you change?","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-11-26T20:17:55Z","receivedAt":"2007-11-26T20:17:55Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Mon, 26 Nov 2007, Dana How wrote:\n> On Nov 25, 2007 1:48 PM, Jakub Narebski wrote:\n>\n> > If you would write git from scratch now, from the beginning, without\n> > concerns for backwards compatibility, what would you change, or what\n> > would you want to have changed?\n> \n> Currently data can be quickly copied from pack to pack,\n> but data cannot be quickly copied blob->pack or pack->blob\n> (there was an alternate blob format that supported this,\n> but it was deprecated). Using the pack format for blobs\n> would fix this. It would also mean blobs wouldn't need to\n> be uncompressed to get the blob type or size I believe.\n\nCould you do some benchmark for repository with your large objects\nas loose objects created with and without core.legacyHeaders (created \nwith git pre 1.5.3), and as single blob packs, perhaps kept, with \n_undocumented_ (except for RelNotes) gitattribute delta unset for\nthose files?\n\n\n>From Documentation/RelNotes-1.5.3:\n\n - We used to have core.legacyheaders configuration, when\n set to false, allowed git to write loose objects in a format\n that mimicks the format used by objects stored in packs. It\n turns out that this was not so useful. Although we will\n continue to read objects written in that format, we do not\n honor that configuration anymore and create loose objects in\n the legacy/traditional format.\n\n - \"pack-objects\" honors \"delta\" attribute set in\n .gitattributes. It does not attempt to deltify blobs that\n come from paths with delta attribute set to false.\n\n - diff-delta code that is used for packing has been improved\n to work better on big files.\n\nThe last part is thanks to your comments, complaints and efforts, Dana.\n\n-- \nJakub Narebski\nPoland\n"},{"id":"60975","messageId":"87oddgzr3c.fsf@graviton.dyn.troilus.org","threadId":"11016","inReplyTo":"20071126200913.GE25784@efreet.light.src","subject":"Re: If you would write git from scratch now, what would you change?","fromName":"Michael Poole","fromEmail":"mdpoole@troilus.org","sentAt":"2007-11-26T20:31:19Z","receivedAt":"2007-11-26T20:31:19Z","isPatch":false,"sender":{"key":"mdpoole@troilus.org","avatar":null},"body":"Jan Hudec writes:\n\n> On Mon, Nov 26, 2007 at 14:50:35 -0500, Michael Poole wrote:\n>> Jan Hudec writes:\n>> \n>> > The basic pull/push actions are:\n>> >\n>> > git pull: Bring the remote ref value here.\n>> > git push: Put the local ref value there.\n>> >\n>> > Are those not oposites?\n>> >\n>> > Than each command has it's different features on top of this -- pull merges\n>> > and push can push multiple refs -- but in the basic operation they are\n>> > oposites.\n>> \n>> I think that is in absolute agreement with David: Ducks swim on the\n>> surface of the water and lobsters swim underneath. Why consider the\n>> different features on top of where they swim?\n>> \n>> The thing about git-pull that surprises so many users is the merge.\n>> There's a separate command to do that step, and git-pull had a fairly\n>> good excuse to do the merge before git's 1.5.x remote system was in\n>> place, but now the only really defensible reason for its behavior is\n>> history.\n>\n> When I first looked at hg -- and that was long before I looked at git --\n> I was surprised that their pull did NOT merge and you had to do a separate\n> step. Partly because doing those two steps is quite common.\n\nFrequency of use is a good argument for having one command that does\nboth. It is not a good argument that \"fetch, then merge\" should be\ncalled \"pull\" or is the opposite of \"push\".\n\nMichael Poole\n"},{"id":"60976","messageId":"85prxwzqvn.fsf@lola.goethe.zz","threadId":"11016","inReplyTo":"20071126195750.GD25784@efreet.light.src","subject":"Re: If you would write git from scratch now, what would you change?","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-11-26T20:35:56Z","receivedAt":"2007-11-26T20:35:56Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Jan Hudec writes:\n\n> On Mon, Nov 26, 2007 at 20:34:25 +0100, David Kastrup wrote:\n>> Nicolas Pitre writes:\n>> > On Mon, 26 Nov 2007, David Kastrup wrote:\n>> >> Get rid of plumbing at the command line level.\n>> >\n>> > We can't get rid of plumbing.\n>> \n>> What about \"at the command line level\" did you not understand?\n>\n> Which part of we neither can nor want did you not understant?\n>\n> The availability of plumbing is really big part of a reason why git is\n> so good and has so many scripts and tool built on top of it.\n\nWhich is the reason I proposed making the plumbing available at a\nscripting level, not at the command line level.\n\nThe actual trend we are getting nowadays is locking the porcelaine,\npreviously available as shell scripts, down into C code, _without_\nmaking use of a reasonable plumbing layer suitable for any scripting at\nall.\n\nSo the git community at the same time praises shell scripting and\nsimultanouesly replaces it without even using the available plumbing,\n_and_ claims that _both_, exclusive and incompatible approaches, are the\nperfect solution. At the same time. While fighting the shell\nportability fight continuously, on Unix as well as Windows.\n\nI may have a big mouth, but swallowing all of this at once is beyond me.\n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"},{"id":"60978","messageId":"56b7f5510711261236n732d56dci6335541391e1e137@mail.gmail.com","threadId":"11016","inReplyTo":"200711262117.56326.jnareb@gmail.com","subject":"Re: If you would write git from scratch now, what would you change?","fromName":"Dana How","fromEmail":"danahow@gmail.com","sentAt":"2007-11-26T20:36:27Z","receivedAt":"2007-11-26T20:36:27Z","isPatch":false,"sender":{"key":"danahow@gmail.com","avatar":null},"body":"On Nov 26, 2007 12:17 PM, Jakub Narebski wrote:\n> On Mon, 26 Nov 2007, Dana How wrote:\n> > On Nov 25, 2007 1:48 PM, Jakub Narebski wrote:\n> >\n> > > If you would write git from scratch now, from the beginning, without\n> > > concerns for backwards compatibility, what would you change, or what\n> > > would you want to have changed?\n> >\n> > Currently data can be quickly copied from pack to pack,\n> > but data cannot be quickly copied blob->pack or pack->blob\n> > (there was an alternate blob format that supported this,\n> > but it was deprecated). Using the pack format for blobs\n> > would fix this. It would also mean blobs wouldn't need to\n> > be uncompressed to get the blob type or size I believe.\n>\n> Could you do some benchmark for repository with your large objects\n> as loose objects created with and without core.legacyHeaders (created\n> with git pre 1.5.3), and as single blob packs, perhaps kept, with\n> _undocumented_ (except for RelNotes) gitattribute delta unset for\n> those files?\nFirst of all, this is a very reasonable request and what I should be doing.\nUnfortunately, I only have the cycles at the moment to point out this\nissue, which appears to be a problem from my perspective.\n\nCurrently,\na user who wants to publish some (large) files does the following:\ngit add (calls deflate)\ngit commit\ngit push (builds a pack to stdout, calling inflate and deflate on each blob).\n\nSo if the blob and pack formats were more similar (different blob format,\nbig blobs are singleton packs, etc) the zlib calls in git push go away.\nThe deflate call could be sped up by using 1 for compression level,\nbut it still takes time.\n\nAnother \"solution\" is to make each workgroup member's .git/objects\nbe a symlink to a tree with a lot of sticky bits and do some scripting.\n(This means \"git push\" doesn't push any data and only alters stuff\n in .git/refs/heads on the server.)\nI'm not entirely enthusiastic about this, and when I mentioned it a while\nago it did cause some retching...\n\n> From Documentation/RelNotes-1.5.3:\n>\n> - We used to have core.legacyheaders configuration, when\n> set to false, allowed git to write loose objects in a format\n> that mimicks the format used by objects stored in packs. It\n> turns out that this was not so useful. Although we will\n> continue to read objects written in that format, we do not\n> honor that configuration anymore and create loose objects in\n> the legacy/traditional format.\n>\n> - \"pack-objects\" honors \"delta\" attribute set in\n> .gitattributes. It does not attempt to deltify blobs that\n> come from paths with delta attribute set to false.\n>\n> - diff-delta code that is used for packing has been improved\n> to work better on big files.\n>\n> The last part is thanks to your comments, complaints and efforts, Dana.\nYes, there have been some very useful improvements recently.\n\nHowever, I didn't actually push for the first \"-\" you list;\nI was pushing for the \"mimic\" option even then\nbut some argument was presented to me against it,\nto which I had no counter-argument until I understood git better later.\n\nThanks,\n-- \nDana L. How danahow@gmail.com +1 650 804 5991 cell\n"},{"id":"60977","messageId":"20071126203654.GF25784@efreet.light.src","threadId":"11016","inReplyTo":"FF804F69-3EEC-4FED-AE92-18C4F5B3645F@lrde.epita.fr","subject":"Re: If you would write git from scratch now, what would you change?","fromName":"Jan Hudec","fromEmail":"bulb@ucw.cz","sentAt":"2007-11-26T20:36:54Z","receivedAt":"2007-11-26T20:36:54Z","isPatch":false,"sender":{"key":"bulb@ucw.cz","avatar":null},"body":"On Mon, Nov 26, 2007 at 21:11:41 +0100, Benoit Sigoure wrote:\n> On Nov 26, 2007, at 8:27 PM, Jan Hudec wrote:\n>\n>> On Mon, Nov 26, 2007 at 18:11:43 +0100, David Kastrup wrote:\n>>> Jakub Narebski writes:\n>>>\n>>>> If you would write git from scratch now, from the beginning, without\n>>>> concerns for backwards compatibility, what would you change, or what\n>>>> would you want to have changed?\n>>>\n>>> Get rid of plumbing at the command line level. It is confusing to\n>>\n>> No, please. It's extremely useful. It should be a bit more hidden, but \n>> it's\n>> a big advantage of git that the plumbing is available.\n>>\n>>> users, and command line arguments, exec calls and I/O streams are not\n>>> efficient and reasonably typed mechanisms for the kind of operations\n>>> done in plumbing. Instead using a good extensible portable scripting\n>>> language (I consider Lua quite suitable in that regard, but it is\n>>> conceivable that something with a native list type supporting easy\n>>> sorts, merges and selections could be more efficient) and implementing\n>>> plumbing in that or in C would have been preferable for creating the\n>>> porcelain.\n>>\n>> POSIX shell is really the best extensible portable scripting language\n>> available for the job. Because the whipuptitude is the most important\n>> property and shell is simply best at one-liners. And since you use it\n>> for regular work (running editor, compiler, git porcelain), it is the\n>> obvious choice for whiping up a short function.\n>\n> Perl seems pretty portable. If we had a decent, complete libgit, it would \n> be easy to create bindings for various languages and script Git in other \n> languages than Shell script.\n\nPerl might be good for the lower level stuff (and is indeed used for that in\ngit a lot), but most useful tools on top of git gather few bigish bits\n(contents of whole files and such) and pass them to some application. And\nthis is what shell is really good at.\n\nSo yes, more direct interfaces for various languages would certainly be good,\nbut it would never be a full replacement for the process interface. It is\nmost generic and for many hacks the easiest thing to use.\n\n-- \n\t\t\t\t\t\t Jan 'Bulb' Hudec \n"},{"id":"60981","messageId":"AA5ECB69-3F77-483E-AD19-04A5515779B3@wincent.com","threadId":"11016","inReplyTo":"20071126195750.GD25784@efreet.light.src","subject":"Re: If you would write git from scratch now, what would you change?","fromName":"Wincent Colaiuta","fromEmail":"win@wincent.com","sentAt":"2007-11-26T20:45:16Z","receivedAt":"2007-11-26T20:45:16Z","isPatch":false,"sender":{"key":"greg@hurrell.net","avatar":"https://avatars.githubusercontent.com/u/7074?v=4"},"body":"El 26/11/2007, a las 20:57, Jan Hudec escribió:\n\n> The availability of plumbing is really big part of a reason why git \n> is so\n> good and has so many scripts and tool built on top of it.\n\nYes, the plumbing is really lovely when it comes time to whipping \ntogether a quick tool for a special task; much nicer than writing a \nplugin.\n\nFor the benefit of newcomers, I just wish the plumbing was kept a \nlittle bit out of sight. You know, porcelain in /usr/bin and plumbing \nin /usr/libexec or other such place.\n\nIt's fine once you've learnt your workflows and know the 10 or 15 Git \ntools that you'll be using day-to-day; but for people who are just \nstarting off this can be a little bit intimidating:\n\n$ git-\nDisplay all 146 possibilities? (y or n)\n\nCheers,\nWincent\n"},{"id":"60982","messageId":"9e4733910711261248o3ece7523s1069490e6c87932f@mail.gmail.com","threadId":"11016","inReplyTo":"87oddgzr3c.fsf@graviton.dyn.troilus.org","subject":"Re: If you would write git from scratch now, what would you change?","fromName":"Jon Smirl","fromEmail":"jonsmirl@gmail.com","sentAt":"2007-11-26T20:48:13Z","receivedAt":"2007-11-26T20:48:13Z","isPatch":false,"sender":{"key":"jonsmirl@gmail.com","avatar":"https://gravatar.com/avatar/cff3bf5bfdfa6708b905712ff91f0f9b8aaca161659f38c02b787920d5d28b7e?d=mp&s=160"},"body":"On 11/26/07, Michael Poole wrote:\n> Jan Hudec writes:\n>\n> > On Mon, Nov 26, 2007 at 14:50:35 -0500, Michael Poole wrote:\n> >> Jan Hudec writes:\n> >>\n> >> > The basic pull/push actions are:\n> >> >\n> >> > git pull: Bring the remote ref value here.\n> >> > git push: Put the local ref value there.\n> >> >\n> >> > Are those not oposites?\n> >> >\n> >> > Than each command has it's different features on top of this -- pull merges\n> >> > and push can push multiple refs -- but in the basic operation they are\n> >> > oposites.\n> >>\n> >> I think that is in absolute agreement with David: Ducks swim on the\n> >> surface of the water and lobsters swim underneath. Why consider the\n> >> different features on top of where they swim?\n> >>\n> >> The thing about git-pull that surprises so many users is the merge.\n> >> There's a separate command to do that step, and git-pull had a fairly\n> >> good excuse to do the merge before git's 1.5.x remote system was in\n> >> place, but now the only really defensible reason for its behavior is\n> >> history.\n> >\n> > When I first looked at hg -- and that was long before I looked at git --\n> > I was surprised that their pull did NOT merge and you had to do a separate\n> > step. Partly because doing those two steps is quite common.\n>\n> Frequency of use is a good argument for having one command that does\n> both. It is not a good argument that \"fetch, then merge\" should be\n> called \"pull\" or is the opposite of \"push\".\n\nI'm starting to think that things oriented around the default names of\nmaster and origin needs rethinking. Everything should use explicitly\nnamed remotes. You could always do something like set a default remote\nrepository, but that is different than using the magic name 'origin'.\n\n-- \nJon Smirl\njonsmirl@gmail.com\n"},{"id":"60983","messageId":"alpine.LFD.0.99999.0711261529080.9605@xanadu.home","threadId":"11016","inReplyTo":"56b7f5510711261217h56214321xb7acd9851b677dd6@mail.gmail.com","subject":"Re: If you would write git from scratch now, what would you change?","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-11-26T20:55:43Z","receivedAt":"2007-11-26T20:55:43Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Mon, 26 Nov 2007, Dana How wrote:\n\n> On Nov 26, 2007 11:52 AM, Nicolas Pitre wrote:\n> > On Mon, 26 Nov 2007, Dana How wrote:\n> > > Currently data can be quickly copied from pack to pack,\n> > > but data cannot be quickly copied blob->pack or pack->blob\n> > I don't see why you would need the pack->blob copy normally.\n> True, but that doesn't change the main point.\n\nSure, but let's not go overboard either.\n\n> > > (there was an alternate blob format that supported this,\n> > > but it was deprecated). Using the pack format for blobs\n> > > would fix this.\n> >\n> > Then you can do just that for big enough blobs where \"big enough\" is\n> > configurable: encapsulate them in a pack instead of a loose object.\n> > Problem solved. Sure you'll end up with a bunch of packs containing\n> > only one blob object, but given that those blobs are so large to be a\n> > problem in your work flow when written out as loose objects, then they\n> > certainly must be few enough not to cause an explosion in the number of\n> > packs.\n> Are you suggesting that \"git add\" create a new pack containing\n> one blob when the blob is big enough?\n\nExactly.\n\n> Re-using (part of) the pack format\n> in a blob (or maybe only some blobs) seems like less code change.\n\nDon't know what you mean exactly here, but what I mean is to do \nsomething as simple as:\n\n\tpretend_sha1_file(...);\n\tadd_object_entry(...);\n\twrite_pack_file();\n\nwhen the buffer to make a blob from is larger than a configured \ntreshold.\n\n> > > It would also mean blobs wouldn't need to\n> > > be uncompressed to get the blob type or size I believe.\n> >\n> > They already don't.\n> It looks like sha1_file.c:parse_sha1_header() works on a buffer\n> filled in by sha1_file.c:unpack_sha1_header() by calling inflate(), right?\n> \n> It is true you don't have to uncompress the *entire* blob.\n\nRight. Only the first 16 bytes or so need to be uncompressed.\n\n> > > The equivalent operation in git would require the creation of\n> > > the blob, and then of a temporary pack to send to the server.\n> > > This requires 3 calls to zlib for each blob, which for very\n> > > large files is not acceptable at my site.\n> >\n> > I currently count 2 calls to zlib, not 3.\n> I count 3:\n> \n> Call 1: git-add calls zlib to make the blob.\n> \n> Call 2: builtin-pack-objects.c:write_one() calls sha1_file.c:read_sha1_file()\n> calls :unpack_sha1_file() calls :unpack_sha1_{header,rest}() calls\n> inflate() to get the data from the blob into a buffer.\n> \n> Call 3: Then write_one() calls deflate to make the new buffer\n> to write into the pack. This is all under the \"if (!to_reuse) {\" path,\n> which is active when packing a blob.\n\nOh, you're right. Somehow I didn't count the needed decompression.\n\n> Remember, I'm comparing \"p4 submit file\" to\n> \"git add file\"/\"git commit\"/\"git push\", which is the comparison\n> the users will be making.\n> \n> On the other hand, I'm looking at code from June;\n> but I haven't noticed big changes since then on the list.\n> \n> Calls 2 and 3 go away if the blob and pack formats were more similar.\n\n... which my suggestion should provide with a minimum of changes, maybe \nless than 10 lines of code.\n\n\nNicolas\n"},{"id":"60984","messageId":"20071126210006.GG25784@efreet.light.src","threadId":"11016","inReplyTo":"85prxwzqvn.fsf@lola.goethe.zz","subject":"Re: If you would write git from scratch now, what would you change?","fromName":"Jan Hudec","fromEmail":"bulb@ucw.cz","sentAt":"2007-11-26T21:00:06Z","receivedAt":"2007-11-26T21:00:06Z","isPatch":false,"sender":{"key":"bulb@ucw.cz","avatar":null},"body":"On Mon, Nov 26, 2007 at 21:35:56 +0100, David Kastrup wrote:\n> Jan Hudec writes:\n> \n> > On Mon, Nov 26, 2007 at 20:34:25 +0100, David Kastrup wrote:\n> >> Nicolas Pitre writes:\n> >> > On Mon, 26 Nov 2007, David Kastrup wrote:\n> >> >> Get rid of plumbing at the command line level.\n> >> >\n> >> > We can't get rid of plumbing.\n> >> \n> >> What about \"at the command line level\" did you not understand?\n> >\n> > Which part of we neither can nor want did you not understant?\n> >\n> > The availability of plumbing is really big part of a reason why git is\n> > so good and has so many scripts and tool built on top of it.\n> \n> Which is the reason I proposed making the plumbing available at a\n> scripting level, not at the command line level.\n\nBut scripting in the first place means *SHELL* scripting. Or you normally use\nLua command line for your daily work?\n\n> The actual trend we are getting nowadays is locking the porcelaine,\n> previously available as shell scripts, down into C code, _without_\n> making use of a reasonable plumbing layer suitable for any scripting at\n> all.\n\nFor myself I would say I don't think C is an appropriate tool for the job. It\nis nice when you need to optimize things to the last instruction, but for my\ntaste it's unwieldy for the high-level stuff.\n\n> So the git community at the same time praises shell scripting and\n> simultanouesly replaces it without even using the available plumbing,\n> _and_ claims that _both_, exclusive and incompatible approaches, are the\n> perfect solution. At the same time. While fighting the shell\n> portability fight continuously, on Unix as well as Windows.\n\nWell, the builtins *do* use the plumbing. They just use the C functions\nwithout using streams and forks. Isn't that what you wanted?\n\nBut the key reason for keeping the plumbing around is prototyping and\nespecially tailoring. Junio has many scripts (you can look at them in the\ntodo branch in git repo) to support his particular workflow and plumbing is\nuseful there. And shell is really the right tool for such things.\n\n> I may have a big mouth, but swallowing all of this at once is beyond me.\n\n-- \n\t\t\t\t\t\t Jan 'Bulb' Hudec \n"},{"id":"60989","messageId":"7vhcj8g0op.fsf@gitster.siamese.dyndns.org","threadId":"11016","inReplyTo":"AA5ECB69-3F77-483E-AD19-04A5515779B3@wincent.com","subject":"Re: If you would write git from scratch now, what would you change?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-26T21:24:22Z","receivedAt":"2007-11-26T21:24:22Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Wincent Colaiuta writes:\n\n> For the benefit of newcomers, I just wish the plumbing was kept a \n> little bit out of sight. You know, porcelain in /usr/bin and plumbing \n> in /usr/libexec or other such place.\n>\n> It's fine once you've learnt your workflows and know the 10 or 15 Git \n> tools that you'll be using day-to-day; but for people who are just \n> starting off this can be a little bit intimidating:\n>\n> $ git-\n> Display all 146 possibilities? (y or n)\n\nI'd agree to that but I've always considered this an issue for distros.\nWe've supported an ability for them to specify a gitexecdir separate\nfrom /usr/bin in our Makefile for almost two years.\n\nThe tab completion for bash and zsh would also help you here, but I see\nthere are quite a few commands that should not be there, and it's time\nto clean it up.\n\n\t$ git \n add fetch push\n am filter-branch rebase\n annotate format-patch rebase--interactive\n apply fsck relink\n archive gc remote\n bisect get-tar-commit-id repack\n blame grep request-pull\n branch gui reset\n bundle imap-send resolve\n checkout init revert\n checkout-index instaweb rm\n cherry less send-email\n cherry-pick lg shortlog\n citool log show\n clean lost-found show-branch\n clone ls-files show-ref\n co ls-remote stash\n commit ls-tree status\n config merge submodule\n convert-objects mergetool svnimport\n count-objects mv tag\n describe name-rev var\n diff pickaxe verify-pack\n diff-stages pull whatchanged\n\nPerhaps this list can be a starting point...\n\n contrib/completion/git-completion.bash | 9 +++++++++\n 1 files changed, 9 insertions(+), 0 deletions(-)\n\ndiff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash\nindex cad842a..1bba68b 100755\n--- a/contrib/completion/git-completion.bash\n+++ b/contrib/completion/git-completion.bash\n@@ -359,6 +359,15 @@ __git_commands ()\n \t\tupload-pack) : plumbing;;\n \t\twrite-tree) : plumbing;;\n \t\tverify-tag) : plumbing;;\n+\t\tannotate) : use blame;;\n+\t\tcheckout-index) : plumbing;;\n+\t\tdiff-stages) : plumbing;;\n+\t\tget-tar-commit-id) : plumbing;;\n+\t\tlost-found) : deprecated;;\n+\t\trebase--interactive) : plumbing;;\n+\t\trelink) : obsolete;;\n+\t\twhatchanged) : plumbing;;\n+\t\tverify-pack) : plumbing;;\n \t\t*) echo $i;;\n \t\tesac\n \tdone\n"},{"id":"60990","messageId":"Pine.LNX.4.64.0711262124411.27959@racer.site","threadId":"11016","inReplyTo":"alpine.LFD.0.99999.0711261417580.9605@xanadu.home","subject":"Re: If you would write git from scratch now, what would you change?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-11-26T21:27:54Z","receivedAt":"2007-11-26T21:27:54Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 26 Nov 2007, Nicolas Pitre wrote:\n\n> On Mon, 26 Nov 2007, David Kastrup wrote:\n> \n> > Get rid of plumbing at the command line level.\n> \n> We can't get rid of plumbing. It is part of Git probably forever and is \n> really really convenient for scripting in any language you want.\n\nI agree, but that's not even the complete truth. Git would be not even \nhalf as useful as it is without its scriptability.\n\nSo it is not only convenience, but very much a reason that git development \nis so fast. That, and that more people than elsewhere let code talk. \nWhich is also much easier when you have a scriptable system.\n\nCiao,\nDscho\n"},{"id":"60991","messageId":"alpine.LFD.0.99999.0711261620220.9605@xanadu.home","threadId":"11016","inReplyTo":"85prxwzqvn.fsf@lola.goethe.zz","subject":"Re: If you would write git from scratch now, what would you change?","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-11-26T21:28:40Z","receivedAt":"2007-11-26T21:28:40Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Mon, 26 Nov 2007, David Kastrup wrote:\n\n> Jan Hudec writes:\n> \n> > On Mon, Nov 26, 2007 at 20:34:25 +0100, David Kastrup wrote:\n> >> Nicolas Pitre writes:\n> >> > On Mon, 26 Nov 2007, David Kastrup wrote:\n> >> >> Get rid of plumbing at the command line level.\n> >> >\n> >> > We can't get rid of plumbing.\n> >> \n> >> What about \"at the command line level\" did you not understand?\n> >\n> > Which part of we neither can nor want did you not understant?\n> >\n> > The availability of plumbing is really big part of a reason why git is\n> > so good and has so many scripts and tool built on top of it.\n> \n> Which is the reason I proposed making the plumbing available at a\n> scripting level, not at the command line level.\n\nYou're mixing two orthogonal issues, namely: 1) the scripting language, \nand 2) the too large number of Git command accessible through your \ndefault path.\n\n#1 is a non issue really. We don't want to lock plumbing to any \nparticular scripting language, and the current interface is the most \nuniversal one in that regard.\n\n#2 can be solved through a single multiplexer such as 'git low-level'.\n\nThat 'git low-level foo' may just look up git-foo in some libexec \ndirectory, and only 'git-low-level' need to be in the path instead of \nall those plumbing commands.\n\nNeed only to have both forms ('git foo' and 'git low-level foo') to work \nfor a transition period.\n\n\nNicolas\n"},{"id":"60996","messageId":"alpine.LFD.0.99999.0711261631170.9605@xanadu.home","threadId":"11016","inReplyTo":"7vhcj8g0op.fsf@gitster.siamese.dyndns.org","subject":"Re: If you would write git from scratch now, what would you change?","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-11-26T21:35:18Z","receivedAt":"2007-11-26T21:35:18Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Mon, 26 Nov 2007, Junio C Hamano wrote:\n\n> Wincent Colaiuta writes:\n> \n> > For the benefit of newcomers, I just wish the plumbing was kept a \n> > little bit out of sight. You know, porcelain in /usr/bin and plumbing \n> > in /usr/libexec or other such place.\n> >\n> > It's fine once you've learnt your workflows and know the 10 or 15 Git \n> > tools that you'll be using day-to-day; but for people who are just \n> > starting off this can be a little bit intimidating:\n> >\n> > $ git-\n> > Display all 146 possibilities? (y or n)\n> \n> I'd agree to that but I've always considered this an issue for distros.\n> We've supported an ability for them to specify a gitexecdir separate\n> from /usr/bin in our Makefile for almost two years.\n\nWould probably be a good thing to start enforcing that by default. It's \neasier to follow such policies when they're coordinated from the project \norigin.\n\n\nNicolas\n"},{"id":"60994","messageId":"alpine.LFD.0.99999.0711261635570.9605@xanadu.home","threadId":"11016","inReplyTo":"Pine.LNX.4.64.0711262124411.27959@racer.site","subject":"Re: If you would write git from scratch now, what would you change?","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-11-26T21:39:23Z","receivedAt":"2007-11-26T21:39:23Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Mon, 26 Nov 2007, Johannes Schindelin wrote:\n\n> Hi,\n> \n> On Mon, 26 Nov 2007, Nicolas Pitre wrote:\n> \n> > On Mon, 26 Nov 2007, David Kastrup wrote:\n> > \n> > > Get rid of plumbing at the command line level.\n> > \n> > We can't get rid of plumbing. It is part of Git probably forever and is \n> > really really convenient for scripting in any language you want.\n> \n> I agree, but that's not even the complete truth. Git would be not even \n> half as useful as it is without its scriptability.\n\nSure, but this is missing the point.\n\nThe issue at hand is about the fact that way too many Git commands are \nto be found in the default command path. Diverging on whether or not \nplumbing is useful is the wrong question.\n\n\nNicolas\n"},{"id":"60995","messageId":"Pine.LNX.4.64.0711262140170.27959@racer.site","threadId":"11016","inReplyTo":"alpine.LFD.0.99999.0711261635570.9605@xanadu.home","subject":"Re: If you would write git from scratch now, what would you change?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-11-26T21:40:49Z","receivedAt":"2007-11-26T21:40:49Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 26 Nov 2007, Nicolas Pitre wrote:\n\n> On Mon, 26 Nov 2007, Johannes Schindelin wrote:\n> \n> > I agree, but that's not even the complete truth. Git would be not \n> > even half as useful as it is without its scriptability.\n> \n> Sure, but this is missing the point.\n> \n> The issue at hand is about the fact that way too many Git commands are \n> to be found in the default command path. Diverging on whether or not \n> plumbing is useful is the wrong question.\n\nAh, thanks. I use a spam filter here, so I did not get the complete \ncontext.\n\nSorry,\nDscho\n"},{"id":"60998","messageId":"7v3ausfzmh.fsf@gitster.siamese.dyndns.org","threadId":"11016","inReplyTo":"alpine.LFD.0.99999.0711261631170.9605@xanadu.home","subject":"Re: If you would write git from scratch now, what would you change?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-26T21:47:18Z","receivedAt":"2007-11-26T21:47:18Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nicolas Pitre writes:\n\n> On Mon, 26 Nov 2007, Junio C Hamano wrote:\n>\n>> Wincent Colaiuta writes:\n>> \n>> > For the benefit of newcomers, I just wish the plumbing was kept a \n>> > little bit out of sight. You know, porcelain in /usr/bin and plumbing \n>> > in /usr/libexec or other such place.\n>> >\n>> > It's fine once you've learnt your workflows and know the 10 or 15 Git \n>> > tools that you'll be using day-to-day; but for people who are just \n>> > starting off this can be a little bit intimidating:\n>> >\n>> > $ git-\n>> > Display all 146 possibilities? (y or n)\n>> \n>> I'd agree to that but I've always considered this an issue for distros.\n>> We've supported an ability for them to specify a gitexecdir separate\n>> from /usr/bin in our Makefile for almost two years.\n>\n> Would probably be a good thing to start enforcing that by default. It's \n> easier to follow such policies when they're coordinated from the project \n> origin.\n\nNot really. The project origin ships the Makefile to install under\n$HOME, but I do not see any distros following that.\n"},{"id":"61000","messageId":"56b7f5510711261402s35b77879xdcb2492ea14a1791@mail.gmail.com","threadId":"11016","inReplyTo":"alpine.LFD.0.99999.0711261529080.9605@xanadu.home","subject":"Re: If you would write git from scratch now, what would you change?","fromName":"Dana How","fromEmail":"danahow@gmail.com","sentAt":"2007-11-26T22:02:45Z","receivedAt":"2007-11-26T22:02:45Z","isPatch":false,"sender":{"key":"danahow@gmail.com","avatar":null},"body":"On Nov 26, 2007 12:55 PM, Nicolas Pitre wrote:\n> On Mon, 26 Nov 2007, Dana How wrote:\n> > On Nov 26, 2007 11:52 AM, Nicolas Pitre wrote:\n> > > On Mon, 26 Nov 2007, Dana How wrote:\n> > > Then you can do just that for big enough blobs where \"big enough\" is\n> > > configurable: encapsulate them in a pack instead of a loose object.\n> > > Problem solved. Sure you'll end up with a bunch of packs containing\n> > > only one blob object, but given that those blobs are so large to be a\n> > > problem in your work flow when written out as loose objects, then they\n> > > certainly must be few enough not to cause an explosion in the number of\n> > > packs.\n> > Are you suggesting that \"git add\" create a new pack containing\n> > one blob when the blob is big enough?\n> Exactly.\nI will think about your suggestion\n(and the number of packs that might result),\nbut I confess I am surprised by it.\n\nWhen I proposed automatically extracting large blobs from source\npacks when creating a new pack under a blob size limit while\npack-objects was running, you objected on the grounds that\npack-objects only creates packs and should not create blobs\n(this proposal had other problems too, but this is the one you didn't like).\n\nNow it's OK for git-add to sometimes create packs instead of blobs?\nI would not have predicted that!\n\n;-)\n-- \nDana L. How danahow@gmail.com +1 650 804 5991 cell\n"},{"id":"61001","messageId":"alpine.LFD.0.99999.0711261703050.9605@xanadu.home","threadId":"11016","inReplyTo":"7v3ausfzmh.fsf@gitster.siamese.dyndns.org","subject":"Re: If you would write git from scratch now, what would you change?","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-11-26T22:03:37Z","receivedAt":"2007-11-26T22:03:37Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Mon, 26 Nov 2007, Junio C Hamano wrote:\n\n> Nicolas Pitre writes:\n> \n> > On Mon, 26 Nov 2007, Junio C Hamano wrote:\n> >\n> >> Wincent Colaiuta writes:\n> >> \n> >> > For the benefit of newcomers, I just wish the plumbing was kept a \n> >> > little bit out of sight. You know, porcelain in /usr/bin and plumbing \n> >> > in /usr/libexec or other such place.\n> >> >\n> >> > It's fine once you've learnt your workflows and know the 10 or 15 Git \n> >> > tools that you'll be using day-to-day; but for people who are just \n> >> > starting off this can be a little bit intimidating:\n> >> >\n> >> > $ git-\n> >> > Display all 146 possibilities? (y or n)\n> >> \n> >> I'd agree to that but I've always considered this an issue for distros.\n> >> We've supported an ability for them to specify a gitexecdir separate\n> >> from /usr/bin in our Makefile for almost two years.\n> >\n> > Would probably be a good thing to start enforcing that by default. It's \n> > easier to follow such policies when they're coordinated from the project \n> > origin.\n> \n> Not really. The project origin ships the Makefile to install under\n> $HOME, but I do not see any distros following that.\n\nWhat about the default RPM spec file?\n\n\nNicolas\n"},{"id":"61004","messageId":"alpine.LFD.0.99999.0711261712400.9605@xanadu.home","threadId":"11016","inReplyTo":"56b7f5510711261402s35b77879xdcb2492ea14a1791@mail.gmail.com","subject":"Re: If you would write git from scratch now, what would you change?","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-11-26T22:22:38Z","receivedAt":"2007-11-26T22:22:38Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Mon, 26 Nov 2007, Dana How wrote:\n\n> On Nov 26, 2007 12:55 PM, Nicolas Pitre wrote:\n> > On Mon, 26 Nov 2007, Dana How wrote:\n> > > On Nov 26, 2007 11:52 AM, Nicolas Pitre wrote:\n> > > > On Mon, 26 Nov 2007, Dana How wrote:\n> > > > Then you can do just that for big enough blobs where \"big enough\" is\n> > > > configurable: encapsulate them in a pack instead of a loose object.\n> > > > Problem solved. Sure you'll end up with a bunch of packs containing\n> > > > only one blob object, but given that those blobs are so large to be a\n> > > > problem in your work flow when written out as loose objects, then they\n> > > > certainly must be few enough not to cause an explosion in the number of\n> > > > packs.\n> > > Are you suggesting that \"git add\" create a new pack containing\n> > > one blob when the blob is big enough?\n> > Exactly.\n> I will think about your suggestion\n> (and the number of packs that might result),\n> but I confess I am surprised by it.\n> \n> When I proposed automatically extracting large blobs from source\n> packs when creating a new pack under a blob size limit while\n> pack-objects was running, you objected on the grounds that\n> pack-objects only creates packs and should not create blobs\n> (this proposal had other problems too, but this is the one you didn't like).\n> \n> Now it's OK for git-add to sometimes create packs instead of blobs?\n> I would not have predicted that!\n\nGoing back to loose objects from packs is indeed something I object to \nif it becomes part of a work flow. Objects should move from the loose \nspace towards the packed space and not the other way around. Sure there \nis fetch.unpackLimit, but with the auto-repack recently added to Git \nthis variable could probably be set even lower.\n\nBut having a pack created for huge blobs up front has many advantages, \nthe most obvious is the fact that later repack can combine and/or send \nthose single-blob packs with almost no cost.\n\nLoose objects are meant to be blazingly fast to create. Once repacked \nthey have no advantage being loose again. Obviously when your blob is \nhuge you won't benefit much from a loose object.\n\n\nNicolas\n"},{"id":"61011","messageId":"20071127010350.GE14735@spearce.org","threadId":"11016","inReplyTo":"7vhcj8g0op.fsf@gitster.siamese.dyndns.org","subject":"Re: If you would write git from scratch now, what would you change?","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-11-27T01:03:50Z","receivedAt":"2007-11-27T01:03:50Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Junio C Hamano wrote:\n> Wincent Colaiuta writes:\n> >\n> > $ git-\n> > Display all 146 possibilities? (y or n)\n> \n> The tab completion for bash and zsh would also help you here, but I see\n> there are quite a few commands that should not be there, and it's time\n> to clean it up.\n...\n> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash\n> index cad842a..1bba68b 100755\n> --- a/contrib/completion/git-completion.bash\n> +++ b/contrib/completion/git-completion.bash\n> @@ -359,6 +359,15 @@ __git_commands ()\n> \t\tupload-pack) : plumbing;;\n> \t\twrite-tree) : plumbing;;\n> \t\tverify-tag) : plumbing;;\n> +\t\tannotate) : use blame;;\n> +\t\tcheckout-index) : plumbing;;\n> +\t\tdiff-stages) : plumbing;;\n> +\t\tget-tar-commit-id) : plumbing;;\n> +\t\tlost-found) : deprecated;;\n> +\t\trebase--interactive) : plumbing;;\n> +\t\trelink) : obsolete;;\n> +\t\twhatchanged) : plumbing;;\n> +\t\tverify-pack) : plumbing;;\n> \t\t*) echo $i;;\n> \t\tesac\n> \tdone\n\nAck'd-by: Shawn O. Pearce \n\n;-)\n\n-- \nShawn.\n"},{"id":"61013","messageId":"20071127012013.GG14735@spearce.org","threadId":"11016","inReplyTo":"e5bfff550711261125i92fb057i85d7217b18cd495d@mail.gmail.com","subject":"Re: If you would write git from scratch now, what would you change?","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-11-27T01:20:13Z","receivedAt":"2007-11-27T01:20:13Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Marco Costalba wrote:\n> On Nov 26, 2007 5:46 PM, Andy Parkins wrote:\n> > Jakub Narebski wrote:\n> >\n> > > If you would write git from scratch now, from the beginning, without\n> > > concerns for backwards compatibility, what would you change, or what\n> > > would you want to have changed?\n> >\n> > - \"git-gui\" would be written in Qt (ducks)\n> \n> But...wait...Qt would require...(I'm scared to say!)... that awful,\n> painful, hopeless thing called C++. Probably you didn't mean what you\n> said ;-)\n\nHeh.\n\nI'll never port git-gui to Qt. Because of that awful, painful\nthing called C++ that it uses. I despise C++. No, please don't\nstart a C++ language war again on the list. :-)\n\n\nI recently considered porting git-gui to XUL, as nobody has ever\nsaid \"Firefox isn't native enough on my OS!\". It also (maybe) has\nthe benefit of having a large developer base (everyone and their\ndog has coded in HTML and Javascript before, except maybe Linus).\n\nBut XUL doesn't support launching a process and connecting pipes\nto its stdin and stdout. I started to try and create an XPCOM\nextension to provide that functionality from NSPR and started to\nrun into major problems compiling the XPCOM plugin, getting the\nnecessary interfaces implemented, etc.\n\nIn the end I was able to recreate the bulk of the main git-gui UI in\nXUL in just an hour or so, but spent days trying to just do a basic\nthing like \"git diff-index --cached -z HEAD\" and consume the result.\nI never even got that to work so I just gave up on the idea.\n\n\nSo git-gui is in Tcl/Tk for the long-term. However I'm going\nto try and port git-gui over to the Tcl/Tk 8.5 \"tiles\" extension\n(if it is available on your system) so we can get better looking\nnative widgets. I'll still fall back to the old style widgets for\nTcl/Tk 8.4 so existing users aren't forced to upgrade to 8.5 just\nto use the latest git-gui. (But really, 8.5 isn't that hard to\nbuild and install...)\n\n-- \nShawn.\n"},{"id":"61014","messageId":"20071127012518.GH14735@spearce.org","threadId":"11016","inReplyTo":"56b7f5510711261118m7a402beah5d9cb75c1ad10b43@mail.gmail.com","subject":"Re: If you would write git from scratch now, what would you change?","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-11-27T01:25:18Z","receivedAt":"2007-11-27T01:25:18Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Dana How wrote:\n> On Nov 25, 2007 1:48 PM, Jakub Narebski wrote:\n> > If you would write git from scratch now, from the beginning, without\n> > concerns for backwards compatibility, what would you change, or what\n> > would you want to have changed?\n> \n> Currently data can be quickly copied from pack to pack,\n> but data cannot be quickly copied blob->pack or pack->blob\n\nI agree with Nico's comment that you probably don't need pack->loose\nobject as its just not something you want to do. But otherwise\nabove you mean \"loose->pack\" or \"pack->loose\" as blob is one type\nof loose object but there are others (tree, commit, tag).\n\n> (there was an alternate blob format that supported this,\n> but it was deprecated). Using the pack format for blobs\n> would fix this. It would also mean blobs wouldn't need to\n> be uncompressed to get the blob type or size I believe.\n\nThe alternate format for loose objects *was* the packfile format,\nbut without the packfile header or trailer as that was really\nquite unnecessary for a single object storage.\n\nUnfortunately we removed that alternate format from the system.\nWe can't create it anymore. We can't efficiently copy it to the\npackfile anymore. But we can still read it in case someone still\nhas loose objects using that alternate format in their repository.\n\nI was sad when Nico removed the format in 726f852b0ed7e. I can\nunderstand why he did so but I think it was a move in the wrong\ndirection.\n\n-- \nShawn.\n"},{"id":"61016","messageId":"fifstd$ilj$1@ger.gmane.org","threadId":"11016","inReplyTo":"20071127012013.GG14735@spearce.org","subject":"Re: If you would write git from scratch now, what would you change?","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-11-27T01:46:23Z","receivedAt":"2007-11-27T01:46:23Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Shawn O. Pearce wrote:\n\n[git-gui in XUL]\n\n> But XUL doesn't support launching a process and connecting pipes\n> to its stdin and stdout.  I started to try and create an XPCOM\n> extension to provide that functionality from NSPR and started to\n> run into major problems compiling the XPCOM plugin, getting the\n> necessary interfaces implemented, etc.\n\nWhat about Ajax / Comet support in XUL, Can this be used for that?\n(Just an [perhaps stupid] idea).\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"61017","messageId":"20071127014804.GJ14735@spearce.org","threadId":"11016","inReplyTo":"200711252248.27904.jnareb@gmail.com","subject":"Re: If you would write git from scratch now, what would you change?","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-11-27T01:48:04Z","receivedAt":"2007-11-27T01:48:04Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Jakub Narebski wrote:\n> If you would write git from scratch now, from the beginning, without \n> concerns for backwards compatibility, what would you change, or what \n> would you want to have changed?\n\n- Sort tree entries by name, *not* by name+type\n\n This has got to be my biggest gripe with Git. I think Linus really\n screwed the pooch with this. We've talked it over a few times\n on the list and he and I have just agreed to disagree on this.\n\n Ask any database person and they'll tell you how wrong the\n current tree ordering is. Or they are nuts and don't get\n the concept of data integrity.\n\n Linus' excuse is that the current ordering makes working with\n the flat index faster as its just one index file. That doesn't\n mean that the flat index file can't contain tree information.\n Like it does in say that new fangled cache-tree extension. :-)\n\n This particular \"design decision\" has brought all sorts of bugs\n into the system, like the D/F merge conflict issues, and even one\n from Linus himself when he first introduced the submodule support.\n Lets not even talk about ugly that made things in jgit.\n\n\n- Loose objects storage is difficult to work with\n\n The standard loose object format of DEFLATE(\"$type $size\\0$data\")\n makes it harder to work with as you need to inflate at least\n part of the object just to see what the hell it is or how big\n its final output buffer needs to be.\n\n It also makes it very hard to stream into a packfile if you have\n determined its not worth creating a delta for the object (or no\n suitable delta base is available).\n\n The new (now deprecated) loose object format that was based on\n the packfile header format simplified this and made it much\n easier to work with.\n\n\n- No proper libgit\n\n Already been stated but we don't have a great library and we\n don't have a good way to build one right now either. A lot of\n our internal code assumes die() will abort the process. That's a\n very bad assumption to be making inside of a library.\n\n\n- Binary packed-refs representation\n\n I probably wouldn't have done an ASCII based packed-refs file,\n or heck, even loose refs. I probably would have just gone with\n a binary file that we wholesale rewrite every time there is any\n sort of ref update.\n\n We already do this with the index. So every time we update a\n file path we are rewriting the entire index. And we update\n file paths a heck of a lot more often than we update branch\n heads. Or tags.\n\n But tools like for-each-ref get invoked heavily, and fast access\n to the ref database is important to overall performance.\n\n\n- No GIT_OBJECT_DIRECTORY vs. GIT_DIR distinction\n\n This is causing problems with $GIT_DIR/objects/info/alternates\n and then try to repack repositories. Not having the ref space of\n the alternates and/or borrowers considered during repacking can\n cause all sorts of fun breakage that may be hard to recover from.\n Plus it means you have to do funny \"refs/forkee\" hacks just to\n avoid pushing unnecessary objects over the wire when the other\n end is borrowing objects.\n\n I probably would have had the object directory unified with its\n ref database, so that they cannot be accessed individually.\n\n\nAll of the above is written with 20/20 hindsight and all that.\n\nLooking back (and knowing myself well) I think the only item I\nwould have gotten right if I had written Git from scratch is the\nfirst one above (the tree entry ordering). I probably would have\ndone something equally \"as bad\" as what we have today for all of\nthe others...\n\n-- \nShawn.\n"},{"id":"61019","messageId":"7vd4twe9mn.fsf@gitster.siamese.dyndns.org","threadId":"11016","inReplyTo":"20071127014804.GJ14735@spearce.org","subject":"Re: If you would write git from scratch now, what would you change?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-27T01:54:08Z","receivedAt":"2007-11-27T01:54:08Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Shawn O. Pearce\" writes:\n\n> All of the above is written with 20/20 hindsight and all that.\n>\n> Looking back (and knowing myself well) I think the only item I\n> would have gotten right if I had written Git from scratch is the\n> first one above (the tree entry ordering). I probably would have\n> done something equally \"as bad\" as what we have today for all of\n> the others...\n\n... not to mention countless others you would get wrong that you did not\nlist in the above, as the current git got them right ;-)\n"},{"id":"61020","messageId":"20071127015833.GL14735@spearce.org","threadId":"11016","inReplyTo":"fifstd$ilj$1@ger.gmane.org","subject":"Re: If you would write git from scratch now, what would you change?","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-11-27T01:58:33Z","receivedAt":"2007-11-27T01:58:33Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Jakub Narebski wrote:\n> Shawn O. Pearce wrote:\n> \n> [git-gui in XUL]\n> \n> > But XUL doesn't support launching a process and connecting pipes\n> > to its stdin and stdout.  I started to try and create an XPCOM\n> > extension to provide that functionality from NSPR and started to\n> > run into major problems compiling the XPCOM plugin, getting the\n> > necessary interfaces implemented, etc.\n> \n> What about Ajax / Comet support in XUL, Can this be used for that?\n> (Just an [perhaps stupid] idea).\n\nYes, XUL fully supports AJAX. If it didn't Google Maps and its\ncool interface wouldn't exist. :-)\n\nThe problem there is that AJAX requires HTTP. So I'd have to\ncreate a \"micro HTTP server\" that runs on the loopback interface\nand listens for HTTP requests from the GUI, parses them, runs the\nnecessary Git action, then sends the results back to the GUI.\n\nSort of ugly.\n\nMy bigger concern is also for a shared machine; how do I secure\nthe HTTP server so only the git-gui process that is supposed to\nbe using it is able to access it? I guess I could create a 600\n~/.gitguicookie file or some such entity and throw random data into\nit to initialize it. That's basically all xauth is doing.\n\n\nActually I might revisit this XUL concept using an HTTP server and\nAJAX. I could actually link the damn HTTP server against libgit.a\n(Junio will hate me). If the server dies XUL can notice it and\nsimply restart it. But there's a whole suite of actions that I\ncan run through the internal APIs with high chances of success,\nand a lot quicker than forking the corresponding plumbing process,\nespecially on fork challenged machines like Windows.\n\n-- \nShawn.\n"},{"id":"61021","messageId":"20071127015942.GM14735@spearce.org","threadId":"11016","inReplyTo":"7vd4twe9mn.fsf@gitster.siamese.dyndns.org","subject":"Re: If you would write git from scratch now, what would you change?","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-11-27T01:59:42Z","receivedAt":"2007-11-27T01:59:42Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Junio C Hamano wrote:\n> \"Shawn O. Pearce\" writes:\n> \n> > All of the above is written with 20/20 hindsight and all that.\n> >\n> > Looking back (and knowing myself well) I think the only item I\n> > would have gotten right if I had written Git from scratch is the\n> > first one above (the tree entry ordering). I probably would have\n> > done something equally \"as bad\" as what we have today for all of\n> > the others...\n> \n> ... not to mention countless others you would get wrong that you did not\n> list in the above, as the current git got them right ;-)\n\nIndeed.\n\nWhich is why nobody is looking to rewrite Git from scratch.\n\nExcept myself and a few other nuts who want a pure Java\nimplementation for Eclipse plugins. :-)\n\n-- \nShawn.\n"},{"id":"61024","messageId":"200711270315.56849.jnareb@gmail.com","threadId":"11016","inReplyTo":"20071127015942.GM14735@spearce.org","subject":"Re: If you would write git from scratch now, what would you change?","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-11-27T02:15:55Z","receivedAt":"2007-11-27T02:15:55Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Shawn O. Pearce wrote:\n> Junio C Hamano wrote:\n>>\n>> ... not to mention countless others you would get wrong that you did not\n>> list in the above, as the current git got them right ;-)\n> \n> Indeed.\n> \n> Which is why nobody is looking to rewrite Git from scratch.\n> \n> Except myself and a few other nuts who want a pure Java\n> implementation for Eclipse plugins. :-)\n\nAnd the project to implement git in C# / Mono (I wonder what is\nthe status of those implementations...)\n\n-- \nJakub Narebski\nPoland\n"},{"id":"61025","messageId":"7v7ik4e4xa.fsf@gitster.siamese.dyndns.org","threadId":"11016","inReplyTo":"20071127010350.GE14735@spearce.org","subject":"Re: If you would write git from scratch now, what would you change?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-27T03:35:45Z","receivedAt":"2007-11-27T03:35:45Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Shawn O. Pearce\" writes:\n\n> Junio C Hamano wrote:\n>> Wincent Colaiuta writes:\n>> >\n>> > $ git-\n>> > Display all 146 possibilities? (y or n)\n>> \n>> The tab completion for bash and zsh would also help you here, but I see\n>> there are quite a few commands that should not be there, and it's time\n>> to clean it up.\n> ...\n>> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash\n>> index cad842a..1bba68b 100755\n>> --- a/contrib/completion/git-completion.bash\n>> +++ b/contrib/completion/git-completion.bash\n>> @@ -359,6 +359,15 @@ __git_commands ()\n>> \t\tupload-pack) : plumbing;;\n>> \t\twrite-tree) : plumbing;;\n>> \t\tverify-tag) : plumbing;;\n>> +\t\tannotate) : use blame;;\n>> +\t\tcheckout-index) : plumbing;;\n>> +\t\tdiff-stages) : plumbing;;\n>> +\t\tget-tar-commit-id) : plumbing;;\n>> +\t\tlost-found) : deprecated;;\n>> +\t\trebase--interactive) : plumbing;;\n>> +\t\trelink) : obsolete;;\n>> +\t\twhatchanged) : plumbing;;\n>> +\t\tverify-pack) : plumbing;;\n>> \t\t*) echo $i;;\n>> \t\tesac\n>> \tdone\n>\n> Ack'd-by: Shawn O. Pearce \n>\n> ;-)\n\nSeriously, speaking I find this \"negative\" list ugly. I am wondering if\nit makes more sense to use positive \"Porcelain\" list, or perhaps even\n\"The most commonly used\" list from \"git help\" output.\n\nHere is an alternate attempt to it.\n\n---\n\n Documentation/cmd-list.perl | 59 ++++++++++++------------\n Makefile | 2 +-\n contrib/completion/git-completion.bash | 77 ++------------------------------\n generate-cmdlist.sh | 34 ++------------\n 4 files changed, 40 insertions(+), 132 deletions(-)\n\ndiff --git a/Documentation/cmd-list.perl b/Documentation/cmd-list.perl\nindex b709551..a966b5e 100755\n--- a/Documentation/cmd-list.perl\n+++ b/Documentation/cmd-list.perl\n@@ -26,10 +26,11 @@ sub format_one {\n \tif (!defined $description) {\n \t\tdie \"No description found in $name.txt\";\n \t}\n+\n \tif (my ($verify_name, $text) = ($description =~ /^($name) - (.*)/)) {\n \t\tprint $out \"gitlink:$name\\[1\\]::\\n\\t\";\n-\t\tif ($attr) {\n-\t\t\tprint $out \"($attr) \";\n+\t\tif ($attr =~ /deprecated/) {\n+\t\t\tprint $out \"(deprecated) \";\n \t\t}\n \t\tprint $out \"$text.\\n\\n\";\n \t}\n@@ -75,27 +76,27 @@ for my $cat (qw(ancillaryinterrogators\n # The following list is sorted with \"sort -d\" to make it easier\n # to find entry in the resulting git.html manual page.\n __DATA__\n-git-add mainporcelain\n+git-add mainporcelain common\n git-am mainporcelain\n git-annotate ancillaryinterrogators\n-git-apply plumbingmanipulators\n+git-apply plumbingmanipulators common\n git-archimport foreignscminterface\n-git-archive mainporcelain\n-git-bisect mainporcelain\n+git-archive mainporcelain common\n+git-bisect mainporcelain common\n git-blame ancillaryinterrogators\n-git-branch mainporcelain\n+git-branch mainporcelain common\n git-bundle mainporcelain\n git-cat-file plumbinginterrogators\n git-check-attr purehelpers\n-git-checkout mainporcelain\n+git-checkout mainporcelain common\n git-checkout-index plumbingmanipulators\n git-check-ref-format purehelpers\n git-cherry ancillaryinterrogators\n-git-cherry-pick mainporcelain\n+git-cherry-pick mainporcelain common\n git-citool mainporcelain\n git-clean mainporcelain\n-git-clone mainporcelain\n-git-commit mainporcelain\n+git-clone mainporcelain common\n+git-commit mainporcelain common\n git-commit-tree plumbingmanipulators\n git-config ancillarymanipulators\n git-count-objects ancillaryinterrogators\n@@ -104,12 +105,12 @@ git-cvsimport foreignscminterface\n git-cvsserver foreignscminterface\n git-daemon synchingrepositories\n git-describe mainporcelain\n-git-diff mainporcelain\n+git-diff mainporcelain common\n git-diff-files plumbinginterrogators\n git-diff-index plumbinginterrogators\n git-diff-tree plumbinginterrogators\n git-fast-import\t\t\t\tancillarymanipulators\n-git-fetch mainporcelain\n+git-fetch mainporcelain common\n git-fetch-pack synchingrepositories\n git-filter-branch ancillarymanipulators\n git-fmt-merge-msg purehelpers\n@@ -118,24 +119,24 @@ git-format-patch mainporcelain\n git-fsck\t ancillaryinterrogators\n git-gc mainporcelain\n git-get-tar-commit-id ancillaryinterrogators\n-git-grep mainporcelain\n+git-grep mainporcelain common\n git-gui mainporcelain\n git-hash-object plumbingmanipulators\n git-http-fetch synchelpers\n git-http-push synchelpers\n git-imap-send foreignscminterface\n git-index-pack plumbingmanipulators\n-git-init mainporcelain\n+git-init mainporcelain common\n git-instaweb ancillaryinterrogators\n gitk mainporcelain\n-git-log mainporcelain\n+git-log mainporcelain common\n git-lost-found ancillarymanipulators\tdeprecated\n git-ls-files plumbinginterrogators\n git-ls-remote plumbinginterrogators\n git-ls-tree plumbinginterrogators\n git-mailinfo purehelpers\n git-mailsplit purehelpers\n-git-merge mainporcelain\n+git-merge mainporcelain common\n git-merge-base plumbinginterrogators\n git-merge-file plumbingmanipulators\n git-merge-index plumbingmanipulators\n@@ -144,7 +145,7 @@ git-mergetool ancillarymanipulators\n git-merge-tree ancillaryinterrogators\n git-mktag plumbingmanipulators\n git-mktree plumbingmanipulators\n-git-mv mainporcelain\n+git-mv mainporcelain common\n git-name-rev plumbinginterrogators\n git-pack-objects plumbingmanipulators\n git-pack-redundant plumbinginterrogators\n@@ -152,13 +153,13 @@ git-pack-refs ancillarymanipulators\n git-parse-remote synchelpers\n git-patch-id purehelpers\n git-peek-remote purehelpers\tdeprecated\n-git-prune ancillarymanipulators\n+git-prune ancillarymanipulators common\n git-prune-packed plumbingmanipulators\n-git-pull mainporcelain\n-git-push mainporcelain\n+git-pull mainporcelain common\n+git-push mainporcelain common\n git-quiltimport foreignscminterface\n git-read-tree plumbingmanipulators\n-git-rebase mainporcelain\n+git-rebase mainporcelain common\n git-receive-pack synchelpers\n git-reflog ancillarymanipulators\n git-relink ancillarymanipulators\n@@ -166,28 +167,28 @@ git-remote ancillarymanipulators\n git-repack ancillarymanipulators\n git-request-pull foreignscminterface\n git-rerere ancillaryinterrogators\n-git-reset mainporcelain\n-git-revert mainporcelain\n+git-reset mainporcelain common\n+git-revert mainporcelain common\n git-rev-list plumbinginterrogators\n git-rev-parse ancillaryinterrogators\n-git-rm mainporcelain\n+git-rm mainporcelain common\n git-runstatus ancillaryinterrogators\n git-send-email foreignscminterface\n git-send-pack synchingrepositories\n git-shell synchelpers\n git-shortlog mainporcelain\n-git-show mainporcelain\n-git-show-branch ancillaryinterrogators\n+git-show mainporcelain common\n+git-show-branch ancillaryinterrogators common\n git-show-index plumbinginterrogators\n git-show-ref plumbinginterrogators\n git-sh-setup purehelpers\n git-stash mainporcelain\n-git-status mainporcelain\n+git-status mainporcelain common\n git-stripspace purehelpers\n git-submodule mainporcelain\n git-svn foreignscminterface\n git-symbolic-ref plumbingmanipulators\n-git-tag mainporcelain\n+git-tag mainporcelain common\n git-tar-tree plumbinginterrogators\tdeprecated\n git-unpack-file plumbinginterrogators\n git-unpack-objects plumbingmanipulators\ndiff --git a/Makefile b/Makefile\nindex ccf522a..ca1c2f5 100644\n--- a/Makefile\n+++ b/Makefile\n@@ -804,7 +804,7 @@ git-merge-subtree$X: git-merge-recursive$X\n $(BUILT_INS): git$X\n \t$(QUIET_BUILT_IN)$(RM) $@ && ln git$X $@\n \n-common-cmds.h: ./generate-cmdlist.sh\n+common-cmds.h: ./generate-cmdlist.sh Documentation/cmd-list.perl\n \n common-cmds.h: $(wildcard Documentation/git-*.txt)\n \t$(QUIET_GEN)./generate-cmdlist.sh > $@+ && mv $@+ $@\ndiff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash\nindex 599b2fc..d54b415 100755\n--- a/contrib/completion/git-completion.bash\n+++ b/contrib/completion/git-completion.bash\n@@ -287,79 +287,10 @@ __git_commands ()\n \t\techo \"$__git_commandlist\"\n \t\treturn\n \tfi\n-\tlocal i IFS=\" \"$'\\n'\n-\tfor i in $(git help -a|egrep '^ ')\n-\tdo\n-\t\tcase $i in\n-\t\tadd--interactive) : plumbing;;\n-\t\tapplymbox) : ask gittus;;\n-\t\tapplypatch) : ask gittus;;\n-\t\tarchimport) : import;;\n-\t\tcat-file) : plumbing;;\n-\t\tcheck-attr) : plumbing;;\n-\t\tcheck-ref-format) : plumbing;;\n-\t\tcommit-tree) : plumbing;;\n-\t\tcvsexportcommit) : export;;\n-\t\tcvsimport) : import;;\n-\t\tcvsserver) : daemon;;\n-\t\tdaemon) : daemon;;\n-\t\tdiff-files) : plumbing;;\n-\t\tdiff-index) : plumbing;;\n-\t\tdiff-tree) : plumbing;;\n-\t\tfast-import) : import;;\n-\t\tfsck-objects) : plumbing;;\n-\t\tfetch--tool) : plumbing;;\n-\t\tfetch-pack) : plumbing;;\n-\t\tfmt-merge-msg) : plumbing;;\n-\t\tfor-each-ref) : plumbing;;\n-\t\thash-object) : plumbing;;\n-\t\thttp-*) : transport;;\n-\t\tindex-pack) : plumbing;;\n-\t\tinit-db) : deprecated;;\n-\t\tlocal-fetch) : plumbing;;\n-\t\tmailinfo) : plumbing;;\n-\t\tmailsplit) : plumbing;;\n-\t\tmerge-*) : plumbing;;\n-\t\tmktree) : plumbing;;\n-\t\tmktag) : plumbing;;\n-\t\tpack-objects) : plumbing;;\n-\t\tpack-redundant) : plumbing;;\n-\t\tpack-refs) : plumbing;;\n-\t\tparse-remote) : plumbing;;\n-\t\tpatch-id) : plumbing;;\n-\t\tpeek-remote) : plumbing;;\n-\t\tprune) : plumbing;;\n-\t\tprune-packed) : plumbing;;\n-\t\tquiltimport) : import;;\n-\t\tread-tree) : plumbing;;\n-\t\treceive-pack) : plumbing;;\n-\t\treflog) : plumbing;;\n-\t\trepo-config) : plumbing;;\n-\t\trerere) : plumbing;;\n-\t\trev-list) : plumbing;;\n-\t\trev-parse) : plumbing;;\n-\t\trunstatus) : plumbing;;\n-\t\tsh-setup) : internal;;\n-\t\tshell) : daemon;;\n-\t\tsend-pack) : plumbing;;\n-\t\tshow-index) : plumbing;;\n-\t\tssh-*) : transport;;\n-\t\tstripspace) : plumbing;;\n-\t\tsvn) : import export;;\n-\t\tsymbolic-ref) : plumbing;;\n-\t\ttar-tree) : deprecated;;\n-\t\tunpack-file) : plumbing;;\n-\t\tunpack-objects) : plumbing;;\n-\t\tupdate-index) : plumbing;;\n-\t\tupdate-ref) : plumbing;;\n-\t\tupdate-server-info) : daemon;;\n-\t\tupload-archive) : plumbing;;\n-\t\tupload-pack) : plumbing;;\n-\t\twrite-tree) : plumbing;;\n-\t\tverify-tag) : plumbing;;\n-\t\t*) echo $i;;\n-\t\tesac\n-\tdone\n+\tgit help | sed -e '\n+\t\t1,/^The most commonly used git/d\n+\t\ts/^ *\\([^ ][^ ]*\\)[ ].*/\\1/\n+\t'\n }\n __git_commandlist=\n __git_commandlist=\"$(__git_commands 2>/dev/null)\"\ndiff --git a/generate-cmdlist.sh b/generate-cmdlist.sh\nindex 17df47b..28f9749 100755\n--- a/generate-cmdlist.sh\n+++ b/generate-cmdlist.sh\n@@ -9,35 +9,11 @@ struct cmdname_help\n \n static struct cmdname_help common_cmds[] = {\"\n \n-sort <<\\EOF |\n-add\n-apply\n-archive\n-bisect\n-branch\n-checkout\n-cherry-pick\n-clone\n-commit\n-diff\n-fetch\n-grep\n-init\n-log\n-merge\n-mv\n-prune\n-pull\n-push\n-rebase\n-reset\n-revert\n-rm\n-show\n-show-branch\n-status\n-tag\n-EOF\n+sed -n -e '\n+\t1,/__DATA__/d\n+\ts/^git-\\([^ \t]*\\)[ \t].*[ \t]common/\\1/p\n+' Documentation/cmd-list.perl |\n+sort |\n while read cmd\n do\n sed -n '\n"},{"id":"61027","messageId":"alpine.LFD.0.99999.0711262346410.9605@xanadu.home","threadId":"11016","inReplyTo":"20071127014804.GJ14735@spearce.org","subject":"Re: If you would write git from scratch now, what would you change?","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-11-27T04:58:55Z","receivedAt":"2007-11-27T04:58:55Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Mon, 26 Nov 2007, Shawn O. Pearce wrote:\n\n> - Loose objects storage is difficult to work with\n> \n> The standard loose object format of DEFLATE(\"$type $size\\0$data\")\n> makes it harder to work with as you need to inflate at least\n> part of the object just to see what the hell it is or how big\n> its final output buffer needs to be.\n\nIt is a bit cumbersome indeed, but I'm afraid we're really stuck with it \nsince every object SHA1 depends on that format.\n\n> It also makes it very hard to stream into a packfile if you have\n> determined its not worth creating a delta for the object (or no\n> suitable delta base is available).\n> \n> The new (now deprecated) loose object format that was based on\n> the packfile header format simplified this and made it much\n> easier to work with.\n\nNot really. Since separate zlib compression levels for loose objects \nand packed objects were introduced, there was a bunch of correctness \nissues. What do you do when both compression levels are different? \nSometimes ignore them, sometimes not? Because the default loose object \ncompression level is about speed and the default pack compression level \nis about good space reduction, the correct thing to do by default would \nhave been to always decompress and recompress anyway when copying an \notherwise unmodified loose object into a pack.\n\n\nNicolas\n"},{"id":"61028","messageId":"alpine.LFD.0.99999.0711262359080.9605@xanadu.home","threadId":"11016","inReplyTo":"20071127012518.GH14735@spearce.org","subject":"Re: If you would write git from scratch now, what would you change?","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-11-27T05:07:41Z","receivedAt":"2007-11-27T05:07:41Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Mon, 26 Nov 2007, Shawn O. Pearce wrote:\n\n> Dana How wrote:\n> > (there was an alternate blob format that supported this,\n> > but it was deprecated). Using the pack format for blobs\n> > would fix this. It would also mean blobs wouldn't need to\n> > be uncompressed to get the blob type or size I believe.\n> \n> The alternate format for loose objects *was* the packfile format,\n> but without the packfile header or trailer as that was really\n> quite unnecessary for a single object storage.\n\nWhat I'm suggesting, though, is to actually create a real pack for those \nblobs where the recompression is really an issue. all the code is \nthere and only needs to be called.\n\nIn most usage cases, though, the proportion of blobs that gets copied \ndirectly into a pack is minimal, and even then they don't amount to a \nlot of cycles compared to the majority of deltified objects.\n\n(yeah, \"deltified\" is said to be wrong by some, but it is really \n convenient a word.)\n\n> I was sad when Nico removed the format in 726f852b0ed7e. I can\n> understand why he did so but I think it was a move in the wrong\n> direction.\n\nI wish I could convince you otherwise by now.\n\n\nNicolas\n"},{"id":"61029","messageId":"83D4511B-BE07-4098-9901-44C164467F76@midwinter.com","threadId":"11016","inReplyTo":"7v7ik4e4xa.fsf@gitster.siamese.dyndns.org","subject":"Re: If you would write git from scratch now, what would you change?","fromName":"Steven Grimm","fromEmail":"koreth@midwinter.com","sentAt":"2007-11-27T05:10:15Z","receivedAt":"2007-11-27T05:10:15Z","isPatch":false,"sender":{"key":"koreth@midwinter.com","avatar":"https://gravatar.com/avatar/71b4d2e8b62f168bdc9e9205341159e3567003b4f9e2127c617c5fa0a1f5bad2?d=mp&s=160"},"body":"On Nov 26, 2007, at 7:35 PM, Junio C Hamano wrote:\n> Seriously, speaking I find this \"negative\" list ugly. I am \n> wondering if\n> it makes more sense to use positive \"Porcelain\" list, or perhaps even\n> \"The most commonly used\" list from \"git help\" output.\n\nYes, a positive list makes much more sense. If for no other reason \nthan that it will require the author of a new command to make a \nconscious decision before that command will be suggested to users.\n\n-Steve\n"},{"id":"61030","messageId":"56b7f5510711262159x2e1fd4fdw8e914cb4a22376a1@mail.gmail.com","threadId":"11016","inReplyTo":"alpine.LFD.0.99999.0711262346410.9605@xanadu.home","subject":"Re: If you would write git from scratch now, what would you change?","fromName":"Dana How","fromEmail":"danahow@gmail.com","sentAt":"2007-11-27T05:59:15Z","receivedAt":"2007-11-27T05:59:15Z","isPatch":false,"sender":{"key":"danahow@gmail.com","avatar":null},"body":"On Nov 26, 2007 8:58 PM, Nicolas Pitre wrote:\n> On Mon, 26 Nov 2007, Shawn O. Pearce wrote:\n> > - Loose objects storage is difficult to work with\n> >\n> > The standard loose object format of DEFLATE(\"$type $size\\0$data\")\n> > makes it harder to work with as you need to inflate at least\n> > part of the object just to see what the hell it is or how big\n> > its final output buffer needs to be.\n>\n> It is a bit cumbersome indeed, but I'm afraid we're really stuck with it\n> since every object SHA1 depends on that format.\n\nYes, now I remember: this was the same argument you used to\nconvince me that losing the \"new\" (deprecated) loose format was OK.\n\nHowever, if we changed\nWRITE(DEFLATE(SHA1(\"$type $size\\0$data\")))\n(where SHA1(x) = x but has the side-effect of updating the SHA-1)\nto\nWRITE($pack_style_object_header)\nSHA1(\"$type $size\\0\")\nWRITE(DEFLATE(SHA1($data)))\nthen the SHA-1 result is the same but we get the pack-style header,\nand blobs can be sucked straight into packs when not deltified.\nThe SHA-1 result is still usable at the end to rename the temporary\nloose object file\n(and put it in the correct xx subdirectory).\n\nBecause we can't change the SHA-1 result we unfortunately can\nnever drop the 2nd call above [this is something that could\nhave been different, to respond to the email that started this thread].\nYou didn't like the duplication between the 1st and 2nd call,\nbut I can't say I see that as a big deal.\n\n> > It also makes it very hard to stream into a packfile if you have\n> > determined its not worth creating a delta for the object (or no\n> > suitable delta base is available).\n> >\n> > The new (now deprecated) loose object format that was based on\n> > the packfile header format simplified this and made it much\n> > easier to work with.\n>\n> Not really. Since separate zlib compression levels for loose objects\n> and packed objects were introduced, there was a bunch of correctness\n> issues. What do you do when both compression levels are different?\n> Sometimes ignore them, sometimes not? Because the default loose object\n> compression level is about speed and the default pack compression level\n> is about good space reduction, the correct thing to do by default would\n> have been to always decompress and recompress anyway when copying an\n> otherwise unmodified loose object into a pack.\nNot exactly. I did think about this. When you are packing to stdout,\nand only sending the resulting packfile locally, you don't want to\nbother with recompressing everything. [This is the \"workgroup\" case\nthat concerns me.] Other cases, sure,\nrecompression could help (e.g., packing to a file means the file\nwill probably be around for a while, so you want to recompress\nif the levels are unequal; and you probably want to recompress\nas well if the packfile will be sent over a \"slow\" link).\n\nThanks,\n-- \nDana L. How danahow@gmail.com +1 650 804 5991 cell\n"},{"id":"61031","messageId":"20071127061210.GP14735@spearce.org","threadId":"11016","inReplyTo":"56b7f5510711262159x2e1fd4fdw8e914cb4a22376a1@mail.gmail.com","subject":"Re: If you would write git from scratch now, what would you change?","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-11-27T06:12:10Z","receivedAt":"2007-11-27T06:12:10Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Dana How wrote:\n> On Nov 26, 2007 8:58 PM, Nicolas Pitre wrote:\n> >\n> > It is a bit cumbersome indeed, but I'm afraid we're really stuck with it\n> > since every object SHA1 depends on that format.\n> \n> Yes, now I remember: this was the same argument you used to\n> convince me that losing the \"new\" (deprecated) loose format was OK.\n> \n> However, if we changed\n> WRITE(DEFLATE(SHA1(\"$type $size\\0$data\")))\n> (where SHA1(x) = x but has the side-effect of updating the SHA-1)\n> to\n> WRITE($pack_style_object_header)\n> SHA1(\"$type $size\\0\")\n> WRITE(DEFLATE(SHA1($data)))\n> then the SHA-1 result is the same but we get the pack-style header,\n> and blobs can be sucked straight into packs when not deltified.\n> The SHA-1 result is still usable at the end to rename the temporary\n> loose object file\n> (and put it in the correct xx subdirectory).\n\nHah. That's exactly what the \"new\" (deprecated) format was, and what\nits code for creating such objects looked like in sha1_file.c. :-)\n \n-- \nShawn.\n"},{"id":"61035","messageId":"figlf6$d48$1@ger.gmane.org","threadId":"11016","inReplyTo":"e5bfff550711261125i92fb057i85d7217b18cd495d@mail.gmail.com","subject":"Re: If you would write git from scratch now, what would you change?","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-11-27T08:45:26Z","receivedAt":"2007-11-27T08:45:26Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"Marco Costalba wrote:\n\n> But...wait...Qt would require...(I'm scared to say!)... that awful,\n> painful, hopeless thing called C++. Probably you didn't mean what you\n> said ;-)\n\nActually although I like C++, that's not the reason, the reason is that Qt\nis a significantly (IMHO) better toolkit than Tk. It's more cross platform\nand looks a lot nicer. The fact that it's C++ is neither here nor there.\n\nPersonally I find these language wars a bit distasteful; to me programming\nis programming - the language is a purely secondary point.\n\n\n\nAndy\n\n-- \nDr Andy Parkins, M Eng (hons), MIET\nandyparkins@gmail.com\n"},{"id":"61056","messageId":"Pine.LNX.4.64.0711271136050.27959@racer.site","threadId":"11016","inReplyTo":"20071127015833.GL14735@spearce.org","subject":"Re: If you would write git from scratch now, what would you change?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-11-27T11:39:32Z","receivedAt":"2007-11-27T11:39:32Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 26 Nov 2007, Shawn O. Pearce wrote:\n\n> Actually I might revisit this XUL concept using an HTTP server and AJAX. \n> I could actually link the damn HTTP server against libgit.a (Junio will \n> hate me). If the server dies XUL can notice it and simply restart it.\n\nBut if you can restart the HTTP server via XUL, you can start other git \nprograms directly.\n\nWhat you'd have to do is (urgh) write a wrapper via start_command() \nwhich would recognize that the second process die()d.\n\nAll in all, I think if you want to switch from Tcl/Tk to another language \nfor git-gui, for the sake of attracting more developers, it might be wiser \nto go Java than XUL.\n\nCiao,\nDscho\n"},{"id":"61057","messageId":"Pine.LNX.4.64.0711271145260.27959@racer.site","threadId":"11016","inReplyTo":"200711270315.56849.jnareb@gmail.com","subject":"C# binding, was Re: If you would write git from scratch now, what would you change?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-11-27T11:47:44Z","receivedAt":"2007-11-27T11:47:44Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 27 Nov 2007, Jakub Narebski wrote:\n\n> Shawn O. Pearce wrote:\n> > Junio C Hamano wrote:\n> >>\n> >> ... not to mention countless others you would get wrong that you did not\n> >> list in the above, as the current git got them right ;-)\n> > \n> > Indeed.\n> > \n> > Which is why nobody is looking to rewrite Git from scratch.\n> > \n> > Except myself and a few other nuts who want a pure Java\n> > implementation for Eclipse plugins. :-)\n> \n> And the project to implement git in C# / Mono (I wonder what is\n> the status of those implementations...)\n\nSee for yourself. I started listing some plumbings in \nhttp://git.or.cz/gitwiki/Plumbings, but it seems that the homepage points \nto a wrong URL for the repo. The correct one is \nhttp://repo.or.cz/w/Widgit.git.\n\nHth,\nDscho\n"},{"id":"61067","messageId":"e5bfff550711270515t2a7bc80ege92442c30bf6aebe@mail.gmail.com","threadId":"11016","inReplyTo":"figlf6$d48$1@ger.gmane.org","subject":"Re: If you would write git from scratch now, what would you change?","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2007-11-27T13:15:21Z","receivedAt":"2007-11-27T13:15:21Z","isPatch":false,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On Nov 27, 2007 9:45 AM, Andy Parkins wrote:\n> Marco Costalba wrote:\n>\n> > But...wait...Qt would require...(I'm scared to say!)... that awful,\n> > painful, hopeless thing called C++. Probably you didn't mean what you\n> > said ;-)\n>\n> Actually although I like C++, that's not the reason, the reason is that Qt\n> is a significantly (IMHO) better toolkit than Tk. It's more cross platform\n> and looks a lot nicer. The fact that it's C++ is neither here nor there.\n>\n\nActually there exist a Python bindings for Qt if you prefer.\n\nI was just joking about C++, never meant to start a \"language war\"\nthat I personally consider as very very un-useful and very pity.\n\n\nMarco\n"},{"id":"61074","messageId":"474C259B.1000705@op5.se","threadId":"11016","inReplyTo":"alpine.LFD.0.99999.0711261417580.9605@xanadu.home","subject":"Re: If you would write git from scratch now, what would you change?","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-11-27T14:11:39Z","receivedAt":"2007-11-27T14:11:39Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Nicolas Pitre wrote:\n> On Mon, 26 Nov 2007, David Kastrup wrote:\n> \n>> Get rid of plumbing at the command line level.\n> \n> We can't get rid of plumbing. It is part of Git probably forever and is \n> really really convenient for scripting in any language you want. \n> \n> The only valid argument IMHO is the way too large number of Git commands \n> directly available from the cmdline.\n> \n> The solution: make purely plumbing commands _not_ directly available \n> from the command line. Instead, they can be available through 'git \n> lowlevel ' instead of 'git ' and only 'git lowlevel' would \n> stand in your shell default path.\n> \n> Such a scheme can be implemented in parallel with the current one for a \n> release while the direct plumbing commands are deprecated in order to \n> give script authors a transition period to fix their code.\n> \n\nThe \"git-cmd\" form of writing commands was deemed obsolete round about\nthe time git.sh was rewritten in C. There's just no reason for it\nanymore.\n\nIt's unfortunate that git-sh-setup makes it equally valid for scripts to\nuse either form, as we can never get rid of the dashed form when so many\nscripts in the core distribution uses it.\n\nAh well.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"61080","messageId":"200711271538.32457.jnareb@gmail.com","threadId":"11016","inReplyTo":"474C259B.1000705@op5.se","subject":"Re: If you would write git from scratch now, what would you change?","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-11-27T14:38:32Z","receivedAt":"2007-11-27T14:38:32Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Andreas Ericsson wrote:\n\n> The \"git-cmd\" form of writing commands was deemed obsolete round about\n> the time git.sh was rewritten in C. There's just no reason for it\n> anymore.\n> \n> It's unfortunate that git-sh-setup makes it equally valid for scripts to\n> use either form, as we can never get rid of the dashed form when so many\n> scripts in the core distribution uses it.\n> \n> Ah well.\n\nI think it would be enough to have \"git\" and perhaps \"git-sh-setup\"\nin PATH, and the rest of git-cmd in EXEC_PATH != PATH.\n\n-- \nJakub Narebski\nPoland\n"},{"id":"61098","messageId":"alpine.LFD.0.9999.0711270821280.5869@woody.linux-foundation.org","threadId":"11016","inReplyTo":"alpine.LFD.0.99999.0711262346410.9605@xanadu.home","subject":"Re: If you would write git from scratch now, what would you change?","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-11-27T16:33:43Z","receivedAt":"2007-11-27T16:33:43Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 26 Nov 2007, Nicolas Pitre wrote:\n\n> On Mon, 26 Nov 2007, Shawn O. Pearce wrote:\n> \n> > - Loose objects storage is difficult to work with\n> > \n> > The standard loose object format of DEFLATE(\"$type $size\\0$data\")\n> > makes it harder to work with as you need to inflate at least\n> > part of the object just to see what the hell it is or how big\n> > its final output buffer needs to be.\n> \n> It is a bit cumbersome indeed, but I'm afraid we're really stuck with it \n> since every object SHA1 depends on that format.\n\nNo. \n\nThe SHA1 itself just depends on \"$type $size\\0$data\" (no deflate phase), \nand that one is easy and cheap to calculate. How we then *encode* the data \non disk is totally immaterial.\n\nIn fact, pack-files obviously do not encode it in that form at all, they \nin fact use two different forms of \"$binaryhdr$DEFLATE($data)\" or \n\"$binaryhdr$basesha$DEFLATE($delta)\" (that's from memory, so don't rely on \nthat).\n\nSo we could easily change the on-disk format, and we obviously have - the \nalternate (but deprecated) format for unpacked objects already did. In \nfact, we could - and probably should - add some kind of \"back end \ninterface\" for alternate encoding formats, in case somebody wants to do \nsomething really crazy like use a database for object tracking.\n\n(Side note: using an actual database would really be insane. There is \nabsoluely zero point. But what *could* be interesting would be to have a \n\"cluster back-end\" for the git object store, where objects get hashed to \ndifferent nodes. If you have a really fast network, it may actually be \nbeneficial to spread the objects out, and get better disk throughput by \nthat kind of strange \"git object RAID-0 striping\" setup)\n\n\t\tLinus\n\n(*) Honesty in advertising: the really *original* format did the SHA1 \nafter the deflate, but that was quickly fixed and was a really stupid \nchoice. The main point for doing that was that it meant that loose objects \ncould be verified by just running \"sha1sum\" on them, and comparing the \nresult with their name.\n"},{"id":"61109","messageId":"20071127123346.o2e0jb9hc4k40w8o@intranet.digizenstudio.com","threadId":"11016","inReplyTo":"fiet88$68n$1@ger.gmane.org","subject":"Re: If you would write git from scratch now, what would you change?","fromName":"Jing Xue","fromEmail":"jingxue@digizenstudio.com","sentAt":"2007-11-27T17:33:46Z","receivedAt":"2007-11-27T17:33:46Z","isPatch":false,"sender":{"key":"jingxue@digizenstudio.com","avatar":null},"body":"\nQuoting Andy Parkins :\n\n> - \"index\", \"cached\" and \"stage\" are a definite source of confusion\n\nHear, hear.\n\n> - \"git add\" and \"git rm\" would be nicer as \"git stage\" and \"git unstage\"\n> (or something similar)\n\nNot sure it would be that easy. (As I have just learned recently) \"git \nrm\" is the opposite of \"git add\" _only_ in the case of \nfiles-not-previously-tracked. And the opposite of \"git add \" for \nfiles-already-being-tracked is \"git reset HEAD -- \", which is \nprobably where you were going with \"git unstage\" 8-) .\n\n> - libgit would have come first\n> - \"git revert\" should be called \"git invert\"\n> - \"git revert\" would (maybe) be \"git reset\"\n> - \"git clone\" wouldn't exist\n\nWhy? AFAIC, git clone works out quite well - both functionality and \nnaming wise.\n\nCheers.\n-- \nJing Xue\n"},{"id":"61111","messageId":"Pine.LNX.4.64.0711271747210.27959@racer.site","threadId":"11016","inReplyTo":"figlf6$d48$1@ger.gmane.org","subject":"Re: If you would write git from scratch now, what would you change?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-11-27T17:48:16Z","receivedAt":"2007-11-27T17:48:16Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 27 Nov 2007, Andy Parkins wrote:\n\n> Actually although I like C++, that's not the reason, the reason is that Qt\n> is a significantly (IMHO) better toolkit than Tk. It's more cross platform\n> and looks a lot nicer.\n\nTcl/Tk was easier to install on a lot more platforms in my life than Qt.\n\nCiao,\nDscho\n"},{"id":"61137","messageId":"20071127235657.GC9174@efreet.light.src","threadId":"11016","inReplyTo":"e5bfff550711270515t2a7bc80ege92442c30bf6aebe@mail.gmail.com","subject":"Re: If you would write git from scratch now, what would you change?","fromName":"Jan Hudec","fromEmail":"bulb@ucw.cz","sentAt":"2007-11-27T23:56:57Z","receivedAt":"2007-11-27T23:56:57Z","isPatch":false,"sender":{"key":"bulb@ucw.cz","avatar":null},"body":"On Tue, Nov 27, 2007 at 14:15:21 +0100, Marco Costalba wrote:\n> On Nov 27, 2007 9:45 AM, Andy Parkins wrote:\n> > Marco Costalba wrote:\n> >\n> > > But...wait...Qt would require...(I'm scared to say!)... that awful,\n> > > painful, hopeless thing called C++. Probably you didn't mean what you\n> > > said ;-)\n> >\n> > Actually although I like C++, that's not the reason, the reason is that Qt\n> > is a significantly (IMHO) better toolkit than Tk. It's more cross platform\n> > and looks a lot nicer. The fact that it's C++ is neither here nor there.\n> >\n> \n> Actually there exist a Python bindings for Qt if you prefer.\n\nI tried to write something in them and got a bit burned. Qt has it's\nidea of memory management (delete children with parent) and the bindings\ndon't protect from accessing pointers to objects deleted this way, which can\ncause rather hard to debug crashes. \n\nGtk seems to be much better for use from various scripting languages.\n\n-- \n\t\t\t\t\t\t Jan 'Bulb' Hudec \n"},{"id":"61138","messageId":"fiib19$dj6$1@ger.gmane.org","threadId":"11016","inReplyTo":"Pine.LNX.4.64.0711271136050.27959@racer.site","subject":"[RFC] git-gui USer's Survey 2007 (was: If you would write git from scratch now, what would you change?)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-11-27T23:59:41Z","receivedAt":"2007-11-27T23:59:41Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Johannes Schindelin wrote:\n\n> On Mon, 26 Nov 2007, Shawn O. Pearce wrote:\n> \n>> Actually I might revisit this XUL concept using an HTTP server and AJAX. \n>> I could actually link the damn HTTP server against libgit.a (Junio will \n>> hate me). If the server dies XUL can notice it and simply restart it.\n> \n> But if you can restart the HTTP server via XUL, you can start other git \n> programs directly.\n> \n> What you'd have to do is (urgh) write a wrapper via start_command() \n> which would recognize that the second process die()d.\n> \n> All in all, I think if you want to switch from Tcl/Tk to another language \n> for git-gui, for the sake of attracting more developers, it might be wiser \n> to go Java than XUL.\n\nWont we get with the same problems as egit/jgit?\n\n----\nThis is proposed set of questions for git-gui mini survey...\n\n1. What language and what toolkit should git-gui be written in?\n (single choice)\n\n a. Tcl/Tk (current implementation)\n b. C++/Qt\n c. C/GTK+\n d. Python (native)\n e. Python/PyQt\n f. Python/PyGTK\n g. Ruby\n h. Java/Swing\n i. Java/SWT\n j. XUL+JavaScript+CSS/XULRunner\n k. other\n l. no opinion\n\n2. If you have chosen \"other\" in question above, what language and\n toolkit should it be? C/XForms? C#/Mono? C/wxWidgets? XAML+Silverlight?\n GTK2-Perl? C/OpenGL? ;-)\n\n3. Do you contribute to git-gui?\n Yes/No\n\n4. If git-gui would use other language/toolkit, would you contribute?\n Yes/No\n\n5. What languages and what toolkits you are proficient with (to send\n patches)? \n (multiple choice)\n\n a. Tcl/Tk (current implementation)\n b. C++/Qt\n c. C/GTK+\n d. Python (native)\n e. Python/PyQt\n f. Python/PyGTK\n g. Ruby\n h. Java/Swing\n i. Java/SWT\n j. XUL+JavaScript+CSS/XULRunner\n k. other\n l. N/A\n\n6. What other?\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"61169","messageId":"Pine.LNX.4.64.0711281225150.27959@racer.site","threadId":"11016","inReplyTo":"fiib19$dj6$1@ger.gmane.org","subject":"Re: [RFC] git-gui USer's Survey 2007 (was: If you would write git from scratch now, what would you change?)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-11-28T12:32:10Z","receivedAt":"2007-11-28T12:32:10Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 28 Nov 2007, Jakub Narebski wrote:\n\n> Johannes Schindelin wrote:\n> \n> > On Mon, 26 Nov 2007, Shawn O. Pearce wrote:\n> > \n> >> Actually I might revisit this XUL concept using an HTTP server and \n> >> AJAX. I could actually link the damn HTTP server against libgit.a \n> >> (Junio will hate me). If the server dies XUL can notice it and \n> >> simply restart it.\n> > \n> > But if you can restart the HTTP server via XUL, you can start other \n> > git programs directly.\n> > \n> > What you'd have to do is (urgh) write a wrapper via start_command() \n> > which would recognize that the second process die()d.\n> > \n> > All in all, I think if you want to switch from Tcl/Tk to another \n> > language for git-gui, for the sake of attracting more developers, it \n> > might be wiser to go Java than XUL.\n> \n> Wont we get with the same problems as egit/jgit?\n\nMy idea was not to get the same problems, but to use jgit. After all, \nShawn made a point of separating the both.\n\n> ----\n> This is proposed set of questions for git-gui mini survey...\n> \n> 1. What language and what toolkit should git-gui be written in?\n> (single choice)\n> \n> a. Tcl/Tk (current implementation)\n> b. C++/Qt\n> c. C/GTK+\n> d. Python (native)\n> e. Python/PyQt\n> f. Python/PyGTK\n> g. Ruby\n> h. Java/Swing\n> i. Java/SWT\n> j. XUL+JavaScript+CSS/XULRunner\n> k. other\n> l. no opinion\n\nI am pretty comfortable with a), but rather than go [b-gi-l] I would \nprefer h).\n\n> 3. Do you contribute to git-gui?\n> Yes/No\n\nYes (sort of; not half as much as I'd like to.)\n\n> 4. If git-gui would use other language/toolkit, would you contribute?\n> Yes/No\n\nYes, as long as it is a language/toolkit that is available on all \nplatforms that I (have to) work. That pretty much excludes C# and Python \nas a language.\n\n> 5. What languages and what toolkits you are proficient with (to send\n> patches)? \n> (multiple choice)\n> \n> a. Tcl/Tk (current implementation)\n> b. C++/Qt\n> c. C/GTK+\n> d. Python (native)\n> e. Python/PyQt\n> f. Python/PyGTK\n> g. Ruby\n> h. Java/Swing\n> i. Java/SWT\n> j. XUL+JavaScript+CSS/XULRunner\n> k. other\n> l. N/A\n\n[abchk]\n\n> 6. What other?\n\nPersonally, I am quite comfortable with the existing implementation, and \nIMHO people dismiss contributing to git-gui too easily; Tcl is not all \nthat complicated, and it is not hard at all to change/imitate existing \ncode.\n\nCiao,\nDscho\n"},{"id":"61185","messageId":"87y7cimru6.fsf@osv.gnss.ru","threadId":"11016","inReplyTo":"fiib19$dj6$1@ger.gmane.org","subject":"Re: [RFC] git-gui USer's Survey 2007","fromName":"Sergei Organov","fromEmail":"osv@javad.com","sentAt":"2007-11-28T13:18:09Z","receivedAt":"2007-11-28T13:18:09Z","isPatch":false,"sender":{"key":"osv@javad.com","avatar":null},"body":"Jakub Narebski writes:\n\n[...]\n\n> This is proposed set of questions for git-gui mini survey...\n>\n> 1. What language and what toolkit should git-gui be written in?\n> (single choice)\n>\n> a. Tcl/Tk (current implementation)\n> b. C++/Qt\n> c. C/GTK+\n> d. Python (native)\n\nWhat's this? Tkinter? If so, it's better to be spelled \"Python/Tk\" here,\nand probably should be removed anyway as there is no apparent reason to\nre-implement current Tcl/Tk in Python/Tk.\n\nAnyway, for Python as a language, a realistic choice of GUI seems to be\nbetween PyGtk, PyQt, and WxPython.\n\n-- \nSergei.\n"},{"id":"61219","messageId":"31e9dd080711280748n30972cd1na8be3c705cc6fe93@mail.gmail.com","threadId":"11016","inReplyTo":"Pine.LNX.4.64.0711281225150.27959@racer.site","subject":"Re: [RFC] git-gui USer's Survey 2007 (was: If you would write git from scratch now, what would you change?)","fromName":"Jason Sewall","fromEmail":"jasonsewall@gmail.com","sentAt":"2007-11-28T15:48:13Z","receivedAt":"2007-11-28T15:48:13Z","isPatch":false,"sender":{"key":"jasonsewall@gmail.com","avatar":null},"body":"On Nov 28, 2007 7:32 AM, Johannes Schindelin wrote:\n> Hi,\n>\n> On Wed, 28 Nov 2007, Jakub Narebski wrote:\n>\n> > Johannes Schindelin wrote:\n> >\n> > 1. What language and what toolkit should git-gui be written in?\n> > (single choice)\n> >\n> > a. Tcl/Tk (current implementation)\n> > b. C++/Qt\n> > c. C/GTK+\n> > d. Python (native)\n> > e. Python/PyQt\n> > f. Python/PyGTK\n> > g. Ruby\n> > h. Java/Swing\n> > i. Java/SWT\n> > j. XUL+JavaScript+CSS/XULRunner\n> > k. other\n> > l. no opinion\n\nSince we're listing off a bunch of toolkits, I should pitch FLTK,\nwhich is well-supported across platforms, reasonably featured, and\npretty lightweight (probably much smaller than any of the other ones\nlisted, in terms of dependency installs)\n\nThat said...\n\n> Personally, I am quite comfortable with the existing implementation, and\n> IMHO people dismiss contributing to git-gui too easily; Tcl is not all\n> that complicated, and it is not hard at all to change/imitate existing\n> code.\n\nAgreed. I don't know much about Tcl/Tk, but I think that git-gui is\nfine as-is. It's not very \"pretty\" compared to all of the fancy Gtk\napps the make up my system, but that's not an obstacle for me. (The\nfonts are pretty bad, though)\n\nJason\n"},{"id":"61323","messageId":"20071128232523.GE9174@efreet.light.src","threadId":"11016","inReplyTo":"Pine.LNX.4.64.0711281225150.27959@racer.site","subject":"Re: [RFC] git-gui USer's Survey 2007 (was: If you would write git from scratch now, what would you change?)","fromName":"Jan Hudec","fromEmail":"bulb@ucw.cz","sentAt":"2007-11-28T23:25:23Z","receivedAt":"2007-11-28T23:25:23Z","isPatch":false,"sender":{"key":"bulb@ucw.cz","avatar":null},"body":"On Wed, Nov 28, 2007 at 12:32:10 +0000, Johannes Schindelin wrote:\n> On Wed, 28 Nov 2007, Jakub Narebski wrote:\n> > 4. If git-gui would use other language/toolkit, would you contribute?\n> > Yes/No\n> \n> Yes, as long as it is a language/toolkit that is available on all \n> platforms that I (have to) work. That pretty much excludes C# and Python \n> as a language.\n\nOut of interest, where does neither of those two work and Qt and tcl/tk do?\nMono and python both seem to be quite portable.\n\n-- \n\t\t\t\t\t\t Jan 'Bulb' Hudec \n"},{"id":"61328","messageId":"Pine.LNX.4.64.0711282345500.27959@racer.site","threadId":"11016","inReplyTo":"20071128232523.GE9174@efreet.light.src","subject":"Re: [RFC] git-gui USer's Survey 2007 (was: If you would write git from scratch now, what would you change?)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-11-28T23:48:12Z","receivedAt":"2007-11-28T23:48:12Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 29 Nov 2007, Jan Hudec wrote:\n\n> On Wed, Nov 28, 2007 at 12:32:10 +0000, Johannes Schindelin wrote:\n> > On Wed, 28 Nov 2007, Jakub Narebski wrote:\n> > > 4. If git-gui would use other language/toolkit, would you \n> > > contribute?\n> > > Yes/No\n> > \n> > Yes, as long as it is a language/toolkit that is available on all \n> > platforms that I (have to) work. That pretty much excludes C# and \n> > Python as a language.\n> \n> Out of interest, where does neither of those two work and Qt and tcl/tk do?\n> Mono and python both seem to be quite portable.\n\nIRIX (an ancient one).\n\nBesides, Mono is darned slow. Even Tcl/Tk is faster.\n\nFurthermore, my complaint was not about a platform where neither C# nor \nPython work. That is irrelevant. If you have one platform where only one \nworks, and another platform where only the other works, you cannot have a \nsingle program for both platforms. Right?\n\nHth,\nDscho\n"},{"id":"61369","messageId":"20071129065706.GA24070@efreet.light.src","threadId":"11016","inReplyTo":"Pine.LNX.4.64.0711282345500.27959@racer.site","subject":"Re: [RFC] git-gui USer's Survey 2007 (was: If you would write git from scratch now, what would you change?)","fromName":"Jan Hudec","fromEmail":"bulb@ucw.cz","sentAt":"2007-11-29T06:57:06Z","receivedAt":"2007-11-29T06:57:06Z","isPatch":false,"sender":{"key":"bulb@ucw.cz","avatar":null},"body":"On Wed, Nov 28, 2007 at 23:48:12 +0000, Johannes Schindelin wrote:\n> Hi,\n> \n> On Thu, 29 Nov 2007, Jan Hudec wrote:\n> \n> > On Wed, Nov 28, 2007 at 12:32:10 +0000, Johannes Schindelin wrote:\n> > > On Wed, 28 Nov 2007, Jakub Narebski wrote:\n> > > > 4. If git-gui would use other language/toolkit, would you \n> > > > contribute?\n> > > > Yes/No\n> > > \n> > > Yes, as long as it is a language/toolkit that is available on all \n> > > platforms that I (have to) work. That pretty much excludes C# and \n> > > Python as a language.\n> > \n> > Out of interest, where does neither of those two work and Qt and tcl/tk do?\n> > Mono and python both seem to be quite portable.\n> \n> IRIX (an ancient one).\n> \n> Besides, Mono is darned slow. Even Tcl/Tk is faster.\n\nOn the shootout Mono seems to be an order of magnitude faster in most tests.\nBut maybe they are performing very poorly on some strange platform where they\ndon't have JIT.\n\n> Furthermore, my complaint was not about a platform where neither C# nor \n> Python work. That is irrelevant. If you have one platform where only one \n> works, and another platform where only the other works, you cannot have a \n> single program for both platforms. Right?\n\nRight.\n\nI probably shouldn't be surprised that mono does not work on older unices,\nbut I am a bit surprised python does not.\n\n-- \n\t\t\t\t\t\t Jan 'Bulb' Hudec \n"},{"id":"61390","messageId":"Pine.LNX.4.64.0711291200000.27959@racer.site","threadId":"11016","inReplyTo":"20071129065706.GA24070@efreet.light.src","subject":"Re: [RFC] git-gui USer's Survey 2007 (was: If you would write git from scratch now, what would you change?)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-11-29T12:01:47Z","receivedAt":"2007-11-29T12:01:47Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 29 Nov 2007, Jan Hudec wrote:\n\n> On Wed, Nov 28, 2007 at 23:48:12 +0000, Johannes Schindelin wrote:\n>\n> > Furthermore, my complaint was not about a platform where neither C# \n> > nor Python work. That is irrelevant. If you have one platform where \n> > only one works, and another platform where only the other works, you \n> > cannot have a single program for both platforms. Right?\n> \n> Right.\n> \n> I probably shouldn't be surprised that mono does not work on older unices,\n> but I am a bit surprised python does not.\n\n*Sigh* I managed again to make myself misunderstood.\n\nEven if newer Python does not easily compile on that IRIX, I have an old \nPython there (2.2). But I don't have any Python on MSys. (Yes, there is \na _MinGW_ port, but no _MSys_ one.) So for me, Python is out.\n\nHth,\nDscho\n"},{"id":"61512","messageId":"20071130175018.GB30048@efreet.light.src","threadId":"11016","inReplyTo":"Pine.LNX.4.64.0711291200000.27959@racer.site","subject":"Re: [RFC] git-gui USer's Survey 2007 (was: If you would write git from scratch now, what would you change?)","fromName":"Jan Hudec","fromEmail":"bulb@ucw.cz","sentAt":"2007-11-30T17:50:18Z","receivedAt":"2007-11-30T17:50:18Z","isPatch":false,"sender":{"key":"bulb@ucw.cz","avatar":null},"body":"On Thu, Nov 29, 2007 at 12:01:47 +0000, Johannes Schindelin wrote:\n> Hi,\n> \n> On Thu, 29 Nov 2007, Jan Hudec wrote:\n> \n> > On Wed, Nov 28, 2007 at 23:48:12 +0000, Johannes Schindelin wrote:\n> >\n> > > Furthermore, my complaint was not about a platform where neither C# \n> > > nor Python work. That is irrelevant. If you have one platform where \n> > > only one works, and another platform where only the other works, you \n> > > cannot have a single program for both platforms. Right?\n> > \n> > Right.\n> > \n> > I probably shouldn't be surprised that mono does not work on older unices,\n> > but I am a bit surprised python does not.\n> \n> *Sigh* I managed again to make myself misunderstood.\n> \n> Even if newer Python does not easily compile on that IRIX, I have an old \n> Python there (2.2). But I don't have any Python on MSys. (Yes, there is \n> a _MinGW_ port, but no _MSys_ one.) So for me, Python is out.\n\nWhile it would be a problem, but is it really fatal? AFAIK MSys uses unixy\npaths inside the program, but accepts arguments and calls other processes\nusing the windows convention, so mingw python should have no problem calling\nmsys programs and vice versa. It might be more problematic to compile\na shared module for it, but .dlls are quite well isolated, so even compiling\na plugin linked with msys for mingw python might not be impossible.\n\nNevertheless, I actually think git-gui is quite well in Tcl/Tk and rewriting\nit in python nor any other language would probably help it in any way.\n\n-- \n\t\t\t\t\t\t Jan 'Bulb' Hudec \n"},{"id":"61515","messageId":"e5bfff550711301025y21e7149bga39fa61ceef854cf@mail.gmail.com","threadId":"11016","inReplyTo":"20071130175018.GB30048@efreet.light.src","subject":"Re: [RFC] git-gui USer's Survey 2007 (was: If you would write git from scratch now, what would you change?)","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2007-11-30T18:25:27Z","receivedAt":"2007-11-30T18:25:27Z","isPatch":false,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On Nov 30, 2007 6:50 PM, Jan Hudec wrote:\n>\n> Nevertheless, I actually think git-gui is quite well in Tcl/Tk and rewriting\n> it in python nor any other language would probably help it in any way.\n>\n\nA little provocation: I've never seen in open source a discussion on\nwhat language to use for an application and then the development of\nthe application from scratch.\n\nWhat I see daily instead is the effort of one (or a very little number\nof people) to develop something in the language he choose and then ,\n_after_ some code has been produced, the effort embraced by other\npeople that join the project.\n\nSome near examples? gitk, gitweb, stgit, git itself especially for\nshell parts (why shell should be a better prototyping language then\nother prototyping languages? portability? easy to learn? performance?\nlibrary support? syntax? probably no one of the above in general\nterms).\n\nI would say this thread, although very interesting from a learning\npoint of view, it's a a little bit academic.\n\n\nMarco\n"},{"id":"61538","messageId":"20071201023520.GQ14735@spearce.org","threadId":"11016","inReplyTo":"20071130175018.GB30048@efreet.light.src","subject":"Re: [RFC] git-gui USer's Survey 2007 (was: If you would write git from scratch now, what would you change?)","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-12-01T02:35:20Z","receivedAt":"2007-12-01T02:35:20Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Jan Hudec wrote:\n> Nevertheless, I actually think git-gui is quite well in Tcl/Tk and rewriting\n> it in python nor any other language would probably help it in any way.\n\nUNIX (really X11) users think git-gui looks like cr*p on their\nsystems as Tk draws with 1980s widgets, not 2007 style widgets.\nThey have every right to complain about the look and feel of the\napplication, its utter crap. Tk 8.5's tiles extension may help\nthat, but I haven't tried.\n\nOn Windows 2000/XP and Mac OS X I think I've gotten git-gui to\n(almost) fit into the rest of the desktop. It fits into the Windows\nUI better than it does Mac OS X, there are still some rough edges\nwhere it is really obvious its not a native Mac OS X application.\n\nOn all platforms Tk has some \"features\" that are less than desirable.\nFor example it has been an absolute nightmare to get split pane\ndivider things to work on all systems. I can't tell you how many\ndays I spent just getting the main window to not react stupidly\non each system. And it *still* doesn't act right everywhere.\nSometimes if you resize the window the status bar on the bottom\ndisappears and Tk just clips it right out of the UI (no, I didn't\nask it to do that, Tk has bugs).\n\nBuilding context sensitive menus isn't fun. Managing some data\nstructures in Tcl isn't fun. The list of why I'm currently unhappy\nwith Tcl/Tk for git-gui is actually pretty long.\n\n-- \nShawn.\n"},{"id":"61553","messageId":"e5bfff550711301853w3fe4a535q85ae7f90b964e296@mail.gmail.com","threadId":"11016","inReplyTo":"20071201023520.GQ14735@spearce.org","subject":"Re: [RFC] git-gui USer's Survey 2007 (was: If you would write git from scratch now, what would you change?)","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2007-12-01T02:53:26Z","receivedAt":"2007-12-01T02:53:26Z","isPatch":false,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On Dec 1, 2007 3:35 AM, Shawn O. Pearce wrote:\n>\n> Building context sensitive menus isn't fun. Managing some data\n> structures in Tcl isn't fun. The list of why I'm currently unhappy\n> with Tcl/Tk for git-gui is actually pretty long.\n>\n\nNot to advertise, just my two cents, but Qt with whatever language\nbinding you want to use, it's really powerful, easy to learn,\ndocumentation is great, easy to create GUI forms, actually you don't\neven need to program because Qt Designer let you create a form\ngraphically, the result is a XML like file that a Qt tool called UIC\ntransforms in a compilable file.\n\nQt library is consistent and complete and very portable, especially\nQt4 works and installs under different OS with no hassles. And the Qt\ncommunity (http://www.qtcentre.org/forum/) is very helpful and\nsupportive.\n\nI really don't want to advertise, but after reading your list of\nTcl/Tk cons I was not able to stay quiet.\n\nMarco\n"},{"id":"61898","messageId":"fj3c0q$id1$1@ger.gmane.org","threadId":"11016","inReplyTo":"Pine.LNX.4.64.0711271747210.27959@racer.site","subject":"Re: If you would write git from scratch now, what would you change?","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-12-04T11:00:42Z","receivedAt":"2007-12-04T11:00:42Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"Johannes Schindelin wrote:\n\n> Tcl/Tk was easier to install on a lot more platforms in my life than Qt.\n\nI wasn't really thinking of the install; that's a packaging problem. I was\nspeaking of the toolkit itself. I know what you mean, but I wasn't even\nthinking of cross-platform in a \"number of places it can run\" sense. What\nI meant (although my point is irrelevant and way off the original question)\nwas the facilities available in the toolkit with a cross-platform\ninterface.\n\nQt puts a common face on threading, process control, networking, file\nsystems, internationalisation, rendering, openGL, and of course the GUI\nitself. Tcl/Tk (to take the most wicked example) gives you applications\nthat are much harder to make run on Windows than on UNIX.\n\nAnyway, I don't want to sound like a strange Qt fan boy; the above is simply\nmy justification for putting \"git-gui in Qt\" on my wish list.\n\n\n\nAndy\n-- \nDr Andy Parkins, M Eng (hons), MIET\nandyparkins@gmail.com\n"}]}