On Fri, Mar 18, 2016 at 12:24 PM, Jeff King <peff@xxxxxxxx> wrote: > On Thu, Mar 17, 2016 at 06:11:36PM +0700, Duy Nguyen wrote: > >> Git's top directory is crowded and I think it's agreed that moving >> test-* to t/helper is a good move. I just wanted to check if we could >> take this opportunity (after v2.8.0) to move some other files too. I >> propose the following new subdirs > > I guess I don't really see the "crowded" problem, but perhaps that is > because I am more or less familiar with where things are in git's code > base. I suppose if you were looking for a "utility" function, you might > look in "util" and therefore have a smaller set of files to check. > > But I think we also run into the opposite problem: I am looking for some > particular function, but I can't find it, because I am looking in "util" > and it is in some other directory. And when files move around, it makes > history harder to follow (maybe that is because git sucks and we need to > make it better, but certainly I run into mild annoyances with the > builtin/ rename when digging in history). Yeah, for finding a particular function, I just "git grep" (or rgrep from emacs) if I fail to locate it after the first guess. We have this problem nowadays anyway. Besides builtin, we also have ewah, refs and some more subdirs. > And you have a similar problem when creating new files. Which slot do > they go in? What if they could feasibly go into two slots? Everything goes to topdir (or later on "src") by default and only goes to "lib" when it's _obvious_ that it's disconnected from git (i'm talking about the "lib/src" layout). > So there can be friction either way. In practice I find I just use ctags > to jump to the functions I am interested in, and I don't care that much > about filenames. > > The reorganization that _would_ be more interesting to me is not files > in directories, but rather functions in files. I wish everything were > designed more as modules with a pair of matching ".c" and ".h" files, > with a public interface defined in the ".h", and messier, private stuff > in the ".c". But we have some real dumping grounds: > > 1. cache.h has the declarations for at least a dozen different > modules; besides being hard to navigate, it causes more frequent > recompilation than necessary. > > 2. a few of the .c files could probably be split (e.g., dir.c is where > all of the pathspec code lives, even though that is used for much > more than filesystem access these days). Heh.. that's what I wanted to do (or at least discuss) after files are moved :) > Splitting those up would _also_ introduce friction (and actually worse > than whole-file renames, because finding code movement between files is > an even harder / more expensive problem). .. and this is why I did not raise it in the first mail. > But I feel like it would buy a > lot more in terms of code clarity, and in reducing the scope of code > which has access to private, static interfaces. -- Duy -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html