{"thread":{"id":"11376","subject":"1.5.4-rc2 plans","startedAt":"2007-12-21T00:32:28Z","lastAt":"2007-12-22T17:54:04Z","messageCount":19,"participants":["Junio C Hamano","Johannes Sixt","Steven Grimm","Mike Frysinger","Pierre Habouzit","Johannes Schindelin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"63893","messageId":"7vwsr8lwf7.fsf@gitster.siamese.dyndns.org","threadId":"11376","inReplyTo":null,"subject":"1.5.4-rc2 plans","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-12-21T00:32:28Z","receivedAt":"2007-12-21T00:32:28Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"I've tagged -rc1 last night.  The changes are mostly fixes.  There are\nsome remaining issues I'd like to see fixed/decided before 1.5.4.\n\nOne important issue is to identify and fix regressions since 1.5.3\nseries.  No \"rewrite scripted git-foo completely in C\" can be regression\nfree, and we had quite a few internal changes during 1.5.4 cycle (not\njust rewrite to C, but C level uses new and improved API such as strbuf\nand parse-options).  Currently I am aware of these regressions:\n\n * handling of options, \"--abbrev 10 HEAD\", \"--abbrev=10 HEAD\" and\n   \"--abbrev HEAD\".  The last one does not work for commands that use\n   parse-options.  Pierre is on top of this, I hope.\n\n * handling of EDITOR in git commit and git tag is currently different.\n   It expects \"vi\" not \"vi --some-funny-option\".  I sent out a\n   for-discussion patch after seeing Steven's and Luciano's.\n\nbut I am sure there must be others that we haven't even identified.\n\nAlso there have been handful usability issues, which can be solved\nwithout incompatible changes:\n\n * Should \"git stash\" stop doing anything useful?  I think the patch\n   from Nana today may be a reasonable compromise, although I still\n   think fundamentally different behaviour for the same command\n   configurable per-user is not very nice (we have precedent in \"git\n   clean\" already, though, but \"git clean\" is inherently dangerous\n   command, and \"git stash\" is much more useful and the issue impacts\n   more people).\n\n * Introduction of \"<tree>:./path\" (Dscho).  I could be talked into\n   accepting the patch if it is useful to people who live deep within\n   subdirectories.\n\n * Making commit log message cleansing optionally less aggressive.  I do\n   not think we have seen the end of the thread yet, but I think Linus's\n   \"three cleansing levels\" approach is on the right track.\n\nI'd like to see the above resolved and hopefully 12 other regressions\nidentified and fixed before the end of the year, when -rc2 can hopefully\nhappen.\n\nThe following technical issues have been raised but not resolved and I\ndo not expect the resolution to be part of 1.5.4.\n\n * Authenticated pserver (Ævar Arnfjörð Bjarmason).  It needs security\n   audit of the code and also the password storage needs to be decided.\n   This can wait post 1.5.4.\n\n * Threaded \"repack -a -d -f\" when having a verify tight pack suffers\n   from massive malloc(3) memory fragmentation, which we cannot do much\n   about.\n\n * Rebase using \"format-patch | am\" machinery has issues when dealing\n   with a mostly-text change that includes NUL (or anything you cannot\n   e-mail patch for).  The workaround is \"rebase -m\" which unfortunatly\n   is slow.  I am working on rewriting cherry-pick whenever I find time\n   to address it, though.\n\n * Handling of trailing blank lines does not mesh well with the way diff\n   and apply whitespace logic is done.\n"},{"id":"63904","messageId":"476B6ABB.6040009@viscovery.net","threadId":"11376","inReplyTo":"7vwsr8lwf7.fsf@gitster.siamese.dyndns.org","subject":"Re: 1.5.4-rc2 plans","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2007-12-21T07:26:51Z","receivedAt":"2007-12-21T07:26:51Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Junio C Hamano schrieb:\n>  * Should \"git stash\" stop doing anything useful?  I think the patch\n>    from Nana today may be a reasonable compromise, although I still\n>    think fundamentally different behaviour for the same command\n>    configurable per-user is not very nice (we have precedent in \"git\n>    clean\" already, though, but \"git clean\" is inherently dangerous\n>    command, and \"git stash\" is much more useful and the issue impacts\n>    more people).\n\nIMO we should give in and play the safe game. For those who don't like to\ntype \"git stash save\" can always\n\n    git config --global alias.shelve \"stash save\"\n    git config --global alias.unshelve \"stash apply\"\n\nand retrain the fingers.\n\n-- Hannes\n"},{"id":"63907","messageId":"1DCAF728-4B12-4EA8-84BB-DFB30B42BFF8@midwinter.com","threadId":"11376","inReplyTo":"7vwsr8lwf7.fsf@gitster.siamese.dyndns.org","subject":"Re: 1.5.4-rc2 plans","fromName":"Steven Grimm","fromEmail":"koreth@midwinter.com","sentAt":"2007-12-21T08:57:46Z","receivedAt":"2007-12-21T08:57:46Z","isPatch":false,"sender":{"key":"koreth@midwinter.com","avatar":"https://gravatar.com/avatar/71b4d2e8b62f168bdc9e9205341159e3567003b4f9e2127c617c5fa0a1f5bad2?d=mp&s=160"},"body":"On Dec 20, 2007, at 4:32 PM, Junio C Hamano wrote:\n> * handling of EDITOR in git commit and git tag is currently different.\n>   It expects \"vi\" not \"vi --some-funny-option\".  I sent out a\n>   for-discussion patch after seeing Steven's and Luciano's.\n\nI'm perfectly fine with your approach (punt and let the shell figure  \nit out). It's certainly a lot less code change than mine. However, if  \nyou want another rev of mine with Johannes' comments taken into  \naccount, I should be able to do that in the next day or two.\n\n-Steve\n"},{"id":"63908","messageId":"8bd0f97a0712210109q7805d967sc9b4cd13d4131360@mail.gmail.com","threadId":"11376","inReplyTo":"476B6ABB.6040009@viscovery.net","subject":"Re: 1.5.4-rc2 plans","fromName":"Mike Frysinger","fromEmail":"vapier.adi@gmail.com","sentAt":"2007-12-21T09:09:49Z","receivedAt":"2007-12-21T09:09:49Z","isPatch":false,"sender":{"key":"vapier.adi@gmail.com","avatar":null},"body":"On Dec 21, 2007 2:26 AM, Johannes Sixt <j.sixt@viscovery.net> wrote:\n> Junio C Hamano schrieb:\n> >  * Should \"git stash\" stop doing anything useful?  I think the patch\n> >    from Nana today may be a reasonable compromise, although I still\n> >    think fundamentally different behaviour for the same command\n> >    configurable per-user is not very nice (we have precedent in \"git\n> >    clean\" already, though, but \"git clean\" is inherently dangerous\n> >    command, and \"git stash\" is much more useful and the issue impacts\n> >    more people).\n>\n> IMO we should give in and play the safe game. For those who don't like to\n> type \"git stash save\" can always\n>\n>     git config --global alias.shelve \"stash save\"\n>     git config --global alias.unshelve \"stash apply\"\n>\n> and retrain the fingers.\n\nin the past, i used git merely to checkout code and send diffs to\nmaintainers ... never for my own work.  ive started to transition from\nusing svn everywhere to trying out git, and saw reference to this\n\"stash\" command on another list.  i wanted to learn more about it, so\ni started off with `git-stash` to get some info, and wondered what\njust happened.  then i typoed the --help option and wondered even more\nwhat just happened :).\n\nafter flipping through the git mailing list for a while, it's good to\nsee that `git stash <random crap>` will be fixed in the next release,\nand yes the default behavior of saving is confusing.  the argument\nthat newbies can easily recover their work really only works if the\nnewbie knows what's going on.  if they knew from the start, then they\nwouldnt be newbies eh.\n\nmaking the default behavior non-destructive (which is to say, not\nchanging anything) and allowing people to arbitrarily configure the\ndefault behavior sounds sane to me.  taking it up a level, people\ncould just as easily write functions in their shell environment to do\nthe same thing.  which is to say that imho, the argument against this\nfor fear of different behavior depending on user is over the top.\nconfiguration options are there to change the behavior based on the\nuser's preference.\n-mike\n"},{"id":"63913","messageId":"20071221104704.GC17701@artemis.madism.org","threadId":"11376","inReplyTo":"7vwsr8lwf7.fsf@gitster.siamese.dyndns.org","subject":"Re: 1.5.4-rc2 plans","fromName":"Pierre Habouzit","fromEmail":"madcoder@artemis.madism.org","sentAt":"2007-12-21T10:47:04Z","receivedAt":"2007-12-21T10:47:04Z","isPatch":false,"sender":{"key":"madcoder@artemis.madism.org","avatar":null},"body":"On Fri, Dec 21, 2007 at 12:32:28AM +0000, Junio C Hamano wrote:\n> I've tagged -rc1 last night.  The changes are mostly fixes.  There are\n> some remaining issues I'd like to see fixed/decided before 1.5.4.\n> \n> One important issue is to identify and fix regressions since 1.5.3\n> series.  No \"rewrite scripted git-foo completely in C\" can be regression\n> free, and we had quite a few internal changes during 1.5.4 cycle (not\n> just rewrite to C, but C level uses new and improved API such as strbuf\n> and parse-options).  Currently I am aware of these regressions:\n> \n>  * handling of options, \"--abbrev 10 HEAD\", \"--abbrev=10 HEAD\" and\n>    \"--abbrev HEAD\".  The last one does not work for commands that use\n>    parse-options.  Pierre is on top of this, I hope.\n\nHmm now I'm confused, I believed we settled for the: --abbrev 10 HEAD is\nforbidden, --abbrev=10 HEAD works, and --abbrev HEAD too. This would\nintroduce no regressions _yet_ as none of the commands that use\nparse-options and take --abbrev accepted the --abbrev 10 form before. I\nalready sent this once, and assumed you took it, hence me being silent\nthe last days. Here is it again then.  Of course this does not affects\nother long options for which `--long-option arg` still works (if they do\ntake an argument).\n\nI'd also like to see any kind of form of gitcli(5) be merged for 1.5.4\ntoo, I believe the first version I ever sent. In the thread where I\nposted the proposal using `{}` the patch introducing it is the version\nformed using:\n  * my first proposal for it ;\n  * your english fixes squashed on top of it ;\n  * a fix wrt the '--no-' prefix and Boolean options that we discussed.\nThis version describes the current state of things properly IMHO. I can\nfind the message id if you need, but I don't have the commit locally\nanymore atm.\n\nCheers,\n\nFrom 37c7baaa82f36d16697fa190635f5d3efbe2a83d Mon Sep 17 00:00:00 2001\nFrom: Pierre Habouzit <madcoder@debian.org>\nDate: Fri, 21 Dec 2007 11:41:41 +0100\nSubject: [PATCH] Force the sticked form for options with optional arguments.\n\nSigned-off-by: Pierre Habouzit <madcoder@debian.org>\n---\n parse-options.c |    6 +++---\n 1 files changed, 3 insertions(+), 3 deletions(-)\n\ndiff --git a/parse-options.c b/parse-options.c\nindex 574ed31..4f5c55e 100644\n--- a/parse-options.c\n+++ b/parse-options.c\n@@ -89,7 +89,7 @@ static int get_value(struct optparse_t *p,\n \t\t\t*(const char **)opt->value = NULL;\n \t\t\treturn 0;\n \t\t}\n-\t\tif (opt->flags & PARSE_OPT_OPTARG && (!arg || *arg == '-')) {\n+\t\tif (opt->flags & PARSE_OPT_OPTARG && !p->opt) {\n \t\t\t*(const char **)opt->value = (const char *)opt->defval;\n \t\t\treturn 0;\n \t\t}\n@@ -103,7 +103,7 @@ static int get_value(struct optparse_t *p,\n \t\t\treturn (*opt->callback)(opt, NULL, 1);\n \t\tif (opt->flags & PARSE_OPT_NOARG)\n \t\t\treturn (*opt->callback)(opt, NULL, 0);\n-\t\tif (opt->flags & PARSE_OPT_OPTARG && (!arg || *arg == '-'))\n+\t\tif (opt->flags & PARSE_OPT_OPTARG && !p->opt)\n \t\t\treturn (*opt->callback)(opt, NULL, 0);\n \t\tif (!arg)\n \t\t\treturn opterror(opt, \"requires a value\", flags);\n@@ -114,7 +114,7 @@ static int get_value(struct optparse_t *p,\n \t\t\t*(int *)opt->value = 0;\n \t\t\treturn 0;\n \t\t}\n-\t\tif (opt->flags & PARSE_OPT_OPTARG && (!arg || !isdigit(*arg))) {\n+\t\tif (opt->flags & PARSE_OPT_OPTARG && !p->opt) {\n \t\t\t*(int *)opt->value = opt->defval;\n \t\t\treturn 0;\n \t\t}\n-- \n1.5.4.rc1.1096.g37c7b\n\n"},{"id":"63916","messageId":"20071221105058.GD17701@artemis.madism.org","threadId":"11376","inReplyTo":"20071221104704.GC17701@artemis.madism.org","subject":"[PATCH] git-tag: fix -l switch handling regression.","fromName":"Pierre Habouzit","fromEmail":"madcoder@debian.org","sentAt":"2007-12-21T10:50:58Z","receivedAt":"2007-12-21T10:50:58Z","isPatch":true,"sender":{"key":"madcoder@debian.org","avatar":"https://avatars.githubusercontent.com/u/44708?v=4"},"body":"Signed-off-by: Pierre Habouzit <madcoder@debian.org>\n---\n\nIt seems that you didnt took that patch either, that IMHO gives a better\nsemantics to git tag -l than yours, while keeping backward\ncompatibility.\n\n\n builtin-tag.c |   12 +++++-------\n 1 files changed, 5 insertions(+), 7 deletions(-)\n\ndiff --git a/builtin-tag.c b/builtin-tag.c\nindex 274901a..020ee1c 100644\n--- a/builtin-tag.c\n+++ b/builtin-tag.c\n@@ -16,7 +16,7 @@\n static const char * const git_tag_usage[] = {\n \t\"git-tag [-a|-s|-u <key-id>] [-f] [-m <msg>|-F <file>] <tagname> [<head>]\",\n \t\"git-tag -d <tagname>...\",\n-\t\"git-tag [-n [<num>]] -l [<pattern>]\",\n+\t\"git-tag -l [-n [<num>]] [<pattern>]\",\n \t\"git-tag -v <tagname>...\",\n \tNULL\n };\n@@ -370,13 +370,11 @@ int cmd_tag(int argc, const char **argv, const char *prefix)\n \tstruct ref_lock *lock;\n \n \tint annotate = 0, sign = 0, force = 0, lines = 0,\n-\t\t\t\t\tdelete = 0, verify = 0;\n-\tchar *list = NULL, *msgfile = NULL, *keyid = NULL;\n-\tconst char *no_pattern = \"NO_PATTERN\";\n+\t\tlist = 0, delete = 0, verify = 0;\n+\tchar *msgfile = NULL, *keyid = NULL;\n \tstruct msg_arg msg = { 0, STRBUF_INIT };\n \tstruct option options[] = {\n-\t\t{ OPTION_STRING, 'l', NULL, &list, \"pattern\", \"list tag names\",\n-\t\t\tPARSE_OPT_OPTARG, NULL, (intptr_t) no_pattern },\n+\t\tOPT_BOOLEAN('l', NULL, &list, \"list tag names\"),\n \t\t{ OPTION_INTEGER, 'n', NULL, &lines, NULL,\n \t\t\t\t\"print n lines of each tag message\",\n \t\t\t\tPARSE_OPT_OPTARG, NULL, 1 },\n@@ -408,7 +406,7 @@ int cmd_tag(int argc, const char **argv, const char *prefix)\n \t\tannotate = 1;\n \n \tif (list)\n-\t\treturn list_tags(list == no_pattern ? NULL : list, lines);\n+\t\treturn list_tags(argv[0], lines);\n \tif (delete)\n \t\treturn for_each_tag_name(argv, delete_tag);\n \tif (verify)\n-- \n1.5.4.rc1.1096.g37c7b\n\n"},{"id":"63918","messageId":"7vk5n8b92w.fsf@gitster.siamese.dyndns.org","threadId":"11376","inReplyTo":"20071221104704.GC17701@artemis.madism.org","subject":"Re: 1.5.4-rc2 plans","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-12-21T11:06:47Z","receivedAt":"2007-12-21T11:06:47Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Pierre Habouzit <madcoder@artemis.madism.org> writes:\n\n> Hmm now I'm confused, I believed we settled for the: --abbrev 10 HEAD is\n> forbidden, --abbrev=10 HEAD works, and --abbrev HEAD too.\n\nhttp://thread.gmane.org/gmane.comp.version-control.git/68121/focus=68659 ?\n\n> I'd also like to see any kind of form of gitcli(5) be merged for 1.5.4\n> too, I believe the first version I ever sent. In the thread where I\n> posted the proposal using `{}` the patch introducing it is the version\n> formed using:\n\nUnfortunately I've been busy lately and have already discarded\nthe whole series that had the {} stuff.  Could you resend\ncleaned up patch please, so that I can take a look over the\nweekend?\n"},{"id":"63919","messageId":"20071221111356.GA25953@artemis.madism.org","threadId":"11376","inReplyTo":"7vk5n8b92w.fsf@gitster.siamese.dyndns.org","subject":"Re: 1.5.4-rc2 plans","fromName":"Pierre Habouzit","fromEmail":"madcoder@artemis.madism.org","sentAt":"2007-12-21T11:13:56Z","receivedAt":"2007-12-21T11:13:56Z","isPatch":false,"sender":{"key":"madcoder@artemis.madism.org","avatar":null},"body":"On Fri, Dec 21, 2007 at 11:06:47AM +0000, Junio C Hamano wrote:\n> Pierre Habouzit <madcoder@artemis.madism.org> writes:\n> \n> > Hmm now I'm confused, I believed we settled for the: --abbrev 10 HEAD is\n> > forbidden, --abbrev=10 HEAD works, and --abbrev HEAD too.\n> \n> http://thread.gmane.org/gmane.comp.version-control.git/68121/focus=68659 ?\n\n  okay, then it's what I remembered, I was confused because the patch\nfor that was around for quite some time, but I just resent it so this\none is okay.\n\n> > I'd also like to see any kind of form of gitcli(5) be merged for 1.5.4\n> > too, I believe the first version I ever sent. In the thread where I\n> > posted the proposal using `{}` the patch introducing it is the version\n> > formed using:\n> \n> Unfortunately I've been busy lately and have already discarded\n> the whole series that had the {} stuff.  Could you resend\n> cleaned up patch please, so that I can take a look over the\n> weekend?\n\n  sure, this is the patch from\nhttp://article.gmane.org/gmane.comp.version-control.git/68140 actually,\nI will resend a proper patch when I've been able to get that one back :)\n\n-- \n·O·  Pierre Habouzit\n··O                                                madcoder@debian.org\nOOO                                                http://www.madism.org\n"},{"id":"63921","messageId":"20071221111956.GB25953@artemis.madism.org","threadId":"11376","inReplyTo":"20071221111356.GA25953@artemis.madism.org","subject":"[PATCH] parse-options: Add a gitcli(5) man page.","fromName":"Pierre Habouzit","fromEmail":"madcoder@artemis.madism.org","sentAt":"2007-12-21T11:19:56Z","receivedAt":"2007-12-21T11:19:56Z","isPatch":true,"sender":{"key":"madcoder@artemis.madism.org","avatar":null},"body":"This page should hold every information about the git ways to parse command\nlines, and best practices to be used for scripting.\n\nSigned-off-by: Pierre Habouzit <madcoder@debian.org>\n---\n    > > Unfortunately I've been busy lately and have already discarded\n    > > the whole series that had the {} stuff.  Could you resend\n    > > cleaned up patch please, so that I can take a look over the\n    > > weekend?\n    > \n    >   sure, this is the patch from\n    > http://article.gmane.org/gmane.comp.version-control.git/68140 actually,\n    > I will resend a proper patch when I've been able to get that one back :)\n\n    in fact that is not the proper one, and I had one kept here. I just\n    pushed the 3 patches on my ph/parseopt branch at\n    git://git.madism.org/git.git, rebased on the current next.\n\n    Cheers,\n\n Documentation/Makefile   |    2 +-\n Documentation/gitcli.txt |  113 ++++++++++++++++++++++++++++++++++++++++++++++\n Makefile                 |    1 +\n 3 files changed, 115 insertions(+), 1 deletions(-)\n create mode 100644 Documentation/gitcli.txt\n\ndiff --git a/Documentation/Makefile b/Documentation/Makefile\nindex 76df06c..c4486d3 100644\n--- a/Documentation/Makefile\n+++ b/Documentation/Makefile\n@@ -2,7 +2,7 @@ MAN1_TXT= \\\n \t$(filter-out $(addsuffix .txt, $(ARTICLES) $(SP_ARTICLES)), \\\n \t\t$(wildcard git-*.txt)) \\\n \tgitk.txt\n-MAN5_TXT=gitattributes.txt gitignore.txt gitmodules.txt\n+MAN5_TXT=gitattributes.txt gitignore.txt gitcli.txt gitmodules.txt\n MAN7_TXT=git.txt\n \n MAN_TXT = $(MAN1_TXT) $(MAN5_TXT) $(MAN7_TXT)\ndiff --git a/Documentation/gitcli.txt b/Documentation/gitcli.txt\nnew file mode 100644\nindex 0000000..b7dcf9c\n--- /dev/null\n+++ b/Documentation/gitcli.txt\n@@ -0,0 +1,113 @@\n+gitcli(5)\n+=========\n+\n+NAME\n+----\n+gitcli - git command line interface and conventions\n+\n+SYNOPSIS\n+--------\n+gitcli\n+\n+\n+DESCRIPTION\n+-----------\n+\n+This manual describes best practice in how to use git CLI.  Here are\n+the rules that you should follow when you are scripting git:\n+\n+ * it's preferred to use the non dashed form of git commands, which means that\n+   you should prefer `\"git foo\"` to `\"git-foo\"`.\n+\n+ * splitting short options to separate words (prefer `\"git foo -a -b\"`\n+   to `\"git foo -ab\"`, the latter may not even work).\n+\n+ * when a command line option takes an argument, use the 'sticked' form.  In\n+   other words, write `\"git foo -oArg\"` instead of `\"git foo -o Arg\"` for short\n+   options, and `\"git foo --long-opt=Arg\"` instead of `\"git foo --long-opt Arg\"`\n+   for long options.  An option that takes optional option-argument must be\n+   written in the 'sticked' form.\n+\n+ * when you give a revision parameter to a command, make sure the parameter is\n+   not ambiguous with a name of a file in the work tree.  E.g. do not write\n+   `\"git log -1 HEAD\"` but write `\"git log -1 HEAD --\"`; the former will not work\n+   if you happen to have a file called `HEAD` in the work tree.\n+\n+\n+ENHANCED CLI\n+------------\n+From the git 1.5.4 series and further, many git commands (not all of them at the\n+time of the writing though) come with an enhanced option parser.\n+\n+Here is an exhaustive list of the facilities provided by this option parser.\n+\n+\n+Magic Options\n+~~~~~~~~~~~~~\n+Commands which have the enhanced option parser activated all understand a\n+couple of magic command line options:\n+\n+-h::\n+\tgives a pretty printed usage of the command.\n++\n+---------------------------------------------\n+$ git describe -h\n+usage: git-describe [options] <committish>*\n+\n+    --contains            find the tag that comes after the commit\n+    --debug               debug search strategy on stderr\n+    --all                 use any ref in .git/refs\n+    --tags                use any tag in .git/refs/tags\n+    --abbrev [<n>]        use <n> digits to display SHA-1s\n+    --candidates <n>      consider <n> most recent tags (default: 10)\n+---------------------------------------------\n+\n+--help-all::\n+\tSome git commands take options that are only used for plumbing or that\n+\tare deprecated, and such options are hidden from the default usage. This\n+\toption gives the full list of options.\n+\n+\n+Negating options\n+~~~~~~~~~~~~~~~~\n+Options with long option names can be negated by prefixing `\"--no-\"`. For\n+example, `\"git branch\"` has the option `\"--track\"` which is 'on' by default. You\n+can use `\"--no-track\"` to override that behaviour. The same goes for `\"--color\"`\n+and `\"--no-color\"`.\n+\n+\n+Aggregating short options\n+~~~~~~~~~~~~~~~~~~~~~~~~~\n+Commands that support the enhanced option parser allow you to aggregate short\n+options. This means that you can for example use `\"git rm -rf\"` or\n+`\"git clean -fdx\"`.\n+\n+\n+Separating argument from the option\n+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n+You can write the mandatory option parameter to an option as a separate\n+word on the command line.  That means that all the following uses work:\n+\n+----------------------------\n+$ git foo --long-opt=Arg\n+$ git foo --long-opt Arg\n+$ git foo -oArg\n+$ git foo -o Arg\n+----------------------------\n+\n+However, this is *NOT* allowed for switches with an optionnal value, where the\n+'sticked' form must be used:\n+----------------------------\n+$ git describe --abbrev HEAD     # correct\n+$ git describe --abbrev=10 HEAD  # correct\n+$ git describe --abbrev 10 HEAD  # NOT WHAT YOU MEANT\n+----------------------------\n+\n+\n+Documentation\n+-------------\n+Documentation by Pierre Habouzit.\n+\n+GIT\n+---\n+Part of the gitlink:git[7] suite\ndiff --git a/Makefile b/Makefile\nindex b635be8..dd6c0d6 100644\n--- a/Makefile\n+++ b/Makefile\n@@ -1173,6 +1173,7 @@ check-docs::\n \t\tdocumented,gitattributes | \\\n \t\tdocumented,gitignore | \\\n \t\tdocumented,gitmodules | \\\n+\t\tdocumented,gitcli | \\\n \t\tdocumented,git-tools | \\\n \t\tsentinel,not,matching,is,ok ) continue ;; \\\n \t\tesac; \\\n-- \n1.5.4.rc1.1096.g37c7b\n"},{"id":"63931","messageId":"7vd4t0atzo.fsf@gitster.siamese.dyndns.org","threadId":"11376","inReplyTo":"20071221105058.GD17701@artemis.madism.org","subject":"Re: [PATCH] git-tag: fix -l switch handling regression.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-12-21T16:32:43Z","receivedAt":"2007-12-21T16:32:43Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Pierre Habouzit <madcoder@debian.org> writes:\n\n> Signed-off-by: Pierre Habouzit <madcoder@debian.org>\n> ---\n>\n> It seems that you didnt took that patch either, that IMHO gives a better\n> semantics to git tag -l than yours, while keeping backward\n> compatibility.\n\nI thought this depended on some other changes.  As is, doesn't\nit break the t7004 test?\n"},{"id":"63954","messageId":"20071221211833.GA10318@artemis.madism.org","threadId":"11376","inReplyTo":"7vd4t0atzo.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] git-tag: fix -l switch handling regression.","fromName":"Pierre Habouzit","fromEmail":"madcoder@debian.org","sentAt":"2007-12-21T21:18:33Z","receivedAt":"2007-12-21T21:18:33Z","isPatch":true,"sender":{"key":"madcoder@debian.org","avatar":"https://avatars.githubusercontent.com/u/44708?v=4"},"body":"On Fri, Dec 21, 2007 at 04:32:43PM +0000, Junio C Hamano wrote:\n> Pierre Habouzit <madcoder@debian.org> writes:\n> \n> > Signed-off-by: Pierre Habouzit <madcoder@debian.org>\n> > ---\n> >\n> > It seems that you didnt took that patch either, that IMHO gives a better\n> > semantics to git tag -l than yours, while keeping backward\n> > compatibility.\n> \n> I thought this depended on some other changes.  As is, doesn't\n> it break the t7004 test?\n\n  Well there are tests that test:\n\n  git tag -n xxx -l ...\n\n  or\n\n  git tag -n \"\" -l ...\n\n  but I think we agreed those test nothing legitimate, and that the\ntests have to be removed. SO yes it hides another patch to cleanse t7004\nfrom the broken tests.\n-- \n·O·  Pierre Habouzit\n··O                                                madcoder@debian.org\nOOO                                                http://www.madism.org\n"},{"id":"63984","messageId":"7vy7bnyx7w.fsf@gitster.siamese.dyndns.org","threadId":"11376","inReplyTo":"20071221211833.GA10318@artemis.madism.org","subject":"Re: [PATCH] git-tag: fix -l switch handling regression.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-12-22T08:01:23Z","receivedAt":"2007-12-22T08:01:23Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Pierre Habouzit <madcoder@debian.org> writes:\n\n> On Fri, Dec 21, 2007 at 04:32:43PM +0000, Junio C Hamano wrote:\n> ...\n>> I thought this depended on some other changes.  As is, doesn't\n>> it break the t7004 test?\n>\n>   Well there are tests that test:\n>\n>   git tag -n xxx -l ...\n>\n>   or\n>\n>   git tag -n \"\" -l ...\n>\n>   but I think we agreed those test nothing legitimate, and that the\n> tests have to be removed. SO yes it hides another patch to cleanse t7004\n> from the broken tests.\n\nThanks for a clarification; I'll resurect parts of my test\nfix-ups and squash that in.\n"},{"id":"63998","messageId":"Pine.LNX.4.64.0712221554030.14355@wbgn129.biozentrum.uni-wuerzburg.de","threadId":"11376","inReplyTo":"8bd0f97a0712210109q7805d967sc9b4cd13d4131360@mail.gmail.com","subject":"Re: 1.5.4-rc2 plans","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-12-22T15:04:50Z","receivedAt":"2007-12-22T15:04:50Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 21 Dec 2007, Mike Frysinger wrote:\n\n> ive started to transition from using svn everywhere to trying out git, \n> and saw reference to this \"stash\" command on another list.  i wanted to \n> learn more about it, so i started off with `git-stash` to get some info, \n> and wondered what just happened.  then i typoed the --help option and \n> wondered even more what just happened :).\n\nI'm very sorry for you, but I, for one, refuse to let decisions be \ninfluenced by people who did not have so much as a glimpse in the \ndocumentation.\n\nIt may be okay for a certain nation state to award people spilling that \nhot coffee that they ordered over there laps, but the rest of the world \nlaughs about such a behaviour.\n\nIf you got rope, stuck your neck through the noose, and jumped, without \nreading the manual first, well, that's not my problem.\n\nBut I guess that we'll get that no-default-action behaviour, and I will \nhave to change my ways.  Sigh.\n\nCiao,\nDscho\n"},{"id":"63999","messageId":"Pine.LNX.4.64.0712221605040.14355@wbgn129.biozentrum.uni-wuerzburg.de","threadId":"11376","inReplyTo":"7vwsr8lwf7.fsf@gitster.siamese.dyndns.org","subject":"Re: 1.5.4-rc2 plans","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-12-22T15:05:32Z","receivedAt":"2007-12-22T15:05:32Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 20 Dec 2007, Junio C Hamano wrote:\n\n>  * Introduction of \"<tree>:./path\" (Dscho).  I could be talked into\n>    accepting the patch if it is useful to people who live deep within\n>    subdirectories.\n\nIMHO this can safely await post-1.5.4.\n\nCiao,\nDscho\n"},{"id":"64003","messageId":"20071222170315.GB23262@artemis.madism.org","threadId":"11376","inReplyTo":"7vwsr8lwf7.fsf@gitster.siamese.dyndns.org","subject":"Re: 1.5.4-rc2 plans","fromName":"Pierre Habouzit","fromEmail":"madcoder@debian.org","sentAt":"2007-12-22T17:03:15Z","receivedAt":"2007-12-22T17:03:15Z","isPatch":false,"sender":{"key":"madcoder@debian.org","avatar":"https://avatars.githubusercontent.com/u/44708?v=4"},"body":"On ven, déc 21, 2007 at 12:32:28 +0000, Junio C Hamano wrote:\n> I've tagged -rc1 last night.  The changes are mostly fixes.  There are\n> some remaining issues I'd like to see fixed/decided before 1.5.4.\n> \n> One important issue is to identify and fix regressions since 1.5.3\n> series.  No \"rewrite scripted git-foo completely in C\" can be regression\n> free, and we had quite a few internal changes during 1.5.4 cycle (not\n> just rewrite to C, but C level uses new and improved API such as strbuf\n> and parse-options).  Currently I am aware of these regressions:\n> \n>  * handling of options, \"--abbrev 10 HEAD\", \"--abbrev=10 HEAD\" and\n>    \"--abbrev HEAD\".  The last one does not work for commands that use\n>    parse-options.  Pierre is on top of this, I hope.\n\n  About that, I know we talked about the -default thing and so on, I'm\nnot sure we should hurry that for 1.5.4 for the following reasons:\n\n  * I grepped through the source and the _sole_ instance of\n    parse-options enabled option arguments are  --abbrev ones for now\n    (even in the shell scripts migrated to git rev-parse --parseopt).\n\n  * Not adding *-default and lax parsing for optional arguments is _not_\n    a regression for the migrated commands.\n\n  * I don't want to urge that because well, I still have the hope we\n    could come up with something even better.\n\n  So I'd argue in favor of that:\n  + push the patch that forces the stuck forms (that I already posted)\n    for 1.5.4.\n  + prepare a series in pu with *-default post 1.5.4 to evaluate this\n    and see what people think.\n\n  Most of the function with optional arguments are the git diff ones,\nand we'll see about them post 1.5.4 anyways.\n-- \n·O·  Pierre Habouzit\n··O                                                madcoder@debian.org\nOOO                                                http://www.madism.org\n"},{"id":"64004","messageId":"7vir2qy7ie.fsf@gitster.siamese.dyndns.org","threadId":"11376","inReplyTo":"20071222170315.GB23262@artemis.madism.org","subject":"Re: 1.5.4-rc2 plans","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-12-22T17:16:41Z","receivedAt":"2007-12-22T17:16:41Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Pierre Habouzit <madcoder@debian.org> writes:\n\n>   So I'd argue in favor of that:\n>   + push the patch that forces the stuck forms (that I already posted)\n>     for 1.5.4.\n\nOk, sounds sane.  You posted multiple serieses; which ones?\n"},{"id":"64007","messageId":"20071222173849.GC23262@artemis.madism.org","threadId":"11376","inReplyTo":"7vir2qy7ie.fsf@gitster.siamese.dyndns.org","subject":"Re: 1.5.4-rc2 plans","fromName":"Pierre Habouzit","fromEmail":"madcoder@debian.org","sentAt":"2007-12-22T17:38:49Z","receivedAt":"2007-12-22T17:38:49Z","isPatch":false,"sender":{"key":"madcoder@debian.org","avatar":"https://avatars.githubusercontent.com/u/44708?v=4"},"body":"On Sat, Dec 22, 2007 at 05:16:41PM +0000, Junio C Hamano wrote:\n> Pierre Habouzit <madcoder@debian.org> writes:\n> \n> >   So I'd argue in favor of that:\n> >   + push the patch that forces the stuck forms (that I already posted)\n> >     for 1.5.4.\n> \n> Ok, sounds sane.  You posted multiple serieses; which ones?\n\nAll the patches I think should go in 1.5.4 are in that very thread.\nForcing the stuck forms for optional arguments is in\nMessage-Id: <20071221104704.GC17701@artemis.madism.org>, or is on\ngit.madism.org in branch ph/parseopt.\n\n-- \n·O·  Pierre Habouzit\n··O                                                madcoder@debian.org\nOOO                                                http://www.madism.org\n"},{"id":"64008","messageId":"7vejdey5ur.fsf@gitster.siamese.dyndns.org","threadId":"11376","inReplyTo":"7vir2qy7ie.fsf@gitster.siamese.dyndns.org","subject":"Re: 1.5.4-rc2 plans","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-12-22T17:52:28Z","receivedAt":"2007-12-22T17:52:28Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> Pierre Habouzit <madcoder@debian.org> writes:\n>\n>>   So I'd argue in favor of that:\n>>   + push the patch that forces the stuck forms (that I already posted)\n>>     for 1.5.4.\n>\n> Ok, sounds sane.  You posted multiple serieses; which ones?\n\nAh, my apologies.  I can fetch them from your git repository at\nmadism.org, of course.\n"},{"id":"64009","messageId":"8bd0f97a0712220954v54dd31c3j19d8835b8813a742@mail.gmail.com","threadId":"11376","inReplyTo":"Pine.LNX.4.64.0712221554030.14355@wbgn129.biozentrum.uni-wuerzburg.de","subject":"Re: 1.5.4-rc2 plans","fromName":"Mike Frysinger","fromEmail":"vapier.adi@gmail.com","sentAt":"2007-12-22T17:54:04Z","receivedAt":"2007-12-22T17:54:04Z","isPatch":false,"sender":{"key":"vapier.adi@gmail.com","avatar":null},"body":"On Dec 22, 2007 10:04 AM, Johannes Schindelin\n<Johannes.Schindelin@gmx.de> wrote:\n> On Fri, 21 Dec 2007, Mike Frysinger wrote:\n> > ive started to transition from using svn everywhere to trying out git,\n> > and saw reference to this \"stash\" command on another list.  i wanted to\n> > learn more about it, so i started off with `git-stash` to get some info,\n> > and wondered what just happened.  then i typoed the --help option and\n> > wondered even more what just happened :).\n>\n> I'm very sorry for you, but I, for one, refuse to let decisions be\n> influenced by people who did not have so much as a glimpse in the\n> documentation.\n>\n> <snip pointless garbage>\n\nwhy do you insist on wasting people's time if your point is merely to\ninsult ?  if that is your goal, go somewhere else.\n-mike\n"}]}