From: "brian m. carlson" <sandals@crustytoothpaste.net>
To: Michael Haggerty <mhagger@alum.mit.edu>
Cc: git@vger.kernel.org, "Jeff King" <peff@peff.net>,
"Nguyễn Thái Ngọc Duy" <pclouds@gmail.com>
Subject: Re: [PATCH v2 00/10] object_id part 2
Date: Mon, 3 Aug 2015 23:45:36 +0000 [thread overview]
Message-ID: <20150803234536.GC581651@vauxhall.crustytoothpaste.net> (raw)
In-Reply-To: <55BEA8E4.7040902@alum.mit.edu>
[-- Attachment #1: Type: text/plain, Size: 1416 bytes --]
On Mon, Aug 03, 2015 at 01:33:56AM +0200, Michael Haggerty wrote:
> Brian, what was your experience when writing these patches? Did they
> tend to work as soon as they compiled without errors (i.e., not super
> risky) or did you often have test suite failures that you had to go back
> and fix (i.e., risky)? If the latter, what kinds of code patterns tended
> to be problematic? Your answers might help reviewers decide how much
> diligence is needed when reviewing these patches and what kind of
> changes to inspect extra carefully. Because doing a thorough review of
> all of the patches would be quite a bit of work.
In this particular branch, I think I may have had one bad patch. (I'm
trying to recall because I've been working on patches for part 3 in the
mean time, and they all seem to group together.) In general, over all
my patches, the conversions I've had to fix the most have been the ones
to use the GIT_SHA1_* constants, because it's very easy to get
off-by-one errors in there or mess up the values such that things break.
Extra effort on those, or additional suggestions on how to make them
cleaner and less brittle, both now and in the future, would be welcome.
--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 835 bytes --]
prev parent reply other threads:[~2015-08-03 23:45 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-13 22:16 [PATCH v2 00/10] object_id part 2 brian m. carlson
2015-06-13 22:16 ` [PATCH v2 01/10] refs: convert some internal functions to use object_id brian m. carlson
2015-06-13 22:16 ` [PATCH v2 02/10] sha1_file: introduce has_object_file helper brian m. carlson
2015-06-13 22:16 ` [PATCH v2 03/10] Convert struct ref to use object_id brian m. carlson
2015-06-15 22:13 ` Junio C Hamano
2015-06-13 22:16 ` [PATCH v2 04/10] add_sought_entry_mem: convert to struct object_id brian m. carlson
2015-06-13 22:16 ` [PATCH v2 05/10] parse_fetch: convert to use " brian m. carlson
2015-06-13 22:16 ` [PATCH v2 06/10] get_remote_heads: convert to " brian m. carlson
2015-06-13 22:16 ` [PATCH v2 07/10] push_refs_with_export: " brian m. carlson
2015-06-13 22:16 ` [PATCH v2 08/10] ref_newer: convert to use " brian m. carlson
2015-06-13 22:16 ` [PATCH v2 10/10] remote: convert functions to " brian m. carlson
2015-08-02 23:33 ` [PATCH v2 00/10] object_id part 2 Michael Haggerty
2015-08-03 23:45 ` 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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150803234536.GC581651@vauxhall.crustytoothpaste.net \
--to=sandals@crustytoothpaste.net \
--cc=git@vger.kernel.org \
--cc=mhagger@alum.mit.edu \
--cc=pclouds@gmail.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.
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.