git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: "brian m. carlson" <sandals@crustytoothpaste.net>
To: David Turner <dturner@twopensource.com>
Cc: Junio C Hamano <gitster@pobox.com>, Jeff King <peff@peff.net>,
	git@vger.kernel.org
Subject: Re: What's cooking in git.git (Dec 2015, #01; Tue, 1)
Date: Thu, 3 Dec 2015 03:02:20 +0000	[thread overview]
Message-ID: <20151203030220.GB25412@vauxhall.crustytoothpaste.net> (raw)
In-Reply-To: <1449102580.14908.2.camel@twopensource.com>

[-- Attachment #1: Type: text/plain, Size: 1230 bytes --]

On Wed, Dec 02, 2015 at 07:29:40PM -0500, David Turner wrote:
> From a selfish perspective, I, would prefer for object-ids to not happen
> quite yet for the refs code.  I have already prepared (but not yet sent)
> a new version of the refs backend vtable (and lmdb) code on top of
> refs-backend-pre-vtable, and it'll be a hassle to reroll it on top of
> new object-id stuff.
> 
> I guess I'll go ahead and send mine now, and we can later make a
> decision about how to deal with the object-id stuff.

As Jeff pointed out, the patches to refs.c were mostly dropped, as the
code that they modified had been removed.  The likelihood of conflict is
therefore low unless you're using struct object a lot.

My preference is that new code use object_id where possible, because
otherwise I'm going to have to go through it later and fix it up.
Keeping in mind that the refs code is likely to undergo a lot of
changes, I'll try to keep away from it for now, but it will need to be
converted at some point.
-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | https://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 835 bytes --]

      reply	other threads:[~2015-12-03  3:02 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-02  0:24 What's cooking in git.git (Dec 2015, #01; Tue, 1) Jeff King
2015-12-02 22:11 ` Junio C Hamano
2015-12-02 22:31   ` Jeff King
2015-12-02 23:31     ` Junio C Hamano
2015-12-03  0:07       ` Jeff King
2015-12-03  0:13         ` Junio C Hamano
2015-12-03  1:09     ` Junio C Hamano
2015-12-07 13:40     ` Patrick Steinhardt
2015-12-07 19:24       ` Junio C Hamano
2015-12-08 10:05         ` Patrick Steinhardt
2015-12-03  0:29   ` David Turner
2015-12-03  3:02     ` brian m. carlson [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=20151203030220.GB25412@vauxhall.crustytoothpaste.net \
    --to=sandals@crustytoothpaste.net \
    --cc=dturner@twopensource.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --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).