git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "René Scharfe" <l.s.r@web.de>
Cc: Jeff King <peff@peff.net>, Git List <git@vger.kernel.org>,
	Johannes Schindelin <johannes.schindelin@gmx.de>
Subject: Re: [PATCH] checkout: don't write merge results into the object database
Date: Thu, 15 Jun 2017 14:56:03 -0700	[thread overview]
Message-ID: <xmqqefukzzik.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <f7d38553-484b-ee81-e059-2c737dad2bc4@web.de> ("René Scharfe"'s message of "Thu, 15 Jun 2017 17:48:18 +0200")

René Scharfe <l.s.r@web.de> writes:

>> If it is a concern, I think it could be solved by "unpretending" after
>> our call to checkout_entry completes. That would need a new call in
>> sha1_file.c, but it should be easy to write.
>
> Good point; we'd accumulate fake entries that we'll never need again.

Hopefully we are not pretending to have the same object from two
callsites; this one may knows the merged one no longer needs to be
in core, but some other callsite wanted to pretend a blob with the
same contents is in the object store, what happens to it?  I do not
think we want to refcount ;-)

> The patch should clean them up.
>
> Alternatively we could finally address the NEEDSWORK comment and
> provide a way to checkout a file without faking an index entry..

Yeah, we should not need index entry, and we should not need the
blob object name.

    ... thinks a bit more ...

Having said that, in the longer term, it may be safe to write an
actual object out to the object store.  The convert-to-working-tree
backends currently work only on raw bytes, but it is not inplausible
for some new interfaces to want to pass the object name to the
backend and tell it either togive raw (converted) bytes back, or to
write out the bytes directly to the filesystem, bypassing the main
Git process.  If we "pretend" in this process, not just we accumulate
cruft in-core as Peff points out, we risk giving out an invalid object
name to such external mechanisms.

I do not think it is too bad to leave a handful of temporary blobs
that are written out by "git checkout -m <other-branch>" in the
object store to be GC'ed.


      reply	other threads:[~2017-06-15 21:56 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-15 11:33 [PATCH] checkout: don't write merge results into the object database René Scharfe
2017-06-15 13:57 ` Jeff King
2017-06-15 15:48   ` René Scharfe
2017-06-15 21:56     ` Junio C Hamano [this message]

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=xmqqefukzzik.fsf@gitster.mtv.corp.google.com \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=johannes.schindelin@gmx.de \
    --cc=l.s.r@web.de \
    --cc=peff@peff.net \
    /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).