Re: What's cooking in git.git (May 2019, #05; Thu, 30)
- Date: Fri, 31 May 2019 20:48:52 +0200 (CEST)
- From: Johannes Schindelin <Johannes.Schindelin@xxxxxx>
- Subject: Re: What's cooking in git.git (May 2019, #05; Thu, 30)
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.Schindelin@xxxxxx> 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.
> >> * 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