{"thread":{"id":"7999","subject":"[FAQ?] Rationale for git's way to manage the index","startedAt":"2007-05-06T16:10:22Z","lastAt":"2007-05-15T23:27:40Z","messageCount":71,"participants":["Matthieu Moy","Johannes Schindelin","Linus Torvalds","Junio C Hamano","Dana How","Julian Phillips","Karl Hasselström","Guilhem Bonnefille","David Kastrup","Daniel Barkalow","Shawn O. Pearce","Martin Langhoff","Johannes Sixt","J. Bruce Fields","Petr Baudis","Carl Worth","Steven Grimm","Jakub Narebski","David Kågedal"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"41216","messageId":"vpqwszm9bm9.fsf@bauges.imag.fr","threadId":"7999","inReplyTo":null,"subject":"[FAQ?] Rationale for git's way to manage the index","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2007-05-06T16:10:22Z","receivedAt":"2007-05-06T16:10:22Z","isPatch":false,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"Hi,\n\nI've read the manual, and I belive I have a correct understanding of\nhow the index works, technically speaking. Still, I'm not clear about\nthe rational for such design.\n\nAlmost any other decent system has an equivalent to cache the stat\ninformation (bzr calls this stat-cache, hg calls it dirstate IIRC).\nThat is, if your run \"$vcs diff\" twice, the second run will only need\nto stat all files, never diff them.\n\nBut the fact that git actually remembers the _content_ of files in the\nindex, and that the default behavior for \"commit\" is to commit only\nthe content that is explicitely \"git add\"ed is something I've never\nseen outside git.\n\nAt first, I find it rather annoying. My usual workflow is\n\n\n% $vcs status\n% $vcs commit -m \"describe whatever I did\"\n\n...\n\nWith git, i'd do\n\n\n% git status\n% git add X\n% git add Y\n% git status\n% git commit\n\nor\n\n\n% git satus -a\n% git commit -a -m \"...\"\n\nIn the former case, I have more commands to type, and in the second\ncase, I loose part of the stat-cache benefit: If I run \"git status -a\"\ntwice, the second run will actually diff all the files touched since\nthe last run, since \"git status -a\" actually updated a temporary\nindex, and discarded it afterwards, so it doesn't update the stat\ninformation in the index (while \"git status\" would have).\n\nIn both cases, I can't really see the benefit. I'm pretty sure this is\na FAQ, and I'm also pretty sure there are good arguments for it, but I\ncan't find it anywhere.\n\nThanks for your answers,\n\n-- \nMatthieu\n"},{"id":"41221","messageId":"Pine.LNX.4.64.0705061851411.4015@racer.site","threadId":"7999","inReplyTo":"vpqwszm9bm9.fsf@bauges.imag.fr","subject":"Re: [FAQ?] Rationale for git's way to manage the index","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-05-06T16:51:48Z","receivedAt":"2007-05-06T16:51:48Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 6 May 2007, Matthieu Moy wrote:\n\n> [...]\n>\n> % git satus -a\n> % git commit -a -m \"...\"\n> \n> In the former case, I have more commands to type, and in the second\n> case, I loose part of the stat-cache benefit: If I run \"git status -a\"\n> twice, the second run will actually diff all the files touched since\n> the last run, since \"git status -a\" actually updated a temporary\n> index, and discarded it afterwards, so it doesn't update the stat\n> information in the index (while \"git status\" would have).\n\nHave you tried \"git status\" _without \"-a\"?\n\n> In both cases, I can't really see the benefit.\n\nThe benefit is a clear distinguishing between DWIM and low level. The \nindex contains _exactly_ what you told it to contain. By forcing users to \nuse \"-a\" with \"git commit\", you make it clear that a separate update \nsteo is involved, and if you made an error (which you see from the file \nlist), you can abort, and start over with the original index.\n\nHth,\nDscho\n"},{"id":"41223","messageId":"alpine.LFD.0.98.0705060951460.25245@woody.linux-foundation.org","threadId":"7999","inReplyTo":"vpqwszm9bm9.fsf@bauges.imag.fr","subject":"Re: [FAQ?] Rationale for git's way to manage the index","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-05-06T17:25:16Z","receivedAt":"2007-05-06T17:25:16Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sun, 6 May 2007, Matthieu Moy wrote:\n> \n> But the fact that git actually remembers the _content_ of files in the\n> index, and that the default behavior for \"commit\" is to commit only\n> the content that is explicitely \"git add\"ed is something I've never\n> seen outside git.\n\nYeah. You'd better get used to it, because it's fundamental.\n\nHere's the rationale list:\n\n - It's fundamentally the only sane thing to do.\n\n Git tracks content at _all_ levels, not \"files\". So this is more than \n an implementation issue, it's a fundamental \"how the world works\" \n issue. The fact that everybody else gets it wrong is _their_ problem. \n\n [ Corollary: the fact that your brain has rotted from using those \n broken systems is obviously your problem, and sadly, there's nothing \n else we can do than try to show the right way and hope that the \n neurons re-generate. CVS has caused endless suffering, this is just \n one small example of it ]\n\n - You fundamentally cannot do it any other way. \n\n Not doing it the way git does it (point to the content) means that the \n index-replacement has to point to something else, namely a \"file ID\". \n\n That's so broken as to be really really sad. In CVS, for example, there \n obviously isn't any \"file ID\", so what does the \"index\" in CVS point \n at? \n\n Right. The \"index\" in CVS is the Entries file, and it not only lacks \n stat information, it also lacks any other information, which means that \n the \"file ID\" is _literally_ just the pathname itself. That causes \n obvious problems, so nobody sane would ever suggest that this is a good \n idea.\n\n So what do other people use? They tend to not have understood the \n \"content is king\" thing (which is what git uses), so they add somethng \n *else* to the \"index\" file than the content. What can I say? People are \n morons. I'm constantly amazed at just how stupid SCM people seem to be.\n\n In most systems, that \"something else\" is a \"file ID\". That just means \n that they are fundamentally broken whenever they do any trivial merge \n with renames. Just don't do it. I've talked before about why tracking \n file ID's is wrong - it's just as wrong as thinking that the \"ID\" of a \n file is the path. \n\n - Tracking content in the index is fundamentally how and why git can do \n merges so much better than anything else, and how we handle conflicts \n gracefully.\n\n Trust me, you haven't seen good merge conflict support until you've \n done a git merge, and realized that you can do things like just\n\n\tgit diff\n\n to see just the *conflicting* parts, not the stuff you don't need to \n worry about. And it's why you can do\n\n\tgit diff --base/--ours/--theirs\n\n to see what the diffs of the conflicting files are wrt the versions \n that got us there. Again, a big part of this is that the index tracks \n *content* rather than some totally idiotic secondary notion that has \n nothing to do with anything sane.\n\nThat's the three major reasons. The first one may not seem relevant to \nyou, but when you start to understand that \"content is the only thing that \nmatters\", you'll move to a whole new level. Not just in git, but in \ngeneral. So the first argument is purely philosophical, but it's still \nimportant.\n\nThe two other rationales are purely practical. It's why git is simply \n_better_ than the alternatives. It's why git can do things that others \ncannot do, or that they have to do strange and weird things for, and git \ndoes totally naturally without having to even think about it.\n\nA file-ID-based thing will always have fundamental problems with file ID \nclashes - issues that cause annoyances both small and big. Git just \ndoesn't have that fundamental design bug.\n\n> At first, I find it rather annoying. My usual workflow is\n\nYou'll just need to get used to it. The git way is actually much better. \nYou'll get used to it quickly enough, but once you do, what's the problem \nwith the workflow you already quote:\n\n> \n> % git status -a\n> % git commit -a -m \"...\"\n\nWhat's so hard with adding that \"-a\" to \"git commit\"? You don't even need \nit on the status line, the status is relevant and understandable (and \nactually tells you more) even without it.\n\n> In the former case, I have more commands to type, and in the second\n> case, I loose part of the stat-cache benefit: If I run \"git status -a\"\n> twice, the second run will actually diff all the files touched since\n> the last run, since \"git status -a\" actually updated a temporary\n> index, and discarded it afterwards, so it doesn't update the stat\n> information in the index (while \"git status\" would have).\n\nWHY do you care?\n\nGit is still about an order of magnitude faster than anything that you can \ncompare with, so I really don't see what you're complaining about?\n\nYou seem to be complaining about the fact that:\n\n - git does extra and unnecessary work when you give it an extra and \n unnecessary flag (the \"-a\" to \"git status\".\n\n - despite the fact that you can make git do unnecessary things, I can \n pretty much guarantee that your workflow is still faster with git than \n with pretty much anything else, so why complain?\n\nSo both of your complaints seem to be a bit pointless to me. But the real \nanswer really is:\n\n - git does things better, and the git approach actually allows you a \n better workflow. Now, admittedly that better workflow is especially \n notable when you have a merge conflict or other nastier situation and \n not as obvious when you just don't do anything exciting, but it's \n actually also more *logical* even in the absense of any merge issues \n (ie the whole \"content vs filenames\" issue).\n\n - but git doesn't *force* that better workflow, and you can always just \n use \"git commit -a\" to emulate the stupidity that is CVS and SVN. \n\nBasically, I use the \"git commit -a\" for all the trivial cases, but \nequally often I carry around independent changes in my tree (often for \nlong times - right now my tree has some experimental stuff I haven't \ncommitted yet in fs/ext3/ialloc.c for example) and I work with a dirty \ntree and commit and change _parts_ of it. And then the \"-a\" thing is \nwrong, and having it as the default would just cause mistakes.\n\nSo git really does the right thing, for so many reasons. But yeah, the \nright thing is different from what CVS does. \n\n(That statement is so true that it basically could be used ass a \ndefinition of CVS: \"tThe right thing is different from what CVS does\" is \nnot about the index, it's about almost _everything_)\n\n\t\tLinus\n"},{"id":"41225","messageId":"vpqk5vlamav.fsf@bauges.imag.fr","threadId":"7999","inReplyTo":"Pine.LNX.4.64.0705061851411.4015@racer.site","subject":"Re: [FAQ?] Rationale for git's way to manage the index","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2007-05-06T17:34:16Z","receivedAt":"2007-05-06T17:34:16Z","isPatch":false,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"Johannes Schindelin writes:\n\n> Hi,\n>\n> On Sun, 6 May 2007, Matthieu Moy wrote:\n>\n>> [...]\n>>\n>> % git satus -a\n>> % git commit -a -m \"...\"\n>> \n>> In the former case, I have more commands to type, and in the second\n>> case, I loose part of the stat-cache benefit: If I run \"git status -a\"\n>> twice, the second run will actually diff all the files touched since\n>> the last run, since \"git status -a\" actually updated a temporary\n>> index, and discarded it afterwards, so it doesn't update the stat\n>> information in the index (while \"git status\" would have).\n>\n> Have you tried \"git status\" _without_ \"-a\"?\n\nReading my message (including the last 5 words of the sentence you're\nquoting) would have told you that ;-).\n\n>> In both cases, I can't really see the benefit.\n>\n> The benefit is a clear distinguishing between DWIM and low level. The \n> index contains _exactly_ what you told it to contain. \n\nIn other systems, commit commits _exactly_ the content of files on\ndisk. And most people seem happy with that.\n\n> By forcing users to use \"-a\" with \"git commit\",\n\nDoes this mean that the normal way to use \"commit\" is to use \"-a\"?\n\n> you make it clear that a separate update steo is involved,\n\nWell, with those kind of arguments, I could have my web browser not do\nDNS resolution for me, because it would make it clear that a separate\nstep from HTTP request is involved. Still, this low-level thing brings\nno benefit to the user, and I know no web browser forcing the user to\nmake this distinction.\n\n> and if you made an error (which you see from the file list), you can\n> abort, and start over with the original index.\n\nYou don't necessarily see your error from the file list:\n\n% vi foo.c\n% git add foo.c\n% vi foo.c\n% git commit -m foo\n[...]\n create mode 100644 foo.c\n%\n\nThis commited the old content of foo.c, while I hardly see any\nscenario where this is the expected behavior.\n\nThen, being able to repare the error if I made it is interesting, but\nI don't get the reason why the error could not just be avoided.\n\nWell, indeed, I just found a thread talking about this:\n\n http://lists-archives.org/git/196050-making-git-commit-to-mean-git-commit-a.html\n\nI'll go through it, I might understand better after that ;-).\n\nThanks,\n\n-- \nMatthieu\n"},{"id":"41227","messageId":"7vvef5c0fw.fsf@assigned-by-dhcp.cox.net","threadId":"7999","inReplyTo":"vpqk5vlamav.fsf@bauges.imag.fr","subject":"Re: [FAQ?] Rationale for git's way to manage the index","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-05-06T17:43:31Z","receivedAt":"2007-05-06T17:43:31Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthieu Moy writes:\n\n> You don't necessarily see your error from the file list:\n>\n> % vi foo.c\n> % git add foo.c\n> % vi foo.c\n> % git commit -m foo\n> [...]\n> create mode 100644 foo.c\n> %\n>\n> This commited the old content of foo.c, while I hardly see any\n> scenario where this is the expected behavior.\n\nOne reason why is because you are using \"-m foo\" (a very\nnon-descriptive commit message that would not help anybody\nincluding yourself in the future). Try the above without giving\nsuch a bogus error message with \"-m\" to commit, but instead let\nit spawn your editor --- you would be doing that in real-life\nwhen you are doing anything nontrivial. Then notice what\nappears on the file list of \"Changed but not updated\" section.\n\nA single liner \"-m\" is handy for \"Oops, typofix in foo.c\" kind\nof commit, but in such a case you literally would be changing\nonly the typofix and won't have \"edit foo.c; git add foo.c; edit\nfoo.c; git commit\" sequence anyway.\n\nI think Linus explained quite well to correct your doubts in\nyour original message, and I do not have anything to add.\n"},{"id":"41232","messageId":"56b7f5510705061122l31304931l8471f11f57f00b19@mail.gmail.com","threadId":"7999","inReplyTo":"vpqk5vlamav.fsf@bauges.imag.fr","subject":"Re: [FAQ?] Rationale for git's way to manage the index","fromName":"Dana How","fromEmail":"danahow@gmail.com","sentAt":"2007-05-06T18:22:09Z","receivedAt":"2007-05-06T18:22:09Z","isPatch":false,"sender":{"key":"danahow@gmail.com","avatar":null},"body":"You might find it useful to break your question into 2 pieces.\n\nOne is what information should be in the index,\nwhich essentially is what Linus addresses.\nThe way I look at this, at the moment,\nis that the index contains whatever's required to make git-write-tree\nwork without collecting information elsewhere.\nI suspect this is the correct historical way to look at this,\nbut I wasn't on this list then.\n\nThe other is how to get information into the index.\nI think this is the original thing that seemed strange to you?\nIt did to me. But, in part, since git has both \"git-commit\"\nand \"git-commit -a\", this is somewhat recognized.\nI've wondered if there's a way to improve this, but I don't\nhave any coherent ideas right now. Thanks for finding\nand posting that thread; that was helpful.\n\nAlso, the idea of an index isn't all that strange. I need\nto use perforce at work, and it has an index (called \"db.have\").\nBut it is stored on the server and has everyone's state mixed\ntogether, uses the type of file IDs Linus complains about,\nand is more difficult to manipulate (hence less useful).\nBeing on the server is a great performance bottleneck as well.\n\nDana\n\nOn 5/6/07, Matthieu Moy wrote:\n> Johannes Schindelin writes:\n>\n> > Hi,\n> >\n> > On Sun, 6 May 2007, Matthieu Moy wrote:\n> >\n> >> [...]\n> >>\n> >> % git satus -a\n> >> % git commit -a -m \"...\"\n> >>\n> >> In the former case, I have more commands to type, and in the second\n> >> case, I loose part of the stat-cache benefit: If I run \"git status -a\"\n> >> twice, the second run will actually diff all the files touched since\n> >> the last run, since \"git status -a\" actually updated a temporary\n> >> index, and discarded it afterwards, so it doesn't update the stat\n> >> information in the index (while \"git status\" would have).\n> >\n> > Have you tried \"git status\" _without_ \"-a\"?\n>\n> Reading my message (including the last 5 words of the sentence you're\n> quoting) would have told you that ;-).\n>\n> >> In both cases, I can't really see the benefit.\n> >\n> > The benefit is a clear distinguishing between DWIM and low level. The\n> > index contains _exactly_ what you told it to contain.\n>\n> In other systems, commit commits _exactly_ the content of files on\n> disk. And most people seem happy with that.\n>\n> > By forcing users to use \"-a\" with \"git commit\",\n>\n> Does this mean that the normal way to use \"commit\" is to use \"-a\"?\n>\n> > you make it clear that a separate update steo is involved,\n>\n> Well, with those kind of arguments, I could have my web browser not do\n> DNS resolution for me, because it would make it clear that a separate\n> step from HTTP request is involved. Still, this low-level thing brings\n> no benefit to the user, and I know no web browser forcing the user to\n> make this distinction.\n>\n> > and if you made an error (which you see from the file list), you can\n> > abort, and start over with the original index.\n>\n> You don't necessarily see your error from the file list:\n>\n> % vi foo.c\n> % git add foo.c\n> % vi foo.c\n> % git commit -m foo\n> [...]\n> create mode 100644 foo.c\n> %\n>\n> This commited the old content of foo.c, while I hardly see any\n> scenario where this is the expected behavior.\n>\n> Then, being able to repare the error if I made it is interesting, but\n> I don't get the reason why the error could not just be avoided.\n>\n> Well, indeed, I just found a thread talking about this:\n>\n> http://lists-archives.org/git/196050-making-git-commit-to-mean-git-commit-a.html\n>\n> I'll go through it, I might understand better after that ;-).\n>\n> Thanks,\n>\n> --\n> Matthieu\n> -\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n>\n\n\n-- \nDana L. How danahow@gmail.com +1 650 804 5991 cell\n"},{"id":"41233","messageId":"vpqbqgxak1i.fsf@bauges.imag.fr","threadId":"7999","inReplyTo":"alpine.LFD.0.98.0705060951460.25245@woody.linux-foundation.org","subject":"Re: [FAQ?] Rationale for git's way to manage the index","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2007-05-06T18:23:05Z","receivedAt":"2007-05-06T18:23:05Z","isPatch":false,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"Linus Torvalds writes:\n\n> On Sun, 6 May 2007, Matthieu Moy wrote:\n>> \n>> But the fact that git actually remembers the _content_ of files in the\n>> index, and that the default behavior for \"commit\" is to commit only\n>> the content that is explicitely \"git add\"ed is something I've never\n>> seen outside git.\n>\n> Yeah. You'd better get used to it, because it's fundamental.\n\nThanks a lot for the detailed explanations.\n\nNote that I'm not \"complaining\", but just not understanding something.\n\n(I would actually complain about the documentation not being clear\nenough, but I'll try to complain with a contribution instead ;-) I'll\nadd something to the FAQ on the wiki, but it's down right now).\n\n> - You fundamentally cannot do it any other way.\n>\n> Not doing it the way git does it (point to the content) means that the \n> index-replacement has to point to something else, namely a \"file ID\". \n\nWell, git's index still tells more than \"the content FOOBAR exists,\nsomewhere\". It also \"contains\", if not \"points to\", the file name.\n\n> What's so hard with adding that \"-a\" to \"git commit\"? You don't even need \n> it on the status line, the status is relevant and understandable (and \n> actually tells you more) even without it.\n\nOff course, I don't have strong argument against it. The biggest\nannoyance is that my fingers are used to \"commit -m message\", and now\ntype \"commit -a message\", but ...\n\nThe reason why I'm posting this is that I was wondering whether\n\"commit -a\" not being the default was supposed to be a message like\n\"you shouln't use it too often\".\n\nIt seems it isn't. I'll just get used to \"commit -a\" (and probably\nalias it), and discover the actual benefits of the index little by\nlittle.\n\n> [...] it basically could be used ass a definition of CVS: [...]\n ^^^\nNot sure this was intentional, but your spelling of \"as\" when used to\ntalk about CVS seems to reveal something about your state of mind ;-).\n\nThanks,\n\n-- \nMatthieu\n"},{"id":"41245","messageId":"alpine.LFD.0.98.0705061243490.25245@woody.linux-foundation.org","threadId":"7999","inReplyTo":"vpqbqgxak1i.fsf@bauges.imag.fr","subject":"Re: [FAQ?] Rationale for git's way to manage the index","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-05-06T19:54:10Z","receivedAt":"2007-05-06T19:54:10Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sun, 6 May 2007, Matthieu Moy wrote:\n> \n> Well, git's index still tells more than \"the content FOOBAR exists,\n> somewhere\". It also \"contains\", if not \"points to\", the file name.\n\nIndeed. \n\nGit's index is basically very much defined as\n\n - sufficient to contain the total \"content\" of the tree (and this \n includes all metadata: the filename, the mode, and the file contents \n are all *parts* of the \"content\", and they are all meaningless on their \n own!)\n\n - additional \"stat\" information to allow the obvious and trivial (but \n hugely important!) filesystem comparison optimizations.\n\nSo you really should see it as *being* the content. The content is not the \n\"file name\" or the \"file content\" as separate parts. You really cannot \nseparate the two. Filenames on their own make no sense (they have to have \nfile content too), and file content on its own is similarly senseless (you \nhave to know how to reach it).\n\nWhat I'm trying to say is that git fundmaentally doesn't _allow_ you to \nsee a filename without its content. The whole notion is insane and not \nvalid. It has no relevance for \"reality\".\n\nAlso, you should realize that when you do\n\n\tgit add X\n\nyou are *not* adding the filename X. No, \"X\" is literally a \"content path \npattern\", the same way it is when you do something like\n\n\tgitk X\n\nand it's worth always keeping in mind that in neither case is \"X\" \nnecessarily a single file, but literally a pathname pattern that is used \nas a \"filter\" on all the possible patterns.\n\n(Of course, the filtering rules are different for \"git add\" and \"gitk\": in \nthe \"git add\" example, you filter the working tree files, while in \"gitk\" \nyou filter the files that git already knows about, so they are different, \nbut in both cases you really should think of them as filters, not as \n\"filenames\", even though one _trivial_ filter is to give a filter that \nmatches exactly one pathname).\n\n> The reason why I'm posting this is that I was wondering whether\n> \"commit -a\" not being the default was supposed to be a message like\n> \"you shouln't use it too often\".\n\nNo, \"git commit -a\" is undoubtedly _convenient_. You can use it as often \nas you like.\n\nSo as long as you see it as a convenience feature, and realize that \"git \ncommit\" is actually a lot more powerful than just being able to always do \nthe convenient, go on and use \"git commit -a\" all the time.\n\nWhen you hit a situation where you want to do something slightly subtler, \nyou'll suddenly be really happy that you always had the convenience \nfeature, but that git didn't make you think that it was how you _had_ to \nwork.\n\n> > [...] it basically could be used ass a definition of CVS: [...]\n> ^^^\n> Not sure this was intentional, but your spelling of \"as\" when used to\n> talk about CVS seems to reveal something about your state of mind ;-).\n\nIndeed ;)\n\nFreudian slip. But yes, I'm really down on CVS. The only thing I like less \nthan CVS is SVN, and that's just because I think it's such a sad waste, \nnot because it's actually _worse_ than CVS. (Ie I dislike SVN from a \"it \ncould have been so much better\" perspective).\n\n\t\t\tLinus\n"},{"id":"41259","messageId":"Pine.LNX.4.64.0705062344230.29485@reaper.quantumfyre.co.uk","threadId":"7999","inReplyTo":"vpqbqgxak1i.fsf@bauges.imag.fr","subject":"Re: [FAQ?] Rationale for git's way to manage the index","fromName":"Julian Phillips","fromEmail":"julian@quantumfyre.co.uk","sentAt":"2007-05-06T22:53:13Z","receivedAt":"2007-05-06T22:53:13Z","isPatch":false,"sender":{"key":"julian@quantumfyre.co.uk","avatar":"https://avatars.githubusercontent.com/u/948888?v=4"},"body":"On Sun, 6 May 2007, Matthieu Moy wrote:\n\n> The reason why I'm posting this is that I was wondering whether\n> \"commit -a\" not being the default was supposed to be a message like\n> \"you shouln't use it too often\".\n\nWell, personally I practically never use it, I find that having a \nseparation between what the current state of my tree is and what will be \ncomitted to be one of the really \"oh wow, why doens't everything else do \nthis?\" features. However, i tend to be working on more than one thing at \nonce, and switch between them - so I commit work on A while work on B is \nstill unfinished, then start C, finish B some point later and commit it, \nand then I can finish C. Git is the first VCS that supports a butterfly \nmind :P.\n\n> It seems it isn't. I'll just get used to \"commit -a\" (and probably\n> alias it), and discover the actual benefits of the index little by\n> little.\n\n\"git add -i\" - this is a feature I have wanted since I started using \nversion control ...\n\n-- \nJulian\n\n ---\nYour good nature will bring you unbounded happiness.\n"},{"id":"41273","messageId":"Pine.LNX.4.64.0705070127180.4167@racer.site","threadId":"7999","inReplyTo":"vpqk5vlamav.fsf@bauges.imag.fr","subject":"Re: [FAQ?] Rationale for git's way to manage the index","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-05-06T23:42:16Z","receivedAt":"2007-05-06T23:42:16Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Matthieu,\n\nOn Sun, 6 May 2007, Matthieu Moy wrote:\n\n> Johannes Schindelin writes:\n> \n> > On Sun, 6 May 2007, Matthieu Moy wrote:\n> >\n> >> [...]\n> >>\n> >> % git satus -a\n> >> % git commit -a -m \"...\"\n> >> \n> >> In the former case, I have more commands to type, and in the second\n> >> case, I loose part of the stat-cache benefit: If I run \"git status -a\"\n> >> twice, the second run will actually diff all the files touched since\n> >> the last run, since \"git status -a\" actually updated a temporary\n> >> index, and discarded it afterwards, so it doesn't update the stat\n> >> information in the index (while \"git status\" would have).\n> >\n> > Have you tried \"git status\" _without_ \"-a\"?\n> \n> Reading my message (including the last 5 words of the sentence you're \n> quoting) would have told you that ;-).\n\nOkay, I rephrase the (badly worded) question:\n\nWhy did you use \"-a\" with \"git status\" to begin with? It's useless.\n\n> >> In both cases, I can't really see the benefit.\n> >\n> > The benefit is a clear distinguishing between DWIM and low level. The \n> > index contains _exactly_ what you told it to contain.\n> \n> In other systems, commit commits _exactly_ the content of files on\n> disk. And most people seem happy with that.\n\nBecause they do not realize that the file _names_ are actually only a key, \nnot the value.\n\nWith Git, it is possible to stage changes, but also to have a dirty stage.\n\nThink, for example, about debugging a program. Many programs have \nMakefiles, which define CFLAGS without \"-g\". Now you want to debug. Since \ngdb acquired the bad habit of not working properly at all without that \nflag (which is especially apparent when single stepping jumps around \nwildly in the source code), you _have_ to change the Makefile to include \n\"-g\" with the CFLAGS.\n\nBut you don't want to commit _that_. It is no useful change for the \nproject. Submitting such a patch makes you look foolish. So, you leave it \nout of the commit.\n\nAnd to make you _aware_ that it is a real possibility, and often a \ndesirable one, git-commit makes you specify \"-a\" when you are _sure_ that \nyou want to commit _all_ of your changes to the tracked files.\n\nWith CVS (which has been bashed on a lot on this list, and rightfully so), \nafter a mistaken \"cvs commit\" _with_ irrelevant changes, like the change \nto the Makefile I illustrated above), you have two options:\n\n\t- leave it as it is (possibly undoing the change in a subsequent \n\t commit), or\n\n\t- edit the files, which often leads to an inconsistent repository. \n\t Yeah, sure, you can checkout the newest state, but you cannot \n\t reproduce known older states.\n\n> > By forcing users to use \"-a\" with \"git commit\",\n> \n> Does this mean that the normal way to use \"commit\" is to use \"-a\"?\n\nWell, I use it quite a lot. But 30% of the time, I prefer to commit with \nspecific filenames, so I can be sure _what_ I commit. FWIW, I picked up on \nthat practice when using CVS...\n\nThere are even about 20% of the time, when I use \"git commit\" _without_ \nany parameters, because I used \"git add\" to tell Git that I resolved some \nconflicts, or that I want this file to be committed, while other files \nshould not be committed.\n\n> > you make it clear that a separate update steo is involved,\n> \n> Well, with those kind of arguments, I could have my web browser not do\n> DNS resolution for me, because it would make it clear that a separate\n> step from HTTP request is involved.\n\nNo. _You_ never need to tell the browser _not_ to resolve via DNS.\n\nBut _you_ sometimes _need_ to commit with _different_ parameters than \n\"-a\". You might not realize that _now_. But at least specifying \"-a\" \neverytime you do your thing gives you a _chance_ to realize it.\n\n> > and if you made an error (which you see from the file list), you can\n> > abort, and start over with the original index.\n> \n> You don't necessarily see your error from the file list:\n> \n> % vi foo.c\n> % git add foo.c\n> % vi foo.c\n> % git commit -m foo\n\nAs others have commented, \"-m\" is a _bad_ option. Yes, for ease of use, it \nis provided.\n\nBut how useful is a commit message which consists of less than five words?\n\nIt does _not_ tell you,\n\n\t- what the _conceptual_ change was,\n\t- _why_ it was done,\n\t- _how_ it was done, and\n\t- what the rationale of the committer was, for the case that \n\t people try to come up with a cleverer patch, to prevent \n\t unnecessary rethinking.\n\nCiao,\nDscho\n"},{"id":"41274","messageId":"Pine.LNX.4.64.0705070146140.4167@racer.site","threadId":"7999","inReplyTo":"vpqbqgxak1i.fsf@bauges.imag.fr","subject":"Re: [FAQ?] Rationale for git's way to manage the index","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-05-06T23:51:38Z","receivedAt":"2007-05-06T23:51:38Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 6 May 2007, Matthieu Moy wrote:\n\n> Linus Torvalds writes:\n> \n> > - You fundamentally cannot do it any other way.\n> >\n> > Not doing it the way git does it (point to the content) means that the \n> > index-replacement has to point to something else, namely a \"file ID\". \n> \n> Well, git's index still tells more than \"the content FOOBAR exists,\n> somewhere\". It also \"contains\", if not \"points to\", the file name.\n\nAs you pointed out yourself, the index _has_ an idea of the content of \nthat file. So, arguably, it does not point to _that_ file, but rather to \nthat file _with a certain content_.\n\n> > What's so hard with adding that \"-a\" to \"git commit\"? You don't even need \n> > it on the status line, the status is relevant and understandable (and \n> > actually tells you more) even without it.\n> \n> Off course, I don't have strong argument against it. The biggest\n> annoyance is that my fingers are used to \"commit -m message\", and now\n> type \"commit -a message\", but ...\n\nJust another reason to hate CVS. Because it trained people to do that. If \nit was not for the training by CVS, I would have strongly opposed to the \nintroduction of the \"-m\" switch to commit. It _encourages_ bad commit \nmessages.\n\nNow, with Git I usually let git-commit start up the editor. Because then I \nam actually encouraged to make up my mind, and put down a meaningful \nmessage, which might not only help _others_ to understand why I did it, \nand how, but also _myself_ (after a few months).\n\n> The reason why I'm posting this is that I was wondering whether \"commit \n> -a\" not being the default was supposed to be a message like \"you \n> shouln't use it too often\".\n\nIMHO yes, that is the message.\n\nIn addition to being nice to people used to the behaviour of \"git commit\" \n_without_ other arguments.\n\nCiao,\nDscho\n"},{"id":"41292","messageId":"20070507063505.GA31269@diana.vm.bytemark.co.uk","threadId":"7999","inReplyTo":"Pine.LNX.4.64.0705062344230.29485@reaper.quantumfyre.co.uk","subject":"Re: [FAQ?] Rationale for git's way to manage the index","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2007-05-07T06:35:05Z","receivedAt":"2007-05-07T06:35:05Z","isPatch":false,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2007-05-06 23:53:13 +0100, Julian Phillips wrote:\n\n> On Sun, 6 May 2007, Matthieu Moy wrote:\n>\n> > The reason why I'm posting this is that I was wondering whether\n> > \"commit -a\" not being the default was supposed to be a message\n> > like \"you shouln't use it too often\".\n>\n> Well, personally I practically never use it, I find that having a\n> separation between what the current state of my tree is and what\n> will be comitted to be one of the really \"oh wow, why doens't\n> everything else do this?\" features. However, i tend to be working on\n> more than one thing at once, and switch between them - so I commit\n> work on A while work on B is still unfinished, then start C, finish\n> B some point later and commit it, and then I can finish C. Git is\n> the first VCS that supports a butterfly mind :P.\n\ngit-gui is really handy for adding/committing a subset of the changes\nin your working tree. Especially for those of us with goldfish memory,\nsince it's so easy to see exactly what's happening: what's going to be\ncommitted and what not.\n\n> \"git add -i\" - this is a feature I have wanted since I started using\n> version control ...\n\nI thought \"git add -i\" was the best thing since sliced bread -- until\nI found the same feature in git-gui, but with a _much_ better\ninterface. Just right-click on a hunk in a diff, and you have the\noption of staging/unstaging that hunk. Pure magic.\n\n-- \nKarl Hasselström, kha@treskal.com\n www.treskal.com/kalle\n"},{"id":"41303","messageId":"vpqd51duklo.fsf@bauges.imag.fr","threadId":"7999","inReplyTo":"Pine.LNX.4.64.0705070146140.4167@racer.site","subject":"Re: [FAQ?] Rationale for git's way to manage the index","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2007-05-07T08:02:59Z","receivedAt":"2007-05-07T08:02:59Z","isPatch":false,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"Johannes Schindelin writes:\n\n> Just another reason to hate CVS. Because it trained people to do that. If \n> it was not for the training by CVS, I would have strongly opposed to the \n> introduction of the \"-m\" switch to commit. It _encourages_ bad commit \n> messages.\n\nWell, this really depends on the use-case, size of commit, ...\n\nI often use a version control system for very low importance stuff. I\ndon't want to type a 3-lines long message to describe a 2-lines long\nchange in my ~/.emacs.el for example. I also work with people using\n(sorry) svn to work collaboratively, but they don't even provide a log\nmessage: the version control system here is just a replacement for\nunison/NFS/whatever other way to have people edit files from different\nmachines.\n\nFor sure, in a context where code quality and review is important, \n-m \"xxx\" isn't the way (except if you prefer your shell's line editor\nto your actual editor).\n\n-- \nMatthieu\n"},{"id":"41319","messageId":"Pine.LNX.4.64.0705071301230.4167@racer.site","threadId":"7999","inReplyTo":"vpqd51duklo.fsf@bauges.imag.fr","subject":"Re: [FAQ?] Rationale for git's way to manage the index","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-05-07T11:05:44Z","receivedAt":"2007-05-07T11:05:44Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 7 May 2007, Matthieu Moy wrote:\n\n> Johannes Schindelin writes:\n> \n> > Just another reason to hate CVS. Because it trained people to do that. If \n> > it was not for the training by CVS, I would have strongly opposed to the \n> > introduction of the \"-m\" switch to commit. It _encourages_ bad commit \n> > messages.\n> \n> Well, this really depends on the use-case, size of commit, ...\n\nOkay, so I use \"-m\" myself sometimes.\n\n> I often use a version control system for very low importance stuff. I \n> don't want to type a 3-lines long message to describe a 2-lines long \n> change in my ~/.emacs.el for example.\n\nIIRC our record is 90+ lines of commit message for a one-line change.\n\n> I also work with people using (sorry) svn to work collaboratively, but \n> they don't even provide a log message: the version control system here \n> is just a replacement for unison/NFS/whatever other way to have people \n> edit files from different machines.\n\nI positively _hate_ empty commit messages. There is _always_ something to \nbe said about the intent of the change, that has no place in the code.\n\n> For sure, in a context where code quality and review is important, -m \n> \"xxx\" isn't the way (except if you prefer your shell's line editor to \n> your actual editor).\n\nI also find it very useful for my own pleasure when reviewing some logs. I \ntrack config files, small scripts, documents, etc. with Git, and I found \nmyself looking for something in _all_ of them. The commit messages helped.\n\nCommit messages, BTW, are somewhat of an artform. You cannot imagine how \nslow I am writing them, because they should be helpful not only for the \nreviewer, but also for the casual git-blame user, who wants to find out \nthe rationale of a change.\n\nCiao,\nDscho\n"},{"id":"41325","messageId":"8b65902a0705070440t40889af0p1fb8dbf7e2a072e4@mail.gmail.com","threadId":"7999","inReplyTo":"vpqwszm9bm9.fsf@bauges.imag.fr","subject":"Re: [FAQ?] Rationale for git's way to manage the index","fromName":"Guilhem Bonnefille","fromEmail":"guilhem.bonnefille@gmail.com","sentAt":"2007-05-07T11:40:33Z","receivedAt":"2007-05-07T11:40:33Z","isPatch":false,"sender":{"key":"guilhem.bonnefille@gmail.com","avatar":"https://gravatar.com/avatar/375364bfee1f61197c540e37465abe3619fc24eb3a36b0edcea7f15b124036b0?d=mp&s=160"},"body":"Hi,\n\nAs a newbie, I'm agree with Matthieu: the Git's index is surprising\nfor people coming from CVS/SVN (mindless?) world. So a good\ndocumentation about this, even in tutorials, is really important.\n\nIn order to improve my productivity with Git, and in order to avoid\ntraps around moving from SVN to Git, I often use the Git Emacs mode.\nIt is really usefull for beginners as it works similarly for CVS, SVN\nand Git: synthetic view of all modifications, easy selection of what\nwill be commited... The biggest drawback of this \"porcelain\": using\nit, you do not understand the Git's index philosophy.\n\n-- \nGuilhem BONNEFILLE\n-=- #UIN: 15146515 JID: guyou@im.apinc.org MSN: guilhem_bonnefille@hotmail.com\n-=- mailto:guilhem.bonnefille@gmail.com\n-=- http://nathguil.free.fr/\n"},{"id":"41329","messageId":"20070507121603.GA3255@diana.vm.bytemark.co.uk","threadId":"7999","inReplyTo":"8b65902a0705070440t40889af0p1fb8dbf7e2a072e4@mail.gmail.com","subject":"Re: [FAQ?] Rationale for git's way to manage the index","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2007-05-07T12:16:03Z","receivedAt":"2007-05-07T12:16:03Z","isPatch":false,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2007-05-07 13:40:33 +0200, Guilhem Bonnefille wrote:\n\n> In order to improve my productivity with Git, and in order to avoid\n> traps around moving from SVN to Git, I often use the Git Emacs mode.\n> It is really usefull for beginners as it works similarly for CVS,\n> SVN and Git: synthetic view of all modifications, easy selection of\n> what will be commited... The biggest drawback of this \"porcelain\":\n> using it, you do not understand the Git's index philosophy.\n\ngit-gui is a good tool here (so good, in fact, that this is the second\ntime today I spam the list about it). It shows very pedagogically the\ndiff between HEAD and index, and the diff between index and working\ndir, and allows you to point and click your way to committing\nprecisely the subset of changes you intended to commit. As an added\nbonus, it's perfectly usable even if you don't know anything about\nemacs.\n\n-- \nKarl Hasselström, kha@treskal.com\n www.treskal.com/kalle\n"},{"id":"41332","messageId":"86vef4yfmo.fsf@lola.quinscape.zz","threadId":"7999","inReplyTo":"20070507121603.GA3255@diana.vm.bytemark.co.uk","subject":"Re: [FAQ?] Rationale for git's way to manage the index","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-05-07T12:36:47Z","receivedAt":"2007-05-07T12:36:47Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Karl Hasselström writes:\n\n> On 2007-05-07 13:40:33 +0200, Guilhem Bonnefille wrote:\n>\n>> In order to improve my productivity with Git, and in order to avoid\n>> traps around moving from SVN to Git, I often use the Git Emacs mode.\n>> It is really usefull for beginners as it works similarly for CVS,\n>> SVN and Git: synthetic view of all modifications, easy selection of\n>> what will be commited... The biggest drawback of this \"porcelain\":\n>> using it, you do not understand the Git's index philosophy.\n>\n> git-gui is a good tool here (so good, in fact, that this is the second\n> time today I spam the list about it).\n\nPlease be sure to _always_ include a URL whenever you are spamming.\n\n-- \nDavid Kastrup\n"},{"id":"41334","messageId":"Pine.LNX.4.64.0705071453120.4167@racer.site","threadId":"7999","inReplyTo":"8b65902a0705070440t40889af0p1fb8dbf7e2a072e4@mail.gmail.com","subject":"Re: [FAQ?] Rationale for git's way to manage the index","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-05-07T12:55:13Z","receivedAt":"2007-05-07T12:55:13Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 7 May 2007, Guilhem Bonnefille wrote:\n\n> As a newbie, I'm agree with Matthieu: the Git's index is surprising for \n> people coming from CVS/SVN (mindless?) world. So a good documentation \n> about this, even in tutorials, is really important.\n\nSo, you are not only a newbie, but you have to unlearn some CVS \nbraindamage.\n\nI don't know how to make it even more prominent that CVS users should read \na special introduction first. AFAICT such a hint is in all the appropriate \nplaces. (I mean, you would not expect to be able to fly a plane, just \nbecause you have learnt to drive a car, wouldn't you?)\n\nCiao,\nDscho\n"},{"id":"41354","messageId":"7v7irk77nl.fsf@assigned-by-dhcp.cox.net","threadId":"7999","inReplyTo":"Pine.LNX.4.64.0705071453120.4167@racer.site","subject":"Re: [FAQ?] Rationale for git's way to manage the index","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-05-07T19:31:10Z","receivedAt":"2007-05-07T19:31:10Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> On Mon, 7 May 2007, Guilhem Bonnefille wrote:\n>\n>> As a newbie, I'm agree with Matthieu: the Git's index is surprising for \n>> people coming from CVS/SVN (mindless?) world. So a good documentation \n>> about this, even in tutorials, is really important.\n>\n> So, you are not only a newbie, but you have to unlearn some CVS \n> braindamage.\n\nWell, people worried that documentation and command set before\n1.5.0 exposed index too much, making learning curve too steep by\nhaving one extra thing people need to learn before starting to\nbe productive with git. Now post 1.5.0 people are confused,\nquite rightly, that they are not told about index early enough.\n\nI am not sure where to strike the right balance should be.\n\n> I don't know how to make it even more prominent that CVS users should read \n> a special introduction first. AFAICT such a hint is in all the appropriate \n> places. (I mean, you would not expect to be able to fly a plane, just \n> because you have learnt to drive a car, wouldn't you?)\n\nLet alone flying. Just taxiing straight was hard for me until I\nshook the habit I picked up from driving a car.\n"},{"id":"41372","messageId":"Pine.LNX.4.64.0705071616310.18541@iabervon.org","threadId":"7999","inReplyTo":"8b65902a0705070440t40889af0p1fb8dbf7e2a072e4@mail.gmail.com","subject":"Re: [FAQ?] Rationale for git's way to manage the index","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2007-05-07T22:23:20Z","receivedAt":"2007-05-07T22:23:20Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Mon, 7 May 2007, Guilhem Bonnefille wrote:\n\n> Hi,\n> \n> As a newbie, I'm agree with Matthieu: the Git's index is surprising\n> for people coming from CVS/SVN (mindless?) world. So a good\n> documentation about this, even in tutorials, is really important.\n\nI think that the confusing thing isn't really the index, but the fact that \ngit, by default, will make commits where the content in the commit is \ndifferent from the content in the working directory. (In fact, you can use \ngit-hash-object --stdin and git-update-index --cacheinfo to do a commit \nwhich shares no content at all with any present or past state of the \nworking directory!)\n\nIn other version control systems, you have to use some option or argument \nto make that kind of non-matching commit (and you're generally limited in \nhow your commits can fail to match the working directory). I think the \nconfusion is that git requires an option to say that you want the commit \nto match the working directory, as opposed to creating a non-matching \ncommit, which is generally the more advanced and more unusual case.\n\nI think this is why people mostly get to understand the index by way of \nusing it to resolve a conflicted merge: in that case, you have to make the \nindex match the working directory before committing, and the index tracks \nyour progress in reaching this state, which is the intuitive use of the \nindex in normal situations.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"41382","messageId":"20070508014114.GC11311@spearce.org","threadId":"7999","inReplyTo":"20070507063505.GA31269@diana.vm.bytemark.co.uk","subject":"Re: [FAQ?] Rationale for git's way to manage the index","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-05-08T01:41:14Z","receivedAt":"2007-05-08T01:41:14Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Karl Hasselstr??m wrote:\n> I thought \"git add -i\" was the best thing since sliced bread -- until\n> I found the same feature in git-gui, but with a _much_ better\n> interface. Just right-click on a hunk in a diff, and you have the\n> option of staging/unstaging that hunk. Pure magic.\n\n\"git add -i\" has a hunk splitting feature that git-gui lacks.\nI'm thinking of adding features to git-gui to let you select a\nregion of a hunk using the text selection, and then stage only\nthat selection. I also want to let you revert hunks from the\nworking directory copy.\n\nBut after reading Junio's comments about \"git add -i\" being a\npossibly bad idea and instead letting you park everything into\na shelf, reset --hard your working directory to HEAD and then\npull things back off the shelf to be staged, I might want to\ndo that differently in git-gui... like use a shelf. ;-)\n\n\nBut I'm glad someone else finds the hunk feature useful in\ngit-gui. I use it far too often myself.\n\n-- \nShawn.\n"},{"id":"41397","messageId":"46a038f90705072016x17bd60c3ic779459438ffc19@mail.gmail.com","threadId":"7999","inReplyTo":"vpqbqgxak1i.fsf@bauges.imag.fr","subject":"Re: [FAQ?] Rationale for git's way to manage the index","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2007-05-08T03:16:32Z","receivedAt":"2007-05-08T03:16:32Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 5/7/07, Matthieu Moy wrote:\n> Linus Torvalds writes:\n>\n> > On Sun, 6 May 2007, Matthieu Moy wrote:\n> >>\n> >> But the fact that git actually remembers the _content_ of files in the\n> >> index, and that the default behavior for \"commit\" is to commit only\n> >> the content that is explicitely \"git add\"ed is something I've never\n> >> seen outside git.\n> >\n> > Yeah. You'd better get used to it, because it's fundamental.\n>\n> Thanks a lot for the detailed explanations.\n\nHeh. Making the index very visible makes sense when you are merging,\nLinus and Junio are both integrators and spend a lot of time merging.\nHence the default is for git-commit to observe the index.\n\nI agree with Linus' other points too, but at the end of the day, it\nmakes life easier and saner mainly when merging, at the expense of\nhaving to pay a bit more attention in common commits. The tradeoff\nmakes sense _specially_ if you are the integrator.\n\nSo I do git-commit -a, and typing that '-a' is small price to pay for\nthe best SCM I've ever used ;-)\n\ncheers,\n\n\nmartin\n"},{"id":"41412","messageId":"alpine.LFD.0.98.0705072137450.3974@woody.linux-foundation.org","threadId":"7999","inReplyTo":"46a038f90705072016x17bd60c3ic779459438ffc19@mail.gmail.com","subject":"Re: [FAQ?] Rationale for git's way to manage the index","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-05-08T04:45:32Z","receivedAt":"2007-05-08T04:45:32Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 8 May 2007, Martin Langhoff wrote:\n> \n> Heh. Making the index very visible makes sense when you are merging,\n> Linus and Junio are both integrators and spend a lot of time merging.\n> Hence the default is for git-commit to observe the index.\n\nIt is definitely true that some of the advantages of the way git does the \nindex really start shinign when merging and you have content conflicts. \nWhat we've done to \"git diff\" really makes things a lot easier (and \nanybody who hasn't used \"gitk --merge\" after a content conflict really \nhasn't realized how *helpful* git is when merging content conflicts).\n\nHowever, in all honesty, while the whole \"index for merges\" comes from \npretty damn early in git history (the whole \"stage number\" thing appeared \non April 15th 2005 - so it was about a week after the first release), it \nwasn't the original impetus of the way git works.\n\nGit used explicit index updates from day 1, even before it did the first \nmerge. It's simply how I've always worked. I tend to have dirty trees, \nwith some random patch in my tree that I do *not* want to commit, because \nit's just a Makefile update for the next version (to remind me - I've \nreleased kernel versions too many times with an old version number, just \nbecause I forgot to update the Makefile).\n\nOr other things like that - I have small test-patches in my tree that I \nwant to build, but that I don't want to commit, and I end up doing big \nmerges and whole patch-application sequences with such a dirty tree \n(obviously if the patch or merge wants to change that file, I then need to \ndo something about that dirty state, but it happens surprisingly seldom).\n\nSo the whole \"update stuff to be committed explicitly\" ends up _really_ \nshining during a merge, but it actually is how I do non-merge development \ntoo.\n\n\t\t\tLinus\n"},{"id":"41419","messageId":"46a038f90705072235n16fbb130q9660df38cb9f3e66@mail.gmail.com","threadId":"7999","inReplyTo":"alpine.LFD.0.98.0705072137450.3974@woody.linux-foundation.org","subject":"Re: [FAQ?] Rationale for git's way to manage the index","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2007-05-08T05:35:32Z","receivedAt":"2007-05-08T05:35:32Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 5/8/07, Linus Torvalds wrote:\n> On Tue, 8 May 2007, Martin Langhoff wrote:\n> > Heh. Making the index very visible makes sense when you are merging,\n> > Linus and Junio are both integrators and spend a lot of time merging.\n> > Hence the default is for git-commit to observe the index.\n>\n> It is definitely true that some of the advantages of the way git does the\n> index really start shinign when merging and you have content conflicts.\n> What we've done to \"git diff\" really makes things a lot easier (and\n> anybody who hasn't used \"gitk --merge\" after a content conflict really\n> hasn't realized how *helpful* git is when merging content conflicts).\n\nTotally, when merging git's approach is incredibly useful. gitk\n--merge and the resolved conflicts not appearing in the default git\ndiff is great stuff.\n\nFor for small, simpleminded and mostly-linear development it's not\nthat important. Of course, I use git on projects large and small, so I\ncan understand it. For someone using it with a small mostly-linear\nproject, the whole index thing is overkill, and the explanations\npointless. I can understand people wondering WTF.\n\n> So the whole \"update stuff to be committed explicitly\" ends up _really_\n> shining during a merge, but it actually is how I do non-merge development\n> too.\n\nOn a large project it's always a good idea to commit with explicit\npaths -- regardless of your SCM. As it happens, I have to use explicit\npaths with CVS, or it'll punish me by taking solid minutes to do a 2\nfile commit. I am sure that the mozilla and OpenOffice developers\nusing CVS also commit with explicit paths. Life's too short to waste\nan hour.\n\n(The times are from working on Moodle, hosted on SF.net with ~4K\nfiles, 700 directories.).\n\ncheers,\n\n\nm\n"},{"id":"41421","messageId":"464023A1.6618BC0A@eudaptics.com","threadId":"7999","inReplyTo":"20070508014114.GC11311@spearce.org","subject":"Re: [FAQ?] Rationale for git's way to manage the index","fromName":"Johannes Sixt","fromEmail":"j.sixt@eudaptics.com","sentAt":"2007-05-08T07:15:45Z","receivedAt":"2007-05-08T07:15:45Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"\"Shawn O. Pearce\" wrote:\n> But I'm glad someone else finds the hunk feature useful in\n> git-gui. I use it far too often myself.\n\nIt it among the most-wanted features here. We discovered it only because\nKarl mentioned it yesterday. ;)\n\n-- Hannes\n"},{"id":"41425","messageId":"20070508073739.GA24409@diana.vm.bytemark.co.uk","threadId":"7999","inReplyTo":"20070508014114.GC11311@spearce.org","subject":"Re: [FAQ?] Rationale for git's way to manage the index","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2007-05-08T07:37:39Z","receivedAt":"2007-05-08T07:37:39Z","isPatch":false,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2007-05-07 21:41:14 -0400, Shawn O. Pearce wrote:\n\n> Karl Hasselström wrote:\n>\n> > I thought \"git add -i\" was the best thing since sliced bread --\n> > until I found the same feature in git-gui, but with a _much_\n> > better interface. Just right-click on a hunk in a diff, and you\n> > have the option of staging/unstaging that hunk. Pure magic.\n>\n> \"git add -i\" has a hunk splitting feature that git-gui lacks. I'm\n> thinking of adding features to git-gui to let you select a region of\n> a hunk using the text selection, and then stage only that selection.\n\nThat would be useful. It's currently possible to split some hunks by\nreducing the number of content lines, but if the changes aren't\nseparated by any unchanged lines at all, that doesn't work.\n\n> I also want to let you revert hunks from the working directory copy.\n\nThat would be handy. But unlike stage/unstage, this can lose\ninformation, so there'd need to be some kind of \"are you _really_\nsure? [Yes] [No]\" safety hatch, which would make it less convenient.\n\n> But after reading Junio's comments about \"git add -i\" being a\n> possibly bad idea and instead letting you park everything into a\n> shelf, reset --hard your working directory to HEAD and then pull\n> things back off the shelf to be staged, I might want to do that\n> differently in git-gui... like use a shelf. ;-)\n\nA shelf could be handy. Actually, it could be handy to have more than\none. Then one could go through the mess in one's working directory and\ntoss changes into one bin for each commit one plans to create --\nincluding one \"trash\" bin for hunks one would like to revert.\n\nI assume that shelves would be implemented as branches that are\nprecisely one commit on top of HEAD? If so, I'd just like to point out\nthat they're exactly like unapplied patches in StGIT.\n\nHmm. I find it inconsistent to force or strongly encourage the user to\ncommit precisely the working directory changes and not a subset\nthereof, which the shelf idea seems to encourage, while at the same\ntime not committing straight from the working directory but from a\nspecific staging area (the index).\n\n> But I'm glad someone else finds the hunk feature useful in git-gui.\n> I use it far too often myself.\n\nI don't think it's a bad thing. If I've made several unrelated changes\nand want to commit them separately for the sake of readable history,\nhow exactly is that a bad thing when compared to committing it all at\nonce? If I care about clean history in the first place, then\npresumably I'll test the commits in isolation if I deem it necessary\n-- and if I don't, then I probably won't test anyway even if the tool\nmakes it easy.\n\n-- \nKarl Hasselström, kha@treskal.com\n www.treskal.com/kalle\n"},{"id":"41437","messageId":"20070508102836.GB27119@diana.vm.bytemark.co.uk","threadId":"7999","inReplyTo":"464023A1.6618BC0A@eudaptics.com","subject":"Re: [FAQ?] Rationale for git's way to manage the index","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2007-05-08T10:28:36Z","receivedAt":"2007-05-08T10:28:36Z","isPatch":false,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2007-05-08 09:15:45 +0200, Johannes Sixt wrote:\n\n> \"Shawn O. Pearce\" wrote:\n>\n> > But I'm glad someone else finds the hunk feature useful in\n> > git-gui. I use it far too often myself.\n>\n> It it among the most-wanted features here. We discovered it only\n> because Karl mentioned it yesterday. ;)\n\nSee? Who said spamming doesn't work? :-)\n\nI think it would be worth introducing git-gui as a commit tool in the\ntutorial(s) and the manual. It gives a very nice graphical\nrepresentation of the dirty state you're going to commit, and the\ndirty state you aren't going to commit because you haven't staged it\nyet. The only drawback is that it's a lot of work to make\ndocumentation with screenshots ...\n\n-- \nKarl Hasselström, kha@treskal.com\n www.treskal.com/kalle\n"},{"id":"41440","messageId":"Pine.LNX.4.64.0705081256410.4167@racer.site","threadId":"7999","inReplyTo":"46a038f90705072016x17bd60c3ic779459438ffc19@mail.gmail.com","subject":"Re: [FAQ?] Rationale for git's way to manage the index","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-05-08T11:07:25Z","receivedAt":"2007-05-08T11:07:25Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 8 May 2007, Martin Langhoff wrote:\n\n> Heh. Making the index very visible makes sense when you are merging,\n\nYou're saying that the main use of the index is to help merging. I have to \ndisagree strongly.\n\nWhen I have been chasing a bug all over the place, and finally found it, \nmy working tree is a mess. Lots of assertions, lots of debugging \nstatements, some of them commented out. So, now it is cleanup time, right?\n\nThe problem is that more often than not, I broke my fix while cleaning up.\n\nTherefore, I now put all changed files into the index (git add -u), and \nclean up the files one by one, always checking with \"git diff\" and \"git \ndiff HEAD\" what I still have to do.\n\nYes, very often I can just take the original version of a file (git reset \n--soft would be handy here), but it helped me quite a number of \ntimes to have my messed-up-but-working state in the index.\n\nIn a sense, I am using the index as the stash commit we talked about every \nonce in a while.\n\nCiao,\nDscho\n"},{"id":"41449","messageId":"20070508124027.GA14366@fieldses.org","threadId":"7999","inReplyTo":"20070508102836.GB27119@diana.vm.bytemark.co.uk","subject":"Re: [FAQ?] Rationale for git's way to manage the index","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2007-05-08T12:40:27Z","receivedAt":"2007-05-08T12:40:27Z","isPatch":false,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"On Tue, May 08, 2007 at 12:28:36PM +0200, Karl Hasselström wrote:\n> I think it would be worth introducing git-gui as a commit tool in the\n> tutorial(s) and the manual. It gives a very nice graphical\n> representation of the dirty state you're going to commit, and the\n> dirty state you aren't going to commit because you haven't staged it\n> yet. The only drawback is that it's a lot of work to make\n> documentation with screenshots ...\n\nYou could put that on a web page someplace.\n\nFor the tutorial and user manual, could git-gui be treated similar gitk,\nwith just a one- or two- line mention here and there? I haven't used\nit, so don't know where it would most logically fit in....\n\n--b.\n"},{"id":"41457","messageId":"20070508145249.GP11311@spearce.org","threadId":"7999","inReplyTo":"20070508073739.GA24409@diana.vm.bytemark.co.uk","subject":"Re: [FAQ?] Rationale for git's way to manage the index","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-05-08T14:52:49Z","receivedAt":"2007-05-08T14:52:49Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Karl Hasselstr??m wrote:\n> It's currently possible to split some hunks by\n> reducing the number of content lines, but if the changes aren't\n> separated by any unchanged lines at all, that doesn't work.\n\nYea, I've played that game before too (reduce content lines) to\ntry and simulate a hunk splitter. ;-) Doesn't always work.\n\nRight now I feel like a huge chunk of the git-gui code is simply not\nmaintainable. The 0.7.0 release is really more about refactoring the\ncode to make it more maintainable, than it is about actual features\n(though there are some new things, like vi-keys).\n\nThe hunk selection stuff is just one part of the 2,000 lines\nstill left in git-gui.sh itself, and that still uses a lot of\nmessy globals. I want to get the code better organized before\nI take on major new additions to it.\n\n> > I also want to let you revert hunks from the working directory copy.\n> \n> That would be handy. But unlike stage/unstage, this can lose\n> information, so there'd need to be some kind of \"are you _really_\n> sure? [Yes] [No]\" safety hatch, which would make it less convenient.\n\nTrue, but that beats the tar out of copying the - lines to your\nclipboard and pasting them into your text editor, then deleting\nthe - prefix. Especially if its a couple of hunks that you want\nto revert. Which I find myself doing all to often.\n\nActually I work around it today by staging what I care about,\nthen reverting the file. Since the revert comes out of the index,\nI get (mostly) the same action as reverting a particular hunk.\nBut it does mean that I lose my index state, if that happened to\nbe of any particular interest.\n\n> I assume that shelves would be implemented as branches that are\n> precisely one commit on top of HEAD? If so, I'd just like to point out\n> that they're exactly like unapplied patches in StGIT.\n\nI haven't looked at StGIT in a while. I've seen noise on the list\nabout nifty features being added, but I haven't kept up with what\nthose features actually are. I think you are right about this and\nmaybe git-gui should try to be compatible with StGIT's unapplied\npatches, should I get into actually implementing a shelving system.\n \n> Hmm. I find it inconsistent to force or strongly encourage the user to\n> commit precisely the working directory changes and not a subset\n> thereof, which the shelf idea seems to encourage, while at the same\n> time not committing straight from the working directory but from a\n> specific staging area (the index).\n\nIndeed; I was thinking that this very morning. Making an index that\nyou stage things into, but then also saying you cannot really do that\nand instead have to shelve what you don't want - that's just evil.\nI'll have to think about it more.\n\nThe blame interface in git-gui needs help more than the index\nstaging features. The colors suck. ;-)\n \n-- \nShawn.\n"},{"id":"41458","messageId":"20070508145311.GA31152@diana.vm.bytemark.co.uk","threadId":"7999","inReplyTo":"20070508124027.GA14366@fieldses.org","subject":"Re: [FAQ?] Rationale for git's way to manage the index","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2007-05-08T14:53:11Z","receivedAt":"2007-05-08T14:53:11Z","isPatch":false,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2007-05-08 08:40:27 -0400, J. Bruce Fields wrote:\n\n> On Tue, May 08, 2007 at 12:28:36PM +0200, Karl Hasselström wrote:\n>\n> > I think it would be worth introducing git-gui as a commit tool in\n> > the tutorial(s) and the manual. It gives a very nice graphical\n> > representation of the dirty state you're going to commit, and the\n> > dirty state you aren't going to commit because you haven't staged\n> > it yet. The only drawback is that it's a lot of work to make\n> > documentation with screenshots ...\n>\n> For the tutorial and user manual, could git-gui be treated similar\n> gitk, with just a one- or two- line mention here and there? I\n> haven't used it, so don't know where it would most logically fit\n> in....\n\nI would introduce it with a paragraph or two right where committing is\ncovered the first time. Explain that the empty file list box to the\nleft contains the changes that will be committed when you press the\ncommit button, and that the file list box on the right contains the\nchanges that won't be committed. By clicking on a file name you get to\nsee the diff to the file, and by clicking on the icon you move it to\nthe other file list box -- that is, you stage/unstage it.\n\nAnd now comes the clever part: Introduce the index, by explaining that\nit essentially _is_ the left file list box. Explain that git-add is\nthe command-line equivalent of moving changes to the left box, and\nthat git-commit without arguments simply commits what's in the index\n-- exactly like git-gui's Commit button.\n\nI think it could work. :-)\n\n-- \nKarl Hasselström, kha@treskal.com\n www.treskal.com/kalle\n"},{"id":"41529","messageId":"20070509034556.GC27980@fieldses.org","threadId":"7999","inReplyTo":"20070508145311.GA31152@diana.vm.bytemark.co.uk","subject":"Re: [FAQ?] Rationale for git's way to manage the index","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2007-05-09T03:45:57Z","receivedAt":"2007-05-09T03:45:57Z","isPatch":false,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"On Tue, May 08, 2007 at 04:53:11PM +0200, Karl Hasselström wrote:\n> I would introduce it with a paragraph or two right where committing is\n> covered the first time. Explain that the empty file list box to the\n> left contains the changes that will be committed when you press the\n> commit button, and that the file list box on the right contains the\n> changes that won't be committed. By clicking on a file name you get to\n> see the diff to the file, and by clicking on the icon you move it to\n> the other file list box -- that is, you stage/unstage it.\n> \n> And now comes the clever part: Introduce the index, by explaining that\n> it essentially _is_ the left file list box. Explain that git-add is\n> the command-line equivalent of moving changes to the left box, and\n> that git-commit without arguments simply commits what's in the index\n> -- exactly like git-gui's Commit button.\n> \n> I think it could work. :-)\n\nDefinitely, sounds fun.\n\nFor the in-tree documentation, maybe I'm just my crusty text-centric\ncommandline point of view, but I'd rather have the primary explanation\ncontinue to depend only on text and commandline examples, and then add a\nnote telling people that playing with git-gui may help develop their\nintuition for the way the index works.\n\nBut I think it'd be interesting to try out the above approach with\nscreenshots, etc., on a web page someplace. It might also make a good\nvisual aid for a talk.\n\n--b.\n"},{"id":"41567","messageId":"Pine.LNX.4.64.0705091139430.4167@racer.site","threadId":"7999","inReplyTo":"20070509034556.GC27980@fieldses.org","subject":"Re: [FAQ?] Rationale for git's way to manage the index","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-05-09T09:40:09Z","receivedAt":"2007-05-09T09:40:09Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 8 May 2007, J. Bruce Fields wrote:\n\n> On Tue, May 08, 2007 at 04:53:11PM +0200, Karl Hasselström wrote:\n> > I would introduce it with a paragraph or two right where committing is\n> > covered the first time. Explain that the empty file list box to the\n> > left contains the changes that will be committed when you press the\n> > commit button, and that the file list box on the right contains the\n> > changes that won't be committed. By clicking on a file name you get to\n> > see the diff to the file, and by clicking on the icon you move it to\n> > the other file list box -- that is, you stage/unstage it.\n> > \n> > And now comes the clever part: Introduce the index, by explaining that\n> > it essentially _is_ the left file list box. Explain that git-add is\n> > the command-line equivalent of moving changes to the left box, and\n> > that git-commit without arguments simply commits what's in the index\n> > -- exactly like git-gui's Commit button.\n> > \n> > I think it could work. :-)\n> \n> Definitely, sounds fun.\n> \n> For the in-tree documentation, maybe I'm just my crusty text-centric\n> commandline point of view, but I'd rather have the primary explanation\n> continue to depend only on text and commandline examples, and then add a\n> note telling people that playing with git-gui may help develop their\n> intuition for the way the index works.\n> \n> But I think it'd be interesting to try out the above approach with\n> screenshots, etc., on a web page someplace. It might also make a good\n> visual aid for a talk.\n\nUsually a wiki is a perfect place to start this...\n\nCiao,\nDscho\n"},{"id":"41583","messageId":"20070509125225.GP4489@pasky.or.cz","threadId":"7999","inReplyTo":"7vvef5c0fw.fsf@assigned-by-dhcp.cox.net","subject":"Re: [FAQ?] Rationale for git's way to manage the index","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2007-05-09T12:52:25Z","receivedAt":"2007-05-09T12:52:25Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Sun, May 06, 2007 at 07:43:31PM CEST, Junio C Hamano wrote:\n> A single liner \"-m\" is handy for \"Oops, typofix in foo.c\" kind\n> of commit, but in such a case you literally would be changing\n> only the typofix and won't have \"edit foo.c; git add foo.c; edit\n> foo.c; git commit\" sequence anyway.\n\nI don't get this argument - I frequently write quite long descriptions\ninside the -m argument(s), since I just find it more convenient than\nhaving to edit it in an editor, for various reasons. So there is really\nno reason why the \"-m is only for short single-liner commit messages\"\nhypothesis could hold true.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nEver try. Ever fail. No matter. // Try again. Fail again. Fail better.\n\t\t-- Samuel Beckett\n"},{"id":"41586","messageId":"20070509130704.GR4489@pasky.or.cz","threadId":"7999","inReplyTo":"Pine.LNX.4.64.0705071301230.4167@racer.site","subject":"Re: [FAQ?] Rationale for git's way to manage the index","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2007-05-09T13:07:04Z","receivedAt":"2007-05-09T13:07:04Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":" Hi,\n\nOn Mon, May 07, 2007 at 01:05:44PM CEST, Johannes Schindelin wrote:\n> On Mon, 7 May 2007, Matthieu Moy wrote:\n> \n> > Johannes Schindelin writes:\n> > \n> > > Just another reason to hate CVS. Because it trained people to do that. If \n> > > it was not for the training by CVS, I would have strongly opposed to the \n> > > introduction of the \"-m\" switch to commit. It _encourages_ bad commit \n> > > messages.\n> > \n> > Well, this really depends on the use-case, size of commit, ...\n> \n> Okay, so I use \"-m\" myself sometimes.\n\n I'm maybe somewhat standing out of the crowd, but I sometimes use -m\nfor *very* long commit messages - just using separate -m parameters for\nparagraphs and writing on; I tend to find it much more natural than\nspawning an editor. Only when I find later that I've made an ugly typo\nin the middle of 250-characters commandline or I figure out that I\nshould add some figure to the message, I throw in -e at the end and add\nthe final touches.\n\n..snip..\n> Commit messages, BTW, are somewhat of an artform. You cannot imagine how \n> slow I am writing them, because they should be helpful not only for the \n> reviewer, but also for the casual git-blame user, who wants to find out \n> the rationale of a change.\n\n But I agree that commit messages are somewhat of an artform, and\njust finding a good headline can be quite difficult sometime. :-)\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nEver try. Ever fail. No matter. // Try again. Fail again. Fail better.\n\t\t-- Samuel Beckett\n"},{"id":"41587","messageId":"20070509131434.GS4489@pasky.or.cz","threadId":"7999","inReplyTo":"Pine.LNX.4.64.0705071453120.4167@racer.site","subject":"Re: [FAQ?] Rationale for git's way to manage the index","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2007-05-09T13:14:34Z","receivedAt":"2007-05-09T13:14:34Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":" Hi,\n\nOn Mon, May 07, 2007 at 02:55:13PM CEST, Johannes Schindelin wrote:\n> On Mon, 7 May 2007, Guilhem Bonnefille wrote:\n> \n> > As a newbie, I'm agree with Matthieu: the Git's index is surprising for \n> > people coming from CVS/SVN (mindless?) world. So a good documentation \n> > about this, even in tutorials, is really important.\n> \n> So, you are not only a newbie, but you have to unlearn some CVS \n> braindamage.\n> \n> I don't know how to make it even more prominent that CVS users should read \n> a special introduction first. AFAICT such a hint is in all the appropriate \n> places. (I mean, you would not expect to be able to fly a plane, just \n> because you have learnt to drive a car, wouldn't you?)\n\n http://www.kernel.org/pub/software/scm/git/docs/tutorial.html does not\ntalk about anything like that (it links to \"Git for CVS users\" but\nthat's really just about importing from CVS and the shared repository\nworkflow).\n\n On the other hand, I think the tutorial linked above gives quite a\nclear explanation of git commit -a, git add etc. Guilhem, what do you\nfind missing in the tutorial about this topic?\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nEver try. Ever fail. No matter. // Try again. Fail again. Fail better.\n\t\t-- Samuel Beckett\n"},{"id":"41589","messageId":"20070509134151.GT4489@pasky.or.cz","threadId":"7999","inReplyTo":"alpine.LFD.0.98.0705072137450.3974@woody.linux-foundation.org","subject":"Re: [FAQ?] Rationale for git's way to manage the index","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2007-05-09T13:41:51Z","receivedAt":"2007-05-09T13:41:51Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Tue, May 08, 2007 at 06:45:32AM CEST, Linus Torvalds wrote:\n> Git used explicit index updates from day 1, even before it did the first \n> merge. It's simply how I've always worked. I tend to have dirty trees, \n> with some random patch in my tree that I do *not* want to commit, because \n> it's just a Makefile update for the next version (to remind me - I've \n> released kernel versions too many times with an old version number, just \n> because I forgot to update the Makefile).\n> \n> Or other things like that - I have small test-patches in my tree that I \n> want to build, but that I don't want to commit, and I end up doing big \n> merges and whole patch-application sequences with such a dirty tree \n> (obviously if the patch or merge wants to change that file, I then need to \n> do something about that dirty state, but it happens surprisingly seldom).\n\nHmm, does this really work so well for you guys? Because thanks to Mr.\nMurphy, in my case, when I have some custom Makefile tweak, I always\nneed to commit some unrelated changes involving Makefile more often than\nusual, and so on; so in general case, file-level changes exclusion\ndoesn't really work so well for me.\n\nSo this use of index seems to me really as a workaround for more\nfine-grained change control (in a similar way that rename following\nwould be a workaround for lack of more fine-grained content moves\ntracking). I will have to look into git-gui's hunk-level control and\nmaybe reimplement it in tig.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nEver try. Ever fail. No matter. // Try again. Fail again. Fail better.\n\t\t-- Samuel Beckett\n"},{"id":"41593","messageId":"Pine.LNX.4.64.0705091513360.4167@racer.site","threadId":"7999","inReplyTo":"20070509125225.GP4489@pasky.or.cz","subject":"Re: [FAQ?] Rationale for git's way to manage the index","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-05-09T13:57:28Z","receivedAt":"2007-05-09T13:57:28Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 9 May 2007, Petr Baudis wrote:\n\n> On Sun, May 06, 2007 at 07:43:31PM CEST, Junio C Hamano wrote:\n> > A single liner \"-m\" is handy for \"Oops, typofix in foo.c\" kind\n> > of commit, but in such a case you literally would be changing\n> > only the typofix and won't have \"edit foo.c; git add foo.c; edit\n> > foo.c; git commit\" sequence anyway.\n> \n> I don't get this argument - I frequently write quite long descriptions\n> inside the -m argument(s), since I just find it more convenient than\n> having to edit it in an editor, for various reasons. So there is really\n> no reason why the \"-m is only for short single-liner commit messages\"\n> hypothesis could hold true.\n\n:-) You yourself provided a reason in another reply: typos.\n\nAnother reason is that you can see how the end result will look like in an \neditor. For example, you'll have a hard time making sure in the \ncommand line that the lines are no longer than 76 characters.\n\nCiao,\nDscho\n"},{"id":"41595","messageId":"20070509142426.GV4489@pasky.or.cz","threadId":"7999","inReplyTo":"Pine.LNX.4.64.0705091513360.4167@racer.site","subject":"[PATCH] git-commit: Reformat log messages provided on commandline","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2007-05-09T14:24:26Z","receivedAt":"2007-05-09T14:24:26Z","isPatch":true,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":" Hi,\n\nOn Wed, May 09, 2007 at 03:57:28PM CEST, Johannes Schindelin wrote:\n> Another reason is that you can see how the end result will look like in an \n> editor. For example, you'll have a hard time making sure in the \n> command line that the lines are no longer than 76 characters.\n\n oh, indeed - good point. cg-commit uses fmt to format the message, I\nthink git-commit should do the same; let's see how controversial such a\nchange would be.\n\n---\nThis makes git-commit filter log messages provided on commandline by fmt,\nthus making nice paragraphs from them. This makes it possible to specify\neven long commit messages on command line without worrying about this, akin\nto cg-commit.\n\nSigned-off-by: Petr Baudis \n---\n\n git-commit.sh | 2 +-\n 1 files changed, 1 insertions(+), 1 deletions(-)\n\ndiff --git a/git-commit.sh b/git-commit.sh\nindex f28fc24..28cbb55 100755\n--- a/git-commit.sh\n+++ b/git-commit.sh\n@@ -432,7 +432,7 @@ fi\n \n if test \"$log_message\" != ''\n then\n-\techo \"$log_message\"\n+\techo \"$log_message\" | fmt\n elif test \"$logfile\" != \"\"\n then\n \tif test \"$logfile\" = -\n\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nEver try. Ever fail. No matter. // Try again. Fail again. Fail better.\n\t\t-- Samuel Beckett\n"},{"id":"41596","messageId":"vpqps5ajb60.fsf@bauges.imag.fr","threadId":"7999","inReplyTo":"20070509142426.GV4489@pasky.or.cz","subject":"Re: [PATCH] git-commit: Reformat log messages provided on commandline","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2007-05-09T14:59:03Z","receivedAt":"2007-05-09T14:59:03Z","isPatch":true,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"Petr Baudis writes:\n\n> -\techo \"$log_message\"\n> +\techo \"$log_message\" | fmt\n\nI wouldn't do that for the first line of the message.\n\nSomeone typing\n\n$ git commit -m \"a very very very very very very very very very very very very long summary\" \\\n -m \"a longer description of the above summary\"\n\nProbably doesn't want his first line to be broken (otherwise,\ngit-format-patch and other tools would be confused).\n\nSo, that would be more like\n\necho \"$log_message\" | (read first_line; echo \"$first_line\"; fmt)\n\n\nPerhaps another option would be to provide, say, a -M option, doing\n\nlog_message=\"$log_message\n\n$(echo $1 | fmt)\"\n\nto allow people to explicitely say whether they want reformatting. But\nthat's probably overkill.\n\n-- \nMatthieu\n"},{"id":"41597","messageId":"Pine.LNX.4.64.0705091658210.4167@racer.site","threadId":"7999","inReplyTo":"20070509142426.GV4489@pasky.or.cz","subject":"Re: [PATCH] git-commit: Reformat log messages provided on commandline","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-05-09T15:01:20Z","receivedAt":"2007-05-09T15:01:20Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 9 May 2007, Petr Baudis wrote:\n\n> On Wed, May 09, 2007 at 03:57:28PM CEST, Johannes Schindelin wrote:\n> > Another reason is that you can see how the end result will look like in an \n> > editor. For example, you'll have a hard time making sure in the \n> > command line that the lines are no longer than 76 characters.\n> \n> oh, indeed - good point. cg-commit uses fmt to format the message, I\n> think git-commit should do the same;\n\nFWIW, I have a builtin git-fmt in my local repo, which uses the (slightly \nenhanced) functions in utf8.c... Maybe after 1.5.2 I dare to submit \nthis...\n\nCiao,\nDscho\n"},{"id":"41598","messageId":"20070509151148.GW4489@pasky.or.cz","threadId":"7999","inReplyTo":"vpqps5ajb60.fsf@bauges.imag.fr","subject":"Re: [PATCH] git-commit: Reformat log messages provided on commandline","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2007-05-09T15:11:48Z","receivedAt":"2007-05-09T15:11:48Z","isPatch":true,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Wed, May 09, 2007 at 04:59:03PM CEST, Matthieu Moy wrote:\n> Petr Baudis writes:\n> \n> > -\techo \"$log_message\"\n> > +\techo \"$log_message\" | fmt\n> \n> I wouldn't do that for the first line of the message.\n> \n> Someone typing\n> \n> $ git commit -m \"a very very very very very very very very very very very very long summary\" \\\n> -m \"a longer description of the above summary\"\n> \n> Probably doesn't want his first line to be broken (otherwise,\n> git-format-patch and other tools would be confused).\n> \n> So, that would be more like\n> \n> echo \"$log_message\" | (read first_line; echo \"$first_line\"; fmt)\n\nHmm, I don't really know if it's more evil to split an extra-long line\nto two or keep it longer than the maximum sane width. Since I'm torn,\nI'd prefer to go for the version that's simpler (also, avoids weird\nresults for those who for some reason chose not to follow the usual\nconvention, but that's a minor point).\n\nI don't really care, but if noone else does either, I'd stay with the\ncurrent simple version. :)\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nEver try. Ever fail. No matter. // Try again. Fail again. Fail better.\n\t\t-- Samuel Beckett\n"},{"id":"41605","messageId":"vpqfy66gght.fsf@bauges.imag.fr","threadId":"7999","inReplyTo":"20070509151148.GW4489@pasky.or.cz","subject":"Re: [PATCH] git-commit: Reformat log messages provided on commandline","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2007-05-09T15:32:14Z","receivedAt":"2007-05-09T15:32:14Z","isPatch":true,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"Petr Baudis writes:\n\n> Hmm, I don't really know if it's more evil to split an extra-long line\n> to two or keep it longer than the maximum sane width.\n\nThe evil already happened several times in git's repository ;-).\n\n$ git log --all --pretty=oneline | grep \\\n ' ................................................................................' \\\n | wc -l\n81\n$\n\nWhen I encounter such long line, I often just don't care, since my\nterminal or tool (gitk ...) is often more than 80 char. And in the\ncases I care, the fix is just to enlarge the window or to scroll (only\npeople using a text-mode console would _really_ be disturbed).\n\nWith the other solution (breaking the line automatically), I have no\neasy fix. In gitk, I have the beginning of a sentence in the summary\nfield, in a mailed patched, I have the sentence split between the\nSubject: header and the body.\n\n(but we agree that both cases are evil. Perhaps just \"ERROR: you're\ndoing evil\" would be better ...)\n\n-- \nMatthieu\n"},{"id":"41608","messageId":"alpine.LFD.0.98.0705090825090.4062@woody.linux-foundation.org","threadId":"7999","inReplyTo":"20070509134151.GT4489@pasky.or.cz","subject":"Re: [FAQ?] Rationale for git's way to manage the index","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-05-09T15:52:09Z","receivedAt":"2007-05-09T15:52:09Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 9 May 2007, Petr Baudis wrote:\n\n> On Tue, May 08, 2007 at 06:45:32AM CEST, Linus Torvalds wrote:\n> > \n> > Or other things like that - I have small test-patches in my tree that I \n> > want to build, but that I don't want to commit, and I end up doing big \n> > merges and whole patch-application sequences with such a dirty tree \n> > (obviously if the patch or merge wants to change that file, I then need to \n> > do something about that dirty state, but it happens surprisingly seldom).\n> \n> Hmm, does this really work so well for you guys? Because thanks to Mr.\n> Murphy, in my case, when I have some custom Makefile tweak, I always\n> need to commit some unrelated changes involving Makefile more often than\n> usual, and so on; so in general case, file-level changes exclusion\n> doesn't really work so well for me.\n\nWell, one thing is that I obviously mainly work on a relatively large \nproject, and one that has been carefully de-centralized over a long long \ntime, so the source code I work with - the kernel - may be more amenable \nto my workflow than most.\n\nFor example, we have long long since tried to avoid having central files \nthat everybody changes - because it's such a pain to manage, even with \ngood automated merging (and even more with central people still using just \nseries of patches).\n\nIn other words, in well-maintained larger projects, you simply don't see \nthose kinds of conflicts very often: people don't work on the same files \nvery much. I regularly go for days, and easily merging hundreds of \nthousands of lines of changes, with a dirty tree, and the merges don't \naffect it at all.\n\nAnd if I happen to hit a dirty file, the pull will just say \"cannot \nmerge\", and I can stash away my changes, and just re-do. So the cost of a \nconflict in a dirty tree is very low when it *does* happen.\n\n> So this use of index seems to me really as a workaround for more\n> fine-grained change control (in a similar way that rename following\n> would be a workaround for lack of more fine-grained content moves\n> tracking). I will have to look into git-gui's hunk-level control and\n> maybe reimplement it in tig.\n\nMany people seem to enjoy per-hunk commits, but I seldom do that. Maybe \nit's just because I'm *so* comfortable with diffs, that when I clean up an \nugly sequence of commits, what I do is literally:\n\n - I make sure that my ugly sequence of commits is on some temporary \n branch, but that the _end_result_ is good and clean (ie I will have \n tested the end result fairly well, and made sure that there are no \n debug statements etc crud left).\n\n I would call this branch something like \"target\", because the end \n result of that branch is what I'm looking for - even if the commits in \n the sequence that gets me there are individually ugly!\n\n - I just switch back to my starting point (and now I'm usually on \n \"master\"), and do\n\n\tgit diff -R target > diff\n\n to create a diff of my current tree (which is initially the starting \n point) to the good result.\n\n - I actually edit the \"diff\" file by hand, and edit it down to the part I \n actually want to commit as the first in the series. And then I just do \n a \"git-apply diff\" to actually apply that part to my working tree.\n\n - I then edit any missing parts in the actual working tree (for example, \n if there were mixed hunks that I want to get to in later commits, and I \n edited out above, or that I need to partially undo), to do any \n finishing touches.\n\n - I now have a tree I can compile and test, and has the \"first part\" of \n the journey towards the final \"target\" state. If compiling/testing \n shows that I missed something, I can still fix things, and/or go back \n to doing another \"git diff -R target\" to see if I missed something).\n\n - I commit that first case, and repeat the sequence from step 2 (and \n at every step, the \"diff\" file ends up shrinking and shrinking).\n\nThe above sounds like it's a complicated sequence, but it really isn't. \nPartly because I just am very comfortable with diffs indeed (probably more \nthan most people), but partly because at all times \"git diff\" works fine \nto see what I've done, and what the diff to \"target\" is.\n\nAnd unlike the \"simpler\" model of committing individual hunks with \"git \nadd -i\" or something like that, my model is actually much superior! It \nmeans that I can actually test each stage individually, and make sure that \nthe intermediate commits are good. It also allows me to edit up places \nwhere the diff mixes up two different things, and the intermediate result \nneeds to be different from the final one.\n\nDo I do this very often? No. Most of the time, the changes are separate \nenough that I can just commit one file at a time, and in fact, I can mix \nand match (ie I can do the above thing in the \"big picture\", but actually \nend up doing one substep where I do just one \"diff and edit\" phase, but \nthen actually commit that as two things by just committing individual \nfiles separately when they are obviously independent changes).\n\nBut the above is literally what I did for the superproject support and for \nsome other things where I want to send out the end result in a nice \nsequence of 5-6 patches, but when I was actually *developing* it I ended \nup making more mistakes, and I started out with 10 patches with some total \nbraino's that I had to fix, or cleanups that I didn't do in the right \nsequence.\n\nAnd I actually mix-and-match other ways of working too. For example, if \nsome commit in my otherwise ugly \"target\" sequence was fine, I'll just \ncherry-pick it instead, and re-order things that way. \n\nThe point of this all is that the \"git way\" is actually very flexible. You \ncan keep the tree dirty and not worry about it, and if you always think \ntwice before you do \"git commit -a\" you won't be committing dirty state \nthat you didn't intend to commit by mistake.\n\nOf course, if you get so used to doing \"git commit -a\" that you just do it \nin your sleep, then the dirty tree model won't work for you, because \nyou'll simply start committing stuff you didn't intend to commit when \nyou're on auto-pilot. But the way I work, I basically always do\n\n\tgit diff\n\nto see what's in my tree, and I will only use the \"-a\" flag when I \n*consciously* think \"ok, that's all one thing\". \n\nBtw, what goes hand-in-hand with this workflow is the nice ability to \nspecify a subtree. So I'll have a dirty tree with two different \ntest-things, but since one of them was a filesystem fix, and the other one \nwas in the kernel, rather than give all the paths explicitly, I'd do\n\n\tgit commit fs/\n\nand it will automatically do the right thing (actually, I often end up \nusing the two-stage \"git add\" + \"git commit\" thing, because one of the \nmore common cases for me is that I'm going to commit a merge that I fixed \nup a conflict in, and then you have to do it that way).\n\n\t\t\tLinus\n"},{"id":"41618","messageId":"873b26klkj.wl%cworth@cworth.org","threadId":"7999","inReplyTo":"alpine.LFD.0.98.0705090825090.4062@woody.linux-foundation.org","subject":"Re: [FAQ?] Rationale for git's way to manage the index","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2007-05-09T16:29:00Z","receivedAt":"2007-05-09T16:29:00Z","isPatch":false,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Wed, 9 May 2007 08:52:09 -0700 (PDT), Linus Torvalds wrote:\n[Snip good description of rebuilding a branch to meet some \"target\"\nstate.]\n\nThat's all really good stuff. And as you mentioned you sometimes use\ncherry-pick during this rebuilding, one can also use \"git add -i\" to\nhelp with splitting up an ugly commit that should have been multiple\ncommit.\n\nFor example, a sequence might look like this, (I always use \"desired\"\nwhere you use target):\n\n\tgit diff HEAD desired | git apply\n\tgit add -i\n\tgit commit\n\tgit reset --hard\n\t# test here and commit --amend as needed\n\nAnd repeat that as needed. It's really no different than your \"edit\nthe diff\" approach. It's just using \"add -i\" instead of a text\neditor. But I do admit that the commit;reset;test;--amend sequence\nmight seem a bit too awkward to some people.\n\n> test-things, but since one of them was a filesystem fix, and the other one\n> was in the kernel, rather than give all the paths explicitly, I'd do\n>\n> \tgit commit fs/\n>\n> and it will automatically do the right thing (actually, I often end up\n> using the two-stage \"git add\" + \"git commit\" thing, because one of the\n> more common cases for me is that I'm going to commit a merge that I fixed\n> up a conflict in, and then you have to do it that way).\n\nThis reminds me of a confusing semantic issue that came about with the\n\"new\" add. It can be quite natural to commit a single file in one step\nwith:\n\n\tgit commit some-file.c\n\nor to do that in two steps with:\n\n\tgit add some-file.c\n\tgit commit\n\n(which is particularly useful if one wants to add multiple files).\n\nI recently found myself wanting to do a similar thing with a directory\npath. I can commit a path with:\n\n\tgit commit path/\n\nbut I don't get anything at all like the same semantics if I do:\n\n\tgit add path/\n\tgit commit\n\n(since \"git add\" will recursively add all untracked files under path/).\n\nNow the \"recursively add all files\" behavior is older, and has been an\nessential part of git-add forever. But I found it to be not at all\nwhat I wanted in this case, (where I'm now trained to say \"git add\" to\nstage things into the index).\n\nI don't know of any good fix for the problem now. Maybe I'll just need to\nremember to break out that old \"git update-index\" for a situation like\nthis, but that sure feels clunky.\n\n-Carl\n"},{"id":"41621","messageId":"56b7f5510705090933t261e414es9e3cc63b28b60546@mail.gmail.com","threadId":"7999","inReplyTo":"alpine.LFD.0.98.0705090825090.4062@woody.linux-foundation.org","subject":"Re: [FAQ?] Rationale for git's way to manage the index","fromName":"Dana How","fromEmail":"danahow@gmail.com","sentAt":"2007-05-09T16:33:40Z","receivedAt":"2007-05-09T16:33:40Z","isPatch":false,"sender":{"key":"danahow@gmail.com","avatar":null},"body":"On 5/9/07, Linus Torvalds wrote:\n> - I just switch back to my starting point (and now I'm usually on\n> \"master\"), and do\n>\n> git diff -R target > diff\n>\n> to create a diff of my current tree (which is initially the starting\n> point) to the good result.\n>\n> - I actually edit the \"diff\" file by hand, and edit it down to the part I\n> actually want to commit as the first in the series. And then I just do\n> a \"git-apply diff\" to actually apply that part to my working tree.\n>\n> - I then edit any missing parts in the actual working tree (for example,\n> if there were mixed hunks that I want to get to in later commits, and I\n> edited out above, or that I need to partially undo), to do any\n> finishing touches.\n>\n> - I now have a tree I can compile and test, and has the \"first part\" of\n> the journey towards the final \"target\" state. If compiling/testing\n> shows that I missed something, I can still fix things, and/or go back\n> to doing another \"git diff -R target\" to see if I missed something).\n>\n> - I commit that first case, and repeat the sequence from step 2 (and\n> at every step, the \"diff\" file ends up shrinking and shrinking).\n\nGeez, this is similar [in nature, not scale] to what I've been doing.\nAfter reading about people \"right-clicking on hunks in git-gui\",\nI was convinced I needed to force myself to do more manipulations\ninside git itself. Hmm...\n\nMaybe, in addition to [or in] the User Manual, git should have some\nworkflow examples, which have been cribbed from various emails\non this list?\n\nThanks,\n-- \nDana L. How danahow@gmail.com +1 650 804 5991 cell\n"},{"id":"41630","messageId":"vpqabwddifi.fsf@bauges.imag.fr","threadId":"7999","inReplyTo":"vpqbqgxak1i.fsf@bauges.imag.fr","subject":"Re: [FAQ?] Rationale for git's way to manage the index","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2007-05-09T17:18:41Z","receivedAt":"2007-05-09T17:18:41Z","isPatch":false,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"Matthieu Moy writes:\n\n> (I would actually complain about the documentation not being clear\n> enough, but I'll try to complain with a contribution instead ;-) I'll\n> add something to the FAQ on the wiki, but it's down right now).\n\nAs promised, here's a FAQ entry on the wiki:\n\nhttp://git.or.cz/gitwiki/GitFaq#head-3aa45c7d75d40068e07231a5bf8a1a0db9a8b717\n\nFeel free to correct it.\n\nAnyway, thanks for the interesting discussion.\n\n-- \nMatthieu\n"},{"id":"41629","messageId":"20070509171845.GC23778@fieldses.org","threadId":"7999","inReplyTo":"56b7f5510705090933t261e414es9e3cc63b28b60546@mail.gmail.com","subject":"Re: [FAQ?] Rationale for git's way to manage the index","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2007-05-09T17:18:45Z","receivedAt":"2007-05-09T17:18:45Z","isPatch":false,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"On Wed, May 09, 2007 at 09:33:40AM -0700, Dana How wrote:\n> Geez, this is similar [in nature, not scale] to what I've been doing.\n> After reading about people \"right-clicking on hunks in git-gui\",\n> I was convinced I needed to force myself to do more manipulations\n> inside git itself. Hmm...\n> \n> Maybe, in addition to [or in] the User Manual, git should have some\n> workflow examples, which have been cribbed from various emails\n> on this list?\n\nThat's something several people have asked for, and I think it's a great\nidea--I just haven't personally had much time to get to it. But I'd\nhappily take even very rough patches and help get them into shape.\n\nThe way I'd thought of doing it was having an \"examples\" section at the\nend of each chapter, with subsections for each individual example; see\nthe one at the end of the \"exploring git history\" chapter:\n\n\thttp://www.kernel.org/pub/software/scm/git/docs/user-manual.html#history-examples\n\nThey shouldn't use the material introduced in the associated chapter,\nbut it's also OK to introduce new commands (with references to the man\npages) when their use in the example is pretty self-explanatory. (In\nfact, this is a great way to introduce more commands and options--git\nhas so many that it would be tedious to try to be comprehensive, but\nthey'd fit well in examples.)\n\nThe patch-editing stuff discussed above might fit best at the end of\n\"rewriting history and maintaining patch series\".\n\n--b.\n"},{"id":"41631","messageId":"20070509172622.GA4489@pasky.or.cz","threadId":"7999","inReplyTo":"20070509171845.GC23778@fieldses.org","subject":"Re: [FAQ?] Rationale for git's way to manage the index","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2007-05-09T17:26:22Z","receivedAt":"2007-05-09T17:26:22Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Wed, May 09, 2007 at 07:18:45PM CEST, J. Bruce Fields wrote:\n> On Wed, May 09, 2007 at 09:33:40AM -0700, Dana How wrote:\n> > Geez, this is similar [in nature, not scale] to what I've been doing.\n> > After reading about people \"right-clicking on hunks in git-gui\",\n> > I was convinced I needed to force myself to do more manipulations\n> > inside git itself. Hmm...\n> > \n> > Maybe, in addition to [or in] the User Manual, git should have some\n> > workflow examples, which have been cribbed from various emails\n> > on this list?\n> \n> That's something several people have asked for, and I think it's a great\n> idea--I just haven't personally had much time to get to it. But I'd\n> happily take even very rough patches and help get them into shape.\n> \n> The way I'd thought of doing it was having an \"examples\" section at the\n> end of each chapter, with subsections for each individual example; see\n> the one at the end of the \"exploring git history\" chapter:\n> \n> \thttp://www.kernel.org/pub/software/scm/git/docs/user-manual.html#history-examples\n> \n> They shouldn't use the material introduced in the associated chapter,\n> but it's also OK to introduce new commands (with references to the man\n> pages) when their use in the example is pretty self-explanatory. (In\n> fact, this is a great way to introduce more commands and options--git\n> has so many that it would be tedious to try to be comprehensive, but\n> they'd fit well in examples.)\n> \n> The patch-editing stuff discussed above might fit best at the end of\n> \"rewriting history and maintaining patch series\".\n\nThere is some workflow-related discussion accumulated over years in\nDocumentation/howto/, some of them also already suffering quite of a\nbitrot. :-(\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nEver try. Ever fail. No matter. // Try again. Fail again. Fail better.\n\t\t-- Samuel Beckett\n"},{"id":"41632","messageId":"20070509172914.GD23778@fieldses.org","threadId":"7999","inReplyTo":"20070509172622.GA4489@pasky.or.cz","subject":"Re: [FAQ?] Rationale for git's way to manage the index","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2007-05-09T17:29:14Z","receivedAt":"2007-05-09T17:29:14Z","isPatch":false,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"On Wed, May 09, 2007 at 07:26:22PM +0200, Petr Baudis wrote:\n> There is some workflow-related discussion accumulated over years in\n> Documentation/howto/, some of them also already suffering quite of a\n> bitrot. :-(\n\nYup. I think we should one-by-one update those and suck them into the\nmanual. (Patches accepted!)\n\n--b.\n"},{"id":"41634","messageId":"Pine.LNX.4.64.0705091322180.18541@iabervon.org","threadId":"7999","inReplyTo":"alpine.LFD.0.98.0705090825090.4062@woody.linux-foundation.org","subject":"Re: [FAQ?] Rationale for git's way to manage the index","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2007-05-09T17:39:55Z","receivedAt":"2007-05-09T17:39:55Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Wed, 9 May 2007, Linus Torvalds wrote:\n\n> Many people seem to enjoy per-hunk commits, but I seldom do that. Maybe \n> it's just because I'm *so* comfortable with diffs, that when I clean up an \n> ugly sequence of commits, what I do is literally:\n> \n> - I make sure that my ugly sequence of commits is on some temporary \n> branch, but that the _end_result_ is good and clean (ie I will have \n> tested the end result fairly well, and made sure that there are no \n> debug statements etc crud left).\n> \n> I would call this branch something like \"target\", because the end \n> result of that branch is what I'm looking for - even if the commits in \n> the sequence that gets me there are individually ugly!\n> \n> - I just switch back to my starting point (and now I'm usually on \n> \"master\"), and do\n> \n> \tgit diff -R target > diff\n> \n> to create a diff of my current tree (which is initially the starting \n> point) to the good result.\n> \n> - I actually edit the \"diff\" file by hand, and edit it down to the part I \n> actually want to commit as the first in the series. And then I just do \n> a \"git-apply diff\" to actually apply that part to my working tree.\n> \n> - I then edit any missing parts in the actual working tree (for example, \n> if there were mixed hunks that I want to get to in later commits, and I \n> edited out above, or that I need to partially undo), to do any \n> finishing touches.\n> \n> - I now have a tree I can compile and test, and has the \"first part\" of \n> the journey towards the final \"target\" state. If compiling/testing \n> shows that I missed something, I can still fix things, and/or go back \n> to doing another \"git diff -R target\" to see if I missed something).\n> \n> - I commit that first case, and repeat the sequence from step 2 (and \n> at every step, the \"diff\" file ends up shrinking and shrinking).\n> \n> The above sounds like it's a complicated sequence, but it really isn't. \n> Partly because I just am very comfortable with diffs indeed (probably more \n> than most people), but partly because at all times \"git diff\" works fine \n> to see what I've done, and what the diff to \"target\" is.\n\nIt only sounds like a complicated sequence because you didn't write a \nscript to do it...\n\n$ git checkout -b clean origin\n$ git-refine target\n (edit the patch in the editor that pops up)\n$ git-refine\nTest changes and commit\n$ make test\n...\n$ git commit\n (write message)\n$ git-refine\n (edit the patch, etc)\n ...\n$ git commit\n$ git-refine\nAll done.\n\nI actually wrote it years ago, but I couldn't describe my workflow well \nenough, so I didn't submit it. If everybody seems to be doing the same \nthing, I can submit my script...\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"41636","messageId":"alpine.LFD.0.98.0705091103290.4062@woody.linux-foundation.org","threadId":"7999","inReplyTo":"Pine.LNX.4.64.0705091322180.18541@iabervon.org","subject":"Re: [FAQ?] Rationale for git's way to manage the index","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-05-09T18:16:53Z","receivedAt":"2007-05-09T18:16:53Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 9 May 2007, Daniel Barkalow wrote:\n> \n> It only sounds like a complicated sequence because you didn't write a \n> script to do it...\n\nWell, I actually think it sounds like a complicated sequence because I \ntried to explain what I do.\n\nThe \"script\" parts don't really end up being any smaller, and not \nscripting it actually means that I can (and often do) things outside of a \nstrict scripting environment.\n\nAs mentioned, I not only mix it up with \"git cherry-pick\", but since I \njust use \"git diff\", I can - and do - things like pick only a certain set \nof files to diff and edit the patch on. \n\nSo it's an iterative process at several levels (the \"outer\" level is the \nact of actually committing each change, and iterating to the next one, \nwhile the \"inner\" level is often a sequence of \"git diff\" exploration), \nit's not very fixed. \n\nFor example, when I said that I do a \n\n\tgit diff -R target > diff\n\nthat's not strictly true. The \"git diff -R\" is useful for comparing the \ncurrent working tree to another commit, but quite often I actually end up \ndoing it differently, and doing it as\n\n\tgit diff ..target file > diff\n\t.. edit ..\n\tgit apply diff\n\nor, if I don't need the edit (ie just the fact that I limit it to a single \nfile is a sufficient \"edit\" in itself), I might just do\n\n\tgit checkout target file\n\ninstead, which will fetch the whole file from the \"target\" branch (and \nalso update it in the index, which may or may not actually be what I want, \nbut that's a different issue).\n\nSo the \"process\" as far as I'm concerned is actually much more fluid than \nnecessarily always working with diffs. Git gives you so many ways to do \nthings like this, and I'm pretty comfortable with lots of them.\n\n\t\t\tLinus\n"},{"id":"41692","messageId":"7vzm4dplhu.fsf@assigned-by-dhcp.cox.net","threadId":"7999","inReplyTo":"alpine.LFD.0.98.0705090825090.4062@woody.linux-foundation.org","subject":"Re: [FAQ?] Rationale for git's way to manage the index","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-05-10T00:31:41Z","receivedAt":"2007-05-10T00:31:41Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> And unlike the \"simpler\" model of committing individual hunks\n> with \"git add -i\" or something like that, my model is actually\n> much superior!\n\nI obviously agree with this. As I said a few times I regret\nintroducing \"add -i\" --- it encourages a wrong workflow, in that\nwhat you commit in steps never match what you had in the working\ntree and could have tested until the very end.\n"},{"id":"41693","messageId":"7vsla5pkug.fsf@assigned-by-dhcp.cox.net","threadId":"7999","inReplyTo":"20070509142426.GV4489@pasky.or.cz","subject":"Re: [PATCH] git-commit: Reformat log messages provided on commandline","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-05-10T00:45:43Z","receivedAt":"2007-05-10T00:45:43Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Petr Baudis writes:\n\n> diff --git a/git-commit.sh b/git-commit.sh\n> index f28fc24..28cbb55 100755\n> --- a/git-commit.sh\n> +++ b/git-commit.sh\n> @@ -432,7 +432,7 @@ fi\n> \n> if test \"$log_message\" != ''\n> then\n> -\techo \"$log_message\"\n> +\techo \"$log_message\" | fmt\n> elif test \"$logfile\" != \"\"\n\nTwo points.\n\n * You would not want to wrap the first line;\n\n * 75-column is not ideal for every project, so this needs to be\n customizable;\n\n * If we were to munge the given message, we would probably also\n want to enforce \"single-liner summary, empty line, and then\n the rest\" convention.\n\nWell, I have three there, but I suspect the first two somebody else\nmay have said already, so...\n\nThis is slightly related, but I have been wondering about the\ninteraction with \"single-liner summary, empty line and then the\nrest\" convention and various commands in the log family.\n\nCurrently, --pretty=oneline and --pretty=email (hence format-patch)\ntake and use only the first line. I think we could change it to:\n\n - take the first paragraph, where the definition of the first\n paragraph is \"skip all blank lines from the beginning, and\n then grab everything up to the next empty line\".\n\n - replace all line breaks with a whitespace.\n\nThis change would not affect well-behaved commit messages that\nadhere to the convention, as their first paragraph always\nconsist of a single line. On the other hand, people from\ndifferent culture can get frustrated by their commit message\nchomped at the first linebreak in the middle of sentence right\nnow, which would be helped by this change.\n\nTheir Subject: and --pretty=oneline output would become very\nlong and unsightly, but their commit messages are already\nugly anyway, and such a change at least avoid the loss of\ninformation.\n\nIf we were to do this, Subject: line would most likely use\nRFC2822 line folding at the places where line breaks were in the\noriginal, but that goes without saying.\n\nWhat do people think?\n"},{"id":"41701","messageId":"4642831C.2090401@midwinter.com","threadId":"7999","inReplyTo":"7vzm4dplhu.fsf@assigned-by-dhcp.cox.net","subject":"Re: [FAQ?] Rationale for git's way to manage the index","fromName":"Steven Grimm","fromEmail":"koreth@midwinter.com","sentAt":"2007-05-10T02:27:40Z","receivedAt":"2007-05-10T02:27:40Z","isPatch":false,"sender":{"key":"koreth@midwinter.com","avatar":"https://gravatar.com/avatar/71b4d2e8b62f168bdc9e9205341159e3567003b4f9e2127c617c5fa0a1f5bad2?d=mp&s=160"},"body":"Junio C Hamano wrote:\n> I obviously agree with this. As I said a few times I regret\n> introducing \"add -i\" --- it encourages a wrong workflow, in that\n> what you commit in steps never match what you had in the working\n> tree and could have tested until the very end.\n> \n\nOn the other hand, not all changes require any testing at all. For \nexample, if you're using git to manage documentation, it is totally \nreasonable to commit a fix for a simple spelling error in one part of a \nfile while not committing an in-progress rewrite of another part.\n\n-Steve\n"},{"id":"41702","messageId":"alpine.LFD.0.98.0705091934440.4062@woody.linux-foundation.org","threadId":"7999","inReplyTo":"4642831C.2090401@midwinter.com","subject":"Re: [FAQ?] Rationale for git's way to manage the index","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-05-10T02:39:01Z","receivedAt":"2007-05-10T02:39:01Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 9 May 2007, Steven Grimm wrote:\n\n> Junio C Hamano wrote:\n> > I obviously agree with this. As I said a few times I regret\n> > introducing \"add -i\" --- it encourages a wrong workflow, in that\n> > what you commit in steps never match what you had in the working\n> > tree and could have tested until the very end.\n> > \n> \n> On the other hand, not all changes require any testing at all. For example, if\n> you're using git to manage documentation, it is totally reasonable to commit a\n> fix for a simple spelling error in one part of a file while not committing an\n> in-progress rewrite of another part.\n\nYeah, I don't think \"git add -i\" is a horrible flow - it just shouldn't be \nthe only or the primary one (ie apparently it *is* the primary one for \ndarcs, and that's a mistake!)\n\nOf course, whether \"git add -i\" is a nice interface or not, I dunno. \nPersonally, if I wanted to do hunk selection, I think I'd stick to \nsomething graphical where I can just click on the hunks. But that's just \nme.\n\n\t\tLinus\n"},{"id":"41717","messageId":"vpq1whp5cqt.fsf@bauges.imag.fr","threadId":"7999","inReplyTo":"alpine.LFD.0.98.0705091934440.4062@woody.linux-foundation.org","subject":"Re: [FAQ?] Rationale for git's way to manage the index","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2007-05-10T08:00:58Z","receivedAt":"2007-05-10T08:00:58Z","isPatch":false,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"Linus Torvalds writes:\n\n> Yeah, I don't think \"git add -i\" is a horrible flow - it just shouldn't be \n> the only or the primary one (ie apparently it *is* the primary one for \n> darcs, and that's a mistake!)\n\nNote that darcs has a way to test before commit even for partial\ncommits. It re-creates your working tree, hardlinking unmodified\nfiles, and runs a command there as a precommit hook.\n\nI still prefer the old good \"you commit what's in the tree, and run\nwhatever you want before commit\", but their approach seems interesting\nalso in this case.\n\n-- \nMatthieu\n"},{"id":"41783","messageId":"20070510220649.GL3141@spearce.org","threadId":"7999","inReplyTo":"7vzm4dplhu.fsf@assigned-by-dhcp.cox.net","subject":"Re: [FAQ?] Rationale for git's way to manage the index","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-05-10T22:06:49Z","receivedAt":"2007-05-10T22:06:49Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Junio C Hamano wrote:\n> Linus Torvalds writes:\n> \n> > And unlike the \"simpler\" model of committing individual hunks\n> > with \"git add -i\" or something like that, my model is actually\n> > much superior!\n> \n> I obviously agree with this. As I said a few times I regret\n> introducing \"add -i\" --- it encourages a wrong workflow, in that\n> what you commit in steps never match what you had in the working\n> tree and could have tested until the very end.\n\nWhich is why I'm considering shelving support (of some kind) in\ngit-gui... but I'm probably not going to take away the current\nindex view, nor am I going to take away the current hunk selection.\n\nBut I would like to make it easier for non-patching-editing gods\n(Linus) to pull hunks in from a shelf, test them, and commit them.\n\nSaid shelf probably would be another branch, much as Linus' nicely\ndocumented workflow does...\n\n-- \nShawn.\n"},{"id":"41791","messageId":"20070510225137.GE4489@pasky.or.cz","threadId":"7999","inReplyTo":"20070510220649.GL3141@spearce.org","subject":"Re: [FAQ?] Rationale for git's way to manage the index","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2007-05-10T22:51:37Z","receivedAt":"2007-05-10T22:51:37Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Fri, May 11, 2007 at 12:06:49AM CEST, Shawn O. Pearce wrote:\n> Which is why I'm considering shelving support (of some kind) in\n> git-gui... but I'm probably not going to take away the current\n> index view, nor am I going to take away the current hunk selection.\n> \n> But I would like to make it easier for non-patching-editing gods\n> (Linus) to pull hunks in from a shelf, test them, and commit them.\n> \n> Said shelf probably would be another branch, much as Linus' nicely\n> documented workflow does...\n\nFWIW, Cogito supports shelving of uncommitted changes when switching a\nbranch (so that they are not retained through the switch but restored\nwhen you switch back to the original branch) by committing the local\nchanges to refs/shelves/HEADNAME.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nEver try. Ever fail. No matter. // Try again. Fail again. Fail better.\n\t\t-- Samuel Beckett\n"},{"id":"41797","messageId":"f20gjc$rne$1@sea.gmane.org","threadId":"7999","inReplyTo":"873b26klkj.wl%cworth@cworth.org","subject":"Re: [FAQ?] Rationale for git's way to manage the index","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-05-11T01:28:31Z","receivedAt":"2007-05-11T01:28:31Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Carl Worth wrote:\n\n> This reminds me of a confusing semantic issue that came about with the\n> \"new\" add. It can be quite natural to commit a single file in one step\n> with:\n> \n> git commit some-file.c\n> \n> or to do that in two steps with:\n> \n> git add some-file.c\n> git commit\n> \n> (which is particularly useful if one wants to add multiple files).\n> \n> I recently found myself wanting to do a similar thing with a directory\n> path. I can commit a path with:\n> \n> git commit path/\n> \n> but I don't get anything at all like the same semantics if I do:\n> \n> git add path/\n> git commit\n> \n> (since \"git add\" will recursively add all untracked files under path/).\n> \n> Now the \"recursively add all files\" behavior is older, and has been an\n> essential part of git-add forever. But I found it to be not at all\n> what I wanted in this case, (where I'm now trained to say \"git add\" to\n> stage things into the index).\n> \n> I don't know of any good fix for the problem now. Maybe I'll just need to\n> remember to break out that old \"git update-index\" for a situation like\n> this, but that sure feels clunky.\n\nIn the new version of git I *think* you can use \"git add -u path/\"\n\n 'git-add' [-n] [-v] [-f] [--interactive | -i] [-u] [--] ...\n\n -u::\n Update all files that git already knows about. This is what\n \"git commit -a\" does in preparation for making a commit.\n\n(in v1.5.2-rc0, documented in v1.5.2-rc3).\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"41826","messageId":"200705111326.35577.jnareb@gmail.com","threadId":"7999","inReplyTo":"7vd518gkyo.fsf@assigned-by-dhcp.cox.net","subject":"Re: [FAQ?] Rationale for git's way to manage the index","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-05-11T11:26:35Z","receivedAt":"2007-05-11T11:26:35Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Fri, 11 May 2007, Junio C Hamano wrote:\n> Jakub Narebski writes:\n> \n>> In the new version of git I *think* you can use \"git add -u path/\"\n> \n> I know you meant well, but next time could you please check the\n> fact before speaking?\n\n> \t\tif (i < argc)\n> \t\t\tdie(\"-u and explicit paths are incompatible\");\n\n> The list is getting more and more cluttered recently, perhaps\n> which is a good sign that more new people are actually using\n> git. Let's try to keep the signal quality of the messages on\n> the list high.\n\nI'm sorry I haven't checked this before writing, especially that\ninformation in the synopsis contradict a bit the information in\nthe `-u' option description:\n\nDocumentation/git-add.txt:\n\n SYNOPSIS\n --------\n 'git-add' [-n] [-v] [-f] [--interactive | -i] [-u] [--] ...\n\n -u::\n Update all files that git already knows about. This is what\n \"git commit -a\" does in preparation for making a commit.\n\nI should have checked the facts before following the synopsis.\n\nI think however that \"git add -u dir/\" could be quite useful; it is\nnot needed to have `-u' and explicit paths incompatibile. I wouldn't\nchange the fact that you can say \"git add -u\" and do not need \n\"git add -u .\" (like in the case without `-u' switch: you need \n\"git add .\" to 'add' all unignored files).\n\n\nBelow there is a patch which corrects synopsis for git add;\nunless you want to go the route of allowing \"git add -u dir/\"...\n\n-- >8 --\nFrom: Jakub Narebski \nDate: Fri, 11 May 2007 13:22:13 +0200\nSubject: [PATCH] Documentation: Correct synopsis for git-add command\n\nChange SYNOPISIS section of Documentation/git-add.txt to mark it\nexplicitely that \"-u option and explicit paths are incompatible\",\nand that \"add --interactive does not take any parameters\".\n\nSigned-off-by: Jakub Narebski \n---\n Documentation/git-add.txt | 3 ++-\n 1 files changed, 2 insertions(+), 1 deletions(-)\n\ndiff --git a/Documentation/git-add.txt b/Documentation/git-add.txt\nindex ea27018..e5fc0da 100644\n--- a/Documentation/git-add.txt\n+++ b/Documentation/git-add.txt\n@@ -7,7 +7,8 @@ git-add - Add file contents to the changeset to be committed next\n \n SYNOPSIS\n --------\n-'git-add' [-n] [-v] [-f] [--interactive | -i] [-u] [--] ...\n+'git-add' [-n] [-v] [-f] [-u | [--] ...]\n+'git-add' (--interactive | -i)\n \n DESCRIPTION\n -----------\n-- \n1.5.1.3\n\n\n-- \nJakub Narebski\nPoland\n"},{"id":"41838","messageId":"7v7irfcns1.fsf@assigned-by-dhcp.cox.net","threadId":"7999","inReplyTo":"200705111326.35577.jnareb@gmail.com","subject":"Re: [FAQ?] Rationale for git's way to manage the index","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-05-11T16:45:18Z","receivedAt":"2007-05-11T16:45:18Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jakub Narebski writes:\n\n> On Fri, 11 May 2007, Junio C Hamano wrote:\n>> Jakub Narebski writes:\n>> \n>>> In the new version of git I *think* you can use \"git add -u path/\"\n>> \n>> I know you meant well, but next time could you please check the\n>> fact before speaking?\n>\n>> \t\tif (i < argc)\n>> \t\t\tdie(\"-u and explicit paths are incompatible\");\n>\n>> The list is getting more and more cluttered recently, perhaps\n>> which is a good sign that more new people are actually using\n>> git. Let's try to keep the signal quality of the messages on\n>> the list high.\n>\n> I'm sorry I haven't checked this before writing, especially that\n> information in the synopsis contradict a bit the information in\n> the `-u' option description:\n> ...\n> -u::\n> Update all files that git already knows about. This is what\n> \"git commit -a\" does in preparation for making a commit.\n\nWhat does \"git commit -a\" do? Does it take paths?\n\n> I think however that \"git add -u dir/\" could be quite useful; it is\n> not needed to have `-u' and explicit paths incompatibile.\n\nI tend to agree, and I think that change should not be too\ndifficult.\n\nAlso it might make sense to have \"git commit\" use it in the\n\"git-commit --only $paths\" codepath. I dunno.\n"},{"id":"41873","messageId":"200705120106.53624.jnareb@gmail.com","threadId":"7999","inReplyTo":"7v7irfcns1.fsf@assigned-by-dhcp.cox.net","subject":"Re: [FAQ?] Rationale for git's way to manage the index","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-05-11T23:06:52Z","receivedAt":"2007-05-11T23:06:52Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n> Jakub Narebski writes:\n>> On Fri, 11 May 2007, Junio C Hamano wrote:\n>>> Jakub Narebski writes:\n>>> \n>>>> In the new version of git I *think* you can use \"git add -u path/\"\n>>> \n>>> I know you meant well, but next time could you please check the\n>>> fact before speaking?\n>>\n>>> \t\tif (i < argc)\n>>> \t\t\tdie(\"-u and explicit paths are incompatible\");\n>>\n>>> The list is getting more and more cluttered recently, perhaps\n>>> which is a good sign that more new people are actually using\n>>> git. Let's try to keep the signal quality of the messages on\n>>> the list high.\n>>\n>> I'm sorry I haven't checked this before writing, especially that\n>> information in the synopsis contradict a bit the information in\n>> the `-u' option description:\n>> ...\n>> -u::\n>> Update all files that git already knows about. This is what\n>> \"git commit -a\" does in preparation for making a commit.\n> \n> What does \"git commit -a\" do? Does it take paths?\n\nI was mislead by synopsis, which reads:\n\n 'git-add' [-n] [-v] [-f] [--interactive | -i] [-u] [--] ...\n\nIt looks from it like -u is _not_ incompatibile with explicit paths;\nmoreover it looks like explicit path is _required_.\n\n>> I think however that \"git add -u dir/\" could be quite useful; it is\n>> not needed to have `-u' and explicit paths incompatibile.\n> \n> I tend to agree, and I think that change should not be too\n> difficult.\n\nSo do you want to accept my patch for git-add documentation for now,\nor rather the replacement patch below? Well, best with the patch that\nchanges -u to be able to work with explicit codepath...\n \n> Also it might make sense to have \"git commit\" use it in the\n> \"git-commit --only $paths\" codepath. I dunno.\n\nDidn't you mean \"git commit --include $paths\" codepath? IIRC --only\ncodepath deals with temporary index...\n\n-- >8 --\nFrom: Jakub Narebski \nDate: Sat, 12 May 2007 01:05:01 +0200\nSubject: [PATCH] Documentation: Correct synopsis for git-add command\n\nChange SYNOPISIS section of Documentation/git-add.txt to mark it\nexplicitely that -u option does not need explicit paths, and that\n\"add --interactive does not take any parameters\".\n\nSigned-off-by: Jakub Narebski \n---\n Documentation/git-add.txt | 3 ++-\n 1 files changed, 2 insertions(+), 1 deletions(-)\n\ndiff --git a/Documentation/git-add.txt b/Documentation/git-add.txt\nindex ea27018..3c6d431 100644\n--- a/Documentation/git-add.txt\n+++ b/Documentation/git-add.txt\n@@ -7,7 +7,8 @@ git-add - Add file contents to the changeset to be committed next\n \n SYNOPSIS\n --------\n-'git-add' [-n] [-v] [-f] [--interactive | -i] [-u] [--] ...\n+'git-add' [-n] [-v] [-f] (-u [[--] ...] | [--] ...)\n+'git-add' (--interactive | -i)\n \n DESCRIPTION\n -----------\n-- \n1.5.1.3\n"},{"id":"41874","messageId":"f23187$5p7$1@sea.gmane.org","threadId":"7999","inReplyTo":"7vsla5pkug.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] git-commit: Reformat log messages provided on commandline","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-05-12T00:25:02Z","receivedAt":"2007-05-12T00:25:02Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n\n> This is slightly related, but I have been wondering about the\n> interaction with \"single-liner summary, empty line and then the\n> rest\" convention and various commands in the log family.\n> \n> Currently, --pretty=oneline and --pretty=email (hence format-patch)\n> take and use only the first line. I think we could change it to:\n> \n> - take the first paragraph, where the definition of the first\n> paragraph is \"skip all blank lines from the beginning, and\n> then grab everything up to the next empty line\".\n> \n> - replace all line breaks with a whitespace.\n[...]\n> If we were to do this, Subject: line would most likely use\n> RFC2822 line folding at the places where line breaks were in the\n> original, but that goes without saying.\n> \n> What do people think?\n\nI agree that it is a good idea. This would e.g. help projects which are\nimported from other SCM, which does not have \"single-liner summary, empty\nline and then the rest\" convention of formatting commit messages.\n\nBTW. does rebase work correctly for commits which do not use above\nconvention?\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"41878","messageId":"7vlkfu98nn.fsf@assigned-by-dhcp.cox.net","threadId":"7999","inReplyTo":"200705120106.53624.jnareb@gmail.com","subject":"Re: [FAQ?] Rationale for git's way to manage the index","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-05-12T00:40:12Z","receivedAt":"2007-05-12T00:40:12Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jakub Narebski writes:\n\n> -'git-add' [-n] [-v] [-f] [--interactive | -i] [-u] [--] ...\n> +'git-add' [-n] [-v] [-f] (-u [[--] ...] | [--] ...)\n\nI do not think this is correct; does -u take optionally path and\nwhen path is ambiguous you can add -- to disambiguate?\n\nHonestly, I would rather not sprinkle synopsis with too many\nnested parentheses and brackets, which only makes it harder to\nsee without giving a clear \"this combines with that but is not\ncompatible with the other\" information. Adding comment to the\nsection that begins with \"-u::\" that says \"... commit -a; this\noption does not take any paths parameters.\" would be cleaner,\nand easier to understand.\n\nOf course, I would prefer a patch to allow use of paths with -u\neven more, but that is what I already said ;-).\n"},{"id":"41879","messageId":"200705120306.03806.jnareb@gmail.com","threadId":"7999","inReplyTo":"7vlkfu98nn.fsf@assigned-by-dhcp.cox.net","subject":"Re: [FAQ?] Rationale for git's way to manage the index","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-05-12T01:06:03Z","receivedAt":"2007-05-12T01:06:03Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n> Jakub Narebski writes:\n> \n>> -'git-add' [-n] [-v] [-f] [--interactive | -i] [-u] [--] ...\n>> +'git-add' [-n] [-v] [-f] (-u [[--] ...] | [--] ...)\n> \n> I do not think this is correct; does -u take optionally path and\n> when path is ambiguous you can add -- to disambiguate?\n[...]\nWith *current* implementation you should take previous patch, \namended, with the following synopsis:\n\n-'git-add' [-n] [-v] [-f] [--interactive | -i] [-u] [--] ...\n+'git-add' [-n] [-v] [-f] (-u | [--] ...)\n+'git-add' (--interactive | -i)\n\n> Of course, I would prefer a patch to allow use of paths with -u\n> even more, but that is what I already said ;-).\n\nThe following synopsis is for such case:\n\n-'git-add' [-n] [-v] [-f] [--interactive | -i] [-u] [--] ...\n+'git-add' [-n] [-v] [-f] (-u [[--] ...] | [--] ...)\n+'git-add' (--interactive | -i)\n\nThis is for \"-u take optionally path and when path is ambiguous you can \nadd -- to disambiguate\", for example if you have '--interactive' file.\n\n-- \nJakub Narebski\nPoland\n"},{"id":"41909","messageId":"200705121135.13142.jnareb@gmail.com","threadId":"7999","inReplyTo":"7vlkfu98nn.fsf@assigned-by-dhcp.cox.net","subject":"Re: [FAQ?] Rationale for git's way to manage the index","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-05-12T09:35:12Z","receivedAt":"2007-05-12T09:35:12Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n> Jakub Narebski writes:\n> \n> > -'git-add' [-n] [-v] [-f] [--interactive | -i] [-u] [--] ...\n> > +'git-add' [-n] [-v] [-f] (-u [[--] ...] | [--] ...)\n> \n> I do not think this is correct; does -u take optionally path and\n> when path is ambiguous you can add -- to disambiguate?\n> \n> Honestly, I would rather not sprinkle synopsis with too many\n> nested parentheses and brackets, which only makes it harder to\n> see without giving a clear \"this combines with that but is not\n> compatible with the other\" information. Adding comment to the\n> section that begins with \"-u::\" that says \"... commit -a; this\n> option does not take any paths parameters.\" would be cleaner,\n> and easier to understand.\n> \n> Of course, I would prefer a patch to allow use of paths with -u\n> even more, but that is what I already said ;-).\n\nThis synopisis is for _after_ patch mentioned above. If you don't\nlike too complicated (too deeply nested) expression in synopsis, it\ncould always be written as:\n\n-'git-add' [-n] [-v] [-f] [--interactive | -i] [-u] [--] ...\n+'git-add' [-n] [-v] [-f] [--] ...\n+'git-add' [-n] [-v] [-f] -u [[--] ...]\n\nor something like that\n-- \nJakub Narebski\nPoland\n"},{"id":"42192","messageId":"87wszagayt.fsf@morpheus.local","threadId":"7999","inReplyTo":"8b65902a0705070440t40889af0p1fb8dbf7e2a072e4@mail.gmail.com","subject":"Re: [FAQ?] Rationale for git's way to manage the index","fromName":"David Kågedal","fromEmail":"davidk@lysator.liu.se","sentAt":"2007-05-15T00:57:30Z","receivedAt":"2007-05-15T00:57:30Z","isPatch":false,"sender":{"key":"davidk@lysator.liu.se","avatar":"https://avatars.githubusercontent.com/u/60530?v=4"},"body":"\"Guilhem Bonnefille\" writes:\n\n> In order to improve my productivity with Git, and in order to avoid\n> traps around moving from SVN to Git, I often use the Git Emacs mode.\n> It is really usefull for beginners as it works similarly for CVS, SVN\n> and Git: synthetic view of all modifications, easy selection of what\n> will be commited... The biggest drawback of this \"porcelain\": using\n> it, you do not understand the Git's index philosophy.\n\nAnd it's broken as well. If you \"update\" in the emacs mode you cannot\ndo a \"git commit\" in a terminal without manually running \"git\nupdate-index\" first.\n\nI think an emacs-mode that is closer to git-gui would be better, and\ncloser to the git philosophy\n\n-- \nDavid Kågedal\n"},{"id":"42195","messageId":"87sl9ygau1.fsf@morpheus.local","threadId":"7999","inReplyTo":"Pine.LNX.4.64.0705081256410.4167@racer.site","subject":"Re: [FAQ?] Rationale for git's way to manage the index","fromName":"David Kågedal","fromEmail":"davidk@lysator.liu.se","sentAt":"2007-05-15T01:00:22Z","receivedAt":"2007-05-15T01:00:22Z","isPatch":false,"sender":{"key":"davidk@lysator.liu.se","avatar":"https://avatars.githubusercontent.com/u/60530?v=4"},"body":"Johannes Schindelin writes:\n\n> Hi,\n>\n> On Tue, 8 May 2007, Martin Langhoff wrote:\n>\n>> Heh. Making the index very visible makes sense when you are merging,\n>\n> You're saying that the main use of the index is to help merging. I have to \n> disagree strongly.\n>\n> When I have been chasing a bug all over the place, and finally found it, \n> my working tree is a mess. Lots of assertions, lots of debugging \n> statements, some of them commented out. So, now it is cleanup time, right?\n>\n> The problem is that more often than not, I broke my fix while cleaning up.\n>\n> Therefore, I now put all changed files into the index (git add -u), and \n> clean up the files one by one, always checking with \"git diff\" and \"git \n> diff HEAD\" what I still have to do.\n\nWhy not simply use a temporary branch for this? They're free, and you\ncan diff just as easily, if not more. And you don't risk losing it if\nyou slip with a command.\n\n-- \nDavid Kågedal\n"},{"id":"42201","messageId":"20070515082935.GC9096@diana.vm.bytemark.co.uk","threadId":"7999","inReplyTo":"87wszagayt.fsf@morpheus.local","subject":"Re: [FAQ?] Rationale for git's way to manage the index","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2007-05-15T08:29:35Z","receivedAt":"2007-05-15T08:29:35Z","isPatch":false,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2007-05-14 17:57:30 -0700, David Kågedal wrote:\n\n> And it's broken as well. If you \"update\" in the emacs mode you\n> cannot do a \"git commit\" in a terminal without manually running \"git\n> update-index\" first.\n>\n> I think an emacs-mode that is closer to git-gui would be better, and\n> closer to the git philosophy\n\nI agree. (But for the record, I find the existing Emacs mode\ntremendously useful too. It's just that in some circumstances, you can\nget confused if you don't know what you're doing.)\n\n-- \nKarl Hasselström, kha@treskal.com\n www.treskal.com/kalle\n"},{"id":"42264","messageId":"Pine.LNX.4.64.0705152305460.6410@racer.site","threadId":"7999","inReplyTo":"87sl9ygau1.fsf@morpheus.local","subject":"Re: [FAQ?] Rationale for git's way to manage the index","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-05-15T23:27:40Z","receivedAt":"2007-05-15T23:27:40Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 14 May 2007, David Kågedal wrote:\n\n> Johannes Schindelin writes:\n> \n> > Therefore, I now put all changed files into the index (git add -u), \n> > and clean up the files one by one, always checking with \"git diff\" and \n> > \"git diff HEAD\" what I still have to do.\n> \n> Why not simply use a temporary branch for this? They're free, and you \n> can diff just as easily, if not more. And you don't risk losing it if \n> you slip with a command.\n\nBecause it is much faster to work with the index?\n\nCiao,\nDscho"}]}