{"thread":{"id":"7579","subject":"What's cooking in git.git (topics)","startedAt":"2007-04-09T08:17:48Z","lastAt":"2007-04-25T08:11:37Z","messageCount":32,"participants":["Junio C Hamano","Alex Riesen","Nicolas Pitre","Martin Waitz","Linus Torvalds","Sam Ravnborg","David Lang","Johannes Schindelin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"38924","messageId":"7vodly0xn7.fsf@assigned-by-dhcp.cox.net","threadId":"7579","inReplyTo":null,"subject":"What's cooking in git.git (topics)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-04-09T08:17:48Z","receivedAt":"2007-04-09T08:17:48Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Here are the topics that have been cooking. Commits prefixed\nwith '-' are only in 'pu' while commits prefixed with '+' are\nin 'next'. The topics list the commits in reverse chronological\norder.\n\n* jc/checkout (Sun Apr 8 22:08:31 2007 -0700) 7 commits\n + Teach git-reset to use index BASE extension.\n + git-read-tree --set-base=\n + Use BASE index extension in git-am.\n + Move check_base() shell function to git-sh-setup\n + Use BASE index extension in git-commit and git-merge.\n + update-index --{set,get}-base\n + Add BASE index extension.\n\nThis series is primarily to make it safer when somebody else\nupdates the tip of the branch you have currently checked out.\nAs I said in previous messages, I think the series covers basic\noperations fine but there probably are gaps in the coverage.\nMotivated volunteers are needed to fill them.\n\n* fl/cvsserver (Sat Apr 7 16:58:10 2007 +0200) 8 commits\n - cvsserver: Add asciidoc documentation for new database backend\n configuration\n + cvsserver: Corrections to the database backend configuration\n + cvsserver: Use DBI->table_info instead of DBI->tables\n + cvsserver: Abort if connect to database fails\n + cvsserver: Make the database backend configurable\n + cvsserver: Allow to override the configuration per access method\n + cvsserver: Handle three part keys in git config correctly\n + cvsserver: Introduce new state variable 'method'\n\nAlthough the code looked sane, I do not interact with git\nrepositories over CVS protocol in real life, so I haven't\npersonally tested it. I cannot push this out to 'master'\nwithout positive feedbacks. Testing needed.\n\n* jc/read-tree-df (Sat Apr 7 07:17:35 2007 -0700) 5 commits\n - t3030: merge-recursive backend test.\n - merge-recursive: handle D/F conflict case more carefully.\n - merge-recursive: do not barf on \"to be removed\" entries.\n - Treat D/F conflict entry more carefully in unpack-\n trees.c::threeway_merge()\n - t1000: fix case table.\n\nThis is a follow-up to \"my branch has foo/bar and I cannot\nswitch to another branch that has foo as a file\" series. It\ndeals with three-way merges that involve D/F conflicts. Again,\nheavy testing and reporting is needed until it graduates to\n'master'.\n\n* jc/quickfetch (Thu Apr 5 03:22:55 2007 -0700) 2 commits\n - git-fetch: use fetch--tool pick-rref to avoid local fetch from\n alternate\n - git-fetch--tool pick-rref\n\nThis is to alleviate Linus's worries about \"git fetch\" from a\nrepository whose object store is your alternate consuming too\nmuch cycles in the new \"SHA-1 collision detection\" code, at the\nsame time avoiding to create a pack that has duplicate objects\nin the repository due to the recent \"keep\" behaviour of\nfetch-pack.\n\n* js/wrap-log (Sun Apr 8 01:28:00 2007 -0700) 2 commits\n - shortlog -w: make wrap-line behaviour optional.\n - Use print_wrapped_text() in shortlog\n\nThis teaches \"git shortlog\" to wrap lines that are too long (by\ndefault, 76 columns) when \"-w\" option is given.\n\nThis was resurrected from my held-box. I do not have an\nimmediate need for it but somebody might. Cheering-on and\ndocumentation updates are needed for it to go anywhere.\n\n* jc/the-index (Sun Apr 1 23:26:07 2007 -0700) 2 commits\n - Make read-cache.c \"the_index\" free.\n - Move index-related variables into a structure.\n\nThis libifies the \"cache\" part of the system. Parked in 'pu' as\nthere is no immediate need, at least for me.\n\n* jc/blame (Tue Mar 27 01:58:01 2007 -0700) 3 commits\n - git-blame: optimize get_origin() from linear search to hash-\n lookup.\n - git-blame: pass \"struct scoreboard *\" pointers around.\n - blame: lift structure definitions up\n* jc/pathattr (Thu Mar 1 01:20:21 2007 -0800) 5 commits\n - pathattr: allow piping to external program.\n - pathattr: read from git_config().\n - git-show: use pathattr to run \"display\"\n - pathattr: path based configuration of various attributes.\n + convert: add scaffolding for path based selection of conversion\n routines.\n* jc/diff (Mon Dec 25 01:08:50 2006 -0800) 2 commits\n - test-para: combined diff between HEAD, index and working tree.\n - para-walk: walk n trees, index and working tree in parallel\n\nThese are stalled...\n"},{"id":"39439","messageId":"7vr6qlxexe.fsf@assigned-by-dhcp.cox.net","threadId":"7579","inReplyTo":"7vodly0xn7.fsf@assigned-by-dhcp.cox.net","subject":"What's cooking in git.git (topics)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-04-16T01:53:49Z","receivedAt":"2007-04-16T01:53:49Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Here are the topics that have been cooking. Commits prefixed\nwith '-' are only in 'pu' while commits prefixed with '+' are\nin 'next'. The topics list the commits in reverse chronological\norder.\n\n* lt/gitlink (Sun Apr 15 11:14:28 2007 -0700) 17 commits\n + Expose subprojects as special files to \"git diff\" machinery\n + Fix some \"git ls-files -o\" fallout from gitlinks\n + Teach \"git-read-tree -u\" to check out submodules as a directory\n + Teach git list-objects logic to not follow gitlinks\n + Fix gitlink index entry filesystem matching\n + Teach \"git-read-tree -u\" to check out submodules as a directory\n + Teach git list-objects logic not to follow gitlinks\n + Don't show gitlink directories when we want \"other\" files\n + Teach git-update-index about gitlinks\n + Teach directory traversal about subprojects\n + Fix thinko in subproject entry sorting\n + Teach core object handling functions about gitlinks\n + Teach \"fsck\" not to follow subproject links\n + Add \"S_IFDIRLNK\" file mode infrastructure for git links\n + Add 'resolve_gitlink_ref()' helper function\n + Avoid overflowing name buffer in deep directory structures\n + diff-lib: use ce_mode_from_stat() rather than messing with modes\n manually\n\nEverybody loves when Linus jumps in and gets the ball rolling\nfor a topic that has been only an idle-talk wishlist with a\nminimum set of patches. Let's see where this goes.\n\n* jc/attr (Sat Apr 14 21:27:20 2007 -0400) 10 commits\n - Document git-check-attr\n - Change attribute negation marker from '!' to '-'.\n - Define a built-in attribute macro \"binary\".\n - attribute macro support\n + Makefile: add patch-ids.h back in.\n + Fix 'diff' attribute semantics.\n + Fix 'crlf' attribute semantics.\n + Teach 'diff' about 'diff' attribute.\n + Define 'crlf' attribute.\n + Add basic infrastructure to assign attributes to paths\n\n... and I tried to learn from that. I do not know how\nsuccessful I was, though.\n\nBut I earlier said that one of the focus of 1.5.2 should be the\ngitattributes support.\n\n* fl/cvsserver (Fri Apr 13 18:13:42 2007 +0200) 12 commits\n + config.txt: Add gitcvs.db* variables\n + cvsserver: Document the GIT branches -> CVS modules mapping more\n prominently\n + cvsserver: Reword documentation on necessity of write access\n + cvsserver: Allow to \"add\" a removed file\n + cvsserver: Add asciidoc documentation for new database backend\n configuration\n + cvsserver: Corrections to the database backend configuration\n + cvsserver: Use DBI->table_info instead of DBI->tables\n + cvsserver: Abort if connect to database fails\n + cvsserver: Make the database backend configurable\n + cvsserver: Allow to override the configuration per access method\n + cvsserver: Handle three part keys in git config correctly\n + cvsserver: Introduce new state variable 'method'\n\nWaiting for Ack's from the field, which unfortunately I haven't\nseen any yet.\n\n* np/pack (Tue Apr 10 22:54:36 2007 -0400) 16 commits\n + clean up add_object_entry()\n + tests for various pack index features\n + use test-genrandom in tests instead of /dev/urandom\n + simple random data generator for tests\n + validate reused pack data with CRC when possible\n + allow forcing index v2 and 64-bit offset treshold\n + pack-redundant.c: learn about index v2\n + show-index.c: learn about index v2\n + sha1_file.c: learn about index version 2\n + index-pack: learn about pack index version 2\n + pack-objects: learn about pack index version 2\n + compute object CRC32 with index-pack\n + compute a CRC32 for each object as stored in a pack\n + add overflow tests on pack offset variables\n + make overflow test on delta base offset work regardless of\n variable size\n + get rid of num_packed_objects()\n\nHaven't seen any breakage report so far. After giving them a\nfinal look, let's push this out to 'master' soonish.\n\n* js/wrap-log (Sun Apr 8 01:28:00 2007 -0700) 2 commits\n + shortlog -w: make wrap-line behaviour optional.\n + Use print_wrapped_text() in shortlog\n\nI do not think it breaks anything but I do not think we are in a\nhurry, either.\n\n* jc/read-tree-df (Sat Apr 7 07:17:35 2007 -0700) 5 commits\n + t3030: merge-recursive backend test.\n + merge-recursive: handle D/F conflict case more carefully.\n + merge-recursive: do not barf on \"to be removed\" entries.\n + Treat D/F conflict entry more carefully in unpack-\n trees.c::threeway_merge()\n + t1000: fix case table.\n\nThis series should not matter in practice as I do not think any\nproject that changes between directory and file is sane, but\npeople are known to do insane things, and this would help them.\n\nAny comments for or against their graduation to 'master'?\n\n* jc/quickfetch (Thu Apr 5 03:22:55 2007 -0700) 2 commits\n + git-fetch: use fetch--tool pick-rref to avoid local fetch from\n alternate\n + git-fetch--tool pick-rref\n\nThis would make fetching from your alternate more efficient by\nnot fetching any objects (because by definition it is not\nnecessary). It doubly matters in this case performance-wise as\nthe recent code verifies fetched objects that were already in\nthe repository, which tends to be expensive.\n\n* jc/the-index (Sun Apr 1 23:26:07 2007 -0700) 2 commits\n - Make read-cache.c \"the_index\" free.\n - Move index-related variables into a structure.\n\nSort of \"libification\", which nobody seems to need right now,\nbut I did it already and there is no reason to throw away.\n\n* jc/blame (Tue Mar 27 01:58:01 2007 -0700) 4 commits\n - git-blame: optimize get_origin() from linear search to hash-\n lookup.\n - git-blame: pass \"struct scoreboard *\" pointers around.\n - blame: lift structure definitions up\n - blame -s: suppress author name and time.\n* jc/diff (Mon Dec 25 01:08:50 2006 -0800) 2 commits\n - test-para: combined diff between HEAD, index and working tree.\n - para-walk: walk n trees, index and working tree in parallel\n\nStalled.\n"},{"id":"39846","messageId":"7v647tcjr6.fsf@assigned-by-dhcp.cox.net","threadId":"7579","inReplyTo":"7vr6qlxexe.fsf@assigned-by-dhcp.cox.net","subject":"What's cooking in git.git (topics)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-04-19T00:04:13Z","receivedAt":"2007-04-19T00:04:13Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Here are the topics that have been cooking. Commits prefixed\nwith '-' are only in 'pu' while commits prefixed with '+' are\nin 'next'. The topics list the commits in reverse chronological\norder.\n\n* np/pack (Mon Apr 16 12:32:13 2007 -0400) 25 commits\n + pack-objects: better check_object() performances\n + add get_size_from_delta()\n + pack-objects: make in_pack_header_size a variable of its own\n + pack-objects: get rid of create_final_object_list()\n + pack-objects: get rid of reuse_cached_pack\n + pack-objects: clean up list sorting\n + pack-objects: rework check_delta_limit usage\n + pack-objects: equal objects in size should delta against newer\n objects\n + pack-objects: optimize preferred base handling a bit\n + clean up add_object_entry()\n + tests for various pack index features\n + use test-genrandom in tests instead of /dev/urandom\n + simple random data generator for tests\n + validate reused pack data with CRC when possible\n + allow forcing index v2 and 64-bit offset treshold\n + pack-redundant.c: learn about index v2\n + show-index.c: learn about index v2\n + sha1_file.c: learn about index version 2\n + index-pack: learn about pack index version 2\n + pack-objects: learn about pack index version 2\n + compute object CRC32 with index-pack\n + compute a CRC32 for each object as stored in a pack\n + add overflow tests on pack offset variables\n + make overflow test on delta base offset work regardless of\n variable size\n + get rid of num_packed_objects()\n\nNico's \"optionally 64-bit pack idx\" aka idx format version 2.\nI've taken another pass at them and am planning to push them out\non 'master' hopefully this weekend, but a documentation update\nthat mention the new --index-version option to git-pack-objects\nwould be nice to have before that happens.\n\n* lt/objalloc (Mon Apr 16 22:13:09 2007 -0700) 3 commits\n - Make the object lookup hash use a \"object index\" instead of a\n pointer\n + Clean up object creation to use more common code\n + Use proper object allocators for unknown object nodes too\n\nThe bottom 2 are genuine clean-ups, and I'd like to push them\nout to 'master' this weekend after giving them one last look.\n\n* jc/attr (Wed Apr 18 16:16:37 2007 -0700) 19 commits\n + Fix funny types used in attribute value representation\n + Allow low-level driver to specify different behaviour during\n internal merge.\n + Custom low-level merge driver: change the configuration scheme.\n + Allow the default low-level merge driver to be configured.\n + Custom low-level merge driver support.\n + Add a demonstration/test of customized merge.\n + Allow specifying specialized merge-backend per path.\n + merge-recursive: separate out xdl_merge() interface.\n + Allow more than true/false to attributes.\n + Document git-check-attr\n + Change attribute negation marker from '!' to '-'.\n + Define a built-in attribute macro \"binary\".\n + attribute macro support\n + Makefile: add patch-ids.h back in.\n + Fix 'diff' attribute semantics.\n + Fix 'crlf' attribute semantics.\n + Teach 'diff' about 'diff' attribute.\n + Define 'crlf' attribute.\n + Add basic infrastructure to assign attributes to paths\n\nYou've heard a lot of noises between me and Linus on this one\nfor the past few days. Remaining tasks before it can graduate\nto 'master' are:\n\n (1) I haven't decided how to allow the merge driver override\n the decision to punt on symlinks and some other minor\n policy decision merge-recursive hardcodes yet;\n\n (2) Not enough test coverage;\n\n (3) No documentation other than my e-mail messages to the list\n and commit log messages as to how you use this stuff;\n\n (4) Example \"low level merge driver\" scripts; covering the same\n set of tools git-mergetool knows about would be good.\n\nHelp from the list, probably starting from (3) and (4), would\nhelp polish the series and squash any remaining bugs.\n\nWe could do $blobid$ only keywords by hooking into this, but\nthat would involve philosophical discussion and I'd rather\npostpone that and have the infrastructure in 'master' first.\n\n* jp/refs (Tue Apr 17 02:42:50 2007 +0100) 1 commit\n + refs.c: add a function to sort a ref list, rather then sorting on\n add\n* jc/quickfetch (Mon Apr 16 00:42:29 2007 -0700) 3 commits\n + Make sure quickfetch is not fooled with a previous, incomplete\n fetch.\n + git-fetch: use fetch--tool pick-rref to avoid local fetch from\n alternate\n + git-fetch--tool pick-rref\n\nI think these two topics should graduate to 'master' this\nweekend, as I haven't heard any breakage from anybody, and they\ndo seem to help.\n\n* lt/gitlink (Sun Apr 15 11:14:28 2007 -0700) 17 commits\n + Expose subprojects as special files to \"git diff\" machinery\n + Fix some \"git ls-files -o\" fallout from gitlinks\n + Teach \"git-read-tree -u\" to check out submodules as a directory\n + Teach git list-objects logic to not follow gitlinks\n + Fix gitlink index entry filesystem matching\n + Teach \"git-read-tree -u\" to check out submodules as a directory\n + Teach git list-objects logic not to follow gitlinks\n + Don't show gitlink directories when we want \"other\" files\n + Teach git-update-index about gitlinks\n + Teach directory traversal about subprojects\n + Fix thinko in subproject entry sorting\n + Teach core object handling functions about gitlinks\n + Teach \"fsck\" not to follow subproject links\n + Add \"S_IFDIRLNK\" file mode infrastructure for git links\n + Add 'resolve_gitlink_ref()' helper function\n + Avoid overflowing name buffer in deep directory structures\n + diff-lib: use ce_mode_from_stat() rather than messing with modes\n manually\n\nStalled; Alex has a set of tests that should go on top of this\nseries but I haven't taken a look at it yet. I think we should\nhave enough for interested people to start futzing with, and I\nam wondering why nobody has sent a note saying \"Hey, I did this\nusing tree objects with commits in it, it works nicely for these\noperations but these things are still cumbersome to do and I\nneed to polish it more\".\n\n* jc/the-index (Sun Apr 1 23:26:07 2007 -0700) 2 commits\n - Make read-cache.c \"the_index\" free.\n - Move index-related variables into a structure.\n\nA small part of libification; nobody seems to want it.\n\n* jc/blame (Tue Mar 27 01:58:01 2007 -0700) 4 commits\n - git-blame: optimize get_origin() from linear search to hash-\n lookup.\n - git-blame: pass \"struct scoreboard *\" pointers around.\n - blame: lift structure definitions up\n - blame -s: suppress author name and time.\n\n* jc/diff (Mon Dec 25 01:08:50 2006 -0800) 2 commits\n - test-para: combined diff between HEAD, index and working tree.\n - para-walk: walk n trees, index and working tree in parallel\n\nStalled.\n"},{"id":"39849","messageId":"20070419002357.GC14247@steel.home","threadId":"7579","inReplyTo":"7v647tcjr6.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's cooking in git.git (topics)","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-04-19T00:23:57Z","receivedAt":"2007-04-19T00:23:57Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Junio C Hamano, Thu, Apr 19, 2007 02:04:13 +0200:\n> \n> Stalled; Alex has a set of tests that should go on top of this\n> series but I haven't taken a look at it yet. I think we should\n> have enough for interested people to start futzing with, and I\n> am wondering why nobody has sent a note saying \"Hey, I did this\n> using tree objects with commits in it, it works nicely for these\n> operations but these things are still cumbersome to do and I\n> need to polish it more\".\n> \n\nI am setting up a super-repo for my own very private use (small home\nserver setup). Still working on what _recursive_ tools do I really\nneed (and fsck is not the most interesting one: git-diff-files is. Am\nafraid of releasing a system I wont ever be able to get to the source\nof).\n\nIt is, as predicted, becoming mostly work on build infrastructure and\nintegrity checks in the super-project. Being the sole user of this\nproject I'll definitely miss all the issues of really big modularized\nprojects, though.\n\n> \n> * jc/the-index (Sun Apr 1 23:26:07 2007 -0700) 2 commits\n> - Make read-cache.c \"the_index\" free.\n> - Move index-related variables into a structure.\n> \n> A small part of libification; nobody seems to want it.\n> \n\nNo user _can_ want it. We need to make the future less a nightmare (it\nmay not even become one).\n"},{"id":"39857","messageId":"alpine.LFD.0.98.0704182233140.4504@xanadu.home","threadId":"7579","inReplyTo":"7v647tcjr6.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's cooking in git.git (topics)","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-04-19T02:39:06Z","receivedAt":"2007-04-19T02:39:06Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Wed, 18 Apr 2007, Junio C Hamano wrote:\n\n> * np/pack (Mon Apr 16 12:32:13 2007 -0400) 25 commits\n> \n> Nico's \"optionally 64-bit pack idx\" aka idx format version 2.\n> I've taken another pass at them and am planning to push them out\n> on 'master' hopefully this weekend, but a documentation update\n> that mention the new --index-version option to git-pack-objects\n> would be nice to have before that happens.\n\nWell... In fact I didn't intend for that option to ever be used by \nanything but test scripts in order to trigger some code paths without \ngenerating jumbo packs (don't know what people would think of me if I \ncreated a 8GB pack in my test ;-)). Therefore I didn't think that \noption was worth documenting.\n\nBut if you insist I'll send you a patch.\n\n\nNicolas\n"},{"id":"39878","messageId":"20070419100757.GB27208@admingilde.org","threadId":"7579","inReplyTo":"7v647tcjr6.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's cooking in git.git (topics)","fromName":"Martin Waitz","fromEmail":"tali@admingilde.org","sentAt":"2007-04-19T10:07:57Z","receivedAt":"2007-04-19T10:07:57Z","isPatch":false,"sender":{"key":"tali@admingilde.org","avatar":"https://gravatar.com/avatar/3f89b03eee362187effabe257898735b475673a12265c398ea9161259ae91553?d=mp&s=160"},"body":"hoi :)\n\nOn Wed, Apr 18, 2007 at 05:04:13PM -0700, Junio C Hamano wrote:\n> * lt/gitlink (Sun Apr 15 11:14:28 2007 -0700) 17 commits\n> \n> Stalled; Alex has a set of tests that should go on top of this\n> series but I haven't taken a look at it yet. I think we should\n> have enough for interested people to start futzing with, and I\n> am wondering why nobody has sent a note saying \"Hey, I did this\n> using tree objects with commits in it, it works nicely for these\n> operations but these things are still cumbersome to do and I\n> need to polish it more\".\n\nYou know that I am interested, but sadly I don't have as much time to\nreally have a look / work on it as I'd liked. But Linus' series\nlooks very good from what I've seen now.\nConceptually Linus approach is very much identical my prototyping work\nand I am convinced that it is the right way to go. Only his code is\nmuch better (hey, it's Linus after all ;-) and about our branch-vs-HEAD\ndiscussion, well we'll see how it works out.\n\nNow, how to go on?\nThe next thing we need is a real checkout & merge support -- but that\nis not that hard.\nThen we need to think about how to handle the submodule object database,\ne.g. when fetching.\n\nI'd also like to be able to support bare supermodule repositories which\ninclude all neccessary submodule objects. But I guess we need some\nmore experience with submodules before we can solve that in a scalable\nway.\n\n-- \nMartin Waitz\n"},{"id":"39929","messageId":"7vslav4yv6.fsf_-_@assigned-by-dhcp.cox.net","threadId":"7579","inReplyTo":"7v647tcjr6.fsf@assigned-by-dhcp.cox.net","subject":"[RFR] gitattributes(5) documentation","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-04-20T01:29:33Z","receivedAt":"2007-04-20T01:29:33Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Here is my current draft. I have build-infrastructure updates\nto deal with a new manual section \"man5/\" (file formats) already\nbut that is boring stuff, so I am sending out only the new file\nto be added for review.\n\nWe probably would want to have gitconfig(5) to describe its file\nformat, and include::config.txt[] in there as well.\n\nAlthough I do not think it is particularly necessary, we _might_\nwant to also have gitdata(5) that describes the file format of\n$GIT_DIR/index, loose objects, .pack, .idx, packed-refs.\n\n-- >8 -- Documentation/gitattributes.txt -- >8 --\n\ngitattributes(5)\n================\n\nNAME\n----\ngitattributes - defining attributes per path\n\nSYNOPSIS\n--------\n.gitattributes\n\n\nDESCRIPTION\n-----------\n\nA `gitattributes` file is a simple text file that gives\n`attributes` to pathnames.\n\nEach line in `gitattributes` file is of form:\n\n\tglob\tattr1 attr2 ...\n\nThat is, a glob pattern followed by an attributes list,\nseparated by whitespaces. When the glob pattern matches the\npath in question, the list of attributes are given to the path.\n\nEach attribute can be in one of these states for a given path:\n\nSet::\n\n\tThe path has the attribute with special value \"true\";\n\tthis is specified by listing only the name of the\n\tattribute in the attribute list.\n\nUnset::\n\n\tThe path has the attribute with special value \"false\";\n\tthis is specified by listing the name of the attribute\n\tprefixed with a dash `-` in the attribute list.\n\nSet to a value::\n\n\tThe path has the attribute with specified string value;\n\tthis is specified by listing the name of the attribute\n\tfollowed by an equal sign `=` and its value in the\n\tattribute list.\n\nUnspecified::\n\n\tNo glob pattern matches the path, and nothing says if\n\tthe path has or does not have the attribute.\n\nWhen more than one glob pattern matches the path, a later line\nthat matches overrides an earlier line.\n\nWhen deciding what attributes are assigned to a path, git\nconsults `.gitattributes` file in the same directory as the path\nin question, and its parent directories, and then finally\n`$GIT_DIR/info/attributes` file, in this order.\n\nSometimes you would need to override an setting of an attribute\nfor a path to `unspecified` state. This can be done by listing\nthe name of the attribute prefixed with an exclamation point `!`.\n\n\nEFFECTS\n-------\n\nCertain operations by git can be influenced by assigning\nparticular attributes to a path. Currently, three operations\nare attributes-aware.\n\nChecking-out and checking-in\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nThe attribute `crlf` affects how the contents stored in the\nrepository are copied to the working tree files when commands\nsuch as `git checkout` and `git merge` is run. It also affects\nhow the contents you prepare in the working tree is stored back\nin the repository when you do `git add` and `git commit`.\n\nSet::\n\tA path to which the `crlf` attribute is set is converted\n\tto have CRLF line endings in the working tree upon\n\tcheckout, and converted back to strip CRLF line endings\n\tto LF line endings upon checkin.\n\nUnset::\n\tA path to which the `crlf` attribute is unset (do not\n\tconfuse this with 'unspecified') does not go through\n\tline endings conversion upon checkin/checkout.\n\nUnspecified::\n\tIf the configuration variable `core.autocrlf` is false, no\n\tconversion is done for paths with `crlf` attribute\n\tunspecified.\n+\nOthewise, the contents of the path is inspected, and if it does\nnot look like a text file, no conversion is done.\n+\nIf `core.autocrlf` is true, and the contents of the path does\nlook like a text file, line endings are converted to CRLF upon\ncheckout and LF upon checkin.\n+\nIf `core.autocrlf` is set to \"input\", and the contents of the\npath does look like a text file, line endings are converted to\nLF upon checkin, but there is no conversion done upon checkout.\n\nAny other value set to `crlf` attribute is ignored and git acts\nas if the attribute is left unspecified.\n\n\nGenerating diff text\n~~~~~~~~~~~~~~~~~~~~\n\nThe attribute `diff` affects if `git diff` generates textual\npatch for the path or just says `Binary files differ`.\n\nSet::\n\tA path to which the `crlf` attribute is set is treated\n\tas text, even when they contain funny bytes such as NUL.\n\nUnset::\n\tA path to which the `crlf` attribute is unset will\n\tgenerate `Binary files differ`.\n\nUnspecified::\n\tA path to which the `crlf` attribute is unspecified\n\tfirst gets its contents inspected, and if it looks like\n\ttext, it is treated as text. Otherwise it would\n\tgenerate `Binary files differ`.\n\nAny other value set to `diff` attribute is ignored and git acts\nas if the attribute is left unspecified.\n\n\nPerforming a three-way merge\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nThe attribute `merge` affects how three versions of a file is\nmerged when a file-level merge is necessary during `git merge`,\nand other programs such as `git revert` and `git cherry-pick`.\n\nSet::\n\tBuilt-in 3-way merge driver is used to merge the\n\tcontents in a way similar to `merge` command of `RCS`\n\tsuite. This is suitable for ordinary text files.\n\nUnset::\n\tTake the version from the current branch as the\n\ttentative merge result, and declare that the merge has\n\tconflicts. This is suitable for binary files that does\n\tnot have a well-defined merge semantics.\n\nUnspecified::\n\tBy default, this uses the same built-in 3-way merge\n\tdriver as is the case the `merge` attribute is set.\n\tHowever, `merge.default` configuration variable can name\n\tdifferent merge driver to be used for paths to which the\n\t`merge` attribute is unspecified.\n\nOther string value::\n\t3-way merge is performed using the specified custom\n\tmerge driver. The built-in 3-way merge driver can be\n\texplicitly specified by asking for \"text\" driver; the\n\tbuilt-in \"take the current branch\" driver can be\n\trequested by \"binary\".\n\nDefining a custom merge driver\n^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n\nThe definition of a merge driver is done in `gitconfig` not\n`gitattributes` file, so strictly speaking this manual page is a\nwrong place to talk about it. However...\n\nTo define a custom merge driver `filfre`, add a section to your\n`$GIT_DIR/config` file (or `$HOME/.gitconfig` file) like this:\n\n----------------------------------------------------------------\n[merge \"filfre\"]\n\tname = feel-free merge driver\n\tdriver = filfre %O %A %B\n\trecursive = binary\n----------------------------------------------------------------\n\nThe `merge.*.name` variable gives the driver a human-readable\nname.\n\nThe `merge.*.driver` variable's value is used to construct a\ncommand to run to merge ancestor's version (`%O`), current\nversion (`%A`) and the other branches' version (`%B`). These\nthree tokens are replaced with the names of temporary files that\nhold the contents of these versions when the command line is\nbuilt.\n\nThe merge driver is expected to leave the result of the merge in\nthe file named with `%A` by overwriting it, and exit with zero\nstatus if it managed to merge them cleanly, or non-zero if there\nwere conflicts.\n\nThe `merge.*.recursive` variable specifies what other merge\ndriver to use when the merge driver is called for an internal\nmerge between common ancestors, when there are more than one.\nWhen left unspecified, the driver itself is used for both\ninternal merge and the final merge.\n\n\nEXAMPLE\n-------\n\nIf you have these three `gitattributes` file:\n\n----------------------------------------------------------------\n(in $GIT_DIR/info/attributes)\n\na*\tfoo !bar -baz\n\n(in .gitattributes)\nabc\tfoo bar baz\n\n(in t/.gitattributes)\nab*\tmerge=filfre\nabc\t-foo -bar\n*.c\tfrotz\n----------------------------------------------------------------\n\nthe attributes given to path `t/abc` are computed as follows:\n\n1. By examining `t/.gitattributes` (which is in the same\n diretory as the path in question), git finds that the first\n line matches. `merge` attribute is set. It also finds that\n the second line matches, and attributes `foo` and `bar`\n are unset.\n\n2. Then it examines `.gitattributes` (which is in the parent\n directory), and finds that the first line matches, but\n `t/.gitattributes` file already decided how `merge`, `foo`\n and `bar` attributes should be given to this path, so it\n leaves `foo` and `bar` unset. Attribute `baz` is set.\n\n3. Finally it examines `$GIT_DIR/info/gitattributes`. This file\n is used to override the in-tree settings. The first line is\n a match, and `foo` is set, `bar` is reverted to unspecified\n state, and `baz` is unset.\n\nAs the result, the attributes assignement to `t/abc` becomes:\n\n----------------------------------------------------------------\nfoo\tset to true\nbar\tunspecified\nbaz\tset to false\nmerge\tset to string value \"filfre\"\nfrotz\tunspecified\n----------------------------------------------------------------\n\n\nGIT\n---\nPart of the gitlink:git[7] suite\n"},{"id":"39931","messageId":"alpine.LFD.0.98.0704191835290.9964@woody.linux-foundation.org","threadId":"7579","inReplyTo":"7vslav4yv6.fsf_-_@assigned-by-dhcp.cox.net","subject":"Re: [RFR] gitattributes(5) documentation","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-04-20T01:45:01Z","receivedAt":"2007-04-20T01:45:01Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\nGreat. And reading the documentation, something struck me: wonderful docs \nabout crlf, but it became clear that either the docs are wrong, or the \nbehaviour is less than optimal: you cannot specify \"crlf=input\" any way?\n\nSo I would sugegst that\n - if crlf is set, we still honor the value of \"core.autocrlf\", we just \n don't care about the *content*.\n\nMaybe that's what the code is doing (I thought it did, but I'm too lazy to \ncheck), but the docs don't say that:\n\nOn Thu, 19 Apr 2007, Junio C Hamano wrote:\n> \n> Set::\n> \tA path to which the `crlf` attribute is set is converted\n> \tto have CRLF line endings in the working tree upon\n> \tcheckout, and converted back to strip CRLF line endings\n> \tto LF line endings upon checkin.\n\nThis documented behaviour is non-optimal for a few reasons:\n - it makes it impossible to say \"this is text\", and have it work on UNIX \n platforms ;)\n - it makes it impossible to have \"autocrlf=input\", and then correct one \n single file that was incorrectly guessed to be binary, and have that \n file behave like other files.\n\nSo I _think_ the right rules are:\n\n - unspecified: use autocrlf *and* content detection logic\n - unset: never do crlf<->lf (\"binary\")\n - set: use autocrlf without content detection logic (\"text\")\n\nwith possibly an added rule:\n\n - set to value: \"true\" or \"input\" force that particular setting \n *regardless* of autocrlf, ie we'd always get CRLF even on UNIX.\n\nHmm?\n\n\t\t\tLinus\n"},{"id":"39933","messageId":"alpine.LFD.0.98.0704192150510.4504@xanadu.home","threadId":"7579","inReplyTo":"7vslav4yv6.fsf_-_@assigned-by-dhcp.cox.net","subject":"Re: [RFR] gitattributes(5) documentation","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-04-20T01:57:23Z","receivedAt":"2007-04-20T01:57:23Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Thu, 19 Apr 2007, Junio C Hamano wrote:\n\n> Generating diff text\n> ~~~~~~~~~~~~~~~~~~~~\n> \n> The attribute `diff` affects if `git diff` generates textual\n> patch for the path or just says `Binary files differ`.\n> \n> Set::\n> \tA path to which the `crlf` attribute is set is treated\n ^^^^\n\n> \tas text, even when they contain funny bytes such as NUL.\n> \n> Unset::\n> \tA path to which the `crlf` attribute is unset will\n ^^^^\n\n> \tgenerate `Binary files differ`.\n> \n> Unspecified::\n> \tA path to which the `crlf` attribute is unspecified\n ^^^^\n\nRemnants of a cut'n paste?\n\n\nNicolas\n"},{"id":"39938","messageId":"7virbr4p0v.fsf@assigned-by-dhcp.cox.net","threadId":"7579","inReplyTo":"alpine.LFD.0.98.0704191835290.9964@woody.linux-foundation.org","subject":"Re: [RFR] gitattributes(5) documentation","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-04-20T05:02:08Z","receivedAt":"2007-04-20T05:02:08Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> This documented behaviour is non-optimal for a few reasons:\n> - it makes it impossible to say \"this is text\", and have it work on UNIX \n> platforms ;)\n> - it makes it impossible to have \"autocrlf=input\", and then correct one \n> single file that was incorrectly guessed to be binary, and have that \n> file behave like other files.\n>\n> So I _think_ the right rules are:\n>\n> - unspecified: use autocrlf *and* content detection logic\n> - unset: never do crlf<->lf (\"binary\")\n> - set: use autocrlf without content detection logic (\"text\")\n>\n> with possibly an added rule:\n>\n> - set to value: \"true\" or \"input\" force that particular setting \n> *regardless* of autocrlf, ie we'd always get CRLF even on UNIX.\n\nA patch (only compile and testsuite tested but otherwise not\ntested) is attached; loses more lines than it adds.\n\nHere is a rewrite of the `crlf` section.\n\n-- >8 --\nChecking-out and checking-in\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nThe attribute `crlf` affects how the contents stored in the\nrepository are copied to the working tree files when commands\nsuch as `git checkout` and `git merge` run. It also affects how\ngit stores the contents you prepare in the working tree in the\nrepository upon `git add` and `git commit`.\n\nSet::\n\n\tSetting the `crlf` attribute on a path is meant to mark\n\tthe path as a \"text\" file. 'core.autocrlf' conversion\n\ttakes place without guessing the content type by\n\tinspection.\n\nUnset::\n\n\tUnsetting the `crlf` attribute on a path is meant to\n\tmark the path as a \"binary\" file. The path never goes\n\tthrough line endings conversion upon checkin/checkout.\n\nUnspecified::\n\n\tUnspecified `crlf` attribute tells git to apply the\n\t`core.autocrlf` conversion when the file content looks\n\tlike text.\n\nSet to string value \"input\"::\n\n\tThis is similar to setting the attribute to `true`, but\n\talso forces git to act as if `core.autocrlf` is set to\n\t`input` for the path.\n\nAny other value set to `crlf` attribute is ignored and git acts\nas if the attribute is left unspecified.\n\n\nThe `core.autocrlf` conversion\n^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n\nIf the configuration variable `core.autocrlf` is false, no\nconversion is done.\n\nWhen `core.autocrlf` is true, it means that the platform wants\nCRLF line endings for files in the working tree, and you want to\nconvert them back to the normal LF line endings when checking\nin to the repository.\n\nWhen `core.autocrlf` is set to \"input\", line endings are\nconverted to LF upon checkin, but there is no conversion done\nupon checkout.\n-- 8< --\n\n convert.c | 75 +++++++++++++++++++++---------------------------------------\n 1 files changed, 26 insertions(+), 49 deletions(-)\n\ndiff --git a/convert.c b/convert.c\nindex a5f60c7..da64253 100644\n--- a/convert.c\n+++ b/convert.c\n@@ -10,6 +10,11 @@\n * translation when the \"auto_crlf\" option is set.\n */\n \n+#define CRLF_GUESS\t(-1)\n+#define CRLF_BINARY\t0\n+#define CRLF_TEXT\t1\n+#define CRLF_INPUT\t2\n+\n struct text_stat {\n \t/* CR, LF and CRLF counts */\n \tunsigned cr, lf, crlf;\n@@ -74,13 +79,13 @@ static int is_binary(unsigned long size, struct text_stat *stats)\n \treturn 0;\n }\n \n-static int crlf_to_git(const char *path, char **bufp, unsigned long *sizep, int guess)\n+static int crlf_to_git(const char *path, char **bufp, unsigned long *sizep, int action)\n {\n \tchar *buffer, *nbuf;\n \tunsigned long size, nsize;\n \tstruct text_stat stats;\n \n-\tif (guess && !auto_crlf)\n+\tif ((action == CRLF_BINARY) || (action == CRLF_GUESS && !auto_crlf))\n \t\treturn 0;\n \n \tsize = *sizep;\n@@ -94,7 +99,7 @@ static int crlf_to_git(const char *path, char **bufp, unsigned long *sizep, int\n \tif (!stats.cr)\n \t\treturn 0;\n \n-\tif (guess) {\n+\tif (action == CRLF_GUESS) {\n \t\t/*\n \t\t * We're currently not going to even try to convert stuff\n \t\t * that has bare CR characters. Does anybody do that crazy\n@@ -119,7 +124,12 @@ static int crlf_to_git(const char *path, char **bufp, unsigned long *sizep, int\n \t*bufp = nbuf;\n \t*sizep = nsize;\n \n-\tif (guess) {\n+\tif (action == CRLF_GUESS) {\n+\t\t/*\n+\t\t * If we guessed, we already know we rejected a file with\n+\t\t * lone CR, and we can strip a CR without looking at what\n+\t\t * follow it.\n+\t\t */\n \t\tdo {\n \t\t\tunsigned char c = *buffer++;\n \t\t\tif (c != '\\r')\n@@ -136,24 +146,15 @@ static int crlf_to_git(const char *path, char **bufp, unsigned long *sizep, int\n \treturn 1;\n }\n \n-static int autocrlf_to_git(const char *path, char **bufp, unsigned long *sizep)\n-{\n-\treturn crlf_to_git(path, bufp, sizep, 1);\n-}\n-\n-static int forcecrlf_to_git(const char *path, char **bufp, unsigned long *sizep)\n-{\n-\treturn crlf_to_git(path, bufp, sizep, 0);\n-}\n-\n-static int crlf_to_working_tree(const char *path, char **bufp, unsigned long *sizep, int guess)\n+static int crlf_to_worktree(const char *path, char **bufp, unsigned long *sizep, int action)\n {\n \tchar *buffer, *nbuf;\n \tunsigned long size, nsize;\n \tstruct text_stat stats;\n \tunsigned char last;\n \n-\tif (guess && auto_crlf <= 0)\n+\tif ((action == CRLF_BINARY) || (action == CRLF_INPUT) ||\n+\t (action == CRLF_GUESS && auto_crlf <= 0))\n \t\treturn 0;\n \n \tsize = *sizep;\n@@ -171,7 +172,7 @@ static int crlf_to_working_tree(const char *path, char **bufp, unsigned long *si\n \tif (stats.lf == stats.crlf)\n \t\treturn 0;\n \n-\tif (guess) {\n+\tif (action == CRLF_GUESS) {\n \t\t/* If we have any bare CR characters, we're not going to touch it */\n \t\tif (stats.cr != stats.crlf)\n \t\t\treturn 0;\n@@ -200,16 +201,6 @@ static int crlf_to_working_tree(const char *path, char **bufp, unsigned long *si\n \treturn 1;\n }\n \n-static int autocrlf_to_working_tree(const char *path, char **bufp, unsigned long *sizep)\n-{\n-\treturn crlf_to_working_tree(path, bufp, sizep, 1);\n-}\n-\n-static int forcecrlf_to_working_tree(const char *path, char **bufp, unsigned long *sizep)\n-{\n-\treturn crlf_to_working_tree(path, bufp, sizep, 0);\n-}\n-\n static void setup_crlf_check(struct git_attr_check *check)\n {\n \tstatic struct git_attr *attr_crlf;\n@@ -228,38 +219,24 @@ static int git_path_check_crlf(const char *path)\n \tif (!git_checkattr(path, 1, &attr_crlf_check)) {\n \t\tconst char *value = attr_crlf_check.value;\n \t\tif (ATTR_TRUE(value))\n-\t\t\treturn 1;\n+\t\t\treturn CRLF_TEXT;\n \t\telse if (ATTR_FALSE(value))\n-\t\t\treturn 0;\n+\t\t\treturn CRLF_BINARY;\n \t\telse if (ATTR_UNSET(value))\n \t\t\t;\n-\t\telse\n-\t\t\tdie(\"unknown value %s given to 'crlf' attribute\",\n-\t\t\t (char *)value);\n+\t\telse if (!strcmp(value, \"input\"))\n+\t\t\treturn CRLF_INPUT;\n+\t\t/* fallthru */\n \t}\n-\treturn -1;\n+\treturn CRLF_GUESS;\n }\n \n int convert_to_git(const char *path, char **bufp, unsigned long *sizep)\n {\n-\tswitch (git_path_check_crlf(path)) {\n-\tcase 0:\n-\t\treturn 0;\n-\tcase 1:\n-\t\treturn forcecrlf_to_git(path, bufp, sizep);\n-\tdefault:\n-\t\treturn autocrlf_to_git(path, bufp, sizep);\n-\t}\n+\treturn crlf_to_git(path, bufp, sizep, git_path_check_crlf(path));\n }\n \n int convert_to_working_tree(const char *path, char **bufp, unsigned long *sizep)\n {\n-\tswitch (git_path_check_crlf(path)) {\n-\tcase 0:\n-\t\treturn 0;\n-\tcase 1:\n-\t\treturn forcecrlf_to_working_tree(path, bufp, sizep);\n-\tdefault:\n-\t\treturn autocrlf_to_working_tree(path, bufp, sizep);\n-\t}\n+\treturn crlf_to_worktree(path, bufp, sizep, git_path_check_crlf(path));\n }\n"},{"id":"39963","messageId":"7vmz13z4au.fsf@assigned-by-dhcp.cox.net","threadId":"7579","inReplyTo":"20070419100757.GB27208@admingilde.org","subject":"Re: What's cooking in git.git (topics)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-04-20T11:14:01Z","receivedAt":"2007-04-20T11:14:01Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Martin Waitz writes:\n\n> Now, how to go on?\n> The next thing we need is a real checkout & merge support -- but that\n> is not that hard.\n\nAs git.git is the project that everybody who is interested in\nmaking the feature to materialize fetches, looks at and works on\nanyway, once the support at the plumbing level is complete, an\nobvious thing to do is to use it in git.git tree itself.\n\nFor example, I would like to eventually be able to remove\ngit-gui/ subdirectory and bind git-gui.git as a subproject.\nAnother possibility that is probably of a smaller impact is to\nbind what is known as 'todo' branch at Meta/ directory, as that\nis where I have the branch checked out in my worktree. People\nwho are not interested in what are in 'todo' would not mind\nhaving an empty directory there in their checkout, and\ninterested ones can use the same layout as I do.\n\nMaking git.git the first guinea pig has a unique bootstrapping\nproblem involved, however. These kind of changes in git.git\nitself has to wait at least until what we have in 'next' today\nis in everybody's hands. Otherwise, people who want to use git\nfor their real work need to first grab a tarball snapshot that\nhas the plumbing subproject support, and then update to\n'master', because we are still too fast moving for any distro\nbinary packaged version to be satisfactory solution for people\nwho want to have all the bells and whistles. Also, I cannot\nhave subproject in git.git until kernel.org starts running git\nwith subproject support -- otherwise nobody can clone or pull\nfrom git.git X-<.\n\nIf there was a project of lessor importance that can afford to\nsay \"if you want to track this project, you have to use git from\n'next', which has not yet been officially released, but we are a\nsmall closely knit group and we can live with this limitation\",\nit would be easier, but that would not be as effective guinea\npig as git.git itself would be.\n\nEating our own dog food is how git has evolved since its early\ndays. There was no Porcelain to speak of back then; Linus gave\na recipe for keeping track of your work using 'update-index',\n'write-tree', 'commit-tree' and 'echo' (we did not even have\n'update-ref' to advance the tip of the branch; instead we did\n\"commit=$(commit-tree) && echo $commit >.git/HEAD\"), and people\nfirst followed that recipe, and later wrote a set of thin shell\nwrappers around that recipe.\n\n> Then we need to think about how to handle the submodule object\n> database, e.g. when fetching.\n\nWith the clear separation of connectivity rules between modules,\nI do not think this is an issue at all.\n"},{"id":"39972","messageId":"81b0412b0704200458n33c1eb83p540b738e7ff26ec9@mail.gmail.com","threadId":"7579","inReplyTo":"7vmz13z4au.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's cooking in git.git (topics)","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-04-20T11:58:12Z","receivedAt":"2007-04-20T11:58:12Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 4/20/07, Junio C Hamano wrote:\n> Making git.git the first guinea pig has a unique bootstrapping\n> problem involved, however. These kind of changes in git.git\n> itself has to wait at least until what we have in 'next' today\n> is in everybody's hands.\n\nHave you any plans as to when that should begin to happen?\nWe can warn user if he tries to add a subproject until\nporcelain support can be considered usable. It certainly\nwont be a problem for early adopters, they know what they're\ndoing, and an accidental git add of a directory (which by accident\nis a git repo all by itself) does not go unnoticed.\nOr even disallow it by default (unset dir_struct:dir_links), and\ngive git add/update-index an option to allow them. We can\nreconsider the default later.\n"},{"id":"40005","messageId":"20070420193142.GA13080@uranus.ravnborg.org","threadId":"7579","inReplyTo":"7vmz13z4au.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's cooking in git.git (topics)","fromName":"Sam Ravnborg","fromEmail":"sam@ravnborg.org","sentAt":"2007-04-20T19:31:42Z","receivedAt":"2007-04-20T19:31:42Z","isPatch":false,"sender":{"key":"sam@ravnborg.org","avatar":"https://gravatar.com/avatar/168a912606ed0742d840bb365e3cc21db390c36531a58341dc7a069cc1f15f62?d=mp&s=160"},"body":"On Fri, Apr 20, 2007 at 04:14:01AM -0700, Junio C Hamano wrote:\n> \n> Making git.git the first guinea pig has a unique bootstrapping\n> problem involved, however. These kind of changes in git.git\n> itself has to wait at least until what we have in 'next' today\n> is in everybody's hands. Otherwise, people who want to use git\n> for their real work need to first grab a tarball snapshot that\n> has the plumbing subproject support, and then update to\n> 'master', because we are still too fast moving for any distro\n> binary packaged version to be satisfactory solution for people\n> who want to have all the bells and whistles. Also, I cannot\n> have subproject in git.git until kernel.org starts running git\n> with subproject support -- otherwise nobody can clone or pull\n> from git.git X-<.\n\nThe bootstrapping issue could be fixed by having a separate\ngit-subproject.git on kernel.org.\n\nBut I see no easy solution for the requireent for kernel.org to\na new git (and I doubt kernel.org sysadmin is too keen to\nupdate to a next-based git).\n\n\tSam\n"},{"id":"40027","messageId":"20070421060950.GE27208@admingilde.org","threadId":"7579","inReplyTo":"20070420193142.GA13080@uranus.ravnborg.org","subject":"Re: What's cooking in git.git (topics)","fromName":"Martin Waitz","fromEmail":"tali@admingilde.org","sentAt":"2007-04-21T06:09:50Z","receivedAt":"2007-04-21T06:09:50Z","isPatch":false,"sender":{"key":"tali@admingilde.org","avatar":"https://gravatar.com/avatar/3f89b03eee362187effabe257898735b475673a12265c398ea9161259ae91553?d=mp&s=160"},"body":"hoi :)\n\nOn Fri, Apr 20, 2007 at 09:31:42PM +0200, Sam Ravnborg wrote:\n> On Fri, Apr 20, 2007 at 04:14:01AM -0700, Junio C Hamano wrote:\n> > \n> > Making git.git the first guinea pig has a unique bootstrapping\n> > problem involved, however. These kind of changes in git.git\n> > itself has to wait at least until what we have in 'next' today\n> > is in everybody's hands. Otherwise, people who want to use git\n> > for their real work need to first grab a tarball snapshot that\n> > has the plumbing subproject support, and then update to\n> > 'master', because we are still too fast moving for any distro\n> > binary packaged version to be satisfactory solution for people\n> > who want to have all the bells and whistles. Also, I cannot\n> > have subproject in git.git until kernel.org starts running git\n> > with subproject support -- otherwise nobody can clone or pull\n> > from git.git X-<.\n> \n> The bootstrapping issue could be fixed by having a separate\n> git-subproject.git on kernel.org.\n> \n> But I see no easy solution for the requireent for kernel.org to\n> a new git (and I doubt kernel.org sysadmin is too keen to\n> update to a next-based git).\n\nWell, it only needs to be new enough to understand enough of\nsubmodules so that it can play the server part.\nSo once we are in that part to be stable we can merge it to master,\nso that kernel.org can use it.\nFull submodule support should then mature until the next major version\nafter which git.git could use it itself.\n\n-- \nMartin Waitz\n"},{"id":"40028","messageId":"alpine.LFD.0.98.0704210001380.9964@woody.linux-foundation.org","threadId":"7579","inReplyTo":"20070421060950.GE27208@admingilde.org","subject":"Re: What's cooking in git.git (topics)","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-04-21T07:11:05Z","receivedAt":"2007-04-21T07:11:05Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sat, 21 Apr 2007, Martin Waitz wrote:\n> On Fri, Apr 20, 2007 at 09:31:42PM +0200, Sam Ravnborg wrote:\n> > \n> > But I see no easy solution for the requireent for kernel.org to\n> > a new git (and I doubt kernel.org sysadmin is too keen to\n> > update to a next-based git).\n> \n> Well, it only needs to be new enough to understand enough of\n> submodules so that it can play the server part.\n\nYes. I don't think kernel.org itself really needs more than already exists \nin 'next': it needs the ability to *serve* projects (and that means doing \nthe tree traversal properly and know to stop traversing at gitlink \nentries), but kernel.org itself wouldn't actually need any of the \nporcelain at all. The porcelain would all be used on the client sides.\n\n> So once we are in that part to be stable we can merge it to master,\n> so that kernel.org can use it.\n> Full submodule support should then mature until the next major version\n> after which git.git could use it itself.\n\nYes. I *think* that the gitlink stuff in 'next' is ready to be merged, if \nonly because (a) there really hasn't been any disagreement about it (yeah, \npartly probably simply because it was me writing the patches, but I think \nlargely because the patches simply were pretty clean!) and (b) there \naren't any real downsides either, since it won't actually affect any \nnon-gitlink use.\n\nSo there's certainly the *possible* downside that the whole approach is \nbroken and won't work, and merging something broken is pointless. However, \nwe've had people thinking about this for quite so time, and I don't think \nanybody seriously believes that it's not a fairly straightforward \n(although probably time-consuming and painful) thing to do all the \nporcelain stuff and it will \"just work\". So it's _possible_ that there is \nsome roadblock that everybody has just ignored, but that just doesn't seem \nvery likely.\n\nSo it could stay in 'next' until we have everything else in place too, and\nthe argument for getting it into master literally boils down to the fact \nthat it's probably already in a good enough shape for the server side \n(even if the client side is obviously totally missing, and we may find \n*bugs* that are just hiding because it's not used very actively as a \nresult). \n\nI don't really have a huge strong personal feeling either way. I've not \nthought about the patches lately, partly because I'm just fairly happy \nwith the core, and partly because I'm just waiting for somebody else to \nstart working on it, and then I'll happily jump in and fix any issues that \ncome up.\n\nSo I would kind of prefer to get it merged sooner rather than later, but \nit's not a huge deal for me - what's more important is probably that \nsomebody else rolls up his sleeves and gets dirty with it too ;)\n\n\t\t\tLinus\n"},{"id":"40082","messageId":"Pine.LNX.4.63.0704211749300.5655@qynat.qvtvafvgr.pbz","threadId":"7579","inReplyTo":"7virbr4p0v.fsf@assigned-by-dhcp.cox.net","subject":"Re: [RFR] gitattributes(5) documentation","fromName":"David Lang","fromEmail":"david.lang@digitalinsight.com","sentAt":"2007-04-22T00:51:57Z","receivedAt":"2007-04-22T00:51:57Z","isPatch":false,"sender":{"key":"david.lang@digitalinsight.com","avatar":null},"body":"On Thu, 19 Apr 2007, Junio C Hamano wrote:\n\n> Set to string value \"input\"::\n>\n> \tThis is similar to setting the attribute to `true`, but\n> \talso forces git to act as if `core.autocrlf` is set to\n> \t`input` for the path.\n>\n> Any other value set to `crlf` attribute is ignored and git acts\n> as if the attribute is left unspecified.\n\nI think that a better option would be that if it's set to a string value, that \nstring value is treated as if core.autocrlf was set to that value.\n\nin the long run this would let you phase out the core.autocrlf option entirely, \nletting the bahavior be specified in gitattributes.\n\nDavid Lang\n"},{"id":"40098","messageId":"7vejmdq63w.fsf@assigned-by-dhcp.cox.net","threadId":"7579","inReplyTo":"7v647tcjr6.fsf@assigned-by-dhcp.cox.net","subject":"What's cooking in git.git (topics)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-04-22T06:24:19Z","receivedAt":"2007-04-22T06:24:19Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Here are the topics that have been cooking. Commits prefixed\nwith '-' are only in 'pu' while commits prefixed with '+' are\nin 'next'. The topics list the commits in reverse chronological\norder.\n\n* jc/attr (Sat Apr 21 19:09:02 2007 -0700) 2 commits\n - Add 'ident' conversion.\n - Add 'filter' attribute and external filter driver definition.\n\nThis is the remaining \"controversial\" bits.\n\n* lt/objalloc (Mon Apr 16 22:13:09 2007 -0700) 1 commit\n . Make the object lookup hash use a \"object index\" instead of a\n pointer\n* jc/the-index (Sun Apr 1 23:26:07 2007 -0700) 2 commits\n - Make read-cache.c \"the_index\" free.\n - Move index-related variables into a structure.\n* jc/blame (Tue Mar 27 01:58:01 2007 -0700) 4 commits\n - git-blame: optimize get_origin() from linear search to hash-\n lookup.\n - git-blame: pass \"struct scoreboard *\" pointers around.\n - blame: lift structure definitions up\n - blame -s: suppress author name and time.\n* jc/diff (Mon Dec 25 01:08:50 2006 -0800) 2 commits\n - test-para: combined diff between HEAD, index and working tree.\n - para-walk: walk n trees, index and working tree in parallel\n\nThe rest are stalled.\n"},{"id":"40100","messageId":"7vmz10q4cx.fsf@assigned-by-dhcp.cox.net","threadId":"7579","inReplyTo":"Pine.LNX.4.63.0704211749300.5655@qynat.qvtvafvgr.pbz","subject":"Re: [RFR] gitattributes(5) documentation","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-04-22T07:02:06Z","receivedAt":"2007-04-22T07:02:06Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"David Lang writes:\n\n> in the long run this would let you phase out the core.autocrlf option\n> entirely, letting the bahavior be specified in gitattributes.\n\nYou _could_, but that is quite against what we want. These\nshould stay separate, and the gitattributes mechanism is\ndesigned specifically to allow them cleanly separated.\n\nThe configuration \"core.autcrlf\" describes a particular\nrepository. If the platform the repository is on expects text\nfiles to be line-terminated with CRLF, you would have\ncore.autocrlf set; otherwise you don't.\n\nOn the other hand, gitattributes' 'crlf' describes if the path\nis text, and that is the reason it can and should be \"in-tree\",\ni.e. not just $GIT_DIR/info/attributes (which is private to the\nrepository) but in .gitattributes (and subdirectories'), which\nis given to everybody who has a copy of the project.\n\nHow text files are handled is a local matter, and stays in the\nconfig. Which ones are text is the same for everybody who has a\ncopy of the project, and is in-tree information.\n"},{"id":"40111","messageId":"Pine.LNX.4.63.0704220221160.5946@qynat.qvtvafvgr.pbz","threadId":"7579","inReplyTo":"7vmz10q4cx.fsf@assigned-by-dhcp.cox.net","subject":"Re: [RFR] gitattributes(5) documentation","fromName":"David Lang","fromEmail":"david.lang@digitalinsight.com","sentAt":"2007-04-22T09:33:53Z","receivedAt":"2007-04-22T09:33:53Z","isPatch":false,"sender":{"key":"david.lang@digitalinsight.com","avatar":null},"body":"On Sun, 22 Apr 2007, Junio C Hamano wrote:\n\n> David Lang writes:\n>\n>> in the long run this would let you phase out the core.autocrlf option\n>> entirely, letting the bahavior be specified in gitattributes.\n>\n> You _could_, but that is quite against what we want. These\n> should stay separate, and the gitattributes mechanism is\n> designed specifically to allow them cleanly separated.\n>\n> The configuration \"core.autcrlf\" describes a particular\n> repository. If the platform the repository is on expects text\n> files to be line-terminated with CRLF, you would have\n> core.autocrlf set; otherwise you don't.\n>\n> On the other hand, gitattributes' 'crlf' describes if the path\n> is text, and that is the reason it can and should be \"in-tree\",\n> i.e. not just $GIT_DIR/info/attributes (which is private to the\n> repository) but in .gitattributes (and subdirectories'), which\n> is given to everybody who has a copy of the project.\n\nI was thinking that it should be in $GIT_DIR/info/gitattributes along with the \nrest of the crlf defintitions.\n\n> How text files are handled is a local matter, and stays in the\n> config. Which ones are text is the same for everybody who has a\n> copy of the project, and is in-tree information.\n\nI understand what you are aiming for, but you are depending on people doing the \ndefining of what files are text in the .gitattributes files instead of \n$GIT_DIR/info/gitattributes, which is also valid to do with things as currently \ndefined (at least if I'm understanding them correctly)\n\nwhat you really do want for crlf is one variable that, if set, uses the value of \nanother variable.\n\ni wonder if this is useful enough to define formally. something along the lines \nof\n[default] crlf=input\nin the $GIT_DIR/info/gitattributes file\n\nat the moment we have crlf (set by core.autocrlf) and merge (set by the \nenvironment variable), I think I saw that it may also be possible to define a \ndifferent diff to use by default as well (possibly by useing a third method to \ndefine the default, possibly by an environment variable, I don't remember)\n\nif you could set the defaults in the $GIT_DIR/info/gitattributes file and then \nhave the flag set/unset/set-to-value in the whatever gitattributes file(s) are \nappropriate, it would consolodate the configurations into one related place \nrather then spreading them around with different ways to set the defaults for \ndifferent things.\n\nDavid Lang\n"},{"id":"40176","messageId":"7v647ninbq.fsf@assigned-by-dhcp.cox.net","threadId":"7579","inReplyTo":"7vejmdq63w.fsf@assigned-by-dhcp.cox.net","subject":"What's cooking in git.git (topics)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-04-23T07:04:09Z","receivedAt":"2007-04-23T07:04:09Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Here are the topics that have been cooking. Commits prefixed\nwith '-' are only in 'pu' while commits prefixed with '+' are\nin 'next'. The topics list the commits in reverse chronological\norder.\n\n* jc/the-index (Sun Apr 1 23:26:07 2007 -0700) 2 commits\n + Make read-cache.c \"the_index\" free.\n + Move index-related variables into a structure.\n\nI gave a brief look at the beginning of libification in\nlcapitulino's repository at repo.or.cz, and I think this is\nrelated to his topic, so instead of leaving this in limbo, I'm\nplanning to merge this in v1.5.2-rc1, hopefully to make the\nlater merge easier.\n\n* mk/diff (Sun Apr 22 23:56:22 2007 -0700) 6 commits\n - Diff between two blobs should take mode changes into account now.\n - use mode of the tree in git-diff, if : syntax is used\n - store mode in rev_list, if : syntax is used\n - add add_object_array_with_mode\n - add get_sha1_with_mode\n - Add S_IFINVALID mode\n\nThis attempts to do something we wanted to do for a long time\n(the comment removed from the top of builtin-diff.c with this\nseries has been there for almost a year). I haven't tried it\nyet myself; it needs a few test. This may help some parts of\ngitweb so it would be desirable if we can fast-track this by\nv1.5.2-rc1.\n\n* jc/attr (Sat Apr 21 03:14:13 2007 -0700) 2 commits\n - Add 'filter' attribute and external filter driver definition.\n - Add 'ident' conversion.\n\nAs 'ident' conversion is stateless, I do not mind too much\nincluding it in v1.5.2-rc1. On the other hand, the arbitrary\n'filter' is quite contentious, although the character-code\nconversion example I gave myself might be a good enough reason\nfor people to want it. Undecided.\n\n* lt/objalloc (Mon Apr 16 22:13:09 2007 -0700) 1 commit\n - Make the object lookup hash use a \"object index\" instead of a\n pointer\n* jc/blame (Tue Mar 27 01:58:01 2007 -0700) 4 commits\n - git-blame: optimize get_origin() from linear search to hash-\n lookup.\n - git-blame: pass \"struct scoreboard *\" pointers around.\n - blame: lift structure definitions up\n - blame -s: suppress author name and time.\n* jc/diff (Mon Dec 25 01:08:50 2006 -0800) 2 commits\n - test-para: combined diff between HEAD, index and working tree.\n - para-walk: walk n trees, index and working tree in parallel\n\nThese are not considered for v1.5.2.\n"},{"id":"40207","messageId":"alpine.LFD.0.98.0704231212260.28339@xanadu.home","threadId":"7579","inReplyTo":"7v647ninbq.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's cooking in git.git (topics)","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-04-23T16:16:38Z","receivedAt":"2007-04-23T16:16:38Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Mon, 23 Apr 2007, Junio C Hamano wrote:\n\n> As 'ident' conversion is stateless, I do not mind too much\n> including it in v1.5.2-rc1. On the other hand, the arbitrary\n> 'filter' is quite contentious, although the character-code\n> conversion example I gave myself might be a good enough reason\n> for people to want it. Undecided.\n\nLike I said there are certainly plenty of good (and bad) reasons for \nusing this facility, and many of them we might not imagine now. Since \nthe code is already written I think you should include it.\n\n\nNicolas\n"},{"id":"40213","messageId":"81b0412b0704231007i81ee20cx9a37f1c8a3df62b1@mail.gmail.com","threadId":"7579","inReplyTo":"7v647ninbq.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's cooking in git.git (topics)","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-04-23T17:07:34Z","receivedAt":"2007-04-23T17:07:34Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 4/23/07, Junio C Hamano wrote:\n> * jc/attr (Sat Apr 21 03:14:13 2007 -0700) 2 commits\n> - Add 'filter' attribute and external filter driver definition.\n> - Add 'ident' conversion.\n>\n> As 'ident' conversion is stateless, I do not mind too much\n> including it in v1.5.2-rc1. On the other hand, the arbitrary\n> 'filter' is quite contentious, although the character-code\n> conversion example I gave myself might be a good enough reason\n> for people to want it. Undecided.\n\nCan I suggest a config option to completely disable content\nmunging code? So that people who really care about the\nreal content, or just don't have the tools for the filters still\ncan checkout the repos depending on the filters.\n"},{"id":"40215","messageId":"7vvefnf1wb.fsf@assigned-by-dhcp.cox.net","threadId":"7579","inReplyTo":"81b0412b0704231007i81ee20cx9a37f1c8a3df62b1@mail.gmail.com","subject":"Re: What's cooking in git.git (topics)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-04-23T17:15:16Z","receivedAt":"2007-04-23T17:15:16Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Alex Riesen\" writes:\n\n> On 4/23/07, Junio C Hamano wrote:\n>> * jc/attr (Sat Apr 21 03:14:13 2007 -0700) 2 commits\n>> - Add 'filter' attribute and external filter driver definition.\n>> - Add 'ident' conversion.\n>>\n>> As 'ident' conversion is stateless, I do not mind too much\n>> including it in v1.5.2-rc1. On the other hand, the arbitrary\n>> 'filter' is quite contentious, although the character-code\n>> conversion example I gave myself might be a good enough reason\n>> for people to want it. Undecided.\n>\n> Can I suggest a config option to completely disable content\n> munging code? So that people who really care about the\n> real content, or just don't have the tools for the filters still\n> can checkout the repos depending on the filters.\n\nThe code may have bugs, but the intent is that you can have this\nline in your $GIT_DIR/info/attributes to override whatever\nattribute settings used in .gitattributes files that are\nin-tree:\n\n\t*\t!ident !filter\n"},{"id":"40217","messageId":"Pine.LNX.4.64.0704231924410.8822@racer.site","threadId":"7579","inReplyTo":"81b0412b0704231007i81ee20cx9a37f1c8a3df62b1@mail.gmail.com","subject":"Re: What's cooking in git.git (topics)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-04-23T17:25:18Z","receivedAt":"2007-04-23T17:25:18Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 23 Apr 2007, Alex Riesen wrote:\n\n> On 4/23/07, Junio C Hamano wrote:\n> > * jc/attr (Sat Apr 21 03:14:13 2007 -0700) 2 commits\n> > - Add 'filter' attribute and external filter driver definition.\n> > - Add 'ident' conversion.\n> >\n> > As 'ident' conversion is stateless, I do not mind too much\n> > including it in v1.5.2-rc1. On the other hand, the arbitrary\n> > 'filter' is quite contentious, although the character-code\n> > conversion example I gave myself might be a good enough reason\n> > for people to want it. Undecided.\n> \n> Can I suggest a config option to completely disable content\n> munging code? So that people who really care about the\n> real content, or just don't have the tools for the filters still\n> can checkout the repos depending on the filters.\n\nIn my worldview, these filters are a local thing. Exactly like crlf. So, \nno need for a config option.\n\nCiao,\nDscho\n"},{"id":"40241","messageId":"20070423211658.GA21404@steel.home","threadId":"7579","inReplyTo":"7vvefnf1wb.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's cooking in git.git (topics)","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-04-23T21:16:58Z","receivedAt":"2007-04-23T21:16:58Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Junio C Hamano, Mon, Apr 23, 2007 19:15:16 +0200:\n> >> As 'ident' conversion is stateless, I do not mind too much\n> >> including it in v1.5.2-rc1. On the other hand, the arbitrary\n> >> 'filter' is quite contentious, although the character-code\n> >> conversion example I gave myself might be a good enough reason\n> >> for people to want it. Undecided.\n> >\n> > Can I suggest a config option to completely disable content\n> > munging code? So that people who really care about the\n> > real content, or just don't have the tools for the filters still\n> > can checkout the repos depending on the filters.\n> \n> The code may have bugs, but the intent is that you can have this\n> line in your $GIT_DIR/info/attributes to override whatever\n> attribute settings used in .gitattributes files that are\n> in-tree:\n> \n> \t*\t!ident !filter\n> \n\nImagine a project which started using the attributes at some point of\ntime. And imagine developers whose repos suddenly start breaking\nbecause of clueless integrator created a filter which does not work\nanywere but his system (typical, really) and didn't tell anyone to\nupdate their configuration (whereas .gitattribute files are in working\ntrees already).\n\nHow do you suggest to distribute filter configurations, BTW?\nThey are not cloned (can they?)\nHow about checkout performance impact? (in case they are not active,\nof course. You're hosed anyway if the filters used. Especially if you\nhappen to have real big files).\n"},{"id":"40244","messageId":"7v4pn6ep41.fsf@assigned-by-dhcp.cox.net","threadId":"7579","inReplyTo":"20070423211658.GA21404@steel.home","subject":"Re: What's cooking in git.git (topics)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-04-23T21:51:26Z","receivedAt":"2007-04-23T21:51:26Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Alex Riesen writes:\n\n> Imagine a project which started using the attributes at some point of\n> time. And imagine developers whose repos suddenly start breaking\n> because of clueless integrator created a filter which does not work\n> anywere but his system (typical, really) and didn't tell anyone to\n> update their configuration (whereas .gitattribute files are in working\n> trees already).\n\nThat's one of the reasons why only the filter names are assigned\nto paths using gitattributes mechanism and what action to take\nwhen a specific filter name is attached to a path is determined\nby the config. Missing filter driver definition in the config\nis not an error but makes the filter a no-op passthru.\n\nThe content filtering is to massage the content into a shape\nthat is more convenient for the platform/filesystem/the user to\nuse. The keyword here is \"more convenient\" and not \"usable\"; in\nother words, it is \"hanging yourself because we gave you a long\nrope\" if your project tries to do something with the filtering\nmechanism to make your project unusable unless the checkout is\ndone with specific filter in effect. So defaulting to passthru\nis meant to fall-back on the plain-old inconvenient checkout,\nwhich is not a bad thing.\n\n> How do you suggest to distribute filter configurations, BTW?\n\nThe same project description message the participant learn about\nthe project that says the public repository locations and such,\nand perhaps in-tree READ.ME file.\n\nThe earlier example I gave would fit this pattern rather well.\nIf somebody (me) cannot deal with UTF-8 encoded Japanese text\nvery well, that user personally can mark such a file in\n$GIT_DIR/info/attributes as 'filter=utf8-japanese-text' and\ndefine the iconv based filtering driver in $GIT_DIR/config in\nthe repository that he (me) uses for editing.\n\nIn addition, I would most likely have another repository that\ndoes not have the filtering driver defined, and that would be\nwhere I would run the build tools for documentation part, since\nthe project documentation is supposed to be in UTF-8. \n\nThis is a \"purely personal\" setting that does not have to be\nknown to the outside world. But the filter=utf8-japanese-text\nattribute could be shared in-tree if the project has more then\none person with difficulty dealing with UTF-8 encoded Japanese\ntext. I may personally edit the file after having iconv convert\nto EUC-JP and convert it back to UTF-8 when checking in, but the\nother person may use local encoding different from EUC-JP for\nediting. In such a case, only the definition in our config\nfiles are different, and in-tree Documentation/.gitattributes\nfile would have\n\n\tgit-lost-found.txt\tfilter=utf8-japanese-text\n\nwhich is distributed project-wide.\n\nRepositories used by people who do not have trouble handling\nUTF-8 encoded Japanese text would not have any filtering driver\ndefined for utf8-japanese-text in their $GIT_DIR/config, and\ntheir checkout would be in UTF-8, because of this passthru\nbehaviour.\n\n> How about checkout performance impact?\n\nMeasurement would be interesting; I haven't done it, and that is\none of the smaller reasons I am not particularly keen on pushing\nthe 'filter' attribute. Hawk-eyed people might have noticed\nthat I swapped the order of the series in 'pu' to have 'ident'\nfirst and then 'filter'.\n"},{"id":"40339","messageId":"81b0412b0704240858w6121430fj624582539f14ceee@mail.gmail.com","threadId":"7579","inReplyTo":"7v4pn6ep41.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's cooking in git.git (topics)","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-04-24T15:58:18Z","receivedAt":"2007-04-24T15:58:18Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 4/23/07, Junio C Hamano wrote:\n> Alex Riesen writes:\n>\n> > Imagine a project which started using the attributes at some point of\n> > time. And imagine developers whose repos suddenly start breaking\n> > because of clueless integrator created a filter which does not work\n> > anywere but his system (typical, really) and didn't tell anyone to\n> > update their configuration (whereas .gitattribute files are in working\n> > trees already).\n>\n> That's one of the reasons why only the filter names are assigned\n> to paths using gitattributes mechanism and what action to take\n> when a specific filter name is attached to a path is determined\n> by the config. Missing filter driver definition in the config\n> is not an error but makes the filter a no-op passthru.\n\nFragile. What if content is useless without filter? How does\nthe user know about the fact so he can work the problem\naround?\n\nWhat if you have multiple filters matching the same path?\n(does not seem to be possible. Someone will ask you why)\n\n> The content filtering is to massage the content into a shape\n> that is more convenient for the platform/filesystem/the user to\n> use. The keyword here is \"more convenient\" and not \"usable\"; in\n\nhow can \"not usable\" be \"more convenient\"?\n\n> > How do you suggest to distribute filter configurations, BTW?\n>\n> The same project description message the participant learn about\n> the project that says the public repository locations and such,\n> and perhaps in-tree READ.ME file.\n\nBut there seem to be no way to notice that the READ.ME should\nbe reread by project participants downstream.\n\n> The earlier example I gave would fit this pattern rather well.\n> If somebody (me) cannot deal with UTF-8 encoded Japanese text\n> very well, that user personally can mark such a file in\n> $GIT_DIR/info/attributes as 'filter=utf8-japanese-text' and\n> define the iconv based filtering driver in $GIT_DIR/config in\n> the repository that he (me) uses for editing.\n\nwhich will be a PITA to setup in each and every clone of the\nrepository, unless it is cloned with the repo.\n"},{"id":"40340","messageId":"Pine.LNX.4.64.0704241802420.6954@racer.site","threadId":"7579","inReplyTo":"81b0412b0704240858w6121430fj624582539f14ceee@mail.gmail.com","subject":"Re: What's cooking in git.git (topics)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-04-24T16:04:08Z","receivedAt":"2007-04-24T16:04:08Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 24 Apr 2007, Alex Riesen wrote:\n\n> On 4/23/07, Junio C Hamano wrote:\n>\n> > The earlier example I gave would fit this pattern rather well.\n> > If somebody (me) cannot deal with UTF-8 encoded Japanese text\n> > very well, that user personally can mark such a file in\n> > $GIT_DIR/info/attributes as 'filter=utf8-japanese-text' and\n> > define the iconv based filtering driver in $GIT_DIR/config in\n> > the repository that he (me) uses for editing.\n> \n> which will be a PITA to setup in each and every clone of the\n> repository, unless it is cloned with the repo.\n\nNot if you do it with templates. If it is such a special case that you \nabsolutely _need_ filters, and cannot use it without filters, it is \nprobably in a very small group. And there, you just setup the templates, \nand voila: you have your filters without much ado.\n\nCiao,\nDscho\n"},{"id":"40341","messageId":"81b0412b0704240914o1096476dn7f26210be987e3fd@mail.gmail.com","threadId":"7579","inReplyTo":"Pine.LNX.4.64.0704241802420.6954@racer.site","subject":"Re: What's cooking in git.git (topics)","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-04-24T16:14:31Z","receivedAt":"2007-04-24T16:14:31Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 4/24/07, Johannes Schindelin wrote:\n> >\n> > which will be a PITA to setup in each and every clone of the\n> > repository, unless it is cloned with the repo.\n>\n> Not if you do it with templates. If it is such a special case that you\n> absolutely _need_ filters, and cannot use it without filters, it is\n> probably in a very small group. And there, you just setup the templates,\n> and voila: you have your filters without much ado.\n\nIt can be a very big group. Than, even if it is the only group in the world,\nit can complain loud and long enough to become a major annoyance.\n"},{"id":"40346","messageId":"Pine.LNX.4.64.0704241843440.6954@racer.site","threadId":"7579","inReplyTo":"81b0412b0704240914o1096476dn7f26210be987e3fd@mail.gmail.com","subject":"Re: What's cooking in git.git (topics)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-04-24T16:44:33Z","receivedAt":"2007-04-24T16:44:33Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 24 Apr 2007, Alex Riesen wrote:\n\n> On 4/24/07, Johannes Schindelin wrote:\n> > >\n> > > which will be a PITA to setup in each and every clone of the\n> > > repository, unless it is cloned with the repo.\n> >\n> > Not if you do it with templates. If it is such a special case that you \n> > absolutely _need_ filters, and cannot use it without filters, it is \n> > probably in a very small group. And there, you just setup the \n> > templates, and voila: you have your filters without much ado.\n> \n> It can be a very big group. Than, even if it is the only group in the \n> world, it can complain loud and long enough to become a major annoyance.\n\nYes, they can.\n\nAnd if we can prove that it would have been cleaner and better and more \nstable to do the same without attributes, they will look like a big group \nof total morons.\n\nCiao,\nDscho\n"},{"id":"40369","messageId":"7vwt014fib.fsf@assigned-by-dhcp.cox.net","threadId":"7579","inReplyTo":"81b0412b0704240858w6121430fj624582539f14ceee@mail.gmail.com","subject":"Re: What's cooking in git.git (topics)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-04-24T21:41:16Z","receivedAt":"2007-04-24T21:41:16Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Alex Riesen\" writes:\n\n> On 4/23/07, Junio C Hamano wrote:\n>> ...\n>> That's one of the reasons why only the filter names are assigned\n>> to paths using gitattributes mechanism and what action to take\n>> when a specific filter name is attached to a path is determined\n>> by the config. Missing filter driver definition in the config\n>> is not an error but makes the filter a no-op passthru.\n>\n> Fragile. What if content is useless without filter?\n\nIn that case, the project screwed itself and it is not our\nproblem anymore ;-).\n\n>> The content filtering is to massage the content into a shape\n>> that is more convenient for the platform/filesystem/the user to\n>> use. The keyword here is \"more convenient\" and not \"usable\"; in\n>\n> how can \"not usable\" be \"more convenient\"?\n\nI think I worded it incorrectly to be misunderstood, but I\ncouldn't word them better then, I do not know I can word them\nbetter now.\n\nSomething could be 1. unusable, or 2. usable. Among usable\nshapes, there are 2-a. inconvenient but usable and 2-b. very\nconvenient to use.\n\nWhat I tried to say was that if you use filtering mechanism to\nmassage contents that is unusable into usable (i.e. crossing\nfrom 1 to 2), you are already misusing the mechanism (but we do\nnot prevent you because we are only \"giving you a long rope\").\nThe filter is meant to be used to cross from 2-a to 2-b.\n"},{"id":"40385","messageId":"81b0412b0704250111h6eb0dbefh47867f4dfd7a4ee@mail.gmail.com","threadId":"7579","inReplyTo":"7vwt014fib.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's cooking in git.git (topics)","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-04-25T08:11:37Z","receivedAt":"2007-04-25T08:11:37Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 4/24/07, Junio C Hamano wrote:\n> >> The content filtering is to massage the content into a shape\n> >> that is more convenient for the platform/filesystem/the user to\n> >> use. The keyword here is \"more convenient\" and not \"usable\"; in\n> >\n> > how can \"not usable\" be \"more convenient\"?\n>\n> I think I worded it incorrectly to be misunderstood, but I\n> couldn't word them better then, I do not know I can word them\n> better now.\n>\n\nYou don't have to. I just can't force myself to believe it can be\nmade useful. I'll shut up for now, and wait until I or someone else\nproves the code has negligible negative impact on the normal\nusage scenarios.\n"}]}