Hi, On Thu, 8 Aug 2024, Junio C Hamano wrote: > Phil Sainty <phil@xxxxxxxxxxxxxxx> writes: > > >> On Wed, Jun 20, 2018 at 1:55 PM Rafael Ascensão <rafa.almas@xxxxxxxxx> wrote: > >> > On Wed, Jun 20, 2018 at 5:39 AM Kevin Daudt <me@xxxxxxxxx> wrote: > >> > > What this is about that when doing `git add path/` (with trailing /), > >> > > >> > This is what I was referring to. If you search for 'Fake Submodules', > >> > you'll see that some people were/are intentionally using this instead of > >> > subtrees or submodules. Unfortunately the original article [1] seems to > >> > be dead, but searching url in the mailing list archives leads to some > >> > additional discussion on the subject [2,3]. > >> > >> Abusing a long standing bug does not make it a feature. I'm not > >> opposed to having a new option to keep that behavior, but it should > >> not be the default. If you use it that way, you're on your own. > > > > Was such an option ever worked on? > > No. > > I do not recall hearing anybody who have been active in the > development community saying anything good about such an option. > For the past 6 or so years, nobody who actively works on git thought > it was an interesting and/or useful thing to work on. > > I cannot quite say that they thought that it is actively a bad idea > to offer such an option, though. I have encountered the wish quite frequently to be able to make changes in a subdirectory and have them reflected as a commit that is both part of that subdirectory's revision history as well as part of the containing project's. The benefits for monorepos, and for reproducible builds, are probably obvious. Sadly, I cannot think of an elegant technical design, and this is not for lack of trying. There are lots of projects I worked on that would have benefitted from being able to track a subdirectory both independently as well as within the context of a containing project, i.e. offering to view (and fetch/push) the changesets in both contexts as equal first citizens. Even the Git and libxdiff projects, as a concrete example, could potentially have benefitted from such a feature: Ideally, it should be possible to push commits made in the `xdiff/` directory not only to the git/git repository but also separately from the rest of Git, say, to xdiff/libxdiff. This way, the `libxdiff` project would still be able today to thrive as an independent project. The only way to implement a feature like this that I _can_ think of is to generate duplicate commit objects, though, with a reference to the "inner" commit stored in the "outer" commit object. And that strategy breaks down really quickly, no matter whether I think about deep dependency trees or about integrating commit histories that have been made in the "inner" project separately and now need to be merged into the "outer" project, and there are many more processes for which this strategy strikes me as inadequate. So yes, I think that the idea per se has a lot of merit in the real world out there. It's the implementation details that are an obstacle. Ciao, Johannes
