{"thread":{"id":"14486","subject":"Considering teaching plumbing to users harmful","startedAt":"2008-07-16T17:21:02Z","lastAt":"2008-07-21T16:22:24Z","messageCount":114,"participants":["Johannes Schindelin","Avery Pennarun","Junio C Hamano","Jesper Eskilson","Petr Baudis","Theodore Tso","Stephen R. van den Berg","Nicolas Pitre","david@lang.hm","Dmitry Potapov","Daniel Barkalow","Stephan Beyer","Sean Kelley","Nigel Magnay","Stephen Sinclair","Peter Valdemar Mørch (Lists)","David Kastrup","Peter Valdemar Mørch","Craig L. Ching","Jakub Narebski","J. Bruce Fields","Karl Hasselström","Kevin Ballard","Robin Rosenberg","Andreas Ericsson","Michael J Gruber","Ping Yin","Jeff King","Jon Loeliger","Jay Soffian","Tarmigan","Sverre Rabbelier","Lars Noschinski"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"83534","messageId":"alpine.DEB.1.00.0807161804400.8950@racer","threadId":"14486","inReplyTo":null,"subject":"Considering teaching plumbing to users harmful","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-07-16T17:21:02Z","receivedAt":"2008-07-16T17:21:02Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nthere have been a number of occasions where I came across people trying to \nbe helpful and teaching Git newbies a few tricks.\n\nHowever, in quite a number of cases, which seem to surge over the last \nweeks, I see people suggesting the use of rev-parse, ls-tree, rev-list \netc.\n\nTheir rationale is invariably \"but I found it useful\", and they seem to be \nunable to recognize the puzzlement in the faces of the people they are \ntrying to help.\n\nInstead they insist that they did nothing wrong.\n\nI had the pleasure of introducing Git to a few users in the last months \nand in my opinion, restricting myself to teaching them these commands \nfirst helped tremendously:\n\n- clone, pull, status, add, commit, push, log\n\nAll of these were presented without options, to keep things simple.\n\nIn particular, I refrained from giving them the \"-a\" option to commit. \nThat seemed to help incredibly with their embracing the index as a natural \nconcept (which it is).\n\nOften I presented the \"pull\" and \"push\" commands _only_ with \"origin \nmaster\" (\"origin is where the repository came from, and master is the \nbranch; you will want to use other parameters here after you used Git for \na while\").\n\n_After_ they grew comfortable with Git, I taught them a few options here \nand there, not hiding, but also not promoting the full range of options.\n\nSo the next tricks were\n\n- log -p, rm, diff, diff --cached, show\n\nThe last one is \"show\", and with that command, I taught the \n\":\" and \":\" syntax, too (which some Git old-timers \ndid not know about ;-)\n\nThe pace needed to be adjusted to the users, in my experience, but not the \norder.\n\nNow, it makes me really, really sad that Git has a reputation of being \ncomplicated, but I regularly hear from _my_ users that they do not \nunderstand how that came about.\n\nAm I the only one who deems teaching plumbing to users (\"I like it raw! \nSo I teach it the same way!\") harmful?\n\nCiao,\nDscho \"who is sad\"\n"},{"id":"83582","messageId":"487E34EC.40708@iar.se","threadId":"14486","inReplyTo":"alpine.DEB.1.00.0807161804400.8950@racer","subject":"Re: Considering teaching plumbing to users harmful","fromName":"Jesper Eskilson","fromEmail":"jesper.eskilson@iar.se","sentAt":"2008-07-16T17:50:36Z","receivedAt":"2008-07-16T17:50:36Z","isPatch":false,"sender":{"key":"jesper.eskilson@iar.se","avatar":null},"body":"Johannes Schindelin wrote:\n\n> Now, it makes me really, really sad that Git has a reputation of being \n> complicated, but I regularly hear from _my_ users that they do not \n> understand how that came about.\n\nWell, Git is not the easiest tool on the market to learn. For people \nused to centralized systems such as RCS/CVS/Subversion, many concepts \nare truly alien. I've recently experienced a transition at our company \nfrom MKS/SI (a RCS derivative) to Subversion, and the mental gap was for \nmany users HUGE. Had we done the transition from MKS/SI to Git, I'm sure \n several user's brains would have exploded.\n\n From my perspective, the concept I found most difficult to grasp at the \nvery beginning was how the index worked, and many of the introductory \ntexts on Git that I looked through only very brielfy explained the \npurpose of the index: Why is it there? Why is it called \"index\"? How \ndoes it fit into a typical workflow? Having a CVS/Subversion background, \nit took a while for me to really assimilate the concept.\n\n-- \n/Jesper\n"},{"id":"83536","messageId":"32541b130807161053w24a21d7bh1fa800a714ce75db@mail.gmail.com","threadId":"14486","inReplyTo":"alpine.DEB.1.00.0807161804400.8950@racer","subject":"Re: Considering teaching plumbing to users harmful","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2008-07-16T17:53:44Z","receivedAt":"2008-07-16T17:53:44Z","isPatch":false,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On 7/16/08, Johannes Schindelin wrote:\n> Am I the only one who deems teaching plumbing to users (\"I like it raw!\n> So I teach it the same way!\") harmful?\n\nI believe the only way you can get away with such a simple learning\nsequence is if your workflow is as simple as that you seem to\ndescribe: everyone has push access to the central 'master'.\n\nThat works (and mostly just as well as any other \"supposedly easy\"\nVCS, like svn), but because git's power is so tempting, almost\nnobody's real-life repository actually works like that.\n\nAt the very least, there will be branches. And where there are\nbranches, there's merging. And with merging comes merge conflicts.\nAnd with merge conflicts comes the crazy (yes, very useful, but still\ncrazy) conflicted index features. And so you suddenly need to find\nout about things like\n\n git diff :{1,3}:path/to/filename\n\nWhich is a great command, but svn definitely makes it easier to do the\nsame thing.\n\nEven if you have a repo with widespread push access, git's log looks\nannoying compared to svn because of all the merge commits. That's a\nprimary reason why rebase was invented, of course. But teaching\npeople about rebase vs. merge is highly nontrivial. \"git pull\n--rebase\" helps a little, but it's still nontrivial, particularly when\nlocal patch #3 of 5 has a conflict.\n\nAlso, inevitably, someone will ask \"what happened to those simple svn\nrevision numbers?\" or \"when I do a merge, why are the patches from\nbranch #1 interspersed with the ones from branch #2 in git log?\" The\nanswers are \"look at gitk to see the real merge history, that's way\nmore powerful than svn, and check out git-bisect!\" and \"use git log\n--topo-order\" respectively, but those are pretty nontrivial answers\ntoo.\n\nSubmodules, which are critical to large-scale software development,\nare also very complicated. You can't explain how to use them without\nknowing about .git/config, the difference between that and\n.gitmodules, the concept of gitlinks (and therefore the concepts of\ntrees and blobs), the idea of a \"disconnected HEAD\" (which all\nsubmodules check out by default), the idea that pushing submodules in\nthe wrong order can create references to non-existing commitids, and\nso on. In contrast, the lame svn:externals mechanism is far easier to\nexplain.\n\nThe \"problem\" with learning git is that it's so powerful. A person\ncan feel like they've \"learned all the svn there is to learn\" in a\ncouple of days, because it really doesn't do all that much. But with\ngit, if you want to make it *appear* simple, you have to artificially\nrestrict what you tell people, and because the git *developers* don't\nwork using that restricted subset of commands, the abstraction always\nleaks.\n\nExample: \"git remote\" didn't originally even have an \"rm\" subcommand.\nWhy? Because real git developers knew they could delete a remote by\nediting .git/config, and it never even occurred to anyone to do it any\nother way. I still do it by editing the file, because the file is in\na nice format and it's still easier than typing \"git remote\".\n\nThe svn developers have the same annoyingly small subset of commands\nthat their users do. It means svn is much less powerful, but it also\nmeans that subset is actually enough to somehow handle *all* the tasks\na user will run into. After all, there's no other way.\n\nThat said, it's debatable if all this is actually a problem. If I\nwanted simple-minded, I'd use svn. Ironically, the plumbing is the\nonly part of git that isn't supposed to ever change, so it's the most\nvaluable knowledge to have. Why *not* teach it?\n\nHave fun,\n\nAvery\n"},{"id":"83540","messageId":"alpine.DEB.1.00.0807161902400.8986@racer","threadId":"14486","inReplyTo":"32541b130807161053w24a21d7bh1fa800a714ce75db@mail.gmail.com","subject":"Re: Considering teaching plumbing to users harmful","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-07-16T18:12:05Z","receivedAt":"2008-07-16T18:12:05Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 16 Jul 2008, Avery Pennarun wrote:\n\n> On 7/16/08, Johannes Schindelin wrote:\n> > Am I the only one who deems teaching plumbing to users (\"I like it raw!\n> > So I teach it the same way!\") harmful?\n> \n> I believe the only way you can get away with such a simple learning\n> sequence is if your workflow is as simple as that you seem to\n> describe: everyone has push access to the central 'master'.\n\nThat _is_ the most common form.\n\nAnd with my way of not even bothering to tell users that \"git pull\" has a \ndefault remote and branch, it is easy to tell users about pulling from \nsomewhere else:\n\n\tgit pull that.big.machine:~gitte/git my-next\n\nNo problem. After having worked with the first form a few time, this \ncommand line is surprisingly easy to teach.\n\n> At the very least, there will be branches.\n\nOh. And you have to teach plumbing for that?\n\nBesides, you do not start with that. Most users will be happy with one \nbranch called master for the first day, if not week.\n\n> And where there are branches, there's merging. And with merging comes \n> merge conflicts.\n\nFunny that you should say that: I had that case. \"git pull origin master\" \nsaid something about conflicts. Happily, this user was able to read, and \nedited the files mentioned to have conflicts.\n\nAfter resolving the conflicts (the \"<<< === >>>\" was known from CVS), add \nand commit were again as encountered in the first 2 minutes of my course.\n\n> And so you suddenly need to find out about things like\n> \n> git diff :{1,3}:path/to/filename\n\nNo. Nobody needed that. All except one user were content with \"git \ndiff\". That one wanted \"git diff --ours\".\n\nSo there was no use to teach some advanced concepts there, let alone in \nthe first few lectures.\n\nBut back to the subject: what does this have to do with plumbing?\n\nI will not even bother to reply to your mentioning rebase, submodules, and \nthe \"complicated\" log due to merges for that very reason: all of this can \nbe done, easily, with porcelain.\n\n> Ironically, the plumbing is the only part of git that isn't supposed to \n> ever change, so it's the most valuable knowledge to have.\n\nAha. So we changed porcelain recently, in a backwards-incompatible way? \nNow, that is news to me.\n\nCiao,\nDscho\n"},{"id":"83541","messageId":"alpine.DEB.1.00.0807161913440.8986@racer","threadId":"14486","inReplyTo":"487E34EC.40708@iar.se","subject":"Re: Considering teaching plumbing to users harmful","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-07-16T18:14:23Z","receivedAt":"2008-07-16T18:14:23Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 16 Jul 2008, Jesper Eskilson wrote:\n\n> Johannes Schindelin wrote:\n> \n> > Now, it makes me really, really sad that Git has a reputation of being \n> > complicated, but I regularly hear from _my_ users that they do not \n> > understand how that came about.\n> \n> Well, Git is not the easiest tool on the market to learn. For people \n> used to centralized systems such as RCS/CVS/Subversion, many concepts \n> are truly alien. I've recently experienced a transition at our company \n> from MKS/SI (a RCS derivative) to Subversion, and the mental gap was for \n> many users HUGE. Had we done the transition from MKS/SI to Git, I'm sure\n> several user's brains would have exploded.\n> \n> From my perspective, the concept I found most difficult to grasp at the \n> very beginning was how the index worked, and many of the introductory \n> texts on Git that I looked through only very brielfy explained the \n> purpose of the index: Why is it there? Why is it called \"index\"? How \n> does it fit into a typical workflow? Having a CVS/Subversion background, \n> it took a while for me to really assimilate the concept.\n\nWhat does your answer have to do with my mail, i.e. with plumbing?\n\nCiao,\nDscho\n"},{"id":"83543","messageId":"7v7iblsnfh.fsf@gitster.siamese.dyndns.org","threadId":"14486","inReplyTo":"32541b130807161053w24a21d7bh1fa800a714ce75db@mail.gmail.com","subject":"Re: Considering teaching plumbing to users harmful","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-07-16T18:18:10Z","receivedAt":"2008-07-16T18:18:10Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Avery Pennarun\" writes:\n\n> On 7/16/08, Johannes Schindelin wrote:\n>> Am I the only one who deems teaching plumbing to users (\"I like it raw!\n>> So I teach it the same way!\") harmful?\n>\n> I believe the only way you can get away with such a simple learning\n> sequence is if your workflow is as simple as that you seem to\n> describe: everyone has push access to the central 'master'.\n>\n> That works (and mostly just as well as any other \"supposedly easy\"\n> VCS, like svn), but because git's power is so tempting, almost\n> nobody's real-life repository actually works like that.\n>\n> At the very least, there will be branches. And where there are\n> branches, there's merging. And with merging comes merge conflicts.\n\nWell, you are wrong. Even when people work only with a single branch\n'master', once you have more than one repository involved, there's already\nmerging. Dscho just described how he would guide new people into the\nprocess without going into the details in that message, by the time his\naudiences need merge conflict resolution they are already comfortable with\nthe index.\n\n> git diff :{1,3}:path/to/filename\n>\n> Which is a great command, but svn definitely makes it easier to do the\n> same thing.\n\nI've never seen anybody who finds \"diff :{1,3}:path\" *useful*.\n\nWell, if you are coming from SVN or CVS where a merge is just a large goo\nof everything that happened on a side branch squashed into one, perhaps it\nmight look useful.\n\nWhat you should learn and teach instead is:\n\n\tgit log -p --merge\n\nThis shows individual changes from the commits involved in the conflict\nwith rationale (of course your committers must be disciplined enough to\nwrite usable commit log messages for you to take full benefit of this).\nAdd path/to/filename if you want to process one path at a time. Also\nadding --left-right to the command line may make it more understandable if\nyou are merging two histories, both of which are from other people, and\nyou do not know which commit is from which side of the merge.\n\n> Even if you have a repo with widespread push access, git's log looks\n> annoying compared to svn because of all the merge commits. That's a\n> primary reason why rebase was invented, of course.\n\nPlease don't talk nonsense if you do not know history. I invented rebase\nprimarily because I wanted to help e-mail based contributors. There is\nnothing about merge avoidance to it.\n\nYou can skip merges with \"git log --no-merges\", just in case you didn't\nknow.\n\nI won't comment on the remainder but that is not because I agree with\nanything you said there ;-)\n"},{"id":"83544","messageId":"487E3BAE.80500@iar.se","threadId":"14486","inReplyTo":"alpine.DEB.1.00.0807161913440.8986@racer","subject":"Re: Considering teaching plumbing to users harmful","fromName":"Jesper Eskilson","fromEmail":"jesper.eskilson@iar.se","sentAt":"2008-07-16T18:19:26Z","receivedAt":"2008-07-16T18:19:26Z","isPatch":false,"sender":{"key":"jesper.eskilson@iar.se","avatar":null},"body":"Johannes Schindelin wrote:\n> Hi,\n> \n> On Wed, 16 Jul 2008, Jesper Eskilson wrote:\n> \n>> Johannes Schindelin wrote:\n>>\n>>> Now, it makes me really, really sad that Git has a reputation of being \n>>> complicated, but I regularly hear from _my_ users that they do not \n>>> understand how that came about.\n>> Well, Git is not the easiest tool on the market to learn. For people \n>> used to centralized systems such as RCS/CVS/Subversion, many concepts \n>> are truly alien. I've recently experienced a transition at our company \n>> from MKS/SI (a RCS derivative) to Subversion, and the mental gap was for \n>> many users HUGE. Had we done the transition from MKS/SI to Git, I'm sure\n>> several user's brains would have exploded.\n>>\n>> From my perspective, the concept I found most difficult to grasp at the \n>> very beginning was how the index worked, and many of the introductory \n>> texts on Git that I looked through only very brielfy explained the \n>> purpose of the index: Why is it there? Why is it called \"index\"? How \n>> does it fit into a typical workflow? Having a CVS/Subversion background, \n>> it took a while for me to really assimilate the concept.\n> \n> What does your answer have to do with my mail, i.e. with plumbing?\n\nNothing, really. I just wanted to comment on your note on Git having a \nreputation being complicated.\n\n-- \n/Jesper\n"},{"id":"83548","messageId":"alpine.DEB.1.00.0807161926040.8986@racer","threadId":"14486","inReplyTo":"487E3BAE.80500@iar.se","subject":"Re: Considering teaching plumbing to users harmful","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-07-16T18:27:02Z","receivedAt":"2008-07-16T18:27:02Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 16 Jul 2008, Jesper Eskilson wrote:\n\n> Johannes Schindelin wrote:\n> \n> > On Wed, 16 Jul 2008, Jesper Eskilson wrote:\n> > \n> > > Johannes Schindelin wrote:\n> > >\n> > > > Now, it makes me really, really sad that Git has a reputation of \n> > > > being complicated, but I regularly hear from _my_ users that they \n> > > > do not understand how that came about.\n> > >\n> > > Well, Git is not the easiest tool on the market to learn. For people \n> > > used to centralized systems such as RCS/CVS/Subversion, many \n> > > concepts are truly alien. I've recently experienced a transition at \n> > > our company from MKS/SI (a RCS derivative) to Subversion, and the \n> > > mental gap was for many users HUGE. Had we done the transition from \n> > > MKS/SI to Git, I'm sure several user's brains would have exploded.\n> > >\n> > > From my perspective, the concept I found most difficult to grasp at \n> > > the very beginning was how the index worked, and many of the \n> > > introductory texts on Git that I looked through only very brielfy \n> > > explained the purpose of the index: Why is it there? Why is it \n> > > called \"index\"? How does it fit into a typical workflow? Having a \n> > > CVS/Subversion background, it took a while for me to really \n> > > assimilate the concept.\n> > \n> > What does your answer have to do with my mail, i.e. with plumbing?\n> \n> Nothing, really. I just wanted to comment on your note on Git having a \n> reputation being complicated.\n\nThanks, but you also read my note that my users did not find Git \ncomplicated. And I think it is not because I am _such_ a good instructor.\n\nCiao,\nDscho\n"},{"id":"83549","messageId":"32541b130807161135h64024151xc60e23d222a3a508@mail.gmail.com","threadId":"14486","inReplyTo":"alpine.DEB.1.00.0807161902400.8986@racer","subject":"Re: Considering teaching plumbing to users harmful","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2008-07-16T18:35:16Z","receivedAt":"2008-07-16T18:35:16Z","isPatch":false,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On 7/16/08, Johannes Schindelin wrote:\n> And with my way of not even bothering to tell users that \"git pull\" has a\n> default remote and branch, it is easy to tell users about pulling from\n> somewhere else:\n\nI agree that this is the best way to teach git pull.\n\n> > At the very least, there will be branches.\n>\n> Oh. And you have to teach plumbing for that?\n\nIn svn, a branch is a revision-controlled directory. In git, a branch\nis a \"ref\". What's a ref? Well, it's a name for a commit. What's a\ncommit? Well, it's a blob. What's a blob? Err, that's complicated.\nWhat happens when I delete a branch? Well, it's still in the reflog.\nWhat's the reflog? Well, it's the local revision history of each\nbranch. Local? Why not shared? In svn, the revision history of each\nbranch is shared, but in git, you don't need to, because...\n\nEven git branches are surprisingly concept heavy, unless your users\nask a lot fewer questions than mine. The really critical question is\nwhy it's so easy to delete a branch in git, and that leads rapidly\ninto the commit-tree stuff, which is always a spiral into plumbing as\nyou try to explain the tree of commits.\n\n> > And so you suddenly need to find out about things like\n> >\n> > git diff :{1,3}:path/to/filename\n>\n> No. Nobody needed that. All except one user were content with \"git\n> diff\". That one wanted \"git diff --ours\".\n\nI can't find that option in the git-diff man page.\n\n> I will not even bother to reply to your mentioning rebase, submodules, and\n> the \"complicated\" log due to merges for that very reason: all of this can\n> be done, easily, with porcelain.\n\nMy point was that the porcelain doesn't even make that stuff easy, and\nthus you need to understand fundamental git internal concepts to use\nthem, and fundamental git internals are easiest to teach using the\nplumbing, which doesn't try to hide them.\n\n> > Ironically, the plumbing is the only part of git that isn't supposed to\n> > ever change, so it's the most valuable knowledge to have.\n>\n> Aha. So we changed porcelain recently, in a backwards-incompatible way?\n> Now, that is news to me.\n\nThere are frequent discussions on this list about changing the output\nof various porcelains vs. plumbing. Improving the porcelain output is\nuseful, because a lot of it right now is mostly accidental (especially\nerror and progress messages), and to make git easier to use over time,\nit will presumably want to be cleaned up.\n\nBut if I write a script that uses git and I need to parse the output,\nthose very useful porcelain changes are backwards incompatible.\n\nThe common advice in that case is to only write scripts that use the\nplumbing, not the porcelain. That's fine advice, I think. But in\nsvn, I can write scripts using the \"svn\" command, because its outputs\nnever change. Quite unadvanced svn users write shell scripts around\nsvn, including basic things such as:\n\n svn status | grep ^C\n\n...to list all conflicted files. I don't think a similar script\naround \"git status\" is guaranteed not to break. Perhaps I've\nmisunderstood though.\n\nHave fun,\n\nAvery\n"},{"id":"83552","messageId":"32541b130807161151x19c20f9t91b7fb9b8c7b8c7b@mail.gmail.com","threadId":"14486","inReplyTo":"7v7iblsnfh.fsf@gitster.siamese.dyndns.org","subject":"Re: Considering teaching plumbing to users harmful","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2008-07-16T18:51:30Z","receivedAt":"2008-07-16T18:51:30Z","isPatch":false,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On 7/16/08, Junio C Hamano wrote:\n> \"Avery Pennarun\" writes:\n> > git diff :{1,3}:path/to/filename\n> >\n> > Which is a great command, but svn definitely makes it easier to do the\n> > same thing.\n>\n> I've never seen anybody who finds \"diff :{1,3}:path\" *useful*.\n\nDunno. I use it frequently, and it works great for me. Perhaps my\nbrain is just poisoned by svn.\n\nI've never tried \"git log -p --merge\". I'll try it next time. This\nis certainly not common knowledge, however. (But to save Dscho the\ntrouble: git usability in general is not the subject of this thread.)\n\n> > Even if you have a repo with widespread push access, git's log looks\n> > annoying compared to svn because of all the merge commits. That's a\n> > primary reason why rebase was invented, of course.\n>\n> Please don't talk nonsense if you do not know history. I invented rebase\n> primarily because I wanted to help e-mail based contributors. There is\n> nothing about merge avoidance to it.\n\nSorry, I mixed up git-rerere and git-rebase. From git-rerere's man page:\n\n When your topic branch is long-lived, however, your topic branch would\n end up having many such \"Merge from master\" commits on it, which would\n unnecessarily clutter the development history. Readers of the Linux\n kernel mailing list may remember that Linus complained about such too\n frequent test merges when a subsystem maintainer asked to pull from a\n branch full of \"useless merges\".\n\nNowadays, I'm pretty sure people use git-rebase to avoid this sort of\nproblem (or \"git pull --rebase\" presumably wouldn't have appeared),\nbut I can now see how git-rebase was not written *for* this problem.\n\nAnyway, my point was that git-rebase (or at least git-rerere and\ngit-reset) are needed if you want to avoid a lot of merge commits.\nAnd, to relate it back to this thread, git-rebase cannot possibly be\nunderstood without understanding git internals, and git internals are\neasiest to understand by learning the plumbing.\n\nsvn avoids these excess merges by default, albeit because it puts your\nworking copy at risk every time you do \"svn update\".\n\n> You can skip merges with \"git log --no-merges\", just in case you didn't\n> know.\n\nPerhaps this is mostly a user education or documentation issue. I\nknow about --no-merges, but it's unclear that this is really a safe\nthing to use, particularly if some of your merges have conflicts.\nLeaving them out leaves out an important part of history. Do you use\nthis option yourself?\n\nHave fun,\n\nAvery\n"},{"id":"83554","messageId":"20080716185930.GP32184@machine.or.cz","threadId":"14486","inReplyTo":"32541b130807161151x19c20f9t91b7fb9b8c7b8c7b@mail.gmail.com","subject":"Re: Considering teaching plumbing to users harmful","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2008-07-16T18:59:30Z","receivedAt":"2008-07-16T18:59:30Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Wed, Jul 16, 2008 at 02:51:30PM -0400, Avery Pennarun wrote:\n> On 7/16/08, Junio C Hamano wrote:\n> > You can skip merges with \"git log --no-merges\", just in case you didn't\n> > know.\n> \n> Perhaps this is mostly a user education or documentation issue. I\n> know about --no-merges, but it's unclear that this is really a safe\n> thing to use, particularly if some of your merges have conflicts.\n> Leaving them out leaves out an important part of history. Do you use\n> this option yourself?\n\nWhereas if you rebase, not only you don't show the conflicts resolution,\nyou didn't even _store_ it in the first place. That isn't much of an\nimprovement. :-) (This is the main reason why I prefer to avoid rebase\nunless absolutely necessary for the workflow.)\n\n\t\t\t\tPetr \"Pasky\" Baudis\n"},{"id":"83555","messageId":"7vmykhr6h1.fsf@gitster.siamese.dyndns.org","threadId":"14486","inReplyTo":"32541b130807161151x19c20f9t91b7fb9b8c7b8c7b@mail.gmail.com","subject":"Re: Considering teaching plumbing to users harmful","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-07-16T19:09:46Z","receivedAt":"2008-07-16T19:09:46Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Avery Pennarun\" writes:\n\n> svn avoids these excess merges by default, albeit because it puts your\n> working copy at risk every time you do \"svn update\".\n\nBy default? As if it has other mode of operation.\n\nOf course if you do not allow any commits in between to make the history\ntruly forked, you won't see merge commits. It is like saying that you\nlike your broken keyboard whose SHIFT key does not work because you think\ncapital letters look ugly and your keyboard protects you from typing them\nby accident.\n\nIs that an improvement?\n\nI won't waste my time further on the apples and rotten oranges comparison,\nbut you should perhaps listen to Linus's talk where he talks about why it\nsucks that SVN/CVS _encourage_ you to keep your local changes uncommitted\nfor several weeks.\n\n>> You can skip merges with \"git log --no-merges\", just in case you didn't\n>> know.\n>\n> Perhaps this is mostly a user education or documentation issue. I\n> know about --no-merges, but it's unclear that this is really a safe\n> thing to use, particularly if some of your merges have conflicts.\n> Leaving them out leaves out an important part of history. Do you use\n> this option yourself?\n\nVery rarely. When I run \"git shortlog\" for summary, it often is handy,\nbut otherwise no.\n"},{"id":"83566","messageId":"32541b130807161222y68f447c9n5afa6f14d871fe50@mail.gmail.com","threadId":"14486","inReplyTo":"20080716185930.GP32184@machine.or.cz","subject":"Re: Considering teaching plumbing to users harmful","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2008-07-16T19:22:41Z","receivedAt":"2008-07-16T19:22:41Z","isPatch":false,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On 7/16/08, Petr Baudis wrote:\n> On Wed, Jul 16, 2008 at 02:51:30PM -0400, Avery Pennarun wrote:\n> > On 7/16/08, Junio C Hamano wrote:\n> > > You can skip merges with \"git log --no-merges\", just in case you didn't\n> > > know.\n> > Perhaps this is mostly a user education or documentation issue. I\n> > know about --no-merges, but it's unclear that this is really a safe\n> > thing to use, particularly if some of your merges have conflicts.\n> > Leaving them out leaves out an important part of history. Do you use\n> > this option yourself?\n>\n> Whereas if you rebase, not only you don't show the conflicts resolution,\n> you didn't even _store_ it in the first place. That isn't much of an\n> improvement. :-) (This is the main reason why I prefer to avoid rebase\n> unless absolutely necessary for the workflow.)\n\nThe key here is that I'd expect \"git log -p\" with a rebased merge at\nleast shows me the actual changes that are in my repository. \"git log\n--no-merges\" will actually omit things.\n\nAvery\n"},{"id":"83569","messageId":"32541b130807161229ob4c21cbsc6c86ee3e42c4101@mail.gmail.com","threadId":"14486","inReplyTo":"7vmykhr6h1.fsf@gitster.siamese.dyndns.org","subject":"Re: Considering teaching plumbing to users harmful","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2008-07-16T19:29:39Z","receivedAt":"2008-07-16T19:29:39Z","isPatch":false,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On 7/16/08, Junio C Hamano wrote:\n> \"Avery Pennarun\" writes:\n> > svn avoids these excess merges by default, albeit because it puts your\n> > working copy at risk every time you do \"svn update\".\n>\n> By default? As if it has other mode of operation.\n>\n> Of course if you do not allow any commits in between to make the history\n> truly forked, you won't see merge commits. It is like saying that you\n> like your broken keyboard whose SHIFT key does not work because you think\n> capital letters look ugly and your keyboard protects you from typing them\n> by accident.\n>\n> Is that an improvement?\n>\n> I won't waste my time further on the apples and rotten oranges comparison,\n\nI find it interesting how git usability discussions tend to go. It\nusually starts out by someone saying, \"Look, git really isn't that\nhard to learn, just do it like this...\" and then someone says, \"But\nactually, that's still really complicated. Everyone thinks xxx other\nVCS is easier to learn. Here's how they do it...\" And then someone\nsays, \"Yeah, but xxx VCS sucks!\" and that somehow makes it okay that\ngit is empirically harder to learn than xxx VCS, as anyone can see by\nbrowsing the web.\n\nsvn is fundamentally broken, but just because they did *some* things\nwrong doesn't mean they did *everything* wrong. You can learn lessons\neven from your inferiors.\n\nHave fun,\n\nAvery\n"},{"id":"83570","messageId":"7vabghr5br.fsf@gitster.siamese.dyndns.org","threadId":"14486","inReplyTo":"32541b130807161229ob4c21cbsc6c86ee3e42c4101@mail.gmail.com","subject":"Re: Considering teaching plumbing to users harmful","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-07-16T19:34:32Z","receivedAt":"2008-07-16T19:34:32Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Avery Pennarun\" writes:\n\n> On 7/16/08, Junio C Hamano wrote:\n>> \"Avery Pennarun\" writes:\n>> > svn avoids these excess merges by default, albeit because it puts your\n>> > working copy at risk every time you do \"svn update\".\n>>\n>> By default? As if it has other mode of operation.\n>>\n>> Of course if you do not allow any commits in between to make the history\n>> truly forked, you won't see merge commits. It is like saying that you\n>> like your broken keyboard whose SHIFT key does not work because you think\n>> capital letters look ugly and your keyboard protects you from typing them\n>> by accident.\n>>\n>> Is that an improvement?\n>>\n>> I won't waste my time further on the apples and rotten oranges comparison,\n> ...\n> svn is fundamentally broken, but just because they did *some* things\n> wrong doesn't mean they did *everything* wrong. You can learn lessons\n> even from your inferiors.\n\nI agree in principle, but read what you wrote again and realize that your\ncriticism does not apply to this case *at all*.\n\nYou said svn makes it easier because it makes it very hard to do merges\nand forces users to stay away from them. This results in user doing \"svn\nupdate\" which is to resolve conflicts with large uncommitted changes but\nkeeps the history straight single-strand-of-pearls. \n\nI am not saying the merge based workflow in git does not have any room to\nimprove. I am just saying that there is nothing we can learn from svn in\nthat area. \"Solves it by not letting us to do merges\" is not a solution.\n"},{"id":"83572","messageId":"32541b130807161246l579d3a5em65496ee9119ef1ef@mail.gmail.com","threadId":"14486","inReplyTo":"7vabghr5br.fsf@gitster.siamese.dyndns.org","subject":"Re: Considering teaching plumbing to users harmful","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2008-07-16T19:46:34Z","receivedAt":"2008-07-16T19:46:34Z","isPatch":false,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On 7/16/08, Junio C Hamano wrote:\n> You said svn makes it easier because it makes it very hard to do merges\n> and forces users to stay away from them. This results in user doing \"svn\n> update\" which is to resolve conflicts with large uncommitted changes but\n> keeps the history straight single-strand-of-pearls.\n>\n> I am not saying the merge based workflow in git does not have any room to\n> improve. I am just saying that there is nothing we can learn from svn in\n> that area. \"Solves it by not letting us to do merges\" is not a solution.\n\nWhat svn does is essentially an unsafe version of\n\n git stash && git pull x y && git stash apply\n\nAnd that's actually a good example of what I'm talking about; in svn,\nthat's just \"svn up\", which is a daily operation that's easy and\nleaves a clean, linear history. In git, it takes three commands\ninstead of one (and 'git stash' wasn't anywhere in Dscho's list of\ncommands he teaches to newbies).\n\nI think there's value in thinking about the relative convenience of\nsvn's workflow for novice users in their day-to-day lives. Now, in\nthe case of svn, that \"convenience\" also leads to novice users blowing\nup the local changes in their working copy occasionally, but that's\njust an svn *architectural* problem. Git doesn't have that\narchitectural problem.\n\nTo be more concrete: would anyone object to a patch that simply made\n'git pull' include the above stash commands (or something like them)\nby default, rather than giving up when dirty files would be changed?\nOr can we do even better?\n\nHave fun,\n\nAvery\n"},{"id":"83575","messageId":"7vr69tpoze.fsf@gitster.siamese.dyndns.org","threadId":"14486","inReplyTo":"32541b130807161246l579d3a5em65496ee9119ef1ef@mail.gmail.com","subject":"Re: Considering teaching plumbing to users harmful","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-07-16T20:12:53Z","receivedAt":"2008-07-16T20:12:53Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Avery Pennarun\" writes:\n\n> On 7/16/08, Junio C Hamano wrote:\n>> You said svn makes it easier because it makes it very hard to do merges\n>> and forces users to stay away from them. This results in user doing \"svn\n>> update\" which is to resolve conflicts with large uncommitted changes but\n>> keeps the history straight single-strand-of-pearls.\n>>\n>> I am not saying the merge based workflow in git does not have any room to\n>> improve. I am just saying that there is nothing we can learn from svn in\n>> that area. \"Solves it by not letting us to do merges\" is not a solution.\n>\n> What svn does is essentially an unsafe version of\n>\n> git stash && git pull x y && git stash apply\n\nIf you are advocating that mode of operation to be easy in git, you should\nthink again. That pull (be it with or without --rebase) can conflict and\nyou would need to resolve it, and then your \"stash pop\" can conflict\nagain. You can have your own \"git avery-up\" alias which is your \"svn up\"\nequivalent, but if you train users with that first, the users have to\nlearn how to cope with conflicts in individual steps anyway.\n\nMaking these three into a single alias is not an improvement either. If\nyou are not ready to incorporate other's changes to your history, why are\nyou pulling? Being distributed gives the power of working independently\nand at your own pace. You should train your brain to think about the\nworkflow first. \"You should stash before pull\" is _not_ a good advice.\n\"Do not pull when you are not ready\" is.\n\nSuppose you are about to finish something you have been cooking (say a\nseries of five logical commits), you've made three of these commits\nalready, and what you have in your work tree and the index is to be split\ninto the last two commits. Somehow you learn that $x above has a updated\nversion.\n\nYes, running \"git stash && git pull --rebase && git stash pop\" would be\nbetter than running \"git pull --rebase\" alone from that state. But that\nwould mean your history would have your first 3 commits (of 5 commit\nseries), somebody else's totally unrelated commits, and then you will work\non finishing the remaining 2 commits on top of it. Why? Why is such a\nbogus linear history any better?\n\nWith git, instead, you have the choice:\n\n\t* \"git fetch\" first to see if it is truly urgent; otherwise you\n don't even have to pull. First finish whatever you were doing\n and then make the pull\n\n\t $ make commit 1\n $ make commit 2\n $ git pull\n\n\t This results in a merge but it is a good merge. The resulting\n\t history shows your 5 commits are isolated work independently\n\t developed while that urgent thing was being done elsewhere.\n\n\t* if it is, then, you save away your work and pull first:\n\n\t $ git branch mywork\n $ git stash save \"remaining two commits' worth of changes\"\n $ git reset --hard HEAD~3 # wipe your 3 commits\n $ git pull\n\n\t and then continue working:\n\n\t $ git checkout mywork\n $ git stash pop\n $ make commit 1\n $ make commit 2\n\n\t and finally integrate:\n\n $ git checkout master\n $ git merge mywork\n\n\t or if you really want linear, pretend all 5 of your commits\n\t were done on top of that urgent thing.\n\n $ git rebase master\n $ git checkout master\n $ git merge mywork\n\n> And that's actually a good example of what I'm talking about; in svn,\n> that's just \"svn up\",...\n\nWhat you forgot to add in the above is that in svn the equivalent of \"pull\nx y\" step will always fast forward because you will not be making forked\ndevelopment with the upstream. In svn it's just \"svn up\" and it results\nin a linear history because that command does not work with merges. By\ndefinition, not working with merges will result in linear history.\n"},{"id":"83577","messageId":"20080716201333.GI2167@mit.edu","threadId":"14486","inReplyTo":"32541b130807161135h64024151xc60e23d222a3a508@mail.gmail.com","subject":"Re: Considering teaching plumbing to users harmful","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2008-07-16T20:13:33Z","receivedAt":"2008-07-16T20:13:33Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Wed, Jul 16, 2008 at 02:35:16PM -0400, Avery Pennarun wrote:\n> In svn, a branch is a revision-controlled directory. In git, a branch\n> is a \"ref\". What's a ref? Well, it's a name for a commit. What's a\n> commit? Well, it's a blob. What's a blob? Err, that's complicated.\n> What happens when I delete a branch? Well, it's still in the reflog.\n> What's the reflog? Well, it's the local revision history of each\n> branch. Local? Why not shared? In svn, the revision history of each\n> branch is shared, but in git, you don't need to, because...\n> \n> Even git branches are surprisingly concept heavy, unless your users\n> ask a lot fewer questions than mine. The really critical question is\n> why it's so easy to delete a branch in git, and that leads rapidly\n> into the commit-tree stuff, which is always a spiral into plumbing as\n> you try to explain the tree of commits.\n\nI don't think you need to go into the plumbing to explain the commit\ntree. What I normally do is tell people that branches point at\ncommits, and that commits are identified by commit ID's, which can be\nfull SHA-1 hashes, or which can be abbreviated for convenience's sake.\nIt's not strictly necessary to tell them about the commit-tree\nplumbing command; just that each commit creates a snapshot, and that\ncommits can have one or more parents, plus the commit mesage, plus the\nsnapshot.\n\nI do absolutely agree with Johannes' assertion that you don't have to\nexplain commit-tree, git-rev-list, and all the rest. The only reason\nwhy users will need to see git-rev-list is because git-log references\nit so prominently, and some of the more powerful git-log options are\nonly documented in git-rev-list.\n\n\t\t\t\t\t\t\t- Ted\n"},{"id":"83578","messageId":"20080716202321.GA30485@cuci.nl","threadId":"14486","inReplyTo":"32541b130807161053w24a21d7bh1fa800a714ce75db@mail.gmail.com","subject":"Re: Considering teaching plumbing to users harmful","fromName":"Stephen R. van den Berg","fromEmail":"srb@cuci.nl","sentAt":"2008-07-16T20:23:21Z","receivedAt":"2008-07-16T20:23:21Z","isPatch":false,"sender":{"key":"srb@cuci.nl","avatar":"https://gravatar.com/avatar/f75389059e827634d38e9df2a9b6ecbd50028b5a454442efa1c7205b7ff29c6a?d=mp&s=160"},"body":"Avery Pennarun wrote:\n>Also, inevitably, someone will ask \"what happened to those simple svn\n>revision numbers?\" or \"when I do a merge, why are the patches from\n>branch #1 interspersed with the ones from branch #2 in git log?\" The\n>answers are \"look at gitk to see the real merge history, that's way\n>more powerful than svn, and check out git-bisect!\" and \"use git log\n>--topo-order\" respectively, but those are pretty nontrivial answers\n>too.\n\nTry --first-parent, it simplifies the history.\n-- \nSincerely,\n Stephen R. van den Berg.\n\nThe eleventh commandment: Thou shalt not re-curse!\n"},{"id":"83579","messageId":"alpine.LFD.1.10.0807161611540.3110@xanadu.home","threadId":"14486","inReplyTo":"alpine.DEB.1.00.0807161804400.8950@racer","subject":"Re: Considering teaching plumbing to users harmful","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2008-07-16T20:27:14Z","receivedAt":"2008-07-16T20:27:14Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Wed, 16 Jul 2008, Johannes Schindelin wrote:\n\n> I had the pleasure of introducing Git to a few users in the last months \n> and in my opinion, restricting myself to teaching them these commands \n> first helped tremendously:\n> \n> - clone, pull, status, add, commit, push, log\n> \n> All of these were presented without options, to keep things simple.\n\nI completely agree with you.\n\nIn the context of remote tracking branches, I usually talk about\n'git init' + 'git remote' + 'git fetch' + 'git merge' and/or\n'git rebase' which is somehow simpler to really understand than\n'git clone' + 'git pull'. At that point the branch concept is usually\nclear.\n\n\nNicolas\n"},{"id":"83594","messageId":"7vmykhpn6z.fsf@gitster.siamese.dyndns.org","threadId":"14486","inReplyTo":"alpine.DEB.1.00.0807161804400.8950@racer","subject":"Re: Considering teaching plumbing to users harmful","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-07-16T20:51:31Z","receivedAt":"2008-07-16T20:51:31Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> Am I the only one who deems teaching plumbing to users (\"I like it raw! \n> So I teach it the same way!\") harmful?\n\nI think that justification is harmful.\n\nMore productive way to think about it is to identify cases where we _need_\nto go down to combination of the plumbing commands in our daily workflow,\nwith today's command set. That would give us a good indication that some\nPorcelain may need to be enhanced.\n\nAn example. I find myself running \"git read-tree -m -u $another_state\"\nwhile redoing a series inside a \"rebase -i\" session to move commit\nboundaries. There may need an insn that says \"use that tree\" instead of\n\"edit\" and running \"read-tree -m -u\" by hand. This does not bother me too\nmuch, but there probably are other examples.\n\nAnother example. I often run \"git ls-files -u\" while looking at which\npaths are conflicting. ls-files is classified as plumbing, but it does\nnot bother me as much as having to see the staged long object names in\nthis output. Other people, however, might find it yucky, and we might\nwant \"git merge --unmerged\" or something that lists the paths (and only\npaths, no stage information) that still have conflicts.\n"},{"id":"83596","messageId":"alpine.DEB.1.10.0807161414590.17859@asgard.lang.hm","threadId":"14486","inReplyTo":"32541b130807161151x19c20f9t91b7fb9b8c7b8c7b@mail.gmail.com","subject":"Re: Considering teaching plumbing to users harmful","fromName":"","fromEmail":"david@lang.hm","sentAt":"2008-07-16T21:16:07Z","receivedAt":"2008-07-16T21:16:07Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Wed, 16 Jul 2008, Avery Pennarun wrote:\n\n> On 7/16/08, Junio C Hamano wrote:\n>> \"Avery Pennarun\" writes:\n>> > git diff :{1,3}:path/to/filename\n>> >\n>> > Which is a great command, but svn definitely makes it easier to do the\n>> > same thing.\n>>\n>> I've never seen anybody who finds \"diff :{1,3}:path\" *useful*.\n>\n> Dunno. I use it frequently, and it works great for me. Perhaps my\n> brain is just poisoned by svn.\n\nthis is exactly the point that Johannes was trying to make, by teaching \npeople these low-level things they get confused and scared. So he is \nsuggesting that everyone make an effort to avoid these (at least \ninitially)\n\nDavid Lang\n\n> I've never tried \"git log -p --merge\". I'll try it next time. This\n> is certainly not common knowledge, however. (But to save Dscho the\n> trouble: git usability in general is not the subject of this thread.)\n>\n>> > Even if you have a repo with widespread push access, git's log looks\n>> > annoying compared to svn because of all the merge commits. That's a\n>> > primary reason why rebase was invented, of course.\n>>\n>> Please don't talk nonsense if you do not know history. I invented rebase\n>> primarily because I wanted to help e-mail based contributors. There is\n>> nothing about merge avoidance to it.\n>\n> Sorry, I mixed up git-rerere and git-rebase. From git-rerere's man page:\n>\n> When your topic branch is long-lived, however, your topic branch would\n> end up having many such \"Merge from master\" commits on it, which would\n> unnecessarily clutter the development history. Readers of the Linux\n> kernel mailing list may remember that Linus complained about such too\n> frequent test merges when a subsystem maintainer asked to pull from a\n> branch full of \"useless merges\".\n>\n> Nowadays, I'm pretty sure people use git-rebase to avoid this sort of\n> problem (or \"git pull --rebase\" presumably wouldn't have appeared),\n> but I can now see how git-rebase was not written *for* this problem.\n>\n> Anyway, my point was that git-rebase (or at least git-rerere and\n> git-reset) are needed if you want to avoid a lot of merge commits.\n> And, to relate it back to this thread, git-rebase cannot possibly be\n> understood without understanding git internals, and git internals are\n> easiest to understand by learning the plumbing.\n>\n> svn avoids these excess merges by default, albeit because it puts your\n> working copy at risk every time you do \"svn update\".\n>\n>> You can skip merges with \"git log --no-merges\", just in case you didn't\n>> know.\n>\n> Perhaps this is mostly a user education or documentation issue. I\n> know about --no-merges, but it's unclear that this is really a safe\n> thing to use, particularly if some of your merges have conflicts.\n> Leaving them out leaves out an important part of history. Do you use\n> this option yourself?\n>\n> Have fun,\n>\n> Avery\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n>\n"},{"id":"83600","messageId":"20080716214849.GF2925@dpotapov.dyndns.org","threadId":"14486","inReplyTo":"alpine.DEB.1.00.0807161804400.8950@racer","subject":"Re: Considering teaching plumbing to users harmful","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2008-07-16T21:48:49Z","receivedAt":"2008-07-16T21:48:49Z","isPatch":false,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"On Wed, Jul 16, 2008 at 06:21:02PM +0100, Johannes Schindelin wrote:\n> \n> I had the pleasure of introducing Git to a few users in the last months \n> and in my opinion, restricting myself to teaching them these commands \n> first helped tremendously:\n> \n> - clone, pull, status, add, commit, push, log\n\nYes, it is a good list, and I think it is very important at the\nbeginning to limit the number commands to 7-8, otherwise many users\nmay be confused. And, of course, it is better to stay away from all\ncommand-line options at first...\n\n> \n> All of these were presented without options, to keep things simple.\n> \n> In particular, I refrained from giving them the \"-a\" option to commit. \n> That seemed to help incredibly with their embracing the index as a natural \n> concept (which it is).\n\nMost things that we call as \"natural\" is those that we got used. Once,\nyou got used to it, it seems very natural, and the index is not\nsomething that is really difficult to learn, but I don't think that\neveryone may understand it fully. Some may use Git for many months and\nonly then suddenly discover that \"git diff\" does not show all\nuncommitted changes, but only changes between their working directory\nand the index. It may sound strange, but it happens.\n\n> Now, it makes me really, really sad that Git has a reputation of being \n> complicated, but I regularly hear from _my_ users that they do not \n> understand how that came about.\n\nI think this reputation is largely due to people who open Git user\nmanual, read about >100 commands, were horrified and stopped learning.\nGit is a powerful and very flexible tool, thus to use it to its fullest\nyou may really need to learn a lot, but it does not mean that you can\nuse it and be much more productive than with other VCS knowing only a\nsmall fraction of all options. Thus if you can explain to users in terms\nthat they understood and connect that with their workflow, users may\nfind Git easier to use than SVN...\n\n> \n> Am I the only one who deems teaching plumbing to users (\"I like it raw! \n> So I teach it the same way!\") harmful?\n\nThere is only one thing that seems to be true about teaching Git (or\nanything else) -- there is no single method that works equally well\nfor anyone. Having said so, I must admit that teaching plumbing will\nbe probably not a good idea for most users, yet there are some who\nprefer bottom-up approach. Some users will prefer to connect Git\nfunctionality to their particular needs and solving some practical\ntasks that they do day in, day out, while others may prefer to start\nwith more abstract things like DAG, structure of data, etc... For\nthe later users, when you explained these basic things, you do not\nhave to explain commands at all. They may occasionally ask you\nsomething like: git grep works fine for me when I need to find\nsomething in arbitrary file at some particular revision, but how\nabout finding something in a particular file at arbitrary revision?\nThen you say -- look at git log, it should have the grep option. It\nis usually all explanations that you need to provide for them. The\nrest, they will quickly pick up on their own. Yet, majority users are\nnot like that. They seem to prefer to start with specific use cases\nand only basic porcelain commands... So, I agree with you here.\n\nDmitry\n"},{"id":"83602","messageId":"alpine.LNX.1.00.0807161605550.19665@iabervon.org","threadId":"14486","inReplyTo":"32541b130807161135h64024151xc60e23d222a3a508@mail.gmail.com","subject":"Re: Considering teaching plumbing to users harmful","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2008-07-16T21:53:49Z","receivedAt":"2008-07-16T21:53:49Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Wed, 16 Jul 2008, Avery Pennarun wrote:\n\n> On 7/16/08, Johannes Schindelin wrote:\n> \n> > > At the very least, there will be branches.\n> >\n> > Oh. And you have to teach plumbing for that?\n> \n> In svn, a branch is a revision-controlled directory. In git, a branch\n> is a \"ref\". What's a ref? Well, it's a name for a commit. What's a\n> commit? Well, it's a blob. What's a blob? Err, that's complicated.\n\nYou're simply wrong. A ref isn't a name for a commit (the point of having \na ref is that it doesn't persist in naming the same commit). A commit \nisn't a blob. If you start telling people complicated and wrong things, \nthey're surely going to be confused.\n\nGit maintains history as a directed graph, with each commit pointing back \nat its history. Refs are the what holds the newest commits that nothing \nelse points back to. If directed graphs aren't in your users' experience, \nyou can put it this way: git maintains history like knitting, where each \nnew stitch holds on to one or more previous stitches, and refs are the \nknitting needles that hold the ends where you're working (except that \nknitting is a lot wider than software development). gitk --all even \nprovides the diagram you want to explain it.\n\nSVN branches are incredible confusing because they fail to distinguish the \ndirectory structure of the project's source tree from the arrangement of \navailable latest versions. And the version numbers for your branch \nincrease when changes are made to other branches.\n\n> > I will not even bother to reply to your mentioning rebase, submodules, and\n> > the \"complicated\" log due to merges for that very reason: all of this can\n> > be done, easily, with porcelain.\n> \n> My point was that the porcelain doesn't even make that stuff easy, and\n> thus you need to understand fundamental git internal concepts to use\n> them, and fundamental git internals are easiest to teach using the\n> plumbing, which doesn't try to hide them.\n\nI don't think the plumbing does a particularly good job of elucidating the \nfundamental git internals; the plumbing does single operations on the \nfundamental structures, but that doesn't explain what the fundamental \nstructures are, or what they mean, or why you'd do particular things to \nthem. In fact, they don't at all show the difference between what's \nexpected to change frequently and what's permanent, which will tend to \ngive you wrong ideas.\n\nAnd for understanding the basic objects, \"git show\" will work better than \n\"git cat-file\" (there's no fundamental reason that trees are binary data \nand other types aren't, and no particular reason to care about the time \nformat in commit headers, etc), and the plumbing programs for creating the \nfundamental objects are an even more uneven and arbitrary presentation.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"83603","messageId":"20080716215917.GG2925@dpotapov.dyndns.org","threadId":"14486","inReplyTo":"32541b130807161151x19c20f9t91b7fb9b8c7b8c7b@mail.gmail.com","subject":"Re: Considering teaching plumbing to users harmful","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2008-07-16T21:59:17Z","receivedAt":"2008-07-16T21:59:17Z","isPatch":false,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"On Wed, Jul 16, 2008 at 02:51:30PM -0400, Avery Pennarun wrote:\n> \n> svn avoids these excess merges by default, albeit because it puts your\n> working copy at risk every time you do \"svn update\".\n\nYou can do \"git pull --rebase\" if you like. And there is a configuration\noption that allows you to avoid typing --rebase every time. Or did you\nmean to being to do that without saving your changes? I think the later\nis really a bogus idea, and it should not be encouraged. The worst than\nthat can be only say \"svn update\" while you still have not saved changes\nin your editor. Then you will have even more fun. So the rule should be:\nsave your changes first, and only then pull from the upstream.\n\nBTW, one thing is to avoid excessive merges, and the other thing is to\ndo not have this feature at all. SVN is still not capable to merge,\nbecause merge means to have more than one parent. SVN cannot do that.\nWhat SVN does instead is very limited and buggy cherry-picking:\nhttp://subversion.tigris.org/issues/show_bug.cgi?id=2897\n\nIn fact, this is not cherry-picking patches but per-file cherry-picking\nand due to limitations of their automatic revision filtering, they have\na nice feature -- to edit svn:mergeinfo manually. Obviously, it is\nimpossible to visualize this per-file property well. Thus when you are\ngoing to merge something in SVN, you have no slightest idea what you are\nreally doing.\n\nHave fun,\nDmitry\n"},{"id":"83605","messageId":"20080716220946.GC18558@leksak.fem-net","threadId":"14486","inReplyTo":"alpine.DEB.1.00.0807161804400.8950@racer","subject":"Re: Considering teaching plumbing to users harmful","fromName":"Stephan Beyer","fromEmail":"s-beyer@gmx.net","sentAt":"2008-07-16T22:09:46Z","receivedAt":"2008-07-16T22:09:46Z","isPatch":false,"sender":{"key":"s-beyer@gmx.net","avatar":"https://avatars.githubusercontent.com/u/143889?v=4"},"body":"Hi,\n\nJohannes Schindelin wrote:\n[...]\n> \n> I had the pleasure of introducing Git to a few users in the last months \n> and in my opinion, restricting myself to teaching them these commands \n> first helped tremendously:\n> \n> - clone, pull, status, add, commit, push, log\n> \n> All of these were presented without options, to keep things simple.\n\nBasically I agree, but depending on the user's foreign SCM knowledge\nit could be useful to talk about some basic \"low-level\" concepts of git\n(without talking about the plumbing).\n\nI mean:\n - objects (commits, trees, blobs ... in very short)\n - index\nand perhaps\n - refs (at least branches)\n\nI was told that before I've seen a first git command and I still think\nthat was very useful.\n\nHmm, just recalling, my first git commands were:\n 1. init\n 2. add\n 3. status\n 4. commit\n 5. diff\n 6. log\n 7. branch\n 8. checkout\nin this order, approximately. :)\n\n(And I've used rebase before merge and I haven't used clone/pull/push for\na long time.)\n\nIt seems I haven't touched any plumbing before I've started with GSoC :)\n\nI also think that for a user it is totally irrelevant if it is plumbing or\nporcelain she is using, as long as it works. I mean, if I tought someone\nusing git, I'd never use the words \"porcelain\" or \"plumbing\".\n\nRegards,\n Stephan\n\n-- \nStephan Beyer , PGP 0x6EDDD207FCC5040F\n"},{"id":"83608","messageId":"20080716222458.GH2925@dpotapov.dyndns.org","threadId":"14486","inReplyTo":"32541b130807161229ob4c21cbsc6c86ee3e42c4101@mail.gmail.com","subject":"Re: Considering teaching plumbing to users harmful","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2008-07-16T22:24:58Z","receivedAt":"2008-07-16T22:24:58Z","isPatch":false,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"On Wed, Jul 16, 2008 at 03:29:39PM -0400, Avery Pennarun wrote:\n> \n> I find it interesting how git usability discussions tend to go. It\n> usually starts out by someone saying, \"Look, git really isn't that\n> hard to learn, just do it like this...\" and then someone says, \"But\n> actually, that's still really complicated. Everyone thinks xxx other\n> VCS is easier to learn. Here's how they do it...\" \n\nEveryone thinks so? Somehow, I don't, and there are people who think\nthat Git is easily to learn if you teach it properly.\n\n> And then someone\n> says, \"Yeah, but xxx VCS sucks!\" and that somehow makes it okay that\n> git is empirically harder to learn than xxx VCS, as anyone can see by\n> browsing the web.\n\nBrowsing the web is not an empirical study. And if you say harder, you\nshould specify to whom. To those who already know xxx VCS, naturally\nanything new or different than what you got used to will be difficult\nat the beginning. Naturally, it is easier to learn something if there\nare more books and articles about it, or just there are more people who\ncan answer on any your questions. But with everything else being equal,\ndo you really believe that SVN or CVS is easier to use than Git if we\nspeak about learning comparable functionality? What is your argument\nfor that? \"svn update\"? Well, it is a sure way to make mess in your\nworking directoy. So, your argument does not sound very convincing.\n\nDmitry\n"},{"id":"83609","messageId":"alpine.DEB.1.00.0807170024310.4318@eeepc-johanness","threadId":"14486","inReplyTo":"32541b130807161229ob4c21cbsc6c86ee3e42c4101@mail.gmail.com","subject":"Re: Considering teaching plumbing to users harmful","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-07-16T22:28:27Z","receivedAt":"2008-07-16T22:28:27Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 16 Jul 2008, Avery Pennarun wrote:\n\n> I find it interesting how git usability discussions tend to go.\n\nI find it not interesting at all, even slightly annoying, that I cannot \nseem to start a perfectly valid discussion about advocating porcelain, and \ntrying to even avoid mentioning plumbing in user-visible documentation, \nwithout somebody highjacking the thread to talk about svn.\n\nI am disinterested in svn. So disinterested that I do not even want to \nread about it. What we could learn from svn, we did, positive and \nnegative lessons, now there is nothing more to be seen here, please move \nalong.\n\nSo can those people who have something to say about _my_ subject of \ndiscussion please speak up? I think this issue has not been discussed \nproperly.\n\nThanks.\nDscho\n"},{"id":"83610","messageId":"20080716223205.GK2167@mit.edu","threadId":"14486","inReplyTo":"7vr69tpoze.fsf@gitster.siamese.dyndns.org","subject":"Re: Considering teaching plumbing to users harmful","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2008-07-16T22:32:05Z","receivedAt":"2008-07-16T22:32:05Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Wed, Jul 16, 2008 at 01:12:53PM -0700, Junio C Hamano wrote:\n> If you are advocating that mode of operation to be easy in git, you should\n> think again. That pull (be it with or without --rebase) can conflict and\n> you would need to resolve it, and then your \"stash pop\" can conflict\n> again. You can have your own \"git avery-up\" alias which is your \"svn up\"\n> equivalent, but if you train users with that first, the users have to\n> learn how to cope with conflicts in individual steps anyway.\n> \n> Making these three into a single alias is not an improvement either. If\n> you are not ready to incorporate other's changes to your history, why are\n> you pulling? Being distributed gives the power of working independently\n> and at your own pace. You should train your brain to think about the\n> workflow first. \"You should stash before pull\" is _not_ a good advice.\n> \"Do not pull when you are not ready\" is.\n\nWhat I've found is that some people will take that advice, and other\npeople won't. Saying that you are thinking about things the wrong way\ndoesn't really help for people who have been so ingrained into an old\nway of doing things. Indeed, it can end up sounding very elistist.\n\nSo from a pedagogical perspective, what I would probably do is show\nthem how to replicate svn-up, and explain to them how this script\nworks:\n\n#!/bin/sh\n# git-up\n\nif git diff --quiet && git diff --quiet --cached ; then\n\tgit pull $*\nelse\n\tgit stash ; git pull $*; git stash pop\nfi\n\nAnd then tell them that if this put this into their path, then \"git\nup\" will work the same way as \"svn up\" --- but that git has a better\nway of doing things, and why it is so. And then what I would tell\nthem is that no really, merges are really easy with git, and that even\nif they were to rely on the \"git up\" alias as a crutch, that over time\nthey would find that there are much more natural, easy, and powerful\nways of doing things.\n\nIn general, I find that people are more willing to listen to \"we have\na more powerful way of doing things\", if you can first give them the\nequivalent of the \"dumb and stupid\" way that they are used to doing\nthings so they can switch to the new tool right away without too much\nof a steep learning curve; they will then switch to the more\nadvanced/powerful workflows at their own pace. Other people may have\nother pedgogical techniques, but I find mine to work fairly well.\n\nRegards,\n\n\t\t\t\t\t\t- Ted\n"},{"id":"83612","messageId":"7vod4xo3j4.fsf@gitster.siamese.dyndns.org","threadId":"14486","inReplyTo":"20080716223205.GK2167@mit.edu","subject":"Re: Considering teaching plumbing to users harmful","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-07-16T22:41:35Z","receivedAt":"2008-07-16T22:41:35Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Theodore Tso writes:\n\n> So from a pedagogical perspective, what I would probably do is show\n> them how to replicate svn-up, and explain to them how this script\n> works:\n>\n> #!/bin/sh\n> # git-up\n>\n> if git diff --quiet && git diff --quiet --cached ; then\n> \tgit pull $*\n> else\n> \tgit stash ; git pull $*; git stash pop\n> fi\n\nLooks good, except:\n\n\tif git diff ....; then\n\t\tgit pull \"$@\"\n\telse\n \tgit stash && git pull \"$@\" && git stash pop\n\tfi\n\nto make sure the conflict notices won't be scrolled off by error messages\nfrom the later commands.\n"},{"id":"83613","messageId":"20080716224954.GL2167@mit.edu","threadId":"14486","inReplyTo":"alpine.DEB.1.00.0807170024310.4318@eeepc-johanness","subject":"Re: Considering teaching plumbing to users harmful","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2008-07-16T22:49:54Z","receivedAt":"2008-07-16T22:49:54Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Thu, Jul 17, 2008 at 12:28:27AM +0200, Johannes Schindelin wrote:\n> Hi,\n> \n> On Wed, 16 Jul 2008, Avery Pennarun wrote:\n> \n> > I find it interesting how git usability discussions tend to go.\n> \n> I find it not interesting at all, even slightly annoying, that I cannot \n> seem to start a perfectly valid discussion about advocating porcelain, and \n> trying to even avoid mentioning plumbing in user-visible documentation, \n> without somebody highjacking the thread to talk about svn.\n\nI've already said I agree with you, but maybe it would be helpful if\nyou focused the discussion a little more with a concrete suggestion\nabout how we could improve the user-visible documentation. For\nexample, it is already the case that \"git help\" only shows porcelain\ncommands, that has been a big step forward.\n\nSo a concrete suggestion might be to move the list of plumbing\ncommands from the top-level git man page to a \"git-plumbing\" man page.\n\nI'll note that the git user manual is pretty good about avoiding the\nuse of git plumbing commands. It's not until Chapter 9, \"Low Level\nGit Commands\" that it start going into the plumbing. (There are a\ncouple of mentions of git rev-parse before chapter 9, but that's about\nit that I could find).\n\nWas there other git documentation where you think there is too many\nreferences to git plumbing?\n\n\t\t\t\t\t\t- Ted\n"},{"id":"83614","messageId":"89b129c60807161553u58f0c926yed4d6fabe49f42af@mail.gmail.com","threadId":"14486","inReplyTo":"20080716223205.GK2167@mit.edu","subject":"Re: Considering teaching plumbing to users harmful","fromName":"Sean Kelley","fromEmail":"sean.v.kelley@gmail.com","sentAt":"2008-07-16T22:53:45Z","receivedAt":"2008-07-16T22:53:45Z","isPatch":false,"sender":{"key":"sean.v.kelley@gmail.com","avatar":null},"body":"Hi\n\nOn Wed, Jul 16, 2008 at 5:32 PM, Theodore Tso wrote:\n>\n> In general, I find that people are more willing to listen to \"we have\n> a more powerful way of doing things\", if you can first give them the\n> equivalent of the \"dumb and stupid\" way that they are used to doing\n> things so they can switch to the new tool right away without too much\n> of a steep learning curve; they will then switch to the more\n> advanced/powerful workflows at their own pace. Other people may have\n> other pedgogical techniques, but I find mine to work fairly well.\n>\n> Regards,\n>\n> - Ted\n\n\n\nWhen one has 100 users in a company using a DVCS, you really need some\nsort of simplified workflow documented and taught. Not everyone who\nwrites code is particularly keen on the vagaries of a VCS' commands.\nI know that must be shocking to this audience the GIT list, but it is\nvery very true. They don't give a crap what sort of weird command\ncombination one can pull out of the 100 or so commands when you type\ngit- at a bash prompt. They just want the damn thing to behave\nin a somewhat friendly fashion. They want to check in their code and\nget on with software development and not over analyzing how many ways\nthey can do the same command. In my experience, what Ted is\nsuggesting is the only way to handle it. Most developers just want it\nto work and focus on debugging their project. Never expect your users\nto have the same interest as you in VCS.\n\nSean\n"},{"id":"83615","messageId":"alpine.DEB.1.00.0807170100320.4318@eeepc-johanness","threadId":"14486","inReplyTo":"7vmykhpn6z.fsf@gitster.siamese.dyndns.org","subject":"Re: Considering teaching plumbing to users harmful","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-07-16T23:05:21Z","receivedAt":"2008-07-16T23:05:21Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 16 Jul 2008, Junio C Hamano wrote:\n\n> Johannes Schindelin writes:\n> \n> > Am I the only one who deems teaching plumbing to users (\"I like it raw! \n> > So I teach it the same way!\") harmful?\n> \n> I think that justification is harmful.\n> \n> More productive way to think about it is to identify cases where we \n> _need_ to go down to combination of the plumbing commands in our daily \n> workflow, with today's command set. That would give us a good \n> indication that some Porcelain may need to be enhanced.\n> \n> An example. I find myself running \"git read-tree -m -u $another_state\" \n> while redoing a series inside a \"rebase -i\" session to move commit \n> boundaries. There may need an insn that says \"use that tree\" instead of \n> \"edit\" and running \"read-tree -m -u\" by hand. This does not bother me \n> too much, but there probably are other examples.\n> \n> Another example. I often run \"git ls-files -u\" while looking at which \n> paths are conflicting. ls-files is classified as plumbing, but it does \n> not bother me as much as having to see the staged long object names in \n> this output. Other people, however, might find it yucky, and we might \n> want \"git merge --unmerged\" or something that lists the paths (and only \n> paths, no stage information) that still have conflicts.\n\nI agree that if you know Git internals -- and you and me do -- it comes in \n_right_ handy to know the 100+ commands with many options by heart.\n\nHowever, my point was about telling users, especially new ones.\n\nFor example, I would _never_ suggest the following workflow to a n00b \nbecause it would be confusing:\n\n\t$ tar xvf \n\t\n\t\n\t\n\t\n\t$ git init\n\t$ git remote add -f origin \n\t$ git read-tree \n\t$ git status\n\t$ git add -p\n\t$ git commit -s\n\t\n\t$ git rebase -i origin/master\n\t$ git format-patch -n origin/master\n\nEven if this is something I did at least a handfull times myself.\n\nCiao,\nDscho\n"},{"id":"83616","messageId":"320075ff0807161617v4a4b323ep5c879745bee89759@mail.gmail.com","threadId":"14486","inReplyTo":"20080716223205.GK2167@mit.edu","subject":"Re: Considering teaching plumbing to users harmful","fromName":"Nigel Magnay","fromEmail":"nigel.magnay@gmail.com","sentAt":"2008-07-16T23:17:49Z","receivedAt":"2008-07-16T23:17:49Z","isPatch":false,"sender":{"key":"nigel.magnay@gmail.com","avatar":"https://gravatar.com/avatar/d85cf38287bef3a8e4fa02358d2756d7589f8676c5eeb881ce2f6d731e4526c3?d=mp&s=160"},"body":">\n> In general, I find that people are more willing to listen to \"we have\n> a more powerful way of doing things\", if you can first give them the\n> equivalent of the \"dumb and stupid\" way that they are used to doing\n> things so they can switch to the new tool right away without too much\n> of a steep learning curve; they will then switch to the more\n> advanced/powerful workflows at their own pace. Other people may have\n> other pedgogical techniques, but I find mine to work fairly well.\n>\n\nThat totally mirrors my experience.\n\nUnless you're teaching people totally new to SCM, they're likely to\nhave experience of something else, and are likely to ask 'but how do I\ndo xyz'. And sometimes the reply is rather embarrassing, as the new\nand powerful way involves 5x as many commands. That's where it gets\nthe reputation of complexity (when actually it might be more correct\nto be a reputation of verbosity).\n\nI tend to actually avoid the commands (porcelain or plumbing) to begin\nwith, and actually concentrate on the data structures (commits, blobs,\nindex etc) - then how various people's repos look when you do\nparticular commands. That way people tend to relax about the many\ncommands as they can grok that there's probably lots of things you\nneed to do bit by bit, but that aren't relevant to understand right\nnow - this seems to help in abstracting away the complexity without\nsweeping it under the carpet.\n\nSo I pretty much agree. Your set looks good, but I always do fetch and\nmerge before pull, and also add rebase at the end.\n"},{"id":"83617","messageId":"alpine.DEB.1.00.0807170105280.4318@eeepc-johanness","threadId":"14486","inReplyTo":"20080716214849.GF2925@dpotapov.dyndns.org","subject":"Re: Considering teaching plumbing to users harmful","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-07-16T23:19:44Z","receivedAt":"2008-07-16T23:19:44Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 17 Jul 2008, Dmitry Potapov wrote:\n\n> On Wed, Jul 16, 2008 at 06:21:02PM +0100, Johannes Schindelin wrote:\n> > \n> > I had the pleasure of introducing Git to a few users in the last \n> > months and in my opinion, restricting myself to teaching them these \n> > commands first helped tremendously:\n> > \n> > - clone, pull, status, add, commit, push, log\n> \n> Yes, it is a good list, and I think it is very important at the \n> beginning to limit the number commands to 7-8, otherwise many users may \n> be confused. And, of course, it is better to stay away from all \n> command-line options at first...\n\nThanks.\n\n> > All of these were presented without options, to keep things simple.\n> > \n> > In particular, I refrained from giving them the \"-a\" option to commit. \n> > That seemed to help incredibly with their embracing the index as a \n> > natural concept (which it is).\n> \n> Most things that we call as \"natural\" is those that we got used.\n\nIn this case, I have to add that it is natural because it is the way you \n_have_ to do it. Even if the other SCMs hide it.\n\nYou almost never commit a full revision. You usually update just a couple \nof files. Now, even CVS has an extra command to add a file, so it accepts \nthe fact that staging and committing are two different operations, even if \n\"cvs add\" does not stage the changes of a tracked file.\n\nOf course, it is easier for us: we can use all the lessons learnt from \nCVS.\n\n> > Now, it makes me really, really sad that Git has a reputation of being \n> > complicated, but I regularly hear from _my_ users that they do not \n> > understand how that came about.\n> \n> I think this reputation is largely due to people who open Git user\n> manual, read about >100 commands, were horrified and stopped learning.\n\nHeh. I catually would be delighted if one outcome of this discussion \nwould be that the user manual starts with a nice big chapter describing \njust my first set of commands, without options.\n\nAnother nice outcome could be if all the plumbing man pages were moved \ninto a different section, and all the porcelain's man pages would be \nchanged to avoid referring to plumbing.\n\nIt could be a good idea, too, to explain advanced topics not by command, \nbut by scenario.\n\n> > Am I the only one who deems teaching plumbing to users (\"I like it \n> > raw! So I teach it the same way!\") harmful?\n> \n> There is only one thing that seems to be true about teaching Git (or\n> anything else) -- there is no single method that works equally well\n> for anyone.\n\nI disagree. I think that the first steps are the same for everyone.\n\nCiao,\nDscho\n"},{"id":"83618","messageId":"alpine.DEB.1.00.0807170120170.4318@eeepc-johanness","threadId":"14486","inReplyTo":"20080716220946.GC18558@leksak.fem-net","subject":"Re: Considering teaching plumbing to users harmful","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-07-16T23:22:55Z","receivedAt":"2008-07-16T23:22:55Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 17 Jul 2008, Stephan Beyer wrote:\n\n> I also think that for a user it is totally irrelevant if it is plumbing \n> or porcelain she is using, as long as it works. I mean, if I tought \n> someone using git, I'd never use the words \"porcelain\" or \"plumbing\".\n\nSo you would say that remembering the name \"rev-parse\" is just as easy as \nremembering \"show\"?\n\nYou want to say that --keep-dash-dash and --stat are on the same level, \nsince both work? Somehow I don't think so.\n\nCiao,\nDscho\n"},{"id":"83621","messageId":"7vk5flo0si.fsf@gitster.siamese.dyndns.org","threadId":"14486","inReplyTo":"alpine.DEB.1.00.0807170100320.4318@eeepc-johanness","subject":"Re: Considering teaching plumbing to users harmful","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-07-16T23:40:45Z","receivedAt":"2008-07-16T23:40:45Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> Hi,\n>\n> On Wed, 16 Jul 2008, Junio C Hamano wrote:\n>\n>> Johannes Schindelin writes:\n>> \n>> > Am I the only one who deems teaching plumbing to users (\"I like it raw! \n>> > So I teach it the same way!\") harmful?\n>> \n>> I think that justification is harmful.\n>> \n>> More productive way to think about it is to identify cases where we \n>> _need_ to go down to combination of the plumbing commands in our daily \n>> workflow, with today's command set. That would give us a good \n>> indication that some Porcelain may need to be enhanced.\n>> \n>> An example. I find myself running \"git read-tree -m -u $another_state\" \n>> while redoing a series inside a \"rebase -i\" session to move commit \n>> boundaries. There may need an insn that says \"use that tree\" instead of \n>> \"edit\" and running \"read-tree -m -u\" by hand. This does not bother me \n>> too much, but there probably are other examples.\n>> \n>> Another example. I often run \"git ls-files -u\" while looking at which \n>> paths are conflicting. ls-files is classified as plumbing, but it does \n>> not bother me as much as having to see the staged long object names in \n>> this output. Other people, however, might find it yucky, and we might \n>> want \"git merge --unmerged\" or something that lists the paths (and only \n>> paths, no stage information) that still have conflicts.\n>\n> I agree that if you know Git internals -- and you and me do -- it comes in \n> _right_ handy to know the 100+ commands with many options by heart.\n>\n> However, my point was about telling users, especially new ones.\n\nPerhaps you did not read my first paragraph?\n"},{"id":"83622","messageId":"alpine.DEB.1.00.0807170152190.4318@eeepc-johanness","threadId":"14486","inReplyTo":"7vk5flo0si.fsf@gitster.siamese.dyndns.org","subject":"Re: Considering teaching plumbing to users harmful","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-07-17T00:02:04Z","receivedAt":"2008-07-17T00:02:04Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 16 Jul 2008, Junio C Hamano wrote:\n\n> Johannes Schindelin writes:\n> \n> > On Wed, 16 Jul 2008, Junio C Hamano wrote:\n> >\n> >> Johannes Schindelin writes:\n> >> \n> >> > Am I the only one who deems teaching plumbing to users (\"I like it \n> >> > raw! So I teach it the same way!\") harmful?\n> >> \n> >> I think that justification is harmful.\n> >> \n> >> More productive way to think about it is to identify cases where we \n> >> _need_ to go down to combination of the plumbing commands in our \n> >> daily workflow, with today's command set. That would give us a good \n> >> indication that some Porcelain may need to be enhanced.\n> >> \n> >> An example. I find myself running \"git read-tree -m -u $another_state\" \n> >> while redoing a series inside a \"rebase -i\" session to move commit \n> >> boundaries. There may need an insn that says \"use that tree\" instead of \n> >> \"edit\" and running \"read-tree -m -u\" by hand. This does not bother me \n> >> too much, but there probably are other examples.\n> >> \n> >> Another example. I often run \"git ls-files -u\" while looking at which \n> >> paths are conflicting. ls-files is classified as plumbing, but it does \n> >> not bother me as much as having to see the staged long object names in \n> >> this output. Other people, however, might find it yucky, and we might \n> >> want \"git merge --unmerged\" or something that lists the paths (and only \n> >> paths, no stage information) that still have conflicts.\n> >\n> > I agree that if you know Git internals -- and you and me do -- it comes in \n> > _right_ handy to know the 100+ commands with many options by heart.\n> >\n> > However, my point was about telling users, especially new ones.\n> \n> Perhaps you did not read my first paragraph?\n\nWell, I did.\n\nBut as was visible from the thread including this message:\n\nhttp://thread.gmane.org/gmane.comp.version-control.git/59935/focus=62021\n\nI take it that we do not really have to go down to the plumbing that \noften.\n\nSure, advanced usage is nice, and often involves plumbing, especially for \nscripting. And there is a time to explain plumbing. But I think that the \nfirst lesson is not it. Not even the second or the third.\n\nAnd as I said in my first mail, I consider it harmful to _start out_ with \nplumbing.\n\nAnd other answers in this thread (the ones that do not try to highjack the \nthread to talk about a crappy but popular SCM) make me even more certain \nof that.\n\nCiao,\nDscho\n\nP.S.: Of course, there may be users who like to spend a lot of time \ngrasping the internals of Git first, before issuing their first Git \ncommand. Just like there are people who like electrodes on their thighs.\n"},{"id":"83625","messageId":"alpine.DEB.1.00.0807170218280.4318@eeepc-johanness","threadId":"14486","inReplyTo":"20080716224954.GL2167@mit.edu","subject":"Re: Considering teaching plumbing to users harmful","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-07-17T00:25:05Z","receivedAt":"2008-07-17T00:25:05Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 16 Jul 2008, Theodore Tso wrote:\n\n> I've already said I agree with you, but maybe it would be helpful if you \n> focused the discussion a little more with a concrete suggestion about \n> how we could improve the user-visible documentation.\n\nWell, I was not sure if I was full of shot or not.\n\n> So a concrete suggestion might be to move the list of plumbing commands \n> from the top-level git man page to a \"git-plumbing\" man page.\n\nI think that would not help much.\n\nAs I replied to Dimitry, I could imagine that moving the plumbing into its \nown manual section would be a way.\n\n> I'll note that the git user manual is pretty good about avoiding the use \n> of git plumbing commands. It's not until Chapter 9, \"Low Level Git \n> Commands\" that it start going into the plumbing. (There are a couple of \n> mentions of git rev-parse before chapter 9, but that's about it that I \n> could find).\n\nWell, rev-parse is one of my pet peeves this day. rev-parse is _nothing_ \nbut plumbing.\n\n> Was there other git documentation where you think there is too many \n> references to git plumbing?\n\nActually, the problem arose with a few \"tutorials\" on the web, and their \ncreators violently arguing for their ways (and me being more and more \nuncertain if they are wrong or me).\n\nAnd then I saw people on IRC doing the same thing. Realizing that the \nrecipients of the \"help\" were more confused than before, and just typed \nwhat was written (they would probably even have typed \"rm -rf $HOME\") \nbecause they had given up trying to understand.\n\nCiao,\nDscho\n"},{"id":"83631","messageId":"20080717010115.GD18558@leksak.fem-net","threadId":"14486","inReplyTo":"alpine.DEB.1.00.0807170120170.4318@eeepc-johanness","subject":"Re: Considering teaching plumbing to users harmful","fromName":"Stephan Beyer","fromEmail":"s-beyer@gmx.net","sentAt":"2008-07-17T01:01:15Z","receivedAt":"2008-07-17T01:01:15Z","isPatch":false,"sender":{"key":"s-beyer@gmx.net","avatar":"https://avatars.githubusercontent.com/u/143889?v=4"},"body":"Hi,\n\nJohannes Schindelin wrote:\n> Hi,\n> \n> On Thu, 17 Jul 2008, Stephan Beyer wrote:\n> \n> > I also think that for a user it is totally irrelevant if it is plumbing \n> > or porcelain she is using, as long as it works. I mean, if I tought \n> > someone using git, I'd never use the words \"porcelain\" or \"plumbing\".\n> \n> So you would say that remembering the name \"rev-parse\" is just as easy as \n> remembering \"show\"?\n\n\"show\" is an intuitional name, \"rev-parse\" is not.[1]\nBut that wasn't my point. The point was, that it is not important to a\nuser whether the tool is called \"plumbing\" or \"porcelain\"; that these\nterms have no value for the user, if she just wants to get a job done.\n\nOf course, \"usually\" porcelain is more helpful and as I've said (or\nat least tried to say), I don't think there is any plumbing that's\nuseful for a git beginner.\n\nRegards,\n Stephan\n\nFootnote:\n 1. A further comment about the intuitionality or \"remembering\":\n git-apply is plumbing and has an intuitional name (hence easy to\n remember), git-am is porcelain and does not have one.\n\n-- \nStephan Beyer , PGP 0x6EDDD207FCC5040F\n"},{"id":"83636","messageId":"20080717024735.GA23896@mit.edu","threadId":"14486","inReplyTo":"alpine.DEB.1.00.0807170218280.4318@eeepc-johanness","subject":"Re: Considering teaching plumbing to users harmful","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2008-07-17T02:47:35Z","receivedAt":"2008-07-17T02:47:35Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Thu, Jul 17, 2008 at 02:25:05AM +0200, Johannes Schindelin wrote:\n> Well, rev-parse is one of my pet peeves this day. rev-parse is _nothing_ \n> but plumbing.\n\nActually the the git man page doesn't list rev-parse as plumbing. :-)\n\n> Actually, the problem arose with a few \"tutorials\" on the web, and their \n> creators violently arguing for their ways (and me being more and more \n> uncertain if they are wrong or me).\n\nI know you don't like hearing about SVN, but normally the tutorials I\ntend to point people to, in addition to the standard official git\ntutorial and git's user manual, are these two web pages. First I tell\npeople to read first part of:\n\n http://utsl.gen.nz/talks/git-svn/intro.html\n\nwhich covers the git \"philosophy\" very nicely, up to the point where\nit starts talking about the \"git svn\" command, and then I tell them to\ngo read:\n\n\thttp://git.or.cz/course/svn.html\n\nThere are no git plumbing commands in either of those two web pages,\nbecause most SVN users would run screaming if they were given a\ntutorial that talked about git-read-tree or git-commit-tree. :-)\n\n\t\t\t\t\t\t\t- Ted\n"},{"id":"83637","messageId":"9b3e2dc20807162021v30fdedcar6ee104ed6bf4b0a3@mail.gmail.com","threadId":"14486","inReplyTo":"20080716223205.GK2167@mit.edu","subject":"Re: Considering teaching plumbing to users harmful","fromName":"Stephen Sinclair","fromEmail":"radarsat1@gmail.com","sentAt":"2008-07-17T03:21:05Z","receivedAt":"2008-07-17T03:21:05Z","isPatch":false,"sender":{"key":"radarsat1@gmail.com","avatar":null},"body":"On Wed, Jul 16, 2008 at 6:32 PM, Theodore Tso wrote:\n> So from a pedagogical perspective, what I would probably do is show\n> them how to replicate svn-up, and explain to them how this script\n> works:\n>\n> #!/bin/sh\n> # git-up\n>\n> if git diff --quiet && git diff --quiet --cached ; then\n> git pull $*\n> else\n> git stash ; git pull $*; git stash pop\n> fi\n\nWouldn't this be confusing if they have a few commits on the local\nbranch that aren't yet pushed to the remote branch?\nThey could suddenly have conflicts that have nothing to do with the\nworking tree, which could throw people off. Not to mention the\nmeaningless merges that clutter the gitk display.\n\nI know I was personally pretty confused the first few times this\nhappened and I had little trapezoidal patterns in gitk showing 2\ncommits being automerged between the local and remote branches. This\nwas before I understood the concepts of local and remote branches.\n\nPerhaps some warning when...\n\nif git diff --quiet origin/master HEAD; then...\n\nPersonally I've since learned that git-pull is a command to think\nabout a little before doing, as opposed to svn up, since you might\nhave to resolve things you aren't prepared for, and we're trying to\navoid teaching git-reset here. I've had to untrain myself from using\ngit-pull, switching to git-fetch/merge more and more often, because I\nkeep doing stupid 3-commit merges by mistake when I didn't intend to.\nSome tracking of what's been pushed and what hasn't is helpful to keep\nthings in the expected order imho.\n\n\nSteve\n"},{"id":"83644","messageId":"7vej5tknlo.fsf@gitster.siamese.dyndns.org","threadId":"14486","inReplyTo":"alpine.DEB.1.00.0807170152190.4318@eeepc-johanness","subject":"Re: Considering teaching plumbing to users harmful","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-07-17T06:53:55Z","receivedAt":"2008-07-17T06:53:55Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n>> > However, my point was about telling users, especially new ones.\n>> \n>> Perhaps you did not read my first paragraph?\n>\n> Well, I did.\n\nThen perhaps I wasn't being clear, and I think we are saying the same\nthing.\n\n> Sure, advanced usage is nice, and often involves plumbing, especially for \n> scripting.\n\nThat is not what I am saying. What I am saying actually is that these\nusage that _need_ to involve plumbing is not \"advanced\", but merely\nshowing weakness of the current Porcelain. Fixing that would allow us\nmove further away from having to resort to plumbing in our daily\nworkflow.\n\nPerhaps our Porcelains already passed that point, in which case you do not\nhave to touch the plumbing commands 99% of time during the day and you do\nnot have to teach new people plumbing at all. I am agreeing that it would\nbe a worthy goal to aim for -- I do not however think we are there yet.\n"},{"id":"83647","messageId":"487EF519.5070902@sneakemail.com","threadId":"14486","inReplyTo":"alpine.DEB.1.00.0807161804400.8950@racer","subject":"Re: Considering teaching plumbing to users harmful","fromName":"Peter Valdemar Mørch (Lists)","fromEmail":"4ux6as402@sneakemail.com","sentAt":"2008-07-17T07:30:33Z","receivedAt":"2008-07-17T07:30:33Z","isPatch":false,"sender":{"key":"4ux6as402@sneakemail.com","avatar":null},"body":"Johannes Schindelin Johannes.Schindelin-at-gmx.de |Lists| wrote:\n> there have been a number of occasions where I came across people trying to \n> be helpful and teaching Git newbies a few tricks.\n> \n> However, in quite a number of cases, which seem to surge over the last \n> weeks, I see people suggesting the use of rev-parse, ls-tree, rev-list \n> etc.\n\nAs a total git newbie (5 days) coming from svn, I *am* bewildered. Even \nsticking to porcelain, it is a feature-rich new tool I have in my hands!\n\nI'm missing clarity about what is porcelain and what is plumbing. `git \nhelp` shows\n\n\"The most commonly used git commands are:\" add .. tag.\n\nIs this list exactly the list of porcelain commands? Then say so there. \nNeither `git help diff` nor `git help ls-tree` say whether they are \nporcelain or plumbing commands. `git help diff` mentions git-diff-index, \nwhich i suspect is plumbing. When I read a man page, it would be nice to \nknow whether a command (either the topic of the page or another \nmentioned command) is intended as porcelain or not.\n\nAlso, I'm guessing that some switches for some porcelain commands have \nplumbing purposes and vice versa. I hope not, but if so that would be \nnice to have documented in 'git help *'\n\nAll of this of course assumes that there is consensus and a clear \ndistinction between what is porcelain and what is plumbing which I'm \ndon't even know if there is.\n\nPeter\n-- \nPeter Valdemar Mørch\nhttp://www.morch.com\n"},{"id":"83667","messageId":"861w1sn4id.fsf@lola.quinscape.zz","threadId":"14486","inReplyTo":"alpine.LNX.1.00.0807161605550.19665@iabervon.org","subject":"Re: Considering teaching plumbing to users harmful","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2008-07-17T11:18:02Z","receivedAt":"2008-07-17T11:18:02Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Daniel Barkalow writes:\n\n> You're simply wrong. A ref isn't a name for a commit (the point of\n> having a ref is that it doesn't persist in naming the same commit). A\n> commit isn't a blob. If you start telling people complicated and wrong\n> things, they're surely going to be confused.\n>\n> Git maintains history as a directed graph, with each commit pointing\n> back at its history. Refs are the what holds the newest commits that\n> nothing else points back to. If directed graphs aren't in your users'\n> experience, you can put it this way: git maintains history like\n> knitting, where each new stitch holds on to one or more previous\n> stitches, and refs are the knitting needles that hold the ends where\n> you're working (except that knitting is a lot wider than software\n> development). gitk --all even provides the diagram you want to explain\n> it.\n\nComplicated and right things are not much less confusing...\n\n> SVN branches are incredible confusing because they fail to distinguish\n> the directory structure of the project's source tree from the\n> arrangement of available latest versions.\n\nThat is because there _is_ no difference. You just store different\nversions in different places. What they are named is a convention,\nnothing more, nothing less.\n\n> And the version numbers for your branch increase when changes are made\n> to other branches.\n\nYou are confusing \"version numbers\" which are assigned by humans with\n\"revision numbers\" which are just an administrational timeline for the\nwhole repository.\n\nReally, Subversion is rather simple to understand. But it is not a\nDVCS. Moving a history from one repository to another is not really\nfeasible unless you are doing straight mirroring.\n\n-- \nDavid Kastrup\n"},{"id":"83678","messageId":"37fcd2780807170538p50221325n5d57f8491bb1723d@mail.gmail.com","threadId":"14486","inReplyTo":"487EF519.5070902@sneakemail.com","subject":"Re: Considering teaching plumbing to users harmful","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2008-07-17T12:38:34Z","receivedAt":"2008-07-17T12:38:34Z","isPatch":false,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"On Thu, Jul 17, 2008 at 11:30 AM, \"Peter Valdemar Mørch (Lists)\"\n<4ux6as402@sneakemail.com> wrote:\n>\n> As a total git newbie (5 days) coming from svn, I *am* bewildered. Even\n> sticking to porcelain, it is a feature-rich new tool I have in my hands!\n>\n> I'm missing clarity about what is porcelain and what is plumbing. `git help`\n> shows\n>\n> \"The most commonly used git commands are:\" add .. tag.\n>\n> Is this list exactly the list of porcelain commands? Then say so there.\n\nThere are a few other commands that are considered as porcelain, but they\nare not so often used or used for very specific purposes, such sending\npatches by email. So, you do not have to bother about them right now.\nIn fact, even this list may be too long to be learned at once. It is\nbetter to proceed step-wise, like this:\n\n=== Getting started ===\n1. Creating your repo\ngit init\ngit clone\n\n2. Commiting your changes\ngit add\ngit commit\n\nThere are also git mv, git rm for those who need them.\n\n3. Inspect your changes before committing them\ngit status\ngit diff\n\n4. Inspecting history\ngit log\n\n5. Synchronization with the upstream\ngit pull\ngit push\n\n=== More commands ===\n\n6. How to revert my changes?\n6.1. reverting uncommitted changes\ngit checkout file\ngit checkout HEAD file\n6.2. committed but not publish changes\ngit reset HEAD^\ngit reset --hard HEAD^\n6.3. published changes\ngit revert\n\n7. Who introduced this change?\ngit log -S as better alternative to git blame\n\n8. Some useful \"tricks\"\ngit grep\ngit add -p\ngit diff --cached\ngit commit --amend\ngit show\ngit log -p\n\n=== Working with branches ===\n\n9. Creating branches and tags\ngit tag\ngit branch\ngit checkout\n\n10. Merging is easy\ngit merge\nBy the way:\ngit pull = git fetch + git merge FETCH_HEAD\ngit merge branch = git pull . branch\n\n11. What is rebase?\nWhen can it be useful?\nAdvantages and disadvantages.\n\n=== More \"advanced\" commands ===\n\n12. git safety net\ngit log -g\n\n13. Find the change that introduced a bug\ngit bisect\n\n14. Short review other commands:\ngit gc\ngit archive\ngit-cherry-pick\ngit remote\ngit format-patch\ngit apply\ngit am\n\n===\n\n> Neither `git help diff` nor `git help ls-tree` say whether they are\n> porcelain or plumbing commands. `git help diff` mentions git-diff-index,\n> which i suspect is plumbing. When I read a man page, it would be nice to\n> know whether a command (either the topic of the page or another mentioned\n> command) is intended as porcelain or not.\n\nI agree, it is very confusing for beginners. The rule of the thumb that\nhelped me when I started was that commands with dash in their names are\nplumbing (there are a few exceptions though).\n\nDmitry\n"},{"id":"83680","messageId":"20080717125536.GO2167@mit.edu","threadId":"14486","inReplyTo":"487EF519.5070902@sneakemail.com","subject":"Re: Considering teaching plumbing to users harmful","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2008-07-17T12:55:36Z","receivedAt":"2008-07-17T12:55:36Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Thu, Jul 17, 2008 at 09:30:33AM +0200, \"Peter Valdemar Mørch (Lists)\" wrote:\n>\n> As a total git newbie (5 days) coming from svn, I *am* bewildered. Even \n> sticking to porcelain, it is a feature-rich new tool I have in my hands!\n>\n> I'm missing clarity about what is porcelain and what is plumbing. `git \n> help` shows\n\nThe top-level man page has a listing of what is porcelain and what is\nplumbing --- although there is some disagreement. Johannes was\ncomplaining about people using git rev-parse in tutorials and saying\nthat there was no way that was porcelain, but in fact it is *not*\nlisted as plumbing in the git man page. So I don't think there is\nreally a strong black-and-white category, but rather a certain set of\nshades of gray, as it were.\n\n> Is this list exactly the list of porcelain commands? Then say so there. \n> Neither `git help diff` nor `git help ls-tree` say whether they are \n> porcelain or plumbing commands. `git help diff` mentions git-diff-index, \n> which i suspect is plumbing. When I read a man page, it would be nice to \n> know whether a command (either the topic of the page or another \n> mentioned command) is intended as porcelain or not.\n\nMy personal long-standing complaint is that there are certain man\npages like \"git log\" where in order to see all of the options which it\ncan take, the man page for git-log redirects you to a man page for\nplumbing. Great way to scare the users. :-)\n\n\nHave you taken a look at the intro-level materials such as \"Everyday\nGit in 20 commands or so\"[1], the git tutorial[2], the official \"Git's\nUser Manual\"[3], or the \"Git-SVN crash course\"[4]? Those are probably\nthe best place to begin --- and to basically treat the git man pages\nas reference materials with a huge number of controls that you won't\nuse or need to use for a long time --- if ever. It's like the 10,000\nfeatures hidden inside Microsoft Office. The features are all\nindispensable to *someone*, but everyone has a different set of the\n100 features which they all *have* to have. (And of course, the 20 or\nso features that everyone really uses. :-)\n\n> All of this of course assumes that there is consensus and a clear \n> distinction between what is porcelain and what is plumbing which I'm \n> don't even know if there is.\n\nI don't think so. It's like what the judge said about pornography ---\nI know it when I see it. :-)\n\nAnd note that there's nothing *wrong* with using plumbing commands.\nIt's just that from a pedagogical point of view, they might not\nnecessarily be the best place to start.\n\n\t\t\t\t\t\t- Ted\n\n[1] http://www.kernel.org/pub/software/scm/git/docs/everyday.html\n[2] http://www.kernel.org/pub/software/scm/git/docs/gittutorial.html\n[3] http://www.kernel.org/pub/software/scm/git/docs/user-manual.html\n[4] http://git.or.cz/course/svn.html\n"},{"id":"83688","messageId":"487F4A9A.1090108@morch.com","threadId":"14486","inReplyTo":"20080717125536.GO2167@mit.edu","subject":"Re: Considering teaching plumbing to users harmful","fromName":"Peter Valdemar Mørch","fromEmail":"lists@morch.com","sentAt":"2008-07-17T13:35:22Z","receivedAt":"2008-07-17T13:35:22Z","isPatch":false,"sender":{"key":"lists@morch.com","avatar":null},"body":"Theodore Tso tytso-at-mit.edu |Lists| wrote:\n> The top-level man page has a listing of what is porcelain and what is\n> plumbing --- although there is some disagreement.\n\nCool! I missed that! Thanks.\n\n> Have you taken a look at the intro-level materials such as \"Everyday\n> Git in 20 commands or so\"[1], the git tutorial[2], the official \"Git's\n> User Manual\"[3], or the \"Git-SVN crash course\"[4]?\n\nYup. I started there and am happily coding, committing, branching & \nmerging away. Now man pages are closest to my fingers in the terminal. :-)\n\nE.g. something I seem to succeed with sometimes, but not consistently is \nthe equivalent of \"svn revert -R .\". \"git help reset\"? Yup: \"git reset \n--hard HEAD .\" When I run into merge conflicts, I'll probably look at \nsuch a doc again, but other than that I'll probably use man pages most.\n\nJust wanted to offer the newbie's opinion, that it would be helpful for \nme with \"Here be plumbing. Newbies look elsewhere\" notices when I'm on \nmy way down the wrong track.\n\nPeter\n-- \nPeter Valdemar Mørch\nhttp://www.morch.com\n"},{"id":"83693","messageId":"63BEA5E623E09F4D92233FB12A9F79430238A144@emailmn.mqsoftware.com","threadId":"14486","inReplyTo":"alpine.DEB.1.00.0807170024310.4318@eeepc-johanness","subject":"RE: Considering teaching plumbing to users harmful","fromName":"Craig L. Ching","fromEmail":"cching@mqsoftware.com","sentAt":"2008-07-17T14:21:58Z","receivedAt":"2008-07-17T14:21:58Z","isPatch":false,"sender":{"key":"cching@mqsoftware.com","avatar":null},"body":" \n\n> -----Original Message-----\n> From: git-owner@vger.kernel.org \n> [mailto:git-owner@vger.kernel.org] On Behalf Of Johannes Schindelin\n> Sent: Wednesday, July 16, 2008 5:28 PM\n> To: Avery Pennarun\n> Cc: Junio C Hamano; git@vger.kernel.org\n> Subject: Re: Considering teaching plumbing to users harmful\n> \n> So can those people who have something to say about _my_ \n> subject of discussion please speak up? I think this issue \n> has not been discussed properly.\n> \nI've read this whole thread with great interest as I started learning\nand using git a few months ago. While I agree with you to a degree,\nthere is a class of \"newbies\" to git who need more than just the basics\nthat you outlined. For instance, I'm in the process of evaluating\nVCS's, and DVCS's in particular, to replace CVS at our workplace.\nBecause of that, I need to get \"up to speed\" as fast as I can. I need\nto know about branches, how to browse history, merging, conflicts, etc.\nIt is true, though, that I have a lot of experience doing these things\nalready by virtue of the fact that I've used VCS's for over a decade and\nhave been evaluating DVCS's for at least the past 3 years, so I have a\nbit of a head start on these things. To learn about these things,\nthough, the sheer size of Git's vocabulary is huge compared to other\nDVCS's. That's a *good* thing, but it also makes it a bit harder to\nlearn it all. It's just a fact of life.\n\nThe first DVCS I learned was monotone. And I think what helped me the\nmost in learning it is that it's syntax is very simple (you'd probably\nsay limited compared to git, but that's neither here nor there, if you\nstick to your original list, git is as simple as monotone), it's\nrepository format, the fact that each developer could keep one\nrepository and create workspaces off of it was perfect for our\nworkflows. What I think really helped with learning monotone is that\nthey had a bunch of common workflows already documented and we could\nsimply try them out. Maybe if Git had a few different workflows\ndocumented that might help. I know we have a \"Git for SVN Users\"\nworkflow, but if you want to move beyond that, it might be good to have\nsome of the more complex workflows documented. I think some people have\nhinted at that suggestion but that maybe it just hasn't been explicitly\nsaid.\n\n> Thanks.\n> Dscho\n> --\n\nCheers,\nCraig\n"},{"id":"83694","messageId":"20080717142654.GQ2167@mit.edu","threadId":"14486","inReplyTo":"487F4A9A.1090108@morch.com","subject":"Re: Considering teaching plumbing to users harmful","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2008-07-17T14:26:54Z","receivedAt":"2008-07-17T14:26:54Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Thu, Jul 17, 2008 at 03:35:22PM +0200, Peter Valdemar Mørch wrote:\n> E.g. something I seem to succeed with sometimes, but not consistently is \n> the equivalent of \"svn revert -R .\". \"git help reset\"? Yup: \"git reset \n> --hard HEAD .\" When I run into merge conflicts, I'll probably look at \n> such a doc again, but other than that I'll probably use man pages most.\n\nYou find quick alias to be a useful replacement for \"svn revert -R\n\" (aka \"hg revert \" and \"bg revert \"):\n\ngit config --global alias.revert-file \"checkout HEAD --\"\n\nOnce you run this command, you can now do \"git revert-file \"\nwhich I personally find very handy. Sometimes I only want to revert\none file, and not all of the files in the working directory, which is\nwhat \"git reset --hard\" will do.\n\n(Note that \"git revert\" does something else useful, but which is not\nthe same as \"hg revert\", \"bk revert\" and \"svn revert\". Oh well, nobody\never said DSCM's had to be consistent.)\n\n\t\t\t\t\t\t- Ted\n"},{"id":"83697","messageId":"20080717145120.GW32184@machine.or.cz","threadId":"14486","inReplyTo":"63BEA5E623E09F4D92233FB12A9F79430238A144@emailmn.mqsoftware.com","subject":"Re: Considering teaching plumbing to users harmful","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2008-07-17T14:51:20Z","receivedAt":"2008-07-17T14:51:20Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Thu, Jul 17, 2008 at 09:21:58AM -0500, Craig L. Ching wrote:\n> Maybe if Git had a few different workflows\n> documented that might help. I know we have a \"Git for SVN Users\"\n> workflow, but if you want to move beyond that, it might be good to have\n> some of the more complex workflows documented. I think some people have\n> hinted at that suggestion but that maybe it just hasn't been explicitly\n> said.\n\nYes, very recently, someone on #git asked about existing documented\nworkflows, and there is very little. It would be interesting project for\nsomeone to build a 'Garden of Git Workflows' (or a Labyrinth) - for each\nworkflow, detailed self-contained documentation ranging from lone developer\nwith topic branches over repo.or.cz/github forks workflow, the workflows\nof \"leaf contributors\", lieutenants and main integrators of the mail-oriented\nkernel/git workflow, up to the single-central-repository workflows.\n\nThere are bits here and there, but the main problem is that they are not\nself-contained. It might be nice to have something like a set of military\nmanuals, appropriate for the roles of the particular developers.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nGNU, n. An animal of South Africa, which in its domesticated state\nresembles a horse, a buffalo and a stag. In its wild condition it is\nsomething like a thunderbolt, an earthquake and a cyclone. -- A. Pierce\n"},{"id":"83702","messageId":"m3od4wse30.fsf@localhost.localdomain","threadId":"14486","inReplyTo":"861w1sn4id.fsf@lola.quinscape.zz","subject":"Re: Considering teaching plumbing to users harmful","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-07-17T15:52:22Z","receivedAt":"2008-07-17T15:52:22Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"David Kastrup writes:\n\n> Daniel Barkalow writes:\n\n> > You're simply wrong. A ref isn't a name for a commit (the point of\n> > having a ref is that it doesn't persist in naming the same commit). A\n> > commit isn't a blob. If you start telling people complicated and wrong\n> > things, they're surely going to be confused.\n\nA ref is a pointer. In the case of branches it is named pointer\nto a commit, \"tip of growth\" of a branch (to stay with analogy from\nbiology).\n\n> > Git maintains history as a directed graph, with each commit pointing\n> > back at its history. Refs are the what holds the newest commits that\n> > nothing else points back to. If directed graphs aren't in your users'\n> > experience, you can put it this way: git maintains history like\n> > knitting, where each new stitch holds on to one or more previous\n> > stitches, and refs are the knitting needles that hold the ends where\n> > you're working (except that knitting is a lot wider than software\n> > development). gitk --all even provides the diagram you want to explain\n> > it.\n>\n> Complicated and right things are not much less confusing...\n \nFor me the idea that commits contain pointers to state of repository\n(state of project) at given \"time\" and pointers to its parents, and\nthose make history simple yet powerfull one.\n\nNevertheless simple ideas not always are easily to explain...\n\n> > SVN branches are incredible confusing because they fail to distinguish\n> > the directory structure of the project's source tree from the\n> > arrangement of available latest versions.\n> \n> That is because there _is_ no difference. You just store different\n> versions in different places. What they are named is a convention,\n> nothing more, nothing less.\n\nBranching by copying (!) and tagging by copying (!!!) is abuse\nof the fact that copying in Subversion is cheap. Distinguishing\nbetween branch part of directory name by _convention_ is design\nmistake; the fact that the tool doesn't help to ensure that\n(a) tags lie on branch (b) tags _doesn't change_ is an example\nof this stupidity.\n \n> > And the version numbers for your branch increase when changes are made\n> > to other branches.\n> \n> You are confusing \"version numbers\" which are assigned by humans with\n> \"revision numbers\" which are just an administrational timeline for the\n> whole repository.\n> \n> Really, Subversion is rather simple to understand. But it is not a\n> DVCS. Moving a history from one repository to another is not really\n> feasible unless you are doing straight mirroring.\n\nSubversion is simple if you are limited to simple things; but the\nsame is true with Git. I find for example the whole 'properties'\nmechanism and its use seriously not simple.\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"83703","messageId":"20080717155538.GE11759@fieldses.org","threadId":"14486","inReplyTo":"7vmykhpn6z.fsf@gitster.siamese.dyndns.org","subject":"Re: Considering teaching plumbing to users harmful","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2008-07-17T15:55:38Z","receivedAt":"2008-07-17T15:55:38Z","isPatch":false,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"On Wed, Jul 16, 2008 at 01:51:31PM -0700, Junio C Hamano wrote:\n> Johannes Schindelin writes:\n> \n> > Am I the only one who deems teaching plumbing to users (\"I like it raw! \n> > So I teach it the same way!\") harmful?\n> \n> I think that justification is harmful.\n> \n> More productive way to think about it is to identify cases where we _need_\n> to go down to combination of the plumbing commands in our daily workflow,\n> with today's command set. That would give us a good indication that some\n> Porcelain may need to be enhanced.\n\nIs there a way to commit the contents of a tarball without using\nplumbing? I occasionally want to track an upstream that I know only as\na series of tarballs, so I do something like:\n\n\tcd repo/\n\tgit checkout upstream\n\trm -rf *\n\ttar -xzvf ../new-version.tar.gz\n\nThen I spend some time mucking around with git-add and git-rm and\neventually end up having to do some sort of git ls-files | git\nupdate-index pipeline.\n\n--b.\n"},{"id":"83704","messageId":"20080717155723.GF11759@fieldses.org","threadId":"14486","inReplyTo":"20080717145120.GW32184@machine.or.cz","subject":"Re: Considering teaching plumbing to users harmful","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2008-07-17T15:57:23Z","receivedAt":"2008-07-17T15:57:23Z","isPatch":false,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"On Thu, Jul 17, 2008 at 04:51:20PM +0200, Petr Baudis wrote:\n> On Thu, Jul 17, 2008 at 09:21:58AM -0500, Craig L. Ching wrote:\n> > Maybe if Git had a few different workflows\n> > documented that might help. I know we have a \"Git for SVN Users\"\n> > workflow, but if you want to move beyond that, it might be good to have\n> > some of the more complex workflows documented. I think some people have\n> > hinted at that suggestion but that maybe it just hasn't been explicitly\n> > said.\n> \n> Yes, very recently, someone on #git asked about existing documented\n> workflows, and there is very little. It would be interesting project for\n> someone to build a 'Garden of Git Workflows' (or a Labyrinth) -\n\nThat's been requested for a long time, but nobody's gotten around to it.\n\nIt might be nice if it could be made a superset of everyday.txt.\n\n--b.\n\n> for each\n> workflow, detailed self-contained documentation ranging from lone developer\n> with topic branches over repo.or.cz/github forks workflow, the workflows\n> of \"leaf contributors\", lieutenants and main integrators of the mail-oriented\n> kernel/git workflow, up to the single-central-repository workflows.\n> \n> There are bits here and there, but the main problem is that they are not\n> self-contained. It might be nice to have something like a set of military\n> manuals, appropriate for the roles of the particular developers.\n> \n> -- \n> \t\t\t\tPetr \"Pasky\" Baudis\n> GNU, n. An animal of South Africa, which in its domesticated state\n> resembles a horse, a buffalo and a stag. In its wild condition it is\n> something like a thunderbolt, an earthquake and a cyclone. -- A. Pierce\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n"},{"id":"83705","messageId":"20080717160346.GA26862@diana.vm.bytemark.co.uk","threadId":"14486","inReplyTo":"20080717155538.GE11759@fieldses.org","subject":"Re: Considering teaching plumbing to users harmful","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2008-07-17T16:03:46Z","receivedAt":"2008-07-17T16:03:46Z","isPatch":false,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2008-07-17 11:55:38 -0400, J. Bruce Fields wrote:\n\n> Is there a way to commit the contents of a tarball without using\n> plumbing?\n\ncontrib/fast-import/import-tars.perl\n\nIt currently lacks a bit in flexibility, IIRC, but it does its job\nwell.\n\n-- \nKarl Hasselström, kha@treskal.com\n www.treskal.com/kalle\n"},{"id":"83706","messageId":"86k5fk1ooq.fsf@lola.quinscape.zz","threadId":"14486","inReplyTo":"m3od4wse30.fsf@localhost.localdomain","subject":"Re: Considering teaching plumbing to users harmful","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2008-07-17T16:05:25Z","receivedAt":"2008-07-17T16:05:25Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Jakub Narebski writes:\n\n> David Kastrup writes:\n>\n>> Daniel Barkalow writes:\n>\n>> > SVN branches are incredible confusing because they fail to\n>> > distinguish the directory structure of the project's source tree\n>> > from the arrangement of available latest versions.\n>> \n>> That is because there _is_ no difference. You just store different\n>> versions in different places. What they are named is a convention,\n>> nothing more, nothing less.\n>\n> Branching by copying (!) and tagging by copying (!!!) is abuse\n> of the fact that copying in Subversion is cheap.\n\nUh, no. A lot of work has been invested into ensuring that copying in\nSubversion in cheap _exactly_ because of the design decision to\nimplement branching and tagging via copying.\n\nIt is not an accident that copying is cheap.\n\n> Distinguishing between branch part of directory name by _convention_\n> is design mistake; the fact that the tool doesn't help to ensure that\n> (a) tags lie on branch (b) tags _doesn't change_ is an example of this\n> stupidity.\n\nHow much have you worked with Subversion so far? I am doing quite a bit\nof work with it, and the do-everything-via-copying paradigm does not get\nin my hair. It actually means that I have to remember fewer commands.\nAnd it is pretty easy to understand.\n\n>> Really, Subversion is rather simple to understand. But it is not a\n>> DVCS. Moving a history from one repository to another is not really\n>> feasible unless you are doing straight mirroring.\n>\n> Subversion is simple if you are limited to simple things; but the\n> same is true with Git. I find for example the whole 'properties'\n> mechanism and its use seriously not simple.\n\nGranted, particularly concerning the external property. OTOH, it makes\nthe equivalent of git submodules rather cheap (and I actually still have\nno idea how git submodules properly work and what implications they\nhave).\n\n-- \nDavid Kastrup\n"},{"id":"83708","messageId":"63BEA5E623E09F4D92233FB12A9F79430238A167@emailmn.mqsoftware.com","threadId":"14486","inReplyTo":"m3od4wse30.fsf@localhost.localdomain","subject":"Subversion is actually not so simple (was RE: Considering teaching plumbing to users harmful)","fromName":"Craig L. Ching","fromEmail":"cching@mqsoftware.com","sentAt":"2008-07-17T16:11:37Z","receivedAt":"2008-07-17T16:11:37Z","isPatch":false,"sender":{"key":"cching@mqsoftware.com","avatar":null},"body":" \n\n> -----Original Message-----\n> From: git-owner@vger.kernel.org \n> [mailto:git-owner@vger.kernel.org] On Behalf Of Jakub Narebski\n> Sent: Thursday, July 17, 2008 10:52 AM\n> To: David Kastrup\n> Cc: git@vger.kernel.org\n> Subject: Re: Considering teaching plumbing to users harmful\n> \n> Subversion is simple if you are limited to simple things; but \n> the same is true with Git. I find for example the whole 'properties'\n> mechanism and its use seriously not simple.\n> \nYes, that's exactly right. Because SVN's underlying repository is\ncomplex, it sometimes falls out in the UI. If you stick with the way\nSVN wants you to do things, you can get along with it fairly well. But\nthat's the problem, it's just not flexible. On the other hand, Git's\nconcept of the repository is so simple and clean, it's a DAG and you can\nactually do a lot more with fewer commands. But then you can do so much\nmore as well and work the way *you* want to.\n\nFor instance, SVN has a history of having to invent concepts that just\nshouldn't need to be invented. Their latest release includes something\nthey call \"merge tracking\", but it falls on the floor in the face of\nwhat they call \"reflective merging.\" [1] I don't find \"merge tracking\"\nand \"reflective merges\" concepts that I should *have* to understand when\nit comes to working with a VCS, the VCS should just *do* those things.\nThose concepts just don't exist in Git. Frankly, I don't find\nSubversion to be easier to use than Git at all and this is coming from a\nvery long-time CVS user. I do find, however, that Git has a very large\nvocabulary and that does take some time to learn, but I'd argue that\nthis is due to it's inherent flexibility than it is due to any inherent\nflaws.\n\n[1] -- http://blogs.open.collab.net/svn/2008/07/subversion-merg.html\n\n> --\n> Jakub Narebski\n> Poland\n> ShadeHawk on #git\n> --\n\nCheers,\nCraig\n"},{"id":"83709","messageId":"63BEA5E623E09F4D92233FB12A9F79430238A16B@emailmn.mqsoftware.com","threadId":"14486","inReplyTo":"86k5fk1ooq.fsf@lola.quinscape.zz","subject":"Subversion's do-everything-via-copying paradigm ( was RE: Re: Considering teaching plumbing to users harmful)","fromName":"Craig L. Ching","fromEmail":"cching@mqsoftware.com","sentAt":"2008-07-17T16:18:06Z","receivedAt":"2008-07-17T16:18:06Z","isPatch":false,"sender":{"key":"cching@mqsoftware.com","avatar":null},"body":" \n\n> -----Original Message-----\n> From: git-owner@vger.kernel.org \n> [mailto:git-owner@vger.kernel.org] On Behalf Of David Kastrup\n> Sent: Thursday, July 17, 2008 11:05 AM\n> To: git@vger.kernel.org\n> Subject: Re: Considering teaching plumbing to users harmful\n> \n> How much have you worked with Subversion so far? I am doing \n> quite a bit of work with it, and the \n> do-everything-via-copying paradigm does not get in my hair. \n> It actually means that I have to remember fewer commands.\n> And it is pretty easy to understand.\n> \n\nDoes it not bother you that renaming a file is a copy + delete [1].\nHave they fixed that yet? That was one of the biggest reasons we never\nmoved to subversion.\n\nOk, I'm done picking on Subversion for now :-P\n\n[1] -- http://subversion.tigris.org/issues/show_bug.cgi?id=898\n\n> --\n> David Kastrup\n> \n\nCheers,\nCraig\n"},{"id":"83714","messageId":"7vzlogh3e7.fsf@gitster.siamese.dyndns.org","threadId":"14486","inReplyTo":"20080717125536.GO2167@mit.edu","subject":"Re: Considering teaching plumbing to users harmful","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-07-17T16:38:40Z","receivedAt":"2008-07-17T16:38:40Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Theodore Tso writes:\n\n> Have you taken a look at the intro-level materials such as \"Everyday\n> Git in 20 commands or so\"[1], the git tutorial[2], the official \"Git's\n> User Manual\"[3], or the \"Git-SVN crash course\"[4]? Those are probably\n> the best place to begin --- and to basically treat the git man pages\n> as reference materials with a huge number of controls that you won't\n> use or need to use for a long time --- if ever.\n\nGood advice.\n\nOne caution is that I wrote the Everyday quite a while ago, certainly way\nbefore 1.5.0, and I suspect the set of best commands and best ways to do\nwhat these sections demonstrate to do may have changed. I do not think\nold ways stopped working (that would be a regression), but there would be\nbetter ways invented after the document was last updated.\n"},{"id":"83726","messageId":"200807171937.03270.jnareb@gmail.com","threadId":"14486","inReplyTo":"63BEA5E623E09F4D92233FB12A9F79430238A167@emailmn.mqsoftware.com","subject":"Re: Subversion is actually not so simple (was RE: Considering teaching plumbing to users harmful)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-07-17T17:37:02Z","receivedAt":"2008-07-17T17:37:02Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Thu, 17 July 2008, Craig L. Ching wrote:\n\n> For instance, SVN has a history of having to invent concepts that just\n> shouldn't need to be invented. Their latest release includes something\n> they call \"merge tracking\", but it falls on the floor in the face of\n> what they call \"reflective merging.\" [1] I don't find \"merge tracking\"\n> and \"reflective merges\" concepts that I should *have* to understand when\n> it comes to working with a VCS, the VCS should just *do* those things.\n> Those concepts just don't exist in Git. Frankly, I don't find\n> Subversion to be easier to use than Git at all and this is coming from a\n> very long-time CVS user. I do find, however, that Git has a very large\n> vocabulary and that does take some time to learn, but I'd argue that\n> this is due to it's inherent flexibility than it is due to any inherent\n> flaws.\n> \n> [1] -- http://blogs.open.collab.net/svn/2008/07/subversion-merg.html\n\nWTF!?!\n\nWithout merge tracking (which at minimum means that commits which are\nresult of [true] merging contain information about which commits were\nmerged) you can't really display and reconstruct history. Without new\nsvn:mergeinfo one had to rely on third party extensions (SVK or svnmerge)\nor on information contained in commit message to get this info. It is\nvery good that at last Subversion 1.5 finally does include merge\ninformation.\n\nBut, if I understand correctly, and if information in mentioned blog\nis correct, then Subversion _fails_ to use this information fully.\nInstead of finding merge bases (see http://revctrl.org ... errr, it\nis now full of spam, and there is no easy way to revert to some older\nversion, so you would have to browse history), and doing 3-way merge[1],\nit requires of user to explicitly request automatical merge:\n\n $ svn merge --reintegrate url://feature-branch .\n\nand from the blog it looks like Subversion just generates patch and\napplies it. Or do I understand it incorrectly?\n\n[1] CVS did it, even Bram Cohen of Codeville agrees now[2] that 3-way\n merge is a correct way to go\n[2] http://bramcohen.livejournal.com/52148.html \n \"3. Use 3-way merge\"\n-- \nJakub Narebski\nPoland\n"},{"id":"83730","messageId":"alpine.DEB.1.00.0807171915420.8986@racer","threadId":"14486","inReplyTo":"20080717155538.GE11759@fieldses.org","subject":"Re: Considering teaching plumbing to users harmful","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-07-17T18:16:37Z","receivedAt":"2008-07-17T18:16:37Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 17 Jul 2008, J. Bruce Fields wrote:\n\n> On Wed, Jul 16, 2008 at 01:51:31PM -0700, Junio C Hamano wrote:\n> > Johannes Schindelin writes:\n> > \n> > > Am I the only one who deems teaching plumbing to users (\"I like it raw! \n> > > So I teach it the same way!\") harmful?\n> > \n> > I think that justification is harmful.\n> > \n> > More productive way to think about it is to identify cases where we _need_\n> > to go down to combination of the plumbing commands in our daily workflow,\n> > with today's command set. That would give us a good indication that some\n> > Porcelain may need to be enhanced.\n> \n> Is there a way to commit the contents of a tarball without using\n> plumbing? I occasionally want to track an upstream that I know only as\n> a series of tarballs, so I do something like:\n> \n> \tcd repo/\n> \tgit checkout upstream\n> \trm -rf *\n> \ttar -xzvf ../new-version.tar.gz\n\nHow about \"git add -u\" and \"git add .\"?\n\nCiao,\nDscho\n"},{"id":"83735","messageId":"7vtzeofjpi.fsf@gitster.siamese.dyndns.org","threadId":"14486","inReplyTo":"alpine.DEB.1.00.0807171915420.8986@racer","subject":"Re: Considering teaching plumbing to users harmful","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-07-17T18:29:13Z","receivedAt":"2008-07-17T18:29:13Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n>> Is there a way to commit the contents of a tarball without using\n>> plumbing? I occasionally want to track an upstream that I know only as\n>> a series of tarballs, so I do something like:\n>> \n>> \tcd repo/\n>> \tgit checkout upstream\n>> \trm -rf *\n>> \ttar -xzvf ../new-version.tar.gz\n>\n> How about \"git add -u\" and \"git add .\"?\n\nIt would work only if new version never removes files.\n"},{"id":"83737","messageId":"alpine.DEB.1.00.0807171940160.8986@racer","threadId":"14486","inReplyTo":"7vtzeofjpi.fsf@gitster.siamese.dyndns.org","subject":"Re: Considering teaching plumbing to users harmful","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-07-17T18:43:51Z","receivedAt":"2008-07-17T18:43:51Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 17 Jul 2008, Junio C Hamano wrote:\n\n> Johannes Schindelin writes:\n> \n> >> Is there a way to commit the contents of a tarball without using \n> >> plumbing? I occasionally want to track an upstream that I know only \n> >> as a series of tarballs, so I do something like:\n> >> \n> >> \tcd repo/\n> >> \tgit checkout upstream\n> >> \trm -rf *\n> >> \ttar -xzvf ../new-version.tar.gz\n> >\n> > How about \"git add -u\" and \"git add .\"?\n> \n> It would work only if new version never removes files.\n\nYou made me doubt for a second there. But \"git add -u\" updates the index \nwhen a tracked files was deleted. So after \"rm -rf *\", \"git add -u\" would \nempty the index.\n\nAFAICT this has been a part of \"git add -u\" ever since dfdac5d(git-add -u: \nmatch the index with working tree.), i.e. ever since the \"-u\" option was \nadded.\n\nCiao,\nDscho\n"},{"id":"83739","messageId":"alpine.LNX.1.00.0807171438430.19665@iabervon.org","threadId":"14486","inReplyTo":"861w1sn4id.fsf@lola.quinscape.zz","subject":"Re: Considering teaching plumbing to users harmful","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2008-07-17T19:00:28Z","receivedAt":"2008-07-17T19:00:28Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Thu, 17 Jul 2008, David Kastrup wrote:\n\n> Daniel Barkalow writes:\n> \n> > You're simply wrong. A ref isn't a name for a commit (the point of\n> > having a ref is that it doesn't persist in naming the same commit). A\n> > commit isn't a blob. If you start telling people complicated and wrong\n> > things, they're surely going to be confused.\n> >\n> > Git maintains history as a directed graph, with each commit pointing\n> > back at its history. Refs are the what holds the newest commits that\n> > nothing else points back to. If directed graphs aren't in your users'\n> > experience, you can put it this way: git maintains history like\n> > knitting, where each new stitch holds on to one or more previous\n> > stitches, and refs are the knitting needles that hold the ends where\n> > you're working (except that knitting is a lot wider than software\n> > development). gitk --all even provides the diagram you want to explain\n> > it.\n> \n> Complicated and right things are not much less confusing...\n> \n> > SVN branches are incredible confusing because they fail to distinguish\n> > the directory structure of the project's source tree from the\n> > arrangement of available latest versions.\n> \n> That is because there _is_ no difference. You just store different\n> versions in different places. What they are named is a convention,\n> nothing more, nothing less.\n\nNo, there's a difference. When you get a tarball of a project that uses \nSVN, the root of the tarball isn't the root of the repository. It's the \nroot of some directory within the repository. And if you ask for a tarball \nof some branch, it's from some different directory in the repository. \nProjects are not at all unaware that there are particular subdirectories \nin the repository structure which contain roots of versions, and above \nthat, the directory structure doesn't refer to the structure of a project \nsnapshot.\n\nBecause SVN lacks a vital concept (graph-structured history), it uses the \nsame implementation for two qualitatively different concepts. This is \nextremely confusing, and much more confusing than having a clean \nseparation between the two concepts like git does.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"83740","messageId":"7vmykgfhtj.fsf@gitster.siamese.dyndns.org","threadId":"14486","inReplyTo":"alpine.DEB.1.00.0807171940160.8986@racer","subject":"Re: Considering teaching plumbing to users harmful","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-07-17T19:10:00Z","receivedAt":"2008-07-17T19:10:00Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> On Thu, 17 Jul 2008, Junio C Hamano wrote:\n>\n>> Johannes Schindelin writes:\n>> \n>> >> Is there a way to commit the contents of a tarball without using \n>> >> plumbing? I occasionally want to track an upstream that I know only \n>> >> as a series of tarballs, so I do something like:\n>> >> \n>> >> \tcd repo/\n>> >> \tgit checkout upstream\n>> >> \trm -rf *\n>> >> \ttar -xzvf ../new-version.tar.gz\n>> >\n>> > How about \"git add -u\" and \"git add .\"?\n>> \n>> It would work only if new version never removes files.\n>\n> You made me doubt for a second there. But \"git add -u\" updates the index \n> when a tracked files was deleted. So after \"rm -rf *\", \"git add -u\" would \n> empty the index.\n\nI thought everybody would react to my message like so after sending it ;-)\nWhat I failed to say was that the main uneasiness about the above command\nsequence Bruce or anybody would have felt would be that \"rm -fr *\" step,\nwhich in itself look scary and does not remove .frotz that came from older\nversion.\n"},{"id":"83742","messageId":"m3k5fks2et.fsf@localhost.localdomain","threadId":"14486","inReplyTo":"86k5fk1ooq.fsf@lola.quinscape.zz","subject":"Re: Considering teaching plumbing to users harmful","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-07-17T20:04:32Z","receivedAt":"2008-07-17T20:04:32Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"[I'm sorry about turning this subthread into Subversion vs. Git rant]\n\nDavid Kastrup writes:\n> Jakub Narebski writes:\n>> David Kastrup writes:\n>>> Daniel Barkalow writes:\n\n>>>> SVN branches are incredible confusing because they fail to\n>>>> distinguish the directory structure of the project's source tree\n>>>> from the arrangement of available latest versions.\n>>> \n>>> That is because there _is_ no difference. You just store different\n>>> versions in different places. What they are named is a convention,\n>>> nothing more, nothing less.\n>>\n>> Branching by copying (!) and tagging by copying (!!!) is abuse\n>> of the fact that copying in Subversion is cheap.\n> \n> Uh, no. A lot of work has been invested into ensuring that copying in\n> Subversion in cheap _exactly_ because of the design decision to\n> implement branching and tagging via copying.\n> \n> It is not an accident that copying is cheap.\n\nI guess that idea of implementing cheap tree copying and idea of\nimplementing branches and tags as \"full-copies\" went hand in hand.\n\nMy feeling is that it looks like designing around implementation,\ninstead of implementing design.\n\nImplementing branches as copies, or in general as directory in\nfilesystem hierarchy is not that bad idea... provided that one\ncan flawlessly distinguish between branch and path in project,\ncan detect where branch name ends and in-project path begins\n(perhaps with project/module name in the middle).\n\nNeverheless designing around idea of graph of revisions is, IMVHO,\nmuch superior design :-)\n \n>> Distinguishing between branch part of directory name by _convention_\n>> is design mistake; the fact that the tool doesn't help to ensure that\n>> (a) tags lie on branch (b) tags _doesn't change_ is an example of this\n>> stupidity.\n> \n> How much have you worked with Subversion so far? I am doing quite a bit\n> of work with it, and the do-everything-via-copying paradigm does not get\n> in my hair. It actually means that I have to remember fewer commands.\n> And it is pretty easy to understand.\n\nIf you know what you are doing, and have good established workflow...\nI was talking there about possibility of mistake (either accident,\nor invalid workflow) of either having tag which is not on a branch,\nor changing the tag (treating it as branch).\n\nBranches and tags _are_ different. And should be, IMHO, treated\ndifferently (well, up to a point) by SCM.\n\n>>> Really, Subversion is rather simple to understand. But it is not a\n>>> DVCS. Moving a history from one repository to another is not really\n>>> feasible unless you are doing straight mirroring.\n>>\n>> Subversion is simple if you are limited to simple things; but the\n>> same is true with Git. I find for example the whole 'properties'\n>> mechanism and its use seriously not simple.\n> \n> Granted, particularly concerning the external property. OTOH, it makes\n> the equivalent of git submodules rather cheap (and I actually still have\n> no idea how git submodules properly work and what implications they\n> have).\n\nGit submodules are roughly equivalent to svn:externals with peg\nrevisions; I mean here that they refer not to some branch in some\nexternal repository, but to specific revision. This is the only sane\ndesign, as it assures that when checking out some historical revision,\nthe state that is checked out will be the same for everybody.\n\nPlease take into account however that submodules are quite new\nfeature, and while underlying engine is solid, interface (UI) needs\nsome polishing (and use cases).\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"83743","messageId":"38486DD8-B4D8-4AAC-9B5F-0A8035D894DD@sb.org","threadId":"14486","inReplyTo":"m3k5fks2et.fsf@localhost.localdomain","subject":"Re: Considering teaching plumbing to users harmful","fromName":"Kevin Ballard","fromEmail":"kevin@sb.org","sentAt":"2008-07-17T20:12:57Z","receivedAt":"2008-07-17T20:12:57Z","isPatch":false,"sender":{"key":"kevin@sb.org","avatar":"https://avatars.githubusercontent.com/u/714?v=4"},"body":"On Jul 17, 2008, at 1:04 PM, Jakub Narebski wrote:\n\n>> Granted, particularly concerning the external property. OTOH, it \n>> makes\n>> the equivalent of git submodules rather cheap (and I actually still \n>> have\n>> no idea how git submodules properly work and what implications they\n>> have).\n>\n> Git submodules are roughly equivalent to svn:externals with peg\n> revisions; I mean here that they refer not to some branch in some\n> external repository, but to specific revision. This is the only sane\n> design, as it assures that when checking out some historical revision,\n> the state that is checked out will be the same for everybody.\n>\n> Please take into account however that submodules are quite new\n> feature, and while underlying engine is solid, interface (UI) needs\n> some polishing (and use cases).\n\nThere is one facet of submodules that annoys me, because it prevents \nme from using them as a replacement for svn:externals. Namely, the \nsubmodule refers to a specific repository, but not a path within that \nrepository. I work with svn repos that use svn:externals to peg \nrevisions (as is appropriate) but they all refer to various paths \nwithin the other repositories, and the only way I can deal with that \nis to throw symlinks everywhere.\n\n-Kevin Ballard\n\n-- \nKevin Ballard\nhttp://kevin.sb.org\nkevin@sb.org\nhttp://www.tildesoft.com\n"},{"id":"83744","messageId":"6B9BBA72-6E75-47E3-911A-4A5309090807@sb.org","threadId":"14486","inReplyTo":"86k5fk1ooq.fsf@lola.quinscape.zz","subject":"Re: Considering teaching plumbing to users harmful","fromName":"Kevin Ballard","fromEmail":"kevin@sb.org","sentAt":"2008-07-17T20:15:01Z","receivedAt":"2008-07-17T20:15:01Z","isPatch":false,"sender":{"key":"kevin@sb.org","avatar":"https://avatars.githubusercontent.com/u/714?v=4"},"body":"On Jul 17, 2008, at 9:05 AM, David Kastrup wrote:\n\n>> Distinguishing between branch part of directory name by _convention_\n>> is design mistake; the fact that the tool doesn't help to ensure that\n>> (a) tags lie on branch (b) tags _doesn't change_ is an example of \n>> this\n>> stupidity.\n>\n> How much have you worked with Subversion so far? I am doing quite a \n> bit\n> of work with it, and the do-everything-via-copying paradigm does not \n> get\n> in my hair. It actually means that I have to remember fewer commands.\n> And it is pretty easy to understand.\n\nSure, it's simpler, but the overhead in creating and using a branch is \nmuch larger. I have to extract the URL from the repository (since \nnaturally I only have trunk checked out), issue a command to copy by \nURL, then issue an `svn switch` command, and then I have to remember \nthat I have a switched repository. Switching between branches is a \npain, especially if you have uncommitted work. There's a reason I \nnever bothered to use branches when I used subversion.\n\n-Kevin Ballard\n\n-- \nKevin Ballard\nhttp://kevin.sb.org\nkevin@sb.org\nhttp://www.tildesoft.com\n"},{"id":"83746","messageId":"20080717202609.GA32184@machine.or.cz","threadId":"14486","inReplyTo":"38486DD8-B4D8-4AAC-9B5F-0A8035D894DD@sb.org","subject":"Re: Considering teaching plumbing to users harmful","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2008-07-17T20:26:09Z","receivedAt":"2008-07-17T20:26:09Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Thu, Jul 17, 2008 at 01:12:57PM -0700, Kevin Ballard wrote:\n> There is one facet of submodules that annoys me, because it prevents me \n> from using them as a replacement for svn:externals. Namely, the submodule \n> refers to a specific repository, but not a path within that repository. I \n> work with svn repos that use svn:externals to peg revisions (as is \n> appropriate) but they all refer to various paths within the other \n> repositories, and the only way I can deal with that is to throw symlinks \n> everywhere.\n\nActually, is this a big problem? Git can track symlinks and without\nadding support for overall partial checkouts, adding this would feel\nlike too huge a hack to me.\n\nAlso, when converting to a different VCS, it might be sensible to adjust\nyour modules setup a bit as well - the requirement to include only\nparticular subdirectory of a submodule sounds rather strange to me.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nGNU, n. An animal of South Africa, which in its domesticated state\nresembles a horse, a buffalo and a stag. In its wild condition it is\nsomething like a thunderbolt, an earthquake and a cyclone. -- A. Pierce\n"},{"id":"83747","messageId":"200807172234.19146.jnareb@gmail.com","threadId":"14486","inReplyTo":"38486DD8-B4D8-4AAC-9B5F-0A8035D894DD@sb.org","subject":"Re: Considering teaching plumbing to users harmful","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-07-17T20:34:14Z","receivedAt":"2008-07-17T20:34:14Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Thu, 17 July 2008, Kevin Ballard wrote:\n> On Jul 17, 2008, at 1:04 PM, Jakub Narebski wrote:\n> \n>> Git submodules are roughly equivalent to svn:externals with peg\n>> revisions; I mean here that they refer not to some branch in some\n>> external repository, but to specific revision. This is the only sane\n>> design, as it assures that when checking out some historical revision,\n>> the state that is checked out will be the same for everybody.\n>>\n>> Please take into account however that submodules are quite new\n>> feature, and while underlying engine is solid, interface (UI) needs\n>> some polishing (and use cases).\n> \n> There is one facet of submodules that annoys me, because it prevents \n> me from using them as a replacement for svn:externals. Namely, the \n> submodule refers to a specific repository, but not a path within that \n> repository. I work with svn repos that use svn:externals to peg \n> revisions (as is appropriate) but they all refer to various paths \n> within the other repositories, and the only way I can deal with that \n> is to throw symlinks everywhere.\n\nI don't quite understand. At the lowest, \"gitlink\" level submodule\nentry is just having _commit_ object in place of directory. And of\ncourse this commit object refers to top tree (top directory) in\na subproject.\n\nIf you have subproject B with the following file structure\n\n B/foo\n B/bar/baz\n\nand you have (super)project A, which contains B as subproject at path\nsub-b, and has some files itself, the directory sytucture would look\nlike this:\n\n A/quux\n A/sub-b/foo\n A/sub-b/bar/baz\n\n\nWhat you want, I guess, is some a bit weird for me mixture of submodule\nand partial (subtree) checkout... and the latter is not implemented yet\n(I say \"yet\" because there was some preliminary implementation of\nsubtree checkout on git mailing list).\n-- \nJakub Narebski\nPoland\n"},{"id":"83748","messageId":"57BAA376-10A4-4E3F-BB8E-37B46E8C49D3@sb.org","threadId":"14486","inReplyTo":"20080717202609.GA32184@machine.or.cz","subject":"Re: Considering teaching plumbing to users harmful","fromName":"Kevin Ballard","fromEmail":"kevin@sb.org","sentAt":"2008-07-17T20:40:56Z","receivedAt":"2008-07-17T20:40:56Z","isPatch":false,"sender":{"key":"kevin@sb.org","avatar":"https://avatars.githubusercontent.com/u/714?v=4"},"body":"On Jul 17, 2008, at 1:26 PM, Petr Baudis wrote:\n\n> On Thu, Jul 17, 2008 at 01:12:57PM -0700, Kevin Ballard wrote:\n>> There is one facet of submodules that annoys me, because it \n>> prevents me\n>> from using them as a replacement for svn:externals. Namely, the \n>> submodule\n>> refers to a specific repository, but not a path within that \n>> repository. I\n>> work with svn repos that use svn:externals to peg revisions (as is\n>> appropriate) but they all refer to various paths within the other\n>> repositories, and the only way I can deal with that is to throw \n>> symlinks\n>> everywhere.\n>\n> Actually, is this a big problem? Git can track symlinks and without\n> adding support for overall partial checkouts, adding this would feel\n> like too huge a hack to me.\n>\n> Also, when converting to a different VCS, it might be sensible to \n> adjust\n> your modules setup a bit as well - the requirement to include only\n> particular subdirectory of a submodule sounds rather strange to me.\n\nThe problem is right now I maintain a bunch of git-svn mirrors of \ninternal svn repos, but the company isn't willing to switch to git. \nAnd we use subtree externals links to do things like pull in the \nmodels from one rails app into another, or pull in various \nsubdirectories of the \"support\" repository.\n\n-Kevin Ballard\n\n-- \nKevin Ballard\nhttp://kevin.sb.org\nkevin@sb.org\nhttp://www.tildesoft.com\n"},{"id":"83749","messageId":"D217A1F1-ED15-4380-9A2E-9EBB4478D95B@sb.org","threadId":"14486","inReplyTo":"200807172234.19146.jnareb@gmail.com","subject":"Re: Considering teaching plumbing to users harmful","fromName":"Kevin Ballard","fromEmail":"kevin@sb.org","sentAt":"2008-07-17T20:42:01Z","receivedAt":"2008-07-17T20:42:01Z","isPatch":false,"sender":{"key":"kevin@sb.org","avatar":"https://avatars.githubusercontent.com/u/714?v=4"},"body":"On Jul 17, 2008, at 1:34 PM, Jakub Narebski wrote:\n\n> On Thu, 17 July 2008, Kevin Ballard wrote:\n>> On Jul 17, 2008, at 1:04 PM, Jakub Narebski wrote:\n>>\n>>> Git submodules are roughly equivalent to svn:externals with peg\n>>> revisions; I mean here that they refer not to some branch in some\n>>> external repository, but to specific revision. This is the only \n>>> sane\n>>> design, as it assures that when checking out some historical \n>>> revision,\n>>> the state that is checked out will be the same for everybody.\n>>>\n>>> Please take into account however that submodules are quite new\n>>> feature, and while underlying engine is solid, interface (UI) needs\n>>> some polishing (and use cases).\n>>\n>> There is one facet of submodules that annoys me, because it prevents\n>> me from using them as a replacement for svn:externals. Namely, the\n>> submodule refers to a specific repository, but not a path within that\n>> repository. I work with svn repos that use svn:externals to peg\n>> revisions (as is appropriate) but they all refer to various paths\n>> within the other repositories, and the only way I can deal with that\n>> is to throw symlinks everywhere.\n>\n> I don't quite understand. At the lowest, \"gitlink\" level submodule\n> entry is just having _commit_ object in place of directory. And of\n> course this commit object refers to top tree (top directory) in\n> a subproject.\n>\n> If you have subproject B with the following file structure\n>\n> B/foo\n> B/bar/baz\n>\n> and you have (super)project A, which contains B as subproject at path\n> sub-b, and has some files itself, the directory sytucture would look\n> like this:\n>\n> A/quux\n> A/sub-b/foo\n> A/sub-b/bar/baz\n>\n>\n> What you want, I guess, is some a bit weird for me mixture of \n> submodule\n> and partial (subtree) checkout... and the latter is not implemented \n> yet\n> (I say \"yet\" because there was some preliminary implementation of\n> subtree checkout on git mailing list).\n\nIt seems you understand what I'm saying. The only way I can mimic it \nis to make the submodules actually live in some hidden directory .foo \nand then scatter symlinks everywhere.\n\n-Kevin Ballard\n\n-- \nKevin Ballard\nhttp://kevin.sb.org\nkevin@sb.org\nhttp://www.tildesoft.com\n"},{"id":"83763","messageId":"85wsjkgr7a.fsf@lola.goethe.zz","threadId":"14486","inReplyTo":"6B9BBA72-6E75-47E3-911A-4A5309090807@sb.org","subject":"Re: Considering teaching plumbing to users harmful","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2008-07-17T21:02:01Z","receivedAt":"2008-07-17T21:02:01Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Kevin Ballard writes:\n\n> On Jul 17, 2008, at 9:05 AM, David Kastrup wrote:\n>\n>> How much have you worked with Subversion so far? I am doing quite a\n>> bit of work with it, and the do-everything-via-copying paradigm does\n>> not get in my hair. It actually means that I have to remember fewer\n>> commands. And it is pretty easy to understand.\n>\n> Sure, it's simpler, but the overhead in creating and using a branch is\n> much larger. I have to extract the URL from the repository (since\n> naturally I only have trunk checked out),\n\nSay something like svn info and then use cut&paste.\n\n> issue a command to copy by URL, then issue an `svn switch` command,\n> and then I have to remember that I have a switched repository.\n\nHuh? How is that different to remembering a switched branch? Anyway,\none tends to check out different branches in different workdirs.\n\n> Switching between branches is a pain, especially if you have\n> uncommitted work. There's a reason I never bothered to use branches\n> when I used subversion.\n\nLooks like it.\n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"},{"id":"83757","messageId":"200807172303.19339.jnareb@gmail.com","threadId":"14486","inReplyTo":"57BAA376-10A4-4E3F-BB8E-37B46E8C49D3@sb.org","subject":"Re: Considering teaching plumbing to users harmful","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-07-17T21:03:18Z","receivedAt":"2008-07-17T21:03:18Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Dnia czwartek 17. lipca 2008 22:40, Kevin Ballard napisał:\n> On Jul 17, 2008, at 1:26 PM, Petr Baudis wrote:\n>> On Thu, Jul 17, 2008 at 01:12:57PM -0700, Kevin Ballard wrote:\n\n>>> There is one facet of submodules that annoys me, because it \n>>> prevents me from using them as a replacement for svn:externals.\n>>> Namely, the submodule refers to a specific repository, but not\n>>> a path within that repository. I work with svn repos that use\n>>> svn:externals to peg revisions (as is appropriate) but they all\n>>> refer to various paths within the other repositories, and the\n>>> only way I can deal with that is to throw symlinks everywhere.\n>>\n>> Actually, is this a big problem? Git can track symlinks and without\n>> adding support for overall partial checkouts, adding this would feel\n>> like too huge a hack to me.\n>>\n>> Also, when converting to a different VCS, it might be sensible to \n>> adjust\n>> your modules setup a bit as well - the requirement to include only\n>> particular subdirectory of a submodule sounds rather strange to me.\n> \n> The problem is right now I maintain a bunch of git-svn mirrors of \n> internal svn repos, but the company isn't willing to switch to git. \n> And we use subtree externals links to do things like pull in the \n> models from one rails app into another, or pull in various \n> subdirectories of the \"support\" repository.\n\nI think the correct solution would be to make 'models' separate \nrepository... or create interim repository containing only changes\nto 'models', and having 'models' as its top directory.\n\n-- \nJakub Narebski\nPoland\n"},{"id":"83762","messageId":"85sku8gr1q.fsf@lola.goethe.zz","threadId":"14486","inReplyTo":"63BEA5E623E09F4D92233FB12A9F79430238A16B@emailmn.mqsoftware.com","subject":"Re: Subversion's do-everything-via-copying paradigm ( was RE: Re: Considering teaching plumbing to users harmful)","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2008-07-17T21:05:21Z","receivedAt":"2008-07-17T21:05:21Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"\"Craig L. Ching\" writes:\n\n>> -----Original Message-----\n>> From: git-owner@vger.kernel.org \n>> [mailto:git-owner@vger.kernel.org] On Behalf Of David Kastrup\n>> Sent: Thursday, July 17, 2008 11:05 AM\n>> To: git@vger.kernel.org\n>> Subject: Re: Considering teaching plumbing to users harmful\n>> \n>> How much have you worked with Subversion so far? I am doing \n>> quite a bit of work with it, and the \n>> do-everything-via-copying paradigm does not get in my hair. \n>> It actually means that I have to remember fewer commands.\n>> And it is pretty easy to understand.\n>> \n>\n> Does it not bother you that renaming a file is a copy + delete [1].\n> Have they fixed that yet? That was one of the biggest reasons we never\n> moved to subversion.\n\nNever bit me.\n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"},{"id":"83758","messageId":"E2027B3B-CF7F-48C2-84C4-3A10131926E1@sb.org","threadId":"14486","inReplyTo":"200807172303.19339.jnareb@gmail.com","subject":"Re: Considering teaching plumbing to users harmful","fromName":"Kevin Ballard","fromEmail":"kevin@sb.org","sentAt":"2008-07-17T21:10:11Z","receivedAt":"2008-07-17T21:10:11Z","isPatch":false,"sender":{"key":"kevin@sb.org","avatar":"https://avatars.githubusercontent.com/u/714?v=4"},"body":"On Jul 17, 2008, at 2:03 PM, Jakub Narebski wrote:\n\n> Dnia czwartek 17. lipca 2008 22:40, Kevin Ballard napisał:\n>> On Jul 17, 2008, at 1:26 PM, Petr Baudis wrote:\n>>> On Thu, Jul 17, 2008 at 01:12:57PM -0700, Kevin Ballard wrote:\n>\n>>>> There is one facet of submodules that annoys me, because it\n>>>> prevents me from using them as a replacement for svn:externals.\n>>>> Namely, the submodule refers to a specific repository, but not\n>>>> a path within that repository. I work with svn repos that use\n>>>> svn:externals to peg revisions (as is appropriate) but they all\n>>>> refer to various paths within the other repositories, and the\n>>>> only way I can deal with that is to throw symlinks everywhere.\n>>>\n>>> Actually, is this a big problem? Git can track symlinks and without\n>>> adding support for overall partial checkouts, adding this would feel\n>>> like too huge a hack to me.\n>>>\n>>> Also, when converting to a different VCS, it might be sensible to\n>>> adjust\n>>> your modules setup a bit as well - the requirement to include only\n>>> particular subdirectory of a submodule sounds rather strange to me.\n>>\n>> The problem is right now I maintain a bunch of git-svn mirrors of\n>> internal svn repos, but the company isn't willing to switch to git.\n>> And we use subtree externals links to do things like pull in the\n>> models from one rails app into another, or pull in various\n>> subdirectories of the \"support\" repository.\n>\n> I think the correct solution would be to make 'models' separate\n> repository... or create interim repository containing only changes\n> to 'models', and having 'models' as its top directory.\n\nThat would require significantly more work to deal with than using \nsymlinks like I described, since the company is not willing to adjust \nanything to help with my git usage (as I'm the only git user here).\n\n-Kevin Ballard\n\n-- \nKevin Ballard\nhttp://kevin.sb.org\nkevin@sb.org\nhttp://www.tildesoft.com\n"},{"id":"83765","messageId":"63BEA5E623E09F4D92233FB12A9F79430238A1B4@emailmn.mqsoftware.com","threadId":"14486","inReplyTo":"85sku8gr1q.fsf@lola.goethe.zz","subject":"RE: Subversion's do-everything-via-copying paradigm ( was RE: Re: Considering teaching plumbing to users harmful)","fromName":"Craig L. Ching","fromEmail":"cching@mqsoftware.com","sentAt":"2008-07-17T22:06:10Z","receivedAt":"2008-07-17T22:06:10Z","isPatch":false,"sender":{"key":"cching@mqsoftware.com","avatar":null},"body":" \n\n> -----Original Message-----\n> From: David Kastrup [mailto:dak@gnu.org] \n> Sent: Thursday, July 17, 2008 4:05 PM\n> To: Craig L. Ching\n> Cc: git@vger.kernel.org\n> Subject: Re: Subversion's do-everything-via-copying paradigm \n> ( was RE: Re: Considering teaching plumbing to users harmful)\n> \n> \"Craig L. Ching\" writes:\n> \n> > Does it not bother you that renaming a file is a copy + delete [1].\n> > Have they fixed that yet? That was one of the biggest \n> reasons we never\n> > moved to subversion.\n> \n> Never bit me.\n> \nIgnorance is bliss as they say ;-)\n\n> -- \n> David Kastrup, Kriemhildstr. 15, 44793 Bochum\n> \n\nCheers,\nCraig\n"},{"id":"83766","messageId":"32541b130807171507j98f883by2e937e894838852@mail.gmail.com","threadId":"14486","inReplyTo":"63BEA5E623E09F4D92233FB12A9F79430238A16B@emailmn.mqsoftware.com","subject":"Re: Subversion's do-everything-via-copying paradigm ( was RE: Re: Considering teaching plumbing to users harmful)","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2008-07-17T22:07:36Z","receivedAt":"2008-07-17T22:07:36Z","isPatch":false,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On 7/17/08, Craig L. Ching wrote:\n> Does it not bother you that renaming a file is a copy + delete [1].\n> Have they fixed that yet? That was one of the biggest reasons we never\n> moved to subversion.\n\nPerhaps you've confused CVS with subversion.\n\nsvn's handilng of renames is not as graceful as git's, but it does\nwork in the common cases. For example, after the aforementioned\ncopy+delete, \"svn blame\" and \"svn log\" will still follow history back\nthrough the rename.\n\nNot sure how I ended up defending subversion on this list. Somehow\nI've been tricked into being on the losing side of this argument :) I\nguess I just wanted to balance the viewpoints a little; there are good\nthings to be learned from svn, but not things about branching,\nmerging, or rename tracking.\n\nHave fun,\n\nAvery\n"},{"id":"83767","messageId":"7vzlogduuo.fsf@gitster.siamese.dyndns.org","threadId":"14486","inReplyTo":"32541b130807171507j98f883by2e937e894838852@mail.gmail.com","subject":"Re: Subversion's do-everything-via-copying paradigm ( was RE: Re: Considering teaching plumbing to users harmful)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-07-17T22:11:27Z","receivedAt":"2008-07-17T22:11:27Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Could you please take this elsewhere? Now it is about subversion and not\nabout git anymore...\n"},{"id":"83771","messageId":"200807180032.53642.robin.rosenberg.lists@dewire.com","threadId":"14486","inReplyTo":"85wsjkgr7a.fsf@lola.goethe.zz","subject":"Re: Considering teaching plumbing to users harmful","fromName":"Robin Rosenberg","fromEmail":"robin.rosenberg.lists@dewire.com","sentAt":"2008-07-17T22:32:53Z","receivedAt":"2008-07-17T22:32:53Z","isPatch":false,"sender":{"key":"robin.rosenberg@dewire.com","avatar":"https://avatars.githubusercontent.com/u/46357?v=4"},"body":"torsdagen den 17 juli 2008 23.02.01 skrev David Kastrup:\n> Kevin Ballard writes:\n> \n> > On Jul 17, 2008, at 9:05 AM, David Kastrup wrote:\n[...]\n> > issue a command to copy by URL, then issue an `svn switch` command,\n> > and then I have to remember that I have a switched repository.\n> \n> Huh? How is that different to remembering a switched branch? Anyway,\nThat's what we have the custom prompt in contrib for. Like this.\n[me@mymachine EGIT (rr/gitselectionprovider)]$\n\nObviously it's not mandatory, but I recommend it as it also show stuff like\nrebase, am, merge and bisect status too.\n\nMaybe one you do that for SVN too. I have one for CVS.\n\n> one tends to check out different branches in different workdirs.\nThis is very different for individuals. \n\n-- robin\n"},{"id":"83839","messageId":"20080718074111.GL2925@dpotapov.dyndns.org","threadId":"14486","inReplyTo":"86k5fk1ooq.fsf@lola.quinscape.zz","subject":"Re: Considering teaching plumbing to users harmful","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2008-07-18T07:41:11Z","receivedAt":"2008-07-18T07:41:11Z","isPatch":false,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"On Thu, Jul 17, 2008 at 06:05:25PM +0200, David Kastrup wrote:\n> Jakub Narebski writes:\n> \n> > Distinguishing between branch part of directory name by _convention_\n> > is design mistake; the fact that the tool doesn't help to ensure that\n> > (a) tags lie on branch (b) tags _doesn't change_ is an example of this\n> > stupidity.\n> \n> How much have you worked with Subversion so far? I am doing quite a bit\n> of work with it, and the do-everything-via-copying paradigm does not get\n> in my hair. It actually means that I have to remember fewer commands.\n> And it is pretty easy to understand.\n\nStaying on trunk, try to compare your files foo and bar with version\n1.0. With Git, it is simple\ngit v1.0 -- foo bar\nbut I don't think you can do that so easily with SVN.\n\nBut the real problem with the do-everything-via-copying paradigm is\nthat now revisions do not identify anything meaningful without some\npath. This leads to problems if you try to implement merge. In Git,\nit is simple -- merge is a commit with more than one parent. You cannot\ndo like that in SVN. Instead, you have to track merges per file. This\nis not just waste of resources, but this merges is very difficult if\nnot impossible to visulize in any useful way. But if you cannot see\nsomething, you cannot control it well. So, not accidently, in systems\nwith inter-file branching, creating feature branches is discouraged.\n\nBesides having fewer commands doesn't necessary mean easier to learn\nor to use. If you have one command that conflates different concepts,\nit is usually more difficult than having a devote command per concept.\n\nCan you remove the concept of branches and merges and have your VCS\nstill useful? Well, you can say \"we don't use branches, every developer\ncommits directly on trunk\". The consequence of that choice is that a lot\nof work-in-progress code is pushed to trunk. But no one has the perfect\nforesight. Some ideas will turn out to be not so good. Some developers\nwill not finish their work and will be reassigned to more urgent tasks.\nAs result, just as release time approaches, you have a lot of unfinished\ncrap in your trunk. Of course, if you don't care about quality of your\nsoftware, it may be easier for you to work in this way.\n\nHowever, if you do care about quality, you have to use feature branches\nfor WIP, and for this workflow to work, you need that merging is really\neasy. Git makes that for you, yet you may need to learn new concepts --\nbranching and merging. Thus comparision of what is easier or difficult\nis meaningless without defining goals. It is always easy to be sloppy\nand don't care...\n\nDmitry\n"},{"id":"83844","messageId":"48805207.80504@op5.se","threadId":"14486","inReplyTo":"alpine.DEB.1.00.0807161804400.8950@racer","subject":"Re: Considering teaching plumbing to users harmful","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2008-07-18T08:19:19Z","receivedAt":"2008-07-18T08:19:19Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Johannes Schindelin wrote:\n> Hi,\n> \n> there have been a number of occasions where I came across people trying to \n> be helpful and teaching Git newbies a few tricks.\n> \n> However, in quite a number of cases, which seem to surge over the last \n> weeks, I see people suggesting the use of rev-parse, ls-tree, rev-list \n> etc.\n> \n> Their rationale is invariably \"but I found it useful\", and they seem to be \n> unable to recognize the puzzlement in the faces of the people they are \n> trying to help.\n> \n> Instead they insist that they did nothing wrong.\n> \n> I had the pleasure of introducing Git to a few users in the last months \n> and in my opinion, restricting myself to teaching them these commands \n> first helped tremendously:\n> \n> - clone, pull, status, add, commit, push, log\n> \n> All of these were presented without options, to keep things simple.\n> \n> In particular, I refrained from giving them the \"-a\" option to commit. \n> That seemed to help incredibly with their embracing the index as a natural \n> concept (which it is).\n> \n> Often I presented the \"pull\" and \"push\" commands _only_ with \"origin \n> master\" (\"origin is where the repository came from, and master is the \n> branch; you will want to use other parameters here after you used Git for \n> a while\").\n> \n> _After_ they grew comfortable with Git, I taught them a few options here \n> and there, not hiding, but also not promoting the full range of options.\n> \n> So the next tricks were\n> \n> - log -p, rm, diff, diff --cached, show\n> \n> The last one is \"show\", and with that command, I taught the \n> \":\" and \":\" syntax, too (which some Git old-timers \n> did not know about ;-)\n> \n\nThanks for the excellent write-up. I wish I'd had this when I did the\nintroductory courses at my dayjob. With those simple commands, 90%\nof the users get access to 90% of the usefulness of git, imo. And,\nmore importantly, it's enough to get them started right away.\n\n\n> The pace needed to be adjusted to the users, in my experience, but not the \n> order.\n> \n> Now, it makes me really, really sad that Git has a reputation of being \n> complicated, but I regularly hear from _my_ users that they do not \n> understand how that came about.\n> \n> Am I the only one who deems teaching plumbing to users (\"I like it raw! \n> So I teach it the same way!\") harmful?\n> \n\nI wholeheartedly agree. Telling people about \"git rev-list\" on day one\nis probably the single greatest mistake I've ever done wrt git. To the\nnon-gitizen, it takes some mumbo-jumbo arguments and spits out a long\nlist of mumbo-jumbo output. Had I started with \"git log\" instead, it\nwould have been infinitely easier to explain how each commit has a\ntotally unique name.\n\nIn addition, I'd recommend setting\ncolor.branch=auto\ncolor.diff=auto\ncolor.pager=true\ncolor.status=true\nbefore starting the \"course\". It makes the learning experience a whole\nlot nicer.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"83859","messageId":"48806897.1080404@fastmail.fm","threadId":"14486","inReplyTo":"alpine.DEB.1.00.0807171940160.8986@racer","subject":"Addremove equivalent [was: Re: Considering teaching plumbing to users harmful]","fromName":"Michael J Gruber","fromEmail":"michaeljgruber+gmane@fastmail.fm","sentAt":"2008-07-18T09:55:35Z","receivedAt":"2008-07-18T09:55:35Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Johannes Schindelin venit, vidit, dixit 17.07.2008 20:43:\n> Hi,\n> \n> On Thu, 17 Jul 2008, Junio C Hamano wrote:\n> \n>> Johannes Schindelin writes:\n>>\n>>>> Is there a way to commit the contents of a tarball without using \n>>>> plumbing? I occasionally want to track an upstream that I know only \n>>>> as a series of tarballs, so I do something like:\n>>>>\n>>>> \tcd repo/\n>>>> \tgit checkout upstream\n>>>> \trm -rf *\n>>>> \ttar -xzvf ../new-version.tar.gz\n>>> How about \"git add -u\" and \"git add .\"?\n>> It would work only if new version never removes files.\n> \n> You made me doubt for a second there. But \"git add -u\" updates the index \n> when a tracked files was deleted. So after \"rm -rf *\", \"git add -u\" would \n> empty the index.\n\nThis brings me to a question I never dared to ask so far. In fact, I'm \nhappy with git-add and using the index explicitly rather than \nimplicitly. Still, sometimes I find my self wanting an \"addremove\", such \nas in a situation like above. (E.g., tracking a dir which is synced by \ndifferent means.)\n\nSay I have a modified file a, removed file b (rm'ed, not git-rm'ed) and \na new file c. Then:\n\ngit add . would add the changes to a and c\ngit add -u would add the changes to a and (the removal of) b\ngit commit -a would commit the changes to a and b (it does add -u + commit)\n\nSo, if I want to add and commit all three kinds of changes using \nporcelaine I have to do:\n\ngit add .\ngit commit -a\n\nor\ngit add .\ngit add -u\ngit commit\n\nAFAICT this means that git will scan for modifications to tracked files \nwhich still exist twice. While this will be noticeable only with large \ndirs on slow FS it's conceptually not so nice. Is there any (porc.) way \naround? I don't know the internals, though; maybe there's no second scan \n(stat...).\n\nCheers\nMichael\n"},{"id":"83862","messageId":"48806D03.30603@fastmail.fm","threadId":"14486","inReplyTo":"alpine.DEB.1.00.0807161804400.8950@racer","subject":"Suggestion: doc restructuring [was: Re: Considering teaching plumbing to users harmful]","fromName":"Michael J Gruber","fromEmail":"michaeljgruber+gmane@fastmail.fm","sentAt":"2008-07-18T10:14:27Z","receivedAt":"2008-07-18T10:14:27Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Johannes Schindelin venit, vidit, dixit 16.07.2008 19:21:\n...\n> \n> Am I the only one who deems teaching plumbing to users (\"I like it raw! \n> So I teach it the same way!\") harmful?\n> \n> Ciao,\n> Dscho \"who is sad\"\n\nIn an attempt at making not only Dscho happier I suggest a restructuring \nof the man pages in the following way:\n\nIn each man page, put a note which says something like:\n\"This is part of linkgit:gitplumbing[7].\" and the like\nIt should be in a prominent place, such as the last line of \"DESCRIPTION\".\n\ngitplumbing[7] etc. pages should contain:\n- a definition of the respective term together with appropriate usage \nadvice (regular use/scripting..., \"Let there be dragons.\")\n- a list of commands like we have in git[1] right now\n\nWith the current situation, people don't look at git[1] in order to find \nout what they're supposed to use. It's too long anyways, and could link \nthe above pages instead.\n\nIf there's enough interest/agreement I'd come up with a refactoring patch.\n\nMichael\n\n\nP.S.: For me\nporcellaine = artistic, fragile\nplumbing = plain, robust\nWhich one would you choose for daily hard work? ;)\n"},{"id":"83881","messageId":"20080718143524.GD5288@fieldses.org","threadId":"14486","inReplyTo":"7vmykgfhtj.fsf@gitster.siamese.dyndns.org","subject":"Re: Considering teaching plumbing to users harmful","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2008-07-18T14:35:24Z","receivedAt":"2008-07-18T14:35:24Z","isPatch":false,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"On Thu, Jul 17, 2008 at 12:10:00PM -0700, Junio C Hamano wrote:\n> Johannes Schindelin writes:\n> \n> > On Thu, 17 Jul 2008, Junio C Hamano wrote:\n> >\n> >> Johannes Schindelin writes:\n> >> \n> >> >> Is there a way to commit the contents of a tarball without using \n> >> >> plumbing? I occasionally want to track an upstream that I know only \n> >> >> as a series of tarballs, so I do something like:\n> >> >> \n> >> >> \tcd repo/\n> >> >> \tgit checkout upstream\n> >> >> \trm -rf *\n> >> >> \ttar -xzvf ../new-version.tar.gz\n> >> >\n> >> > How about \"git add -u\" and \"git add .\"?\n> >> \n> >> It would work only if new version never removes files.\n> >\n> > You made me doubt for a second there. But \"git add -u\" updates the index \n> > when a tracked files was deleted. So after \"rm -rf *\", \"git add -u\" would \n> > empty the index.\n> \n> I thought everybody would react to my message like so after sending it ;-)\n> What I failed to say was that the main uneasiness about the above command\n> sequence Bruce or anybody would have felt would be that \"rm -fr *\" step,\n> which in itself look scary and does not remove .frotz that came from older\n> version.\n\nYeah, good point, that's not very careful.\n\nBut actually it's \"add -u\" that I missed--I forgot it would take into\naccount removed files as well. Thanks!\n\n--b.\n"},{"id":"83891","messageId":"46dff0320807181002i33320669ica5e407adc30d8b6@mail.gmail.com","threadId":"14486","inReplyTo":"7vr69tpoze.fsf@gitster.siamese.dyndns.org","subject":"Re: Considering teaching plumbing to users harmful","fromName":"Ping Yin","fromEmail":"pkufranky@gmail.com","sentAt":"2008-07-18T17:02:35Z","receivedAt":"2008-07-18T17:02:35Z","isPatch":false,"sender":{"key":"pkufranky@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5346?v=4"},"body":"On Thu, Jul 17, 2008 at 4:12 AM, Junio C Hamano wrote:\n\n> Suppose you are about to finish something you have been cooking (say a\n> series of five logical commits), you've made three of these commits\n> already, and what you have in your work tree and the index is to be split\n> into the last two commits. Somehow you learn that $x above has a updated\n> version.\n>\n> Yes, running \"git stash && git pull --rebase && git stash pop\" would be\n> better than running \"git pull --rebase\" alone from that state. But that\n> would mean your history would have your first 3 commits (of 5 commit\n> series), somebody else's totally unrelated commits, and then you will work\n> on finishing the remaining 2 commits on top of it.\n\nHmm, the first 3 commits are not pushed out, right? So by \"rebase\",\nthe history should be first the somebody else's commits\n(origin/master), then the first 3 commits, then the remaining 2\ncommits?:\n\n\n-- \nPing Yin\n"},{"id":"83906","messageId":"4880E041.8070001@freescale.com","threadId":"14486","inReplyTo":"48806D03.30603@fastmail.fm","subject":"Re: Suggestion: doc restructuring [was: Re: Considering teaching plumbing to users harmful]","fromName":"Jon Loeliger","fromEmail":"jdl@freescale.com","sentAt":"2008-07-18T18:26:09Z","receivedAt":"2008-07-18T18:26:09Z","isPatch":false,"sender":{"key":"jdl@jdl.com","avatar":"https://gravatar.com/avatar/75ce9a10b151acd2c28ec4ab2136dba7b2ff1634530bd04b155981a749d08a64?d=mp&s=160"},"body":"Michael J Gruber wrote:\n> Johannes Schindelin venit, vidit, dixit 16.07.2008 19:21:\n> ...\n>>\n>> Am I the only one who deems teaching plumbing to users (\"I like it \n>> raw! So I teach it the same way!\") harmful?\n>>\n>> Ciao,\n>> Dscho \"who is sad\"\n> \n> In an attempt at making not only Dscho happier I suggest a restructuring \n> of the man pages in the following way:\n> \n> In each man page, put a note which says something like:\n> \"This is part of linkgit:gitplumbing[7].\" and the like\n> It should be in a prominent place, such as the last line of \"DESCRIPTION\".\n> \n> gitplumbing[7] etc. pages should contain:\n> - a definition of the respective term together with appropriate usage \n> advice (regular use/scripting..., \"Let there be dragons.\")\n> - a list of commands like we have in git[1] right now\n> \n> With the current situation, people don't look at git[1] in order to find \n> out what they're supposed to use. It's too long anyways, and could link \n> the above pages instead.\n> \n> If there's enough interest/agreement I'd come up with a refactoring patch.\n> \n> Michael\n\nI'd like to throw my beef with the main Git man page\nout there for consideration as well...\n\nWhen I hit the man page, which I do on line quite frequently,\nI usually use it as an index to get to the real, current man\npage for a particular command. (I am at git.kernel.org for\nother reasons all the time, so it is convenient.)\n\nThe current sub-setting and organization is painful because\nit doesn't have a comprehensive, linear, alphabetized list\nof commands from which to select the real man page. I never\nknow which \"section\" to find a given command. Is it an\nAncillary \"manipulator\" command? Or maybe just a \"Manipulation\"\ncommand, or maybe an \"Interrogation\" command? A \"Helper\"?\n\nI always have to painfully search the page for it instead.\n\nI'm not saying get rid of the Categorical organization.\nI am saying, we need a first-page with a straight, alphabetized\ncommand index somewhere easy and located conveniently.\n\nThanks for listening,\njdl\n"},{"id":"83904","messageId":"20080718182615.GA9035@sigill.intra.peff.net","threadId":"14486","inReplyTo":"48805207.80504@op5.se","subject":"Re: Considering teaching plumbing to users harmful","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-07-18T18:26:16Z","receivedAt":"2008-07-18T18:26:16Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Jul 18, 2008 at 10:19:19AM +0200, Andreas Ericsson wrote:\n\n> In addition, I'd recommend setting\n> color.branch=auto\n> color.diff=auto\n> color.pager=true\n> color.status=true\n> before starting the \"course\". It makes the learning experience a whole\n> lot nicer.\n\nYou might be interested in the \"color.ui\" config option.\n\n-Peff\n"},{"id":"83908","messageId":"63BEA5E623E09F4D92233FB12A9F79430238A204@emailmn.mqsoftware.com","threadId":"14486","inReplyTo":"4880E041.8070001@freescale.com","subject":"RE: Suggestion: doc restructuring [was: Re: Considering teaching plumbing to users harmful]","fromName":"Craig L. Ching","fromEmail":"cching@mqsoftware.com","sentAt":"2008-07-18T18:52:56Z","receivedAt":"2008-07-18T18:52:56Z","isPatch":false,"sender":{"key":"cching@mqsoftware.com","avatar":null},"body":"> -----Original Message-----\n> From: git-owner@vger.kernel.org \n> [mailto:git-owner@vger.kernel.org] On Behalf Of Jon Loeliger\n> Sent: Friday, July 18, 2008 1:26 PM\n> To: Michael J Gruber\n> Cc: git@vger.kernel.org\n> Subject: Re: Suggestion: doc restructuring [was: Re: \n> Considering teaching plumbing to users harmful]\n> \n> I always have to painfully search the page for it instead.\n> \nI don't want to complain too loudly because I don't think I have any\ngood solutions, maybe yours is a good one, having an alphabetized list\nof commands. What I wanted to second, though, was that I too use the\nbrowser search for all of the Git pages and that indicates that\n*something* isn't optimal.\n\nOne easy thing I could suggest, and I'd be willing to try submitting\nsome patches if people agreed it's a valuable change (at least that's\nsomething I think I could handle contributing for now ;-) ) is that when\nyou hit the \"Documentation\" link off the main page, instead of going\nstraight to the Man page, maybe it should go to a page that clearly has\nthe options that people are looking for. E.g. a link to the tutorial, a\nlink to the man page, a link to the Git User's manual, a link to the\nFAQ, a link to the \"Git for SVN Users\" page, etc. The way it is now,\nonce you're used to the html rendered man page, it's not hard, but I do\nthink it's not the most newbie friendly way to navigate the\ndocumentation atm. Or maybe just feature those links more prominently\nat the top of the man page so they're dead easy to spot. Just my $0.02.\nIf someone definitively says what should be done, I'd be willing to give\nit a shot.\n\n> I'm not saying get rid of the Categorical organization.\n> I am saying, we need a first-page with a straight, \n> alphabetized command index somewhere easy and located conveniently.\n> \n> Thanks for listening,\n> jdl\n> --\n> To unsubscribe from this list: send the line \"unsubscribe \n> git\" in the body of a message to majordomo@vger.kernel.org \n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n> \n\nCheers,\nCraig\n"},{"id":"83911","messageId":"7v3am76kg7.fsf@gitster.siamese.dyndns.org","threadId":"14486","inReplyTo":"4880E041.8070001@freescale.com","subject":"Re: Suggestion: doc restructuring","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-07-18T19:50:16Z","receivedAt":"2008-07-18T19:50:16Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jon Loeliger writes:\n\n> The current sub-setting and organization is painful because\n> it doesn't have a comprehensive, linear, alphabetized list\n> of commands from which to select the real man page. I never\n> know which \"section\" to find a given command. Is it an\n> Ancillary \"manipulator\" command? Or maybe just a \"Manipulation\"\n> command, or maybe an \"Interrogation\" command? A \"Helper\"?\n>\n> I always have to painfully search the page for it instead.\n\nWhen you are on-line (like your case to read kernel.org webpage), it is\nrather easy with ^F (or whatever browser you use lets you search).\n\nBut I do agree with you that on printed medium we would want a nice\nalphabetized list somewhere.\n"},{"id":"83912","messageId":"76718490807181318o228171f9j836aaca2edb9b377@mail.gmail.com","threadId":"14486","inReplyTo":"48806897.1080404@fastmail.fm","subject":"Re: Addremove equivalent [was: Re: Considering teaching plumbing to users harmful]","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2008-07-18T20:18:41Z","receivedAt":"2008-07-18T20:18:41Z","isPatch":false,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"On Fri, Jul 18, 2008 at 5:55 AM, Michael J Gruber\n wrote:\n> sometimes I find my self wanting an \"addremove\", such as in a situation like\n\nI have the following aliased as \"addremove\":\n\n git ls-files -d -m -o -z --exclude-standard \\\n | xargs -0 git update-index --add --remove\n\nhttp://www-cs-students.stanford.edu/~blynn/gitmagic/ch05.html\n\nj.\n"},{"id":"83921","messageId":"alpine.DEB.1.00.0807190102390.3064@eeepc-johanness","threadId":"14486","inReplyTo":"76718490807181318o228171f9j836aaca2edb9b377@mail.gmail.com","subject":"Re: Addremove equivalent [was: Re: Considering teaching plumbing to users harmful]","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-07-18T23:03:22Z","receivedAt":"2008-07-18T23:03:22Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 18 Jul 2008, Jay Soffian wrote:\n\n> On Fri, Jul 18, 2008 at 5:55 AM, Michael J Gruber\n> wrote:\n> > sometimes I find my self wanting an \"addremove\", such as in a situation like\n> \n> I have the following aliased as \"addremove\":\n> \n> git ls-files -d -m -o -z --exclude-standard \\\n> | xargs -0 git update-index --add --remove\n\nBut that is everything, _except_ easy for newbies!!!\n\nI still suggest \"git add -u && git add .\".\n\nHth,\nDscho\n"},{"id":"83930","messageId":"alpine.DEB.1.00.0807190314010.3064@eeepc-johanness","threadId":"14486","inReplyTo":"48806D03.30603@fastmail.fm","subject":"Re: Suggestion: doc restructuring [was: Re: Considering teaching plumbing to users harmful]","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-07-19T01:19:25Z","receivedAt":"2008-07-19T01:19:25Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 18 Jul 2008, Michael J Gruber wrote:\n\n> Johannes Schindelin venit, vidit, dixit 16.07.2008 19:21:\n> ...\n> > \n> > Am I the only one who deems teaching plumbing to users (\"I like it \n> > raw! So I teach it the same way!\") harmful?\n> \n> In an attempt at making not only Dscho happier I suggest a restructuring \n> of the man pages in the following way:\n> \n> In each man page, put a note which says something like: \"This is part of \n> linkgit:gitplumbing[7].\" and the like It should be in a prominent place, \n> such as the last line of \"DESCRIPTION\".\n\nActually, I do not particularly like that direction.\n\nRecently, somebody taught me that it makes sense, from the psychological \nview, to stress positive points, and avoid negative terms.\n\nFor example, \"do not use this\" -- even if followed by \"use that instead\" \n-- is suboptimal. People will be more stressed, have a shorter attention \nspan, and in general recall much less, if you use negative terms.\n\nSo what I really would like is this: leave the plumbing pages as they are, \nbut enhance those pages that users (especially new ones) are likely to see \nmost often.\n\nBy \"enhancing\" I mean to illustrate the principles and commands more in \nterm of a select _few_ commands. And they should describe the options \nthemselves, instead of referring to plumbing man pages.\n\nMaybe I'll find some time this weekend to write up a bit more of my \ntutorials, which I would then post so people see what I mean should be \ntaught to n00bs first.\n\nCiao,\nDscho\n"},{"id":"83989","messageId":"7vsku5grpr.fsf@gitster.siamese.dyndns.org","threadId":"14486","inReplyTo":"76718490807181318o228171f9j836aaca2edb9b377@mail.gmail.com","subject":"Re: Addremove equivalent","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-07-20T03:27:44Z","receivedAt":"2008-07-20T03:27:44Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Jay Soffian\" writes:\n\n> On Fri, Jul 18, 2008 at 5:55 AM, Michael J Gruber\n> wrote:\n>> sometimes I find my self wanting an \"addremove\", such as in a situation like\n>\n> I have the following aliased as \"addremove\":\n>\n> git ls-files -d -m -o -z --exclude-standard \\\n> | xargs -0 git update-index --add --remove\n\nI'll send out two patches on this topic.\n\nJunio C Hamano (2):\n builtin-add.c: restructure the code for maintainability\n git-add -a: add all files\n"},{"id":"83990","messageId":"7vod4tgrns.fsf_-_@gitster.siamese.dyndns.org","threadId":"14486","inReplyTo":"7vsku5grpr.fsf@gitster.siamese.dyndns.org","subject":"[PATCH 1/2] builtin-add.c: restructure the code for maintainability","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-07-20T03:28:55Z","receivedAt":"2008-07-20T03:28:55Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"The implementation of \"git add\" has four major codepaths that are mutually\nexclusive:\n\n - if \"--interactive\" or \"--patch\" mode, spawn \"git add--interactive\" and\n exit without doing anything else. Otherwise things are handled\n internally in this C code.\n\n - if \"--update\", update the modified files and exit without doing\n anything else;\n\n - if \"--refresh\", do refresh and exit without doing anything else;\n\n - otherwise, find the paths that match pathspecs and stage their\n contents.\n\nand it led to an unholy mess in the code structure; each of the latter\nthree codepaths has separate call to read_cache() even though they are all\n\"read the current index, update it and write it back\" so logically they\nshould read the index once _anyway_.\n\nThis cleans up the latter three cases by introducing a handful helper\nvariables:\n\n - \"add_new_files\" is set if we need to scan the working tree for paths\n that match the pathspec. This variable is false for \"--update\" and\n \"--refresh\", because they only work on already tracked files.\n\n - \"require_pathspec\" is set if the user must give at least one pathspec.\n \"--update\" does not need it but all the other cases do.\n\nThis is in preparation for introducing a new option \"-a\" that does the\nequivalent of \"git add -u && git add .\" (aka \"addremove\").\n\nSigned-off-by: Junio C Hamano \n---\n builtin-add.c | 75 ++++++++++++++++++++++++++++++++------------------------\n 1 files changed, 43 insertions(+), 32 deletions(-)\n\ndiff --git a/builtin-add.c b/builtin-add.c\nindex bf13aa3..9b2ee8c 100644\n--- a/builtin-add.c\n+++ b/builtin-add.c\n@@ -140,8 +140,6 @@ static void refresh(int verbose, const char **pathspec)\n \tfor (specs = 0; pathspec[specs]; specs++)\n \t\t/* nothing */;\n \tseen = xcalloc(specs, 1);\n-\tif (read_cache() < 0)\n-\t\tdie(\"index file corrupt\");\n \trefresh_index(&the_index, verbose ? 0 : REFRESH_QUIET, pathspec, seen);\n \tfor (i = 0; i < specs; i++) {\n \t\tif (!seen[i])\n@@ -216,13 +214,36 @@ static int add_config(const char *var, const char *value, void *cb)\n \treturn git_default_config(var, value, cb);\n }\n \n+static int add_files(struct dir_struct *dir, int flags)\n+{\n+\tint i, exit_status = 0;\n+\n+\tif (dir->ignored_nr) {\n+\t\tfprintf(stderr, ignore_error);\n+\t\tfor (i = 0; i < dir->ignored_nr; i++)\n+\t\t\tfprintf(stderr, \"%s\\n\", dir->ignored[i]->name);\n+\t\tfprintf(stderr, \"Use -f if you really want to add them.\\n\");\n+\t\tdie(\"no files added\");\n+\t}\n+\n+\tfor (i = 0; i < dir->nr; i++)\n+\t\tif (add_file_to_cache(dir->entries[i]->name, flags)) {\n+\t\t\tif (!ignore_add_errors)\n+\t\t\t\tdie(\"adding files failed\");\n+\t\t\texit_status = 1;\n+\t\t}\n+\treturn exit_status;\n+}\n+\n int cmd_add(int argc, const char **argv, const char *prefix)\n {\n \tint exit_status = 0;\n-\tint i, newfd;\n+\tint newfd;\n \tconst char **pathspec;\n \tstruct dir_struct dir;\n \tint flags;\n+\tint add_new_files;\n+\tint require_pathspec;\n \n \targc = parse_options(argc, argv, builtin_add_options,\n \t\t\t builtin_add_usage, 0);\n@@ -233,53 +254,43 @@ int cmd_add(int argc, const char **argv, const char *prefix)\n \n \tgit_config(add_config, NULL);\n \n+\tadd_new_files = !take_worktree_changes && !refresh_only;\n+\trequire_pathspec = !take_worktree_changes;\n+\n \tnewfd = hold_locked_index(&lock_file, 1);\n \n \tflags = ((verbose ? ADD_CACHE_VERBOSE : 0) |\n \t\t (show_only ? ADD_CACHE_PRETEND : 0) |\n \t\t (ignore_add_errors ? ADD_CACHE_IGNORE_ERRORS : 0));\n \n-\tif (take_worktree_changes) {\n-\t\tconst char **pathspec;\n-\t\tif (read_cache() < 0)\n-\t\t\tdie(\"index file corrupt\");\n-\t\tpathspec = get_pathspec(prefix, argv);\n-\t\texit_status = add_files_to_cache(prefix, pathspec, flags);\n-\t\tgoto finish;\n-\t}\n-\n-\tif (argc == 0) {\n+\tif (require_pathspec && argc == 0) {\n \t\tfprintf(stderr, \"Nothing specified, nothing added.\\n\");\n \t\tfprintf(stderr, \"Maybe you wanted to say 'git add .'?\\n\");\n \t\treturn 0;\n \t}\n \tpathspec = get_pathspec(prefix, argv);\n \n-\tif (refresh_only) {\n-\t\trefresh(verbose, pathspec);\n-\t\tgoto finish;\n-\t}\n-\n-\tfill_directory(&dir, pathspec, ignored_too);\n+\t/*\n+\t * If we are adding new files, we need to scan the working\n+\t * tree to find the ones that match pathspecs; this needs\n+\t * to be done before we read the index.\n+\t */\n+\tif (add_new_files)\n+\t\tfill_directory(&dir, pathspec, ignored_too);\n \n \tif (read_cache() < 0)\n \t\tdie(\"index file corrupt\");\n \n-\tif (dir.ignored_nr) {\n-\t\tfprintf(stderr, ignore_error);\n-\t\tfor (i = 0; i < dir.ignored_nr; i++) {\n-\t\t\tfprintf(stderr, \"%s\\n\", dir.ignored[i]->name);\n-\t\t}\n-\t\tfprintf(stderr, \"Use -f if you really want to add them.\\n\");\n-\t\tdie(\"no files added\");\n+\tif (refresh_only) {\n+\t\trefresh(verbose, pathspec);\n+\t\tgoto finish;\n \t}\n \n-\tfor (i = 0; i < dir.nr; i++)\n-\t\tif (add_file_to_cache(dir.entries[i]->name, flags)) {\n-\t\t\tif (!ignore_add_errors)\n-\t\t\t\tdie(\"adding files failed\");\n-\t\t\texit_status = 1;\n-\t\t}\n+\tif (take_worktree_changes)\n+\t\texit_status |= add_files_to_cache(prefix, pathspec, flags);\n+\n+\tif (add_new_files)\n+\t\texit_status |= add_files(&dir, flags);\n \n finish:\n \tif (active_cache_changed) {\n-- \n1.5.6.4.570.g052e6\n"},{"id":"83991","messageId":"7vk5fhgrm6.fsf_-_@gitster.siamese.dyndns.org","threadId":"14486","inReplyTo":"7vsku5grpr.fsf@gitster.siamese.dyndns.org","subject":"[PATCH 2/2] git-add -a: add all files","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-07-20T03:29:53Z","receivedAt":"2008-07-20T03:29:53Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"People sometimes find that \"git add -u && git add .\" are 13 keystrokes too\nmany.\n\nThe support of this has been very low priority for me personally, because\nI almost never do \"git add .\" in an already populated directory, and if a\ndirectory is not already populated, there is no point saying \"git add -u\"\nat the same time.\n\nHowever, for two types of people that are very different from me, this\nmode of operation may make sense and there is no reason to leave it\nunsupported. That is:\n\n (1) If you are extremely well disciplined and keep perfect .gitignore, it\n always is safe to say \"git add .\"; or\n\n (2) If you are extremely undisciplined and do not even know what files\n you created, and you do not very much care, it does not matter if\n \"git add .\" included everything.\n\nSo here it is, although I suspect I will not use it myself, ever.\n\nSigned-off-by: Junio C Hamano \n---\n builtin-add.c | 13 +++++++++++--\n 1 files changed, 11 insertions(+), 2 deletions(-)\n\ndiff --git a/builtin-add.c b/builtin-add.c\nindex 9b2ee8c..bc02fd7 100644\n--- a/builtin-add.c\n+++ b/builtin-add.c\n@@ -190,7 +190,7 @@ static const char ignore_error[] =\n \"The following paths are ignored by one of your .gitignore files:\\n\";\n \n static int verbose = 0, show_only = 0, ignored_too = 0, refresh_only = 0;\n-static int ignore_add_errors;\n+static int ignore_add_errors, addremove;\n \n static struct option builtin_add_options[] = {\n \tOPT__DRY_RUN(&show_only),\n@@ -200,6 +200,7 @@ static struct option builtin_add_options[] = {\n \tOPT_BOOLEAN('p', \"patch\", &patch_interactive, \"interactive patching\"),\n \tOPT_BOOLEAN('f', \"force\", &ignored_too, \"allow adding otherwise ignored files\"),\n \tOPT_BOOLEAN('u', \"update\", &take_worktree_changes, \"update tracked files\"),\n+\tOPT_BOOLEAN('a', \"all\", &addremove, \"add all, noticing removal of tracked files\"),\n \tOPT_BOOLEAN( 0 , \"refresh\", &refresh_only, \"don't add, only refresh the index\"),\n \tOPT_BOOLEAN( 0 , \"ignore-errors\", &ignore_add_errors, \"just skip files which cannot be added because of errors\"),\n \tOPT_END(),\n@@ -254,6 +255,14 @@ int cmd_add(int argc, const char **argv, const char *prefix)\n \n \tgit_config(add_config, NULL);\n \n+\tif (addremove && take_worktree_changes)\n+\t\tdie(\"-a and -u are mutually incompatible\");\n+\tif (addremove && !argc) {\n+\t\tstatic const char *here[2] = { \".\", NULL };\n+\t\targc = 1;\n+\t\targv = here;\n+\t}\n+\n \tadd_new_files = !take_worktree_changes && !refresh_only;\n \trequire_pathspec = !take_worktree_changes;\n \n@@ -286,7 +295,7 @@ int cmd_add(int argc, const char **argv, const char *prefix)\n \t\tgoto finish;\n \t}\n \n-\tif (take_worktree_changes)\n+\tif (take_worktree_changes || addremove)\n \t\texit_status |= add_files_to_cache(prefix, pathspec, flags);\n \n \tif (add_new_files)\n-- \n1.5.6.4.570.g052e6\n"},{"id":"83992","messageId":"7vej5pgrhl.fsf_-_@gitster.siamese.dyndns.org","threadId":"14486","inReplyTo":"7vk5fhgrm6.fsf_-_@gitster.siamese.dyndns.org","subject":"[PATCH 3/2] git-add -a: tests","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-07-20T03:32:38Z","receivedAt":"2008-07-20T03:32:38Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"And here is a small test script that makes sure that:\n\n - both modified and new files are included, and\n - no ignored files are included.\n\nSigned-off-by: Junio C Hamano \n---\n t/t2202-add-addremove.sh | 38 ++++++++++++++++++++++++++++++++++++++\n 1 files changed, 38 insertions(+), 0 deletions(-)\n\ndiff --git a/t/t2202-add-addremove.sh b/t/t2202-add-addremove.sh\nnew file mode 100755\nindex 0000000..7bf8eda\n--- /dev/null\n+++ b/t/t2202-add-addremove.sh\n@@ -0,0 +1,38 @@\n+#!/bin/sh\n+\n+test_description='git add -a'\n+\n+. ./test-lib.sh\n+\n+test_expect_success setup '\n+\techo .gitignore >expect &&\n+\t(\n+\t\techo actual\n+\t\techo expect\n+\t\techo ignored\n+\t) >.gitignore &&\n+\tgit add -a &&\n+\ttest_tick &&\n+\tgit commit -m initial &&\n+\tgit ls-files >actual &&\n+\ttest_cmp expect actual\n+'\n+\n+test_expect_success 'git add -a' '\n+\t(\n+\t\techo .gitignore\n+\t\techo not-ignored\n+\t\techo \"M\t.gitignore\"\n+\t\techo \"A\tnot-ignored\"\n+\t) >expect &&\n+\t>ignored &&\n+\t>not-ignored &&\n+\techo modification >>.gitignore &&\n+\tgit add -a &&\n+\tgit update-index --refresh &&\n+\tgit ls-files >actual &&\n+\tgit diff-index --name-status --cached HEAD >>actual &&\n+\ttest_cmp expect actual\n+'\n+\n+test_done\n"},{"id":"83993","messageId":"905315640807192120k45b8c0e3k5b341e77c466dde@mail.gmail.com","threadId":"14486","inReplyTo":"7vk5fhgrm6.fsf_-_@gitster.siamese.dyndns.org","subject":"Re: [PATCH 2/2] git-add -a: add all files","fromName":"Tarmigan","fromEmail":"tarmigan+git@gmail.com","sentAt":"2008-07-20T04:20:09Z","receivedAt":"2008-07-20T04:20:09Z","isPatch":true,"sender":{"key":"tarmigan+git@gmail.com","avatar":null},"body":"On Sat, Jul 19, 2008 at 8:29 PM, Junio C Hamano wrote:\n> People sometimes find that \"git add -u && git add .\" are 13 keystrokes too\n> many.\n\nIt's too bad that 'commit -a' and 'add -a' will have different\nmeanings. Are add and commit considered porcelain enough that their\nshort options could be changed? Probably not, but it would be nice to\nalign 'commit -a' and 'add -a' or maybe 'commit -u' and 'add -u'. I\ncan just hear people whining about inconsistent flags between\nsubcommands with this change.\n\n> The support of this has been very low priority for me personally, because\n> I almost never do \"git add .\" in an already populated directory, and if a\n> directory is not already populated, there is no point saying \"git add -u\"\n> at the same time.\n\nYour reasoning for not using it (which is probably the case for most\npeople), combined with the inconsistent short options makes me dislike\nthe short option a little bit, but I like the long --add option.\n\nThanks,\nTarmigan\n"},{"id":"83994","messageId":"905315640807192128q5e1a4533m3c3585d534772df3@mail.gmail.com","threadId":"14486","inReplyTo":"905315640807192120k45b8c0e3k5b341e77c466dde@mail.gmail.com","subject":"Re: [PATCH 2/2] git-add -a: add all files","fromName":"Tarmigan","fromEmail":"tarmigan+git@gmail.com","sentAt":"2008-07-20T04:28:32Z","receivedAt":"2008-07-20T04:28:32Z","isPatch":true,"sender":{"key":"tarmigan+git@gmail.com","avatar":null},"body":"On Sat, Jul 19, 2008 at 9:20 PM, Tarmigan wrote:\n> On Sat, Jul 19, 2008 at 8:29 PM, Junio C Hamano wrote:\n>> People sometimes find that \"git add -u && git add .\" are 13 keystrokes too\n>> many.\n>\n> It's too bad that 'commit -a' and 'add -a' will have different\n> meanings. Are add and commit considered porcelain enough that their\n> short options could be changed? Probably not, but it would be nice to\n> align 'commit -a' and 'add -a' or maybe 'commit -u' and 'add -u'. I\n> can just hear people whining about inconsistent flags between\n> subcommands with this change.\n>\n>> The support of this has been very low priority for me personally, because\n>> I almost never do \"git add .\" in an already populated directory, and if a\n>> directory is not already populated, there is no point saying \"git add -u\"\n>> at the same time.\n>\n> Your reasoning for not using it (which is probably the case for most\n> people), combined with the inconsistent short options makes me dislike\n> the short option a little bit, but I like the long --add option.\n\nI meant --all instead of --add obviously.\n\n>\n> Thanks,\n> Tarmigan\n>\n"},{"id":"84009","messageId":"7vk5fhc6qo.fsf@gitster.siamese.dyndns.org","threadId":"14486","inReplyTo":"alpine.DEB.1.00.0807190314010.3064@eeepc-johanness","subject":"Re: Suggestion: doc restructuring","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-07-20T08:14:23Z","receivedAt":"2008-07-20T08:14:23Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> So what I really would like is this: leave the plumbing pages as they are, \n> but enhance those pages that users (especially new ones) are likely to see \n> most often.\n\nRegarding the original \"do we want to ever teach plumbing to new users?\"\nissue, I suspect that, with sufficient enhancement to Porcelain, we might\nbe able to reach a point where end users can work without ever touching a\nsingle plumbing command at all.\n\n\tSide note, that was why I suggested us to first think about use\n\tcases in our every day work that we still need to resort to the\n\tplumbing, so that we can identify what that enhancement would\n\tconsist of.\n\nWhen we reach that point, we might want to restructure the documentation\ninto two volumes. One volume for end-users who exclusively use the stock\ngit Porcelain, and another that describes plumbing commands for Porcelain\nwriters.\n\nPerhaps move the plumbing documentation to section 3; just like Perl has\nDBI.3pm and friends there, /usr/share/man/man3/git-cat-file.3git will\ndescribe what scripts can do with the command.\n"},{"id":"84018","messageId":"alpine.DEB.1.00.0807201250530.3305@eeepc-johanness","threadId":"14486","inReplyTo":"905315640807192120k45b8c0e3k5b341e77c466dde@mail.gmail.com","subject":"Re: [PATCH 2/2] git-add -a: add all files","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-07-20T10:56:42Z","receivedAt":"2008-07-20T10:56:42Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sat, 19 Jul 2008, Tarmigan wrote:\n\n> It's too bad that 'commit -a' and 'add -a' will have different\n> meanings.\n\nTwo things:\n\n- add and commit are two _different_ operations, not only in name, but \n also in nature. The fact that \"commit -a\" calls \"add\" is a _pure_ \n convenience. It does not change the fact that \"add\" and \"commit\" are \n completely, utterly different.\n\n- if you are a heavy user of \"commit -a\", chances are that your history is \n not really useful, because you committed unrelated changes accidentally \n in the same commit.\n\nThe latter point, BTW, is the reason I _never_ teach the \"-a\" option \n(actually, I teach no option at all) in my first two Git lessons.\n\nCiao,\nDscho\n"},{"id":"84019","messageId":"alpine.DEB.1.00.0807201257400.3305@eeepc-johanness","threadId":"14486","inReplyTo":"7vk5fhc6qo.fsf@gitster.siamese.dyndns.org","subject":"Re: Suggestion: doc restructuring","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-07-20T11:02:01Z","receivedAt":"2008-07-20T11:02:01Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 20 Jul 2008, Junio C Hamano wrote:\n\n> Johannes Schindelin writes:\n> \n> > So what I really would like is this: leave the plumbing pages as they \n> > are, but enhance those pages that users (especially new ones) are \n> > likely to see most often.\n> \n> Regarding the original \"do we want to ever teach plumbing to new users?\" \n> issue, I suspect that, with sufficient enhancement to Porcelain, we \n> might be able to reach a point where end users can work without ever \n> touching a single plumbing command at all.\n\nI just went back to the thread I mentioned earlier, \nhttp://thread.gmane.org/gmane.comp.version-control.git/59935/focus=62021\nand I did not find where you need plumbing.\n\n> Perhaps move the plumbing documentation to section 3; just like Perl has \n> DBI.3pm and friends there, /usr/share/man/man3/git-cat-file.3git will \n> describe what scripts can do with the command.\n\nBut of course! I was wondering where to put it, but understanding \nplumbing as a sort of library for shell scripts makes sense absolutely!\n\nCiao,\nDscho\n"},{"id":"84031","messageId":"76718490807200545l653bbda1l4d13f1e1e698c855@mail.gmail.com","threadId":"14486","inReplyTo":"alpine.DEB.1.00.0807201250530.3305@eeepc-johanness","subject":"Re: [PATCH 2/2] git-add -a: add all files","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2008-07-20T12:45:24Z","receivedAt":"2008-07-20T12:45:24Z","isPatch":true,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"On Sun, Jul 20, 2008 at 6:56 AM, Johannes Schindelin\n wrote:\n> Two things:\n>\n> - add and commit are two _different_ operations, not only in name, but\n> also in nature. The fact that \"commit -a\" calls \"add\" is a _pure_\n> convenience. It does not change the fact that \"add\" and \"commit\" are\n> completely, utterly different.\n>\n> - if you are a heavy user of \"commit -a\", chances are that your history is\n> not really useful, because you committed unrelated changes accidentally\n> in the same commit.\n>\n> The latter point, BTW, is the reason I _never_ teach the \"-a\" option\n> (actually, I teach no option at all) in my first two Git lessons.\n\nI don't like \"commit -a\" and never use it and wonder why a\nshort-option was wasted on it.\n\nI do like the new \"add -a\" (thank you Junio) but I will rarely use it.\nI had the \"addremove\" alias in my .gitconfig specifically because I\nused it so infrequently that it was hard for me to remember when I did\nneed it. So I think that \"add --addremove\" would be fine and we don't\nneed to spend a short-option (\"-a\") on it.\n\nLastly, I point out that when I started with git, it became much\nclearer when I began reading \"git add\" as \"git stage\". I think my\nfirst alias was \"staged => diff --cached\". But I am someone who likes\nto learn how the things I use work early on.\n\nj.\n"},{"id":"84045","messageId":"7v4p6k8l36.fsf@gitster.siamese.dyndns.org","threadId":"14486","inReplyTo":"76718490807200545l653bbda1l4d13f1e1e698c855@mail.gmail.com","subject":"Re: [PATCH 2/2] git-add -a: add all files","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-07-20T18:30:21Z","receivedAt":"2008-07-20T18:30:21Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Jay Soffian\" writes:\n\n> On Sun, Jul 20, 2008 at 6:56 AM, Johannes Schindelin\n> wrote:\n>> Two things:\n>>\n>> - add and commit are two _different_ operations, not only in name, but\n>> also in nature. The fact that \"commit -a\" calls \"add\" is a _pure_\n>> convenience. It does not change the fact that \"add\" and \"commit\" are\n>> completely, utterly different.\n>>\n>> - if you are a heavy user of \"commit -a\", chances are that your history is\n>> not really useful, because you committed unrelated changes accidentally\n>> in the same commit.\n>>\n>> The latter point, BTW, is the reason I _never_ teach the \"-a\" option\n>> (actually, I teach no option at all) in my first two Git lessons.\n>\n> I don't like \"commit -a\" and never use it and wonder why a\n> short-option was wasted on it.\n>\n> I do like the new \"add -a\" (thank you Junio) but I will rarely use it.\n\nI do not understand either of you. If for whatever reason \"add -A\" makes\nsense in your workflow, it's a sign that you are extremely disciplined\nthat changes in your working tree at one point of time where you would\nissue \"add -A\" are concentrated on a single topic, and at one of such\npoints you may want to commit. For such a disciplined person, \"commit -a\"\nwould make perfect sense there.\n\nSo for such people who would find \"add -A\" useful, \"commit -a\" will not be\n\"unrelated changes in the same commit\". And for such people, I would even\nsay \"commit -A\" would be even more useful, too.\n\nI'll never be in that camp of perfect people myself, though..\n"},{"id":"84063","messageId":"bd6139dc0807201334l446f6da2i36178a1e1063a3bf@mail.gmail.com","threadId":"14486","inReplyTo":"76718490807200545l653bbda1l4d13f1e1e698c855@mail.gmail.com","subject":"Re: [PATCH 2/2] git-add -a: add all files","fromName":"Sverre Rabbelier","fromEmail":"alturin@gmail.com","sentAt":"2008-07-20T20:34:06Z","receivedAt":"2008-07-20T20:34:06Z","isPatch":true,"sender":{"key":"alturin@gmail.com","avatar":null},"body":"On Sun, Jul 20, 2008 at 2:45 PM, Jay Soffian wrote:\n> Lastly, I point out that when I started with git, it became much\n> clearer when I began reading \"git add\" as \"git stage\". I think my\n> first alias was \"staged => diff --cached\". But I am someone who likes\n> to learn how the things I use work early on.\n\nI love it, and the great thing is that auto-complete works on it too!\n\"git diff --cached\" 17 keystrokes\n\"git stag\" 8 keystrokes\nThat's a 9 keystrokes improvement!\n\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"84066","messageId":"20080720204647.GA31432@lars.home.noschinski.de","threadId":"14486","inReplyTo":"7v4p6k8l36.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH 2/2] git-add -a: add all files","fromName":"Lars Noschinski","fromEmail":"lars-2008-1@usenet.noschinski.de","sentAt":"2008-07-20T20:46:47Z","receivedAt":"2008-07-20T20:46:47Z","isPatch":true,"sender":{"key":"lars-2008-1@usenet.noschinski.de","avatar":null},"body":"* Junio C Hamano [08-07-20 20:30]:\n>So for such people who would find \"add -A\" useful, \"commit -a\" will not be\n>\"unrelated changes in the same commit\". And for such people, I would even\n>say \"commit -A\" would be even more useful, too.\n\nThere is one occasion I could use a \"add -A\": To shorten\n\n git add -u; git add .; git commit -m \"wip\"; git checkout $stuff\n\nSo in my opinion, if one wants a \"stage my whole workdir\" option, it\nwould be suited best as an option to commit (and maybe stash).\n"},{"id":"84105","messageId":"20080720235933.GA12454@sigill.intra.peff.net","threadId":"14486","inReplyTo":"7v4p6k8l36.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH 2/2] git-add -a: add all files","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-07-20T23:59:33Z","receivedAt":"2008-07-20T23:59:33Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Jul 20, 2008 at 11:30:21AM -0700, Junio C Hamano wrote:\n\n> So for such people who would find \"add -A\" useful, \"commit -a\" will not be\n> \"unrelated changes in the same commit\". And for such people, I would even\n> say \"commit -A\" would be even more useful, too.\n> \n> I'll never be in that camp of perfect people myself, though..\n\nI don't claim to be perfect, but I do use \"commit -a\" and I haven't ever\nhad a problem committing unrelated changes. My secret is to keep a good\n.gitignore, and to peek at \"git status\" and \"git diff\" before\ncommitting. So it's just a shorthand because after seeing that\neverything is ready for commit, I'm too lazy to type each filename. I\nalso use \"git add .\" for the same purpose if files are to be added.\n\nBut note that avoiding \"-a\" doesn't save you from unrelated changes\nanyway; it only saves you from changes in unrelated files. You still\nhave to look below the file granularity with \"git diff\" to avoid (for\nexample) a debugging printf. I often will use \"git add -i\" if I have a\nlot of complex changes, even if I end up staging _everything_. But it\nlets me say \"yes, this should go in\" for each hunk.\n\nSo maybe I will use \"git add -A\", but I have to admit to not really\nhaving felt its lack to this point. However, something Lars said makes\nme wonder: do people _really_ want this as an option to add? I seem to\nrecall the primary request for this being the \"undisciplined\" approach\nyou gave (\"I have a project that periodically gets data dumped by an\nexternal program, and I want to commit it all\"). In that case, the next\nstep is always commit, so what would be most convenient is \"commit -A\".\n\nBut again, I haven ever felt the lack of this feature; such usage for me\nalways goes in scripts, where I am more than happy to write out \"add .\n&& add -u && commit\".\n\n-Peff\n"},{"id":"84107","messageId":"7vprp814oe.fsf@gitster.siamese.dyndns.org","threadId":"14486","inReplyTo":"20080720235933.GA12454@sigill.intra.peff.net","subject":"Re: [PATCH 2/2] git-add -a: add all files","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-07-21T00:06:41Z","receivedAt":"2008-07-21T00:06:41Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> But again, I haven ever felt the lack of this feature; such usage for me\n> always goes in scripts, where I am more than happy to write out \"add .\n> && add -u && commit\".\n\nThe reason we did not have such \"feature\" so far was not because somebody\nhigh in the git foodchain was opposed to the idea, but simply because\nnobody came up with a usable patch to do so.\n\nI do not have anything fundamentally against \"add -A\" nor \"commit -A\". To\nme, this is in \"perhaps nice to have for some people, but I would not use\nit myself and I wouldn't bother\" category, not in \"I'm opposed -- it would\npromote bad workflow\" cateogry.\n"},{"id":"84111","messageId":"20080721001731.GC12454@sigill.intra.peff.net","threadId":"14486","inReplyTo":"7vprp814oe.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH 2/2] git-add -a: add all files","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-07-21T00:17:32Z","receivedAt":"2008-07-21T00:17:32Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Jul 20, 2008 at 05:06:41PM -0700, Junio C Hamano wrote:\n\n> > But again, I haven ever felt the lack of this feature; such usage for me\n> > always goes in scripts, where I am more than happy to write out \"add .\n> > && add -u && commit\".\n> \n> The reason we did not have such \"feature\" so far was not because somebody\n> high in the git foodchain was opposed to the idea, but simply because\n> nobody came up with a usable patch to do so.\n> \n> I do not have anything fundamentally against \"add -A\" nor \"commit -A\". To\n> me, this is in \"perhaps nice to have for some people, but I would not use\n> it myself and I wouldn't bother\" category, not in \"I'm opposed -- it would\n> promote bad workflow\" cateogry.\n\nI think I didn't make my point well; I am also not that I am opposed to\nthis feature. The paragraph you quoted meant to say \"What I described\nabove with commit -A is what I think people who are asking for this\nfeature want. But _I_ don't actually want it, even as somebody who does\nthis workflow, so I might be wrong.\"\n\n-Peff\n"},{"id":"84113","messageId":"20080721002253.GD12454@sigill.intra.peff.net","threadId":"14486","inReplyTo":"20080721001731.GC12454@sigill.intra.peff.net","subject":"Re: [PATCH 2/2] git-add -a: add all files","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-07-21T00:22:53Z","receivedAt":"2008-07-21T00:22:53Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Jul 20, 2008 at 08:17:32PM -0400, Jeff King wrote:\n\n> I think I didn't make my point well; I am also not that I am opposed to\n\nUrgh, bad editing. \"I am also not opposed\" in case it was not clear.\n\n-Peff\n"},{"id":"84131","messageId":"76718490807201911j11bd4b3k914cec91485f9e0e@mail.gmail.com","threadId":"14486","inReplyTo":"7v4p6k8l36.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH 2/2] git-add -a: add all files","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2008-07-21T02:11:08Z","receivedAt":"2008-07-21T02:11:08Z","isPatch":true,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"On Sun, Jul 20, 2008 at 2:30 PM, Junio C Hamano wrote:\n> I do not understand either of you. If for whatever reason \"add -A\" makes\n> sense in your workflow, it's a sign that you are extremely disciplined\n> that changes in your working tree at one point of time where you would\n> issue \"add -A\" are concentrated on a single topic, and at one of such\n> points you may want to commit. For such a disciplined person, \"commit -a\"\n> would make perfect sense there.\n>\n> So for such people who would find \"add -A\" useful, \"commit -a\" will not be\n> \"unrelated changes in the same commit\". And for such people, I would even\n> say \"commit -A\" would be even more useful, too.\n\nHah, it's Sunday and my brain wasn't awake. You're right, \"commit -a\"\ncomplements when I'd use \"add -a\" -- namely, when I have a branch that\nis tracking a non-git source: either files I'm rsyncing from another\nVCS or drops I'm getting as tarballs. (I'm aware of import-tars.perl.)\n\nj.\n"},{"id":"84145","messageId":"48842FA8.5070309@op5.se","threadId":"14486","inReplyTo":"7vk5fhc6qo.fsf@gitster.siamese.dyndns.org","subject":"Re: Suggestion: doc restructuring","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2008-07-21T06:41:44Z","receivedAt":"2008-07-21T06:41:44Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Junio C Hamano wrote:\n> Johannes Schindelin writes:\n> \n>> So what I really would like is this: leave the plumbing pages as they are, \n>> but enhance those pages that users (especially new ones) are likely to see \n>> most often.\n> \n> Regarding the original \"do we want to ever teach plumbing to new users?\"\n> issue, I suspect that, with sufficient enhancement to Porcelain, we might\n> be able to reach a point where end users can work without ever touching a\n> single plumbing command at all.\n> \n> \tSide note, that was why I suggested us to first think about use\n> \tcases in our every day work that we still need to resort to the\n> \tplumbing, so that we can identify what that enhancement would\n> \tconsist of.\n> \n\nHalf a year or so ago, there were some mailings to the list along the lines\nof \"what git commands do you use?\", using the bash history and a shell\noneliner to dig out some crude intel. Here's mine:\ncat ~/.bash_history | grep ^git | awk '{ print $2 }' | grep -v '^--' | sort | uniq --count | sort -nr\n 29 status\n 26 diff\n 19 show\n 17 log\n 11 branch\n 9 grep\n 8 pull\n 8 commit\n 7 fetch\n 7 describe\n 6 rev-list\n 5 help\n 4 push\n 4 merge\n 3 reset\n 3 config\n 3 clone\n 3 add\n 2 rev-parse\n 2 format-patch\n 1 stash\n 1 checkout\n 1 apply\n\nTo be fair, rev-parse and rev-list are on there due to some oneline scripting.\nI needed to move commits from several different branches to a single place,\nfiltering on author.\n\n> When we reach that point, we might want to restructure the documentation\n> into two volumes. One volume for end-users who exclusively use the stock\n> git Porcelain, and another that describes plumbing commands for Porcelain\n> writers.\n> \n> Perhaps move the plumbing documentation to section 3; just like Perl has\n> DBI.3pm and friends there, /usr/share/man/man3/git-cat-file.3git will\n> describe what scripts can do with the command.\n\nI like this idea, although newbie users may not know what section 3 is for.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"84166","messageId":"alpine.DEB.1.00.0807211202250.3305@eeepc-johanness","threadId":"14486","inReplyTo":"48842FA8.5070309@op5.se","subject":"Re: Suggestion: doc restructuring","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-07-21T10:04:26Z","receivedAt":"2008-07-21T10:04:26Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 21 Jul 2008, Andreas Ericsson wrote:\n\n> Junio C Hamano wrote:\n> \n> > Side note, that was why I suggested us to first think about use cases \n> > in our every day work that we still need to resort to the plumbing, \n> > so that we can identify what that enhancement would consist of.\n> \n> Half a year or so ago, there were some mailings to the list along the \n> lines of \"what git commands do you use?\", using the bash history and a \n> shell oneliner to dig out some crude intel.\n\nActually, I did not even like that approach back then. Just because you \nhappen to be an old-timer and use rev-parse and rev-list frequently does \nnot mean that you _have_ to use it, or even _should_ use it, or that it \nwould be good to teach your command lines to a newbie.\n\nCiao,\nDscho\n"},{"id":"84201","messageId":"7viquztdfj.fsf@gitster.siamese.dyndns.org","threadId":"14486","inReplyTo":"48842FA8.5070309@op5.se","subject":"Re: Suggestion: doc restructuring","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-07-21T16:22:24Z","receivedAt":"2008-07-21T16:22:24Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andreas Ericsson writes:\n\n> Junio C Hamano wrote:\n>> Johannes Schindelin writes:\n>>\n>>> So what I really would like is this: leave the plumbing pages as\n>>> they are, but enhance those pages that users (especially new ones)\n>>> are likely to see most often.\n>>\n>> Regarding the original \"do we want to ever teach plumbing to new users?\"\n>> issue, I suspect that, with sufficient enhancement to Porcelain, we might\n>> be able to reach a point where end users can work without ever touching a\n>> single plumbing command at all.\n>>\n>> \tSide note, that was why I suggested us to first think about use\n>> \tcases in our every day work that we still need to resort to the\n>> \tplumbing, so that we can identify what that enhancement would\n>> \tconsist of.\n>>\n>\n> Half a year or so ago, there were some mailings to the list along the lines\n> of \"what git commands do you use?\", using the bash history and a shell\n> oneliner to dig out some crude intel. Here's mine:\n> cat ~/.bash_history | grep ^git | awk '{ print $2 }' | grep -v '^--' | sort | uniq --count | sort -nr\n> 29 status\n> 26 diff\n> 19 show\n> 17 log\n> ...\n\nWhile that stat might be interesting to look at, it does not have \nmuch relevance to what I was suggesting.\n"}]}