{"thread":{"id":"6353","subject":"Importing from tarballs; add, rm, update-index?","startedAt":"2007-01-12T13:41:21Z","lastAt":"2007-01-16T12:12:12Z","messageCount":38,"participants":["Chris Riddoch","Morten Welinder","Junio C Hamano","Peter Baumann","Carl Worth","Jakub Narebski","Johannes Schindelin","Brian Gernhardt","Julian Phillips","Alan Chandler","Nicolas Pitre","Shawn O. Pearce","Daniel Barkalow","Horst H. von Brand","Christian MICHON"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"31553","messageId":"6efbd9b70701120541n5dc4d0e1va50ae96543d8c80@mail.gmail.com","threadId":"6353","inReplyTo":null,"subject":"Importing from tarballs; add, rm, update-index?","fromName":"Chris Riddoch","fromEmail":"riddochc@gmail.com","sentAt":"2007-01-12T13:41:21Z","receivedAt":"2007-01-12T13:41:21Z","isPatch":false,"sender":{"key":"riddochc@gmail.com","avatar":null},"body":"Hi, folks.\n\nI've got a very, very old codebase I'm trying to wrap my head around.\nIt was apparently once tracked with RCS, but the ,v files are long\ngone and all that remains are a series of tarballs on an FTP site\ncontaining alpha, beta, and final releases of various versions of the\nproject. There's a logical progression, but between each there are\nnew files, deleted files, and lots of changed files. gitk will at\nleast help me make sense of the actual changes. I've got part of a\nshell script to automate this process.\n\nHere's the problem.\n\nI have tried to follow the debate on git add, rm, commit -a, etc. But\nI can't figure out how to simply say, take the full state of the\nworking directory, and make the index directly reflect that state.\nAdditions, removals, and differences alike. One step, preferably.\n\nMy 2 cents on recent UI changes: I'm quite uncertain about the correct\n(future 1.5.0) way of handling this kind of change to the index. To\nelaborate:\n\nFirst, specifying extra files after 'git commit' bypasses the index.\nIf I remove foo.txt, and want to make a new commit reflecting only\nthat removal, would 'git commit foo.txt' do what I mean? Apparently\nso; I had to test it to find out, though. It is a little surprising.\n\nUsing the 'add' command to really mean 'record the state of this file'\nis confusing. It makes me think of CVS's add (predictably), which\nmakes note of a new file and I think, \"Well, I read on the list that\nthis is just another kind of 'adding content to the index,' right?\"\nOkay, I can accept that. But using the 'git add .' idiom makes me\nwonder whether the subdirectories are also supposed to be added, or\nwhether I need to worry about a recursive option. Oddly, 'git pull .'\ndoesn't make me blink. But then I need to remember to use 'git add'\nto keep track of most changes in the index, new files and edits alike.\n I suspect a newbie coming from CVS might even use the word \"re-add\"\nin their head to understand 'add'.\n\nBut this makes 'git rm' quite confusing. After thinking I finally\nunderstand 'git add', I think 'git rm' would mean \"record the new\n(nonexistent) state of this file in the index.\" And then I'm\nsurprised to discover the file in my working directory actually\nremoved. No, I guess I needed --cached. Oops. Wait a minute.\nCache? The same cache mentioned in glossary.txt as being \"Obsolete\nfor index?\"\n\nIf rm is the opposite of add, shouldn't it work on the index by\ndefault? Hmm... \"adding content to the index.\" This file being\nremoved is new information that needs to be added to the index, like a\nmodification. Removing a file is a kind of modification, after all.\nI think this was the logic behind someone's suggestion of 'git add\n--remove' which is quite ridiculous but follows somewhat naturally\nfrom the idea that 'git add' is supposed to add information about\nchanges in the working directory to the index.\n\nAt this point, I think the behavior of 'git add' is as ridiculous as\nthat of 'git rm'. Recent changes to 'git add' and 'git rm' make me\nbelieve we're indecisive about whether we want people to think in\nterms of the index or not. I get the impression we're leaning towards\nencouraging awareness of the index, because it's so helpful with\nmerges.\n\nYou know what I think we need? A good command for updating the index.\n It could even be both porcelain and plumbing, if it had the right\nerror-checking.\n\nI suggest calling it something like update-index. ;)\n\nUnless I'm completely misunderstanding git?\n\n-- \nepistemological humility\n Chris Riddoch\n"},{"id":"31558","messageId":"118833cc0701120640o3cae8c14t5b5ba6ee6f022b53@mail.gmail.com","threadId":"6353","inReplyTo":"6efbd9b70701120541n5dc4d0e1va50ae96543d8c80@mail.gmail.com","subject":"Re: Importing from tarballs; add, rm, update-index?","fromName":"Morten Welinder","fromEmail":"mwelinder@gmail.com","sentAt":"2007-01-12T14:40:41Z","receivedAt":"2007-01-12T14:40:41Z","isPatch":false,"sender":{"key":"mwelinder@gmail.com","avatar":null},"body":"I did this with a large pile of tarballs, see\n\n http://blogs.gnome.org/view/mortenw/2007/01/07/0\n\nfor the script.\n\nBottom line: git is very, very good at compressing a pile of related tarballs.\nIn fact, about 10x better than gzip.\n\n(Not really surprising, of course.)\n"},{"id":"31574","messageId":"7virfct737.fsf@assigned-by-dhcp.cox.net","threadId":"6353","inReplyTo":"6efbd9b70701120541n5dc4d0e1va50ae96543d8c80@mail.gmail.com","subject":"Re: Importing from tarballs; add, rm, update-index?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-12T18:47:56Z","receivedAt":"2007-01-12T18:47:56Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Chris Riddoch\" writes:\n\n> I suggest calling it something like update-index. ;)\n\nExactly.\n\nPeople new to git need to learn that the next commit is prepared\nnot in the working tree but in a separate entity (staging area),\nand there are ways to update what it consists of. If that\nconcept is new for people coming from other SCM, renaming\n\"index\" to \"staging area\" only reduces potential confusion\n(because \"index\" is too generic word that can mean anything) --\nit does not remove the need to learn the new concept.\n\nAnd we have called that staging area \"the index\", and the act of\nupdating what it consists of has been called \"updating the\nindex\" for a long time. The primary command to do so has been\n\"git-update-index\" plumbing, but we added some sugarcoating and\nnow \"git-add\" and \"git-rm\" (also \"git-merge\", \"git-am\" and\nfriends \"updates the index\" for automatable cases) are two most\nvisible ways for the users.\n\nThe logical name for the operation, if we _were_ to have only\none command for \"updating the index\", is \"git-update\" or\n\"git-update-index\". I do not have anything against \"git stage\"\nbut I simply do not see the point, other than \"git update\" would\nimply something entirely different to people coming from other\nSCM so we would want to avoid the word, and \"git update-index\"\nis too long to type every day.\n\nIn any case, there are valid reasons that update-index has --add\nand --remove options to force callers to specifically say \"Yes I\nknow I am talking about unusual things, please\". If we _were_\nto do a single command (be it \"git-update\" or \"git-stage\"), it\nneeds the same --add/--remove safety, which makes \"it's too long\nto type every day -- let's have a single Porcelain-ish\" argument\nsomewhat moot. We can have \"git-add\" and \"git-rm\" instead.\n\nAnd indeed we do. That's where we currently stand.\n\n> First, specifying extra files after 'git commit' bypasses the index.\n\nWhich I happen to think is a misfeature.\n\n> If I remove foo.txt, and want to make a new commit reflecting only\n> that removal, \n\nIf you try latest 'git status' in that situation, it would say\nfoo.txt is deleted but not updated and suggests to use git-add or\ngit-rm to include it in the commit you are creating.\n\n> ... But then I need to remember to use 'git add'\n> to keep track of most changes in the index, new files and edits alike.\n\n\"git commit -a\" is your friend. I think new people should be\ntaught that form first, and then \"git status\" output, and then\nwhat \"git status\" suggests them to do (which is \"git add\" or\n\"git rm\").\n"},{"id":"31576","messageId":"slrneqfnb8.a6s.Peter.B.Baumann@xp.machine.xx","threadId":"6353","inReplyTo":"7virfct737.fsf@assigned-by-dhcp.cox.net","subject":"Re: Importing from tarballs; add, rm, update-index?","fromName":"Peter Baumann","fromEmail":"peter.b.baumann@stud.informatik.uni-erlangen.de","sentAt":"2007-01-12T19:11:36Z","receivedAt":"2007-01-12T19:11:36Z","isPatch":false,"sender":{"key":"waste.manager@gmx.de","avatar":null},"body":"On 2007-01-12, Junio C Hamano wrote:\n> \"Chris Riddoch\" writes:\n>\n>> I suggest calling it something like update-index. ;)\n>\n> Exactly.\n>\n> People new to git need to learn that the next commit is prepared\n> not in the working tree but in a separate entity (staging area),\n> and there are ways to update what it consists of. If that\n> concept is new for people coming from other SCM, renaming\n> \"index\" to \"staging area\" only reduces potential confusion\n> (because \"index\" is too generic word that can mean anything) --\n> it does not remove the need to learn the new concept.\n>\n> And we have called that staging area \"the index\", and the act of\n> updating what it consists of has been called \"updating the\n> index\" for a long time. The primary command to do so has been\n> \"git-update-index\" plumbing, but we added some sugarcoating and\n> now \"git-add\" and \"git-rm\" (also \"git-merge\", \"git-am\" and\n> friends \"updates the index\" for automatable cases) are two most\n> visible ways for the users.\n>\n> The logical name for the operation, if we _were_ to have only\n> one command for \"updating the index\", is \"git-update\" or\n> \"git-update-index\". I do not have anything against \"git stage\"\n> but I simply do not see the point, other than \"git update\" would\n> imply something entirely different to people coming from other\n> SCM so we would want to avoid the word, and \"git update-index\"\n> is too long to type every day.\n\nI already proposed it but I like \"git refresh\". It describes precisely\nwhats happening - the previous content of the file known to git is\nrefreshed. AFAIK \"update\" isn't such a good choice because people from\nother VCS would expect something else(think e.g. of cvs update).\n>\n> In any case, there are valid reasons that update-index has --add\n> and --remove options to force callers to specifically say \"Yes I\n> know I am talking about unusual things, please\". If we _were_\n> to do a single command (be it \"git-update\" or \"git-stage\"), it\n> needs the same --add/--remove safety, which makes \"it's too long\n> to type every day -- let's have a single Porcelain-ish\" argument\n> somewhat moot. We can have \"git-add\" and \"git-rm\" instead.\n>\n> And indeed we do. That's where we currently stand.\n>\n\nMe doesn't really like the new semantics of \"git-add\", because it does\ntwo seperate things - it adds new files and it refreshes the content of\npreviously known files. These two are, at least for me, two seperate\noperations. And reading \"git add\" only suggests to me the first - adding\nnew files.\n\n-Peter\n"},{"id":"31578","messageId":"873b6gxcmv.wl%cworth@cworth.org","threadId":"6353","inReplyTo":"7virfct737.fsf@assigned-by-dhcp.cox.net","subject":"Re: Importing from tarballs; add, rm, update-index?","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2007-01-12T19:34:32Z","receivedAt":"2007-01-12T19:34:32Z","isPatch":false,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Fri, 12 Jan 2007 10:47:56 -0800, Junio C Hamano wrote:\n> People new to git need to learn that the next commit is prepared\n> not in the working tree but in a separate entity (staging area),\n\nWhy's that? Git really provides two separate notions here.\n\n1. Prepare content in staging area, then commit it.\n\n\tWorking with this notion, the commands a user might use are\n\t\"git update-index\", (and more recently \"git add\"), \"git\n\tcommit\", and \"git commit -a\".\n\n2. Prepare content in working tree, and commit from there\n\n\tWorking with this notion, the commands a user might use are\n\t\"git add\" (to add a new file---not the new staging add),\n\t\"git commit files...\", and \"git commit -a\".\n\n> \"git-update-index\". I do not have anything against \"git stage\"\n> but I simply do not see the point, other than \"git update\" would\n> imply something entirely different to people coming from other\n> SCM so we would want to avoid the word, and \"git update-index\"\n> is too long to type every day.\n\nYes, those would be the only reasons for the rename. If those aren't\nimportant then just declare \"update-index\" the porcelain command.\n\n> > First, specifying extra files after 'git commit' bypasses the index.\n>\n> Which I happen to think is a misfeature.\n\nBut this feature _exists_ in git, and it's also _extremely_ useful.\n\nIt also just happens to provide an alternate concept by which someone\ncan understand \"commit -a\", (not that \"commit -a\" shows up under both\nof the conceptual notions I described above).\n\nI still don't understand how people argue so strongly against the\nconceptual notion of \"committing content from working tree\" when git\ndoes provide this functionality, and it also just happens to exactly\nmatch what a lot of people want to do anyway.\n\nThe index is still there, and will still benefit the user during merge\nconflicts, but there's no requirement for the user to think of the\nindex as a staging area to get that benefit. And there's particularly\nno need for the user to be forced to conceptualize every commit as\nfirst being staged before committed.\n\nWhere's the actual benefit to the user in only promoting the \"stage\ncontent, then commit\" model?\n\n-Carl\n"},{"id":"31579","messageId":"7vejq0t4ij.fsf@assigned-by-dhcp.cox.net","threadId":"6353","inReplyTo":"slrneqfnb8.a6s.Peter.B.Baumann@xp.machine.xx","subject":"Re: Importing from tarballs; add, rm, update-index?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-12T19:43:32Z","receivedAt":"2007-01-12T19:43:32Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Peter Baumann \nwrites:\n\n> Me doesn't really like the new semantics of \"git-add\", because it does\n> two seperate things - it adds new files and it refreshes the content of\n> previously known files.\n\nhttp://thread.gmane.org/gmane.comp.version-control.git/32452/focus=32792\n"},{"id":"31584","messageId":"eo8qie$ap7$1@sea.gmane.org","threadId":"6353","inReplyTo":"6efbd9b70701120541n5dc4d0e1va50ae96543d8c80@mail.gmail.com","subject":"Re: Importing from tarballs; add, rm, update-index?","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-01-12T20:20:53Z","receivedAt":"2007-01-12T20:20:53Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"[Cc: git@vger.kernel.org]\n\nChris Riddoch wrote:\n\n> I've got a very, very old codebase I'm trying to wrap my head around.\n> It was apparently once tracked with RCS, but the ,v files are long\n> gone and all that remains are a series of tarballs on an FTP site\n> containing alpha, beta, and final releases of various versions of the\n> project.  There's a logical progression, but between each there are\n> new files, deleted files, and lots of changed files.  gitk will at\n> least help me make sense of the actual changes.  I've got part of a\n> shell script to automate this process.\n\nhttp://git.or.cz/gitwiki/GitFaq#import-tar\n\n(because this kind usage is/should be rare, using plumbing here is not an\nerror, I think).\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"31594","messageId":"20070112210403.GB6262@xp.machine.xx","threadId":"6353","inReplyTo":"7vejq0t4ij.fsf@assigned-by-dhcp.cox.net","subject":"Re: Importing from tarballs; add, rm, update-index?","fromName":"Peter Baumann","fromEmail":"waste.manager@gmx.de","sentAt":"2007-01-12T21:04:03Z","receivedAt":"2007-01-12T21:04:03Z","isPatch":false,"sender":{"key":"waste.manager@gmx.de","avatar":null},"body":"On Fri, Jan 12, 2007 at 11:43:32AM -0800, Junio C Hamano wrote:\n> Peter Baumann \n> writes:\n> \n> > Me doesn't really like the new semantics of \"git-add\", because it does\n> > two seperate things - it adds new files and it refreshes the content of\n> > previously known files.\n> \n> http://thread.gmane.org/gmane.comp.version-control.git/32452/focus=32792\n> \n\n[For the readers conveniance I added the above mail below.]\n\nYes. I fully second Linus opinion. But I think there should be a difference in\nadding completly new content to the index (number of entries in the index grows)\nor replacing content in the index.\n\nThat's what I'm aiming for.\n\n-Peter\n\n?> \n?> If the \"create file; git add; edit file; git commit\" confusion isn't\n?> blisteringly obvious to the git maintainers then I think I have to\n?> give up here.\n?> \n?> And this isn't just CVS-induced brain damage.\n?\n?I'm sorry, but you are wrong.\n?\n? It really _is_ CVS-induced brain damage, and I'm trying to teach you. You \n? can give up, but that's really \"refuse to see the damage that systems like \n? RCS and CVS has done to the world\"\n? \n? The fundamental brain damage that CVS (and RCS, and SVN, and just about \n? anything else) has had is thinking that \"filenames\" (and sometimes this is \n? \"fixed\" to be \"file ID's\") are somehow special, and a totally separate \n? thing from \"file contents\".\n? \n? Really. It's a BUG. It's a deficiency in CVS and friends. And it's a \n? deficiency that you have gotten so used to that you don't even see that \n? it's simply obviously NOT TRUE.\n? \n? You _cannot_ have a filename without the contents of that filename. That \n? whole concept doesn't make sense, except in the twisted AND WRONG mental \n? model of \"files have identities even without content\".\n? \n? The whole point of git is that it is about \"project state\" and the history \n? that binds those states together. People have kind of come to accept that, \n? and a lot of people realize what it means, but I don't think you've really \n? accepted what it means for something as simple as a \"git add\" command.\n? \n? Again, totally ignore the index. Imagine that it doesn't exist. Imagine \n? that you never actually learnt about it, and that none of the \n? documentation ever mentions it, and just ask yourself:\n? \n? \t\"What does 'adding a file' really mean?\"\n? \n? I mean _really_. It cannot be about the \"filename\", because a filename \n? simply doesn't have any meaning alone. Remember what git is all about.\n? \n? No, when you do a \"git add\", YOU DO NOT TALK ABOUT FILENAMES AT ALL.\n? \n? \tNOT EVEN CLOSE!\n? \n? No. Git is, and has always been, all about tracking project content. The \n? fact that CVS is crap, and thinks that \"filenames\" are special (and this \n? causes major problems when you do renames), and the fact that SVN is crap, \n? and things that \"file identities\" are special (and this causes major \n? problems when you split a file or when two files join) is very much about \n? THEIR F*CKING IDIOTIC FUNDAMENTAL BRAINDAMAGE!\n? \n? So take five minutes to really think about that. Take an hour. Take a \n? week. Ponder it.\n? \n? What does it mean to \"add\" something to a project? It has _nothing_ to do \n? with \"filenames\". Yeah, the filename obviously exists, but it's not \n? something that exists on its own. You add the ONLY thing that git tracks. \n? \n? You add CONTENT.\n? \n? When you do \"git add file.c\" you aren't adding a filename to the list of \n? files that git knows about. Not even CLOSE. No. You are really adding \n? _content_ to the project you are tracking. You haven't bound it to a \n? commit yet, but it's there. It's there both conceptually, and very much in \n? a real technical sense too (you've literally added the git object that \n? that file describes to the object database - the \"commit\" and \"tree\" \n? objects to tie it all together is just waiting to be added, but they \n? really just expose it - the actual file object has already been created \n? when you do \"git add\".)\n? \n? So yes, you very much ARE talking about CVS braindamage. The reason why\n? \n? \tgit add file.c\n? \techo New line >> file.c\n? \tgit commit\n? \n? commits the _old_ content, is very much because git is ALL ABOUT THE \n? CONTENT. It has _never_ been about filenames. And it _shouldn't_ be about \n? filenames, because that would be BUGGY AND BROKEN.\n? \n? Sorry for shouting, but as long as you think \"git add\" adds a filename, \n? you're just not getting it. And I think it's really sad that you don't \n? even seem to understand that yes, this _is_ braindamage that has been \n? forced upon you by decades of mental rape done by bad source control \n? systems.\n? \n? Please. File identities are _bad_ in the SVN kind of setting. The CVS kind \n? of \"filename == file identity\" is even _worse_, but it's still exactly the \n? same disease. It's the disease of thinking that metadata is somehow \n? \"different\" from real data, and that \"files\" have identities that are \n? somehow separate from the data they contain.\n? \n? Face it, git is consistent, and if it acted the way you seem to expect it \n? to act, it would actually be a BUG. Exactly because you cannot and MUST \n? NOT think that \"filename\" is something that has meaning without \"file \n? content\" (or \"file type\" and \"file permissions\" - they all go together).\n? \n? And notice? NONE OF THIS HAS ANYTHING AT ALL TO DO WITH 'INDEX'!! The \n? explanation above is not \"this is how the index works\". It's a much more \n? fundamnetal issue of getting the right mental model, where the only thing \n? that matters is contents.\n? \n? So even without an index, \"git add\" should work the way it works, once you \n? can just let go of the broken model that is CVS.\n? \n? Please. Join me, Luke. The power of the git side is stronger. I am your \n? father. \n? \n?\t\t\tLinus\n"},{"id":"31611","messageId":"Pine.LNX.4.63.0701130023330.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6353","inReplyTo":"7virfct737.fsf@assigned-by-dhcp.cox.net","subject":"Re: Importing from tarballs; add, rm, update-index?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-01-12T23:28:29Z","receivedAt":"2007-01-12T23:28:29Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 12 Jan 2007, Junio C Hamano wrote:\n\n> \"Chris Riddoch\" writes:\n>\n> > First, specifying extra files after 'git commit' bypasses the index.\n> \n> Which I happen to think is a misfeature.\n\nYou probably should not teach people about that feature right away, \nbecause it has huge potential of shooting-yourself-in-your-own-foot.\n\nBut darn it, it's _useful_.\n\nVery often I happen to find a subtle bug in the middle of my work. Which \nbasically means that I have a dirty working tree, a dirty index, and I \n_need_ to commit something completely different. Usually it is a \none-liner, which I don't even have to test in isolation, but with my dirty \nworking tree. And usually it is in a file which was non-dirty until I \nput in a fix, so committing specific files -- bypassing the current index \n-- _is_ useful.\n\nCiao,\nDscho\n"},{"id":"31613","messageId":"7vmz4npzg9.fsf@assigned-by-dhcp.cox.net","threadId":"6353","inReplyTo":"Pine.LNX.4.63.0701130023330.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: Importing from tarballs; add, rm, update-index?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-13T00:01:10Z","receivedAt":"2007-01-13T00:01:10Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> You probably should not teach people about that feature right away, \n> because it has huge potential of shooting-yourself-in-your-own-foot.\n>\n> But darn it, it's _useful_.\n\nI am not saying it is not useful. It is just I do not think\npeople should be taught about before understanding what it\nmeans.\n"},{"id":"31615","messageId":"7v7ivrpx9y.fsf@assigned-by-dhcp.cox.net","threadId":"6353","inReplyTo":"20070112210403.GB6262@xp.machine.xx","subject":"Re: Importing from tarballs; add, rm, update-index?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-13T00:48:09Z","receivedAt":"2007-01-13T00:48:09Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Peter Baumann writes:\n\n> Yes. I fully second Linus opinion. But I think there should be\n> a difference in adding completly new content to the index\n> (number of entries in the index grows) or replacing content in\n> the index.\n\nHuh?\n\n> ? So take five minutes to really think about that. Take an hour. Take a \n> ? week. Ponder it.\n\nI'd second this ;-).\n\n> ? What does it mean to \"add\" something to a project? It has _nothing_ to do \n> ? with \"filenames\". Yeah, the filename obviously exists, but it's not \n> ? something that exists on its own. You add the ONLY thing that git tracks. \n> ? \n> ? You add CONTENT.\n> ? \n> ? When you do \"git add file.c\" you aren't adding a filename to the list of \n> ? files that git knows about. Not even CLOSE. No. You are really adding \n> ? _content_ to the project you are tracking.\n\nRead this again, please. Ponder it if you may.\n\n> ? So even without an index, \"git add\" should work the way it works, once you \n> ? can just let go of the broken model that is CVS.\n> ? \n> ? Please. Join me, Luke. The power of the git side is stronger. I am your \n> ? father. \n> ? \n> ?\t\t\tLinus\n\nAnd probably I am your uncle ;-).\n"},{"id":"31622","messageId":"B641F998-7DC1-404E-BDB8-7377F8516AB9@silverinsanity.com","threadId":"6353","inReplyTo":"7vejq0t4ij.fsf@assigned-by-dhcp.cox.net","subject":"Re: Importing from tarballs; add, rm, update-index?","fromName":"Brian Gernhardt","fromEmail":"benji@silverinsanity.com","sentAt":"2007-01-13T06:36:48Z","receivedAt":"2007-01-13T06:36:48Z","isPatch":false,"sender":{"key":"benji@silverinsanity.com","avatar":"https://gravatar.com/avatar/e06c101dbc25c68114d859b4a9ec7cf8a2c52fd2b0270ef0eac0e2e63ff22311?d=mp&s=160"},"body":"\nOn Jan 12, 2007, at 2:43 PM, Junio C Hamano wrote:\n\n> Peter Baumann \n> writes:\n>\n>> Me doesn't really like the new semantics of \"git-add\", because it \n>> does\n>> two seperate things - it adds new files and it refreshes the \n>> content of\n>> previously known files.\n>\n> http://thread.gmane.org/gmane.comp.version-control.git/32452/ \n> focus=32792\n\nShould this be added to Documentation/rants/filename- \nbraindamage.txt? ;-)\n\n~~ Brian\n"},{"id":"31624","messageId":"20070113093322.GA4825@xp.machine.xx","threadId":"6353","inReplyTo":"7v7ivrpx9y.fsf@assigned-by-dhcp.cox.net","subject":"Re: Importing from tarballs; add, rm, update-index?","fromName":"Peter Baumann","fromEmail":"waste.manager@gmx.de","sentAt":"2007-01-13T09:33:22Z","receivedAt":"2007-01-13T09:33:22Z","isPatch":false,"sender":{"key":"waste.manager@gmx.de","avatar":null},"body":"On Fri, Jan 12, 2007 at 04:48:09PM -0800, Junio C Hamano wrote:\n> Peter Baumann writes:\n> \n> > Yes. I fully second Linus opinion. But I think there should be\n> > a difference in adding completly new content to the index\n> > (number of entries in the index grows) or replacing content in\n> > the index.\n> \n> Huh?\n> \n> > ? So take five minutes to really think about that. Take an hour. Take a \n> > ? week. Ponder it.\n> \n> I'd second this ;-).\n> \n> > ? What does it mean to \"add\" something to a project? It has _nothing_ to do \n> > ? with \"filenames\". Yeah, the filename obviously exists, but it's not \n> > ? something that exists on its own. You add the ONLY thing that git tracks. \n> > ? \n> > ? You add CONTENT.\n> > ? \n> > ? When you do \"git add file.c\" you aren't adding a filename to the list of \n> > ? files that git knows about. Not even CLOSE. No. You are really adding \n> > ? _content_ to the project you are tracking.\n> \n> Read this again, please. Ponder it if you may.\n> \n\nYes. I am adding content. And not a file. But at least to me, it makes a\n*BIG* difference if I'm adding totally new content (reserving one more\nbucket where to place to content) or just replacing the content *in* one\nof those already reserved buckets. And that has nothing to do with\nfiles (or at least the silly me can't grok it).\n\n> > ? So even without an index, \"git add\" should work the way it works, once you \n> > ? can just let go of the broken model that is CVS.\n> > ? \n> > ? Please. Join me, Luke. The power of the git side is stronger. I am your \n> > ? father. \n> > ? \n> > ?\t\t\tLinus\n> \n> And probably I am your uncle ;-).\n> \n\nYou are welcome :-)\n\n-Peter\n"},{"id":"31625","messageId":"slrneqha0g.5sa.Peter.B.Baumann@xp.machine.xx","threadId":"6353","inReplyTo":"B641F998-7DC1-404E-BDB8-7377F8516AB9@silverinsanity.com","subject":"Re: Importing from tarballs; add, rm, update-index?","fromName":"Peter Baumann","fromEmail":"peter.b.baumann@stud.informatik.uni-erlangen.de","sentAt":"2007-01-13T09:36:16Z","receivedAt":"2007-01-13T09:36:16Z","isPatch":false,"sender":{"key":"waste.manager@gmx.de","avatar":null},"body":"On 2007-01-13, Brian Gernhardt wrote:\n>\n> On Jan 12, 2007, at 2:43 PM, Junio C Hamano wrote:\n>\n>> Peter Baumann \n>> writes:\n>>\n>>> Me doesn't really like the new semantics of \"git-add\", because it \n>>> does\n>>> two seperate things - it adds new files and it refreshes the \n>>> content of\n>>> previously known files.\n>>\n>> http://thread.gmane.org/gmane.comp.version-control.git/32452/ \n>> focus=32792\n>\n> Should this be added to Documentation/rants/filename- \n> braindamage.txt? ;-)\n>\n> ~~ Brian\n\nOk. Obviously I should't have said that it add \"files\" (gr, silly me).\nWhat I meant was it adds the content of files. But there is a difference\nin adding and replacing content.\n\n-Peter\n"},{"id":"31631","messageId":"Pine.LNX.4.63.0701131204511.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6353","inReplyTo":"20070113093322.GA4825@xp.machine.xx","subject":"Re: Importing from tarballs; add, rm, update-index?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-01-13T11:17:18Z","receivedAt":"2007-01-13T11:17:18Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sat, 13 Jan 2007, Peter Baumann wrote:\n\n> On Fri, Jan 12, 2007 at 04:48:09PM -0800, Junio C Hamano wrote:\n> > Peter Baumann writes:\n> > \n> > > ? What does it mean to \"add\" something to a project? It has \n> > > _nothing_ to do ? with \"filenames\". Yeah, the filename obviously \n> > > exists, but it's not ? something that exists on its own. You add the \n> > > ONLY thing that git tracks. ? ? You add CONTENT. ? ? When you do \n> > > \"git add file.c\" you aren't adding a filename to the list of ? files \n> > > that git knows about. Not even CLOSE. No. You are really adding ? \n> > > _content_ to the project you are tracking.\n> > \n> > Read this again, please. Ponder it if you may.\n> > \n> \n> Yes. I am adding content. And not a file. But at least to me, it makes a\n> *BIG* difference if I'm adding totally new content (reserving one more\n> bucket where to place to content) or just replacing the content *in* one\n> of those already reserved buckets.\n\nBzzzzt! Nope. \"Reserved buckets\" as you use it is nothing else than a \nfile.\n\n> And that has nothing to do with files (or at least the silly me can't \n> grok it).\n\nContent: a byte stream with a label (so you can find it again). Of \n_course_ you don't want the byte stream vanish in a big black hole, so you \n_have_ to name it.\n\nBut git-add actually does two things: it adds a (completely new) object, \nwhich just holds the byte stream, being named by its content (the hash). \n\nBut when committing, the _existing_ tree object is \"updated\", by writing a \n_new_ tree object. So, it is not an \"updating\" in the sense of \"editing\", \nrather \"updating\" as in copy-on-write.\n\nSo no, there are no \"reserved buckets\". You are very much _adding_ \nnew information.\n\nAnother way to look at it: in git, you never \"take away\" anything. You \nonly add things. Even if you remove a file from your working tree, and \nwant to commit the change, it means that you _add_ information: The \ninformation that this file is no longer in the current revision. But the \ncommit references the old revision (indeed, the _whole_ ancestry!), in \nwhich the file _was_ present, so you literally _added_ something _on top_ \nof the old revision.\n\nHth,\nDscho\n"},{"id":"31636","messageId":"87y7o6x60w.wl%cworth@cworth.org","threadId":"6353","inReplyTo":"7v7ivrpx9y.fsf@assigned-by-dhcp.cox.net","subject":"Re: Importing from tarballs; add, rm, update-index?","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2007-01-13T16:09:35Z","receivedAt":"2007-01-13T16:09:35Z","isPatch":false,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Fri, 12 Jan 2007 16:48:09 -0800, Junio C Hamano wrote:\n> Peter Baumann writes:\n>\n> > Yes. I fully second Linus opinion. But I think there should be\n> > a difference in adding completly new content to the index\n> > (number of entries in the index grows) or replacing content in\n> > the index.\n>\n> Huh?\n\nHere's an easy way to see the difference that Peter is trying to point\nout, (and it really has nothing to do with whether \"git add\" for a new\nfile should add the content of that file to the index---that's a\ntotally separate issue that Linus was talking about in that other\nmessage).\n\nJust look at \"commit -a\" and how its documented right now. Currently\nit's documented as doing an automatic \"add\" to all known files. That\ndescriptions is unsatisfactory for two reasons:\n\n1. \"commit -a\" will also commit the removal of files---which requires\n an index modification that \"git add\" cannot do\n\n2. \"add\" can cause an entirely new path (with content, Vader!) to be\n added to the index. So the user has to carefully separate out this\n behavior of \"add\" to properly understand what \"commit -a\" is\n doing. The documentation tries to help here with \"known files\", but\n the talk of an \"automatic 'add'\" that never adds any new paths\n really goes against the primary functionality of \"git add\".\n\n I say \"primary functionality\" because the 'commit -a' workflow,\n (which we've all agreed should be the thing that is taught first),\n requires users to use 'git add' when adding a new path to the\n index, but never requires the user to use the 'update the index'\n sense of 'git add', (instead, the user just needs to _learn_ this\n sense to understand commit -a).\n\nSo there's lots of room for potential confusion there, and we've got\nevidence of that confusion in the messages that started this an other\nrecent threads about how to remove files.\n\nI like the idea of adding a porcelain command for update-index, and\nit's nice to try to describe \"commit -a\" in terms of the new porcelain\ncommand. But, to make that really work, I think that porcelain for\nupdate-index should really match the semantics needed by \"commit\n-a\". That is, it should never add new paths to the index, but it\nshould update content for existing paths, and it should remove paths\nfrom the index when files have been removed from the working tree.\n\nLet's call this new command \"refresh\", just to experiment with another\nname. If it existed, then \"commit -a\" could be described as simply\ndoing \"refresh\" on all files, (with no need to have a notion of\n\"tracked files\", nor any extra language about file removal). That is,\n\"commit -a\" could be understood as something like:\n\n\tgit refresh -a\n\tgit commit\n\n(or maybe \"git refresh .; git commit\" if one prefers that, but I think\nit'd be nice to carry the -a option over to the new porcelain).\n\nAlso, this would even make it possible to provide an accurate\nindex-based description of \"commit paths...\". Namely, something like:\n\n\tcommit paths...\n\n\tThis command starts with a new index initialized from the\n\tcontents of the current commit (HEAD). It then performs the\n\tfollowing commands:\n\n\t\tgit refresh paths...\n\t\tgit commit\n\n\t[Some extra language needed here about restoring into the\n\tindex other changes that were \"skipped over\".]\n\nSo, someone might like to have that kind of description somewhere in\nthe technical documentation of git. (I'd still prefer to see \"commit\npaths...\" documented as simply \"commits the working-tree content of\nall specified paths\").\n\nAnyway, did I succeed in pointing out why some of us think that the\n\"add a new path (with content) to the index\" and the \"update content\nfor existing path\" really shouldn't be mixed up in the same \"add\"\ncommand?\n\n-Carl\n"},{"id":"31637","messageId":"20070113161936.GB4825@xp.machine.xx","threadId":"6353","inReplyTo":"Pine.LNX.4.63.0701131204511.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: Importing from tarballs; add, rm, update-index?","fromName":"Peter Baumann","fromEmail":"siprbaum@stud.informatik.uni-erlangen.de","sentAt":"2007-01-13T16:19:36Z","receivedAt":"2007-01-13T16:19:36Z","isPatch":false,"sender":{"key":"waste.manager@gmx.de","avatar":null},"body":"On Sat, Jan 13, 2007 at 12:17:18PM +0100, Johannes Schindelin wrote:\n> Hi,\n> \n> On Sat, 13 Jan 2007, Peter Baumann wrote:\n> \n> > On Fri, Jan 12, 2007 at 04:48:09PM -0800, Junio C Hamano wrote:\n> > > Peter Baumann writes:\n> > > \n> > > > ? What does it mean to \"add\" something to a project? It has \n> > > > _nothing_ to do ? with \"filenames\". Yeah, the filename obviously \n> > > > exists, but it's not ? something that exists on its own. You add the \n> > > > ONLY thing that git tracks. ? ? You add CONTENT. ? ? When you do \n> > > > \"git add file.c\" you aren't adding a filename to the list of ? files \n> > > > that git knows about. Not even CLOSE. No. You are really adding ? \n> > > > _content_ to the project you are tracking.\n> > > \n> > > Read this again, please. Ponder it if you may.\n> > > \n> > \n> > Yes. I am adding content. And not a file. But at least to me, it makes a\n> > *BIG* difference if I'm adding totally new content (reserving one more\n> > bucket where to place to content) or just replacing the content *in* one\n> > of those already reserved buckets.\n> \n> Bzzzzt! Nope. \"Reserved buckets\" as you use it is nothing else than a \n> file.\n> \n> > And that has nothing to do with files (or at least the silly me can't \n> > grok it).\n> \n> Content: a byte stream with a label (so you can find it again). Of \n> _course_ you don't want the byte stream vanish in a big black hole, so you \n> _have_ to name it.\n> \n> But git-add actually does two things: it adds a (completely new) object, \n> which just holds the byte stream, being named by its content (the hash). \n> \nOK. Now we are talking clear. I don't like git-add to do two things (see\nbelow)\n\n> But when committing, the _existing_ tree object is \"updated\", by writing a \n> _new_ tree object. So, it is not an \"updating\" in the sense of \"editing\", \n> rather \"updating\" as in copy-on-write.\n> \n> So no, there are no \"reserved buckets\". You are very much _adding_ \n> new information.\n> \n\nI unterstand the concept of the index, I even glanced at the code. The\nindex holds for every file... err.. content a struct cache_entry (my\nabove mentioned \"buckets\"). If I add a new cache_entry, I enlarge my\nlater committed tree by at least one new file (adding a new file could\nalso add an entry for a directory in the final tree object).\n\nI would much more like the idea of having one command (git-add) which\nwould enlarge the index by a new struct cache_entry and another which\nreplaces a previously added cache_entry. Because I'd like to control\nhow my final tree looks like and add least to me adding a file entry to\na tree is something different than updating a file entry (at least\nmentally).\n\nI'd favour the following model:\n\n git-add: register the content of a previously unkown file to git\n (there was now struct chache_entry in the index previously which\n described a file with the same name)\n\n git-rm: remove a struct cache_entry from the index and after some\n safty checks remove the file, too. (see in the mailinglist archive;\n there was much talk about git-rm and its semantic)\n\n git-refresh (or git-stage or git-update or what-ever you call it):\n replace the cache_entry by a new one\n\nAnd this all about content; the content which would represent my next\ntree object. Because developers don't think of \"add\" if they want to\nremove a file from the commit. If the power users liked to have only one\ncommand, wich does remove, add and update then lets not call it add.\nBetter make this commmand the above mentioned git-refresh which would do\n\"the right thing\" if called with a new file/removed file\n\nIm simply think its confusing to call the described command git-add, as\nwe have it now. It's at least *very* confusing for new starters.\n\n-Peter\n\n> Another way to look at it: in git, you never \"take away\" anything. You \n> only add things. Even if you remove a file from your working tree, and \n> want to commit the change, it means that you _add_ information: The \n> information that this file is no longer in the current revision. But the \n> commit references the old revision (indeed, the _whole_ ancestry!), in \n> which the file _was_ present, so you literally _added_ something _on top_ \n> of the old revision.\n> \n> Hth,\n> Dscho\n> \n"},{"id":"31638","messageId":"Pine.LNX.4.64.0701131620100.19099@beast.quantumfyre.co.uk","threadId":"6353","inReplyTo":"20070113161936.GB4825@xp.machine.xx","subject":"Re: Importing from tarballs; add, rm, update-index?","fromName":"Julian Phillips","fromEmail":"julian@quantumfyre.co.uk","sentAt":"2007-01-13T16:27:00Z","receivedAt":"2007-01-13T16:27:00Z","isPatch":false,"sender":{"key":"julian@quantumfyre.co.uk","avatar":"https://avatars.githubusercontent.com/u/948888?v=4"},"body":"On Sat, 13 Jan 2007, Peter Baumann wrote:\n\n> I'd favour the following model:\n>\n> git-add: register the content of a previously unkown file to git\n> (there was now struct chache_entry in the index previously which\n> described a file with the same name)\n>\n> git-rm: remove a struct cache_entry from the index and after some\n> safty checks remove the file, too. (see in the mailinglist archive;\n> there was much talk about git-rm and its semantic)\n>\n> git-refresh (or git-stage or git-update or what-ever you call it):\n> replace the cache_entry by a new one\n>\n> And this all about content; the content which would represent my next\n> tree object. Because developers don't think of \"add\" if they want to\n> remove a file from the commit. If the power users liked to have only one\n> command, wich does remove, add and update then lets not call it add.\n> Better make this commmand the above mentioned git-refresh which would do\n> \"the right thing\" if called with a new file/removed file\n>\n> Im simply think its confusing to call the described command git-add, as\n> we have it now. It's at least *very* confusing for new starters.\n\nPersonally I actually find having a single add command to be the simplest \nconceptual model ...\n\nI think of it like this:\n\n* start off with current content (index matches HEAD matches working tree)\n* I do some stuff (add files, edit files, delete files)\n* I add my changes to the index\n* I do more stuff\n* I add my changes to the index\n* I do more stuff\n* I realise that the latest changes are actually different, so I commit \nthe index, and then keep going, or I add the changes and commit.\n\nThe only thing I find slightly confusing is that the staging area for the \nnext commit is called the index.\n\n(But then maybe I've been reading this list too long - though I have only \nactually starting playing with git recently)\n\n-- \nJulian\n\n ---\nPower, like a desolating pestilence,\nPollutes whate'er it touches...\n \t\t-- Percy Bysshe Shelley\n"},{"id":"31639","messageId":"E5A7E6A8-45FF-4A7A-A31E-DFEBAD48DF1C@silverinsanity.com","threadId":"6353","inReplyTo":"slrneqha0g.5sa.Peter.B.Baumann@xp.machine.xx","subject":"Re: Importing from tarballs; add, rm, update-index?","fromName":"Brian Gernhardt","fromEmail":"benji@silverinsanity.com","sentAt":"2007-01-13T16:31:37Z","receivedAt":"2007-01-13T16:31:37Z","isPatch":false,"sender":{"key":"benji@silverinsanity.com","avatar":"https://gravatar.com/avatar/e06c101dbc25c68114d859b4a9ec7cf8a2c52fd2b0270ef0eac0e2e63ff22311?d=mp&s=160"},"body":"\nOn Jan 13, 2007, at 4:36 AM, Peter Baumann wrote:\n\n> On 2007-01-13, Brian Gernhardt wrote:\n>>\n>> On Jan 12, 2007, at 2:43 PM, Junio C Hamano wrote:\n>>\n>>> Peter Baumann \n>>> writes:\n>>>\n>>>> Me doesn't really like the new semantics of \"git-add\", because it\n>>>> does\n>>>> two seperate things - it adds new files and it refreshes the\n>>>> content of\n>>>> previously known files.\n>>>\n>>> http://thread.gmane.org/gmane.comp.version-control.git/32452/\n>>> focus=32792\n>>\n>> Should this be added to Documentation/rants/filename-\n>> braindamage.txt? ;-)\n>>\n>> ~~ Brian\n>\n> Ok. Obviously I should't have said that it add \"files\" (gr, silly me).\n> What I meant was it adds the content of files. But there is a \n> difference\n> in adding and replacing content.\n\nI was referring to adding Linus' rant... And maybe several others. \nI tend to find his rants at least slightly amusing, highly \ninformative, and I tend to end up agreeing. I have very little \nopinion on your complaint so long as the system works consistently. \n\"git commit -a\" is still my most common workflow. I've used git-add \n(and prior to that git-update-index) from time to time when I fix \nbugs that need to be separate from my current work, but far far more \ncommon is \"I finished this chunk of functionality, add all the \nchanges I did to make it happen\".\n\n~~ Brian\n"},{"id":"31641","messageId":"6C7B9A8F-122D-446A-AF25-409C9DCAA592@silverinsanity.com","threadId":"6353","inReplyTo":"87y7o6x60w.wl%cworth@cworth.org","subject":"Re: Importing from tarballs; add, rm, update-index?","fromName":"Brian Gernhardt","fromEmail":"benji@silverinsanity.com","sentAt":"2007-01-13T16:45:29Z","receivedAt":"2007-01-13T16:45:29Z","isPatch":false,"sender":{"key":"benji@silverinsanity.com","avatar":"https://gravatar.com/avatar/e06c101dbc25c68114d859b4a9ec7cf8a2c52fd2b0270ef0eac0e2e63ff22311?d=mp&s=160"},"body":"\nOn Jan 13, 2007, at 11:09 AM, Carl Worth wrote:\n\n> Also, this would even make it possible to provide an accurate\n> index-based description of \"commit paths...\". Namely, something like:\n>\n> \tcommit paths...\n>\n> \tThis command starts with a new index initialized from the\n> \tcontents of the current commit (HEAD). It then performs the\n> \tfollowing commands:\n>\n> \t\tgit refresh paths...\n> \t\tgit commit\n>\n> \t[Some extra language needed here about restoring into the\n> \tindex other changes that were \"skipped over\".]\n>\n> So, someone might like to have that kind of description somewhere in\n> the technical documentation of git. (I'd still prefer to see \"commit\n> paths...\" documented as simply \"commits the working-tree content of\n> all specified paths\").\n\nI fail to see why this description can't be used with s/refresh/ \nadd/. I also don't think it's a very clear description because of \nthe \"starting with a new index\" and the hand-waving involved in \n\"restoring into the index other changes\".\n\nI can somewhat understand the desire to split git-add (although I \ndon't share it). But I don't see the need for it to be a new git- \nrefresh, since that functionality already exists as git-update- \nindex. Is using git-add to add to the index a conceptual problem or \nis it causing actual problems in people's usage of git? If it's an \nissue of teaching new users, I _think_ that could be resolved very \nsimply as \"git add adds content to the index\" when we explain the \nindex as the staging area for a new commit and wean people off of \n\"git commit -a\". A short discussion of \"tracking content vs. files\" \nis probably also a good idea. (I honestly haven't read the tutorials \nin a long long time, so this may already be in there.)\n\n~~ Brian\n"},{"id":"31642","messageId":"20070113164811.GC4825@xp.machine.xx","threadId":"6353","inReplyTo":"87y7o6x60w.wl%cworth@cworth.org","subject":"Re: Importing from tarballs; add, rm, update-index?","fromName":"Peter Baumann","fromEmail":"siprbaum@stud.informatik.uni-erlangen.de","sentAt":"2007-01-13T16:48:11Z","receivedAt":"2007-01-13T16:48:11Z","isPatch":false,"sender":{"key":"waste.manager@gmx.de","avatar":null},"body":"On Sat, Jan 13, 2007 at 08:09:35AM -0800, Carl Worth wrote:\n> On Fri, 12 Jan 2007 16:48:09 -0800, Junio C Hamano wrote:\n> > Peter Baumann writes:\n> >\n> > > Yes. I fully second Linus opinion. But I think there should be\n> > > a difference in adding completly new content to the index\n> > > (number of entries in the index grows) or replacing content in\n> > > the index.\n> >\n> > Huh?\n> \n> Here's an easy way to see the difference that Peter is trying to point\n> out, (and it really has nothing to do with whether \"git add\" for a new\n> file should add the content of that file to the index---that's a\n> totally separate issue that Linus was talking about in that other\n> message).\n> \n> Just look at \"commit -a\" and how its documented right now. Currently\n> it's documented as doing an automatic \"add\" to all known files. That\n> descriptions is unsatisfactory for two reasons:\n> \n> 1. \"commit -a\" will also commit the removal of files---which requires\n> an index modification that \"git add\" cannot do\n> \n> 2. \"add\" can cause an entirely new path (with content, Vader!) to be\n> added to the index. So the user has to carefully separate out this\n> behavior of \"add\" to properly understand what \"commit -a\" is\n> doing. The documentation tries to help here with \"known files\", but\n> the talk of an \"automatic 'add'\" that never adds any new paths\n> really goes against the primary functionality of \"git add\".\n> \n> I say \"primary functionality\" because the 'commit -a' workflow,\n> (which we've all agreed should be the thing that is taught first),\n> requires users to use 'git add' when adding a new path to the\n> index, but never requires the user to use the 'update the index'\n> sense of 'git add', (instead, the user just needs to _learn_ this\n> sense to understand commit -a).\n> \n> So there's lots of room for potential confusion there, and we've got\n> evidence of that confusion in the messages that started this an other\n> recent threads about how to remove files.\n> \n> I like the idea of adding a porcelain command for update-index, and\n> it's nice to try to describe \"commit -a\" in terms of the new porcelain\n> command. But, to make that really work, I think that porcelain for\n> update-index should really match the semantics needed by \"commit\n> -a\". That is, it should never add new paths to the index, but it\n> should update content for existing paths, and it should remove paths\n> >from the index when files have been removed from the working tree.\n> \n> Let's call this new command \"refresh\", just to experiment with another\n> name. If it existed, then \"commit -a\" could be described as simply\n> doing \"refresh\" on all files, (with no need to have a notion of\n> \"tracked files\", nor any extra language about file removal). That is,\n> \"commit -a\" could be understood as something like:\n> \n> \tgit refresh -a\n> \tgit commit\n> \n> (or maybe \"git refresh .; git commit\" if one prefers that, but I think\n> it'd be nice to carry the -a option over to the new porcelain).\n> \n> Also, this would even make it possible to provide an accurate\n> index-based description of \"commit paths...\". Namely, something like:\n> \n> \tcommit paths...\n> \n> \tThis command starts with a new index initialized from the\n> \tcontents of the current commit (HEAD). It then performs the\n> \tfollowing commands:\n> \n> \t\tgit refresh paths...\n> \t\tgit commit\n> \n> \t[Some extra language needed here about restoring into the\n> \tindex other changes that were \"skipped over\".]\n> \n> So, someone might like to have that kind of description somewhere in\n> the technical documentation of git. (I'd still prefer to see \"commit\n> paths...\" documented as simply \"commits the working-tree content of\n> all specified paths\").\n> \n> Anyway, did I succeed in pointing out why some of us think that the\n> \"add a new path (with content) to the index\" and the \"update content\n> for existing path\" really shouldn't be mixed up in the same \"add\"\n> command?\n> \n\nYes. At least for me :-)\n\n-Peter\n\n> -Carl\n"},{"id":"31645","messageId":"7v1wlylsa8.fsf@assigned-by-dhcp.cox.net","threadId":"6353","inReplyTo":"20070113093322.GA4825@xp.machine.xx","subject":"Re: Importing from tarballs; add, rm, update-index?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-13T18:01:51Z","receivedAt":"2007-01-13T18:01:51Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Peter Baumann writes:\n\n> Yes. I am adding content. And not a file. But at least to me, it makes a\n> *BIG* difference if I'm adding totally new content (reserving one more\n> bucket where to place to content) or just replacing the content *in* one\n> of those already reserved buckets. And that has nothing to do with\n> files (or at least the silly me can't grok it).\n\nTo put this silly naming argument to the rest for now, because I\nam not going to change add/rm nor introduce refresh, at least\nduring this round, so keeping this thread alive would just waste\neverybody's time doing mental masturbation.\n\nPhysically the index is represented as a list of tuples. When we say \"git tracks contents\",\nhowever, we look at it as if content of each blob object is just\na bytestream labeled with the pathname.\n\nWhen you say \"git-update-index file\" (without --add/--remove),\nwhat happens is \"UPDATE\" (in SQL sense). The part of the data\nrecorded in the current index that is labeled with \"file\" is\nreplaced with what is from the working tree.\n\nThe --add option changes the \"UPDATE\" to \"INSERT OR REPLACE\".\nIt allows contents that are labelled with a pathname that does\nnot yet exist in the index. What --remove does is to allow it\nto also \"DELETE\".\n\nSo there _is_ a distinction between adding new pathname and\nupdating the contents at the low level.\n\nHowever, if you look at the way 'git-update-index' is used in\nthe Porcelain-ish scripts (now you would need to go back and\nexamine a bit older versions of git, since many commands have\nbeen rewritten in C to become built-in and we use update-index\nin much fewer places in today's version), we almost always used\nupdate-index with --add when talking about the set of paths the\nend user talks about ('am' and 'applypatch' uses --index-info;\nthis is also \"INSERT OR REPLACE\" operation primarily). The\nplaces we did not, we knew we were only dealing with known set\nof paths taken from the current index, so they also could have\nhad --add without any ill effects. \n\nIn other words, there was not much need for \"UPDATE only, please\ndo not INSERT\" in practice.\n\nThat's primarily why the higher level interface git-add / git-mv\ndoes not expose that distinction; git-add will do \"INSERT OR\nREPLACE\". git-rm will do \"DELETE\", and there will be no higher\nlevel to only do \"UPDATE\".\n"},{"id":"31646","messageId":"200701131815.27481.alan@chandlerfamily.org.uk","threadId":"6353","inReplyTo":"E5A7E6A8-45FF-4A7A-A31E-DFEBAD48DF1C@silverinsanity.com","subject":"Re: Importing from tarballs; add, rm, update-index?","fromName":"Alan Chandler","fromEmail":"alan@chandlerfamily.org.uk","sentAt":"2007-01-13T18:15:27Z","receivedAt":"2007-01-13T18:15:27Z","isPatch":false,"sender":{"key":"alan@chandlerfamily.org.uk","avatar":"https://gravatar.com/avatar/1862247e5ea8eac114c842f9dc3a5db6253754e24ef7171757cf97eedce48b8c?d=mp&s=160"},"body":"> I was referring to adding Linus' rant... And maybe several others.\n> I tend to find his rants at least slightly amusing, highly\n> informative, and I tend to end up agreeing. I have very little\n> opinion on your complaint so long as the system works consistently.\n> \"git commit -a\" is still my most common workflow. I've used git-add\n> (and prior to that git-update-index) from time to time when I fix\n> bugs that need to be separate from my current work, but far far more\n> common is \"I finished this chunk of functionality, add all the\n> changes I did to make it happen\".\n\nI think the fact that this thread has come alive again implies we didn't \nbottom it last time through.\n\nOne thing, in particular, has been bugging me with the hide the index \nconcept - that is, its still necessary to git add files for them to be \npicked up with git commit -a\n\nMy (albeit limited) experience with using git is at home coding a java \napplication for my web site using eclipse. During the application \ndevelopment when I am initially coding the application, or when I am \ndoing a major update that adds new pages to my site then I have to \nremember to git add files. My immediate instinct is do do commands of \nthe form\n\ngit add \nJavasource/uk/org/chandlerfamily/appname/tapestry/pages/subdir/xxx.java\n\nand\ngit add Webcontent/subdir/xxx.html\n\nwhich even with bash completion is a pain to enter.\n\n(although that is probably harder than it needs to be - can't I just do \ngit add . ?)\n\nI don't know whether we have had the debate here - if we have done it \nwould have been in the very very early days, but subject to \nthe .gitignore rules what would be the implications of a git commit -a \nthat automatically adds any files within the directory (and \nsubdirectories) in which it is issued.\n\nThen I think you don't even have to get into what is git add all about \nuntil you get to the \"use the index\" stage.\n\nI am (at the moment - but I am good at changing my mind) in the side of \ngiit add for both adding new paths and updating content. This is \npurely pragmatic - don't have to remember which one I am trying to do.\n\n-- \nAlan Chandler\nhttp://www.chandlerfamily.org.uk\n"},{"id":"31647","messageId":"Pine.LNX.4.64.0701131340040.2577@xanadu.home","threadId":"6353","inReplyTo":"87y7o6x60w.wl%cworth@cworth.org","subject":"Re: Importing from tarballs; add, rm, update-index?","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-01-13T18:54:20Z","receivedAt":"2007-01-13T18:54:20Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Sat, 13 Jan 2007, Carl Worth wrote:\n\n> Anyway, did I succeed in pointing out why some of us think that the\n> \"add a new path (with content) to the index\" and the \"update content\n> for existing path\" really shouldn't be mixed up in the same \"add\"\n> command?\n\nNot really.\n\nThe fact is that there is no strong reason why they shouldn't. But \nthere are good reasons why they should. The most important one being \nthat the user doesn't need to bother deciding which one of the two \ncommands should be used in any given situation. And because a single \ncommand can cover two _technically_ different cases transparently is a \npretty good reason for not imposing this technical issue to the user.\n\nBut remember that git-update-index is still and will always be available \nto you for fancier and more fine grained control if/when you have a \nspecial need for it. This is not the case for the vast majority of \nusers though and the primary user interface should reflect that.\n\n\nNicolas\n"},{"id":"31648","messageId":"8E585186-FC3F-473B-BA1F-91CFEF1A63F4@silverinsanity.com","threadId":"6353","inReplyTo":"200701131815.27481.alan@chandlerfamily.org.uk","subject":"Re: Importing from tarballs; add, rm, update-index?","fromName":"Brian Gernhardt","fromEmail":"benji@silverinsanity.com","sentAt":"2007-01-13T19:31:08Z","receivedAt":"2007-01-13T19:31:08Z","isPatch":false,"sender":{"key":"benji@silverinsanity.com","avatar":"https://gravatar.com/avatar/e06c101dbc25c68114d859b4a9ec7cf8a2c52fd2b0270ef0eac0e2e63ff22311?d=mp&s=160"},"body":"\nOn Jan 13, 2007, at 1:15 PM, Alan Chandler wrote:\n\n> (although that is probably harder than it needs to be - can't I \n> just do\n> git add . ?)\n\nYes. It sounds very much like you want to simply do \"git add . ; git \ncommit -a\". But making that the default for \"commit -a\" would be \nobnoxious for many other people.\n\nI know that fairly often I begin adding a chunk of new code and \nrealize the changes I made to the existing code should logically be a \ndifferent commit. Having \"git commit -a\" ignore the new files (and \nany new object/log/debug/etc files I haven't added to .gitignore) \nmakes things so much simpler.\n\nA more through version (\"git commit --everything\"?) that also adds \nfiles would be fine, but don't muck up the existing -a, please.\n\n~~ Brian\n"},{"id":"31649","messageId":"87wt3qwwm0.wl%cworth@cworth.org","threadId":"6353","inReplyTo":"Pine.LNX.4.64.0701131340040.2577@xanadu.home","subject":"Re: Importing from tarballs; add, rm, update-index?","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2007-01-13T19:32:55Z","receivedAt":"2007-01-13T19:32:55Z","isPatch":false,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Sat, 13 Jan 2007 13:54:20 -0500 (EST), Nicolas Pitre wrote:\n> The fact is that there is no strong reason why they shouldn't. But\n> there are good reasons why they should. The most important one being\n> that the user doesn't need to bother deciding which one of the two\n> commands should be used in any given situation. And because a single\n> command can cover two _technically_ different cases transparently is a\n> pretty good reason for not imposing this technical issue to the user.\n\nBut that same reasoning could be extended to say there shouldn't be\nseparate \"add\" and \"rm\", because a single command can transparently\ncover these two technically different cases transparently, (that would\nbe update-index without --add and --remove safety checks). But nobody\nhas been proposing that that would be a good direction to go.\n\nSo there are at least three cases one could identify for updating\ncontent into the index:\n\n1. Adding content for a path that didn't previously exist in the index\n\n2. Updating content for a path that does already exist in the index\n\n3. Removing a path and its content from the index\n\nAs things stand currently, git's providing a first-class operation\n(\"git add\") that provides (1) and (2) and another operation (\"git rm\")\nfor (3).\n\nHowever, \"commit -a\" is implicitly performing operations from (2) and\n(3).\n\nSo the documentation of \"commit -a\" being implemented with \"add\" just\nplain doesn't make sense---and this is causing confusion.\n\nI'd love to see _something_ get accepted to resolve that\nconfusion. What I was proposing was a command that did (1) and another\nthat did (2) or (3), (and \"commit -a\" could then be documented as\nusing this command).\n\nBut there are probably other ways to fix the problem.\n\n-Carl\n"},{"id":"31650","messageId":"7vwt3qk722.fsf@assigned-by-dhcp.cox.net","threadId":"6353","inReplyTo":"87wt3qwwm0.wl%cworth@cworth.org","subject":"Re: Importing from tarballs; add, rm, update-index?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-13T20:25:41Z","receivedAt":"2007-01-13T20:25:41Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Carl Worth writes:\n\n> So the documentation of \"commit -a\" being implemented with \"add\" just\n> plain doesn't make sense---and this is causing confusion.\n\ndiff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt\nindex cb081cd..b4528d7 100644\n--- a/Documentation/git-commit.txt\n+++ b/Documentation/git-commit.txt\n@@ -32,7 +32,8 @@ methods:\n \n 4. by using the -a switch with the 'commit' command to automatically \"add\"\n changes from all known files i.e. files that have already been committed\n- before, and perform the actual commit.\n+ before, and to automatically \"rm\" files that have been\n+ removed from the working tree, and perform the actual commit.\n \n The gitlink:git-status[1] command can be used to obtain a\n summary of what is included by any of the above for the next\n"},{"id":"31651","messageId":"Pine.LNX.4.64.0701131503110.2577@xanadu.home","threadId":"6353","inReplyTo":"87wt3qwwm0.wl%cworth@cworth.org","subject":"Re: Importing from tarballs; add, rm, update-index?","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-01-13T20:29:57Z","receivedAt":"2007-01-13T20:29:57Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Sat, 13 Jan 2007, Carl Worth wrote:\n\n> On Sat, 13 Jan 2007 13:54:20 -0500 (EST), Nicolas Pitre wrote:\n> > The fact is that there is no strong reason why they shouldn't. But\n> > there are good reasons why they should. The most important one being\n> > that the user doesn't need to bother deciding which one of the two\n> > commands should be used in any given situation. And because a single\n> > command can cover two _technically_ different cases transparently is a\n> > pretty good reason for not imposing this technical issue to the user.\n> \n> But that same reasoning could be extended to say there shouldn't be\n> separate \"add\" and \"rm\", because a single command can transparently\n> cover these two technically different cases transparently, (that would\n> be update-index without --add and --remove safety checks). But nobody\n> has been proposing that that would be a good direction to go.\n\nIf nobody has been proposing that then it must not be a good direction \nto go indeed. This is however not the case for 'add' handling both new \nand existing files which I believe most people like.\n\n> So there are at least three cases one could identify for updating\n> content into the index:\n> \n> 1. Adding content for a path that didn't previously exist in the index\n> \n> 2. Updating content for a path that does already exist in the index\n> \n> 3. Removing a path and its content from the index\n> \n> As things stand currently, git's providing a first-class operation\n> (\"git add\") that provides (1) and (2) and another operation (\"git rm\")\n> for (3).\n> \n> However, \"commit -a\" is implicitly performing operations from (2) and\n> (3).\n> \n> So the documentation of \"commit -a\" being implemented with \"add\" just\n> plain doesn't make sense---and this is causing confusion.\n\nOK if that is what your grip is about let's fix the documentation then.\n\n> I'd love to see _something_ get accepted to resolve that\n> confusion. What I was proposing was a command that did (1) and another\n> that did (2) or (3), (and \"commit -a\" could then be documented as\n> using this command).\n\nNo. The command set is sane. Many people like it, and it does the work \nfine already, better than it used to.\n\nYou don't fix bad documentation by suiting the command set to it. \nYou fix the bad documentation instead.\n\nSo what about this:\n\ndiff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt\nindex cb081cd..96917d4 100644\n--- a/Documentation/git-commit.txt\n+++ b/Documentation/git-commit.txt\n@@ -32,7 +32,7 @@ methods:\n \n 4. by using the -a switch with the 'commit' command to automatically \"add\"\n changes from all known files i.e. files that have already been committed\n- before, and perform the actual commit.\n+ before, and/or \"rm\" missing known files, then perform the actual commit.\n \n The gitlink:git-status[1] command can be used to obtain a\n summary of what is included by any of the above for the next\n\nNicolas\n"},{"id":"31652","messageId":"20070113203456.GA17648@spearce.org","threadId":"6353","inReplyTo":"8E585186-FC3F-473B-BA1F-91CFEF1A63F4@silverinsanity.com","subject":"Re: Importing from tarballs; add, rm, update-index?","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-01-13T20:34:56Z","receivedAt":"2007-01-13T20:34:56Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Brian Gernhardt wrote:\n> Yes. It sounds very much like you want to simply do \"git add . ; git \n> commit -a\". But making that the default for \"commit -a\" would be \n> obnoxious for many other people.\n\nI find it annoying that \"commit -a\" isn't implemented in terms of\n\"git add .\". Mainly because I'll make a number of changes in Eclipse\nthen go back and do \"commit -a\" and only days later discover that\nI have untracked files in my working directory which should have\nbeen added to the commit several days ago.\n\nAlthough despite the fact that I always have my .gitignore setup \nproperly, every once in a while I'll change something to produce\na new file that Git should really ignore, and I'll forget to put\nit into .gitignore. Having some sort of \"commit -a\" which adds\nthat new file would be an issue.\n \n> A more through version (\"git commit --everything\"?) that also adds \n> files would be fine, but don't muck up the existing -a, please.\n\nYes, breaking -a may be a problem.\n\n-- \nShawn.\n"},{"id":"31683","messageId":"Pine.LNX.4.63.0701141340020.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6353","inReplyTo":"20070113203456.GA17648@spearce.org","subject":"Re: Importing from tarballs; add, rm, update-index?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-01-14T12:42:04Z","receivedAt":"2007-01-14T12:42:04Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sat, 13 Jan 2007, Shawn O. Pearce wrote:\n\n> Brian Gernhardt wrote:\n> > Yes. It sounds very much like you want to simply do \"git add . ; git \n> > commit -a\". But making that the default for \"commit -a\" would be \n> > obnoxious for many other people.\n> \n> I find it annoying that \"commit -a\" isn't implemented in terms of\n> \"git add .\". Mainly because I'll make a number of changes in Eclipse\n> then go back and do \"commit -a\" and only days later discover that\n> I have untracked files in my working directory which should have\n> been added to the commit several days ago.\n\nYou mean, you _ignored_ the text \"git commit -a\" gives you? It really \nshows you the output of \"git status\", exactly so you know what you \ncommitted, and sometimes more importantly, what you didn't.\n\nI mean, \"git commit\" spends a lot of time getting that information, so you \nbetter use it.\n\nCiao,\nDscho\n"},{"id":"31696","messageId":"20070114224204.GA10888@spearce.org","threadId":"6353","inReplyTo":"Pine.LNX.4.63.0701141340020.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: Importing from tarballs; add, rm, update-index?","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-01-14T22:42:04Z","receivedAt":"2007-01-14T22:42:04Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Johannes Schindelin wrote:\n> You mean, you _ignored_ the text \"git commit -a\" gives you? It really \n> shows you the output of \"git status\", exactly so you know what you \n> committed, and sometimes more importantly, what you didn't.\n\nBecause I'm a moron and forgot what files I had created recently.\nConsequently I don't see them missing from the output of git commit.\nConsequently I think the commit is OK. :-)\n\n-- \nShawn.\n"},{"id":"31714","messageId":"7v4pqtf699.fsf@assigned-by-dhcp.cox.net","threadId":"6353","inReplyTo":"20070114224204.GA10888@spearce.org","subject":"Re: Importing from tarballs; add, rm, update-index?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-15T01:06:26Z","receivedAt":"2007-01-15T01:06:26Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Shawn O. Pearce\" writes:\n\n> Johannes Schindelin wrote:\n>> You mean, you _ignored_ the text \"git commit -a\" gives you? It really \n>> shows you the output of \"git status\", exactly so you know what you \n>> committed, and sometimes more importantly, what you didn't.\n>\n> Because I'm a moron and forgot what files I had created recently.\n> Consequently I don't see them missing from the output of git commit.\n> Consequently I think the commit is OK. :-)\n\nI think Johannes is refering you to the \"Untracked files\"\nsection.\n"},{"id":"31746","messageId":"20070115011217.GA11240@spearce.org","threadId":"6353","inReplyTo":"7v4pqtf699.fsf@assigned-by-dhcp.cox.net","subject":"Re: Importing from tarballs; add, rm, update-index?","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-01-15T01:12:18Z","receivedAt":"2007-01-15T01:12:18Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Junio C Hamano wrote:\n> \"Shawn O. Pearce\" writes:\n> \n> > Johannes Schindelin wrote:\n> >> You mean, you _ignored_ the text \"git commit -a\" gives you? It really \n> >> shows you the output of \"git status\", exactly so you know what you \n> >> committed, and sometimes more importantly, what you didn't.\n> >\n> > Because I'm a moron and forgot what files I had created recently.\n> > Consequently I don't see them missing from the output of git commit.\n> > Consequently I think the commit is OK. :-)\n> \n> I think Johannes is refering you to the \"Untracked files\"\n> section.\n\nI commit often directly from the command line.\n\nBut yes, you're right. If I actually started my editor its right\nthere in the commit message template. Easy enough to quit without\nwriting the file, add the new files, and restart the commit.\n\n-- \nShawn.\n"},{"id":"31780","messageId":"Pine.LNX.4.64.0701151727310.20138@iabervon.org","threadId":"6353","inReplyTo":"20070115011217.GA11240@spearce.org","subject":"Re: Importing from tarballs; add, rm, update-index?","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2007-01-15T22:46:05Z","receivedAt":"2007-01-15T22:46:05Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Sun, 14 Jan 2007, Shawn O. Pearce wrote:\n\n> I commit often directly from the command line.\n> \n> But yes, you're right. If I actually started my editor its right\n> there in the commit message template. Easy enough to quit without\n> writing the file, add the new files, and restart the commit.\n\nAn config option to prohibit committing with untracked files should be \neasy to add. If your workflow is such that incorrect commits are sometimes \ngenerated given either policy, the system should ask you which you mean.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"31785","messageId":"200701160034.l0G0YC5J005016@laptop13.inf.utfsm.cl","threadId":"6353","inReplyTo":"Pine.LNX.4.64.0701151727310.20138@iabervon.org","subject":"Re: Importing from tarballs; add, rm, update-index?","fromName":"Horst H. von Brand","fromEmail":"vonbrand@inf.utfsm.cl","sentAt":"2007-01-16T00:34:12Z","receivedAt":"2007-01-16T00:34:12Z","isPatch":false,"sender":{"key":"vonbrand@inf.utfsm.cl","avatar":"https://avatars.githubusercontent.com/u/211384?v=4"},"body":"Daniel Barkalow wrote:\n> An config option to prohibit committing with untracked files should be \n> easy to add.\n\nRight. And that will annoy the heck out of people who have random litter\nleft behind, so their fingers will go \"git clean; git commit -a\" and then\n\"OOoops!!!\". If they can't read the commit message template in the first\nplace, or train their fingers to \"git add\" new files immediately...\n\n> If your workflow is such that incorrect commits are sometimes \n> generated given either policy, the system should ask you which you mean.\n\nLeave it alone. At least it will work the same always. Consistency is good.\n-- \nDr. Horst H. von Brand User #22616 counter.li.org\nDepartamento de Informatica Fono: +56 32 2654431\nUniversidad Tecnica Federico Santa Maria +56 32 2654239\nCasilla 110-V, Valparaiso, Chile Fax: +56 32 2797513\n"},{"id":"31788","messageId":"eoh7ht$cc$1@sea.gmane.org","threadId":"6353","inReplyTo":"Pine.LNX.4.64.0701151727310.20138@iabervon.org","subject":"Re: Importing from tarballs; add, rm, update-index?","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-01-16T00:51:39Z","receivedAt":"2007-01-16T00:51:39Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Daniel Barkalow wrote:\n\n> On Sun, 14 Jan 2007, Shawn O. Pearce wrote:\n> \n>> I commit often directly from the command line.\n>> \n>> But yes, you're right. If I actually started my editor its right\n>> there in the commit message template. Easy enough to quit without\n>> writing the file, add the new files, and restart the commit.\n> \n> An config option to prohibit committing with untracked files should be \n> easy to add. If your workflow is such that incorrect commits are sometimes \n> generated given either policy, the system should ask you which you mean.\n\nNot a config option. Pre-commit hook should be enough.\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"31801","messageId":"Pine.LNX.4.64.0701152154030.20138@iabervon.org","threadId":"6353","inReplyTo":"200701160034.l0G0YC5J005016@laptop13.inf.utfsm.cl","subject":"Re: Importing from tarballs; add, rm, update-index?","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2007-01-16T03:35:28Z","receivedAt":"2007-01-16T03:35:28Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Mon, 15 Jan 2007, Horst H. von Brand wrote:\n\n> Daniel Barkalow wrote:\n> > An config option to prohibit committing with untracked files should be \n> > easy to add.\n> \n> Right. And that will annoy the heck out of people who have random litter\n> left behind, so their fingers will go \"git clean; git commit -a\" and then\n> \"OOoops!!!\". If they can't read the commit message template in the first\n> place, or train their fingers to \"git add\" new files immediately...\n\nOr they can avoid enabling the config option if it's not actually helpful \nto them. I don't think it should be the default behavior, but I think it \nshould be available to people who tend to make the mistake Shawn \ndescribed. For that matter, it would be nice to have an option for \nfilename patterns that shouldn't be left untracked. I end up with plenty \nof junk, but none of it is *.c or *.h, unless the file is one I put in \n.gitignore.\n\nActually, a \"git ignore\" command that adds things to .gitignore (like 'for \ni in \"$*\"; do echo $i >> .gitignore; done; git-update-index --add \n.gitignore') would probably also be helpful. All of the files in my \ndirectories are one of (1) Things everybody wants to ignore, because \nthey're build system output or common backup file patterns, (2) Things \nthat should be tracked, because they're source, and (3) Things that \nshouldn't be tracked in the project, but which I want to hang on to, like \ninteresting debugging output.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"31816","messageId":"46d6db660701160412v6de41281sf167f23e7045017e@mail.gmail.com","threadId":"6353","inReplyTo":"Pine.LNX.4.64.0701152154030.20138@iabervon.org","subject":"Re: Importing from tarballs; add, rm, update-index?","fromName":"Christian MICHON","fromEmail":"christian.michon@gmail.com","sentAt":"2007-01-16T12:12:12Z","receivedAt":"2007-01-16T12:12:12Z","isPatch":false,"sender":{"key":"christian.michon@gmail.com","avatar":"https://gravatar.com/avatar/8a7c327b21187fbcab5c27640a49450eec72e0355dc292501197f27a5a744ec4?d=mp&s=160"},"body":"This is an interesting idea... so I went through the <> exercise of\ndownloading 117 tar bzipped versions of the kernel 2.6 (from 2.6.0 to\n2.6.19.2, without the release candidates). Quite an interesting\nbenchmark.\n\nThen I started importing them, through a similar script, creating a\nbranch for each version (for easy checkout). It takes around\n1.5 hours to complete.\n\nResults:\n======\n\ninitial point: 4.3Gb of tar.bz2 files\n\nintermediate: ~800Mb with ~120000 git objects\n\nfinal point: 100Mb with prune-packed objects\n(so it's about 2.5x the average tar.bz2 size of just a single kernel)\n\n--\nChristian\n"}]}