{"thread":{"id":"51135","subject":"[PATCH 0/3] hash-object doc: small fixes","startedAt":"2019-05-20T21:53:24Z","lastAt":"2019-05-28T16:56:28Z","messageCount":12,"participants":["Ævar Arnfjörð Bjarmason","Jeff King","Jakub Narebski","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":3},"messages":[{"id":"375958","messageId":"20190520215312.10363-1-avarab@gmail.com","threadId":"51135","inReplyTo":null,"subject":"[PATCH 0/3] hash-object doc: small fixes","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2019-05-20T21:53:09Z","receivedAt":"2019-05-20T21:53:24Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"Small doc fixes. Maybe trivial enough to land in 2.22, but there's no\nrush.\n\nA pair of #leftoverbits I noticed is that we've implemented the\n\"--stdin-paths\" option via unquote_c_style() from day one, so our\ncurrent docs lie (and still do with this series) about wanting\n\\n-delimited files, you can't hash a file called '\"foo\"' as you'd\nexpect, you need to pass '\"\\\"foo\\\"\"'.\n\nI wonder if we should document this at this point, or just change it\nand add a \"-z\" option. None of our tests fail if I remove this\nunquote_c_style() codepath, and it's never been documented, but\nsomeone in the wild may have organically depended on it.\n\nÆvar Arnfjörð Bjarmason (3):\n hash-object doc: stop mentioning git-cvsimport\n hash-object doc: elaborate on -w and --literally promises\n hash-object doc: point to ls-files and rev-parse\n\n Documentation/git-hash-object.txt | 22 +++++++++++++++++-----\n 1 file changed, 17 insertions(+), 5 deletions(-)\n\n-- \n2.21.0.1020.gf2820cf01a\n\n"},{"id":"375959","messageId":"20190520215312.10363-2-avarab@gmail.com","threadId":"51135","inReplyTo":"20190520215312.10363-1-avarab@gmail.com","subject":"[PATCH 1/3] hash-object doc: stop mentioning git-cvsimport","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2019-05-20T21:53:10Z","receivedAt":"2019-05-20T21:53:27Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"Remove a reference to git-cvsimport in the intro. As can be seen from\nthe history of this command[1] it was originally intended for use with\ngit-cvsimport, but how it uses it (and that it uses it at all) is\nirrelevant trivia at this point.\n\n1. See 7672db20c2 (\"[PATCH] Expose object ID computation functions.\",\n 2005-07-08) and 8b8840e046 (\"[PATCH] cvsgit fixes: spaces in\n filenames and CVS server dialog woes\", 2005-08-15).\n\nSigned-off-by: Ævar Arnfjörð Bjarmason \n---\n Documentation/git-hash-object.txt | 4 +---\n 1 file changed, 1 insertion(+), 3 deletions(-)\n\ndiff --git a/Documentation/git-hash-object.txt b/Documentation/git-hash-object.txt\nindex 814e74406a..df9e2c58bd 100644\n--- a/Documentation/git-hash-object.txt\n+++ b/Documentation/git-hash-object.txt\n@@ -18,9 +18,7 @@ Computes the object ID value for an object with specified type\n with the contents of the named file (which can be outside of the\n work tree), and optionally writes the resulting object into the\n object database. Reports its object ID to its standard output.\n-This is used by 'git cvsimport' to update the index\n-without modifying files in the work tree. When is not\n-specified, it defaults to \"blob\".\n+When is not specified, it defaults to \"blob\".\n \n OPTIONS\n -------\n-- \n2.21.0.1020.gf2820cf01a\n\n"},{"id":"375960","messageId":"20190520215312.10363-3-avarab@gmail.com","threadId":"51135","inReplyTo":"20190520215312.10363-1-avarab@gmail.com","subject":"[PATCH 2/3] hash-object doc: elaborate on -w and --literally promises","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2019-05-20T21:53:11Z","receivedAt":"2019-05-20T21:53:29Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"Clarify the hash-object docs to explicitly note that the --literally\noption guarantees that a loose object will be written, but that a\nnormal -w (\"write\") invocation doesn't.\n\nAt first I thought talking about \"loose object\" in the docs was a\nmistake in 83115ac4a8 (\"git-hash-object.txt: document --literally\noption\", 2015-05-04), but as is clear from 5ba9a93b39 (\"hash-object:\nadd --literally option\", 2014-09-11) this was intended all along.\n\nAs seen in 4dd1fbc7b1 (\"Bigfile: teach \"git add\" to send a large file\nstraight to a pack\", 2011-05-08) we'll otherwise not guarantee that we\nwrite loose objects, so let's explicitly note that, using vague enough\nlanguage to leave the door open to any arbitrary future storage\nformat, not just loose objects and packs.\n\nWhile I'm at it remove the mention of \"--stdin\" from the \"--literally\"\ndocumentation. This wasn't correct, the \"--literally\" option combines\nwith any other option (e.g. \"--stdin-paths\"), not just \"--stdin\".\n\nSigned-off-by: Ævar Arnfjörð Bjarmason \n---\n Documentation/git-hash-object.txt | 11 +++++++++--\n 1 file changed, 9 insertions(+), 2 deletions(-)\n\ndiff --git a/Documentation/git-hash-object.txt b/Documentation/git-hash-object.txt\nindex df9e2c58bd..100630d021 100644\n--- a/Documentation/git-hash-object.txt\n+++ b/Documentation/git-hash-object.txt\n@@ -28,6 +28,12 @@ OPTIONS\n \n -w::\n \tActually write the object into the object database.\n++\n+No guarantees are made as to how the object is added to the database\n+(e.g. whether as a loose object, or streamed to a pack), except in the\n+case of the `--literally` option. How it's written may depend on\n+heuristics such as the `core.bigFileThreshold` configuration variable\n+(see linkgit:git-config[1]).\n \n --stdin::\n \tRead the object from standard input instead of from a file.\n@@ -53,10 +59,11 @@ OPTIONS\n \tis always implied, unless the `--path` option is given.\n \n --literally::\n-\tAllow `--stdin` to hash any garbage into a loose object which might not\n+\tAllow for hashing arbitrary data which might not\n \totherwise pass standard object parsing or git-fsck checks. Useful for\n \tstress-testing Git itself or reproducing characteristics of corrupt or\n-\tbogus objects encountered in the wild.\n+\tbogus objects encountered in the wild. When writing objects guarantees\n+\tthat the written object will be a loose object, for ease of debugging.\n \n GIT\n ---\n-- \n2.21.0.1020.gf2820cf01a\n\n"},{"id":"375961","messageId":"20190520215312.10363-4-avarab@gmail.com","threadId":"51135","inReplyTo":"20190520215312.10363-1-avarab@gmail.com","subject":"[PATCH 3/3] hash-object doc: point to ls-files and rev-parse","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2019-05-20T21:53:12Z","receivedAt":"2019-05-20T21:53:36Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"Amend the intro to note that it's better to ask the index about files\nalready tracked by it.\n\nI've seen uses of this in the wild where the use-case was finding\nobject IDs for files found in a freshly cloned repo, i.e. something\nlike \"git ls-files | git hash-object --stdin-paths\".\n\nSigned-off-by: Ævar Arnfjörð Bjarmason \n---\n Documentation/git-hash-object.txt | 7 +++++++\n 1 file changed, 7 insertions(+)\n\ndiff --git a/Documentation/git-hash-object.txt b/Documentation/git-hash-object.txt\nindex 100630d021..077d83ec65 100644\n--- a/Documentation/git-hash-object.txt\n+++ b/Documentation/git-hash-object.txt\n@@ -20,6 +20,13 @@ work tree), and optionally writes the resulting object into the\n object database. Reports its object ID to its standard output.\n When is not specified, it defaults to \"blob\".\n \n+This command won't take the shortcut of seeing if the path(s) to be\n+hashed are present in the index, in which case their already computed\n+object ID could be retrieved by linkgit:git-ls-files[1] via the\n+`--stage` option, or by linkgit:git-rev-parse[1]. Use those instead of\n+e.g. `--stdin-paths` if the intent is to say find the blob object IDs\n+of checked-out files.\n+\n OPTIONS\n -------\n \n-- \n2.21.0.1020.gf2820cf01a\n\n"},{"id":"376048","messageId":"20190522045704.GA29933@sigill.intra.peff.net","threadId":"51135","inReplyTo":"20190520215312.10363-2-avarab@gmail.com","subject":"Re: [PATCH 1/3] hash-object doc: stop mentioning git-cvsimport","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2019-05-22T04:57:04Z","receivedAt":"2019-05-22T04:57:07Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, May 20, 2019 at 11:53:10PM +0200, Ævar Arnfjörð Bjarmason wrote:\n\n> Remove a reference to git-cvsimport in the intro. As can be seen from\n> the history of this command[1] it was originally intended for use with\n> git-cvsimport, but how it uses it (and that it uses it at all) is\n> irrelevant trivia at this point.\n\nYeah, this is definitely obscuring the main point for most readers. The\npatch looks good.\n\n-Peff\n"},{"id":"376049","messageId":"20190522050839.GB29933@sigill.intra.peff.net","threadId":"51135","inReplyTo":"20190520215312.10363-3-avarab@gmail.com","subject":"Re: [PATCH 2/3] hash-object doc: elaborate on -w and --literally promises","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2019-05-22T05:08:39Z","receivedAt":"2019-05-22T05:08:42Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, May 20, 2019 at 11:53:11PM +0200, Ævar Arnfjörð Bjarmason wrote:\n\n> Clarify the hash-object docs to explicitly note that the --literally\n> option guarantees that a loose object will be written, but that a\n> normal -w (\"write\") invocation doesn't.\n\nI had to double-check here: you mean that _when_ we are writing an\nobject, \"--literally\" would always write loose, right?\n\n> At first I thought talking about \"loose object\" in the docs was a\n> mistake in 83115ac4a8 (\"git-hash-object.txt: document --literally\n> option\", 2015-05-04), but as is clear from 5ba9a93b39 (\"hash-object:\n> add --literally option\", 2014-09-11) this was intended all along.\n\nHmm. After reading both of those, I do think it's mostly an\nimplementation detail. I would not be at all surprised to find that the\ntest suite relies on this (e.g., cleaning up with rm\n.git/objects/ab/cd1234). But I suspect we also rely on that for the\nnon-literal case, too. ;)\n\nSo I am on the fence. In some sense it doesn't hurt to document the\nbehavior, but I'm not sure I would want to lock us in to any particular\nbehavior, even for --literally. The intent of the option (as I recall)\nreally is just \"let us write whatever trash we want as an object,\nignoring all quality checks\".\n\n> --literally::\n> -\tAllow `--stdin` to hash any garbage into a loose object which might not\n> +\tAllow for hashing arbitrary data which might not\n> \totherwise pass standard object parsing or git-fsck checks. Useful for\n> \tstress-testing Git itself or reproducing characteristics of corrupt or\n> -\tbogus objects encountered in the wild.\n> +\tbogus objects encountered in the wild. When writing objects guarantees\n> +\tthat the written object will be a loose object, for ease of debugging.\n\nI had to read this last sentence a few times to parse it. Maybe a comma\nbefore guarantees would help? Or even:\n\n When writing objects, this option guarantees that the written object\n will be a loose object, for ease of debugging.\n\n-Peff\n"},{"id":"376050","messageId":"20190522051523.GC29933@sigill.intra.peff.net","threadId":"51135","inReplyTo":"20190520215312.10363-4-avarab@gmail.com","subject":"Re: [PATCH 3/3] hash-object doc: point to ls-files and rev-parse","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2019-05-22T05:15:23Z","receivedAt":"2019-05-22T05:15:27Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, May 20, 2019 at 11:53:12PM +0200, Ævar Arnfjörð Bjarmason wrote:\n\n> Amend the intro to note that it's better to ask the index about files\n> already tracked by it.\n> \n> I've seen uses of this in the wild where the use-case was finding\n> object IDs for files found in a freshly cloned repo, i.e. something\n> like \"git ls-files | git hash-object --stdin-paths\".\n\nThis example left me scratching my head, because it seems like such a\nbad way to accomplish the goal that I had trouble figuring out what the\ngoal was in the first place.\n\nOf course I am pretty familiar with Git, so my mindset is not\nnecessarily the same as the average reader of the manpage. But the\nsuggested documentation really seems to me to be warning about a\nconvoluted use case that most people would not come up with in the first\nplace.\n\nAnd adding it in the introductory text means that people are more likely\nto read and be confused by it, when they are really just looking to find\ndetails on more mundane usage.\n\nOr put another way: I could come up with a hundred bad ways to script\nGit, but we are probably better off enumerating the _good_ ways to do\nso, rather than listing the bad ways and leaving the user to figure out\nwhat's left.\n\nSo I'm mildly negative on this patch.\n\n-Peff\n"},{"id":"376171","messageId":"86woigp3ro.fsf@gmail.com","threadId":"51135","inReplyTo":"20190522050839.GB29933@sigill.intra.peff.net","subject":"Re: [PATCH 2/3] hash-object doc: elaborate on -w and --literally promises","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2019-05-24T10:04:27Z","receivedAt":"2019-05-24T10:04:32Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Jeff King writes:\n> On Mon, May 20, 2019 at 11:53:11PM +0200, Ævar Arnfjörð Bjarmason wrote:\n>\n>> Clarify the hash-object docs to explicitly note that the --literally\n>> option guarantees that a loose object will be written, but that a\n>> normal -w (\"write\") invocation doesn't.\n>\n> I had to double-check here: you mean that _when_ we are writing an\n> object, \"--literally\" would always write loose, right?\n>\n>> At first I thought talking about \"loose object\" in the docs was a\n>> mistake in 83115ac4a8 (\"git-hash-object.txt: document --literally\n>> option\", 2015-05-04), but as is clear from 5ba9a93b39 (\"hash-object:\n>> add --literally option\", 2014-09-11) this was intended all along.\n>\n> Hmm. After reading both of those, I do think it's mostly an\n> implementation detail. I would not be at all surprised to find that the\n> test suite relies on this (e.g., cleaning up with rm\n> .git/objects/ab/cd1234). But I suspect we also rely on that for the\n> non-literal case, too. ;)\n>\n> So I am on the fence. In some sense it doesn't hurt to document the\n> behavior, but I'm not sure I would want to lock us in to any particular\n> behavior, even for --literally. The intent of the option (as I recall)\n> really is just \"let us write whatever trash we want as an object,\n> ignoring all quality checks\".\n\nI thik that this implemetation detail of `--literally` is here to stay;\nhow would you otherwise fix the issue if garbage object makes Git crash?\n\nHowever, I would prefer to have options state _intent_; if there is\nlegitimate need for a tool that creates loose objects, it would be\nbetter to have separate `--loose` option to `git hash-object` (which\nwould imply `-w`, otherwise it doesn't have sense).\n\n>> --literally::\n>> -\tAllow `--stdin` to hash any garbage into a loose object which might not\n>> +\tAllow for hashing arbitrary data which might not\n>> \totherwise pass standard object parsing or git-fsck checks. Useful for\n>> \tstress-testing Git itself or reproducing characteristics of corrupt or\n>> -\tbogus objects encountered in the wild.\n>> +\tbogus objects encountered in the wild. When writing objects guarantees\n>> +\tthat the written object will be a loose object, for ease of debugging.\n>\n> I had to read this last sentence a few times to parse it. Maybe a comma\n> before guarantees would help? Or even:\n>\n> When writing objects, this option guarantees that the written object\n> will be a loose object, for ease of debugging.\n\nI agree that this reads better.\n\nRegards,\n--\nJakub Narębski\n"},{"id":"376174","messageId":"87lfywf9fp.fsf@evledraar.gmail.com","threadId":"51135","inReplyTo":"86woigp3ro.fsf@gmail.com","subject":"Re: [PATCH 2/3] hash-object doc: elaborate on -w and --literally promises","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2019-05-24T10:12:10Z","receivedAt":"2019-05-24T10:12:15Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Fri, May 24 2019, Jakub Narebski wrote:\n\n> Jeff King writes:\n>> On Mon, May 20, 2019 at 11:53:11PM +0200, Ævar Arnfjörð Bjarmason wrote:\n>>\n>>> Clarify the hash-object docs to explicitly note that the --literally\n>>> option guarantees that a loose object will be written, but that a\n>>> normal -w (\"write\") invocation doesn't.\n>>\n>> I had to double-check here: you mean that _when_ we are writing an\n>> object, \"--literally\" would always write loose, right?\n>>\n>>> At first I thought talking about \"loose object\" in the docs was a\n>>> mistake in 83115ac4a8 (\"git-hash-object.txt: document --literally\n>>> option\", 2015-05-04), but as is clear from 5ba9a93b39 (\"hash-object:\n>>> add --literally option\", 2014-09-11) this was intended all along.\n>>\n>> Hmm. After reading both of those, I do think it's mostly an\n>> implementation detail. I would not be at all surprised to find that the\n>> test suite relies on this (e.g., cleaning up with rm\n>> .git/objects/ab/cd1234). But I suspect we also rely on that for the\n>> non-literal case, too. ;)\n>>\n>> So I am on the fence. In some sense it doesn't hurt to document the\n>> behavior, but I'm not sure I would want to lock us in to any particular\n>> behavior, even for --literally. The intent of the option (as I recall)\n>> really is just \"let us write whatever trash we want as an object,\n>> ignoring all quality checks\".\n>\n> I thik that this implemetation detail of `--literally` is here to stay;\n> how would you otherwise fix the issue if garbage object makes Git crash?\n>\n> However, I would prefer to have options state _intent_; if there is\n> legitimate need for a tool that creates loose objects, it would be\n> better to have separate `--loose` option to `git hash-object` (which\n> would imply `-w`, otherwise it doesn't have sense).\n\nI wonder if we can just remove this option and replace it with a\nGIT_TEST_* env variable, or even a test-tool helper. I can't see why\nanyone other than our own test suite wants this, and that's why it was\nadded. So why document it & expose it in a plumbing tool?\n\n>>> --literally::\n>>> -\tAllow `--stdin` to hash any garbage into a loose object which might not\n>>> +\tAllow for hashing arbitrary data which might not\n>>> \totherwise pass standard object parsing or git-fsck checks. Useful for\n>>> \tstress-testing Git itself or reproducing characteristics of corrupt or\n>>> -\tbogus objects encountered in the wild.\n>>> +\tbogus objects encountered in the wild. When writing objects guarantees\n>>> +\tthat the written object will be a loose object, for ease of debugging.\n>>\n>> I had to read this last sentence a few times to parse it. Maybe a comma\n>> before guarantees would help? Or even:\n>>\n>> When writing objects, this option guarantees that the written object\n>> will be a loose object, for ease of debugging.\n>\n> I agree that this reads better.\n>\n> Regards,\n"},{"id":"376270","messageId":"20190528060641.GC7946@sigill.intra.peff.net","threadId":"51135","inReplyTo":"87lfywf9fp.fsf@evledraar.gmail.com","subject":"Re: [PATCH 2/3] hash-object doc: elaborate on -w and --literally promises","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2019-05-28T06:06:42Z","receivedAt":"2019-05-28T06:06:45Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, May 24, 2019 at 12:12:10PM +0200, Ævar Arnfjörð Bjarmason wrote:\n\n> > I thik that this implemetation detail of `--literally` is here to stay;\n> > how would you otherwise fix the issue if garbage object makes Git crash?\n> >\n> > However, I would prefer to have options state _intent_; if there is\n> > legitimate need for a tool that creates loose objects, it would be\n> > better to have separate `--loose` option to `git hash-object` (which\n> > would imply `-w`, otherwise it doesn't have sense).\n> \n> I wonder if we can just remove this option and replace it with a\n> GIT_TEST_* env variable, or even a test-tool helper. I can't see why\n> anyone other than our own test suite wants this, and that's why it was\n> added. So why document it & expose it in a plumbing tool?\n\nI can think of a few reasons you might want it in the general toolbox:\n\n - you could be recreating a known-buggy history and want to overcome\n consistency checks (e.g., imagine a tool that imports or modifies\n git history, and needs to recreate objects literally, warts and\n all). I think we don't do a lot of quality checks in hash-object\n now, but we have discussed it (and --literally would be the obvious\n escape hatch).\n\n - folks like security researchers who are poking at Git and want to\n see how it reacts to various almost-correct inputs. They _could_ use\n the test-tool helper, but being able to demonstrate bugs with the\n standard toolbox is helpful for communication.\n\n - likewise for general non-security debugging (\"it behaves in this\n funny way if I violate this constraint...\")\n\nSo I actually think it's nice to have it as part of the plumbing, as\nlong as it's buried and documented sufficiently that unsuspecting users\ndo not stumble onto it.\n\nAnd at any rate, now that it has been in the wild for a while, we risk\nbreaking somebody who has come to depend on it.\n\n-Peff\n"},{"id":"376321","messageId":"xmqqd0k24j7s.fsf@gitster-ct.c.googlers.com","threadId":"51135","inReplyTo":"20190520215312.10363-3-avarab@gmail.com","subject":"Re: [PATCH 2/3] hash-object doc: elaborate on -w and --literally promises","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2019-05-28T16:49:59Z","receivedAt":"2019-05-28T16:50:08Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ævar Arnfjörð Bjarmason writes:\n\n> Clarify the hash-object docs to explicitly note that the --literally\n> option guarantees that a loose object will be written, but that a\n> normal -w (\"write\") invocation doesn't.\n>\n> At first I thought talking about \"loose object\" in the docs was a\n> mistake in 83115ac4a8 (\"git-hash-object.txt: document --literally\n> option\", 2015-05-04), but as is clear from 5ba9a93b39 (\"hash-object:\n> add --literally option\", 2014-09-11) this was intended all along.\n\nI have to admit that this \"loose only\" was the doing of my\ndefeatism. IOW, I was utterly pessimistic that I would be able to\nadd more types (and more importantly, unbounded number of random\ntypes) of objects in the packstream.\n\nSo, \"loose object\" limitation is a practical one for those of us who\ncannot think of a reasonable way to cram arbitrary number of random\nnew types into just 3 bits of the \"type\" bitfield, and not inherent\nto the \"hash-object --literally\" command.\n\nSo I am very happy to see the first hunk of this patch, but I doubt\nthere is much value in the last sentence the second hunk adds.\n\nThanks.\n"},{"id":"376322","messageId":"xmqq8suq4ix8.fsf@gitster-ct.c.googlers.com","threadId":"51135","inReplyTo":"86woigp3ro.fsf@gmail.com","subject":"Re: [PATCH 2/3] hash-object doc: elaborate on -w and --literally promises","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2019-05-28T16:56:19Z","receivedAt":"2019-05-28T16:56:28Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jakub Narebski writes:\n\n> I thik that this implemetation detail of `--literally` is here to stay;\n> how would you otherwise fix the issue if garbage object makes Git crash?\n\nBy repacking, presumably ;-).\n\nMore importantly, there needs a way to extend \"enum object_type\" to\nallow unbounded number of arbitrary (garbage) types before we can\nallow --literally to record such a garbage type in a pack stream.\n\nSo I'd expect the implementation detail would stay for a long time.\nBut there is nothing that says `--literally` inherently must write\nloose. It is plausible that a new implementation writes objects of\nknown/valid types to a pack stream, while unknown/garbage types to\nloose objects.\n\n> However, I would prefer to have options state _intent_; if there is\n> legitimate need for a tool that creates loose objects, it would be\n> better to have separate `--loose` option to `git hash-object` (which\n> would imply `-w`, otherwise it doesn't have sense).\n\nYes, I very much agree with that.\n"}]}