{"thread":{"id":"26496","subject":"[1.8.0 RFD] Homogeneous use of short options","startedAt":"2011-02-14T15:04:00Z","lastAt":"2011-02-15T07:18:25Z","messageCount":6,"participants":["Michael J Gruber","Nguyen Thai Ngoc Duy","Jay Soffian","Junio C Hamano","Miles Bader"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"161053","messageId":"4D594460.1040206@drmicha.warpmail.net","threadId":"26496","inReplyTo":null,"subject":"[1.8.0 RFD] Homogeneous use of short options","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2011-02-14T15:04:00Z","receivedAt":"2011-02-14T15:04:00Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Proposal:\nMake our use of short options more homogeneous.\n\nI have put together a list of options which are used by the \"most common\ncommands\", using the output of \"git --help-all\":\n\nhttp://repo.or.cz/w/git/mjg.git/blob/options.txt\n\n(scroll down for the short options)\n\nThis leaves out a few commands with different option parsing (diff, log,\nrebase, show) but indicates that we're doing a good job already. A few\nnotable outliers:\n\nadd -A: Why capital A? Compare commit -a etc.\n\ncommit -n, fetch -n, merge -n: These are REALLY bad! Users should be\nable to rely on '-n' being '--dry-run' or at least being no-op to their\nrepo, like clone/grep/tag -n.\n\ntag -v: This is not a real problem, but users have certain expections\nfor \"-f,-h,-n,-v\" which we should break as rarely as possible. OTOH,\nwhat would \"verbose\" mean for tag? (NB: tag.txt is grossly wrong.)\n\ngrep -?: This tries to be compatible with GNU grep, so it's a natural\noutlier.\n\nRisks:\nUsers and scripts may obviously depend on the current options names.\n\nMigration plan:\nIntroduce new options first (1.7.x) along with warnings in the release\nnotes (optionally, make the commands output warnings). Then change the\nbehavior in 1.8.0.\n\nTODO:\nGenerate an option list for the other common commands.\n\nI'll also follow up with a little series fixing inconsistencies in the\ndescriptions.\n"},{"id":"161062","messageId":"AANLkTikFEQTrt+vw5tJ+prSB0Krb9VOZFg+Wn0G_Movr@mail.gmail.com","threadId":"26496","inReplyTo":"4D594460.1040206@drmicha.warpmail.net","subject":"Re: [1.8.0 RFD] Homogeneous use of short options","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2011-02-14T15:19:11Z","receivedAt":"2011-02-14T15:19:11Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Mon, Feb 14, 2011 at 10:04 PM, Michael J Gruber\n wrote:\n> Proposal:\n> Make our use of short options more homogeneous.\n>\n> ...\n>\n> Risks:\n> Users and scripts may obviously depend on the current options names.\n>\n> Migration plan:\n> Introduce new options first (1.7.x) along with warnings in the release\n> notes (optionally, make the commands output warnings). Then change the\n> behavior in 1.8.0.\n\nSometimes I think we could just add a new \"root\" name for total UI\nredesign. Say all commands starting with \"gic\" (or whatever name it\nis, \"gt\" may be even shorter) will have new/consistent behavior while\n\"git\" ones remain unchanged (or changed gradually and sloooowly). It\nhappened with bazaar (baz vs bzr) long ago.\n-- \nDuy\n"},{"id":"161084","messageId":"AANLkTi=PGwYz_GbYT3UR00UrhMi5KP_KU1y-+g+Qo1n9@mail.gmail.com","threadId":"26496","inReplyTo":"4D594460.1040206@drmicha.warpmail.net","subject":"Re: [1.8.0 RFD] Homogeneous use of short options","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2011-02-14T19:03:01Z","receivedAt":"2011-02-14T19:03:01Z","isPatch":false,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"On Mon, Feb 14, 2011 at 10:04 AM, Michael J Gruber\n wrote:\n> tag -v: This is not a real problem, but users have certain expections\n> for \"-f,-h,-n,-v\" which we should break as rarely as possible. OTOH,\n> what would \"verbose\" mean for tag? (NB: tag.txt is grossly wrong.)\n\nI made mine look like branch -v:\n\n$ cat bin/git-tagv\n#!/bin/sh\nformat='\ncase %(objecttype) in\n commit)\n sha1=%(objectname:short)\n subject=%(subject)\n ;;\n tag)\n sha1=%(*objectname:short)\n subject=%(*subject)\n ;;\nesac\nprintf \"%s\\t%s\\t%s\\n\" %(refname:short) \"$sha1\" \"$subject\"\n'\neval \"$(git for-each-ref --shell --format=\"$format\" refs/tags)\" |\ncolumn -t -s \"$(printf '\\t')\"\n\nj.\n"},{"id":"161102","messageId":"AANLkTim1GUnyqkNbFPhkPEOitGG7PxsW1eeubkN69hf5@mail.gmail.com","threadId":"26496","inReplyTo":"4D594460.1040206@drmicha.warpmail.net","subject":"Re: [1.8.0 RFD] Homogeneous use of short options","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-02-14T21:00:02Z","receivedAt":"2011-02-14T21:00:02Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"On Mon, Feb 14, 2011 at 7:04 AM, Michael J Gruber\n wrote:\n\n> add -A: Why capital A? Compare commit -a etc.\n\nIIRC, this was in anticipation for a similar interface to include\n_new_ files in the commit in the form of \"commit -A\", which _is_\ndifferent from the existing \"commit -a\".\n"},{"id":"161139","messageId":"871v3a2k7i.fsf@catnip.gol.com","threadId":"26496","inReplyTo":"AANLkTim1GUnyqkNbFPhkPEOitGG7PxsW1eeubkN69hf5@mail.gmail.com","subject":"Re: [1.8.0 RFD] Homogeneous use of short options","fromName":"Miles Bader","fromEmail":"miles@gnu.org","sentAt":"2011-02-15T00:52:01Z","receivedAt":"2011-02-15T00:52:01Z","isPatch":false,"sender":{"key":"miles@gnu.org","avatar":"https://gravatar.com/avatar/01069b69593af7bff28e2f97afeb3644ae6fe2f5f56cb3a8cf34c5fb8c36efe5?d=mp&s=160"},"body":"Junio C Hamano writes:\n>> add -A: Why capital A? Compare commit -a etc.\n>\n> IIRC, this was in anticipation for a similar interface to include\n> _new_ files in the commit in the form of \"commit -A\", which _is_\n> different from the existing \"commit -a\".\n\nI look up the meaning of \"git commit -u\":\n\n$ git commit --help\n...\n -u[], --untracked-files[=]\n Show untracked files (Default: all).\n\n The mode parameter is optional, and is used to specify the handling\n of untracked files.\n\n The possible options are:\n\n · no - Show no untracked files\n · normal - Shows untracked files and directories\n · all - Also shows individual files in untracked directories.\n\n See git-config(1) for configuration variable used to change the\n default for when the option is not specified.\n\nI guess it means it only affects the status-display for --dry-run, but\nit seems a little confusing to not say that explicitly...\n\n-miles\n\n-- \nCabbage, n. A familiar kitchen-garden vegetable about as large and wise as a\nman's head.\n"},{"id":"161156","messageId":"4D5A28C1.1080803@drmicha.warpmail.net","threadId":"26496","inReplyTo":"871v3a2k7i.fsf@catnip.gol.com","subject":"Re: [1.8.0 RFD] Homogeneous use of short options","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2011-02-15T07:18:25Z","receivedAt":"2011-02-15T07:18:25Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Miles Bader venit, vidit, dixit 15.02.2011 01:52:\n> Junio C Hamano writes:\n>>> add -A: Why capital A? Compare commit -a etc.\n>>\n>> IIRC, this was in anticipation for a similar interface to include\n>> _new_ files in the commit in the form of \"commit -A\", which _is_\n>> different from the existing \"commit -a\".\n> \n> I look up the meaning of \"git commit -u\":\n> \n> $ git commit --help\n> ...\n> -u[], --untracked-files[=]\n> Show untracked files (Default: all).\n> \n> The mode parameter is optional, and is used to specify the handling\n> of untracked files.\n> \n> The possible options are:\n> \n> · no - Show no untracked files\n> · normal - Shows untracked files and directories\n> · all - Also shows individual files in untracked directories.\n> \n> See git-config(1) for configuration variable used to change the\n> default for when the option is not specified.\n> \n> I guess it means it only affects the status-display for --dry-run, but\n> it seems a little confusing to not say that explicitly...\n\nI think it is confusing only until you have used \"commit\" without \"-m\"\nfor the first time - and only if you overlooked the 3 occurences of\n\"show\" ;)\n\nMichael\n"}]}