git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, Derrick Stolee <dstolee@microsoft.com>
Subject: Re: What's cooking in git.git (May 2019, #05; Thu, 30)
Date: Fri, 31 May 2019 20:48:52 +0200 (CEST)	[thread overview]
Message-ID: <nycvar.QRO.7.76.6.1905312032370.1775@tvgsbejvaqbjf.bet> (raw)
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.

> [...]
> 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.

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

  reply	other threads:[~2019-05-31 18:49 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-30 21:23 What's cooking in git.git (May 2019, #05; Thu, 30) Junio C Hamano
2019-05-31 11:39 ` Johannes Schindelin
2019-05-31 17:02   ` Junio C Hamano
2019-05-31 17:14     ` Johannes Schindelin
2019-05-31 12:42 ` Johannes Schindelin
2019-05-31 17:34   ` Junio C Hamano
2019-05-31 18:48     ` Johannes Schindelin [this message]
2019-06-01 15:08     ` Kaartic Sivaraam
2019-06-02 17:48     ` Philip Oakley
2019-05-31 18:56   ` Junio C Hamano
2019-05-31 20:26     ` cc/list-objects-filter-wo-sparse-path, was " Johannes Schindelin
2019-06-02 14:32       ` Jiang Xin
2019-06-05 18:38 ` Nickolai Belakovski
2019-06-06 13:09   ` Johannes Schindelin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=nycvar.QRO.7.76.6.1905312032370.1775@tvgsbejvaqbjf.bet \
    --to=johannes.schindelin@gmx.de \
    --cc=dstolee@microsoft.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).