{"thread":{"id":"4243","subject":"[PATCH 0/2] tagsize < 8kb restriction","startedAt":"2006-05-22T14:48:03Z","lastAt":"2006-05-25T20:03:40Z","messageCount":12,"participants":["Björn Engelmann","Junio C Hamano","Sean","Linus Torvalds"],"isPatch":true,"patchVersion":1,"patchTotal":2},"messages":[{"id":"20451","messageId":"4471CF23.1070807@gmx.de","threadId":"4243","inReplyTo":null,"subject":"[PATCH 0/2] tagsize < 8kb restriction","fromName":"Björn Engelmann","fromEmail":"bjengelmann@gmx.de","sentAt":"2006-05-22T14:48:03Z","receivedAt":"2006-05-22T14:48:03Z","isPatch":true,"sender":{"key":"bjengelmann@gmx.de","avatar":null},"body":"Hi,\n\nI am currently working on an interface for source code quality assurance\ntools to automatically scan newly commited code. Since it is the only\nway to add data (scan-results) to an already-existing commit, I decided\nto use tags for that.\n\nSince the scan-results will most definitly exeed the 8kb-limit, I would\nlike to remove this artificial restriction.\n\nI know I could also\n\n git-hash-object -t tag -w\n\nbut prefer using the \"official\" way.\n\n\nIn order not to write duplicate code I used parts of index_pipe() in\nsha1_file.c\n\nWhat I found odd when writing the patch was that main() in mktag.c uses\nxread() to read from stdin (which respects EAGAIN and EINTR return\nvalues), but index_pipe() in sha1_file.c just uses read() for doing\nmerely the same thing. For unifying both routines i found that xread()\nmight be the better choice.\n\nRemoving the restriction was pretty straightforward but do you think\nthis would break something in other places ?\n\n\n[PATCH 1/2]\n remove the < 8kb restrinction from git-mktag\n\n[PATCH 2/2]\n add more informative error messages to git-mktag\n\n\nBj\n"},{"id":"20464","messageId":"7vac99c1hv.fsf@assigned-by-dhcp.cox.net","threadId":"4243","inReplyTo":"4471CF23.1070807@gmx.de","subject":"Re: [PATCH 0/2] tagsize < 8kb restriction","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-05-22T19:18:04Z","receivedAt":"2006-05-22T19:18:04Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Björn Engelmann writes:\n\n> I am currently working on an interface for source code quality assurance\n> tools to automatically scan newly commited code. Since it is the only\n> way to add data (scan-results) to an already-existing commit, I decided\n> to use tags for that.\n>\n> Since the scan-results will most definitly exeed the 8kb-limit, I would\n> like to remove this artificial restriction.\n\nLifting the limit is good, but I am not sure if the use of tags\nfor that purpose is appropriate (or any git object for that\nmatter). I'll talk about that at the end.\n\n> What I found odd when writing the patch was that main() in mktag.c uses\n> xread() to read from stdin (which respects EAGAIN and EINTR return\n> values), but index_pipe() in sha1_file.c just uses read() for doing\n> merely the same thing. For unifying both routines i found that xread()\n> might be the better choice.\n\nGood.\n\n> Removing the restriction was pretty straightforward but do you think\n> this would break something in other places ?\n\nI do not think so offhand.\n\nNow, about the usage of such a long tag for your purpose.\n\nAs you noticed, commits and tags are the only types of objetcs\nthat can refer to other commits structurally. But there are\ncases where you do not even need nor want structural reference.\nFor example, 'git cherry-pick' records the commit object name of\nthe cherry-picked commit in the commit message as part of the\ntext -- such a commit does not have structural reference to the\noriginal commit, and we would not _want_ one. I have a strong\nsuspicion that your application does not need or want structural\nreference to commits, and it might be better to merely mention\ntheir object names as part of the text the application produces,\njust like what 'git cherry-pick' does.\n\nPresumably you will have one such tag per commit, and by default\n'fetch' (both cg and git) tries to follow tags, which means\nanybody who fetches new revision would automatically download\nthis QA data -- that is one implication of using a tag to store\nthis information. Without knowing the nature of it, I am not\nsure if everybody who tracks the source wants such baggage. If\nnot, then use of a tag for this may not be appropriate.\n\nAnother question is if the QA data expected to be amended or\nannotated later, after it is created.\n\nIf the answer is yes, then you probably would not want tags --\nyou can create a new tag that points at the same commit to\nupdate the data, but then you have no structural relationships\ngiven by git between such tags that point at the same commit.\nYou could infer their order by timestamp but that is about it.\nI think you are better off creating a separate QA project that\nadds one new file per commit on the main project, and have the\nfile identify the commit object on the main project (either\nstart your text file format for QA data with the commit object\nname, or name each such QA data file after the commit object\nname). Then your automated procedure could scan and add a new\nfile to the QA project every time a new commit is made to the\nmain project, and the data in the QA project can be amended or\nannotated and the changes will be version controlled.\n\nIf the answer is no, then it is probably better to just use an\nappend-only log file that textually records which entry\ncorresponds to which commit in the project. If it is not\nversion controlled, and if it is not part of the main project, I\ndo not see much point in putting the data under git control and\nin the same project.\n"},{"id":"20492","messageId":"BAYC1-PASMTP1164FE2A24B4D1B4C0A607AE9A0@CEZ.ICE","threadId":"4243","inReplyTo":"7vac99c1hv.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH 0/2] tagsize < 8kb restriction","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-05-22T23:12:40Z","receivedAt":"2006-05-22T23:12:40Z","isPatch":true,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Mon, 22 May 2006 12:18:04 -0700\nJunio C Hamano wrote:\n\n> Now, about the usage of such a long tag for your purpose.\n> \n> As you noticed, commits and tags are the only types of objetcs\n> that can refer to other commits structurally. But there are\n> cases where you do not even need nor want structural reference.\n> For example, 'git cherry-pick' records the commit object name of\n> the cherry-picked commit in the commit message as part of the\n> text -- such a commit does not have structural reference to the\n> original commit, and we would not _want_ one. I have a strong\n> suspicion that your application does not need or want structural\n> reference to commits, and it might be better to merely mention\n> their object names as part of the text the application produces,\n> just like what 'git cherry-pick' does.\n\nWhat seems to becoming clear as more people find new ways to use\ngit is that many of them would be well served by having a solid\ninfrastructure to handle metadata. Consider the case above: _git_\nitself doesn't need a structural reference, but users and external\napplications definitely need to be able to lookup which metadata\nis associated with any given commit. Having a git standard for\nthis type of data would help. Tags already do this, so they're\nlikely to be used and abused in ways not initially envisioned,\njust because git doesn't have another such facility.\n \n> Presumably you will have one such tag per commit, and by default\n> 'fetch' (both cg and git) tries to follow tags, which means\n> anybody who fetches new revision would automatically download\n> this QA data -- that is one implication of using a tag to store\n> this information. Without knowing the nature of it, I am not\n> sure if everybody who tracks the source wants such baggage. If\n> not, then use of a tag for this may not be appropriate.\n\nRight. It would be much nicer if it was possible to request or\nignore specific types of metadata when fetching; yet another\nreason that it would be great if git had something built in\nwhich anticipated this need.\n \n> Another question is if the QA data expected to be amended or\n> annotated later, after it is created.\n> \n> If the answer is yes, then you probably would not want tags --\n> you can create a new tag that points at the same commit to\n> update the data, but then you have no structural relationships\n> given by git between such tags that point at the same commit.\n> You could infer their order by timestamp but that is about it.\n> I think you are better off creating a separate QA project that\n> adds one new file per commit on the main project, and have the\n> file identify the commit object on the main project (either\n> start your text file format for QA data with the commit object\n> name, or name each such QA data file after the commit object\n> name). Then your automated procedure could scan and add a new\n> file to the QA project every time a new commit is made to the\n> main project, and the data in the QA project can be amended or\n> annotated and the changes will be version controlled.\n\nThere are a lot of nice features with using a separate meta-data\nbranch. However, you lose the ability to do lookups like you can\nwith tags. A tag like index that gave the ability to associate\ncommits on otherwise unrelated branches might be a way to get\nthe best of both worlds. However, there will be times where\nversion controlled meta-data is overkill. Just need to codify a\ngit-standard for meta data, so that git can help where possible.\n \n> If the answer is no, then it is probably better to just use an\n> append-only log file that textually records which entry\n> corresponds to which commit in the project. If it is not\n> version controlled, and if it is not part of the main project, I\n> do not see much point in putting the data under git control and\n> in the same project.\n\nIt would be very nice if git gave a standard way to lookup and\nperhaps even display metadata. Could add an option to git log\nfor example that said, show all metadata of a certain type.\n\nThere are a limitless number of examples where people want to\nassociate extra information with each commit. Other SCM's call\nthese \"attributes\" or have other such names. Given git's design\nit isn't too hard to imagine offering the ability for version \ncontrolled (or not) and public (or not) meta-data. Very similar\nto tags, but perhaps with a few extra features.\n\nIf git already offered this feature, there'd be no need for a\nflat-file ref-log; the data could be stored in a git-standard\nway for metadata and gain the features of whatever tools grow\nup around it, like querying, inspecting, purging etc.. All of\na sudden people would be able to look at (and perhaps even update)\ntheir own meta data via git log/qgit/gitk/gitweb etc.. All we\nneed is a standard that everyone can conform with.\n\nSean\n"},{"id":"20498","messageId":"Pine.LNX.4.64.0605221646540.3697@g5.osdl.org","threadId":"4243","inReplyTo":"BAYC1-PASMTP1164FE2A24B4D1B4C0A607AE9A0@CEZ.ICE","subject":"Re: [PATCH 0/2] tagsize < 8kb restriction","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-05-23T00:02:41Z","receivedAt":"2006-05-23T00:02:41Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 22 May 2006, Sean wrote:\n> What seems to becoming clear as more people find new ways to use\n> git is that many of them would be well served by having a solid\n> infrastructure to handle metadata. Consider the case above: _git_\n> itself doesn't need a structural reference, but users and external\n> applications definitely need to be able to lookup which metadata\n> is associated with any given commit. Having a git standard for\n> this type of data would help. Tags already do this, so they're\n> likely to be used and abused in ways not initially envisioned,\n> just because git doesn't have another such facility.\n\nI definitely think we should allow arbitrary tags.\n\nThat said, I think that what you actually want to do may be totally \ndifferent.\n\nIf _each_ commit has some extra information associated with it, you don't \nwant to create a tag that points to the commit, you more likely want to \ncreate an object that is indexed by the commit ID rather than the other \nway around.\n\nIOW, I _think_ that what you described would be that if you have the \ncommit ID, you want to find the data based on that ID. No?\n\nAnd that you can do quite easily, while _also_ using git to distribute the \nextra per-commit meta-data. Just create a separate branch that has the \ndata indexed by commit ID. That could be as simple as having one file per \ncommit (using, perhaps, a similar directory layout as the .git/objects/ \ndirectory itself), and then you could do something like\n\n\t# Get the SHA1 of the named commit\n\tcommit=$(git-rev-parse --verify \"$cmitname\"^0)\n\n\t# turn it into a filename (slash between two first chars and the rest)\n\tfilename=$(echo $commit | sed 's:^\\(..\\)\\(.*\\):\\1/\\2:')\n\n\t# look it up in the \"annotations\" branch\n\tgit cat-file blob \"annotations:$filename\"\n\nwhich gets the data from the \"annotations\" branch, indexed by the SHA1 \nname.\n\nNow, everybody can track your \"annotations\" branch using git, and get your \nper-commit annotations for the main branch.\n\nSee?\n\nThe real advantage of tags is that you can use them for the SHA1 \nexpressions, and follow them automatically. If that's what you want (ie \nyou don't want to index things by the commit SHA1, but by some external \nname, like the name the commit had in some other repository), then by all \nmeans use tags. But if you just want to associate some data with each \ncommit, the above \"separate branch for annotations\" approach is much more \nefficient.\n\n\t\tLinus\n"},{"id":"20532","messageId":"BAYC1-PASMTP07A0CAD58FB1CE30882F19AE9B0@CEZ.ICE","threadId":"4243","inReplyTo":"Pine.LNX.4.64.0605221646540.3697@g5.osdl.org","subject":"Re: [PATCH 0/2] tagsize < 8kb restriction","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-05-23T09:59:00Z","receivedAt":"2006-05-23T09:59:00Z","isPatch":true,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Mon, 22 May 2006 17:02:41 -0700 (PDT)\nLinus Torvalds wrote:\n\n> That said, I think that what you actually want to do may be totally \n> different.\n> \n> If _each_ commit has some extra information associated with it, you don't \n> want to create a tag that points to the commit, you more likely want to \n> create an object that is indexed by the commit ID rather than the other \n> way around.\n> \n> IOW, I _think_ that what you described would be that if you have the \n> commit ID, you want to find the data based on that ID. No?\n\nCorrect. But even though there isn't currently an efficient way to do\nthe reverse lookup, many of the visual tools do it. So for instance, if\nyou embed some metadata in the name of a tag, it will actually be nicely\nshown to you associated with the proper commit in qgit/gitk/gitweb. So\nyou _can_ abuse tags and get modest results. And of course the low level\ntools let you do.. git name-rev --tags to lookup the meta data as well.\nSo you can do git log | git name-rev --tags --stdin and see which tags\nare associated with each commit.\n\nI'm not arguing that this makes tags well designed for the these types\nof things, just that there is no other option built in to the low level\ngit that comes as close.\n\n> And that you can do quite easily, while _also_ using git to distribute the \n> extra per-commit meta-data. Just create a separate branch that has the \n> data indexed by commit ID. That could be as simple as having one file per \n> commit (using, perhaps, a similar directory layout as the .git/objects/ \n> directory itself), and then you could do something like\n> \n> \t# Get the SHA1 of the named commit\n> \tcommit=$(git-rev-parse --verify \"$cmitname\"^0)\n> \n> \t# turn it into a filename (slash between two first chars and the rest)\n> \tfilename=$(echo $commit | sed 's:^\\(..\\)\\(.*\\):\\1/\\2:')\n> \n> \t# look it up in the \"annotations\" branch\n> \tgit cat-file blob \"annotations:$filename\"\n> \n> which gets the data from the \"annotations\" branch, indexed by the SHA1 \n> name.\n> \n> Now, everybody can track your \"annotations\" branch using git, and get your \n> per-commit annotations for the main branch.\n> \n> See?\n\nSure, makes a lot of sense. Although the one file per commit thing doesn't\nscale well. It's already a problem when trying to use a lot of tags for\ninstance.\n\nMore than the technical details of the implementation though, i'm trying to\nmake a case that git would do well to codify something like the above and\nprovide a _standard_ method of associating meta data with commits. This\nwould allow all the tools to start displaying meta data etc and have a\ndefined way to efficiently query and manipulate it. \n\nSean\n"},{"id":"20577","messageId":"44737353.20904@gmx.de","threadId":"4243","inReplyTo":"7vac99c1hv.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH 0/2] tagsize < 8kb restriction","fromName":"Björn Engelmann","fromEmail":"bjengelmann@gmx.de","sentAt":"2006-05-23T20:40:51Z","receivedAt":"2006-05-23T20:40:51Z","isPatch":true,"sender":{"key":"bjengelmann@gmx.de","avatar":null},"body":"Hi,\n\nI hope this time I got it right. Is there some kind of style-guide I can\nrefer to in future ?\n\n\n> Another question is if the QA data expected to be amended or\n> annotated later, after it is created.\n>\n> If the answer is yes, then you probably would not want tags --\n> you can create a new tag that points at the same commit to\n> update the data, but then you have no structural relationships\n> given by git between such tags that point at the same commit.\n> You could infer their order by timestamp but that is about it.\n> I think you are better off creating a separate QA project that\n> adds one new file per commit on the main project, and have the\n> file identify the commit object on the main project (either\n> start your text file format for QA data with the commit object\n> name, or name each such QA data file after the commit object\n> name). Then your automated procedure could scan and add a new\n> file to the QA project every time a new commit is made to the\n> main project, and the data in the QA project can be amended or\n> annotated and the changes will be version controlled.\n> \n\nGreat idea ! Thanks a lot. Originally it was not planned to alter the\nresults once committet, but this way it would even be possible to rescan\na commit with a different tool and merge the results. Git would also be\nable to use delta-encoding when packing what can be considered extremly\nefficient since most probably most scan-results won't differ much.\n\nI am currently wondering where to store the reference to such a\nsub-repository. It certainly is a head, but I would like to avoid anyone\ncommiting code into this \"branch\". Maybe I will create a new directory\n.git/refs/annotations.\n\nWhen thinking about this very elegant way to handle meta-data, I got\nanother idea:\nThe quality assurance system also works distributed. For scalability\nreasons there are multiple scanners, each scanning one commit at a time.\nDo you think git could also be used to handle \"locking\" ? The scanners\nwould then push a commit with an empty result-file into the\nannotations-repository so all other scanners who are looking for\ncurrently unscanned commits would ignore it in future. When finished the\nresult can be inserted by pushing a subsequent commit. This way one\navoids the need for a seperate job-server / protocol.\nI am not sure how git would perform in such an environment. Do you think\nthe \"git-push\"-implementation is sufficiently \"thread-save\" for this ?\nOr could simultaniously pushing into the same branch f.e. break the\nrepository ?\n\nHmm.. 2 more things on my mind:\n1.) Do you intend to add some more advanced metadata-functionality to\ngit in the future or should I send a patch with my implementation once\nit is finished ? Will be just some scripts using similar commands to\nwhat Linus sent me (thanks for that, btw)\n\n2.) Searching for a way to add objects to the database I spent quite a\nwhile to find the right command. Don't you think it would be much more\nintuitive having an\n\n git-create-object [-t ] [-n] [-f] [-z] [--stdin] [-r\n]\n\ncommand for creating any type of object (-t blob as default), optionally\nomitting writing it to the database (-n = no-write) (like\ngit-hash-object), by default validating its input (overriding with -f)\n(like git-mktag, git-mktree) and maybe even able to add a reference to\nit with -r (like git-tag).\n\nBj\n"},{"id":"20590","messageId":"7vzmh81gfa.fsf@assigned-by-dhcp.cox.net","threadId":"4243","inReplyTo":"44737353.20904@gmx.de","subject":"Re: [PATCH 0/2] tagsize < 8kb restriction","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-05-23T23:15:37Z","receivedAt":"2006-05-23T23:15:37Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Björn Engelmann writes:\n\n> I am currently wondering where to store the reference to such a\n> sub-repository. It certainly is a head, but I would like to avoid anyone\n> commiting code into this \"branch\". Maybe I will create a new directory\n> .git/refs/annotations.\n\nI would recommend against that. Why shouldn't it be an ordinary\nbranch that is different from the default \"master\"?\n\nIf you are in a shared repository settings, then update hook is\nthere for you to prevent people who do not have any business\ntouching that branch head from mucking with it.\n\n> I am not sure how git would perform in such an environment. Do you think\n> the \"git-push\"-implementation is sufficiently \"thread-save\" for this ?\n\nYes.\n\nAnd I do not necessarily think your workflow would want to have\nsuch \"an empty file works as a lock\" convention.\n\nJust do things locklessly. If two people in the group happened\nto do duplicated work, the first push would succeed and the\nsecond person would be prevented from pushing (and suggested to\nmerge in the work first). When the second person pulls, he\nwould realize the scan result by the first person is already\nthere. If that is considered to be too much wasted work, then\nit means your distributed workflow did not have sufficient\ncommunication among people. Being able to work distributed does\nnot mean you need no coordination, and a distributed SCM is not\na substitute for comminication among paticipants.\n\n> 1.) Do you intend to add some more advanced metadata-functionality to\n> git in the future or should I send a patch with my implementation once\n> it is finished ? Will be just some scripts using similar commands to\n> what Linus sent me (thanks for that, btw)\n\nNeither, until/unless we have a clear design.\n\nI think the annotation branch (or a separate repository) is a\nvery natural consequence of what the tool already give you, and\nthe tools work just fine as they are. There is nothing\ninnovative in what I suggested above nor Linus outlined in the\nother message.\n\nIf you are talking about an application that builds on top of\ngit to do issue management (or QA or whatever), that uses\nmetadata linked to the commits on the main development branch,\nthat would be a wonderful system, but that does not necessarily\nhave to come with git (it's just an application on top of git,\nand the workflow of your organization may or may not match other\npeople's workflow).\n\n> 2.) Searching for a way to add objects to the database I spent quite a\n> while to find the right command. Don't you think it would be much more\n> intuitive having an\n>\n> git-create-object [-t ] [-n] [-f] [-z] [--stdin] [-r\n> ]\n>\n> command for creating any type of object (-t blob as default).\n\nNo, I do not think we would want to make it too easy and relaxed\nto create arbitrary object-looking thing. Each type have\ndefined format and semantics, and creation of an object of each\ntype should be validated. I do not want to encourage bypassing\nit by introducing such a backdoor. The backdoor is easy to\nwrite, but I suspect it would actively harm us, instead of\nhelping us, by encouraging \"let's build a custom type of object,\nwe do not care if other people would not understand it\"\nmentality.\n"},{"id":"20594","messageId":"7v64jw1eua.fsf@assigned-by-dhcp.cox.net","threadId":"4243","inReplyTo":"44737353.20904@gmx.de","subject":"Re: [PATCH 0/2] tagsize < 8kb restriction","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-05-23T23:49:49Z","receivedAt":"2006-05-23T23:49:49Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Björn Engelmann writes:\n\n> I hope this time I got it right.\n\nThanks. Pushed out as a part of \"next\". Will hopefully be part\nof \"master\" by the end of the week if not earlier.\n"},{"id":"20644","messageId":"4474B10A.1020704@gmx.de","threadId":"4243","inReplyTo":"7vzmh81gfa.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH 0/2] tagsize < 8kb restriction","fromName":"Björn Engelmann","fromEmail":"bjengelmann@gmx.de","sentAt":"2006-05-24T19:16:26Z","receivedAt":"2006-05-24T19:16:26Z","isPatch":true,"sender":{"key":"bjengelmann@gmx.de","avatar":null},"body":"\n>> 2.) Searching for a way to add objects to the database I spent quite a\n>> while to find the right command. Don't you think it would be much more\n>> intuitive having an\n>>\n>> git-create-object [-t ] [-n] [-f] [-z] [--stdin] [-r\n>> ]\n>>\n>> command for creating any type of object (-t blob as default).\n>> \n>\n> No, I do not think we would want to make it too easy and relaxed\n> to create arbitrary object-looking thing. Each type have\n> defined format and semantics, and creation of an object of each\n> type should be validated. I do not want to encourage bypassing\n> it by introducing such a backdoor. The backdoor is easy to\n> write, but I suspect it would actively harm us, instead of\n> helping us, by encouraging \"let's build a custom type of object,\n> we do not care if other people would not understand it\"\n> mentality.\n> \n\nWell, this is exactly what you have now in\n git-hash-object -w -t foo\n\nThat is why I said, all input should be validated by default. All I\nproposed was\na) unify the tools in order to have less duplicate code (git-mktag,\ngit-mktree & git-hash-object do merely the same except for the\nvalidating part)\nb) remove the possibility to introduce unchecked objects of arbitrary\ntype (or only allow it with the -f = \"force, use with caution\"-option)\n\nmaybe I should have written \"blob, tag, tree or commit\" instead of\n\"arbitrary\". I did not mean really arbitrary like it is implemented\nright now in git-hash-object.\n\nBj\n"},{"id":"20646","messageId":"7v1wuj6wln.fsf@assigned-by-dhcp.cox.net","threadId":"4243","inReplyTo":"4474B10A.1020704@gmx.de","subject":"Re: [PATCH 0/2] tagsize < 8kb restriction","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-05-24T19:39:32Z","receivedAt":"2006-05-24T19:39:32Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Björn Engelmann writes:\n\n> That is why I said, all input should be validated by default. All I\n> proposed was\n> a) unify the tools in order to have less duplicate code\n> (git-mktag, git-mktree & git-hash-object do merely the same\n> except for the validating part)\n> b) remove the possibility to introduce unchecked objects of arbitrary\n> type (or only allow it with the -f = \"force, use with caution\"-option)\n> maybe I should have written \"blob, tag, tree or commit\" instead of\n> \"arbitrary\". I did not mean really arbitrary like it is implemented\n> right now in git-hash-object.\n\nSorry, I forgot all about hash-objects X-<. It was a convenient\nway to try out new things such as 'gitlink'. Thanks for the\nclarification.\n\nAs to unification, I am not sure if there are a lot to unify.\nEverybody starts with type, length and a LF, but after that each\ntype has its own format constraints. A grand unified command\nthat knows about format constraints of every type under the sun\ndoes not sound like a good approach. While we have only handful\ntypes (and I expect things will stay that way) it is not a big\ndeal either way, though.\n\nAnd the common part is already shared (write_sha1_file_prepare()\nand write_sha1_file() from sha1_file.c).\n"},{"id":"20678","messageId":"44759ABF.1010209@gmx.de","threadId":"4243","inReplyTo":"7v1wuj6wln.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH 0/2] tagsize < 8kb restriction","fromName":"Björn Engelmann","fromEmail":"bjengelmann@gmx.de","sentAt":"2006-05-25T11:53:35Z","receivedAt":"2006-05-25T11:53:35Z","isPatch":true,"sender":{"key":"bjengelmann@gmx.de","avatar":null},"body":"\n> Sorry, I forgot all about hash-objects X-<. It was a convenient\n> way to try out new things such as 'gitlink'. Thanks for the\n> clarification.\n>\n> As to unification, I am not sure if there are a lot to unify.\n> Everybody starts with type, length and a LF, but after that each\n> type has its own format constraints. A grand unified command\n> that knows about format constraints of every type under the sun\n> does not sound like a good approach. While we have only handful\n> types (and I expect things will stay that way) it is not a big\n> deal either way, though.\n> \nOops, sorry, I forgot that \"modular\" in C means something else than in\nthe OO-World...\nYou are right. Probably it is best to have one tool handle each type.\n\nActually what I am aiming for is not the internal structure. I am more\nconcerned about cleaning up the user-interface. When I started learning\ngit I found it very annoying and inconsistent that there are commands\nfor creating a tag and a tree in a validated fashion, but the command\nfor creating blobs was named \"git-hash-object -w\" and also could create\nall other objects without validating them at all. Also, AFAIK there is\ncurrently no way of creating a commit object with validating.\n\nI am well aware that all functionality neccessary already exists. I just\nwant to prevent people learning git in future to have the same\nfrustrating experience as I did.\n\nObviously renaming / moving code around like that would break nearly all\ntools build ontop of git. Therefore I would prefer to use aliasing. If\nyou feel like this would introduce too many unneccessary commands, I\nwould instead focus on improving the documentation.\n\nBj\n"},{"id":"20701","messageId":"7v8xopub1f.fsf@assigned-by-dhcp.cox.net","threadId":"4243","inReplyTo":"44759ABF.1010209@gmx.de","subject":"Re: [PATCH 0/2] tagsize < 8kb restriction","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-05-25T20:03:40Z","receivedAt":"2006-05-25T20:03:40Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Björn Engelmann writes:\n\n> I am well aware that all functionality neccessary already exists. I just\n> want to prevent people learning git in future to have the same\n> frustrating experience as I did.\n\nI think I understood your points, but for normal \"people\nlearning git\", hash-object, write-tree, commit-tree and mktag\nare _not_ the commands they need to know about. These low level\ncommands are for Porcelain writers. The users do not create\nblobs or trees or commits -- they \"git add\", \"git rm\", \"git\ncommit\", and \"git pull\" and as part of these actions, blobs,\ntrees and commits are created. The users do not even create\ntags with mktag -- they use \"git tag\" for that.\n"}]}