{"thread":{"id":"43105","subject":"Re: [PATCH 0/2] Making \"git commit\" to mean \"git commit -a\".","startedAt":"2006-11-29T03:06:03Z","lastAt":"2006-12-02T07:48:33Z","messageCount":76,"participants":["Marco Costalba","Seth Falcon","Linus Torvalds","Nicolas Pitre","Shawn Pearce","Andy Parkins","Junio C Hamano","Andreas Ericsson","Michael K. Edwards","Johannes Schindelin","Carl Worth","Steven Grimm","Sam Vilain","Jakub Narebski","Robert Shearman","Theodore Tso","Han-Wen Nienhuys","Daniel Barkalow","Alan Chandler","Josef Weidendorfer"],"isPatch":true,"patchVersion":1,"patchTotal":2},"messages":[{"id":"298677","messageId":"7virgzuf38.fsf@assigned-by-dhcp.cox.net","threadId":"43105","inReplyTo":"871wnnwi3k.wl%cworth@cworth.org","subject":"Re: [PATCH 0/2] Making \"git commit\" to mean \"git commit -a\".","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-29T03:06:03Z","receivedAt":"2006-11-29T03:06:03Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Carl Worth writes:\n\n>> The problem I have with the new behaviour is that it goes\n>> against the mental model when I start doing anything nontrivial\n>> (I would not use words as strong as \"totally breaks the mental\n>> model\", but it comes close). I am not sure how well I can\n>> express this, but the short of it is that \"grokking index\" is\n>> not about understanding how the index works, but about trusting\n>> that git does the right thing to the index and you do not have\n>> to worry about it all the time.\n>\n> Frankly, I do not currently trust git to always do the right thing\n> with the index.\n\nThis clearly shows that I did not express myself well. You are\ncorrect that there are commands that ignore the index by default\n(a notable example \"git apply\" has been given by both of us),\nand you do have to know about what the commands you use do to\nthe index.\n\nWhat I meant by \"do not have to worry about\" is not about the\nindex operations each command invocation involves. Of course\nyou need to know (unless you will do a \"commit -a\" at the end)\nthat git apply without --index will leave the index out of sync\nrelative to your working tree, for example.\n\nWhat you do _not_ have to worry about all the time is the local\nchanges you do not want to go in your next commit but still want\nto keep in your working tree. Although it probably is not\nkosher from the purist point of view, it is very convenient to\nbe able to keep truly local changes (say, my GIT-VERSION-GEN,\neverybody's change to Makefile to set \"prefix=/usr/local\", or\n\"#define DEBUG 1\" in one of the C files you are currently\nmucking with) that you have no intention of committing, while\nyou want to record the changes to the paths you worked on so far\nwith patch application, merging and edit + update-index in your\nnext commit. You record the latter in the index using git tools\nto build what you want to have in your next commit in the index\nin each step (again, each step you may have to be aware what you\nare doing). After you update the index, you can forget about\nthem -- because the index remembers them for you. They are in\nthe state you tentatively decided is good for the next commit.\nYou do not have to worry about the local changes you still have\nthat you do not want to have in the commit because you do not\nrun update-index on them, and you can trust that git does not\nautomatically do so either, so they stay local.\n\n>> Once I am done, I can ask \"git diff\" and expect it to show my\n>> local changes I have no intention of committing for now\n>> (e.g. GIT-VERSION-GEN in the working tree has v1.4.5-rc1.GIT\n>> long before I plan to start the rc1 cycle to constantly remind\n>> me what the next version will be, which is a trick I picked up\n>> from Linus), and \"git diff --cached\" would show exactly what I\n>> will commit.\n>\n> I understand the trick, and I'm not proposing anything that would\n> preclude it. But I really don't find it a compelling argument for the\n> default behavior of git-commit.\n\nThe above paragraph is not the important part of my message.\nWhat was much more important is what immediately followed it,\nwhich you did not quote:\n\n And at that point, I trust \"git commit\" to do the right thing --\n the damn thing I just checked with \"git diff --cached\" _is_ what\n will be committed.\n\nLike it or not, git was designed by and for people who use the\nindex to work in a dirty worktree. The \"-a\" option to \"git\ncommit\" is politely explained as the \"--all\" option, but its\ntrue pronunciation is \"screw the index -- I rightfully haven't\nbeen paying attention to the index (my workflow did not require\nme to) because I know all the changes in my worktree are what I\nwant in the next commit\" option.\n\nThe \"screw the index\" attitude is not a wrong thing per-se. It\nis perfectly a good habit to always work in a worktree that\nexactly matches HEAD after each commit, and the only index\nmanipulation you would (unfortunately) need to do between your\nown two commits are \"git add\" (for this use pattern, \"git rm\" is\nan unnecessary thing to do -- just saying \"rm\" is enough). Then\n\"git diff\" (without --cached but perhaps with paths) would serve\nas a preview for your next commit because you are going to do\nthe \"screw the index\" commit (except that unfortunate \"git add\"\nthing, which we _could_ fix with \"intent to add\" entries in the\nindex) and you would be happy with the similarity to CVS.\n\nOnce you use \"I care about the index\" workflow, however, you\nwill see more areas where git's index shine. For example, \"git\ndiff\" starts to take a more useful role. \"I care about the\nindex\" attitude means you let the index be the incremental\nstaging area for your next commit, and when you reach a good\n\"snapshot\" point you update the index with various means\nprovided by git. \"git diff\" will show \"what could further be\nadded to the next commit\" without talking about what you already\ndecided are good earlier and updated the index with. As we\nalready discussed, \"git merge\" will update the index for cleanly\nmerged paths to let you concentrate on more interesting cases\n(i.e. merge conflicts). To people who care about the index, the\nnext commit preview is \"git diff --cached\", not \"git diff HEAD\".\nWhat git promises to them is not to update-index the local\nchanges they have without being told and without their knowing.\n\nThis is where \"git commit\" that does \"-a\" by default goes quite\nagainst the underlying mental model of git. You staged what\nshould appear in the next commit in the index because you did\nnot want to worry about the local changes you still want to keep\nin your working tree. Doing the \"screw the index\" commit by\ndefault to these people is slap in the face. You do not want to\nget your index suddenly screwed at the final moment of making\nthe commit, which happened to me when I did \"commit --amend\"\nwith the version with those two patches applied.\n\nDon't get me wrong. I know there are cases that it is useful to\nalways commit with \"-a\", but that really has to be opt-in. When\nI work in my alternate \"trivial fixes only\" repository, I use\nthe \"screw the index\" workflow myself. When I run git apply and\nthe patch does not apply, I use \"git apply --reject\" and fix the\nmess by hand, and at that point I do not care if that operation\nupdates the index for the paths involved or not (although I do\ncheck if the patch tries to add new paths -- they need to be\ntold to git even whey you take the \"screw the index\" attitude),\nand I do not bother running update-index on them either. But\nthat is possible only because I know I am going to commit the\nfinal result with \"screw the index\" option.\n\n\"grokking the index\" is not about knowing how the index could be\nused in your workflow. It is about actually using the index to\nstage your next commit. Somebody a bit smarter than me once\nsaid that if you deny the index you are denying git. Although I\nwould not say it that strongly, because \"screw the index\" is\nalso a valid workflow to use (arguably part of) git, \"screw the\nindex\" at the commit time _has_ _to_ be a conscious act.\n\n"},{"id":"294299","messageId":"Pine.LNX.4.64.0611282322320.9647@xanadu.home","threadId":"43105","inReplyTo":"7virgzuf38.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH 0/2] Making \"git commit\" to mean \"git commit -a\".","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2006-11-29T04:33:59Z","receivedAt":"2006-11-29T04:33:59Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Tue, 28 Nov 2006, Junio C Hamano wrote:\n\n> What you do _not_ have to worry about all the time is the local\n> changes you do not want to go in your next commit but still want\n> to keep in your working tree.\n\nThis argument has its converse. What you should _not_ have to worry \nabout all the time is whether your index really includes all the changes \nyou want included in your next commit.\n\nAnd whether wanting to leave local changes in the working directory \nwithout commiting them actually happen more often than wanting to commit \nevery changes is arguable.\n\nWhat should be pretty consensual though, is the fact that having \nexperienced GIT users add an alias for \"commit\" actually becoming \"comit \n-i\" to preserve the current behavior is much easier than asking new GIT \nusers do the same but with \"commit -a\".\n\nSo in that context I think having commit without arguments meaning \ncommit -a is a pretty sensible default. And I don't think it has any \ninfluence on the \"learning about the index\" issue.\n\n\n"},{"id":"295171","messageId":"7vr6vmsnly.fsf@assigned-by-dhcp.cox.net","threadId":"43105","inReplyTo":"Pine.LNX.4.64.0611282322320.9647@xanadu.home","subject":"Re: [PATCH 0/2] Making \"git commit\" to mean \"git commit -a\".","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-29T07:44:57Z","receivedAt":"2006-11-29T07:44:57Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nicolas Pitre writes:\n\n> This argument has its converse. What you should _not_ have to worry \n> about all the time is whether your index really includes all the changes \n> you want included in your next commit.\n\nThat's what we have \"git diff\" with various output options for;\nI often do \"git diff --stat\" or \"git diff --name-status\" when I\nknow I am about to commit in a dirty working tree. I suspect\nthat I am not getting your point.\n\n> And whether wanting to leave local changes in the working directory \n> without commiting them actually happen more often than wanting to commit \n> every changes is arguable.\n\nI do not think anybody is talking about which happens more\noften. \"screw the index\" people do not have to worry about the\nindex during the course of their changes in the working tree\ntoward the next commit, and the only time they need to tell git\n(which _IS_ a system based on the index, dammit) about what they\nwant to do with the index is at the commit time, and they tell\ngit to \"screw the index\" by passing \"-a\" to \"git commit\". In\nother words, \"-a\" at commit time is a magic incantation to allow\nthem to be casual about index manipulation before reaching the\npoint to commit. They do not have to worry about differences\nbetween \"git rm --force\" vs \"/bin/rm\" nor \"git apply\" vs \"git\napply --index\").\n\nIt might make sense to have a configuration in .git/config that\nsays \"user.workingtreeistheking = true\". This should obviously\naffect what \"git commit\" does by default, but it also should\nchange the behaviour of other commands to suit the \"screw the\nindex\" workflow better.\n\nFor example, the configuration should probably make \"git diff\"\n(without an explicit --cached nor HEAD) pretend it was asked to\nshow diff between HEAD and the working tree, because the user\nchose not to care about the index. Not caring about the index\nis different from consciously keeping the index clean; for\nexample, running \"git apply --index\" by mistake when he meant to\nsay \"git apply\" should be tolerated, and Porcelain-ish that is\nworking under workingtreeistheking mode should behave as if the\nindex does not exist. In other words, the index is _not_ a\nstaging area towards the next commit for him; the working tree\nis.\n\nI thought Cogito largely follows that model, so it certainly is\npossible to do things that way. And I would not mind if the\nchanges are cleanly done and maintainable. I am NOT going to\nsay that I will refuse to maintain the code that implements the\nworkingtreeistheking half of the system, although it is very\nunlikely that I would ever enable that configuration in my\nrepositories.\n\nWould that make people happy? I do not think so. I think it\nwill lead to more confusion to have two majorly different\nsemantics in the same set of tools.\n\n"},{"id":"298154","messageId":"Pine.LNX.4.64.0611291234350.9647@xanadu.home","threadId":"43105","inReplyTo":"7vr6vmsnly.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH 0/2] Making \"git commit\" to mean \"git commit -a\".","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2006-11-29T18:08:52Z","receivedAt":"2006-11-29T18:08:52Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Tue, 28 Nov 2006, Junio C Hamano wrote:\n\n> Nicolas Pitre writes:\n> \n> > This argument has its converse. What you should _not_ have to worry \n> > about all the time is whether your index really includes all the changes \n> > you want included in your next commit.\n> \n> That's what we have \"git diff\" with various output options for;\n> I often do \"git diff --stat\" or \"git diff --name-status\" when I\n> know I am about to commit in a dirty working tree. I suspect\n> that I am not getting your point.\n\nI'm afraid this conversation is getting nowhere then.\n\n> > And whether wanting to leave local changes in the working directory \n> > without commiting them actually happen more often than wanting to commit \n> > every changes is arguable.\n> \n> I do not think anybody is talking about which happens more\n> often.\n\nBut I do.\n\n> \"screw the index\" people do not have to worry about the\n> index during the course of their changes in the working tree\n> toward the next commit, and the only time they need to tell git\n> (which _IS_ a system based on the index, dammit) about what they\n> want to do with the index is at the commit time, and they tell\n> git to \"screw the index\" by passing \"-a\" to \"git commit\".\n\nNo one talked about \"screw the index\" people. Those are happily using \nCogito.\n\nWe're talking about flattening the GIT learning curve. And as futile it \nmay seem to you that newbies should just use \"commit -a\" without \nthinking, they still get bothered by that -a there. And probably \nthey'll forget about it once in a while and then GIT will _appear_ as \nmalfunctioning to them.\n\nOf course amongst those newbies that didn't went away at this point \nthere will be those who decide to study further and come to the index \nconcept. And I hope that we all agree that the index is a powerful but \nstill advanced concept that should not be presented up front.\n\nBut my point is: why not making a very little change to the default \ncommit behavior. Really little change involving -a being the default. \nThe impact on newbies will be significant as they won't have to grok \neverything at once to make sense of this -a we are telling them to use \nblindly. And it will sort of match known expectations to commit \neverything dirty.\n\nAnd actually my point above is that in many cases, maybe the majoryty of \nthose case but this is arguable, what one is doing is not keeping dirty \nand uncommited state around but rather committing every changes all the \ntime. In _that_ case, which might not be all the time but often enough, \nthen using -a is annoying[1].\n\nSo having -a the default makes GIT much more friendly to new users. You \n\"add\" files, you \"commit\", you edit some files, you \"commit\" again, and \neverything works fine, and you are happy and starts feeling good about \nGIT.\n\nNow for those who've seen the light and want to use the index it is not \nmuch of a bother to add a -i to their commit invokation. At this point \nif you understand the index you know what you're doing, and using -i \nwon't bother you as much it bothered you to use -a without knowing \nwhy when you was a newbie.\n\nBut still, if you are a GIT old fart and have difficulties switching \nhabits, or if you simply are the kind with dirty not-to-commit state in \nyour tree and adding -i all the time bothers you just like [1] above, \nthen there is a way out! You are a GIT expert at this point of course \nand certainly know how to add an alias for the -i to be implicit with \nyour \"commit\".\n\nTherefore I think this is much more logical to ask the experts to add an \nalias for \"commit -i\" than asking such tricks from less experienced \nusers. This is all my point is about.\n\n\n"},{"id":"297204","messageId":"ekkir2$6fq$1@sea.gmane.org","threadId":"43105","inReplyTo":"Pine.LNX.4.64.0611291234350.9647@xanadu.home","subject":"Re: [PATCH 0/2] Making \"git commit\" to mean \"git commit -a\".","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-11-29T18:18:58Z","receivedAt":"2006-11-29T18:18:58Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Nicolas Pitre wrote:\n\n> But my point is: why not making a very little change to the default \n> commit behavior. Really little change involving -a being the default.  \n> The impact on newbies will be significant as they won't have to grok \n> everything at once to make sense of this -a we are telling them to use \n> blindly. And it will sort of match known expectations to commit \n> everything dirty.\n> \n> And actually my point above is that in many cases, maybe the majoryty of \n> those case but this is arguable, what one is doing is not keeping dirty \n> and uncommited state around but rather committing every changes all the \n> time.  In _that_ case, which might not be all the time but often enough, \n> then using -a is annoying[1].\n> \n> So having -a the default makes GIT much more friendly to new users.  You \n> \"add\" files, you \"commit\", you edit some files, you \"commit\" again, and \n> everything works fine, and you are happy and starts feeling good about \n> GIT.\n> \n> Now for those who've seen the light and want to use the index it is not \n> much of a bother to add a -i to their commit invokation.  At this point \n> if you understand the index you know what you're doing, and using -i \n> won't bother you as much it bothered you to use -a without knowing \n> why when you was a newbie.\n> \n> But still, if you are a GIT old fart and have difficulties switching \n> habits, or if you simply are the kind with dirty not-to-commit state in \n> your tree and adding -i all the time bothers you just like [1] above, \n> then there is a way out!  You are a GIT expert at this point of course \n> and certainly know how to add an alias for the -i to be implicit with \n> your \"commit\".\n> \n> Therefore I think this is much more logical to ask the experts to add an \n> alias for \"commit -i\" than asking such tricks from less experienced \n> users. This is all my point is about.\n\nBut for different reasons this alias cannot be named \"commit\". So you cannot\nwith alias make \"git commit\" (with -a by default) work with index. \n\nIf \"git commit -a\" by default heresy ;-) was accepted, I'd rather it be via\nconfiguration option.\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"},{"id":"296261","messageId":"7vzmaaozi8.fsf@assigned-by-dhcp.cox.net","threadId":"43105","inReplyTo":"Pine.LNX.4.64.0611291234350.9647@xanadu.home","subject":"Re: [PATCH 0/2] Making \"git commit\" to mean \"git commit -a\".","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-29T18:53:51Z","receivedAt":"2006-11-29T18:53:51Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nicolas Pitre writes:\n\n> Of course amongst those newbies that didn't went away at this point \n> there will be those who decide to study further and come to the index \n> concept. And I hope that we all agree that the index is a powerful but \n> still advanced concept that should not be presented up front.\n\nI do not necessarily agree with the last sentence.\n\n> But my point is: why not making a very little change to the default \n> commit behavior. Really little change involving -a being the default. \n\nWhile I understand that is what you are suggesting, my point is\nthat it will not stop at \"commit -a\". I already gave an example\nthat \"diff\" needs to behave differently, if you want to match\nthe behaviour of git consistently with \"newbie\" expectations.\n\nIf you go down that path, you would end up with two systems\nnamed git, that base their operations on two quite different\nmental models and behave differently. You do not want to go\nthere; well at least I don't.\n\n> The impact on newbies will be significant as they won't have to grok \n> everything at once to make sense of this -a we are telling them to use \n> blindly.\n\nSo don't tell them to use \"-a\" blindly. Teach them what it\nmeans using the terms they understand; we assume they haven't\nlearned the \"index\" yet, so we would explain that \"it is a way\nto commit all changes in the working tree\". It is a short-hand\nso that they do not have to list all modified paths (or their\ngit is recent enough, \".\").\n\nAfter they learn what it means and get used to using it, they\nwill start wondering why we do not default to \"-a\". By that\ntime, they would already have learned the config (because the\nfirst thing the tutorial teaches is user.name/user.email), and\ncan use the alias mechanismk there to alias -a away.\n"},{"id":"295248","messageId":"456DDADC.7030509@midwinter.com","threadId":"43105","inReplyTo":"7vzmaaozi8.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH 0/2] Making \"git commit\" to mean \"git commit -a\".","fromName":"Steven Grimm","fromEmail":"koreth@midwinter.com","sentAt":"2006-11-29T19:09:16Z","receivedAt":"2006-11-29T19:09:16Z","isPatch":true,"sender":{"key":"koreth@midwinter.com","avatar":"https://gravatar.com/avatar/71b4d2e8b62f168bdc9e9205341159e3567003b4f9e2127c617c5fa0a1f5bad2?d=mp&s=160"},"body":"Junio C Hamano wrote:\n> After they learn what it means and get used to using it, they\n> will start wondering why we do not default to \"-a\".\n\nMore likely they will start wondering the instant you tell them to use \nit the first time. Or at least they'll ask, \"If '-a' means commit all \nfiles, what's the default?\" And then you either have to blow off the \nquestion or start telling them about the index.\n\n-Steve\n"},{"id":"294749","messageId":"456DDB91.8080608@midwinter.com","threadId":"43105","inReplyTo":"ekkir2$6fq$1@sea.gmane.org","subject":"Re: [PATCH 0/2] Making \"git commit\" to mean \"git commit -a\".","fromName":"Steven Grimm","fromEmail":"koreth@midwinter.com","sentAt":"2006-11-29T19:12:17Z","receivedAt":"2006-11-29T19:12:17Z","isPatch":true,"sender":{"key":"koreth@midwinter.com","avatar":"https://gravatar.com/avatar/71b4d2e8b62f168bdc9e9205341159e3567003b4f9e2127c617c5fa0a1f5bad2?d=mp&s=160"},"body":"Jakub Narebski wrote:\n> If \"git commit -a\" by default heresy ;-) was accepted, I'd rather it be via\n> configuration option.\n> \n\nSo the newbie-friendly behavior should require learning how to edit a \nconfiguration file, and the expert-friendly behavior should be the one \nyou get on your first out-of-the-box exposure to git?\n\n"},{"id":"298684","messageId":"ekkn1u$mi9$1@sea.gmane.org","threadId":"43105","inReplyTo":"456DDB91.8080608@midwinter.com","subject":"Re: [PATCH 0/2] Making \"git commit\" to mean \"git commit -a\".","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-11-29T19:30:54Z","receivedAt":"2006-11-29T19:30:54Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Steven Grimm wrote:\n\n> Jakub Narebski wrote:\n>>\n>> If \"git commit -a\" by default heresy ;-) was accepted, I'd rather it be via\n>> configuration option.\n> \n> So the newbie-friendly behavior should require learning how to edit a \n> configuration file, and the expert-friendly behavior should be the one \n> you get on your first out-of-the-box exposure to git?\n\nWell, newbie friendly could be the default, while hacker friendly\n(expert friendly) would require learning how to configure git\n(there is actually no need to hand-edit configuration file, by the way).\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"},{"id":"294758","messageId":"Pine.LNX.4.63.0611292059480.30004@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"43105","inReplyTo":"456DDADC.7030509@midwinter.com","subject":"Re: [PATCH 0/2] Making \"git commit\" to mean \"git commit -a\".","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-11-29T20:01:11Z","receivedAt":"2006-11-29T20:01:11Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 29 Nov 2006, Steven Grimm wrote:\n\n> Junio C Hamano wrote:\n> > After they learn what it means and get used to using it, they\n> > will start wondering why we do not default to \"-a\".\n> \n> More likely they will start wondering the instant you tell them to use \n> it the first time. Or at least they'll ask, \"If '-a' means commit all \n> files, what's the default?\" And then you either have to blow off the \n> question or start telling them about the index.\n\nSo what? Tell them that there is a staging area, which makes many \noperations of git very powerful and fast. And this staging area is called \n\"the index\" in git. And to put some files into it, specify those \nfiles. If you want _all_ modified files there, use \"-a\". That's it.\n\nCiao,\nDscho\n"},{"id":"294606","messageId":"7vlkluoulf.fsf@assigned-by-dhcp.cox.net","threadId":"43105","inReplyTo":"Pine.LNX.4.63.0611292059480.30004@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH 0/2] Making \"git commit\" to mean \"git commit -a\".","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-29T20:39:56Z","receivedAt":"2006-11-29T20:39:56Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> On Wed, 29 Nov 2006, Steven Grimm wrote:\n>\n>> More likely they will start wondering the instant you tell them to use \n>> it the first time. Or at least they'll ask, \"If '-a' means commit all \n>> files, what's the default?\" And then you either have to blow off the \n>> question or start telling them about the index.\n>\n> So what? Tell them that there is a staging area, which makes many \n> operations of git very powerful and fast. And this staging area is called \n> \"the index\" in git. And to put some files into it, specify those \n> files. If you want _all_ modified files there, use \"-a\". That's it.\n\nWell said.\n\nI think I have stated my preference and reasoning clearly enough\non this topic, so I won't waste my time repeating them. My time\nis better spent on _listening_ to people who might want to make\nconvincing arguments to influence what I will end up deciding\n(the final decision will be mine anyway).\n\nBy the way, I've been having fun with the xdl_merge() stuff;\nthanks for a job well done. I will push some of it out in 'pu'\nshortly.\n"},{"id":"298666","messageId":"Pine.LNX.4.63.0611292248310.30004@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"43105","inReplyTo":"7vlkluoulf.fsf@assigned-by-dhcp.cox.net","subject":"xdl_merge(), was Re: [PATCH 0/2] Making \"git commit\" to mean \"git commit -a\".","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-11-29T21:50:24Z","receivedAt":"2006-11-29T21:50:24Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 29 Nov 2006, Junio C Hamano wrote:\n\n> By the way, I've been having fun with the xdl_merge() stuff; thanks for \n> a job well done. I will push some of it out in 'pu' shortly.\n\nOh *blush*, I fixed a few things since I sent that out... Will submit the \nremaining things as soon as the beast shows up in pu.\n\nCiao,\nDscho\n"},{"id":"296266","messageId":"87ejrlvn7r.wl%cworth@cworth.org","threadId":"43105","inReplyTo":"7vr6vmsnly.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH 0/2] Making \"git commit\" to mean \"git commit -a\".","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2006-11-29T23:37:28Z","receivedAt":"2006-11-29T23:37:28Z","isPatch":true,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Tue, 28 Nov 2006 23:44:57 -0800, Junio C Hamano wrote:\n> Nicolas Pitre writes:\n>\n> > This argument has its converse. What you should _not_ have to worry\n> > about all the time is whether your index really includes all the changes\n> > you want included in your next commit.\n>\n> That's what we have \"git diff\" with various output options for;\n> I often do \"git diff --stat\" or \"git diff --name-status\" when I\n> know I am about to commit in a dirty working tree. I suspect\n> that I am not getting your point.\n\nI think you just backed up the point you didn't understand. You said,\n\"when I know I am about to commit in a dirty working tree\". That's an\nexceptional thing to do, (from the point of view of your \"pure\ndiscipline\"), so you will always be conscious of doing it when you do.\n\n> > And whether wanting to leave local changes in the working directory\n> > without commiting them actually happen more often than wanting to commit\n> > every changes is arguable.\n>\n> I do not think anybody is talking about which happens more\n> often.\n\nThat's exactly what I'm trying to talk about here.\n\nI've been using your \"commit -i and -a as default\" patches since you\nsent them out, (thanks again for sending them). I will readily admit\nthat the very first commit I wanted to make was a \"partial, dirty\ntree\" commit.\n\nWhat happened was that I had made a couple of independent changes in\nconcert and now I wanted to commit them separately. I think that in my\nusage, this is the most common case for me using update-index and\ncommit rather than \"commit -a\". It also happened that the independent\nchanges modified disjoint sets of files.\n\nNow, the index works perfectly for this kind of situation, and I like\nit. Some of the people that I know, (people who are currently refusing\nto touch git, and people for whom I've been trying to be a proponent\nin this discussion), would just use \"git commit file1 file2 ....\" in\nthis situation. I don't do that since I really like being able to\nidentify the files in one command, (update-index), and then preview\nthe commit I'm going to make before I do so, (with \"diff\n--cached). Sure, I could just do the commit, do an after-the-fact\nreview with \"show\" and then reset if I screwed up, but that just feels\nlike the wrong way to go about it.\n\nSo, I'm an index lover here. I see how it's useful and I use it on a\nregular basis. But I do believe I make \"clean index\" commits more\nfrequently. And regardless, I still think we should change the default\nfor git-commit to make it easier for users to learn git.\n\n[As an aside, the situation of independent changes being mixed in a\nworking tree is not always so lucky as to be cleanly separated into\ndisjoint file sets. When it's not, I have to disentangle them. Now,\nthe index could really help during this operation too, but we would\nneed better tools than update-index which only works on a per-file\nbasis. Something that let me easily select chunks of the patch would\nbe really nice.]\n\n> \"screw the index\" people do not have to worry about the\n> index during the course of their changes in the working tree\n> toward the next commit, and the only time they need to tell git\n> (which _IS_ a system based on the index, dammit)\n\nI don't think \"screw the index\" is an accurate way to characterize my\nposition at least. [In fact is \"_the_ index\" even a good way to\ndescribe what git has? Doesn't a commit operation that lists explicit\nfiles build up an alternate index which it will throw away if there's\na failure at some point?]\n\nSo some git operations work by creating a tree object by first putting\nsome state into an index file. That's fine. And users can even take\nadvantage of doing that themselves if they want to. That's fine too.\n\nAll I'd like is that new users didn't have to learn those concepts as\nearly as they have to do with current git.\n\nNow, one time git really does have \"_the_ index\" and when the user\nreally needs to know about it is when there is a conflicted merge. As\nLinus has been pointing out recently, there are some important\nbenefits that the index provides at this point. And I think this is\nthe right time to teach users about the index. I think they can learn\nit and take advantage of it at that point, (and I wouldn't even expect\nthem to necessarily want to change the configuration of what \"git\ncommit\" means).\n\nIn general, the process of resolving a conflicted merge is poorly\npresented to the user by git. The commands that leave the conflicted\nindex, (git pull, git rebase, etc.) and that examine it, (git status),\ndon't do a good job of telling the user what to do (git update-index)\nand how to examine the situation (git diff --merge). I think this\ncould be improved a lot, and one piece of that is the \"git resolve\"\nthing I've been proposing recently.\n\n> It might make sense to have a configuration in .git/config that\n> says \"user.workingtreeistheking = true\". This should obviously\n> affect what \"git commit\" does by default,\n\nI'd love to see a configuration value added, but I don't think we gain\nanything at all if we add a configuration value and leave the default\nvalue the same. It's not easier to tell new users to configure git to\nwork this way then it is to tell them to use \"commit -a\".\n\n> but it also should\n> change the behaviour of other commands to suit the \"screw the\n> index\" workflow better.\n>\n> For example, the configuration should probably make \"git diff\"\n> (without an explicit --cached nor HEAD) pretend it was asked to\n> show diff between HEAD and the working tree, because the user\n> chose not to care about the index.\n\nActually, I strongly disagree on this point. Months ago, before I\nunderstood the index as well as I do now, I did argue for a change\nlike that, since I thought the index was just confusing. But I think\nit would be a mistake to make two fundamentally different models creep\nthrough all the tools. (Which is to say, I'm agreeing with what I\nthink your motivation is for pushing back against that kind of thing.)\n\nPlus, this model would be just broken anyway. The problem is that \"git\ndiff\" meaning \"git diff HEAD\" works just fine when you're in a\n\"normal\" situation. But as soon as you're looking at a conflicted\nmerge, then \"git diff HEAD\" isn't useful at all, but the difference\nbetween the index and the working tree is very useful. In that\nsituation, the behavior of \"git diff\" suddenly makes a lot of sense,\nand the index has its chance to shine. This can lead to a nice\nepiphany for users I think.\n\n Not caring about the index\n> is different from consciously keeping the index clean;\n\nYes, those are different. And I agree with you that a \"pretend the\nindex doesn't exist\" mode would not be an improvement.\n\nWhat I would like to see instead is that all commands keep the index\nclean by default, (with the notable exception of failed merge). And\nthe only way to get it dirty would be with an explicit option such as\n\"apply --index\".\n\nSee? If users only get a dirty index by asking for it, then the\nlikelihood of confusion goes way down, as users who haven't heard of\n\"the index\" certainly won't have any reason to pass a \"--index\" option\naround.\n\n> Would that make people happy? I do not think so. I think it\n> will lead to more confusion to have two majorly different\n> semantics in the same set of tools.\n\nAgreed. Let's not go there.\n\nI think what I'm asking for is a much more mild change. The \"keep the\nindex clean\" behavior exists almost everywhere already, (the few\nexceptions are things like \"git cherry-pick -n\", and the notable\nexception of a conflicted merge). So I don't think supporting \"commit\n-a by default\" means we have to introduce a large conceptual change.\n\nAlso, for the case of the conflicted merge, the index really is a key\npart of what lets the user work through things. But there's really not\nan _essential_ need for the user to fully grok the index to take\nadvantage of that. It's not hard to describe the behavior of \"git\ndiff\" and \"git diff --merge\" in terms of things that the user wants to\nknow, without mentioning the index at all. (Now, if a user asks, \"how\nis git able to tell me all this amazing stuff\", then would be a great\ntime to explain the index, I think).\n\nDid I succeed in getting you to consider anything new here? I hope\nso. I don't want you to feel like we're both just saying the same\nthings back and forth over and over with no progress.\n\n-Carl\n"},{"id":"298738","messageId":"Pine.LNX.4.63.0611300050180.30004@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"43105","inReplyTo":"87ejrlvn7r.wl%cworth@cworth.org","subject":"Re: [PATCH 0/2] Making \"git commit\" to mean \"git commit -a\".","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-11-29T23:53:10Z","receivedAt":"2006-11-29T23:53:10Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 29 Nov 2006, Carl Worth wrote:\n\n> [As an aside, the situation of independent changes being mixed in a \n> working tree is not always so lucky as to be cleanly separated into \n> disjoint file sets. When it's not, I have to disentangle them. Now, the \n> index could really help during this operation too, but we would need \n> better tools than update-index which only works on a per-file basis. \n> Something that let me easily select chunks of the patch would be really \n> nice.]\n\nI regularly do something like\n\n\t$ git diff [file] > a1.patch\n\t$ vi a1.patch\n\t [edit out the chunks I want to commit]\n\t$ git apply -R < a1.patch\n\t$ git commit [file]\n\t$ git apply < a1.patch\n\nSeems a little bit convoluted, but works...\n\nHth,\nDscho\n"},{"id":"296654","messageId":"Pine.LNX.4.64.0611291900550.20138@iabervon.org","threadId":"43105","inReplyTo":"7virgzuf38.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH 0/2] Making \"git commit\" to mean \"git commit -a\".","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2006-11-30T00:52:06Z","receivedAt":"2006-11-30T00:52:06Z","isPatch":true,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Tue, 28 Nov 2006, Junio C Hamano wrote:\n\n> The above paragraph is not the important part of my message.\n> What was much more important is what immediately followed it,\n> which you did not quote:\n> \n> And at that point, I trust \"git commit\" to do the right thing --\n> the damn thing I just checked with \"git diff --cached\" _is_ what\n> will be committed.\n\nPerhaps you'd be happier if the command to commit what \"git diff --cached\" \nshows were \"git commit --cached\" rather than \"git commit -i\"? (Or if they \nwere both --index; how did we miss that last September?)\n\nIt seems logical to me that \"git commit\" would commit the changes shown by \n\"git diff\" (in addition to changes in the index, of course, which are so \nobvious as to need no mention). I personally check with \"git diff\" and \ncommit if everything there looks good; otherwise I tweak stuff until it \ndoes. And if there are a lot of changes, and all of those in some files \nlook good, but those in other files need work, I can \"git update-index\" \nthe ones I know I like so I don't have to go through them each time I'm \nchecking on other stuff next time.\n\n> This is where \"git commit\" that does \"-a\" by default goes quite\n> against the underlying mental model of git. You staged what\n> should appear in the next commit in the index because you did\n> not want to worry about the local changes you still want to keep\n> in your working tree. \n\nThat is not so clear to me. Maybe you're putting changes into the index to \nreduce the noise in \"git diff\", by updating everything that's \nunquestionable while you examine the other stuff. I think that everything \nin the index is clearly in the next commit, but it's obviously not true \nthat everything in the next commit is in the index (because you might not \nbe done updating things yet).\n\n> Doing the \"screw the index\" commit by default to these people is slap in \n> the face. You do not want to get your index suddenly screwed at the \n> final moment of making the commit, which happened to me when I did \n> \"commit --amend\" with the version with those two patches applied.\n\nI personally think that --amend should default to retaining the same tree, \nwith options available for using the index or -a or paths. Using the index \nby default is just as wrong as -a; you're just more careful about it by \nexperience. The index holds stuff to go in the *next* commit, but --amend \ngenerates a new version of the *previous* commit, so the logical basis for \nthe new previous commit is the old previous commit's tree, leaving the \nindex alone.\n\n\t-Daniel\n"},{"id":"295194","messageId":"7vodqpn3t4.fsf@assigned-by-dhcp.cox.net","threadId":"43105","inReplyTo":"87ejrlvn7r.wl%cworth@cworth.org","subject":"Re: [PATCH 0/2] Making \"git commit\" to mean \"git commit -a\".","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-30T01:03:51Z","receivedAt":"2006-11-30T01:03:51Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Carl Worth writes:\n\n> I think what I'm asking for is a much more mild change. The \"keep the\n> index clean\" behavior exists almost everywhere already, (the few\n> exceptions are things like \"git cherry-pick -n\", and the notable\n> exception of a conflicted merge). So I don't think supporting \"commit\n> -a by default\" means we have to introduce a large conceptual change.\n\nWe seem to be agreeing (and Linus seems to, too, in a thread\nnext door) that it is a good thing that git keeps index clean\nunless you explicitly ask it to.\n\nWe also seem to be agreeing that people with more involved needs\ncan deliberately make index different from HEAD, way before\nissuing \"git commit\", and that they can commit even when \"git\ndiff\" gives nonempty differences, and these are good things.\n\nAre we on the same page?\n\nNow what does it mean to make \"commit\" silently update the index\nwith all the changes in the working tree without being told?\n\nUnless you are introducing \"working tree is the king\" mode to\ngit to make everything ignore the index's \"contents\" part (in\nother words, the index is used as the CVS/Entries file, nothing\nmore, under that mode of operation), I think you just introduced\nan inconsistency at the place where the difference matters most.\n\nI do not agree what you are asking is a \"mild change\" at all,\nand I said it already that it goes against the mental model of\nhow git tools work.\n\nEarlier, the world model was \"you build it in the index and you\nmake a commit of what is in the index; there is a last-minute\nindex operation you can do by passing paths to commit and as a\nshort-hand there is -a as well [*1*]\". Now you made the world\nmodel \"it does not matter what you have in the index before\nissuing git-commit; if you want to preserve what you built in\nthe index, you have to do something non-default\". That WOULD\nsolicit more newbie confusion. \"If it does not matter at the\nend unless you do something special, why bother doing it at\nall?\" would be the question you would face.\n\nEarlier on the \"UI warts\" thread, people said that the users do\nnot form the mental model of how the toolset works by reading\nthe tool's documentation but by trying things out, and I think\nthat is a valid observation. We should not be sending a wrong\nmessage by introducing inconsistencies like that.\n\nThe tool's UI should naturally reflect what world model it is\nbased on, and like it or not, the world model of git includes\nthe index. The way to explain \"-a\" to new users should not be\n\"you can _ignore_ index as long as you use -a\". I do not think\ndenying the index buys the new users anything. Rather,\n\"building your next commit incrementally in the index is the\nworkflow git is designed to support, but you are not required to\ndo that _incrementally_. Until you encounter a complex\nsituation such as resolving a large conflicting merge, doing\nthat incrementally does not buy you anything as long as you work\nin a clean working tree. Instead, you can tell git what you\nwant to commit when you run 'git-commit' by giving paths or\ndirectory names, or if you want to commit everything in the\nworking tree, then you can also say '-a'\".\n\nI am all for rewording the cryptic \"use update-index to update\"\nmessage with \"use 'commit -a' to commit all of them\" or\nsomesuch. That does NOT break the mental model.\n\nAnother thing that we need to be aware of is that new users\nwon't be \"newbies\" forever, and the tool should not be optimized\nfor the first few pages of the tutorial. You and Nico say\n\"experienced people can always alias UI warts away\", but I think\nthat is a wrong attitude. Users with experience, long after\nthis discussion is forgotten, would complain \"other tools help\nus build the next commit in the index, but git-commit by default\ndiscards the distinction between what were marked for commit and\nwhat were not, unless explicitly told not to. Why does it do -a\nby default, and why should I forced to alias that stupid default\naway?\"\n\n\n[Footnote]\n\n*1* In retrospect, making \"commit -o\" the default was a very bad\nchange; I got tired of repeating myself in that discussion and\napplied that change, but it was probably a mistake.\n\n"},{"id":"296055","messageId":"7vk61dn2yj.fsf@assigned-by-dhcp.cox.net","threadId":"43105","inReplyTo":"7vodqpn3t4.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH 0/2] Making \"git commit\" to mean \"git commit -a\".","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-30T01:22:12Z","receivedAt":"2006-11-30T01:22:12Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> ... Rather,\n> \"building your next commit incrementally in the index is the\n> workflow git is designed to support, but you are not required to\n> do that _incrementally_. Until you encounter a complex\n> situation such as resolving a large conflicting merge, doing\n> that incrementally does not buy you anything as long as you work\n> in a clean working tree.\n\nSide note. I think the above \"Until...\" is an overstatement,\nand maybe the readers of the tutorial can be taught a lot\nearlier how the index can help them. Maybe the following\nsequence can be added to an early part of the tutorial sequence?\n\n $ edit hello.c\n $ make test\n $ git diff\n $ git update-index hello.c; # ok, that is good so far.\n $ edit hello.c; # hack more\n $ make test; # oops, does not work\n $ git diff; # ah, that overeager edit broken what was good\n $ git checkout hello.c; # get the last good one back\n\n"},{"id":"297863","messageId":"456E3AB7.1030306@midwinter.com","threadId":"43105","inReplyTo":"7vk61dn2yj.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH 0/2] Making \"git commit\" to mean \"git commit -a\".","fromName":"Steven Grimm","fromEmail":"koreth@midwinter.com","sentAt":"2006-11-30T01:58:15Z","receivedAt":"2006-11-30T01:58:15Z","isPatch":true,"sender":{"key":"koreth@midwinter.com","avatar":"https://gravatar.com/avatar/71b4d2e8b62f168bdc9e9205341159e3567003b4f9e2127c617c5fa0a1f5bad2?d=mp&s=160"},"body":"Junio C Hamano wrote:\n> Side note. I think the above \"Until...\" is an overstatement,\n> and maybe the readers of the tutorial can be taught a lot\n> earlier how the index can help them. Maybe the following\n> sequence can be added to an early part of the tutorial sequence?\n>\n> $ edit hello.c\n> $ make test\n> $ git diff\n> $ git update-index hello.c; # ok, that is good so far.\n> $ edit hello.c; # hack more\n> $ make test; # oops, does not work\n> $ git diff; # ah, that overeager edit broken what was good\n> $ git checkout hello.c; # get the last good one back\n> \n\nThat actually points out one of the things I think isn't so hot about \nusing update-index for checkpointing your work. Here's a longer \ndevelopment session:\n\n$ edit hello.c\n$ make test\n$ git update-index hello.c; # so far so good\n$ edit hello.c\n$ make test\n$ git update-index hello.c; # looks good too\n$ edit hello.c\n$ make test\n$ git update-index hello.c; # sure, seems okay\n$ edit hello.c\n$ make test; # oops! design flaw in the second edit uncovered!\n$ ???; # how do I back out the last three edits but not the first?\n\nIf you know for certain that you will only ever want to back out the \nmost recent edit during your development, or back out all the way to \nHEAD, then update-index is fine, but if (like me) you want to checkpoint \nyour work frequently so you can step back in a very fine-grained \nfashion, then it's less than ideal to have only one checkpoint that \nkeeps getting overwritten.\n\nFor frequent checkpointing, as far as I can tell I pretty much need to \ncommit (to a development branch, of course) every time. I do that \nbecause I never know beforehand whether I'll need to go back by more \nthan one step later on; 99% of the time I don't have to, of course, but \nthe remaining 1% is pretty painful if I can't.\n\nAm I missing some magic index command that would support multi-level \nbacking out? Obviously StGIT is an option as well, but that seems like \noverkill when all I want is to checkpoint my work. The above is why, \neven though (I think) I know enough about the index to use it as you \ndescribe, I often don't bother and just run \"commit -a\" during \ndevelopment instead. When I merge, I usually fold all my checkpoint \ncommits together and merge the change as a logical unit.\n\nBut I'm still a relative n00b and would appreciate knowing if I'm just \nmissing some big obvious technique.\n\n"},{"id":"295176","messageId":"456E3C3A.6050807@vilain.net","threadId":"43105","inReplyTo":"456E3AB7.1030306@midwinter.com","subject":"Re: [PATCH 0/2] Making \"git commit\" to mean \"git commit -a\".","fromName":"Sam Vilain","fromEmail":"sam@vilain.net","sentAt":"2006-11-30T02:04:42Z","receivedAt":"2006-11-30T02:04:42Z","isPatch":true,"sender":{"key":"sam@vilain.net","avatar":"https://gravatar.com/avatar/8fc840ca854dbf6f7065b4335e3b934951c1dca3b11db688e95e471901f8f4a8?d=mp&s=160"},"body":"Steven Grimm wrote:\n> Am I missing some magic index command that would support multi-level \n> backing out? Obviously StGIT is an option as well, but that seems like \n> overkill when all I want is to checkpoint my work. The above is why, \n> even though (I think) I know enough about the index to use it as you \n> describe, I often don't bother and just run \"commit -a\" during \n> development instead. When I merge, I usually fold all my checkpoint \n> commits together and merge the change as a logical unit.\n> \n\nTry `git commit --amend'.\n\n"},{"id":"297959","messageId":"Pine.LNX.4.63.0611300310520.30004@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"43105","inReplyTo":"7vk61dn2yj.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH 0/2] Making \"git commit\" to mean \"git commit -a\".","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-11-30T02:11:20Z","receivedAt":"2006-11-30T02:11:20Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 29 Nov 2006, Junio C Hamano wrote:\n\n> Junio C Hamano writes:\n> \n> > ... Rather,\n> > \"building your next commit incrementally in the index is the\n> > workflow git is designed to support, but you are not required to\n> > do that _incrementally_. Until you encounter a complex\n> > situation such as resolving a large conflicting merge, doing\n> > that incrementally does not buy you anything as long as you work\n> > in a clean working tree.\n> \n> Side note. I think the above \"Until...\" is an overstatement,\n> and maybe the readers of the tutorial can be taught a lot\n> earlier how the index can help them. Maybe the following\n> sequence can be added to an early part of the tutorial sequence?\n> \n> $ edit hello.c\n> $ make test\n> $ git diff\n> $ git update-index hello.c; # ok, that is good so far.\n> $ edit hello.c; # hack more\n> $ make test; # oops, does not work\n> $ git diff; # ah, that overeager edit broken what was good\n> $ git checkout hello.c; # get the last good one back\n\nI like it. Sort of a \"temporary commit\" to check against.\n\nCiao,\nDscho\n"},{"id":"294949","messageId":"7vejrln0n5.fsf@assigned-by-dhcp.cox.net","threadId":"43105","inReplyTo":"456E3AB7.1030306@midwinter.com","subject":"Re: [PATCH 0/2] Making \"git commit\" to mean \"git commit -a\".","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-30T02:12:14Z","receivedAt":"2006-11-30T02:12:14Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Steven Grimm writes:\n\n> But I'm still a relative n00b and would appreciate knowing if I'm just\n> missing some big obvious technique.\n\nYou are doing just fine. Using commits to do snapshot is\nanother workflow people often use. These people tend to do so\nin a work branch and cherry-pick the resulting series of commits\nonto more permanent branch while reorganizing and tidying up the\ndevelopment history to be published to the outside world.\n\n"},{"id":"295111","messageId":"Pine.LNX.4.64.0611291859070.3513@woody.osdl.org","threadId":"43105","inReplyTo":"Pine.LNX.4.63.0611300310520.30004@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH 0/2] Making \"git commit\" to mean \"git commit -a\".","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-11-30T03:10:47Z","receivedAt":"2006-11-30T03:10:47Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 30 Nov 2006, Johannes Schindelin wrote:\n> \n> I like it. Sort of a \"temporary commit\" to check against.\n\nI (very) occasionally do this for patches I get.\n\nYou can do\n\n\tgit-apply --index patch\n\nand it will apply the patch and update the index for you. That's great for \ncommitting the patch (because it means that it adds and removes your files \nautomatically for you), but most of the time when I get an email that I \nwant to apply, I just use \"git-applymbox\".\n\nSo where doing the \"git apply --index\" thing is great is when you see a \npatch that has some obvious deficiency that makes you not want to commit \nit directly, but add some fixup of your own.\n\nThat's when it's useful to use the index to your advantage - you can do \n\"git diff\" (to see just the fixups you did on top of the patch), or you \ncan do \"git diff HEAD\" (to see the combined effect of both the patch _and_ \nyour fixups).\n\nThat said, I have to admit that I usually (a) don't do this very often (ie \nthis is not part of my daily routine) and (b) I tend to do \"git reset\" \nfairly soon afterwards (or alternatively, just \"git commit -a\") to get \nback to the situation where the index will match the current HEAD 100% \nagain. So the \"index doesn't match HEAD\" situation is always just a \n_temporary_ thing for me.\n\n"},{"id":"293871","messageId":"m21wnlo6bj.fsf@ziti.fhcrc.org","threadId":"43105","inReplyTo":"7vlkluoulf.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH 0/2] Making \"git commit\" to mean \"git commit -a\".","fromName":"Seth Falcon","fromEmail":"sethfalcon@gmail.com","sentAt":"2006-11-30T05:24:16Z","receivedAt":"2006-11-30T05:24:16Z","isPatch":true,"sender":{"key":"sethfalcon@gmail.com","avatar":"https://gravatar.com/avatar/fd62fe73d3013b12fce71d5269ec52eaca3c4cee479efc6eea3603d6f1d8bf8d?d=mp&s=160"},"body":"Junio C Hamano writes:\n> My time is better spent on _listening_ to people who might want to\n> make convincing arguments to influence what I will end up deciding\n> (the final decision will be mine anyway).\n\nSo I will add my $0.02:\n\n Summary: leave git-commit as-is\n\n I think the intimidation factor of the index is overstated. A\n scratch working area is a natural concept -- that's what people do\n who don't even _know_ what an scm is. I agree with Junio's\n description of commit -a as default breaking the mental model.\n\n I've played with three distributed scm: tla, hg, and git. I've\n stuck with git because, in part, it helped me to learn its more\n advanced features -- not because it was easiest to use intially out\n of the box. And if I'm not going to get something more than cvs or\n svn gives me, what's the point of switching in the first place?\n\n\n + seth\n \n \n\n"},{"id":"295417","messageId":"Pine.LNX.4.63.0611301124260.30004@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"43105","inReplyTo":"Pine.LNX.4.64.0611291859070.3513@woody.osdl.org","subject":"Re: [PATCH 0/2] Making \"git commit\" to mean \"git commit -a\".","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-11-30T10:27:54Z","receivedAt":"2006-11-30T10:27:54Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 29 Nov 2006, Linus Torvalds wrote:\n\n> So where doing the \"git apply --index\" thing is great is when you see a \n> patch that has some obvious deficiency that makes you not want to commit \n> it directly, but add some fixup of your own.\n\nAn obvious deficiency would also be the presence of hundreds of debug \nquirks I had to introduce to find the bug which I finally fixed. But I do \nnot want to commit, because it is such a mess. So: into the index, ye \nfiles.\n\nNow I can clean up everything I introduced to find the bug. If the result \ndoes not work as expected? \"git diff\"!\n\nBut now that I cleaned up the mess, I find that there is a more elegant \nway to solve the problem. Into the index, ye files! Clicketyclick, if I \nmess up, I always have the state in the index!\n\nCiao,\nDscho\n"},{"id":"298634","messageId":"456EBBE7.8030404@op5.se","threadId":"43105","inReplyTo":"Pine.LNX.4.64.0611291859070.3513@woody.osdl.org","subject":"Re: [PATCH 0/2] Making \"git commit\" to mean \"git commit -a\".","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2006-11-30T11:09:27Z","receivedAt":"2006-11-30T11:09:27Z","isPatch":true,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Linus Torvalds wrote:\n> \n> That said, I have to admit that I usually (a) don't do this very often (ie \n> this is not part of my daily routine) and (b) I tend to do \"git reset\" \n> fairly soon afterwards (or alternatively, just \"git commit -a\") to get \n> back to the situation where the index will match the current HEAD 100% \n> again. So the \"index doesn't match HEAD\" situation is always just a \n> _temporary_ thing for me.\n> \n\nA staging area is per definition meant to keep temporary things before \nthey are committed to their designated place so there's nothing odd \nabout that.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\n"},{"id":"296095","messageId":"Pine.LNX.4.64.0611300749560.3513@woody.osdl.org","threadId":"43105","inReplyTo":"456EBBE7.8030404@op5.se","subject":"Re: [PATCH 0/2] Making \"git commit\" to mean \"git commit -a\".","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-11-30T15:58:09Z","receivedAt":"2006-11-30T15:58:09Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 30 Nov 2006, Andreas Ericsson wrote:\n\n> Linus Torvalds wrote:\n> > \n> > That said, I have to admit that I usually (a) don't do this very often (ie\n> > this is not part of my daily routine) and (b) I tend to do \"git reset\"\n> > fairly soon afterwards (or alternatively, just \"git commit -a\") to get back\n> > to the situation where the index will match the current HEAD 100% again. So\n> > the \"index doesn't match HEAD\" situation is always just a _temporary_ thing\n> > for me.\n> \n> A staging area is per definition meant to keep temporary things before they\n> are committed to their designated place so there's nothing odd about that.\n\nSure. It's just that some people seem to expect the index to be different \nfrom HEAD, and are afraid of being \"confused\" by it.\n\nThe fear seems to be about \"git diff\" getting different results from \"git \ndiff HEAD\", and always having to _check_ the two.\n\nSo I wanted to make it clear that I never have that situation, because I \nnever leave the index \"dirty\". I agree that there is nothing odd about it, \nbut I think that people who don't actively use the index (or don't use git \nat all, and just worry about it) see it as a kind of separate entity with \na life all its own.\n\nI can see that if you think the index is likely to be out of kilter with \nHEAD, you'd always worry about \"ok, so maybe the diff I get from 'git \ndiff' isn't the _true_ diff, so now I have to do _both_ 'git diff' and \n'git diff HEAD' to make sure I know what's up\".\n\nI just wanted to clarify that that is never the case for me, and I doubt \nanybody else really does it either. For a very complicated merge, I could \npossibly see somebody having a dirty index for a day or two and taking a \nbreak with the index dirty, but\n\n (a) I've certainly never seen that myself (and it would have to be \n something very messy indeed - I remember multi-day merges with CVS, \n but that was because CVS is so bad at merging, not because the merges \n per se would have been all that messy)\n\n (b) if you have a merge _that_ messy, I don't think you're likely to \n forget about it, and rather than be confused about the difference \n between 'git diff' and 'git diff HEAD', you'll be really really happy \n that you have some way of seeing just the _remaining_ pieces, rather \n than all the crud you already fixed up.\n\nIn other words, the fact that the index _normally_ matches the HEAD may be \nobvious, but it's also important - it's important to allay fears from \nnon-index users about it being somehow scary and confusing. It's not.\n\n"},{"id":"296448","messageId":"20061130164046.GB17715@thunk.org","threadId":"43105","inReplyTo":"Pine.LNX.4.64.0611300749560.3513@woody.osdl.org","subject":"Re: [PATCH 0/2] Making \"git commit\" to mean \"git commit -a\".","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2006-11-30T16:40:47Z","receivedAt":"2006-11-30T16:40:47Z","isPatch":true,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Thu, Nov 30, 2006 at 07:58:09AM -0800, Linus Torvalds wrote:\n> So I wanted to make it clear that I never have that situation, because I \n> never leave the index \"dirty\". I agree that there is nothing odd about it, \n> but I think that people who don't actively use the index (or don't use git \n> at all, and just worry about it) see it as a kind of separate entity with \n> a life all its own.\n\nWell, sure, because the documentation *talks* about it as a separate\nentity all its own. Just look at the man page for git-diff as a great\nexample of this, or the ascii art diagram of the index. It is all\ntechnically _correct_, but it is scary as all heck.\n\n> I can see that if you think the index is likely to be out of kilter with \n> HEAD, you'd always worry about \"ok, so maybe the diff I get from 'git \n> diff' isn't the _true_ diff, so now I have to do _both_ 'git diff' and \n> 'git diff HEAD' to make sure I know what's up\".\n> \n> I just wanted to clarify that that is never the case for me, and I doubt \n> anybody else really does it either. \n\nBut then why is the default for \"git commit\" to commit the index, if\nthe index is almost == HEAD? And why is git-update-index given such\nprominence in the documentation?\n\n> In other words, the fact that the index _normally_ matches the HEAD may be \n> obvious, but it's also important - it's important to allay fears from \n> non-index users about it being somehow scary and confusing. It's not.\n\nIf everyone agrees with this, I think it would be easier to make\nchanges to the documentation and maybe some UI tweaks about what the\ndefault might be.\n\nOne suggestion is that perhaps a mode where warns users when index !=\nHEAD for certain critical commands might not be a bad thing. That\nmight give users that are just graduating beyond novice git usage, and\njust starting to become aware of the index, reassurance because if\nthey *don't* see the warning message, they can rest assured that they\ndon't have to do both \"git diff\" and \"git diff HEAD\", for example.\n\n"},{"id":"296120","messageId":"Pine.LNX.4.64.0611300903080.3513@woody.osdl.org","threadId":"43105","inReplyTo":"20061130164046.GB17715@thunk.org","subject":"Re: [PATCH 0/2] Making \"git commit\" to mean \"git commit -a\".","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-11-30T17:13:52Z","receivedAt":"2006-11-30T17:13:52Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 30 Nov 2006, Theodore Tso wrote:\n>\n> But then why is the default for \"git commit\" to commit the index, if\n> the index is almost == HEAD? And why is git-update-index given such\n> prominence in the documentation?\n\nThe default is: commit everything that you ask for to be committed.\n\nIf you haven't marked anything to be committed (which you can do with \"git \nadd\" too, or with simply being in the middle of a merge, or by having done \nsomething like \"git pull -n\" or similar that does everything _but_ \ncommit), then git commit will say \"nothing to do\".\n\nIt has NOTHING to do with the index per se. \n\nI still don't understand why people are so hung up about the index.\n\nSo ignore the index entirely, and follow along with me:\n\n\t\"git commit\" with no parameters simply DOES NOT DO ANYTHING YOU \n\tHAVEN'T ALREADY ASKED YOU TO DO.\n\nIt's that simple. It's that logical. Ignore the index. Ignore everything \nelse. Just read that simple, straightforward, and logical sentence on its \nown. It all makes sense.\n\nThen, the trivial follow-up is:\n\n\tIf you want to commit _all_ dirty files, use \"git commit -a\". \n\tOtherwise, name the files or subdirectories you want to commit \n\texplicitly.\n\nAgain: THIS JUST MAKES SENSE.\n\nAsking for \"-a\" to be the default behaviour is BAD.\n\nFor example, in \"git commit --amend\", it's _important_ that \"-a\" not be \nthe default, because you may well want to just amend the commit _message_. \nNo files updated AT ALL. You may have other state that is still dirty \n(because you didn't ask it to be committed last time), and they should NOT \nbe committed, because the simple rule is:\n\n\t\"git commit\" with no parameters simply DOES NOT DO ANYTHING YOU \n\tHAVEN'T ALREADY ASKED YOU TO DO.\n\nRepeat the above sentence again. IT JUST MAKES SENSE.\n\nSo maybe the documentation shouldn't mention the \"index\" at all, because \nit apparently scares and confuses people. But the fact is, the \ndocumentation started out as _technical_ documentation, that explains the \n_technical_ side of git. We don't have lots of \"end-user\" docs. \n\nBut the lack of such end-user documentation should not cause idiotic \nthreads like this, where people blame \"the index\". \n\nYeah, so the docs are too scary. But none of this has anything to do with \n\"the index\". It's all logical on its own, and the default behaviour to not \ncommit anything you haven't asked to be committed is the right one.\n\nMake \"git commit\" just say \"You didn't say what you wanted to commit. \nMaybe you meant 'git commit -a'\" if there's nothing to commit. How hard \ncan that be? But don't change semantics now, and please DO NOT change them \nto something _worse_ than what we have now (and automatically adding the \n\"-a\" only in _certain_ circumstances is definitely much worse imnsho)\n\n"},{"id":"297900","messageId":"Pine.LNX.4.64.0611301229290.9647@xanadu.home","threadId":"43105","inReplyTo":"Pine.LNX.4.64.0611300903080.3513@woody.osdl.org","subject":"Re: [PATCH 0/2] Making \"git commit\" to mean \"git commit -a\".","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2006-11-30T17:37:49Z","receivedAt":"2006-11-30T17:37:49Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Thu, 30 Nov 2006, Linus Torvalds wrote:\n\n> The default is: commit everything that you ask for to be committed.\n> \n> If you haven't marked anything to be committed (which you can do with \"git \n> add\" too, or with simply being in the middle of a merge, or by having done \n> something like \"git pull -n\" or similar that does everything _but_ \n> commit), then git commit will say \"nothing to do\".\n\nMight it be a good idea to have \"git-add\" do the same as \n\"git-update-index\" on already tracked files? That could be easily \ntaught as \"you must explicitly _add_ files to your next commit\" and \nwhether the file is already tracked or not wouldn't matter. This would \nhelp newbies actually getting used the index without mentioning the \ndreaded word \"index\" at all.\n\nRight now git-add on an already tracked file does nothing, not even a \nmessage to say it did nothing.\n\n\n"},{"id":"295037","messageId":"87k61cu7qe.wl%cworth@cworth.org","threadId":"43105","inReplyTo":"Pine.LNX.4.64.0611300903080.3513@woody.osdl.org","subject":"Re: [PATCH 0/2] Making \"git commit\" to mean \"git commit -a\".","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2006-11-30T18:09:29Z","receivedAt":"2006-11-30T18:09:29Z","isPatch":true,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Thu, 30 Nov 2006 09:13:52 -0800 (PST), Linus Torvalds wrote:\n> On Thu, 30 Nov 2006, Theodore Tso wrote:\n> >\n> > But then why is the default for \"git commit\" to commit the index, if\n> > the index is almost == HEAD? And why is git-update-index given such\n> > prominence in the documentation?\n>\n> The default is: commit everything that you ask for to be committed.\n...\n> It has NOTHING to do with the index per se.\n\nOK. I'll try to not mention the \"index\" any more in any postings\nhere.\n\nAnd can we agree that any time git spits out a message directing the\nuser to use update-index that that's a (minor) user-interface wart?\n\n> \t\"git commit\" with no parameters simply DOES NOT DO ANYTHING YOU\n> \tHAVEN'T ALREADY ASKED YOU TO DO.\n\nI think the response that would come from the people that are confused\nis:\n\n\t\"But I told git I wanted to track this file when I said 'git\n\tadd' long ago. Why is it making me tell it again.\"\n\nAs you mentioned, all systems have _some_ mechanism for keeping track\nof the files to be committed, (and git's is only unique in having a\nname and providing more functionality for direct manipulation and lots\nof extra information in the case of a merge conflict).\n\nBut I think most every system out there _except_ git default to a\nstate of committing every file it \"knows\" about as it exists in the\nworking tree, and then allowing the user to restrict that behavior to\nsome subset of the files.\n\nGit allows the same subsetting, and has behavior that is very similar\nto these other systems when the user provides a list of files.\n\nGit also provides a unique mode in that users can \"stage\" file state\nto be committed later in spite of subsequent different changes being\nmade to the same files in the working tree that won't be\ncommitted. Some git users love this functionality. But mentioning it\nto new users does scare them off to some extent, (\"Why would I _want_\nto do that?\", \"What if that happens accidentally?\").\n\nAnd I think one thing that happens is that the current defaults\nnaturally lead users to hear about this \"scary\" functionality, even if\nthe presenter, (whether a human or printed documentation), isn't\ntrying to go that direction:\n\nPresenter:\tSo use \"git commit -a\" here.\n\nNew user:\tWhy -a?\n\nPresenter:\tTo tell git that you want to commit all files rather\n\t\tthan having to list them all on the command line.\n\nNew user:\tWhy not just \"git commit\" for that then?\n\nPresenter:\tBecause that's something else.\n\nNew user:\tWhat's that?\n\nPresenter: \tIt lets you stage things---stuff you think is ready to\n\t\tcommit, but when you want to delay that commit until\n\t\tafter making other changes to the files that you don't\n\t\twant to commit.\n\nNew user:\tWhat? Really? That's bizarre.\n\nPresenter:\tIt can be useful in some situations. But for now,\n\t\tjust use \"commit -a\" and it will do what you want.\n\nAnd at this point the user either trusts me, accepts it, gives git a\ntry and falls in love, or the user gives up and uses something else.\n\nI think the above accurately captures the essence of actual\nconversations I've had with new new users. And I'd be glad to take\nsuggestions on how to improve what I say here. But it's that feeling\nof \"git is bizarre\" that I'd like to reduce, and I'd like to improve\nthe success rate of the conversation, (though I think I've done pretty\nwell for people that trust me).\n\nAnd note that the same kind of conversation happens when using git\ndirectly with tutorials and man pages, but without a human\npresenter. Only, there the conversation is much worse. First, it's\nharder to pull off \"just trust me and give it a try\" in technical\ndocumentation. Second, the documentation does not do a good job of\nletting the user know when they're getting more technical information\nthan they need.\n\nFor example, there's \"git status\", (used by \"git commit\"), that\ndirects the user to \"git update-index\". Then there's the documentation\nof git-commit that says \"Updates the index file...and makes a commit\nobject.\"\n\nAnd so far my best response to those problems is to short-cut them by\nimproving the defaults of git-commit, (the documentation should be\nimproved too, and I did submit a patch to get \"update-index\" out of\ngit-status output for example).\n\nAnyway, I'm repeating myself on some of these details, but only\nbecause some people still haven't seemed to grasp the real, new-user\nconfusion that arises here.\n\nThat's really what I'm trying to reduce with all the talk about\n\"commit all known files by default\".\n\n> \t\"git commit\" with no parameters simply DOES NOT DO ANYTHING YOU\n> \tHAVEN'T ALREADY ASKED YOU TO DO.\n>\n> Repeat the above sentence again. IT JUST MAKES SENSE.\n\nYes. And it makes sense for the user to be able to say \"unless I tell\nyou differently, I want to always commit the working-tree state of\n with every commit\".\n\n-Carl\n"},{"id":"293991","messageId":"Pine.LNX.4.64.0611301026060.3513@woody.osdl.org","threadId":"43105","inReplyTo":"87k61cu7qe.wl%cworth@cworth.org","subject":"Re: [PATCH 0/2] Making \"git commit\" to mean \"git commit -a\".","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-11-30T18:33:12Z","receivedAt":"2006-11-30T18:33:12Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 30 Nov 2006, Carl Worth wrote:\n> >\n> > Repeat the above sentence again. IT JUST MAKES SENSE.\n> \n> Yes. And it makes sense for the user to be able to say \"unless I tell\n> you differently, I want to always commit the working-tree state of\n> with every commit\".\n\nIf so, you should make it a special case.\n\nI refuse to believe in the \"people who know what the hell they are doing \nshould work more at it\" philosophy.\n\nThe \"git commit -a\" behaviour as it is now is better than the \nalternatives, exactly because it's more flexible. It _allows_ you to not \ncommit anything at all (and as already mentioned, there are cases where \nthat is exactly what you want).\n\nIf you want to have a \"-a by default\", then that you require _you_ to do \nmore work, and no, it's NOT an excuse to say \"I'm a clueless newbie, and I \ndon't know how to set a config option, so I think it's the smart and \nbeautiful people who should suffer for my shortcomings\".\n\nYou can even do it by doing an alias like\n\n\t[alias]\n\t\tci = commit -a\n\nand then you can revel in your CVS-induced mudpit all you want. Just \ndon't try to convince people who have gotten over that braindamage to live \nin the same muck with you.\n\nProblem solved. For all I care, we can make that alias a default one, so \npeople who just can't get their mind out of the gutter that is CVS can \ncontinue with their evil ways.\n\n"},{"id":"297399","messageId":"87irgwu6e6.wl%cworth@cworth.org","threadId":"43105","inReplyTo":"Pine.LNX.4.64.0611301229290.9647@xanadu.home","subject":"Re: [PATCH 0/2] Making \"git commit\" to mean \"git commit -a\".","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2006-11-30T18:38:25Z","receivedAt":"2006-11-30T18:38:25Z","isPatch":true,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Thu, 30 Nov 2006 12:37:49 -0500 (EST), Nicolas Pitre wrote:\n> Might it be a good idea to have \"git-add\" do the same as\n> \"git-update-index\" on already tracked files? That could be easily\n> taught as \"you must explicitly _add_ files to your next commit\"\n\nI think this is worth doing, but it doesn't solve the problem.\n\nIt would be nice if this worked, because then it would be natural to\nteach users to \"git add\" their changes, and then when the obvious\ncomplaint about that being annoying to type all the time, then respond\nby teaching \"git commit -a\" as a shortcut. That would be very natural.\n\nBut this doesn't quite work. Here's a major \"index is confusing\"\nscenario that I first hit on my first exposure to git, (it was so long\nago that I completely forgot about it when when Linus asked what the\nbig deal is about the index).\n\nIt's all about the fine details of what \"git add\" does that can be\n_extremely_ surprising to new users. Here's a simple scenario:\n\n\t$ git init-db\n\tdefaulting to local storage area\n\t$ echo \"hello wurld\" > hello\n\t$ git add hello\n\n\t# Oops! Look at that typo.\n\n\t$ echo \"hello world\" > hello\n\t$ git commit -m \"add hello\"\n\tCommitting initial tree 0267c1bf2956b3df47851e0163f2ea86c002379d\n\t$ git diff\n\tdiff --git a/hello b/hello\n\tindex b1df5e6..3b18e51 100644\n\t--- a/hello\n\t+++ b/hello\n\t@@ -1 +1 @@\n\t-hello wurld\n\t+hello world\n\nAnd here the new user reaction is \"What?! I fixed that before I\nmade the commit! What kind of broken system is this.\"\n\nThe above example is not at all surprising to someone who understands\nthe index. And it's that \"why should that behavior be confusing\"\ndisconnect that I'm trying to bridge here. Can you see why the above\nconfuses new users?\n\nIn most other systems I've used, 'add' means \"I want the system to\n'know' about this file\" while 'commit' means \"Please commit the\ncurrent state of all files you 'know' about (or the ones I mention\nhere on the command line)\".\n\nThe current semantics do nothing to avoid this \"interaction bug\" and\nthere is no way to explain it to the user without going through an\n\"explanation of the index\" and the user is left to decide that the\nindex is just there to help make broken commits.\n\nSo, I'd love for \"git add\" to be a shorter way to type \"update-index\",\n(I have been campaigning for eliminating hyphens after all), but\nwithout different semantics _somewhere_ the default behavior still is\npotentially very confusing. The \"ignore the index\" stance Linus has\nbeen proposing recently just doesn't work here.\n\nAnd all of this contributes to make git harder to learn than it should\nbe.\n\n-Carl\n\nPS. It was actually \"hard\" for me to create that example above. The\nfirst time I ran through the commands I ended up with an empty diff at\nthe end. \"Huh? I _know_ that git does surprising things here.\" That\nwas because I was using Junio's \"commit -a\" patch which did right\nthing rather than demonstrating the old wrong behavior I was trying to\ndemonstrate.\n"},{"id":"298667","messageId":"ekn8s3$lh6$1@sea.gmane.org","threadId":"43105","inReplyTo":"87irgwu6e6.wl%cworth@cworth.org","subject":"Re: [PATCH 0/2] Making \"git commit\" to mean \"git commit -a\".","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-11-30T18:47:16Z","receivedAt":"2006-11-30T18:47:16Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Carl Worth wrote:\n\n> In most other systems I've used, 'add' means \"I want the system to\n> 'know' about this file\" while 'commit' means \"Please commit the\n> current state of all files you 'know' about (or the ones I mention\n> here on the command line)\".\n\nwhile in git \"git add\" means \"I want to add this file\" (in the state\nit is now) and not \"I want the system to 'know' about this file\".\nAnd \"commit\" mean \"Please commit the current 'known' state of all\nfiles (or/and the current state of files I mention here on the\ncomand line)\".\n\nYes, this is different than what other SCM do...\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"},{"id":"296429","messageId":"87hcwgu5t1.wl%cworth@cworth.org","threadId":"43105","inReplyTo":"87irgwu6e6.wl%cworth@cworth.org","subject":"Re: [PATCH 0/2] Making \"git commit\" to mean \"git commit -a\".","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2006-11-30T18:51:06Z","receivedAt":"2006-11-30T18:51:06Z","isPatch":true,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Thu, 30 Nov 2006 10:38:25 -0800, Carl Worth wrote:\n> And it's that \"why should that behavior be confusing\"\n> disconnect that I'm trying to bridge here. Can you see why the above\n> confuses new users?\n\nBy the way, I think I've said all I can in this thread.\n\nIf the \"create file; git add; edit file; git commit\" confusion isn't\nblisteringly obvious to the git maintainers then I think I have to\ngive up here.\n\nAnd this isn't just CVS-induced brain damage. It's the user being\nrequired to mentally juggle 3 states for the file, (the last\n\"committed\" state, the current \"working tree\" state, and this\n\"something else\" state). The sequence above, (which is very natural),\nexposes this \"something else\" state that to a new user.\n\nIf we imagine a new user as coming, not from cvs, but coming from\nno revision control system, then it's less confusing to add one single\nnew state, (the \"last committed\" state), in addition to the \"working\ntree\" state the user is familiar with.\n\nForcing the user to learn two instead of one is just plain harder,\n(which is completely separate from git _allowing_ this extra state\nonce you learn it).\n\nSo if git is determined to just be harder to learn this way, then I\ndon't know what more I can do to help here.\n\nI love git, and I think everyone should use it. I would just like to\nhelp make it a bit easier for people to do that.\n\n-Carl\n"},{"id":"294726","messageId":"87fyc0u56z.wl%cworth@cworth.org","threadId":"43105","inReplyTo":"ekn8s3$lh6$1@sea.gmane.org","subject":"Re: [PATCH 0/2] Making \"git commit\" to mean \"git commit -a\".","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2006-11-30T19:04:20Z","receivedAt":"2006-11-30T19:04:20Z","isPatch":true,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Thu, 30 Nov 2006 19:47:16 +0100, Jakub Narebski wrote:\n> while in git \"git add\" means \"I want to add this file\" (in the state\n> it is now) and not \"I want the system to 'know' about this file\".\n> And \"commit\" mean \"Please commit the current 'known' state of all\n> files (or/and the current state of files I mention here on the\n> comand line)\".\n\nYes. There is a logical explanation for what git does, and it is\nself-consistent.\n\nIt just means that the user is _forced_ to pass file state across the:\n\n\t\"working tree\" -> git\n\nboundary at two different times with two different commands for the\nvery first commit the user makes. And the user _must_ understand that\nthis is a two-step process, (even though, without the \"typo\" in my\nexample above it would be natural to conclude the transition occurred\nonly during \"commit\").\n\nSee? Git _is_ harder to learn, and a user really cannot learn it\nwithout being careful about the index right from the very beginning.\n\n-Carl\n"},{"id":"298437","messageId":"Pine.LNX.4.64.0611301132350.3513@woody.osdl.org","threadId":"43105","inReplyTo":"87hcwgu5t1.wl%cworth@cworth.org","subject":"Re: [PATCH 0/2] Making \"git commit\" to mean \"git commit -a\".","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-11-30T19:55:30Z","receivedAt":"2006-11-30T19:55:30Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 30 Nov 2006, Carl Worth wrote:\n> \n> If the \"create file; git add; edit file; git commit\" confusion isn't\n> blisteringly obvious to the git maintainers then I think I have to\n> give up here.\n> \n> And this isn't just CVS-induced brain damage.\n\nI'm sorry, but you are wrong.\n\nIt really _is_ CVS-induced brain damage, and I'm trying to teach you. You \ncan give up, but that's really \"refuse to see the damage that systems like \nRCS and CVS has done to the world\"\n\nThe fundamental brain damage that CVS (and RCS, and SVN, and just about \nanything else) has had is thinking that \"filenames\" (and sometimes this is \n\"fixed\" to be \"file ID's\") are somehow special, and a totally separate \nthing from \"file contents\".\n\nReally. It's a BUG. It's a deficiency in CVS and friends. And it's a \ndeficiency that you have gotten so used to that you don't even see that \nit's simply obviously NOT TRUE.\n\nYou _cannot_ have a filename without the contents of that filename. That \nwhole concept doesn't make sense, except in the twisted AND WRONG mental \nmodel of \"files have identities even without content\".\n\nThe whole point of git is that it is about \"project state\" and the history \nthat binds those states together. People have kind of come to accept that, \nand a lot of people realize what it means, but I don't think you've really \naccepted what it means for something as simple as a \"git add\" command.\n\nAgain, totally ignore the index. Imagine that it doesn't exist. Imagine \nthat you never actually learnt about it, and that none of the \ndocumentation ever mentions it, and just ask yourself:\n\n\t\"What does 'adding a file' really mean?\"\n\nI mean _really_. It cannot be about the \"filename\", because a filename \nsimply doesn't have any meaning alone. Remember what git is all about.\n\nNo, when you do a \"git add\", YOU DO NOT TALK ABOUT FILENAMES AT ALL.\n\n\tNOT EVEN CLOSE!\n\nNo. Git is, and has always been, all about tracking project content. The \nfact that CVS is crap, and thinks that \"filenames\" are special (and this \ncauses major problems when you do renames), and the fact that SVN is crap, \nand things that \"file identities\" are special (and this causes major \nproblems when you split a file or when two files join) is very much about \nTHEIR F*CKING IDIOTIC FUNDAMENTAL BRAINDAMAGE!\n\nSo take five minutes to really think about that. Take an hour. Take a \nweek. Ponder it.\n\nWhat does it mean to \"add\" something to a project? It has _nothing_ to do \nwith \"filenames\". Yeah, the filename obviously exists, but it's not \nsomething that exists on its own. You add the ONLY thing that git tracks. \n\nYou add CONTENT.\n\nWhen you do \"git add file.c\" you aren't adding a filename to the list of \nfiles that git knows about. Not even CLOSE. No. You are really adding \n_content_ to the project you are tracking. You haven't bound it to a \ncommit yet, but it's there. It's there both conceptually, and very much in \na real technical sense too (you've literally added the git object that \nthat file describes to the object database - the \"commit\" and \"tree\" \nobjects to tie it all together is just waiting to be added, but they \nreally just expose it - the actual file object has already been created \nwhen you do \"git add\".)\n\nSo yes, you very much ARE talking about CVS braindamage. The reason why\n\n\tgit add file.c\n\techo New line >> file.c\n\tgit commit\n\ncommits the _old_ content, is very much because git is ALL ABOUT THE \nCONTENT. It has _never_ been about filenames. And it _shouldn't_ be about \nfilenames, because that would be BUGGY AND BROKEN.\n\nSorry for shouting, but as long as you think \"git add\" adds a filename, \nyou're just not getting it. And I think it's really sad that you don't \neven seem to understand that yes, this _is_ braindamage that has been \nforced upon you by decades of mental rape done by bad source control \nsystems.\n\nPlease. File identities are _bad_ in the SVN kind of setting. The CVS kind \nof \"filename == file identity\" is even _worse_, but it's still exactly the \nsame disease. It's the disease of thinking that metadata is somehow \n\"different\" from real data, and that \"files\" have identities that are \nsomehow separate from the data they contain.\n\nFace it, git is consistent, and if it acted the way you seem to expect it \nto act, it would actually be a BUG. Exactly because you cannot and MUST \nNOT think that \"filename\" is something that has meaning without \"file \ncontent\" (or \"file type\" and \"file permissions\" - they all go together).\n\nAnd notice? NONE OF THIS HAS ANYTHING AT ALL TO DO WITH 'INDEX'!! The \nexplanation above is not \"this is how the index works\". It's a much more \nfundamnetal issue of getting the right mental model, where the only thing \nthat matters is contents.\n\nSo even without an index, \"git add\" should work the way it works, once you \ncan just let go of the broken model that is CVS.\n\nPlease. Join me, Luke. The power of the git side is stronger. I am your \nfather. \n\n"},{"id":"296699","messageId":"Pine.LNX.4.64.0611301521320.9647@xanadu.home","threadId":"43105","inReplyTo":"Pine.LNX.4.64.0611301132350.3513@woody.osdl.org","subject":"Re: [PATCH 0/2] Making \"git commit\" to mean \"git commit -a\".","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2006-11-30T20:47:20Z","receivedAt":"2006-11-30T20:47:20Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Thu, 30 Nov 2006, Linus Torvalds wrote:\n\n> What does it mean to \"add\" something to a project? It has _nothing_ to do \n> with \"filenames\". Yeah, the filename obviously exists, but it's not \n> something that exists on its own. You add the ONLY thing that git tracks. \n> \n> You add CONTENT.\n> \n> When you do \"git add file.c\" you aren't adding a filename to the list of \n> files that git knows about. Not even CLOSE. No. You are really adding \n> _content_ to the project you are tracking. You haven't bound it to a \n> commit yet, but it's there. It's there both conceptually, and very much in \n> a real technical sense too (you've literally added the git object that \n> that file describes to the object database - the \"commit\" and \"tree\" \n> objects to tie it all together is just waiting to be added, but they \n> really just expose it - the actual file object has already been created \n> when you do \"git add\".)\n> \n> So yes, you very much ARE talking about CVS braindamage. The reason why\n> \n> \tgit add file.c\n> \techo New line >> file.c\n> \tgit commit\n> \n> commits the _old_ content, is very much because git is ALL ABOUT THE \n> CONTENT. It has _never_ been about filenames. And it _shouldn't_ be about \n> filenames, because that would be BUGGY AND BROKEN.\n\nGreat. But let me repeat my last question:\n\nWould it make sense for \"git add\" to do the same as \"git update-index\" \non already tracked files? Given the explanation above this would make \n100% sense to me.\n\nEven for newbies this might help them understand the power of the index \nwith only one command. \"You _add_ your changes together before you may \ncommit.\" That's simple to understand even for newbies. And then \nthey'll start using the power of the index even without realizing it.\n\nBut right now, doing \"git add\" on an already tracked file simply does \nnothing. This is even worse than erroring out.\n\n\n"},{"id":"297865","messageId":"Pine.LNX.4.64.0611301253380.3513@woody.osdl.org","threadId":"43105","inReplyTo":"Pine.LNX.4.64.0611301521320.9647@xanadu.home","subject":"Re: [PATCH 0/2] Making \"git commit\" to mean \"git commit -a\".","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-11-30T21:03:19Z","receivedAt":"2006-11-30T21:03:19Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 30 Nov 2006, Nicolas Pitre wrote:\n> \n> Would it make sense for \"git add\" to do the same as \"git update-index\" \n> on already tracked files? Given the explanation above this would make \n> 100% sense to me.\n\nYeah, I think it would probably make sense. I also think it would make \nsense to rename \"update-index\" entirely, or at least offer other names for \nit (ie the \"git resolved\" suggestion).\n\nIn short - I agree that it's all just facets of the same thing: telling \ngit that some part of the working tree is now in a state ready to be \ncommitted. Whether it's because we want to \"add\" content, or just mark it \nas no longer having conflicts, or any other reason.\n\n> But right now, doing \"git add\" on an already tracked file simply does \n> nothing. This is even worse than erroring out.\n\nYeah, that's arguably a stupid thing to do (\"you already added it, what do \nyou want me to do?\") but the choice we use is probably the worst of the \nthree straightforward possibilities (ignore, update or error).\n\nThe _original_ \"git add\" was literally just this one-liner:\n\n\t#!/bin/sh\n\tgit-update-index --add -- \"$@\"\n\nwhich actually was better in this respect (it updated the content), but \nthat didn't do sub-directories, so this is arguable a bug introduced by \ncommit 37539fbd: \n\n [PATCH] Improved \"git add\"\n\n This fixes everybodys favourite complaint about \"git add\", namely that it\n doesn't take directories.\n\nwhich started using \n\n\tgit-ls-files --others -z -- \"$@\"\n\ntogether with the exclude files to generate the list of files to add. At \nthat point, we lost files that already existed (since \"--others\" specifies \njust files we don't know about).\n\n"},{"id":"295549","messageId":"eknhjr$nce$1@sea.gmane.org","threadId":"43105","inReplyTo":"Pine.LNX.4.64.0611301253380.3513@woody.osdl.org","subject":"Re: [PATCH 0/2] Making \"git commit\" to mean \"git commit -a\".","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-11-30T21:16:29Z","receivedAt":"2006-11-30T21:16:29Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Linus Torvalds wrote:\n\n> The _original_ \"git add\" was literally just this one-liner:\n> \n>         #!/bin/sh\n>         git-update-index --add -- \"$@\"\n> \n> which actually was better in this respect (it updated the content), but \n> that didn't do sub-directories, so this is arguable a bug introduced by \n> commit 37539fbd: \n> \n>     [PATCH] Improved \"git add\"\n> \n>     This fixes everybodys favourite complaint about \"git add\", namely that it\n>     doesn't take directories.\n> \n> which started using \n> \n>         git-ls-files --others -z -- \"$@\"\n> \n> together with the exclude files to generate the list of files to add. At \n> that point, we lost files that already existed (since \"--others\" specifies \n> just files we don't know about).\n\nSo should we use then\n\n git-ls-files --cached --others -z -- \"$@\"\n\nin git-add?\n\nI'm very much for having git-add, -rm, -mv and -resolved as porcelain\nwrappers around git update-index, so there would be even less events\nwhen you have to use this plumbish command directly.\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"},{"id":"294635","messageId":"7vhcwgiqer.fsf@assigned-by-dhcp.cox.net","threadId":"43105","inReplyTo":"Pine.LNX.4.64.0611301521320.9647@xanadu.home","subject":"Re: [PATCH 0/2] Making \"git commit\" to mean \"git commit -a\".","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-30T21:19:08Z","receivedAt":"2006-11-30T21:19:08Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nicolas Pitre writes:\n\n> ... But let me repeat my last question:\n>\n> Would it make sense for \"git add\" to do the same as \"git update-index\" \n> on already tracked files? Given the explanation above this would make \n> 100% sense to me.\n\nI think this makes sense and what we did in the original \"git\nadd\".\n"},{"id":"296019","messageId":"456F4E38.50001@codeweavers.com","threadId":"43105","inReplyTo":"87hcwgu5t1.wl%cworth@cworth.org","subject":"Re: [PATCH 0/2] Making \"git commit\" to mean \"git commit -a\".","fromName":"Robert Shearman","fromEmail":"rob@codeweavers.com","sentAt":"2006-11-30T21:33:44Z","receivedAt":"2006-11-30T21:33:44Z","isPatch":true,"sender":{"key":"robertshearman@gmail.com","avatar":null},"body":"Carl Worth wrote:\n> If the \"create file; git add; edit file; git commit\" confusion isn't\n> blisteringly obvious to the git maintainers then I think I have to\n> give up here.\n>\n> And this isn't just CVS-induced brain damage. It's the user being\n> required to mentally juggle 3 states for the file, (the last\n> \"committed\" state, the current \"working tree\" state, and this\n> \"something else\" state). The sequence above, (which is very natural),\n> exposes this \"something else\" state that to a new user.\n> \n\nExactly. We had a tutorial for the project I contribute to (admittedly \nthe initial users were all used to how CVS worked) and while a number of \npeople got the concept of the index and were fairly happy with it, it \ndid add to the confusion of the tutorial, so now it doesn't mention the \nindex at all.\n\nThe tutorial introduced it as a staging area for commits, but the \ntrouble is that once you work like this you have to remember that \n\"git-diff\" won't show you what will be committed, so you have to use \n\"git-diff-index\" as well. If you get them mixed up then you end up \ncommitting the wrong thing.\n\nHere's a selected list of the commands introduced in the tutorial, \nwithout mentioning the index:\ngit diff\ngit commit -a\ngit commit \ngit reset HEAD^\ngit cherry-pick\n\nHere would be the same entries, but introducing the index too:\ngit-update-index\ngit diff\ngit diff-index\ngit commit\ngit commit -a\ngit commit \ngit reset HEAD^\ngit reset --soft HEAD^\ngit cherry-pick\ngit cherry-pick -n\n\nThe tutorial then goes from having ~12 common commands to learn up to ~17.\n\n> If we imagine a new user as coming, not from cvs, but coming from\n> no revision control system, then it's less confusing to add one single\n> new state, (the \"last committed\" state), in addition to the \"working\n> tree\" state the user is familiar with.\n>\n> Forcing the user to learn two instead of one is just plain harder,\n> (which is completely separate from git _allowing_ this extra state\n> once you learn it).\n\nHaving the index exposed for even simple operations means that the user \nhas to initially learn three states instead of two. The worst thing \nabout the index is that it is a limbo state. The committed content is in \nthe history and can be viewed by gitk (and other tools that the user \nwill be introduced to later) and the working tree is exactly what the \nuser sees in their editor. Having a hidden state isn't very good from an \nHCI point of view.\n\nOnce you understand the concept of the index, it is very useful. \nHowever, new users should be shielded from it if at all possible.\n\nI'm not advocating making \"git-commit\" equal to \"git-commit -a\" as I've \nbeen frustrated by command's semantics changing in git before. I can \nunderstand long-time git users would automatically try to use \n\"git-commit\" to just commit their index and get annoyed if it did \nsomething unexpected. Therefore, I would advocate there being no default \nbehaviour for \"git-commit\" except for displaying a help message, and \nmaking previous \"git-commit\" users now use \"git-commit -i\".\n\n-- \nRob Shearman\n"},{"id":"296803","messageId":"878xhsty3t.wl%cworth@cworth.org","threadId":"43105","inReplyTo":"eknhjr$nce$1@sea.gmane.org","subject":"Re: [PATCH 0/2] Making \"git commit\" to mean \"git commit -a\".","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2006-11-30T21:37:26Z","receivedAt":"2006-11-30T21:37:26Z","isPatch":true,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Thu, 30 Nov 2006 Linus Torvalds wrote:\n> On Thu, 30 Nov 2006, Nicolas Pitre wrote:\n> >\n> > Would it make sense for \"git add\" to do the same as \"git update-index\"\n> > on already tracked files? Given the explanation above this would make\n> > 100% sense to me.\n>\n> Yeah, I think it would probably make sense. I also think it would make\n> sense to rename \"update-index\" entirely, or at least offer other names for\n> it (ie the \"git resolved\" suggestion).\n\nOn Thu, 30 Nov 2006 22:16:29 +0100, Jakub Narebski wrote:\n> I'm very much for having git-add, -rm, -mv and -resolved as porcelain\n> wrappers around git update-index, so there would be even less events\n> when you have to use this plumbish command directly.\n\nI'm happy with the direction of having several commands that take the\nplace of update-index, each with its own name oriented toward what the\nuser wants to do.\n\nObviously, \"add\", \"mv\", and \"rm\" have obvious places where the user\nwants to use them.\n\nThere's the merge case where \"resolve\" and \"resolved\" have both been\nfloated as possible names.\n\nIt might even make sense to invent one more name for the case where\nthe user wants to inform git that a file has been edited and that git\nshould accept the new contents. It's the sort of \"note that file is\nedited\" operation that could be recommended to the user with \"add; fix\ntypo; commit\" confusion.\n\nSure, \"add\" could be used again, and \"update-index\" clearly _works_\nbut it's a rather ugly name, (and already has \"plumbing\" functionality\nlike --add and --remove that we don't want here).\n\nIf \"resolved\" is the name for the new command, then \"edited\" might\nwork, but I think these adjectives don't work well next to the more\nactive verbs that git normally accepts, (and yes, \"mv\" and \"rm\" are\nverbs even if horribly mangled spellings).\n\nSo I'd vote for \"resolve\" along with something else for the\nmark-as-edited case. Maybe \"refresh\"? That's the best I've thought of\nso far. Anyone else have a better suggestion? It does clash with the\nseparate notion of \"git update-index --refresh\" which is a bit\nannoying. Any other suggestions for this?\n\n-Carl\n"},{"id":"294708","messageId":"f2b55d220611301341n45c45506rca312dfa8ee6f795@mail.gmail.com","threadId":"43105","inReplyTo":"878xhsty3t.wl%cworth@cworth.org","subject":"Re: [PATCH 0/2] Making \"git commit\" to mean \"git commit -a\".","fromName":"Michael K. Edwards","fromEmail":"medwards.linux@gmail.com","sentAt":"2006-11-30T21:41:37Z","receivedAt":"2006-11-30T21:41:37Z","isPatch":true,"sender":{"key":"medwards.linux@gmail.com","avatar":null},"body":"On 11/30/06, Carl Worth wrote:\n> So I'd vote for \"resolve\" along with something else for the\n> mark-as-edited case. Maybe \"refresh\"? That's the best I've thought of\n> so far. Anyone else have a better suggestion? It does clash with the\n> separate notion of \"git update-index --refresh\" which is a bit\n> annoying. Any other suggestions for this?\n\ngit mark\n\nand git add becomes just a synonym for git mark.\n\nCheers,\n"},{"id":"295402","messageId":"eknj33$q2r$1@sea.gmane.org","threadId":"43105","inReplyTo":"456F4E38.50001@codeweavers.com","subject":"Re: [PATCH 0/2] Making \"git commit\" to mean \"git commit -a\".","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-11-30T21:41:41Z","receivedAt":"2006-11-30T21:41:41Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Robert Shearman wrote:\n\n> Having the index exposed for even simple operations means that the user \n> has to initially learn three states instead of two. The worst thing \n> about the index is that it is a limbo state. The committed content is in \n> the history and can be viewed by gitk (and other tools that the user \n> will be introduced to later) and the working tree is exactly what the \n> user sees in their editor. Having a hidden state isn't very good from an \n> HCI point of view.\n\nIndex is accessible, just like committed contents. The fact that gitk, qgit,\ngit-gui doesn't display state of index is their limitation.\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"},{"id":"295924","messageId":"8764cwtxhm.wl%cworth@cworth.org","threadId":"43105","inReplyTo":"f2b55d220611301341n45c45506rca312dfa8ee6f795@mail.gmail.com","subject":"Re: [PATCH 0/2] Making \"git commit\" to mean \"git commit -a\".","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2006-11-30T21:50:45Z","receivedAt":"2006-11-30T21:50:45Z","isPatch":true,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Thu, 30 Nov 2006 13:41:37 -0800, \"Michael K. Edwards\" wrote:\n>\n> git mark\n\nI actually thought of that. But compared to \"refresh\" it sounds more\nlike something that suggests marking a file path rather than copying\ncontents, so our dark lord might not approve of the wrong ideas it\nmight allow to persist in brain-damaged heads.\n\nIt is nice and short, which is a bonus though.\n\n-Carl\n"},{"id":"296009","messageId":"200611302258.09523.jnareb@gmail.com","threadId":"43105","inReplyTo":"8764cwtxhm.wl%cworth@cworth.org","subject":"Re: [PATCH 0/2] Making \"git commit\" to mean \"git commit -a\".","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-11-30T21:58:09Z","receivedAt":"2006-11-30T21:58:09Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Dnia czwartek 30. listopada 2006 22:50, Carl Worth napisał:\n> On Thu, 30 Nov 2006 13:41:37 -0800, \"Michael K. Edwards\" wrote:\n>>\n>> git mark\n> \n> I actually thought of that. But compared to \"refresh\" it sounds more\n> like something that suggests marking a file path rather than copying\n> contents, so our dark lord might not approve of the wrong ideas it\n> might allow to persist in brain-damaged heads.\n> \n> It is nice and short, which is a bonus though.\n\nWhat about \"git update\"? \"git add\" would also work, I think.\n-- \nJakub Narebski\n"},{"id":"298213","messageId":"200611302307.52115.Josef.Weidendorfer@gmx.de","threadId":"43105","inReplyTo":"878xhsty3t.wl%cworth@cworth.org","subject":"Re: [PATCH 0/2] Making \"git commit\" to mean \"git commit -a\".","fromName":"Josef Weidendorfer","fromEmail":"josef.weidendorfer@gmx.de","sentAt":"2006-11-30T22:07:51Z","receivedAt":"2006-11-30T22:07:51Z","isPatch":true,"sender":{"key":"josef.weidendorfer@gmx.de","avatar":null},"body":"On Thursday 30 November 2006 22:37, Carl Worth wrote:\n> So I'd vote for \"resolve\" along with something else for the\n> mark-as-edited case. Maybe \"refresh\"? That's the best I've thought of\n> so far. Anyone else have a better suggestion?\n\ngit stage\n\n"},{"id":"298438","messageId":"Pine.LNX.4.64.0611301624430.9647@xanadu.home","threadId":"43105","inReplyTo":"7vhcwgiqer.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH 0/2] Making \"git commit\" to mean \"git commit -a\".","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2006-11-30T22:21:00Z","receivedAt":"2006-11-30T22:21:00Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Thu, 30 Nov 2006, Junio C Hamano wrote:\n\n> Nicolas Pitre writes:\n> \n> > ... But let me repeat my last question:\n> >\n> > Would it make sense for \"git add\" to do the same as \"git update-index\" \n> > on already tracked files? Given the explanation above this would make \n> > 100% sense to me.\n> \n> I think this makes sense and what we did in the original \"git\n> add\".\n\nWonderful! We might be converging to something then.\n\nBecause, conceptually, it then becomes much easier to tell newbies about \nthe index as follows (this could be pasted in a tutorial somewhere):\n\n Contrary to other SCMs, with GIT you have to explicitly \"add\" all\n the changes you want to commit together. This can be done in a few\n different ways:\n\n 1) By using \"git add \"\n\n This can be performed multiple times before a commit. Note that \n this is not only for adding new files. Even modified files must be\n added to the set of changes about to be committed. The \"git \n status\" command gives you a summary of what is included so far for \n the commit. When done you should use the \"git commit\" command to\n make it real.\n\n Note: don't forget to \"add\" a file again if you modified it after \n the first \"add\" and before \"commit\". Otherwise only the previous \n \"added\" state of that file will be committed.\n\n 2) By using \"git commit -a\" directly\n\n This is a quick way to automatically \"add\" all modified files to \n the set of changes and perform the actual commit without having to \n separately \"add\" them. This will not \"add\" new files -- those \n files still have to be added explicitly before performing a commit.\n\n Here's a twist. If you do \"git commit ...\" then \n only the changes belonging to those explicitly specified files will \n be committed, entirely bypassing the current \"added\" changes. Those\n \"added\" changes will still remain available for a subsequent commit.\n\n There is a twist about that twist: if you do \"git commit -i ...\" \n then the commit will consider changes to those specified files \n _including_ all \"added\" changes so far.\n\n But for instance it is best to only remember \"git add\" + \"git \n commit\" and/or \"git commit -a\".\n\nDoesn't it sounds nice? The index is being introduced up front without \neven mentioning it, and I think the above should be fairly palatable to \nnewbies as well. Would only lack some enhancements to the commit \ntemplate and the \"nothing to commit\" message so the user is cued about \nthe fact that \"current changeset is empty -- don't forget to 'git add' \nmodified files, or use 'git commit -a'\".\n\nWhat do you think?\n\n"},{"id":"294717","messageId":"Pine.LNX.4.63.0611302324370.30004@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"43105","inReplyTo":"878xhsty3t.wl%cworth@cworth.org","subject":"Re: [PATCH 0/2] Making \"git commit\" to mean \"git commit -a\".","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-11-30T22:25:52Z","receivedAt":"2006-11-30T22:25:52Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 30 Nov 2006, Carl Worth wrote:\n\n> It might even make sense to invent one more name for the case where\n> the user wants to inform git that a file has been edited and that git\n> should accept the new contents. It's the sort of \"note that file is\n> edited\" operation that could be recommended to the user with \"add; fix\n> typo; commit\" confusion.\n\nI suggest \"commit\". How about this: after editing the file, you tell git \nthat you finished editing it by doing\n\n\tgit commit the-edited-file.txt\n\nHmmm?\n\nCiao,\nDscho\n"},{"id":"295779","messageId":"Pine.LNX.4.63.0611302326070.30004@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"43105","inReplyTo":"200611302258.09523.jnareb@gmail.com","subject":"Re: [PATCH 0/2] Making \"git commit\" to mean \"git commit -a\".","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-11-30T22:26:51Z","receivedAt":"2006-11-30T22:26:51Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 30 Nov 2006, Jakub Narebski wrote:\n\n> What about \"git update\"?\n\n... and suffer another thread a la \"pull/merge\"? Please no.\n\nCiao,\nDscho\n"},{"id":"297239","messageId":"Pine.LNX.4.64.0611301725560.9647@xanadu.home","threadId":"43105","inReplyTo":"878xhsty3t.wl%cworth@cworth.org","subject":"Re: [PATCH 0/2] Making \"git commit\" to mean \"git commit -a\".","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2006-11-30T22:31:05Z","receivedAt":"2006-11-30T22:31:05Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Thu, 30 Nov 2006, Carl Worth wrote:\n\n> It might even make sense to invent one more name for the case where\n> the user wants to inform git that a file has been edited and that git\n> should accept the new contents. It's the sort of \"note that file is\n> edited\" operation that could be recommended to the user with \"add; fix\n> typo; commit\" confusion.\n> \n> Sure, \"add\" could be used again, and \"update-index\" clearly _works_\n> but it's a rather ugly name, (and already has \"plumbing\" functionality\n> like --add and --remove that we don't want here).\n\nI disagree. \"add\" is beautiful. It is short, easy to remember, and \ntranscend pretty much what the index is all about. And just because \n\"add\" and \"edited\" can be made into the same command is a pretty damn \ngood reason not to create a separate command.\n\n You \"add\" changes to the changeset then you commit that changeset.\n\nNo need to care whether or not this is a new file, an edited file, etc.\n\n\n"},{"id":"298630","messageId":"Pine.LNX.4.64.0611301736340.9647@xanadu.home","threadId":"43105","inReplyTo":"Pine.LNX.4.63.0611302324370.30004@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH 0/2] Making \"git commit\" to mean \"git commit -a\".","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2006-11-30T22:37:25Z","receivedAt":"2006-11-30T22:37:25Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Thu, 30 Nov 2006, Johannes Schindelin wrote:\n\n> Hi,\n> \n> On Thu, 30 Nov 2006, Carl Worth wrote:\n> \n> > It might even make sense to invent one more name for the case where\n> > the user wants to inform git that a file has been edited and that git\n> > should accept the new contents. It's the sort of \"note that file is\n> > edited\" operation that could be recommended to the user with \"add; fix\n> > typo; commit\" confusion.\n> \n> I suggest \"commit\". How about this: after editing the file, you tell git \n> that you finished editing it by doing\n> \n> \tgit commit the-edited-file.txt\n> \n> Hmmm?\n\nSure. ;-)\n\n\n"},{"id":"294004","messageId":"Pine.LNX.4.64.0611301740540.9647@xanadu.home","threadId":"43105","inReplyTo":"7vac28h898.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH 0/2] Making \"git commit\" to mean \"git commit -a\".","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2006-11-30T22:46:22Z","receivedAt":"2006-11-30T22:46:22Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Thu, 30 Nov 2006, Junio C Hamano wrote:\n\n> What this will \"achieve\" is:\n> \n> $ git add hello.c ;# index remembers the path\n> $ git diff ;# nothing -- it sees 0{40} and 0{40} on both sides\n> $ edit hello.c\n> $ git diff ;# still nothing\n> $ git commit ;# takes the content of 'hello.c' at this point\n> \n> This is a non-trivial amount of work but not a rocket science.\n> It is however of a negative value that helps the users stick to\n> the \"filename matters more than content\" mindset.\n\nAnd personally I think this bastardizes the index.\n\nI think so far the index is not a problem. the problem is in the UI and \nin the doc. With a \"git add\" as I described it I don't think the user \nwill ask for such thing.\n\nAnd let's have a \"git diff --commit\" be a much meaningful alias for the \nappropriate diff argument (which argument I always forget about myself) \nneeded to show what is going to be committed.\n\n\n"},{"id":"298123","messageId":"7vy7psft60.fsf@assigned-by-dhcp.cox.net","threadId":"43105","inReplyTo":"878xhsty3t.wl%cworth@cworth.org","subject":"Re: [PATCH 0/2] Making \"git commit\" to mean \"git commit -a\".","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-30T22:47:51Z","receivedAt":"2006-11-30T22:47:51Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Carl Worth writes:\n\n> I'm happy with the direction of having several commands that take the\n> place of update-index, each with its own name oriented toward what the\n> user wants to do.\n>\n> Obviously, \"add\", \"mv\", and \"rm\" have obvious places where the user\n> wants to use them.\n>\n> There's the merge case where \"resolve\" and \"resolved\" have both been\n> floated as possible names.\n>\n> It might even make sense to invent one more name for the case where\n> the user wants to inform git that a file has been edited and that git\n> should accept the new contents. It's the sort of \"note that file is\n> edited\" operation that could be recommended to the user with \"add; fix\n> typo; commit\" confusion.\n>\n> Sure, \"add\" could be used again, and \"update-index\" clearly _works_\n> but it's a rather ugly name, (and already has \"plumbing\" functionality\n> like --add and --remove that we don't want here).\n\ncheckin.\n\nYou check things into index with \"git checkin\" and later commit\nthe index with \"git commit\".\n\n"},{"id":"294942","messageId":"Pine.LNX.4.63.0611302354060.30004@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"43105","inReplyTo":"7vac28h898.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH 0/2] Making \"git commit\" to mean \"git commit -a\".","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-11-30T22:55:32Z","receivedAt":"2006-11-30T22:55:32Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 30 Nov 2006, Junio C Hamano wrote:\n\n> Linus Torvalds writes:\n> \n> > ...\n> > So yes, you very much ARE talking about CVS braindamage. The reason why\n> >\n> > \tgit add file.c\n> > \techo New line >> file.c\n> > \tgit commit\n> >\n> > commits the _old_ content, is very much because git is ALL ABOUT THE \n> > CONTENT. It has _never_ been about filenames. And it _shouldn't_ be about \n> > filenames, because that would be BUGGY AND BROKEN.\n> \n> I think this pretty much sums up and closes the current topic,\n> by declaring \"expecting to give behaviour consistent to the\n> 'filename is what the user tells the SCM to track' mental model\n> CVS instilled is a lost cause\".\n\nI think this is so important, that I vote for including this email as \nDocumentation/howto/explain-why-git-is-better-than-cvs.txt\n\nCiao,\nDscho\n"},{"id":"298176","messageId":"7vlklsfsgz.fsf@assigned-by-dhcp.cox.net","threadId":"43105","inReplyTo":"Pine.LNX.4.64.0611301624430.9647@xanadu.home","subject":"Re: [PATCH 0/2] Making \"git commit\" to mean \"git commit -a\".","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-30T23:02:52Z","receivedAt":"2006-11-30T23:02:52Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nicolas Pitre writes:\n\n> Wonderful! We might be converging to something then.\n\nYup. And it appears that we even agree that \"intent to add\" is\na bad idea ;-).\n\n> Here's a twist. If you do \"git commit ...\" then \n> only the changes belonging to those explicitly specified files will \n> be committed, entirely bypassing the current \"added\" changes. Those\n> \"added\" changes will still remain available for a subsequent commit.\n>\n> There is a twist about that twist: if you do \"git commit -i ...\" \n> then the commit will consider changes to those specified files \n> _including_ all \"added\" changes so far.\n\nI sense that you are inviting me to argue for reverting the\nother \"git commit\" braindead which is spelled \"--only\" (and\nworse yet, it is the default). I am very tempted.\n\n> But for instance it is best to only remember \"git add\" + \"git \n> commit\" and/or \"git commit -a\".\n>\n> Doesn't it sounds nice? The index is being introduced up front without \n> even mentioning it, and I think the above should be fairly palatable to \n> newbies as well. Would only lack some enhancements to the commit \n> template and the \"nothing to commit\" message so the user is cued about \n> the fact that \"current changeset is empty -- don't forget to 'git add' \n> modified files, or use 'git commit -a'\".\n>\n> What do you think?\n\nOther than these \"twists\", I think it makes sense, and that is\nwhat I think.\n\nBut making sense to me does not necessarily validate that a\ntutorial document is great for its intended audience, since I\nlost git virginity long time ago. I can only endorse that the\ndescription is technically accurate.\n"},{"id":"295145","messageId":"Pine.LNX.4.64.0611301520370.3513@woody.osdl.org","threadId":"43105","inReplyTo":"7vlklsfsgz.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH 0/2] Making \"git commit\" to mean \"git commit -a\".","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-11-30T23:40:58Z","receivedAt":"2006-11-30T23:40:58Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 30 Nov 2006, Junio C Hamano wrote:\n> \n> I sense that you are inviting me to argue for reverting the\n> other \"git commit\" braindead which is spelled \"--only\" (and\n> worse yet, it is the default). I am very tempted.\n\nI actually really like the current defaults for \"git commit\".\n\nAnd I say that despite the fact that the defaults are _different_ from the \noriginal ones.\n\nI like the fact that when you do \"git commit filename\", it really will \ncommit _only_ that file, not the other files you added. It's logical.\n\nSo you can do\n\n\techo a > file-a\n\techo b > file-b\n\tgit add file-a file-b\n\n\tgit commit file-a\n\nand it will only commit one of them. Now, admittedly, the status message \nthat you get is slightly misleading (it says that \"file-b\" is untracked, \nwhich is not strictly true or at least somewhat confusing - it's untracked \nonly within the context of that one commit), but this is all logically \nconsistent.\n\nAnd it's wonderful for noticing \"Oh, sh*t, I forgot to commit that \nprevious change, let's commit that other file first!\". You can do things \nlike this _despite_ the fact that you've added other files to the list of \nfiles to be committed.\n\nThe current semantics for \"git commit\" are really powerful, and really \nflexible. Yes, there are different \"cases\", but they all have their place:\n\n - \"git commit\" on its own:\n\n This is for things where you prepared things earlier: notably a merge, \n for example. But it might be the \"--amend\" case too, where you simply \n don't want to change any of the working tree, just the commit message.\n\n The fact that it has a nice fallback for the \"nothing to commit\" case \n which basically just prints out the same thing as \"git status\" is just \n gravy.\n\n - \"git commit explicit/file anotherfile\"\n\n This is great (and I use it) exactly for when you have random other \n additions in your tree that are brewing, and you just want to commit a \n particular fix that takes precedence. You may be in the middle of \n something else, but you found a critical bug that needs to be fixed, \n and while you _could_ do it on another branch, it's just a lot more \n convenient to specify exactly what you want to commit.\n\n - \"git commit -a\"\n\n Sure, this is the common case, but just how painful is it to type those \n extra few characters? And not defaulting to this is just sensible, \n considering that \"-a\" really is not _that_ special, and the above two \n cases simply aren't that unusual either. And it's just good to make \n people have to _think_ about the fact that it commits everything that \n have dirty.\n\nAt least for me, it turns out that the only mode I _never_ use personally \nis the \"git commit -i\" thing, which was actually the original behaviour, \nand which you'd think that I would encourage for that reason. But no. Of \nall the modes of \"git commit\", that's the one I think is the least \nimportant, and least interesting.\n\nOf course, during a merge, you do need \"-i\" if you list files, but I think \n\"-a\" subsumes almost all cases (you _can_ use \"-i file-list\" or totally \nmanually decide to have some extra edits you did that you don't want to \ncommit together with the merge, but that's such a special case that I \ndoubt anybody does it, so I don't think it's a big deal).\n\nAnyway, we have \"-i\", and we don't force anybody to use it, so the fact \nthat it's a bit odd and not that useful doesn't really matter. It \ncertainly \"fits\" in the git commit family as another case, it's just not \none of the important cases.\n\n"},{"id":"297776","messageId":"eknrig$n27$1@sea.gmane.org","threadId":"43105","inReplyTo":"7vlklsfsgz.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH 0/2] Making \"git commit\" to mean \"git commit -a\".","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-12-01T00:06:28Z","receivedAt":"2006-12-01T00:06:28Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Linus Torvalds wrote:\n\n> At least for me, it turns out that the only mode I _never_ use personally \n> is the \"git commit -i\" thing, which was actually the original behaviour, \n> and which you'd think that I would encourage for that reason. But no. Of \n> all the modes of \"git commit\", that's the one I think is the least \n> important, and least interesting.\n> \n> Of course, during a merge, you do need \"-i\" if you list files, but I think \n> \"-a\" subsumes almost all cases (you _can_ use \"-i file-list\" or totally \n> manually decide to have some extra edits you did that you don't want to \n> commit together with the merge, but that's such a special case that I \n> doubt anybody does it, so I don't think it's a big deal).\n> \n> Anyway, we have \"-i\", and we don't force anybody to use it, so the fact \n> that it's a bit odd and not that useful doesn't really matter. It \n> certainly \"fits\" in the git commit family as another case, it's just not \n> one of the important cases.\n\nSo, in short, -i is easier to explain, but is also least used. Perhaps\nalso because one can simply update index with before git commit\ninstead of doing \"git commit -i \".\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"},{"id":"297237","messageId":"873b80tqvv.wl%cworth@cworth.org","threadId":"43105","inReplyTo":"Pine.LNX.4.64.0611301520370.3513@woody.osdl.org","subject":"Re: [PATCH 0/2] Making \"git commit\" to mean \"git commit -a\".","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2006-12-01T00:13:24Z","receivedAt":"2006-12-01T00:13:24Z","isPatch":true,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Thu, 30 Nov 2006 15:40:58 -0800 (PST), Linus Torvalds wrote:\n> I like the fact that when you do \"git commit filename\", it really will\n> commit _only_ that file, not the other files you added. It's logical.\n>\n> So you can do\n>\n> \techo a > file-a\n> \techo b > file-b\n> \tgit add file-a file-b\n>\n> \tgit commit file-a\n\nBut, wait a second. What if I do my typo fix to file-a in between that\n\"git add\" and the \"git commit\". Why should \"git commit\" insist so\nvehemently on committing the _old_ state of file-a while \"git commit\nfile-a\" so happily commits the _new_ state?\n\nI'm really not seeing conceptual consistency to what \"commit \"\ndoes compared to \"commit\".\n\nThe \"commit \" case is a special-case of \"commit -a\" while\n\"commit\" is just plain different. See?\n\nI do like the direction Nico is going with \"git add\" and his little\ntutorial. I think the first part of that, (without the twists), could\nmake a very nice introduction to git.\n\nThe \"twists\" part though is quite a nightmare, and \"twists on twists\"\nis something that should be left to B-grade screenwriters, not\ntechnical writers, (nothing against Nico there---the stuff is really\nconfusing).\n\nBut dropping back to the old default for \"git commit explicit/file\"\nreally would only make things worse.\n\n> - \"git commit\" on its own:\n>\n> This is for things where you prepared things earlier: notably a merge,\n> for example.\n\nFor \"notably a merge\", how often is this not equivalent to \"commit -a\"\nin your view?\n\n> But it might be the \"--amend\" case too, where you simply\n> don't want to change any of the working tree, just the commit message.\n\nPersonally, I think I use --amend to change the tree of the last\ncommit as often as I change just the message. Regardless of the\nrelative frequency, I definitely use it often for both of those modes,\nso both should be supported.\n\n> - \"git commit explicit/file anotherfile\"\n>\n> This is great (and I use it) exactly for when you have random other\n> additions in your tree that are brewing, and you just want to commit a\n> particular fix that takes precedence.\n\nAs I mention above, this usage is exactly \"commit -a\" but restricted\nto just a few paths. Why isn't it just as brain-damaged to take\ncontents from the working tree instead of the index here as in the\ncase of my \"add; fix typo; commit\" example?\n\n> - \"git commit -a\"\n>\n> Sure, this is the common case, but just how painful is it to type those\n> extra few characters?\n\nIf we all agree it's the most common, then why isn't it the default?!\nIt's the right thing for after resolving a conflicted merge, (since\nthe working tree is where the user _first_ resolves things, before the\nchanges make it to the index), the command is consistent with the\nbehavior of \"git commit explicit/file\", and the existing \"git commit\"\nbehavior would still be available in the rare cases it's desired, (and\nthen, how painful would it be to type the few extra characters to ask\nfor that?).\n\nI know, I know. I said I'd give up and yet I keep harping on this\nstuff. I'm hopeless.\n\n-Carl\n"},{"id":"295146","messageId":"Pine.LNX.4.64.0611301618490.3513@woody.osdl.org","threadId":"43105","inReplyTo":"873b80tqvv.wl%cworth@cworth.org","subject":"Re: [PATCH 0/2] Making \"git commit\" to mean \"git commit -a\".","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-12-01T00:21:56Z","receivedAt":"2006-12-01T00:21:56Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 30 Nov 2006, Carl Worth wrote:\n> >\n> > So you can do\n> >\n> > \techo a > file-a\n> > \techo b > file-b\n> > \tgit add file-a file-b\n> >\n> > \tgit commit file-a\n> \n> But, wait a second. What if I do my typo fix to file-a in between that\n> \"git add\" and the \"git commit\". Why should \"git commit\" insist so\n> vehemently on committing the _old_ state of file-a while \"git commit\n> file-a\" so happily commits the _new_ state?\n\nBecause that's what \"git commit filename\" means.\n\nIt means \"commit the changes to this file\".\n\n> I'm really not seeing conceptual consistency to what \"commit \"\n> does compared to \"commit\".\n\nExactly what the command says. \"git commit\" says \"commit everything I've \ntold you to commit\". While \"git commit filename\" says \"commit the changes \nthat I've made to this file\".\n\nYes, they are two totally different cases, but nobody sane can claim that \nit is strange. Exactly _because_ you explicitly list the filename, that \nalso means that you want the file content AT THAT TIME. If you don't list \nthe filename, you obviously must be talking about committing something you \ndid earlier.\n\n"},{"id":"294702","messageId":"7vk61cea58.fsf@assigned-by-dhcp.cox.net","threadId":"43105","inReplyTo":"Pine.LNX.4.64.0611301520370.3513@woody.osdl.org","subject":"Re: [PATCH 0/2] Making \"git commit\" to mean \"git commit -a\".","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-01T00:24:03Z","receivedAt":"2006-12-01T00:24:03Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> On Thu, 30 Nov 2006, Junio C Hamano wrote:\n>> \n>> I sense that you are inviting me to argue for reverting the\n>> other \"git commit\" braindead which is spelled \"--only\" (and\n>> worse yet, it is the default). I am very tempted.\n>\n> I actually really like the current defaults for \"git commit\".\n\nHmmm. I did not make my judgement based on what the command did\nin the ancient _original_ version. The --only behaviour being\ntotally different from others (from \"index is the only thing\nthat matters\" point of view) was what bothered me. It did not\nfeel logical.\n\nHowever, if you put it this way:\n\n> I like the fact that when you do \"git commit filename\", it really will \n> commit _only_ that file, not the other files you added. It's logical.\n\nthat makes tons of sense.\n\nWhat's \"logical\" largely depends on how things ought to behave\nin the mental model, and the mental model you would form largely\ndepends on how things are explained to you.\n\n\n"},{"id":"295715","messageId":"871wnkh142.wl%cworth@cworth.org","threadId":"43105","inReplyTo":"Pine.LNX.4.64.0611301618490.3513@woody.osdl.org","subject":"Re: [PATCH 0/2] Making \"git commit\" to mean \"git commit -a\".","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2006-12-01T01:10:53Z","receivedAt":"2006-12-01T01:10:53Z","isPatch":true,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Thu, 30 Nov 2006 16:21:56 -0800 (PST), Linus Torvalds wrote:\n> Exactly what the command says. \"git commit\" says \"commit everything I've\n> told you to commit\". While \"git commit filename\" says \"commit the changes\n> that I've made to this file\".\n>\n> Yes, they are two totally different cases, but nobody sane can claim that\n> it is strange.\n\nCall me insane.\n\nI think it is very strange that the following command sequences commit\ndifferent content for myfile:\n\n\techo old > myfile\n\tgit add myfile\n\techo new > myfile\n\tgit commit\n\ncompared to:\n\n\techo old > myfile\n\tgit add myfile\n\techo new > myfile\n\tgit commit myfile\n\nThe difference there is very subtle and really does prevent a\nreasonable, \"just ignore the index and you can use git comfortably\".\n\nNow, the behavior above can be explained. You and I both understand it\njust fine. And Nico's proposed tutorial document even explains it,\n(twists and all).\n\nBut it is strange, and I cannot see how the first case is at all useful.\n\nThe point is that by-and-large I don't ever want to commit anything\nthat is not present in my working tree at the time I type\n\"commit\". That's precisely why I'm typing \"commit\" at that time.\n\nIf I do ever want to commit content that is not currently in my\nworking tree, then I should have to do something\nexceptional. Otherwise, git will always have user-interface traps that\nwill trip people up.\n\nYou might point at my first example and say that the timing of my \"git\nadd\" command is the exceptional thing I did to trigger the old commit.\nBut the second command above destroys that explanation. In the second,\nthe timing of \"git add\" doesn't trigger any exceptional behavior at\nall. The new content of the file is still committed.\n\n> Exactly _because_ you explicitly list the filename, that\n> also means that you want the file content AT THAT TIME. If you don't list\n> the filename, you obviously must be talking about committing something you\n> did earlier.\n\nYou're explaining the behavior, but not providing any justification\nfor this being the right thing based on what a user actually wants to\ndo.\n\n-Carl\n"},{"id":"296000","messageId":"Pine.LNX.4.64.0611302017120.9647@xanadu.home","threadId":"43105","inReplyTo":"7vlklsfsgz.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH 0/2] Making \"git commit\" to mean \"git commit -a\".","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2006-12-01T01:20:10Z","receivedAt":"2006-12-01T01:20:10Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Thu, 30 Nov 2006, Junio C Hamano wrote:\n\n> I sense that you are inviting me to argue for reverting the\n> other \"git commit\" braindead which is spelled \"--only\" (and\n> worse yet, it is the default). I am very tempted.\n\nNo no no !\n\nI argued for that at the time and I still stands behind that change !\n\n\n"},{"id":"296675","messageId":"Pine.LNX.4.64.0611301720240.3513@woody.osdl.org","threadId":"43105","inReplyTo":"871wnkh142.wl%cworth@cworth.org","subject":"Re: [PATCH 0/2] Making \"git commit\" to mean \"git commit -a\".","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-12-01T01:32:22Z","receivedAt":"2006-12-01T01:32:22Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 30 Nov 2006, Carl Worth wrote:\n> \n> The difference there is very subtle and really does prevent a\n> reasonable, \"just ignore the index and you can use git comfortably\".\n\nIf you want to ignore the index, you'd always use \"git commit -a\".\n\nSo what's your point?\n\n> But it is strange, and I cannot see how the first case is at all useful.\n\nThe old argument by incredulity. The fact that you cannot see it doesnt' \nchange the fact that I use it all the time. Usually not for the same file, \nbut committing something that is different in the index and in the working \ntree is my normal behaviour - it's how any number of things work (like \nmerging while you have dirty state, or applying patches while you have \nchanges).\n\nSo, let me condense the argument:\n\n - your argument is that cannot understand how anybody would ever want to \n use this.\n\nThat's really what it all boils down to. That's your ONLY argument. You \ndidn't actually answer any of me explaining _why_ it's how it works, and \nwhy it _has_ to be why it works. Your argument just boils down to \"I can't \nbelieve it's useful to be consistent\".\n\nMy argument is:\n\n - the current behaviour is actually very powerful, and I've given \n examples of when I actually do use it (and whether you know it or not, \n they are also things you've probably done - the \"pull from somebody \n else with dirty files\" is actually exactly the same thing, you just \n never realized it just because it happened to be the same thing on two \n different files)\n\n - the \"git add file ; change file ; git commit\" behaviour is absolutely \n REQUIRED once you get the whole \"git tracks content\" logic. Doing \n anything but committing the old version (the one you added) would be \n illogical and wrong, because it's strictly against the whole POINT of \n tracking content.\n\nSo. That's what it boils down to. Your personal incredulity against \nfundamental concepts and real usage.\n\nThe reason I like UNIX is that it has \"fundamental concepts\". And \nsurprise, surprise, a lot of the same issues are at play in \"git\" too. \nPretty much _all_ the behaviour (apart from actual _naming_ issues) really \ncome from fundamental concepts, and _not_ doing special cases.\n\nI guarantee you, in the end you're better off building a world-view on a \ncoherent guiding logic, than on \"personal incredulity\" or \"I can't believe \nthat anybody would actually ever want to do that\".\n\nAs an X developer, don't you get tired of hearing people saying \"I can't \nbelieve anybody would ever want to use a network transparent protocol and \ndo graphics from another machine\"? The non-X people (and every single \n\"let's replace X with something more efficient\" discussion) always tend to \ntake that approach. \n\nSame thing. It really doesn't matter what you think is \"normal\". What \nmatters a lot more in the end is that you keep a coherent set of concepts, \nso that once you really learn the concepts, it all makes sense.\n\nAnd in git, the over-arching concept for just about _anything_ is \"git \ntracks contents, and filenames don't matter\". The behaviour of \"git add\" \nand \"git commit\" is just a small detail in that whole picture.\n\n"},{"id":"297606","messageId":"87y7psfjvk.wl%cworth@cworth.org","threadId":"43105","inReplyTo":"Pine.LNX.4.64.0611301720240.3513@woody.osdl.org","subject":"Re: [PATCH 0/2] Making \"git commit\" to mean \"git commit -a\".","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2006-12-01T02:08:31Z","receivedAt":"2006-12-01T02:08:31Z","isPatch":true,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Thu, 30 Nov 2006 17:32:22 -0800 (PST), Linus Torvalds wrote:\n>\n> The old argument by incredulity. The fact that you cannot see it doesnt'\n> change the fact that I use it all the time.\n\nI'm sorry, Linus. I'm really failing to communicate with you somehow\nhere.\n\nI _do_ use this all the time too. I don't need you to explain it to me\nagain. I get it, I like it, I use it. That's not at all what I'm\ntrying to discuss here.\n\n> - your argument is that cannot understand how anybody would ever want to\n> use this.\n\nNope. I get it and I use it. Most commonly I do things like\n\"update-index;commit\" to separate independent changes, (I could use\n\"git commit explicit/files\" instead but I *gasp* actually enjoy being\nable to manually stage things in the index first).\n\nWhat I'm trying to say is that the _defaults_ are not well geared\ntoward helping new users do what they want to with git.\n\n> That's really what it all boils down to. That's your ONLY argument. You\n> didn't actually answer any of me explaining _why_ it's how it works, and\n> why it _has_ to be why it works. Your argument just boils down to \"I can't\n> believe it's useful to be consistent\".\n\nI do understand how git works. I understand your points about\nfilenames and content. I understand that.\n\nOne thing you never really answered was my conversation with a new\nuser that left the user with the impression of \"git is bizarre\". How\ncan I fix that conversation?\n\nThe idea I have for improving this is to do nothing more than change\nthe default semantics for one command to the semantics of that same\ncommand with a single-letter option. You keep saying that my idea is\nbrain-damaged, (that carrying the filename from \"git add\" to \"git\ncommit\" without the old contents would violate something fundamental).\nBut \"commit -a\" already exists and does _exactly_ what I'm asking for\nhere. People use that without destroying git's model. Why would it\nnecessarily be so evil to do that by default?\n\nBy the way, none of the \"confusion\" arguments are coming from me\ndirectly. They're coming through me by proxy, (on behalf of people\nI've seen deciding against using git). Personally, I love git and plan\nto continue using it forever. I'm very happy with it. I'm even\ncomfortable with all of the aspects of its interface that I'm arguing\nagainst changing here, (which really are not big fundamental\nthings). I just think its harder for new people to get to that point\nthan it should be.\n\n> - the \"git add file ; change file ; git commit\" behaviour is absolutely\n> REQUIRED once you get the whole \"git tracks content\" logic. Doing\n> anything but committing the old version (the one you added) would be\n> illogical and wrong, because it's strictly against the whole POINT of\n> tracking content.\n\nHere's another question based on that example. You say above that\ncommitting the old version is the only logical thing to\ndo. Separately, you say that after adding file-a and file-b it's often\nconvenient to be able to commit file-a without file-b.\n\nSo, given the following:\n\n\techo a > file-a\n\techo b > file-b\n\tgit add file-a file-b\n\techo a-not-ready-yet > file-a\n\nHow could I do both of these at once? That is, how can I commit the\n_old_ version of file-a, (the only logical choice), but not commit\nfile-b? There's no commit command that does that is there? (I don't\nthink that's a fault in git since I think this would be a fairly\nexceptional thing to do).\n\n> So. That's what it boils down to. Your personal incredulity against\n> fundamental concepts and real usage.\n\n[I'll snip the rest, because I really do think I understand, agree\nwith, and accept the fundamental concepts of git.]\n\nBut as for \"real usage\", by far, the thing I want to do most often is\nto commit the state of my files as the exist in my working tree at the\ntime of commit. Any time I do anything else, I'm well aware of it, and\nI'm quite happy to do \"special\" index-manipulating commands, (taking\nadvantage of the fundamental, content-tracking nature of git to do\nit).\n\nI think the defaults for git-commit should reflect that aspect of real\nusage. That's all.\n\n-Carl\n"},{"id":"296893","messageId":"Pine.LNX.4.64.0611301827540.3451@woody.osdl.org","threadId":"43105","inReplyTo":"87y7psfjvk.wl%cworth@cworth.org","subject":"Re: [PATCH 0/2] Making \"git commit\" to mean \"git commit -a\".","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-12-01T02:44:41Z","receivedAt":"2006-12-01T02:44:41Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 30 Nov 2006, Carl Worth wrote:\n> \n> What I'm trying to say is that the _defaults_ are not well geared\n> toward helping new users do what they want to with git.\n\nI really think we're better off just telling people how things work (with \npractical examples, and _not_ by trying to explain things at too high a \nconceptual level).\n\nI don't think people generally are all that stupid, and I think it's \nactually counter-productive to try to basically lie about how things work. \nIt will just make it harder for people later.\n\n> One thing you never really answered was my conversation with a new\n> user that left the user with the impression of \"git is bizarre\". How\n> can I fix that conversation?\n\nI really _think_ that a lot of that is in the documentation being overly \ntechnically oriented and talking often about the technical side of how \nthings work in the index, rather than the purely user side of what that \n_results_ in.\n\nI really believe that people can understand the concept of \"git add\" \nsquirrelling away the whole state of the file at add-time, and suddenly \nit's not all that complicated. Also, it's not even something that people \nreally need to worry about, and I think we should make that more clear.\n\nIn other words, the documentation could _literally_ give the example of\n\n\tgit add file.c\n\t.. change file.c ..\n\tgit commit\n\tgit diff file.c\n\nand talk about this issue up-front, but then just say outright to people \nthat \"if you don't want to know about these details, you can always just \nuse 'git commit -a', and you'll never really even notice\".\n\nThere really isn't all that much to \"hide\". I think we've sometimes done a \nhorrible job on _presentation_, but I also think that it's better to give \nexamples of thigns like this, and then tell people not to worry, because \nthey'll never need to care unless they actually start doing something \nfancy.\n\nSo all your examples of \"badness\" aren't really all that bad. Newbies \nshould be told:\n\n - use \"git commit -a\" normally (with pointers on fancier usage)\n\n - and yes, we obviously should change the message to say \"git commit -a\"\n instead of \"git update-index\"\n\n - do NOT use the \"-m\" flag, and look at what git tells you in the\n commit message!\n\n This is actually important, because even for non-newbie users, the git \n commit message for a conflicting merge contains useful information, \n and people should read it. It lists the conflicting filenames for a \n reason, namely so that you can talk about what the conflicts in \n question _were_.\n\n[ Btw, I can't stress that last point enough. Using the \"-m\" flag should \n really really REALLY be discouraged. It is almost always a horrible \n mistake, not just because it means that you miss what git will tell you \n about which files are getting checked in, but because it invariably \n leads to bad single-line commit messages.\n\n In my personal opinion, the \"-m\" flag is really only good for scripts \n and sending example git sequences to each other, ie it's there for \n automated \"do this\" kind of scripting, and using it for real work should \n be a castration offence, so that you don't perpetuate your genes.\n\n (I've seen _way_ too many projects where there's a lot of \"update \n version\" one-liner commit messages. Damn, I can understand that in CVS, \n where the logs are useless _anyway_, but in git it shouldn't be \n allowed!). ]\n\nOk, with that rant out of the way, my _point_ is that we're actually much \nbetter off educating users about _why_ git is different, than trying to \nlie to them and say \"it's just like CVS by default, but when you're a real \nman, we'll show you how you can rock your world\".\n\n"},{"id":"296939","messageId":"87wt5cffms.wl%cworth@cworth.org","threadId":"43105","inReplyTo":"Pine.LNX.4.64.0611301827540.3451@woody.osdl.org","subject":"Re: [PATCH 0/2] Making \"git commit\" to mean \"git commit -a\".","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2006-12-01T03:40:11Z","receivedAt":"2006-12-01T03:40:11Z","isPatch":true,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Thu, 30 Nov 2006 18:44:41 -0800 (PST), Linus Torvalds wrote:\n> I really think we're better off just telling people how things work (with\n> practical examples, and _not_ by trying to explain things at too high a\n> conceptual level).\n>\n> I don't think people generally are all that stupid, and I think it's\n> actually counter-productive to try to basically lie about how things work.\n> It will just make it harder for people later.\n\nSure. There's no need to lie to about how things work. And I agree\nthat would cause later problems. As far as getting the message out, we\nhave several different ways to do that:\n\n 1. In-person presentations, demos, tutorials\n\n 2. Written tutorials\n\n 3. Reference documentation\n\n 4. Output from git commands\n\n 5. The default behavior of git commands\n\nAnd that list is roughly sorted from most to least \"information\nbandwidth\". The limited bandwidth at the bottom-most levels in my\nlist, (together with the fact that people often start trying the tool\nat only those levels), means we have to be even that much more careful\nabout the messaging there.\n\nIn my experience, I think we succeed quite well at level 1. In person,\nwe get immediate feedback from the user and it's easy to catch and\ncut-off any user confusion up-front. \"Oh, you don't even need to run\nthat command...use this instead\", etc.\n\nAs for the other levels, you hit on most of them in your comments:\n\n> I really _think_ that a lot of that is in the documentation being overly\n> technically oriented and talking often about the technical side of how\n> things work in the index, rather than the purely user side of what that\n> _results_ in.\n\nYes, this is a big problem at level 3. Things like the \"man git-diff\"\nscare factor that Ted pointed out. So let's work to fix all of that.\n\n> I really believe that people can understand the concept of \"git add\"\n> squirrelling away the whole state of the file at add-time, and suddenly\n> it's not all that complicated. Also, it's not even something that people\n> really need to worry about, and I think we should make that more clear.\n\nOne trick with saying \"we just need to document this better\" to avoid\nthe confusion is that approach assumes that the users are actually\n_reading_ the right documentation. Now, we're currently making this\nharder than it should be at level 4 by doing things like sending users\nto the documentation for update-index. But still, if we can make\nthings less surprising in some cases _without_ needing the\ndocumentation, then we make it that much easier.\n\n> In other words, the documentation could _literally_ give the example of\n>\n> \tgit add file.c\n> \t.. change file.c ..\n> \tgit commit\n> \tgit diff file.c\n>\n> and talk about this issue up-front,\n\nYes, adding lots of good examples to the written documentation will\nhelp, (anyone that reads it at least).\n\n> that \"if you don't want to know about these details, you can always just\n> use 'git commit -a', and you'll never really even notice\".\n...\n> - use \"git commit -a\" normally (with pointers on fancier usage)\n...\n> - and yes, we obviously should change the message to say \"git commit -a\"\n> instead of \"git update-index\"\n\nSo here you're arguing for documenting the heck out of \"commit -a\" at\nall of levels 1-4. If we're going to do that, why not just go the next\ntiny step and make it work as \"git commit\" by default, (which people\n_will_ try). If we can say, \"come from hg or bzr and things will just\nwork\", people can try that, be satisfied that git isn't bizarre, and\nthen we can teach where git's actually superior.\n\n> - do NOT use the \"-m\" flag, and look at what git tells you in the\n> commit message!\n\nInteresting. I do use -m almost exclusively. I do that for speed I\nthink, (but I do do multi-line commit messages). The only drawback I\nwas aware of was that I'm doing manual word wrapping, but I might\nstart trying this to see information in the commit message, (instead\nI've been checking first with \"git diff --cached\").\n\n> Ok, with that rant out of the way, my _point_ is that we're actually much\n> better off educating users about _why_ git is different, than trying to\n> lie to them and say \"it's just like CVS by default, but when you're a real\n> man, we'll show you how you can rock your world\".\n\nI still don't see any lie here. If we all agree that \"git commit -a\"\nis the most commonly desired form, it's what users expect by default\n(based on _any_ other system they might be coming from), and we agree\nwe need to mention it a lot more at every level of the\ndocumentation---given all that, why do we insist on having something\nelse be the default?\n\nBecause it gives us an opportunity to teach about the power of the\nindex to anyone that gets confused and complains? That strategy\nignores everyone that gets confused and just leaves without talking to\nus.\n\nI'm talking about changing the default of what \"git commit\" does, yes,\nbut it can still be documented honestly as to what it really does and\nwhy. It would fit in just fine with Nico's new documentation for \"git\nadd\" for example, and \"git diff\" doesn't need to be changed at all,\n(but it's documentation should be made much less scary).\n\n-Carl\n"},{"id":"295813","messageId":"f2b55d220611301952x68f30bccs1700588eee4a6a97@mail.gmail.com","threadId":"43105","inReplyTo":"Pine.LNX.4.64.0611301827540.3451@woody.osdl.org","subject":"Re: [PATCH 0/2] Making \"git commit\" to mean \"git commit -a\".","fromName":"Michael K. Edwards","fromEmail":"medwards.linux@gmail.com","sentAt":"2006-12-01T03:52:09Z","receivedAt":"2006-12-01T03:52:09Z","isPatch":true,"sender":{"key":"medwards.linux@gmail.com","avatar":null},"body":"I think Linus is right that the semantics of \"git commit\" and \"git\nadd\" are not broken and do not need fixing. But Carl and others are\nright that they are not self-explanatory to most people, whether or\nnot they have been tainted by CVS and its ilk. Maybe this is a job\nfor a little contextual documentation (aka hand-holding) to accompany\nthe tutorial and reference docs.\n\nHow about we add a set of \"expert\" flags in the config, gating access\nto non-intuitive behavior and to idioms that should be discouraged in\ncasual use. For instance, with an empty config, \"git commit -m\" fails\nwith a message to the effect of:\n \"As a general rule, you shouldn't use the -m flag unless you're\nscripting git for automation purposes. If this is what you are doing,\nor if you insist on committing without feedback about the state of\nyour tree, you need to set the 'expert-commit-message' flag\".\n\nLikewise, when your working copy does not match HEAD, \"git commit\"\nwith neither -a nor an explicit list of files fails, saying:\n \"'git commit' on a dirty working copy does the Right Thing! But\nsome people find the Right Thing counter-intuitive at first. Either\nstick to 'git commit -a' or read the docs and set the\n'expert-commit-dirty' flag.\"\n\nAnd \"git add\" still does the right thing, but warns:\n \"Remember, git is not CVS. 'git add' has taken a snapshot of the\ncurrent _contents_ of the newly added files, not just their names.\nFrom now on, you will need to 'git mark' edits to them if you want\nthem to be part of the next commit, just like edits to files that have\nalready been committed. This warning can be suppressed by setting the\n'expert-add-content' flag.\"\n\nNote that 'expert-commit', etc. should NOT change the semantics of any\ncommand that doesn't error out. They should just enable idioms that a\nnovice user is likely to try and get unexpected results. They should\nbe overridable from the environment, of course, either one by one\n(export GIT_EXPERT_COMMIT_MESSAGE=y) or wholesale (export\nGIT_I_GROK_IN_FULLNESS_UP_TO=1.4.4).\n\nCheers,\n"},{"id":"294425","messageId":"200612010834.22916.andyparkins@gmail.com","threadId":"43105","inReplyTo":"Pine.LNX.4.64.0611301253380.3513@woody.osdl.org","subject":"Re: [PATCH 0/2] Making \"git commit\" to mean \"git commit -a\".","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2006-12-01T08:34:21Z","receivedAt":"2006-12-01T08:34:21Z","isPatch":true,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Thursday 2006 November 30 21:03, Linus Torvalds wrote:\n\n> Yeah, I think it would probably make sense. I also think it would make\n> sense to rename \"update-index\" entirely, or at least offer other names for\n\nHow about this:\n\ngit-update-index becomes plumbing only - never expect a user to run it.\n\nHence,\n\ngit-add becomes git-prepare and does\n a) update-index --add\n when the file being \"prepared\" is not tracked\n b) update-index\n when the file is already tracked\n\ngit-rm takes on \"git-update-index --remove\" (and --force-remove) with \nappropriate switches.\n\ngit-mv does what it does - it's already pretty perfect\n\ngit-cp gets added; even though it's simply \"cp a b; git-prepare b\"\n\nObviously with all the details that I've left out filled in.\n\n\nAndy\n-- \nDr Andy Parkins, M Eng (hons), MIEE\n"},{"id":"298303","messageId":"456FEB53.7080703@op5.se","threadId":"43105","inReplyTo":"87fyc0u56z.wl%cworth@cworth.org","subject":"Re: [PATCH 0/2] Making \"git commit\" to mean \"git commit -a\".","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2006-12-01T08:44:03Z","receivedAt":"2006-12-01T08:44:03Z","isPatch":true,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Carl Worth wrote:\n> \n> See? Git _is_ harder to learn, and a user really cannot learn it\n> without being careful about the index right from the very beginning.\n> \n\nI'm not so sure about that. I came from CVS / SVN, although I've fiddled \nquite a bit with other scm's as well. The two-step commit process of git \ndidn't terrify me at all, and I had used git at least a month before I \njoined the mailing-list and found out that there's this thing called an \n\"index\". I knew about it before, since back then (June or July 2005) \nthere was only git-update-index to mark things to commit. I just didn't \nworry about it but expected the scm to tell me if I was about to break \nsomething horribly (which it often but not always did).\n\nI think the main thing people are having difficulties with when it comes \nto git is that it doesn't do things like other SCM's do it. Imo this is \na good thing, because it allows git to be more powerful than other \nSCM's. Otoh it forces users migrating from \ndarcs/hg/monotone/perforce/whatever to git actually read the \ndocumentation (and quite a lot of it), while hg -> bzr migrators use \npretty much the same commands for pretty much the same actions. This \nmakes users accustomed to not reading docs / trying things out before \nattempting Real Work(tm), which breaks down horribly when user \nexpectations doesn't match reality. The simplest and usually most \neffective solution is to meet the users half-way, and tell them early on \nthat this power comes at the cost of having to read the documentation \nand do the tutorials.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\n"},{"id":"294648","messageId":"456FEED4.7030400@op5.se","threadId":"43105","inReplyTo":"Pine.LNX.4.64.0611301624430.9647@xanadu.home","subject":"Re: [PATCH 0/2] Making \"git commit\" to mean \"git commit -a\".","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2006-12-01T08:59:00Z","receivedAt":"2006-12-01T08:59:00Z","isPatch":true,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Nicolas Pitre wrote:\n> On Thu, 30 Nov 2006, Junio C Hamano wrote:\n> \n>> Nicolas Pitre writes:\n>>\n>>> ... But let me repeat my last question:\n>>>\n>>> Would it make sense for \"git add\" to do the same as \"git update-index\" \n>>> on already tracked files? Given the explanation above this would make \n>>> 100% sense to me.\n>> I think this makes sense and what we did in the original \"git\n>> add\".\n> \n> Wonderful! We might be converging to something then.\n> \n> Because, conceptually, it then becomes much easier to tell newbies about \n> the index as follows (this could be pasted in a tutorial somewhere):\n> \n> Contrary to other SCMs, with GIT you have to explicitly \"add\" all\n> the changes you want to commit together. This can be done in a few\n> different ways:\n> \n> 1) By using \"git add \"\n> \n> This can be performed multiple times before a commit. Note that \n> this is not only for adding new files. Even modified files must be\n> added to the set of changes about to be committed. The \"git \n> status\" command gives you a summary of what is included so far for \n> the commit. When done you should use the \"git commit\" command to\n> make it real.\n> \n> Note: don't forget to \"add\" a file again if you modified it after \n> the first \"add\" and before \"commit\". Otherwise only the previous \n> \"added\" state of that file will be committed.\n> \n\"This is because git tracks content, so what you're really 'add'ing to \nthe commit is the *content* of the file in the state it is in when you \n'add' it.\"\n\n\n> 2) By using \"git commit -a\" directly\n> \n> This is a quick way to automatically \"add\" all modified files to \n\n.. \"add\" all tracked and modified files to ...\n\n> the set of changes and perform the actual commit without having to \n> separately \"add\" them. This will not \"add\" new files -- those \n> files still have to be added explicitly before performing a commit.\n> \n> Here's a twist. If you do \"git commit ...\" then \n> only the changes belonging to those explicitly specified files will \n> be committed, entirely bypassing the current \"added\" changes. Those\n> \"added\" changes will still remain available for a subsequent commit.\n> \n> There is a twist about that twist: if you do \"git commit -i ...\" \n> then the commit will consider changes to those specified files \n> _including_ all \"added\" changes so far.\n> \n> But for instance it is best to only remember \"git add\" + \"git \n> commit\" and/or \"git commit -a\".\n> \n> Doesn't it sounds nice? The index is being introduced up front without \n> even mentioning it, and I think the above should be fairly palatable to \n> newbies as well. Would only lack some enhancements to the commit \n> template and the \"nothing to commit\" message so the user is cued about \n> the fact that \"current changeset is empty -- don't forget to 'git add' \n> modified files, or use 'git commit -a'\".\n> \n> What do you think?\n> \n\nme likes\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\n"},{"id":"296615","messageId":"456FF664.3060109@xs4all.nl","threadId":"43105","inReplyTo":"456FEB53.7080703@op5.se","subject":"Re: [PATCH 0/2] Making \"git commit\" to mean \"git commit -a\".","fromName":"Han-Wen Nienhuys","fromEmail":"hanwen@xs4all.nl","sentAt":"2006-12-01T09:31:16Z","receivedAt":"2006-12-01T09:31:16Z","isPatch":true,"sender":{"key":"hanwen@google.com","avatar":"https://avatars.githubusercontent.com/u/31547?v=4"},"body":"Andreas Ericsson escreveu:\n> Carl Worth wrote:\n>>\n>> See? Git _is_ harder to learn, and a user really cannot learn it\n>> without being careful about the index right from the very beginning.\n>>\n> \n> I'm not so sure about that. I came from CVS / SVN, although I've fiddled\n> quite a bit with other scm's as well. The two-step commit process of git\n> didn't terrify me at all, and I had used git at least a month before I\n> joined the mailing-list and found out that there's this thing called an\n\nI still don't know exactly how to operate adds and commits from the\ncommand line. I regularly get bitten by not supplying the -a and -i\noptions.\n\nI'm coming from darcs, where you can select which each diff hunk\nto put in a commit separately.\n\nHowever, I almost never do that. I operate git like darcs, from the\nemacs support mode. I almost never do -a commits anyway, because with\nemacs (M-x git-status) it's more natural to make functionally distinct\ncommits, at the risk of introducing non-tested tree states in the\nrepository.\n\n-- \n"},{"id":"294061","messageId":"20061201182740.GB31025@spearce.org","threadId":"43105","inReplyTo":"eknj33$q2r$1@sea.gmane.org","subject":"Re: [PATCH 0/2] Making \"git commit\" to mean \"git commit -a\".","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-12-01T18:27:40Z","receivedAt":"2006-12-01T18:27:40Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Jakub Narebski wrote:\n> Robert Shearman wrote:\n> \n> > Having the index exposed for even simple operations means that the user \n> > has to initially learn three states instead of two. The worst thing \n> > about the index is that it is a limbo state. The committed content is in \n> > the history and can be viewed by gitk (and other tools that the user \n> > will be introduced to later) and the working tree is exactly what the \n> > user sees in their editor. Having a hidden state isn't very good from an \n> > HCI point of view.\n> \n> Index is accessible, just like committed contents. The fact that gitk, qgit,\n> git-gui doesn't display state of index is their limitation.\n\nActually git-gui shows the index, but not quite as well as diff\nand friends would.\n\nBut based on this thread I had a major realization: git-gui is\ntotally wrong in how it displays files (and therefore gitool is\ntoo!). I'm going to rewrite that part of git-gui's UI, hopefully\nearly next week.\n\nLinus is right: To deny the index is to deny git itself. Trying to\nhide part of the index in git-gui is just wrong and makes things\nlike merge conflict resolutions harder, not easier.\n\n-- \n"},{"id":"297000","messageId":"200612012333.16588.alan@chandlerfamily.org.uk","threadId":"43105","inReplyTo":"200612010834.22916.andyparkins@gmail.com","subject":"Re: [PATCH 0/2] Making \"git commit\" to mean \"git commit -a\".","fromName":"Alan Chandler","fromEmail":"alan@chandlerfamily.org.uk","sentAt":"2006-12-01T23:33:16Z","receivedAt":"2006-12-01T23:33:16Z","isPatch":true,"sender":{"key":"alan@chandlerfamily.org.uk","avatar":"https://gravatar.com/avatar/1862247e5ea8eac114c842f9dc3a5db6253754e24ef7171757cf97eedce48b8c?d=mp&s=160"},"body":"On Friday 01 December 2006 08:34, Andy Parkins wrote:\n> How about this:\n...\n>\n> Hence,\n>\n> git-add becomes git-prepare and does\n\nWhy can't it stay as git-add\n\nIt means \"add the current state of the content to the index\"\n\nIt has the useful property that git-commit -a can be seen as a short cut for \nadd all the files in the working try and commit. \n\n\n-- \nAlan Chandler\n"},{"id":"297810","messageId":"200612012336.39154.alan@chandlerfamily.org.uk","threadId":"43105","inReplyTo":"456FEED4.7030400@op5.se","subject":"Re: [PATCH 0/2] Making \"git commit\" to mean \"git commit -a\".","fromName":"Alan Chandler","fromEmail":"alan@chandlerfamily.org.uk","sentAt":"2006-12-01T23:36:39Z","receivedAt":"2006-12-01T23:36:39Z","isPatch":true,"sender":{"key":"alan@chandlerfamily.org.uk","avatar":"https://gravatar.com/avatar/1862247e5ea8eac114c842f9dc3a5db6253754e24ef7171757cf97eedce48b8c?d=mp&s=160"},"body":"On Friday 01 December 2006 08:59, Andreas Ericsson wrote:\n> Nicolas Pitre wrote:\n>\n> > 2) By using \"git commit -a\" directly\n> >\n> > This is a quick way to automatically \"add\" all modified files to\n>\n> .. \"add\" all tracked and modified files to ...\n\nadd all tracked and modified content\n\n>\n...\n>\n> me likes\n\nme too\n-- \nAlan Chandler\n"},{"id":"293851","messageId":"e5bfff550612012348g4c6bc53bqbc0ff8633ea1a51a@mail.gmail.com","threadId":"43105","inReplyTo":"eknj33$q2r$1@sea.gmane.org","subject":"Re: [PATCH 0/2] Making \"git commit\" to mean \"git commit -a\".","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2006-12-02T07:48:33Z","receivedAt":"2006-12-02T07:48:33Z","isPatch":true,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":">\n> Index is accessible, just like committed contents. The fact that gitk, qgit,\n> git-gui doesn't display state of index is their limitation.\n> --\n\nActually qgit let's you see state index for each file when committing\nwith qgit commit dialog.\n\nIndeed you can also choose to update only the index state of a file\nwithout committing, ie without create a new tree object.\n\nInternally, the index state of each file is known and tracked. No\nother interface is provided, as example a diff, just because I found\nit confusing and of little concrete help.\n\nOf course if knowning the index state became important to perform some\nconcrete and quite common operation I could add whatever GUI would\nsuite.\n\nSuggestions are welcomed ;-)\n\n"}]}