{"thread":{"id":"41726","subject":"[RFC] Code reorgnization","startedAt":"2016-03-17T11:11:36Z","lastAt":"2016-03-18T05:59:25Z","messageCount":14,"participants":["Duy Nguyen","Johannes Schindelin","Junio C Hamano","Thomas Adam","Stefan Beller","Pranit Bauva","John Keeping","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"281024","messageId":"20160317111136.GA21745@lanh","threadId":"41726","inReplyTo":null,"subject":"[RFC] Code reorgnization","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2016-03-17T11:11:36Z","receivedAt":"2016-03-17T11:11:36Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"Git's top directory is crowded and I think it's agreed that moving\ntest-* to t/helper is a good move. I just wanted to check if we could\ntake this opportunity (after v2.8.0) to move some other files too. I\npropose the following new subdirs\n\nlib\n---\nThis contains files that are about data structures or algorithms. Very\ngeneral purpose. This directory includes\n\nargv-array.[ch] base85.c column.[ch] delta.h diff-delta.c hashmap.[ch]\nhex.c khash.h kwset.[ch] levenshtein.[ch] mergesort.[ch] patch-delta.c\nprio-queue.[ch] sha1-array.[ch] sha1-lookup.[ch] strbuf.[ch]\nstring-list.[ch] url.[ch] urlmatch.[ch] utf8.[ch] varint.[ch]\nversioncmp.c wildmatch.[ch]\n\nodb\n---\nThe grouping of object database files is to easily make connections\nbetween them. Unlike, for example, diff-related files which either\nstart with \"diff\" or has that word in the file name to make\nconnections.\n\nalloc.c blob.[ch] bulk-checkin.[ch] commit-slab.h commit.[ch]\nobject.[ch] pack.h pack-revindex.[ch] replace_object.c sha1_file.c\nstreaming.[ch] tag.[ch] tree.[ch]\n\nindex\n-----\nFor the same reason of odb subdir. This directory contains\n\ncache-tree.[ch] name-hash.c preload-index.c read-cache.c\nsplit-index.[ch] unpack-trees.[ch]\n\nsys (or maybe util or support)\n------------------------------\nThese are still general purpose but is usually system-related. They\nare still far away from git's core logic. I want to separate them to\nmake it easier to spot \"important\" files at top dir.\n\nabspath.c color.[ch] copy.c csum-file.[ch] ctype.c date.c editor.c\nexec_cmd.[ch] gettext.[ch] gettext.h gpg-interface.[ch] ident.c\nlockfile.[ch] mailinfo.[ch] mailmap.[ch] pager.c parse-options-cb.c\nparse-options.[ch] pathspec.[ch] pkt-line.[ch] progress.[ch]\nprompt.[ch] quote.[ch] run-command.[ch] sideband.[ch] sigchain.[ch]\nsymlinks.c tar.h tempfile.[ch] thread-utils.[ch] trace.[ch]\nunix-socket.[ch] usage.c userdiff.[ch] wrapper.c write_or_die.c zlib.c\n\nGood? Bad? Ugly?\n--\nDuy\n"},{"id":"281039","messageId":"alpine.DEB.2.20.1603171431000.4690@virtualbox","threadId":"41726","inReplyTo":"20160317111136.GA21745@lanh","subject":"Re: [RFC] Code reorgnization","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2016-03-17T13:32:39Z","receivedAt":"2016-03-17T13:32:39Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Duy,\n\nOn Thu, 17 Mar 2016, Duy Nguyen wrote:\n\n> Git's top directory is crowded and I think it's agreed that moving\n> test-* to t/helper is a good move. I just wanted to check if we could\n> take this opportunity (after v2.8.0) to move some other files too. I\n> propose the following new subdirs\n> \n> lib\n> ---\n> This contains files that are about data structures or algorithms. Very\n> general purpose. This directory includes\n> \n> argv-array.[ch] base85.c column.[ch] delta.h diff-delta.c hashmap.[ch]\n> hex.c khash.h kwset.[ch] levenshtein.[ch] mergesort.[ch] patch-delta.c\n> prio-queue.[ch] sha1-array.[ch] sha1-lookup.[ch] strbuf.[ch]\n> string-list.[ch] url.[ch] urlmatch.[ch] utf8.[ch] varint.[ch]\n> versioncmp.c wildmatch.[ch]\n\nThe name \"lib\" makes it sound as if this contains the source code of\nlibgit.a. Maybe \"generic\" or \"common\" or \"util\" would be better (my\nfavorite would be \"util\").\n\n> odb\n> ---\n> The grouping of object database files is to easily make connections\n> between them. Unlike, for example, diff-related files which either\n> start with \"diff\" or has that word in the file name to make\n> connections.\n> \n> alloc.c blob.[ch] bulk-checkin.[ch] commit-slab.h commit.[ch]\n> object.[ch] pack.h pack-revindex.[ch] replace_object.c sha1_file.c\n> streaming.[ch] tag.[ch] tree.[ch]\n> \n> index\n> -----\n> For the same reason of odb subdir. This directory contains\n> \n> cache-tree.[ch] name-hash.c preload-index.c read-cache.c\n> split-index.[ch] unpack-trees.[ch]\n> \n> sys (or maybe util or support)\n> ------------------------------\n> These are still general purpose but is usually system-related. They\n> are still far away from git's core logic. I want to separate them to\n> make it easier to spot \"important\" files at top dir.\n> \n> abspath.c color.[ch] copy.c csum-file.[ch] ctype.c date.c editor.c\n> exec_cmd.[ch] gettext.[ch] gettext.h gpg-interface.[ch] ident.c\n> lockfile.[ch] mailinfo.[ch] mailmap.[ch] pager.c parse-options-cb.c\n> parse-options.[ch] pathspec.[ch] pkt-line.[ch] progress.[ch]\n> prompt.[ch] quote.[ch] run-command.[ch] sideband.[ch] sigchain.[ch]\n> symlinks.c tar.h tempfile.[ch] thread-utils.[ch] trace.[ch]\n> unix-socket.[ch] usage.c userdiff.[ch] wrapper.c write_or_die.c zlib.c\n> \n> Good? Bad? Ugly?\n\nDisruptive. Probably a change for 3.0?\n\nCiao,\nDscho\n"},{"id":"281040","messageId":"CACsJy8BFdk6jtRqSKE0ThtcZi39hHC_QbDx6oka0qWk7eiD4wQ@mail.gmail.com","threadId":"41726","inReplyTo":"alpine.DEB.2.20.1603171431000.4690@virtualbox","subject":"Re: [RFC] Code reorgnization","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2016-03-17T13:35:53Z","receivedAt":"2016-03-17T13:35:53Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Thu, Mar 17, 2016 at 8:32 PM, Johannes Schindelin\n wrote:\n>> Good? Bad? Ugly?\n>\n> Disruptive. Probably a change for 3.0?\n\nWe tested it with the builtin rename a long time ago, so it's probably\nnot bad. By the principle of \"dogfooding\", we should try it soon and\nmake sure it's not disruptive, or prepare ourselves for such a change\n(I think git-am can't track renames, for example, without us giving it\na clue somehow)\n-- \nDuy\n"},{"id":"281048","messageId":"xmqqbn6d13f5.fsf@gitster.mtv.corp.google.com","threadId":"41726","inReplyTo":"20160317111136.GA21745@lanh","subject":"Re: [RFC] Code reorgnization","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-03-17T16:21:02Z","receivedAt":"2016-03-17T16:21:02Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Duy Nguyen writes:\n\n> Good? Bad? Ugly?\n\nToo fine-grained to induce confusion for things that have to work as\na bridge between two categories (e.g. odb & index). In short, bad\nand ugly.\n\nI am OK with a looser classification e.g. (1) things that can be\nused without Git at all like strbuf, string-list vs (2) things that\nare Git but shared across different subcommands like read-cache,\nsha1_file, vs (3) command implementations (e.g. builtin/ and also\nstandalone).\n"},{"id":"281055","messageId":"CA+39Oz6jNwcyCQFiakh=Ech6p8UYRW9pn95e6cTGXf8nFcwwWQ@mail.gmail.com","threadId":"41726","inReplyTo":"20160317111136.GA21745@lanh","subject":"Re: [RFC] Code reorgnization","fromName":"Thomas Adam","fromEmail":"thomas@xteddy.org","sentAt":"2016-03-17T17:00:03Z","receivedAt":"2016-03-17T17:00:03Z","isPatch":false,"sender":{"key":"thomas@xteddy.org","avatar":"https://gravatar.com/avatar/e7256db4738e501e5d2e84f00bb0bd99503165729573848a03330301fc2adc4a?d=mp&s=160"},"body":"On 17 March 2016 at 11:11, Duy Nguyen wrote:\n> Git's top directory is crowded and I think it's agreed that moving\n> test-* to t/helper is a good move. I just wanted to check if we could\n> take this opportunity (after v2.8.0) to move some other files too. I\n> propose the following new subdirs\n\nI wonder whether previous discussions on this still count? See:\n\nhttp://marc.info/?l=git&m=129650572621523&w=1\n\n-- Thomas Adam\n"},{"id":"281056","messageId":"xmqq7fh10zcp.fsf@gitster.mtv.corp.google.com","threadId":"41726","inReplyTo":"CA+39Oz6jNwcyCQFiakh=Ech6p8UYRW9pn95e6cTGXf8nFcwwWQ@mail.gmail.com","subject":"Re: [RFC] Code reorgnization","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-03-17T17:48:54Z","receivedAt":"2016-03-17T17:48:54Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Thomas Adam writes:\n\n> On 17 March 2016 at 11:11, Duy Nguyen wrote:\n>> Git's top directory is crowded and I think it's agreed that moving\n>> test-* to t/helper is a good move. I just wanted to check if we could\n>> take this opportunity (after v2.8.0) to move some other files too. I\n>> propose the following new subdirs\n>\n> I wonder whether previous discussions on this still count? See:\n>\n> http://marc.info/?l=git&m=129650572621523&w=1\n\nIf you refer to ancient discussion, especially to a large thread\nlike that one, please spend a bit more time to summarize it. It\nis between one person spends a bit more time, and all others\nindependently go there and read.\n\nThe essense of the proposal [1] back then was to move all the source\nfile to src/, rename t/ to testsuite. And I think [2] is a pretty\ngood summary of the common feeling back then that explains why the\nproposal died out:\n\n Moving everything into src/ and calling it \"organized\" doesn't\n actually accomplish much other than perhaps making the README\n file more visible to newbs; things are _still_ a mess, just a\n mess with four more letters...\n\nThis round is slightly more organized, so many points the old thread\nraised would not apply, I suspect.\n\n\n[References]\n\n*1* http://thread.gmane.org/gmane.comp.version-control.git/165720/focus=165748\n\n*2* http://thread.gmane.org/gmane.comp.version-control.git/165720/focus=166019\n"},{"id":"281065","messageId":"CAGZ79kbcwFcPSJ9xwE6xi4gQ871m3brtfAut2TChGNzL-foxdQ@mail.gmail.com","threadId":"41726","inReplyTo":"20160317111136.GA21745@lanh","subject":"Re: [RFC] Code reorgnization","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2016-03-17T18:37:39Z","receivedAt":"2016-03-17T18:37:39Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Thu, Mar 17, 2016 at 4:11 AM, Duy Nguyen wrote:\n> Good? Bad? Ugly?\n\nFor now I would just go with 3 directories:\n\nnon-git/ (or util, helpers, or anything that could be ripped out and be useful\n e.g. strbufs, argv-array run-command, lockfile\ngit/ (maybe called lib? All stuff that is pure Git and is used for libgit\n\nbuiltin/ (as we have it today + all that stuff that doesn't go into\ngit/ very well?)\n\nThanks,\nStefan\n"},{"id":"281078","messageId":"xmqqy49gzzrf.fsf@gitster.mtv.corp.google.com","threadId":"41726","inReplyTo":"CAGZ79kbcwFcPSJ9xwE6xi4gQ871m3brtfAut2TChGNzL-foxdQ@mail.gmail.com","subject":"Re: [RFC] Code reorgnization","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-03-17T19:10:44Z","receivedAt":"2016-03-17T19:10:44Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Stefan Beller writes:\n\n> For now I would just go with 3 directories:\n>\n> non-git/ (or util, helpers, or anything that could be ripped out and be useful\n> e.g. strbufs, argv-array run-command, lockfile\n> git/ (maybe called lib? All stuff that is pure Git and is used for libgit\n>\n> builtin/ (as we have it today + all that stuff that doesn't go into\n> git/ very well?)\n\nIt is unclear where you want to have standalone programs in the\nabove. I'd say lib/ and src/ for the first two, where lib/ is for\nthings that could be lifted without any Git dependencies and src/\nfor everything else.\n\nAren't there some folks who link directly with our codebase (I am\nthinking about cgit, but hjemli.net/git/cgit does not seem to be\nresponding anymore)?\n"},{"id":"281081","messageId":"CAFZEwPMBr4oK9tM7rMsBUDhON-0+jymGT=t1sdkztbh3eNyt5g@mail.gmail.com","threadId":"41726","inReplyTo":"xmqqy49gzzrf.fsf@gitster.mtv.corp.google.com","subject":"Re: [RFC] Code reorgnization","fromName":"Pranit Bauva","fromEmail":"pranit.bauva@gmail.com","sentAt":"2016-03-17T21:03:27Z","receivedAt":"2016-03-17T21:03:27Z","isPatch":false,"sender":{"key":"pranit.bauva@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2959938?v=4"},"body":"On Fri, Mar 18, 2016 at 12:40 AM, Junio C Hamano wrote:\n> Stefan Beller writes:\n>\n>> For now I would just go with 3 directories:\n>>\n>> non-git/ (or util, helpers, or anything that could be ripped out and be useful\n>> e.g. strbufs, argv-array run-command, lockfile\n>> git/ (maybe called lib? All stuff that is pure Git and is used for libgit\n>>\n>> builtin/ (as we have it today + all that stuff that doesn't go into\n>> git/ very well?)\n>\n> It is unclear where you want to have standalone programs in the\n> above. I'd say lib/ and src/ for the first two, where lib/ is for\n> things that could be lifted without any Git dependencies and src/\n> for everything else.\n>\n> Aren't there some folks who link directly with our codebase (I am\n> thinking about cgit, but hjemli.net/git/cgit does not seem to be\n> responding anymore)?\n\nThey now have a new mailing list.[1] I guess they forward all the\nmails to the new one[2]. The new one seems active. [3]\n\n[1] : cgit@lists.zx2c4.com\n[2] : https://lists.zx2c4.com/pipermail/cgit/2013-May/001380.html\n[3] : http://news.gmane.org/gmane.comp.version-control.cgit\n"},{"id":"281083","messageId":"20160317214355.GA32317@serenity.lan","threadId":"41726","inReplyTo":"xmqqy49gzzrf.fsf@gitster.mtv.corp.google.com","subject":"Re: [RFC] Code reorgnization","fromName":"John Keeping","fromEmail":"john@keeping.me.uk","sentAt":"2016-03-17T21:43:55Z","receivedAt":"2016-03-17T21:43:55Z","isPatch":false,"sender":{"key":"john@keeping.me.uk","avatar":"https://avatars.githubusercontent.com/u/1702081?v=4"},"body":"On Thu, Mar 17, 2016 at 12:10:44PM -0700, Junio C Hamano wrote:\n> Stefan Beller writes:\n> \n> > For now I would just go with 3 directories:\n> >\n> > non-git/ (or util, helpers, or anything that could be ripped out and be useful\n> > e.g. strbufs, argv-array run-command, lockfile\n> > git/ (maybe called lib? All stuff that is pure Git and is used for libgit\n> >\n> > builtin/ (as we have it today + all that stuff that doesn't go into\n> > git/ very well?)\n> \n> It is unclear where you want to have standalone programs in the\n> above. I'd say lib/ and src/ for the first two, where lib/ is for\n> things that could be lifted without any Git dependencies and src/\n> for everything else.\n> \n> Aren't there some folks who link directly with our codebase (I am\n> thinking about cgit, but hjemli.net/git/cgit does not seem to be\n> responding anymore)?\n\nCGit lives at https://git.zx2c4.com/cgit/ these days.\n\nThe organisation of the git code shouldn't make a difference since CGit\njust links with libgit.a, even if it does CGit pulls in git.git as a\nsubmodule so it can just fix any problems in the same commit that\nupdates the submodule reference.\n"},{"id":"281087","messageId":"xmqqh9g4zsf8.fsf@gitster.mtv.corp.google.com","threadId":"41726","inReplyTo":"20160317214355.GA32317@serenity.lan","subject":"Re: [RFC] Code reorgnization","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-03-17T21:49:15Z","receivedAt":"2016-03-17T21:49:15Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"John Keeping writes:\n\n> The organisation of the git code shouldn't make a difference since CGit\n> just links with libgit.a, even if it does CGit pulls in git.git as a\n> submodule so it can just fix any problems in the same commit that\n> updates the submodule reference.\n\nI was mostly worried about where Duy and Stefan want to place *.h\n"},{"id":"281101","messageId":"CACsJy8Bt211aSusEZ0xTDS96ZQgCjrMi-sDmZXkz_jCuUnkcTA@mail.gmail.com","threadId":"41726","inReplyTo":"xmqqh9g4zsf8.fsf@gitster.mtv.corp.google.com","subject":"Re: [RFC] Code reorgnization","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2016-03-18T00:28:22Z","receivedAt":"2016-03-18T00:28:22Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Fri, Mar 18, 2016 at 4:49 AM, Junio C Hamano wrote:\n> John Keeping writes:\n>\n>> The organisation of the git code shouldn't make a difference since CGit\n>> just links with libgit.a, even if it does CGit pulls in git.git as a\n>> submodule so it can just fix any problems in the same commit that\n>> updates the submodule reference.\n>\n> I was mostly worried about where Duy and Stefan want to place *.h\n\n*.h stay with their *.c. CFLAGS has two more -Isrc and -Ilib. I don't\nexpect any #include line changes. Maybe we can start moving stuff to\n\"lib\" soon. Many of them rarely receive changes these days. The\ncreation of \"src\" could be more disruptive and can wait until\n$(topdir) is once again unbearable.\n-- \nDuy\n"},{"id":"281117","messageId":"20160318052447.GD22327@sigill.intra.peff.net","threadId":"41726","inReplyTo":"20160317111136.GA21745@lanh","subject":"Re: [RFC] Code reorgnization","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-03-18T05:24:47Z","receivedAt":"2016-03-18T05:24:47Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Mar 17, 2016 at 06:11:36PM +0700, Duy Nguyen wrote:\n\n> Git's top directory is crowded and I think it's agreed that moving\n> test-* to t/helper is a good move. I just wanted to check if we could\n> take this opportunity (after v2.8.0) to move some other files too. I\n> propose the following new subdirs\n\nI guess I don't really see the \"crowded\" problem, but perhaps that is\nbecause I am more or less familiar with where things are in git's code\nbase. I suppose if you were looking for a \"utility\" function, you might\nlook in \"util\" and therefore have a smaller set of files to check.\n\nBut I think we also run into the opposite problem: I am looking for some\nparticular function, but I can't find it, because I am looking in \"util\"\nand it is in some other directory. And when files move around, it makes\nhistory harder to follow (maybe that is because git sucks and we need to\nmake it better, but certainly I run into mild annoyances with the\nbuiltin/ rename when digging in history).\n\nAnd you have a similar problem when creating new files. Which slot do\nthey go in? What if they could feasibly go into two slots?\n\nSo there can be friction either way. In practice I find I just use ctags\nto jump to the functions I am interested in, and I don't care that much\nabout filenames.\n\nThe reorganization that _would_ be more interesting to me is not files\nin directories, but rather functions in files. I wish everything were\ndesigned more as modules with a pair of matching \".c\" and \".h\" files,\nwith a public interface defined in the \".h\", and messier, private stuff\nin the \".c\". But we have some real dumping grounds:\n\n 1. cache.h has the declarations for at least a dozen different\n modules; besides being hard to navigate, it causes more frequent\n recompilation than necessary.\n\n 2. a few of the .c files could probably be split (e.g., dir.c is where\n all of the pathspec code lives, even though that is used for much\n more than filesystem access these days).\n\nSplitting those up would _also_ introduce friction (and actually worse\nthan whole-file renames, because finding code movement between files is\nan even harder / more expensive problem). But I feel like it would buy a\nlot more in terms of code clarity, and in reducing the scope of code\nwhich has access to private, static interfaces.\n\n-Peff\n"},{"id":"281124","messageId":"CACsJy8AmrdVeB95RUbVPamM7DMxFKRJ9REd0SN_oq_4HEb6E9g@mail.gmail.com","threadId":"41726","inReplyTo":"20160318052447.GD22327@sigill.intra.peff.net","subject":"Re: [RFC] Code reorgnization","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2016-03-18T05:59:25Z","receivedAt":"2016-03-18T05:59:25Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Fri, Mar 18, 2016 at 12:24 PM, Jeff King wrote:\n> On Thu, Mar 17, 2016 at 06:11:36PM +0700, Duy Nguyen wrote:\n>\n>> Git's top directory is crowded and I think it's agreed that moving\n>> test-* to t/helper is a good move. I just wanted to check if we could\n>> take this opportunity (after v2.8.0) to move some other files too. I\n>> propose the following new subdirs\n>\n> I guess I don't really see the \"crowded\" problem, but perhaps that is\n> because I am more or less familiar with where things are in git's code\n> base. I suppose if you were looking for a \"utility\" function, you might\n> look in \"util\" and therefore have a smaller set of files to check.\n>\n> But I think we also run into the opposite problem: I am looking for some\n> particular function, but I can't find it, because I am looking in \"util\"\n> and it is in some other directory. And when files move around, it makes\n> history harder to follow (maybe that is because git sucks and we need to\n> make it better, but certainly I run into mild annoyances with the\n> builtin/ rename when digging in history).\n\nYeah, for finding a particular function, I just \"git grep\" (or rgrep\nfrom emacs) if I fail to locate it after the first guess. We have this\nproblem nowadays anyway. Besides builtin, we also have ewah, refs and\nsome more subdirs.\n\n> And you have a similar problem when creating new files. Which slot do\n> they go in? What if they could feasibly go into two slots?\n\nEverything goes to topdir (or later on \"src\") by default and only goes\nto \"lib\" when it's _obvious_ that it's disconnected from git (i'm\ntalking about the \"lib/src\" layout).\n\n> So there can be friction either way. In practice I find I just use ctags\n> to jump to the functions I am interested in, and I don't care that much\n> about filenames.\n>\n> The reorganization that _would_ be more interesting to me is not files\n> in directories, but rather functions in files. I wish everything were\n> designed more as modules with a pair of matching \".c\" and \".h\" files,\n> with a public interface defined in the \".h\", and messier, private stuff\n> in the \".c\". But we have some real dumping grounds:\n>\n> 1. cache.h has the declarations for at least a dozen different\n> modules; besides being hard to navigate, it causes more frequent\n> recompilation than necessary.\n>\n> 2. a few of the .c files could probably be split (e.g., dir.c is where\n> all of the pathspec code lives, even though that is used for much\n> more than filesystem access these days).\n\nHeh.. that's what I wanted to do (or at least discuss) after files are moved :)\n\n> Splitting those up would _also_ introduce friction (and actually worse\n> than whole-file renames, because finding code movement between files is\n> an even harder / more expensive problem).\n\n.. and this is why I did not raise it in the first mail.\n\n> But I feel like it would buy a\n> lot more in terms of code clarity, and in reducing the scope of code\n> which has access to private, static interfaces.\n-- \nDuy\n"}]}