{"thread":{"id":"38615","subject":"[PATCH 1/2] clone: add disassociate alias to dissociate option","startedAt":"2015-02-20T19:10:21Z","lastAt":"2015-02-24T22:00:34Z","messageCount":11,"participants":["Matt Whiteley","Eric Sunshine","Jeff King","Junio C Hamano","Michael Haggerty"],"isPatch":true,"patchVersion":1,"patchTotal":2},"messages":[{"id":"256429","messageId":"1424459423-11727-1-git-send-email-mattwhiteley@gmail.com","threadId":"38615","inReplyTo":null,"subject":"[PATCH] --disassociate alias for --dissociate clone option","fromName":"Matt Whiteley","fromEmail":"mattwhiteley@gmail.com","sentAt":"2015-02-20T19:10:21Z","receivedAt":"2015-02-20T19:10:21Z","isPatch":true,"sender":{"key":"mattwhiteley@gmail.com","avatar":"https://gravatar.com/avatar/9a876e4bb725959b7ad4df8863115edc32fa3d96abc7b046393eff7f1ae9e1be?d=mp&s=160"},"body":"I find the new --dissociate option for clone very helpful but I have a\nhard time with the spelling. It seems reasonable to have an alias since\none exists for --recursive.\n"},{"id":"256428","messageId":"1424459423-11727-2-git-send-email-mattwhiteley@gmail.com","threadId":"38615","inReplyTo":"1424459423-11727-1-git-send-email-mattwhiteley@gmail.com","subject":"[PATCH 1/2] clone: add disassociate alias to dissociate option","fromName":"Matt Whiteley","fromEmail":"mattwhiteley@gmail.com","sentAt":"2015-02-20T19:10:22Z","receivedAt":"2015-02-20T19:10:22Z","isPatch":true,"sender":{"key":"mattwhiteley@gmail.com","avatar":"https://gravatar.com/avatar/9a876e4bb725959b7ad4df8863115edc32fa3d96abc7b046393eff7f1ae9e1be?d=mp&s=160"},"body":"Enable clone to accept alternate spelling for dissociate option. Add\nalias to documentation following existing recursive/recurse-submodules\nconvention.\n\nSigned-off-by: Matt Whiteley <mattwhiteley@gmail.com>\n---\n Documentation/git-clone.txt | 3 ++-\n builtin/clone.c             | 2 ++\n 2 files changed, 4 insertions(+), 1 deletion(-)\n\ndiff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt\nindex f1f2a3f..0b4c1b2 100644\n--- a/Documentation/git-clone.txt\n+++ b/Documentation/git-clone.txt\n@@ -12,7 +12,7 @@ SYNOPSIS\n 'git clone' [--template=<template_directory>]\n \t  [-l] [-s] [--no-hardlinks] [-q] [-n] [--bare] [--mirror]\n \t  [-o <name>] [-b <name>] [-u <upload-pack>] [--reference <repository>]\n-\t  [--dissociate] [--separate-git-dir <git dir>]\n+\t  [--dissociate | --disassociate] [--separate-git-dir <git dir>]\n \t  [--depth <depth>] [--[no-]single-branch]\n \t  [--recursive | --recurse-submodules] [--] <repository>\n \t  [<directory>]\n@@ -102,6 +102,7 @@ objects from the source repository into a pack in the cloned repository.\n `--dissociate` option.\n \n --dissociate::\n+--disassociate::\n \tBorrow the objects from reference repositories specified\n \twith the `--reference` options only to reduce network\n \ttransfer and stop borrowing from them after a clone is made\ndiff --git a/builtin/clone.c b/builtin/clone.c\nindex 316c75d..7e193ae 100644\n--- a/builtin/clone.c\n+++ b/builtin/clone.c\n@@ -97,6 +97,8 @@ static struct option builtin_clone_options[] = {\n \t\t    N_(\"clone only one branch, HEAD or --branch\")),\n \tOPT_BOOL(0, \"dissociate\", &option_dissociate,\n \t\t N_(\"use --reference only while cloning\")),\n+\tOPT_BOOL(0, \"disassociate\", &option_dissociate,\n+\t\t N_(\"use --reference only while cloning\")),\n \tOPT_STRING(0, \"separate-git-dir\", &real_git_dir, N_(\"gitdir\"),\n \t\t   N_(\"separate git dir from working tree\")),\n \tOPT_STRING_LIST('c', \"config\", &option_config, N_(\"key=value\"),\n-- \n2.3.0\n"},{"id":"256430","messageId":"1424459423-11727-3-git-send-email-mattwhiteley@gmail.com","threadId":"38615","inReplyTo":"1424459423-11727-1-git-send-email-mattwhiteley@gmail.com","subject":"[PATCH 2/2] clone: Realign lines near disassociate option","fromName":"Matt Whiteley","fromEmail":"mattwhiteley@gmail.com","sentAt":"2015-02-20T19:10:23Z","receivedAt":"2015-02-20T19:10:23Z","isPatch":true,"sender":{"key":"mattwhiteley@gmail.com","avatar":"https://gravatar.com/avatar/9a876e4bb725959b7ad4df8863115edc32fa3d96abc7b046393eff7f1ae9e1be?d=mp&s=160"},"body":"Fix long line splitting format while adding to builtin_clone_options.\n\nSigned-off-by: Matt Whiteley <mattwhiteley@gmail.com>\n---\n builtin/clone.c | 14 +++++++-------\n 1 file changed, 7 insertions(+), 7 deletions(-)\n\ndiff --git a/builtin/clone.c b/builtin/clone.c\nindex 7e193ae..fd6bcf4 100644\n--- a/builtin/clone.c\n+++ b/builtin/clone.c\n@@ -72,15 +72,15 @@ static struct option builtin_clone_options[] = {\n \tOPT_BOOL(0, \"mirror\", &option_mirror,\n \t\t N_(\"create a mirror repository (implies bare)\")),\n \tOPT_BOOL('l', \"local\", &option_local,\n-\t\tN_(\"to clone from a local repository\")),\n+\t\t N_(\"to clone from a local repository\")),\n \tOPT_BOOL(0, \"no-hardlinks\", &option_no_hardlinks,\n-\t\t    N_(\"don't use local hardlinks, always copy\")),\n+\t\t N_(\"don't use local hardlinks, always copy\")),\n \tOPT_BOOL('s', \"shared\", &option_shared,\n-\t\t    N_(\"setup as shared repository\")),\n+\t\t N_(\"setup as shared repository\")),\n \tOPT_BOOL(0, \"recursive\", &option_recursive,\n-\t\t    N_(\"initialize submodules in the clone\")),\n+\t\t N_(\"initialize submodules in the clone\")),\n \tOPT_BOOL(0, \"recurse-submodules\", &option_recursive,\n-\t\t    N_(\"initialize submodules in the clone\")),\n+\t\t N_(\"initialize submodules in the clone\")),\n \tOPT_STRING(0, \"template\", &option_template, N_(\"template-directory\"),\n \t\t   N_(\"directory from which templates will be used\")),\n \tOPT_CALLBACK(0 , \"reference\", &option_reference, N_(\"repo\"),\n@@ -92,9 +92,9 @@ static struct option builtin_clone_options[] = {\n \tOPT_STRING('u', \"upload-pack\", &option_upload_pack, N_(\"path\"),\n \t\t   N_(\"path to git-upload-pack on the remote\")),\n \tOPT_STRING(0, \"depth\", &option_depth, N_(\"depth\"),\n-\t\t    N_(\"create a shallow clone of that depth\")),\n+\t\t   N_(\"create a shallow clone of that depth\")),\n \tOPT_BOOL(0, \"single-branch\", &option_single_branch,\n-\t\t    N_(\"clone only one branch, HEAD or --branch\")),\n+\t\t N_(\"clone only one branch, HEAD or --branch\")),\n \tOPT_BOOL(0, \"dissociate\", &option_dissociate,\n \t\t N_(\"use --reference only while cloning\")),\n \tOPT_BOOL(0, \"disassociate\", &option_dissociate,\n-- \n2.3.0\n"},{"id":"256438","messageId":"CAPig+cTGZohqPRL2OHcaF5bBwED-bhCsZJkp9g00uqJKWfObaA@mail.gmail.com","threadId":"38615","inReplyTo":"1424459423-11727-1-git-send-email-mattwhiteley@gmail.com","subject":"Re: [PATCH] --disassociate alias for --dissociate clone option","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2015-02-20T22:01:13Z","receivedAt":"2015-02-20T22:01:13Z","isPatch":true,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Fri, Feb 20, 2015 at 2:10 PM, Matt Whiteley <mattwhiteley@gmail.com> wrote:\n> I find the new --dissociate option for clone very helpful but I have a\n> hard time with the spelling. It seems reasonable to have an alias since\n> one exists for --recursive.\n\nYou may be undermining your own argument for inclusion of a new\n--dissociate option by citing the aliased \"recursive\" option.\n\ngit-clone's --recursive-submodules was added (see ccdd3da6) for\ndisambiguation long after --recursive; and not the other way around\nwith --recursive being more convenient or easier to remember or spell\nthan --recursive-submodules. The implication of ccdd3da6 is that\n--recursive-submodules is favored over --recursive (and perhaps the\nlatter may some day be deprecated).\n"},{"id":"256462","messageId":"20150221062754.GC29665@peff.net","threadId":"38615","inReplyTo":"1424459423-11727-2-git-send-email-mattwhiteley@gmail.com","subject":"Re: [PATCH 1/2] clone: add disassociate alias to dissociate option","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2015-02-21T06:27:55Z","receivedAt":"2015-02-21T06:27:55Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Feb 20, 2015 at 11:10:22AM -0800, Matt Whiteley wrote:\n\n> diff --git a/builtin/clone.c b/builtin/clone.c\n> index 316c75d..7e193ae 100644\n> --- a/builtin/clone.c\n> +++ b/builtin/clone.c\n> @@ -97,6 +97,8 @@ static struct option builtin_clone_options[] = {\n>  \t\t    N_(\"clone only one branch, HEAD or --branch\")),\n>  \tOPT_BOOL(0, \"dissociate\", &option_dissociate,\n>  \t\t N_(\"use --reference only while cloning\")),\n> +\tOPT_BOOL(0, \"disassociate\", &option_dissociate,\n> +\t\t N_(\"use --reference only while cloning\")),\n\nShould this second one be marked as OPT_HIDDEN? I do not think we need\nto show both in \"git clone --help\".\n\n-Peff\n"},{"id":"256464","messageId":"xmqqzj87wxck.fsf@gitster.dls.corp.google.com","threadId":"38615","inReplyTo":"20150221062754.GC29665@peff.net","subject":"Re: [PATCH 1/2] clone: add disassociate alias to dissociate option","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-02-21T07:13:47Z","receivedAt":"2015-02-21T07:13:47Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> On Fri, Feb 20, 2015 at 11:10:22AM -0800, Matt Whiteley wrote:\n>\n>> diff --git a/builtin/clone.c b/builtin/clone.c\n>> index 316c75d..7e193ae 100644\n>> --- a/builtin/clone.c\n>> +++ b/builtin/clone.c\n>> @@ -97,6 +97,8 @@ static struct option builtin_clone_options[] = {\n>>  \t\t    N_(\"clone only one branch, HEAD or --branch\")),\n>>  \tOPT_BOOL(0, \"dissociate\", &option_dissociate,\n>>  \t\t N_(\"use --reference only while cloning\")),\n>> +\tOPT_BOOL(0, \"disassociate\", &option_dissociate,\n>> +\t\t N_(\"use --reference only while cloning\")),\n>\n> Should this second one be marked as OPT_HIDDEN? I do not think we need\n> to show both in \"git clone --help\".\n\nFor that matter, I am not sure why we want to add this synonym in\nthe first place.\n\nhttp://www.merriam-webster.com/dictionary/dissociate\n\n    : to end your relationship with or connection to someone or\n    something : to separate (yourself) from someone or something\n\nwhich is exactly what I wanted the option to achieve.\n"},{"id":"256465","messageId":"20150221073509.GA32548@peff.net","threadId":"38615","inReplyTo":"xmqqzj87wxck.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH 1/2] clone: add disassociate alias to dissociate option","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2015-02-21T07:35:09Z","receivedAt":"2015-02-21T07:35:09Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Feb 20, 2015 at 11:13:47PM -0800, Junio C Hamano wrote:\n\n> >>  \tOPT_BOOL(0, \"dissociate\", &option_dissociate,\n> >>  \t\t N_(\"use --reference only while cloning\")),\n> >> +\tOPT_BOOL(0, \"disassociate\", &option_dissociate,\n> >> +\t\t N_(\"use --reference only while cloning\")),\n> >\n> > Should this second one be marked as OPT_HIDDEN? I do not think we need\n> > to show both in \"git clone --help\".\n> \n> For that matter, I am not sure why we want to add this synonym in\n> the first place.\n> \n> http://www.merriam-webster.com/dictionary/dissociate\n> \n>     : to end your relationship with or connection to someone or\n>     something : to separate (yourself) from someone or something\n> \n> which is exactly what I wanted the option to achieve.\n\nThat is also the definition of disassociate. :) They are both equally\ncorrect here, and some people tend to use one over the other:\n\n  http://grammarist.com/usage/dissociate-disassociate/\n\nSo I don't think the spirit of the patch is wrong, in that sense. I am\nopen to the argument that we do not want to get in the habit of\nproviding every possible synonym, as it would clutter the interface.\nThis case is a bit more extreme; given the similarity of the two words,\nit is easy to use the wrong one. But I do not personally care much\neither way.\n\nAs a side note, while writing out an explanation of \"--reference\n--dissociate\" recently, Michael (cc'd) and I noticed that it seems quite\nverbose to have to specify both options.\n\nBy itself, --dissociate does nothing. It _could_ imply --reference (but\nright now complains that --reference was not provided and turns itself\noff). But if we were to have a single-option version of \"reference and\ndissociate\", I do not think \"--dissociate\" is the best choice. By itself\nit does not mean much (dissociate from _what_?).\n\nI wonder if there is some better word that could become a synonym for\n\"--reference --dissociate\". Maybe \"--borrow\", but that does not\nnecessarily carry the implication that the relationship ends as soon as\nthe clone is done. What is really happening is that we are reusing\nobjects in order to save bandwidth. Maybe \"--reuse-from\" would work?\n\nI dunno. I am not extremely happy with any of the suggestions I made,\nnor is any of this of extreme importance to me. But I thought I would\nmention it while we are on the subject.\n\n-Peff\n"},{"id":"256483","messageId":"xmqqvbitx0eh.fsf@gitster.dls.corp.google.com","threadId":"38615","inReplyTo":"20150221073509.GA32548@peff.net","subject":"Re: [PATCH 1/2] clone: add disassociate alias to dissociate option","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-02-22T18:32:22Z","receivedAt":"2015-02-22T18:32:22Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> I wonder if there is some better word that could become a synonym for\n> \"--reference --dissociate\". Maybe \"--borrow\", but that does not\n> necessarily carry the implication that the relationship ends as soon as\n> the clone is done.\n\nYou are retracing the exact line of the thinking that led me to a\ncop-out that is a separate \"--dissociate\".\n\nThe original idea was to give \"--borrow /local/repository/path\", but\nthat would have made it unclear what the differences between that\nnew option and existing \"--reference\" were.  Both borrow the objects\nin order to reduce the network cost, and the difference is that one\nkeeps borrowing while the other one limits the borrowing to strictly\nthe initial phase.  The two words, \"borrow\" and \"reference\", would\nnot convey that key distinction.  \"Do the reference thing (which is\nwell understood from old days, even before v1.6.0) and then severe\nthe ties\" was suboptimal but was easy to explain, and that is why I\ncall it a cop-out.\n\n> What is really happening is that we are reusing\n> objects in order to save bandwidth. Maybe \"--reuse-from\" would work?\n>\n> I dunno. I am not extremely happy with any of the suggestions I made,...\n\nI dunno, either.\n\nWe are all on the same page.  We know the cop-out is suboptimal, we\nunderstand why the cop-out is better than \"--borrow\", and we cannot\ncome up with a better name that contrasts with the existing\n\"--reference\" to make it clear how the new thing is different.\n"},{"id":"256562","messageId":"54EC3EF8.7040302@alum.mit.edu","threadId":"38615","inReplyTo":"xmqqvbitx0eh.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH 1/2] clone: add disassociate alias to dissociate option","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2015-02-24T09:06:00Z","receivedAt":"2015-02-24T09:06:00Z","isPatch":true,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"On 02/22/2015 07:32 PM, Junio C Hamano wrote:\n> Jeff King <peff@peff.net> writes:\n> \n>> I wonder if there is some better word that could become a synonym for\n>> \"--reference --dissociate\". Maybe \"--borrow\", but that does not\n>> necessarily carry the implication that the relationship ends as soon as\n>> the clone is done.\n> \n> You are retracing the exact line of the thinking that led me to a\n> cop-out that is a separate \"--dissociate\".\n> \n> The original idea was to give \"--borrow /local/repository/path\", but\n> that would have made it unclear what the differences between that\n> new option and existing \"--reference\" were.  Both borrow the objects\n> in order to reduce the network cost, and the difference is that one\n> keeps borrowing while the other one limits the borrowing to strictly\n> the initial phase.  The two words, \"borrow\" and \"reference\", would\n> not convey that key distinction.  \"Do the reference thing (which is\n> well understood from old days, even before v1.6.0) and then severe\n> the ties\" was suboptimal but was easy to explain, and that is why I\n> call it a cop-out.\n> \n>> What is really happening is that we are reusing\n>> objects in order to save bandwidth. Maybe \"--reuse-from\" would work?\n>>\n>> I dunno. I am not extremely happy with any of the suggestions I made,...\n> \n> I dunno, either.\n> \n> We are all on the same page.  We know the cop-out is suboptimal, we\n> understand why the cop-out is better than \"--borrow\", and we cannot\n> come up with a better name that contrasts with the existing\n> \"--reference\" to make it clear how the new thing is different.\n\nI'll take that as an invitation to brainstorm :-)\n\n    --use-objects-from=\n    --copy-objects-from=\n    --precopy-objects-from=\n    --precopy-from=\n    --donor=\n    --object-donor=\n    --steal-from=\n    --steal-objects-from=\n\nOf these, I think I like \"--object-donor\" the best.\n\nBy the way, once we have stopped thinking about this feature as\n\"--reference\" and then \"--dissociate\", it becomes obvious that a nice\ngeneralization would be to allow *any* repository (including remote\nones) to serve as the object donor. This would allow users to get most\nof their objects from a \"nearby\" repository (e.g., a mirror on the LAN)\nand then top off from a more distant \"authoritative\" repository.\n\nIn fact, this donor/recipient relationship could be made persistent:\nbefore fetching from repository A, always first fetch any objects that\nrepository B has available. OTOH, making the relationship persistent\nwould presumably require us to retain remote-tracking references for\nrepository B even though they are not intrinsically interesting to the\nuser, and would lead to reference namespace conflicts if the user wants\na \"--mirror\" clone.\n\nMichael\n\n-- \nMichael Haggerty\nmhagger@alum.mit.edu\n"},{"id":"256588","messageId":"xmqqbnkjqdko.fsf@gitster.dls.corp.google.com","threadId":"38615","inReplyTo":"54EC3EF8.7040302@alum.mit.edu","subject":"Re: [PATCH 1/2] clone: add disassociate alias to dissociate option","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-02-24T20:06:31Z","receivedAt":"2015-02-24T20:06:31Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael Haggerty <mhagger@alum.mit.edu> writes:\n\n> On 02/22/2015 07:32 PM, Junio C Hamano wrote:\n>> ...  Both borrow the objects\n>> in order to reduce the network cost, and the difference is that one\n>> keeps borrowing while the other one limits the borrowing to strictly\n>> the initial phase.  The two words, \"borrow\" and \"reference\", would\n>> not convey that key distinction. ... and that is why I\n>> call it a cop-out.\n>> ...\n>> We are all on the same page.  We know the cop-out is suboptimal, we\n>> understand why the cop-out is better than \"--borrow\", and we cannot\n>> come up with a better name that contrasts with the existing\n>> \"--reference\" to make it clear how the new thing is different.\n>\n> I'll take that as an invitation to brainstorm :-)\n>\n>     --use-objects-from=\n>     --copy-objects-from=\n>     --precopy-objects-from=\n>     --precopy-from=\n>     --donor=\n>     --object-donor=\n>     --steal-from=\n>     --steal-objects-from=\n>\n> Of these, I think I like \"--object-donor\" the best.\n\nDonor (somehow the word reminds me of organ harvesting, yuck)?\n\nI didn't think of the word 'copy', but that probably captures the\nessence the best.  \"reference-to-borrow-and-then-dissociate\" is an\nimplementation detail, which, as you say, we do not want the users\nto view this operation as; copying locally instead of over the\nnetwork is what the user wants to do.\n\n> By the way, once we have stopped thinking about this feature as\n> \"--reference\" and then \"--dissociate\", it becomes obvious that a nice\n> generalization would be to allow *any* repository (including remote\n> ones) to serve as the object donor.\n\nAs I do not think of a workable approach to implement such a\nmechanism, I'd refrain from being irresponsible and say \"Yeah,\nthat's a neat idea\", which would make me sound like clueless \"me\ntoo, why doesn't Git do that?\" crowd.\n"},{"id":"256599","messageId":"54ECF482.3010303@alum.mit.edu","threadId":"38615","inReplyTo":"xmqqbnkjqdko.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH 1/2] clone: add disassociate alias to dissociate option","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2015-02-24T22:00:34Z","receivedAt":"2015-02-24T22:00:34Z","isPatch":true,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"On 02/24/2015 09:06 PM, Junio C Hamano wrote:\n> Michael Haggerty <mhagger@alum.mit.edu> writes:\n>> By the way, once we have stopped thinking about this feature as\n>> \"--reference\" and then \"--dissociate\", it becomes obvious that a nice\n>> generalization would be to allow *any* repository (including remote\n>> ones) to serve as the object donor.\n> \n> As I do not think of a workable approach to implement such a\n> mechanism, I'd refrain from being irresponsible and say \"Yeah,\n> that's a neat idea\", which would make me sound like clueless \"me\n> too, why doesn't Git do that?\" crowd.\n\nI think this would be done by effectively creating a clone of the nearby\nrepository then a fetch of the distant one, with some reference\nshuffling between the steps. If the nearby repository contains far more\nobjects than the user really wants, then the initial clone will be\nwasteful. But since the use case will probably be that the nearby\nrepository is (1) a mirror of the distant repo, and (depending on how\nold it is) contains approximately a subset of the objects in the distant\nrepository, and (2) much faster to work with than the distant repo, I\nthink even this crude approach would often be a win.\n\nMichael\n\n-- \nMichael Haggerty\nmhagger@alum.mit.edu\n"}]}