Hi Junio, On Fri, 31 May 2019, Junio C Hamano wrote:
> [...] as I said in "What's cooking" report one issue ago, the criteria > is no longer "this is obviously correct"---it is "this is obvious and > trivial fix for a regression". I heard that, just wanted to give you my stance ;-) In Git for Windows, I am not *quite* as conservative, but then, I do not have to deal with the onslaught of a gazillion patch series, either. And of course, Git for Windows caters to *Windows* users, which does change the perspective quite a bit: file locking issues are no longer just a nuisance, scripts are too slow to be called production-ready, repositories tend to be ridiculously large (a lot larger than regular open source repositories, for sure), etc. So for example, I did fast-track the experimental built-in `git add -i`, even if it was tested only by me, and for less than two months: the benefit is just too great to pass up. So yeah, I run Git for Windows in a different way than you run Git, and I think both ways have their merits. > [...] > Johannes Schindelin <johannes.schinde...@gmx.de> writes: > > > On Thu, 30 May 2019, Junio C Hamano wrote: > > > >> * po/git-help-on-git-itself (2019-05-16) 2 commits > >> - Doc: git.txt: remove backticks from link and add git-scm.com/docs > >> - git.c: show usage for accessing the git(1) help page > >> > >> "git help git" was hard to discover (well, at least for some > >> people). > >> > >> Will merge to 'next'. > > > > I guess it would not hurt anybody (and get a bit more exposure) if it was > > merged before v2.22.0, but it does not fix a problem introduced in this > > cycle, so... > > Yeah, I think you already know this but my stance towards these > "would never hurt to merge even in -rc period" topics is to merge > them soon after the final. Fair enough. > >> * ba/clone-remote-submodules (2019-05-28) 1 commit > >> (merged to 'next' on 2019-05-29 at 71972f94c2) > >> + clone: add `--remote-submodules` flag > >> > >> "git clone --recurse-submodules" learned to set up the submodules > >> to ignore commit object names recorded in the superproject gitlink > >> and instead use the commits that happen to be at the tip of the > >> remote-tracking branches from the get-go, by passing the new > >> "--remote-submodules" option. > >> > >> Will cook in 'next'. > > > > Are we really sure that this is a good option name? With that > > description, I would have expected `--recurse-submodules=follow-tips` > > or some such. > > > > In other words, I would have been in favor of keeping this in `pu` for > > a little while longer. But it's already in `next`... > > As far as I am concerned, ones in 'next' that is not meant to be > fast-tracked to 'master' during the -rc period are like only in `pu`. > Soon after the final, when 'next' is rewound, any of them can be kicked > out to give it a fresh start, and it is a good time to think and > nominate which ones to boot and reboot, like you just did. > > As to your question, I do not have a strong opinion either way. Input > from folks more invested in submodules, and especially from those who > want to use submodules in non-traditional ways, would be most welcome. > To me, it feels that the "ignore what gitlink entries say, and use the > commits that happen to be pointed at by refs of a clone of the submodule > you happen to follow" is not really a good match to the way "gitlink" > based Git submodules are designed to be used, but that mode of the > operation is not wrong per-se (it was just that we did not design the > system to support well). I am probably a terrible person to ask about submodules, as I am of the firm opinion that friends don't let friends use submodules. And people who suggest to their enememies to use submodules are just awful people that I don't want to talk to, like, ever. And it is no secret that I believe that the submodule feature was just pushed through for no other reason than to shut up the people who wanted to discuss a Git feature that would reflect the svn:externals (something for which there are real scenarios out there, and they were just steamrollered by the push for submodules). Nevertheless, I still think that even a feature as unwise as submodules *can* be the best solution under certain circumstances, at least for now. And those circumstances deserve really good naming. Just like all other Git use cases. > >> * ds/close-object-store (2019-05-28) 3 commits > >> - packfile: rename close_all_packs to close_object_store > >> - packfile: close commit-graph in close_all_packs > >> - commit-graph: use raw_object_store when closing > >> (this branch uses ds/commit-graph-write-refactor.) > >> > >> The commit-graph file is now part of the "files that the runtime > >> may keep open file descriptors on, all of which would need to be > >> closed when done with the object store", and the file descriptor to > >> an existing commit-graph file now is closed before "gc" finializes > >> a new instance to replace it. > >> > >> Waiting on ds/commit-graph-write-refactor to stabilize. > > > > FWIW I backported this to Git for Windows, as the underlying bug would > > prevent an auto gc from working as intended (iff the commit graph feature > > is turned on, of course). > > Yes, I can see how a system that does not allow filesystem > operations on a still-open file would need these three patches. How > ready is the underlying topic? IIRC there were a few internal API > details still to be reworked? Well, what can I say: I cheated. I rebased these three patches to Git for Windows' `master` *excluding* `ds/commit-graph-write-refactor`. Because even I am conservative, at times ;-) AFAICT even Stolee is on board with giving that refactoring effort a bit more time. Ciao, Dscho
