All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Shawn O. Pearce" <spearce@spearce.org>
To: Junio C Hamano <gitster@pobox.com>
Cc: Johannes Sixt <j.sixt@viscovery.net>,
	Charles Bailey <charles@hashpling.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Git Mailing List <git@vger.kernel.org>
Subject: Re: Be more careful about updating refs
Date: Thu, 17 Jan 2008 21:13:00 -0500	[thread overview]
Message-ID: <20080118021300.GR24004@spearce.org> (raw)
In-Reply-To: <7v63xrki29.fsf@gitster.siamese.dyndns.org>

Junio C Hamano <gitster@pobox.com> wrote:
> Junio C Hamano <gitster@pobox.com> writes:
> 
> > The following patch seems to fix the issue for me, but this is
> > primarily meant for discussion, as I do not quite understand why
> > the same issue does not manifest itself when NO_MMAP is not
> > used.
> > ...
...
> What I do not quite understand is how this can be a new issue.

It isn't.  It is indeed a pretty old issue, as far as git issues go.
Its probably about as old as fast-import being accepted into your
tree is.
 
> The codepath to allow updating an existing branch shown above
> (i.e. "if it is not force and old is not NULL") uses the usual
> lookup_commit_reference_gently() interface to access b->sha1,
> and does not use gfi-aware gfi_unpack_entry() or anything
> magical, which means it would have passed the same codepath down
> to trigger the same issue.  IOW, even before this tightening of
> write_ref_sha1(), we already should have had the issue of not
> being to able to grab the object b->sha1 refers to out of the
> newly built packfile.
> 
> Is it just nobody seriously exercised the codepath yet, or is
> there a difference between these two calls that is more subtle
> than that?

I think the problem is nobody has tested fast-import updating an
existing ref while using NO_MMAP.  Or if they did, they didn't report
the problem as they didn't figure they needed fast-import that badly.

Updating an existing ref is not a common operation, but the test
suite does test for it.  So it must be the NO_MMAP configuration
is simply not being tested well enough.

-- 
Shawn.

  reply	other threads:[~2008-01-18  2:13 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-15 23:50 Be more careful about updating refs Linus Torvalds
2008-01-16  0:02 ` Linus Torvalds
2008-01-16 19:52   ` Junio C Hamano
2008-01-17  9:15     ` Charles Bailey
2008-01-17 10:52       ` Johannes Sixt
2008-01-17 11:01         ` Charles Bailey
2008-01-17 12:41           ` Johannes Sixt
2008-01-17 12:58             ` Johannes Schindelin
2008-01-17 13:07               ` Charles Bailey
2008-01-18  1:43             ` Junio C Hamano
2008-01-18  2:01               ` Junio C Hamano
2008-01-18  2:13                 ` Shawn O. Pearce [this message]
2008-01-18  2:25                   ` Junio C Hamano
2008-01-18  2:33                     ` Shawn O. Pearce
2008-01-18  2:58                       ` Shawn O. Pearce
2008-01-18  3:18                         ` Shawn O. Pearce
2008-01-18  3:22                           ` Shawn O. Pearce
     [not found]                             ` <20080118035700.GA3458@spearce.org>
2008-01-18  4:27                               ` [PATCH] Fix random fast-import errors when compiled with NO_MMAP Linus Torvalds
2008-01-18  8:42                                 ` Charles Bailey
2008-01-18 17:08                                   ` Linus Torvalds
2008-01-19  3:25                                     ` Junio C Hamano
2008-01-19  3:55                                       ` Linus Torvalds
2008-01-21  3:57                                       ` Shawn O. Pearce
2008-01-18  6:10                               ` Junio C Hamano
2008-01-21  4:10                                 ` Shawn O. Pearce
2008-01-18  7:53                               ` Johannes Sixt
2008-01-18  9:26                               ` Charles Bailey
2008-01-18  9:36                                 ` Junio C Hamano
2008-01-18  9:45                                   ` Charles Bailey
2008-01-18 10:57                                     ` Junio C Hamano
2008-01-18  2:30               ` Be more careful about updating refs Shawn O. Pearce
2008-01-17 10:56       ` Charles Bailey
2008-01-16  0:29 ` Junio C Hamano
2008-01-16  0:42   ` Linus Torvalds
2008-01-16  1:11 ` Junio C Hamano
2008-01-23 22:53 ` Sam Vilain

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

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

  git send-email \
    --in-reply-to=20080118021300.GR24004@spearce.org \
    --to=spearce@spearce.org \
    --cc=charles@hashpling.org \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=j.sixt@viscovery.net \
    --cc=torvalds@linux-foundation.org \
    /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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.