{"thread":{"id":"15233","subject":"Are these bugs?","startedAt":"2008-08-27T23:36:47Z","lastAt":"2008-08-28T08:44:08Z","messageCount":6,"participants":["Jay Soffian","Junio C Hamano","Stephan Beyer","Benny Halevy"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"88818","messageId":"76718490808271636i4de8f385pdaeb1672f06a00d7@mail.gmail.com","threadId":"15233","inReplyTo":null,"subject":"Are these bugs?","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2008-08-27T23:36:47Z","receivedAt":"2008-08-27T23:36:47Z","isPatch":false,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"1. You can't use reset in a just initialized repo:\n\n$ mkdir testrepo\n$ cd testrepo\n$ echo foo > foo\n$ git init\n$ git add .\n$ git reset\nfatal: Failed to resolve 'HEAD' as a valid ref.\n\nIn the real-world, I had initialized a new repository and realized I'd\nstaged extra files I didn't want. I was going to \"git reset\" then\nre-add the specific files I wanted, but that obviously failed. I\nworked around this by using \"git rm --cached\" to get rid of what I\ndidn't want.\n\nI understand why \"git reset\" failed, but at best the error message is\nconfusing to a new user.\n\n2. \"git add --ignore-errors\" doesn't work with ignored files:\n\n$ mkdir testrepo\n$ cd testrepo\n$ git init\nInitialized empty Git repository in /Users/jay/testrepo/.git/\n$ echo foo >> .git/info/exclude\n$ echo foo > foo\n$ echo bar > bar\n$ git add --ignore-errors foo bar\nThe following paths are ignored by one of your .gitignore files:\nfoo\nUse -f if you really want to add them.\nfatal: no files added\n\nNow you may ask \"why are you specifying foo if you don't want to add\nit?\" In the real-world I was generating the list to \"git add\" with\nxargs and it was quite a long list. It was easiest to filter out what\nI didn't want through .git/info/exclude. But I ended up having to \"...\n| grep -v | xargs git add\".\n\nSo I think preferable would be: \"Use -f if you really want to add them\nor --ignore errors to continue anyway.\"\n\n$ git version\ngit version 1.6.0.176.g8698c\n\nThoughts?\n\nj.\n"},{"id":"88822","messageId":"7v1w0akolk.fsf@gitster.siamese.dyndns.org","threadId":"15233","inReplyTo":"76718490808271636i4de8f385pdaeb1672f06a00d7@mail.gmail.com","subject":"Re: Are these bugs?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-08-27T23:47:03Z","receivedAt":"2008-08-27T23:47:03Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Jay Soffian\" writes:\n\n> I understand why \"git reset\" failed, but at best the error message is\n> confusing to a new user.\n\nThis is in \"patches welcome\" category.\n\n> 2. \"git add --ignore-errors\" doesn't work with ignored files:\n>\n> $ git add --ignore-errors foo bar\n\nThe option, IIRC, is more about filesystem errors (failure to read), not\nabout safety against user errors (specifying otherwise ignored paths).\n\nIf you are automating something that uses xargs to drive addition to the\nindex, and the feeder to xargs knows better than .gitignore files, then\nprobably your script should be using '-f' unconditionally. So I do not\nsee why you would think #2 could be a bug.\n"},{"id":"88837","messageId":"20080828010458.GE12354@leksak.fem-net","threadId":"15233","inReplyTo":"7v1w0akolk.fsf@gitster.siamese.dyndns.org","subject":"Re: Are these bugs?","fromName":"Stephan Beyer","fromEmail":"s-beyer@gmx.net","sentAt":"2008-08-28T01:04:58Z","receivedAt":"2008-08-28T01:04:58Z","isPatch":false,"sender":{"key":"s-beyer@gmx.net","avatar":"https://avatars.githubusercontent.com/u/143889?v=4"},"body":"Hi,\n\nJunio C Hamano wrote:\n> \"Jay Soffian\" writes:\n> \n> > I understand why \"git reset\" failed, but at best the error message is\n> > confusing to a new user.\n> \n> This is in \"patches welcome\" category.\n\n\nI sometimes wondered if \"git init\" should create a dummy commit\nwith empty tree, empty commit message or something like that and\nset refs/heads/master to that and HEAD to master.\nBut I always said to myself that this is a stupid idea for several\nreasons, i.e. backwards compatibility, or: if the dummy commit is to\nbe ignored (i.e. will not become parent of the first commit),\nthen it does not really help at all in decreasing complexity.\nSo I rejected this thought, but now it came back. ;-)\n\nA backwards-compatibily-breaking dummy commit would also help\nrebasing onto the dummy (replacing the first real commit).\nBut I still think it's stupid.\n\n\n\nSo, for a patch, is it sane to just remove/clear the index\nif get_sha1(\"HEAD\", sha1) fails?\n\nRegards,\n Stephan\n\n-- \nStephan Beyer , PGP 0x6EDDD207FCC5040F\n"},{"id":"88838","messageId":"7vwsi2j5q6.fsf@gitster.siamese.dyndns.org","threadId":"15233","inReplyTo":"20080828010458.GE12354@leksak.fem-net","subject":"Re: Are these bugs?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-08-28T01:20:01Z","receivedAt":"2008-08-28T01:20:01Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Stephan Beyer writes:\n\n> Junio C Hamano wrote:\n> \n>> \"Jay Soffian\" writes:\n>> \n>> > I understand why \"git reset\" failed, but at best the error message is\n>> > confusing to a new user.\n>> \n>> This is in \"patches welcome\" category.\n>\n> \n> But I still think it's stupid.\n> \n\nYes I think it is stupid. The dummy commit does not change the fact that\nyou need to special case it anyway, and special casing you can do without\nthe dummy commit that will contaminate the history. We already have such\nspecial case for \"log -p\" (--root used to be optional). If rebasing onto\nemptiness is problematic, the command should be taught how.\n\n> So, for a patch, is it sane to just remove/clear the index\n> if get_sha1(\"HEAD\", sha1) fails?\n\nAs a general idea, yes, but details matter.\n\nIf the user says \"git reset [--hard/--soft/--mixed] HEAD\" from the command\nline, we should say \"You do not even have HEAD commit\". If \"git reset\"\ndeduced (incorrectly) that the user meant HEAD, and only in that case, we\nshould clear the index.\n"},{"id":"88840","messageId":"76718490808271826y4ff8bc37ub046de3be5111eb5@mail.gmail.com","threadId":"15233","inReplyTo":"76718490808271825j68ac6abch406a8e12b5849b1a@mail.gmail.com","subject":"Re: Are these bugs?","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2008-08-28T01:26:27Z","receivedAt":"2008-08-28T01:26:27Z","isPatch":false,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"Oops, should've gone to list.\n\n\n---------- Forwarded message ----------\nFrom: Jay Soffian \nDate: Wed, Aug 27, 2008 at 9:25 PM\nSubject: Re: Are these bugs?\nTo: Junio C Hamano \n\n\nOn Wed, Aug 27, 2008 at 7:47 PM, Junio C Hamano wrote:\n> \"Jay Soffian\" writes:\n>\n>> I understand why \"git reset\" failed, but at best the error message is\n>> confusing to a new user.\n>\n> This is in \"patches welcome\" category.\n\nOkay, good to know. I'll add it to me \"things to do in spare time\" list.\n\n>> 2. \"git add --ignore-errors\" doesn't work with ignored files:\n>>\n>> $ git add --ignore-errors foo bar\n>\n> The option, IIRC, is more about filesystem errors (failure to read), not\n> about safety against user errors (specifying otherwise ignored paths).\n>\n> If you are automating something that uses xargs to drive addition to the\n> index, and the feeder to xargs knows better than .gitignore files, then\n> probably your script should be using '-f' unconditionally. So I do not\n> see why you would think #2 could be a bug.\n\nWell that's just it, my feeder to xargs did *not* know better than the\n.gitignore files so -f would have done the exact opposite of what I\nwanted. The git-add man page's description of --ignore-errors agrees\nwith what you write above though, so I'll just move along on this one.\n\nj.\n"},{"id":"88992","messageId":"48B66558.8010607@gmail.com","threadId":"15233","inReplyTo":"7vwsi2j5q6.fsf@gitster.siamese.dyndns.org","subject":"Re: Are these bugs?","fromName":"Benny Halevy","fromEmail":"bhalevy@panasas.com","sentAt":"2008-08-28T08:44:08Z","receivedAt":"2008-08-28T08:44:08Z","isPatch":false,"sender":{"key":"bhalevy@panasas.com","avatar":null},"body":"On Aug. 28, 2008, 4:20 +0300, Junio C Hamano wrote:\n> Stephan Beyer writes:\n> \n>> Junio C Hamano wrote:\n>>\n>>> \"Jay Soffian\" writes:\n>>>\n>>>> I understand why \"git reset\" failed, but at best the error message is\n>>>> confusing to a new user.\n>>> This is in \"patches welcome\" category.\n>> \n>> But I still think it's stupid.\n>> \n> \n> Yes I think it is stupid. The dummy commit does not change the fact that\n> you need to special case it anyway, and special casing you can do without\n> the dummy commit that will contaminate the history. We already have such\n> special case for \"log -p\" (--root used to be optional). If rebasing onto\n> emptiness is problematic, the command should be taught how.\n> \n>> So, for a patch, is it sane to just remove/clear the index\n>> if get_sha1(\"HEAD\", sha1) fails?\n> \n> As a general idea, yes, but details matter.\n> \n> If the user says \"git reset [--hard/--soft/--mixed] HEAD\" from the command\n> line, we should say \"You do not even have HEAD commit\". If \"git reset\"\n> deduced (incorrectly) that the user meant HEAD, and only in that case, we\n> should clear the index.\n\nI'm really not sure about the details, but providing a way to refer\nto the empty state of the tree is needed. For example, I don't know\nhow to do an interactive rebase of all commits in my tree, or to rebase\na sub-series starting at \"INIT\" (or \"NIL\" or whatever :) onto some\nother base (say some remote branch).\n\nBenny\n\n> \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"}]}