{"push_id":587969578,"size":124,"distinct_size":3,"ref":"refs/heads/jk/stash-apply-p-wip","head":"65d0963e4d629fc064c9739b6d55a716855fe6eb","before":"8447c31ca0ebcf66230b9cd8075407de79da4396","commits":[{"sha":"1f23cfe0ef5b2634a7b911a8b6dc4eff7f78ba5d","author":{"email":"b57189c5f2fd5b3daf3350a77fde90def1080fa5@gmail.com","name":"Jonathan Nieder"},"message":"doc: document error handling functions and conventions\n\nSigned-off-by: Jonathan Nieder <jrnieder@gmail.com>\nSigned-off-by: Junio C Hamano <gitster@pobox.com>","distinct":false,"url":"https://api.github.com/repos/peff/git/commits/1f23cfe0ef5b2634a7b911a8b6dc4eff7f78ba5d"},{"sha":"aa7710e064a9ee644e1e86bd6f89193200ac4ccd","author":{"email":"024f400cd820cb2ddbe54c7fecfd01e45f30bb96@gmail.com","name":"Nguyễn Thái Ngọc Duy"},"message":"attr.c: rename arg name attr_nr to avoid shadowing the global one\n\nHelped-by: Junio C Hamano <gitster@pobox.com>\nSigned-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>\nSigned-off-by: Junio C Hamano <gitster@pobox.com>","distinct":false,"url":"https://api.github.com/repos/peff/git/commits/aa7710e064a9ee644e1e86bd6f89193200ac4ccd"},{"sha":"fad32bcd83ec4e4f88013e4a0b05f42e32e2c6f5","author":{"email":"024f400cd820cb2ddbe54c7fecfd01e45f30bb96@gmail.com","name":"Nguyễn Thái Ngọc Duy"},"message":"attr: do not attempt to expand when we know it's not a macro\n\nKeep track of all recognized macros in the new \"maybe_macro\" field.\nIf this field is true, it _may_ be a macro (depending on what's in the\ncurrent attr stack). But if the field is false, it's definitely not a\nmacro, no need to go through the whole attr stack in macroexpand_one()\nto search for one.\n\nWithout this, \"git grep abcdefghi\" on git.git hits the inner loop in\nmacroexpand_one() 2481 times. With this, it's 66 times.\n\nHelped-by: Eric Sunshine <sunshine@sunshineco.com>\nSigned-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>\nSigned-off-by: Junio C Hamano <gitster@pobox.com>","distinct":false,"url":"https://api.github.com/repos/peff/git/commits/fad32bcd83ec4e4f88013e4a0b05f42e32e2c6f5"},{"sha":"06a604e67051b9342c158432a49e42a5440f9280","author":{"email":"024f400cd820cb2ddbe54c7fecfd01e45f30bb96@gmail.com","name":"Nguyễn Thái Ngọc Duy"},"message":"attr: avoid heavy work when we know the specified attr is not defined\n\nIf we have never seen attr 'X' in any .gitattributes file we have\nexamined so far, we can be sure that 'X' is not defined. So no need to\ngo over all the attr stack to look for attr 'X'. This is the purpose\nbehind this new field maybe_real.\n\nThis optimization breaks down if macros are involved because we can't\nknow for sure what macro would expand to 'X' at attr parsing time. But\nif we go the pessimistic way and assume all macros are expanded, we hit\nthe builtin \"binary\" macro. At least the \"diff\" attr defined in this\nmacro will disable this optimization for git-grep. So we wait until\nany attr lines _may_ reference to a macro before we turn this off.\n\nIn git.git, this reduces the number of fill_one() call for \"git grep\nabcdefghi\" from ~5348 to 2955. The optimization stops when it reads\nt/.gitattributes, which uses 'binary' macro. We could probably reduce\nit further by limiting the 'binary' reference to t/ and subdirs only\nin this case.\n\n\"git grep\" is actually a good example to justify this patch. The\ncommand checks \"diff\" attribute on every file. People usually don't\ndefine this attribute. But they pay the attr lookup penalty anyway\nwithout this patch, proportional to the number of attr lines they have\nin repo.\n\nHelped-by: Junio C Hamano <gitster@pobox.com>\nSigned-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>\nSigned-off-by: Junio C Hamano <gitster@pobox.com>","distinct":false,"url":"https://api.github.com/repos/peff/git/commits/06a604e67051b9342c158432a49e42a5440f9280"},{"sha":"1767c51787f2a9aaf99716a48e8928618c1c9481","author":{"email":"696e3fbcf235d40b6ea1ebd61c87cbea79d444e7@peff.net","name":"Jeff King"},"message":"t/lib-httpd: switch SANITY check for NOT_ROOT\n\nThe SANITY prerequisite is really about whether the\nfilesystem will respect the permissions we set, and being\nroot is only one part of that. But the httpd tests really\njust care about not being root, as they are trying to avoid\nweirdness in apache (see a1a3011 for details).\n\nLet's switch out SANITY for a new NOT_ROOT prerequisite,\nwhich will let us tweak SANITY more freely.\n\nWe implement NOT_ROOT by checking `id -u`, which is in POSIX\nand seems to be available even on MSYS.  Note that we cannot\njust call this \"ROOT\" and ask for \"!ROOT\". The possible\noutcomes are:\n\n  1. we know we are root\n\n  2. we know we are not root\n\n  3. we could not tell, because `id` was not available\n\nWe should conservatively treat (3) as \"does not have the\nprerequisite\", which means that a naive negation would not\nwork.\n\nHelped-by: Kyle J. McKay <mackyle@gmail.com>\nSigned-off-by: Jeff King <peff@peff.net>\nSigned-off-by: Junio C Hamano <gitster@pobox.com>","distinct":false,"url":"https://api.github.com/repos/peff/git/commits/1767c51787f2a9aaf99716a48e8928618c1c9481"},{"sha":"eae69530ae3915d54f660d56cc3f92dd6bed03ae","author":{"email":"a6723cc3f76163bf7adb636a73ac3b0ceb3e6b9b@pobox.com","name":"Junio C Hamano"},"message":"tests: correct misuses of POSIXPERM\n\nPOSIXPERM requires that a later call to stat(2) (hence \"ls -l\")\nfaithfully reproduces what an earlier chmod(2) did.  Some\nfilesystems cannot satisify this.\n\nSANITY requires that a file or a directory is indeed accessible (or\ninaccessible) when its permission bits would say it ought to be\naccessible (or inaccessible).  Running tests as root would lose this\nprerequisite for obvious reasons.\n\nFix a few tests that misuse POSIXPERM.\n\nt0061-run-command.sh has two uses of POSIXPERM.\n\n - One checks that an attempt to execute a file that is marked as\n   unexecutable results in a failure with EACCES; I do not think\n   having root-ness or any other capability that busts the\n   filesystem permission mode bits will make you run an unexecutable\n   file, so this should be left as-is.  The test does not have\n   anything to do with SANITY.\n\n - The other one expects 'git nitfol' runs the alias when an\n   alias.nitfol is defined and a directory on the PATH is marked as\n   unreadable and unsearchable.  I _think_ the test tries to reject\n   the alternative expectation that we want to refuse to run the\n   alias because it would break \"no alias may mask a command\" rule\n   if a file 'git-nitfol' exists in the unreadable directory but we\n   cannot even determine if that is the case.  Under !SANITY that\n   busts the permission bits, this test no longer checks that, so it\n   must be protected with SANITY.\n\nt1509-root-worktree.sh expects to be run on a / that is writable by\nthe user and sees if Git behaves \"sensibly\" when /.git is the\nrepository to govern a worktree that is the whole filesystem, and\nalso if Git behaves \"sensibly\" when / itself is a bare repository\nwith refs, objects, and friends (I find the definition of \"behaves\nsensibly\" under these conditions hard to fathom, but it is a\ndifferent matter).\n\nThe implementation of the test is very much problematic.\n\n - It requires POSIXPERM, but it does not do chmod or checks modes\n   in any way.\n\n - It runs \"rm /*\" and \"rm -fr /refs /objects ...\" in one of the\n   tests, and also does \"cd / && git init --bare\".  If done on a\n   live system that takes advantages of the \"feature\" being tested,\n   these obviously will clobber the system.  But there is no guard\n   against such a breakage.\n\n - It uses \"test $UID = 0\" to see rootness, which now should be\n   spelled \"! test_have_prereq NOT_ROOT\"\n\nSigned-off-by: Junio C Hamano <gitster@pobox.com>","distinct":false,"url":"https://api.github.com/repos/peff/git/commits/eae69530ae3915d54f660d56cc3f92dd6bed03ae"},{"sha":"bdfdaa4978dd92992737e662f25adc01d32d0774","author":{"email":"696e3fbcf235d40b6ea1ebd61c87cbea79d444e7@peff.net","name":"Jeff King"},"message":"strbuf.h: integrate api-strbuf.txt documentation\n\nSome of strbuf is documented as comments above functions,\nand some is separate in Documentation/technical/api-strbuf.txt.\nThis makes it annoying to find the appropriate documentation.\nWe'd rather have it all in one place, which means all in the\ntext document, or all in the header.\n\nLet's choose the header as that place. Even though the\nformatting is not quite as pretty, this keeps the\ndocumentation close to the related code.  The hope is that\nthis makes it easier to find what you want (human-readable\ncomments are right next to the C declarations), and easier\nfor writers to keep the documentation up to date.\n\nThis is more or less a straight import of the text from\napi-strbuf.txt into C comments, complete with asciidoc\nformatting. The exceptions are:\n\n 1. All comments created in this way are started with \"/**\"\n    to indicate they are part of the API documentation. This\n    may help later with extracting the text to pretty-print\n    it.\n\n 2. Function descriptions do not repeat the function name,\n    as it is available in the context directly below.  So:\n\n      `strbuf_add`::\n\n          Add data of given length to the buffer.\n\n    from api-strbuf.txt becomes:\n\n      /**\n       * Add data of given length to the buffer.\n       */\n      void strbuf_add(struct strbuf *sb, const void *, size_t);\n\n    As a result, any block-continuation required in asciidoc\n    for that list item was dropped in favor of straight\n    blank-line paragraph (since it is not necessary when we\n    are not in a list item).\n\n 3. There is minor re-wording to integrate existing comments\n    and api-strbuf text. In each case, I took whichever\n    version was more descriptive, and eliminated any\n    redundancies. In one case, for strbuf_addstr, the api\n    documentation gave its inline definition; I eliminated\n    this as redundant with the actual definition, which can\n    be seen directly below the comment.\n\n 4. The functions in the header file are re-ordered to match\n    the ordering of the API documentation, under the\n    assumption that more thought went into the grouping\n    there.\n\nHelped-by: Jonathan Nieder <jrnieder@gmail.com>\nSigned-off-by: Jeff King <peff@peff.net>\nSigned-off-by: Junio C Hamano <gitster@pobox.com>","distinct":false,"url":"https://api.github.com/repos/peff/git/commits/bdfdaa4978dd92992737e662f25adc01d32d0774"},{"sha":"6afbbdda3339349feae91161f4e530d511c4db76","author":{"email":"a7f3b1612c245dae606b3b9617b4f52187fddb65@google.com","name":"Stefan Beller"},"message":"strbuf.h: unify documentation comments beginnings\n\nThe prior patch uses \"/**\" to denote \"documentation\"\ncomments that we pulled from api-strbuf.txt. Let's use a\nconsistent style for similar comments that were already in\nstrbuf.h.\n\nSigned-off-by: Stefan Beller <sbeller@google.com>\nSigned-off-by: Jeff King <peff@peff.net>\nSigned-off-by: Junio C Hamano <gitster@pobox.com>","distinct":false,"url":"https://api.github.com/repos/peff/git/commits/6afbbdda3339349feae91161f4e530d511c4db76"},{"sha":"aa07cac43fb03a01bcbcdffdaa49bf72a9eb06d1","author":{"email":"696e3fbcf235d40b6ea1ebd61c87cbea79d444e7@peff.net","name":"Jeff King"},"message":"strbuf.h: drop asciidoc list formatting from API docs\n\nUsing a hanging indent is much more readable. This means we\nwon't format as asciidoc anymore, but since we don't have a\nworking system for extracting these comments anyway, it's\nprobably more important to just make the source readable.\n\nSigned-off-by: Jeff King <peff@peff.net>\nSigned-off-by: Junio C Hamano <gitster@pobox.com>","distinct":false,"url":"https://api.github.com/repos/peff/git/commits/aa07cac43fb03a01bcbcdffdaa49bf72a9eb06d1"},{"sha":"088c9a86ff5332ee15415be3408ccf34687bc2d2","author":{"email":"696e3fbcf235d40b6ea1ebd61c87cbea79d444e7@peff.net","name":"Jeff King"},"message":"strbuf.h: format asciidoc code blocks as 4-space indent\n\nThis is much easier to read when the whole thing is stuffed\ninside a comment block. And there is precedent for this\nconvention in markdown (and just in general ascii text).\n\nSigned-off-by: Jeff King <peff@peff.net>\nSigned-off-by: Junio C Hamano <gitster@pobox.com>","distinct":false,"url":"https://api.github.com/repos/peff/git/commits/088c9a86ff5332ee15415be3408ccf34687bc2d2"},{"sha":"14e2177a40ca5861f0518cb6bbe0a6856ffa7552","author":{"email":"696e3fbcf235d40b6ea1ebd61c87cbea79d444e7@peff.net","name":"Jeff King"},"message":"strbuf.h: reorganize api function grouping headers\n\nThe original API doc had something like:\n\n    Functions\n    ---------\n\n    * Life cycle\n\n      ... some life-cycle functions ...\n\n    * Related to the contents of the buffer\n\n      ... functions related to contents ....\n\n    etc\n\nThis grouping can be hard to read in the comment sources,\ngiven the \"*\" in the comment lines, and the amount of text\nbetween each section.\n\nInstead, let's make a flat list of groupings, and underline\neach as a section header. That makes them stand out, and\neliminates the weird half-phrase of \"Related to...\". Like:\n\n    Functions related to the contents of the buffer\n    -----------------------------------------------\n\nSigned-off-by: Jeff King <peff@peff.net>\nSigned-off-by: Junio C Hamano <gitster@pobox.com>","distinct":false,"url":"https://api.github.com/repos/peff/git/commits/14e2177a40ca5861f0518cb6bbe0a6856ffa7552"},{"sha":"f20e56e202fa2a6cd3faa1710ed9f600ba58ce1d","author":{"email":"696e3fbcf235d40b6ea1ebd61c87cbea79d444e7@peff.net","name":"Jeff King"},"message":"strbuf.h: drop boilerplate descriptions of strbuf_split_*\n\nThe description of strbuf_split_buf says most of what\nneeds to be said for all of the split variants that take\nstrings, raw memory, etc. We have a boilerplate comment\nabove each that points to the first. This boilerplate\nends up making it harder to read, because it spaces out the\nfunctions, which could otherwise be read as a group.\n\nLet's drop the boilerplate completely, and mention the\nvariants in the top comment. This is perhaps slightly worse\nfor a hypothetical system which pulls the documentation for\neach function out of the comment immediately preceding it.\nBut such a system does not yet exist, and anyway, the end\nresult of extracting the boilerplate comments would not lead\nto a very easy-to-read result.  We would do better in the\nlong run to teach the extraction system about groups of\nrelated functions.\n\nSigned-off-by: Jeff King <peff@peff.net>\nSigned-off-by: Junio C Hamano <gitster@pobox.com>","distinct":false,"url":"https://api.github.com/repos/peff/git/commits/f20e56e202fa2a6cd3faa1710ed9f600ba58ce1d"},{"sha":"d468fa2721d1ff918c0991e9e1f762872b3f82ae","author":{"email":"696e3fbcf235d40b6ea1ebd61c87cbea79d444e7@peff.net","name":"Jeff King"},"message":"strbuf.h: group documentation for trim functions\n\nThe relationship between these makes more sense if you read\nthem as a group, which can help people who are looking for\nthe right function. Let's give them a single comment.\n\nSigned-off-by: Jeff King <peff@peff.net>\nSigned-off-by: Junio C Hamano <gitster@pobox.com>","distinct":false,"url":"https://api.github.com/repos/peff/git/commits/d468fa2721d1ff918c0991e9e1f762872b3f82ae"},{"sha":"33cae5428ab504e318cfac880d59e0bda58590d7","author":{"email":"9904419133015298990973ad253a390ae1d3133a@glandium.org","name":"Mike Hommey"},"message":"transport-helper: do not request symbolic refs to remote helpers\n\nA typical remote helper will return a `list` of refs containing a symbolic\nref HEAD, pointing to, e.g. refs/heads/master. In the case of a clone, all\nthe refs are being requested through `fetch` or `import`, including the\nsymbolic ref.\n\nWhile this works properly, in some cases of a fetch, like `git fetch url`\nor `git fetch origin HEAD`, or any fetch command involving a symbolic ref\nwithout also fetching the corresponding ref it points to, the fetch command\nfails with:\n\n  fatal: bad object 0000000000000000000000000000000000000000\n  error: <remote> did not send all necessary objects\n\n(in the case the remote helper returned '?' values to the `list` command).\n\nThis is because there is only one ref given to fetch(), and it's not\nfurther resolved to something at the end of fetch_with_import().\n\nWhile this can be somehow handled in the remote helper itself, by adding\na refspec for the symbolic ref, and storing an explicit ref in a private\nnamespace, and then handling the `import` for that symbolic ref\nspecifically, very few existing remote helpers are actually doing that.\n\nSo, instead of requesting the exact list of wanted refs to remote helpers,\ntreat symbolic refs differently and request the ref they point to instead.\nThen, resolve the symbolic refs values based on the pointed ref.\nThis assumes there is no more than one level of indirection (a symbolic\nref doesn't point to another symbolic ref).\n\nSigned-off-by: Mike Hommey <mh@glandium.org>\nSigned-off-by: Junio C Hamano <gitster@pobox.com>","distinct":false,"url":"https://api.github.com/repos/peff/git/commits/33cae5428ab504e318cfac880d59e0bda58590d7"},{"sha":"edb72d551128f798f5f43292789cb7c731d1e01f","author":{"email":"eec72676ad9a62f2727dfed6d270d98c0d02adec@linux.intel.com","name":"Kirill A. Shutemov"},"message":"rebase -i: use full object name internally throughout the script\n\nIn earlier days, the abbreviated commit object name shown to the end\nusers were generated with hardcoded --abbrev=7; 56895038 (rebase\n-i: respect core.abbrev, 2013-09-28) tried to make it honor the user\nspecified core.abbrev, but it missed the very initial invocation of\nthe editor.\n\nThese days, we try to use the full 40-hex object names internally to\navoid ambiguity that can arise after rebase starts running.  Newly\ncreated objects during the rebase may share the same prefix with\nexisting commits listed in the insn sheet.  These object names are\nshortened just before invoking the sequence editor to present the\ninsn sheet to the end user, and then expanded back to full object\nnames when the editor returns.\n\nBut the code still used the shortened names when preparing the insn\nsheet for the very first time, resulting \"7 hexdigits or more\"\noutput to the user.  Change the code to use full 40-hex commit\nobject names from the very beginning to make things more uniform.\n\nSigned-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>\nSigned-off-by: Junio C Hamano <gitster@pobox.com>","distinct":false,"url":"https://api.github.com/repos/peff/git/commits/edb72d551128f798f5f43292789cb7c731d1e01f"},{"sha":"923fc5ab4017801078a54310f94fd95c28b91ce0","author":{"email":"a6723cc3f76163bf7adb636a73ac3b0ceb3e6b9b@pobox.com","name":"Junio C Hamano"},"message":"apply.c: typofix\n\nSigned-off-by: Junio C Hamano <gitster@pobox.com>","distinct":false,"url":"https://api.github.com/repos/peff/git/commits/923fc5ab4017801078a54310f94fd95c28b91ce0"},{"sha":"2988289f2c5764605105037bfcb12f85b9971cf9","author":{"email":"a6723cc3f76163bf7adb636a73ac3b0ceb3e6b9b@pobox.com","name":"Junio C Hamano"},"message":"apply: make update_pre_post_images() sanity check the given postlen\n\n\"git apply --whitespace=fix\" used to be able to assume that fixing\nerrors will always reduce the size by e.g. stripping whitespaces at\nthe end of lines or collapsing runs of spaces into tabs at the\nbeginning of lines.  An update to accomodate fixes that lengthens\nthe result by e.g. expanding leading tabs into spaces were made long\ntime ago but the logic miscounted the necessary space after such\nwhitespace fixes, leading to either under-allocation or over-usage\nof already allocated space.\n\nIllustrate this with a runtime sanity-check to protect us from\nfuture breakage.  The test was stolen from Kyle McKay who helped\nto identify the problem.\n\nHelped-by: \"Kyle J. McKay\" <mackyle@gmail.com>\nSigned-off-by: Junio C Hamano <gitster@pobox.com>","distinct":false,"url":"https://api.github.com/repos/peff/git/commits/2988289f2c5764605105037bfcb12f85b9971cf9"},{"sha":"407a792ef7e3c142a47c6b09a80f9ede4e14f444","author":{"email":"a6723cc3f76163bf7adb636a73ac3b0ceb3e6b9b@pobox.com","name":"Junio C Hamano"},"message":"apply: count the size of postimage correctly\n\nUnder --whitespace=fix option, match_fragment() function examines\nthe preimage (the common context and the removed lines in the patch)\nand the file being patched and checks if they match after correcting\nall whitespace errors.  When they are found to match, the common\ncontext lines in the preimage is replaced with the fixed copy,\nbecause these lines will then be copied to the corresponding place\nin the postimage by a later call to update_pre_post_images().  Lines\nthat are added in the postimage, under --whitespace=fix, have their\nwhitespace errors already fixed when apply_one_fragment() prepares\nthe preimage and the postimage, so in the end, application of the\npatch can be done by replacing the block of text in the file being\npatched that matched the preimage with what is in the postimage that\nwas updated by update_pre_post_images().\n\nIn the earlier days, fixing whitespace errors always resulted in\nreduction of size, either collapsing runs of spaces in the indent to\na tab or removing the trailing whitespaces.  These days, however,\nsome whitespace error fix results in extending the size.\n\n250b3c6c (apply --whitespace=fix: avoid running over the postimage\nbuffer, 2013-03-22) tried to compute the final postimage size but\nits math was flawed.  It counted the size of the block of text in\nthe original being patched after fixing the whitespace errors on its\nlines that correspond to the preimage.  That number does not have\nmuch to do with how big the final postimage would be.\n\nInstead count (1) the added lines in the postimage, whose size is\nthe same as in the final patch result because their whitespace\nerrors have already been corrected, and (2) the fixed size of the\nlines that are common.\n\nSigned-off-by: Junio C Hamano <gitster@pobox.com>","distinct":false,"url":"https://api.github.com/repos/peff/git/commits/407a792ef7e3c142a47c6b09a80f9ede4e14f444"},{"sha":"a9c4641df7989c9adf6af471705ebf735c35a92f","author":{"email":"1e54dc1c299571bb7a58e37a7ea31ffd91d38f4e@gmail.com","name":"Alexander Kuleshov"},"message":"add -i: return from list_and_choose if there is no candidate\n\nThe list_and_choose() helper is given a prompt and a list, asks the\nuser to make selection from the list, and then returns a list of\nitems chosen.  Even when it is given an empty list as the original\ncandidate set to choose from, it gave a prompt to the user, who can\nonly say \"I am done choosing\".\n\nReturn an empty result when the input is an empty list without\nbothering the user.  The existing caller must already have a logic\nto say \"Nothing to do\" or an equivalent when the returned list is\nempty (i.e. the user chose to select nothing) if it is necessary, so\nno change to the callers is necessary.\n\nThis fixes the case where \"add untracked\" is asked in \"git add -i\"\nand there is no untracked files in the working tree.  We used to give\nan empty list of files to choose from with a prompt, but with this\nchange, we no longer do.\n\nSigned-off-by: Alexander Kuleshov <kuleshovmail@gmail.com>\nSigned-off-by: Junio C Hamano <gitster@pobox.com>","distinct":false,"url":"https://api.github.com/repos/peff/git/commits/a9c4641df7989c9adf6af471705ebf735c35a92f"},{"sha":"3cab02de5087447e1c48ada03a0db0fffc89e920","author":{"email":"a6723cc3f76163bf7adb636a73ac3b0ceb3e6b9b@pobox.com","name":"Junio C Hamano"},"message":"Documentation: what does \"git log --indexed-objects\" even mean?\n\n4fe10219 (rev-list: add --indexed-objects option, 2014-10-16) adds\n\"--indexed-objects\" option to \"rev-list\", and it is only useful in\nthe context of \"git rev-list\" and not \"git log\".  There are other\nobject traversal options that do not make sense for \"git log\" that\nare shown in the manual page.\n\nMove the description of \"--indexed-objects\" to the object traversal\nsection so that it sits together with its friends \"--objects\",\n\"--objects-edge\", etc. and then show them only in \"git rev-list\"\ndocumentation.\n\nAcked-by: Jeff King <peff@peff.net>\nSigned-off-by: Junio C Hamano <gitster@pobox.com>","distinct":false,"url":"https://api.github.com/repos/peff/git/commits/3cab02de5087447e1c48ada03a0db0fffc89e920"}]}