Re: What's cooking in git.git (May 2019, #05; Thu, 30)

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: May 31, 2019, 18:48 UTC
Message-ID: <nycvar.QRO.7.76.6.1905312032370.1775@tvgsbejvaqbjf.bet>
In-Reply-To: <xmqq5zpqwms1.fsf@gitster-ct.c.googlers.com>

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.

Show 21 quoted lines

> [...]
> Johannes Schindelin <Johannes.Schindelin@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.

Show 34 quoted lines

> >> * 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.

Show 22 quoted lines

> >> * 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