Hi Junio, On Thu, 18 Jul 2019, Junio C Hamano wrote: > "Johannes Schindelin via GitGitGadget" <gitgitgadget@xxxxxxxxx> > writes: > > > From: Johannes Schindelin <johannes.schindelin@xxxxxx> > > > > It is a real old anachronism from the Cogito days to have a > > .git/branches/ directory. And to have tests that ensure that Cogito > > users can migrate away from using that directory. > > > > But so be it, let's continue testing it. > > > > Let's make sure, however, that git init does not need to create that > > directory. > > > > This bug was noticed when testing with templates that had been > > pre-committed, skipping the empty branches/ directory of course because > > Git does not track empty directories. > > Many tests assume that the .git/info/ directory exists, and the only > reason why they can is because we have templates/info--exclude; the > situation around .git/branches/ is exactly the same. No, the situation with `info/` is that it includes a file called `exclude`, which means that the `templates/` directory can be "tracked". This is important because we want to commit all those generated files that cannot be generated inside Visual Studio without Git for Windows' SDK (which weighs in with several hundred megabytes to download, a gigabyte on disk). The `branches/` subdirectory, in contrast, is totally useless for at least 99.999% of the users, and hence it is understandable that it does not even contain a single file. Which means that it is *not* "tracked". So when checking out, e.g. the `vs/master` branch at https://github.com/git-for-windows/git, which is auto-generated using this here patch series from Git for Windows' `master`, to allow building in Visual Studio without having to download the full Git for Windows SDK, there will be the `info/` directory (by virtue of containing a trackable file) exists, and the `branches/` subdirectory won't exist. As a consequence, the test scripts indicated in the commit message, which _can_ be run in a regular Git for Windows (no Git for Windows SDK required), will fail without this patch. > Deprecating .git/branches/ directory and dropping the parts of tests > that wants to make sure the support still works (t5516 is not about > migration but about working with .git/branches configuration) would > be a different matter. Indeed. You probably forgot that I already proposed that, long time ago: https://public-inbox.org/git/cover.1494509599.git.johannes.schindelin@xxxxxx/ I haven't forgotten, because you shot it down unceremoniously: The last time I thought about trying this several years ago, I found that people who need to grab things from many places still do use .git/branches/ and their use case is hard to migrate to .git/config, primarily because the former is "one per file" and it is easy to add/remove/tweak without affecting others. Ask akpm@ if he still prefers to use .git/branches/ for example. Of course, with such a kind of argument, there is no way how I could possibly prove that it is no longer advisable to have `.git/branches/`. "Someone, somewhere _probably_ finds this still useful, so we won't remove it." > Until that happens, let's not do this patch; Well, that's another of these type of arguments. Without this patch, and without removing support for `.git/branches/`, you force the Visual Studio build to _not_ pass the test suite. It's as simple as that. So basically, by this statement you decided that there will not be a fully-functional way to build Git in Visual Studio and to pass the test suite with that. Which is a shame. > otherwise it would force us to sprinkle "mkdir -p .git/info/" all > over the place for the same rationale. You may have assumed that I did not carefully verify that the test suite passes with these patches. But I did. And I would not have submitted this patch series if such a patch was necessary, at least not without said patch. > A directory in .git/ created by hardcoded mkdir in "git init" (like > .git/refs/) and created by copying templates by "git init" (like > .git/info/ and .git/branches) are both "created by 'git init'". > Special casing the latter is just silly. The thing that _really_ is silly is that we have that directory in Git's templates, still. Git itself does not populate it. Git does not need it, ever. Git works Just Fine without it, and it is really by design that it does not require the presence of that subdirectory. Only those two test cases insist, for some reason that escapes me, on the presence of those subdirectories. As I said, Git does not populate that subdirectory. It even lacks all facilities to populate it. You have to write the files inside it yourself, you have to figure out the syntax of the files in that directory, and the only place where we document this is buried deeply in `Documentation/gitrepository-layout.txt`. It is a bit silly, too, that we say there, in that very documentation for that very feature, that this feature is "slightly deprecated". Either it is deprecated, or it isn't. Further, it is a bit silly that this "slight deprecation" has been there since a1d4aa74241 (Add repository-layout document., 2005-09-01). In other words, that feature was "slightly deprecated" already a mere five months after Git was made public. Yet we still shlep it around, fourteen (!) years later. In yet other words, the support for `.git/branches` has been "slightly deprecated" more than 33x longer than it hasn't been. I just wish that my patches to remove the support for `.git/branches` would have gone somewhere useful instead of into this ugly impasse. Ciao, Dscho
