git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Alex Vandiver <alexmv@dropbox.com>
Cc: git@vger.kernel.org,
	Johannes Schindelin <Johannes.Schindelin@gmx.de>,
	Ben Peart <peartben@gmail.com>
Subject: Re: [PATCH 2/2] fsmonitor: Store fsmonitor bitmap before splitting index
Date: Fri, 10 Nov 2017 14:11:41 +0900	[thread overview]
Message-ID: <xmqqvaiig1ki.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <4ff73be656d5bbf9e2cada6bdec61843da9d1516.1510257457.git.alexmv@dropbox.com> (Alex Vandiver's message of "Thu, 9 Nov 2017 11:58:10 -0800")

Alex Vandiver <alexmv@dropbox.com> writes:

> ba1b9caca6 resolved the problem of the fsmonitor data being applied to

(from SubmittingPatches)

If you want to reference a previous commit in the history of a stable
branch, use the format "abbreviated sha1 (subject, date)",
with the subject enclosed in a pair of double-quotes, like this:

    Commit f86a374 ("pack-bitmap.c: fix a memleak", 2015-03-30)
    noticed that ...

The "Copy commit summary" command of gitk can be used to obtain this
format, or this invocation of "git show":

    git show -s --date=short --pretty='format:%h ("%s", %ad)' <commit>


> the non-base index when reading; however, a similar problem exists
> when writing the index.  Specifically, writing of the fsmonitor
> extension happens only after the work to split the index has been
> applied -- as such, the information in the index is only for the
> non-"base" index, and thus the extension information contains only
> partial data.

So... what's the effect of not applying this change?  Do we miss
paths that are known to the watchman to have been modified and end
up not adding them if we do "git add -u"?  Or do we miss paths that
are known to the watchman to be clean but mistakenly think are dirty,
and spend unnecessary cycles?  IOW, is this fixing a correctness
issue, or a performance one?

> When saving, compute the ewah bitmap before the index is split, and
> store it in the fsmonitor_dirty field, mirroring the behavior that
> occurred during reading.  fsmonitor_dirty is kept from being leaked by
> being freed when the extension data is written -- which always happens
> precisely once, no matter the split index configuration.

The observation and the approach stated to fix both sounds
sensible.  I'll queue this too, awaiting for Ben's review.

Thanks.

  reply	other threads:[~2017-11-10  5:11 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-09 19:58 [PATCH 0/2] fsmonitor: Stop reading from PWD, write fsmonitor+split index right Alex Vandiver
2017-11-09 19:58 ` [PATCH 1/2] fsmonitor: Read from getcwd(), not the PWD environment variable Alex Vandiver
2017-11-09 19:58   ` [PATCH 2/2] fsmonitor: Store fsmonitor bitmap before splitting index Alex Vandiver
2017-11-10  5:11     ` Junio C Hamano [this message]
2017-11-13 15:28     ` Ben Peart
2017-12-16  2:02       ` Alex Vandiver
2017-11-10  5:04   ` [PATCH 1/2] fsmonitor: Read from getcwd(), not the PWD environment variable Junio C Hamano
2017-11-10 21:03     ` [PATCH v1] fsmonitor: simplify determining the git worktree under Windows Ben Peart
2017-11-13  1:02       ` Junio C Hamano

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=xmqqvaiig1ki.fsf@gitster.mtv.corp.google.com \
    --to=gitster@pobox.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=alexmv@dropbox.com \
    --cc=git@vger.kernel.org \
    --cc=peartben@gmail.com \
    --subject='Re: [PATCH 2/2] fsmonitor: Store fsmonitor bitmap before splitting index' \
    /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

git@vger.kernel.org list mirror (unofficial, one of many)

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://public-inbox.org/git
	git clone --mirror http://ou63pmih66umazou.onion/git
	git clone --mirror http://czquwvybam4bgbro.onion/git
	git clone --mirror http://hjrcffqmbrq6wope.onion/git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 git git/ https://public-inbox.org/git \
		git@vger.kernel.org
	public-inbox-index git

Example config snippet for mirrors.
Newsgroups are available over NNTP:
	nntp://news.public-inbox.org/inbox.comp.version-control.git
	nntp://7fh6tueqddpjyxjmgtdiueylzoqt6pt7hec3pukyptlmohoowvhde4yd.onion/inbox.comp.version-control.git
	nntp://ie5yzdi7fg72h7s4sdcztq5evakq23rdt33mfyfcddc5u3ndnw24ogqd.onion/inbox.comp.version-control.git
	nntp://4uok3hntl7oi7b4uf4rtfwefqeexfzil2w6kgk2jn5z2f764irre7byd.onion/inbox.comp.version-control.git
	nntp://news.gmane.io/gmane.comp.version-control.git
 note: .onion URLs require Tor: https://www.torproject.org/

code repositories for project(s) associated with this inbox:

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

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git