{"thread":{"id":"46361","subject":"[PATCH] RFC: Introduce '.gitorderfile'","startedAt":"2017-07-11T23:38:41Z","lastAt":"2017-07-13T20:47:30Z","messageCount":16,"participants":["Stefan Beller","Junio C Hamano","Jeff King","Ævar Arnfjörð Bjarmason","Brandon Williams"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"324244","messageId":"20170711233827.23486-1-sbeller@google.com","threadId":"46361","inReplyTo":null,"subject":"[PATCH] RFC: Introduce '.gitorderfile'","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2017-07-11T23:38:27Z","receivedAt":"2017-07-11T23:38:41Z","isPatch":true,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"Conceptually the file order as set with command line -O or via the config\n'diff.orderFile' is interesting to both the author (when I run a quick git\n diff locally) as well as reviewer (a patch floating on the mailing list),\nso it is not just the author who should be responsible for getting their\nconfig in order, but a project would benefit when they could give a good\ndefault for such an order.\n\nWhile the change in this RFC patch to diff.c may look uncontroversial,\n(Oh look! it's just another knob we can turn!), the change to the\nnewly introduced '.gitorderfile' may be more controversial. Here is my\nrationale for proposing it:\n\n I want to force myself to think about the design before pointing out\n memory leaks and coding style, so the least I would wish for is:\n *.h\n *.c\n but as we have more to look at, I would want to have the most abstract\n thing to come first. And most abstract from the actual code is the\n user interaction, the documentation. I heard the claim that the git\n project deliberately names the directory 'Documentation/' with a capital\n D such that we had this property by default already. With a patch like\n this we could rename Documentation/ to docs and still enjoy reading the\n docs first.\n Given this alibi, I would claim that t/ is misnamed though! I personally\n would prefer to review tests just after the documentation instead of\n after the code as the tests are more abstract and encode promises to the\n user unlike the code itself that is truth at the end of the day.\n\nSigned-off-by: Stefan Beller \n---\n\nI wrote:\n> offtopic: As a general thing for our patches, can we configure\n> (or even convince Git in general), that headers ought to be sent *before*\n> its accompanying source? I think that would help reviewers like me, who\n> tend to start reading linearly and then giving random thoughts, because the\n> header prepares the reviewer for the source code with expectations. Also\n> by having it the other way around, the review first focuses on design\n> (Is this function signature sane; the docs said it would do X while not\n> doing Y, is that sane?) instead of code.\n\nand hence I came up with this patch, as I think we would want to expose\nsuch a good feature ('diff.orderFile') even for those who are not looking\nfor it themselves.\n\nThanks,\nStefan\n\n\n .gitorderfile | 6 ++++++\n diff.c | 11 +++++++++++\n 2 files changed, 17 insertions(+)\n create mode 100644 .gitorderfile\n\ndiff --git a/.gitorderfile b/.gitorderfile\nnew file mode 100644\nindex 0000000000..5131ede927\n--- /dev/null\n+++ b/.gitorderfile\n@@ -0,0 +1,6 @@\n+Documentation/*\n+t/*\n+*.sh\n+*.h\n+*.c\n+Makefile\ndiff --git a/diff.c b/diff.c\nindex 00b4c86698..8d537db06a 100644\n--- a/diff.c\n+++ b/diff.c\n@@ -3398,6 +3398,17 @@ void diff_setup(struct diff_options *options)\n \tif (diff_indent_heuristic)\n \t\tDIFF_XDL_SET(options, INDENT_HEURISTIC);\n \n+\tif (!diff_order_file_cfg) {\n+\t\tstruct stat st;\n+\t\tint c = lstat(\".gitorderfile\", &st);\n+\t\tif (c == 0 && S_ISREG(st.st_mode))\n+\t\t\tdiff_order_file_cfg = \".gitorderfile\";\n+\t\telse if (c < 0 && errno == ENOENT)\n+\t\t\t; /* File does not exist. no preset. */\n+\t\telse\n+\t\t\tdie_errno(\"stat '.gitorderfile'\");\n+\t}\n+\n \toptions->orderfile = diff_order_file_cfg;\n \n \tif (diff_no_prefix) {\n-- \n2.13.2.695.g117ddefdb4\n\n"},{"id":"324297","messageId":"xmqqinix1j29.fsf@gitster.mtv.corp.google.com","threadId":"46361","inReplyTo":"20170711233827.23486-1-sbeller@google.com","subject":"Re: [PATCH] RFC: Introduce '.gitorderfile'","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-07-12T20:44:46Z","receivedAt":"2017-07-12T20:44:53Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Stefan Beller writes:\n\n> I want to force myself to think about the design before pointing out\n> memory leaks and coding style, so the least I would wish for is:\n> *.h\n> *.c\n> but as we have more to look at, I would want to have the most abstract\n> thing to come first. And most abstract from the actual code is the\n> user interaction, the documentation.\n\nThis is exactly why I invented the orderfile in the first place.\nBut such a \"policy\" is not something a project would want to enforce\nits users all the time; it is left to personal preference of the\nparticipants.\n\nJust set diff.orderFile to suit your taste without bothering other\npeople, I would say.\n"},{"id":"324298","messageId":"20170712205734.h77fgbbkavwpkr4h@sigill.intra.peff.net","threadId":"46361","inReplyTo":"xmqqinix1j29.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH] RFC: Introduce '.gitorderfile'","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2017-07-12T20:57:34Z","receivedAt":"2017-07-12T20:57:40Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Jul 12, 2017 at 01:44:46PM -0700, Junio C Hamano wrote:\n\n> Stefan Beller writes:\n> \n> > I want to force myself to think about the design before pointing out\n> > memory leaks and coding style, so the least I would wish for is:\n> > *.h\n> > *.c\n> > but as we have more to look at, I would want to have the most abstract\n> > thing to come first. And most abstract from the actual code is the\n> > user interaction, the documentation.\n> \n> This is exactly why I invented the orderfile in the first place.\n> But such a \"policy\" is not something a project would want to enforce\n> its users all the time; it is left to personal preference of the\n> participants.\n> \n> Just set diff.orderFile to suit your taste without bothering other\n> people, I would say.\n\nI could see somebody arguing that format-patch should respect a project\npreference, since its primary purpose is to communicate your work to the\nrest of the project.\n\nBut then you could make a similar argument for other diff options, too.\n\n-Peff\n"},{"id":"324299","messageId":"CAGZ79kYftkxbDY2E_=2w0VYx8COF_yc61h78gs2qaraK9HRSuA@mail.gmail.com","threadId":"46361","inReplyTo":"xmqqinix1j29.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH] RFC: Introduce '.gitorderfile'","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2017-07-12T20:58:52Z","receivedAt":"2017-07-12T20:58:59Z","isPatch":true,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Wed, Jul 12, 2017 at 1:44 PM, Junio C Hamano wrote:\n> Stefan Beller writes:\n\n\n>\n> Just set diff.orderFile to suit your taste without bothering other\n> people, I would say.\n\nI must have explained it very badly, I'll try again:\n\nThere are 2 different use cases to use diffs.\n1. my personal use case to look at logs, diffs.\n I'll just set diff.orderFile and I'll be fine.\n2. collaboration.\n When I want to review a patch from the mailing list,\n I could (a) download the patch, apply locally, see the diff\n formatted nicely according to diff.orderFile. Go back to my\n mail client, type an answer, quoting the patch out of order.\n This is very much work for me, so ...\n\n Alternatively (b) I could ask anyone who wants me to review\n patches to set diff.orderFile to my liking. Then I can stay in\n my mail client and have the diff hunks presented in an order\n that is most effective for review. (This is nuts, because\n the author would just ask someone else to review their code.\n \"Who am I to suggest obscure rules in collaboration?\")\n\n Another alternative (c) is to have this 'suggested' order file\n in place. Anyone that does not care about an order would use\n the suggested order, that coincidentally matches what reviewers\n in this project think is best for review.\n\n With that, the author has no additional burden and the reviewers\n get better patch presentations by default.\n\n\n>\n>> I want to force myself to think about the design before pointing out\n>> memory leaks and coding style, so the least I would wish for is:\n>> *.h\n>> *.c\n>> but as we have more to look at, I would want to have the most abstract\n>> thing to come first. And most abstract from the actual code is the\n>> user interaction, the documentation.\n>\n> This is exactly why I invented the orderfile in the first place.\n\nThis is my personal use case.\n\n> But such a \"policy\" is not something a project would want to enforce\n> its users all the time; it is left to personal preference of the\n> participants.\n\nI kindly ask that we enforce a policy on people sending patches.\nAnd to do that I would not want to bloat SubmittingPatches, but\nrather give a good default, so that people not thinking about this\ndetail, still get it right.\n\nThanks,\nStefan\n"},{"id":"324300","messageId":"878tjtz7uc.fsf@gmail.com","threadId":"46361","inReplyTo":"xmqqinix1j29.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH] RFC: Introduce '.gitorderfile'","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2017-07-12T21:03:07Z","receivedAt":"2017-07-12T21:03:16Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Wed, Jul 12 2017, Junio C. Hamano jotted:\n\n> Stefan Beller writes:\n>\n>> I want to force myself to think about the design before pointing out\n>> memory leaks and coding style, so the least I would wish for is:\n>> *.h\n>> *.c\n>> but as we have more to look at, I would want to have the most abstract\n>> thing to come first. And most abstract from the actual code is the\n>> user interaction, the documentation.\n>\n> This is exactly why I invented the orderfile in the first place.\n> But such a \"policy\" is not something a project would want to enforce\n> its users all the time; it is left to personal preference of the\n> participants.\n>\n> Just set diff.orderFile to suit your taste without bothering other\n> people, I would say.\n\nI very much like Stefan's approach here[1]. It's very useful to be able\nto set something like this in a config on a project-wide basis, so that\nwherever patches are reviewed (in Gitweb, Git[hub|lab], git-format-patch\netc.) they look as the project prefers.\n\nAs Stefan points out we're already accomplishing this with Documentation\nas a result of a hack.\n\nBut I see why you'd be concerned about this. If you're looking at random\ngit repos there's a limit to what we'd like to allow them to customize\nwithout causing confusion. The diff order is relatively innocent, but\nyou might make the case that other diff settings should be adjusted too\n(e.g. -U0 on certain file types), and that's quite the rabbit hole.\n\nStill, I think this is innocuous enough to stright the right balance\nbetween intrusion and usability. Some would find this *very* useful,\nthink projects that for whatever reason need to commit e.g. verbose XML\nconfig along with their code, and the framework they're using happens to\nrely on conf/ and src/ directories.\n\n1. Although nit: let's call it .gitorder not .gitorderfile, that it's a\n file is implicit. We don't have .gitignorefile, .gitattributesfile\n etc.\n"},{"id":"324301","messageId":"CAGZ79kYYg6-UMrKRPeJTbHdGR0juZ2OwFZmkuYgeYe5X+cm_sQ@mail.gmail.com","threadId":"46361","inReplyTo":"20170712205734.h77fgbbkavwpkr4h@sigill.intra.peff.net","subject":"Re: [PATCH] RFC: Introduce '.gitorderfile'","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2017-07-12T21:08:35Z","receivedAt":"2017-07-12T21:08:42Z","isPatch":true,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Wed, Jul 12, 2017 at 1:57 PM, Jeff King wrote:\n> On Wed, Jul 12, 2017 at 01:44:46PM -0700, Junio C Hamano wrote:\n>\n>> Stefan Beller writes:\n>>\n>> > I want to force myself to think about the design before pointing out\n>> > memory leaks and coding style, so the least I would wish for is:\n>> > *.h\n>> > *.c\n>> > but as we have more to look at, I would want to have the most abstract\n>> > thing to come first. And most abstract from the actual code is the\n>> > user interaction, the documentation.\n>>\n>> This is exactly why I invented the orderfile in the first place.\n>> But such a \"policy\" is not something a project would want to enforce\n>> its users all the time; it is left to personal preference of the\n>> participants.\n>>\n>> Just set diff.orderFile to suit your taste without bothering other\n>> people, I would say.\n>\n> I could see somebody arguing that format-patch should respect a project\n> preference, since its primary purpose is to communicate your work to the\n> rest of the project.\n>\n> But then you could make a similar argument for other diff options, too.\n\nThis similar argument would be to have a in-tree configuration for\n--unified= for example?\n\nThis triggers two reactions for me:\n\n(a) We should totally do that.\n Different projects have different coding styles (e.g. opening brace\n in its own new line or at the end of the condition), which very much impacts\n how useful the context is. So, sure, the project knows best what their\n preference is.\n\n(b) It's a rabbit hole to go down.\n Any config option that format-patch respects can be argued to be useful\n to be preset by a project. So in the end we'd have a \".gitconfig\"\nfile offering\n good defaults for people using that project. This may have security\nimplications.\n And it's a lot of work.\n\nI see your point for (b), I'll think about it more.\n\nThanks,\nStefan\n"},{"id":"324311","messageId":"xmqqzic9z69i.fsf@gitster.mtv.corp.google.com","threadId":"46361","inReplyTo":"CAGZ79kYftkxbDY2E_=2w0VYx8COF_yc61h78gs2qaraK9HRSuA@mail.gmail.com","subject":"Re: [PATCH] RFC: Introduce '.gitorderfile'","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-07-12T21:37:13Z","receivedAt":"2017-07-12T21:37:25Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Stefan Beller writes:\n\n> 2. collaboration.\n> When I want to review a patch from the mailing list,\n> I could (a) download the patch, apply locally, see the diff\n> formatted nicely according to diff.orderFile.\n\nIf you are not doing a review of a patch with complex changes that\nbenefits by a local diff.orderfile (i.e. only in the mail client\nwithout applying and viewing the changes in wider context), then you\neither (1) have a much greater memory than I do and know all the\ncode outside the patch context by heart, or (2) not reviewing them\nproperly in context.\n\nI tend to suspect that it is the latter case, so that argument does\nnot sound convincing at least to me.\n\nNo, I do not apply all patches before commenting from my mailbox; a\none or two-pager patch can often be viewed and judged without much\nsurrounding context, and can be answered in the mail client, perhaps\nwhile running \"less\" on some related files that may or may not be\ntouched by the patch in another terminal, without applying the\npatch. But such a one or two-pager patch can be viewed in any\npresentation order and do not behefit much fro diff.orderfile\nanyway.\n"},{"id":"324313","messageId":"CAGZ79kZuMirZVrWTQ5eU7izYWyM8YtvDzMh4gRzvGXXVp=NMkQ@mail.gmail.com","threadId":"46361","inReplyTo":"xmqqzic9z69i.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH] RFC: Introduce '.gitorderfile'","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2017-07-12T21:55:42Z","receivedAt":"2017-07-12T21:55:54Z","isPatch":true,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Wed, Jul 12, 2017 at 2:37 PM, Junio C Hamano wrote:\n> Stefan Beller writes:\n>\n>> 2. collaboration.\n>> When I want to review a patch from the mailing list,\n>> I could (a) download the patch, apply locally, see the diff\n>> formatted nicely according to diff.orderFile.\n>\n> If you are not doing a review of a patch with complex changes that\n> benefits by a local diff.orderfile (i.e. only in the mail client\n> without applying and viewing the changes in wider context), then you\n> either (1) have a much greater memory than I do and know all the\n> code outside the patch context by heart, or (2) not reviewing them\n> properly in context.\n>\n> I tend to suspect that it is the latter case, so that argument does\n> not sound convincing at least to me.\n\nNote that this request originated from\nhttps://public-inbox.org/git/cover.1499800530.git.jonathantanmy@google.com/\n\nThere are different sorts of patches to review:\n(a) major new features, introducing radically new concepts.\n Example given above.\n\n In this case I neither need (1) nor (2). I want to get the abstract\n design and then decide if it is worth my time to pursue reviewing the\n details of the patch.\n\n The order file makes an impact!\n\n(b) minor new features (in the big picture of a major feature), refactorings\n Examples: 96dc883b3c, repository: enable initialization of submodules\n lb/status-stash-count\n\n Reviewing these patches requires more diving into code, but you'd\n still want to make a call early on whether to reject the design\n before calling out the memory leak that you found after applying\n the patch.\n\n The order file *may* be useful.\n\n(c) updating existing things\n (bug fixes, documentation, improving performance)\n Example: jk/reflog-walk-maint\n\n When looking at these changes, (2) is the answer.\n I look at surrounding code (there may be no need to apply\n the patch though, it depends)\n\n The order file is useless, IMHO, but also does not produce harm.\n\n> No, I do not apply all patches before commenting from my mailbox; a\n> one or two-pager patch can often be viewed and judged without much\n> surrounding context, and can be answered in the mail client, perhaps\n> while running \"less\" on some related files that may or may not be\n> touched by the patch in another terminal, without applying the\n> patch. But such a one or two-pager patch can be viewed in any\n> presentation order and do not behefit much fro diff.orderfile\n> anyway.\n\nThis sounds like (c), which we have a lot more of than (a) or (b).\n\nThanks for your thoughts,\nStefan\n"},{"id":"324326","messageId":"xmqqa849yzwh.fsf@gitster.mtv.corp.google.com","threadId":"46361","inReplyTo":"20170712205734.h77fgbbkavwpkr4h@sigill.intra.peff.net","subject":"Re: [PATCH] RFC: Introduce '.gitorderfile'","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-07-12T23:54:38Z","receivedAt":"2017-07-12T23:54:45Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> I could see somebody arguing that format-patch should respect a project\n> preference, since its primary purpose is to communicate your work to the\n> rest of the project.\n>\n> But then you could make a similar argument for other diff options, too.\n\nYeah, and that opens a whole can of worms.\n\nWe let projects to ship clean/smudge or textconv filters and also\nmark paths to which these tools may be of help, but we do not let\nprojects to automatically enable them in the cloned repository. The\nprojects must _tell_ the user how to run the last step (e.g. \"There\nis a tools/setup-my-clone script shipped with the source; running it\nwill add necessary configurations to work better with our project\").\n\nI do not think usefulness of diff.orderfile is being questioned, but\nI think it is something we should treat just like any other thing\nthat affects repository configuration. A .gitorderfile that allows\nthe project to behave as if we allowed to auto-enable just one thing\nin the clone, while not allowing others, a source of issues and\nunnecessary headaches later.\n\nBesides, diff-order is *not* the only order that matters in the use\nof the system, and we _will_ regret the name \".gitorderfile\" later,\nas people would start making noises about forcing ls-files and other\nthings to also show the list following that order.\n\n\n"},{"id":"324372","messageId":"20170713155923.a2nissoyczvewoh3@sigill.intra.peff.net","threadId":"46361","inReplyTo":"CAGZ79kYYg6-UMrKRPeJTbHdGR0juZ2OwFZmkuYgeYe5X+cm_sQ@mail.gmail.com","subject":"Re: [PATCH] RFC: Introduce '.gitorderfile'","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2017-07-13T15:59:23Z","receivedAt":"2017-07-13T15:59:31Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Jul 12, 2017 at 02:08:35PM -0700, Stefan Beller wrote:\n\n> > I could see somebody arguing that format-patch should respect a project\n> > preference, since its primary purpose is to communicate your work to the\n> > rest of the project.\n> >\n> > But then you could make a similar argument for other diff options, too.\n> \n> This similar argument would be to have a in-tree configuration for\n> --unified= for example?\n\nYes, that was exactly the option I was thinking of. :)\n\n> This triggers two reactions for me:\n> \n> (a) We should totally do that.\n> Different projects have different coding styles (e.g. opening brace\n> in its own new line or at the end of the condition), which very much impacts\n> how useful the context is. So, sure, the project knows best what their\n> preference is.\n> \n> (b) It's a rabbit hole to go down.\n> Any config option that format-patch respects can be argued to be useful\n> to be preset by a project. So in the end we'd have a \".gitconfig\"\n> file offering\n> good defaults for people using that project. This may have security\n> implications.\n> And it's a lot of work.\n> \n> I see your point for (b), I'll think about it more.\n\nAnd yes, I had both of those reactions, too. We've had the\n\"project-level .gitconfig\" discussion many times over the years. And it\ngenerally comes back to \"you can ship a snippet of config and then give\npeople a script which adds it to their repo\".\n\n-Peff\n"},{"id":"324373","messageId":"20170713160014.laowcywx7pb5we77@sigill.intra.peff.net","threadId":"46361","inReplyTo":"xmqqa849yzwh.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH] RFC: Introduce '.gitorderfile'","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2017-07-13T16:00:14Z","receivedAt":"2017-07-13T16:00:26Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Jul 12, 2017 at 04:54:38PM -0700, Junio C Hamano wrote:\n\n> Jeff King writes:\n> \n> > I could see somebody arguing that format-patch should respect a project\n> > preference, since its primary purpose is to communicate your work to the\n> > rest of the project.\n> >\n> > But then you could make a similar argument for other diff options, too.\n> \n> Yeah, and that opens a whole can of worms.\n> \n> We let projects to ship clean/smudge or textconv filters and also\n> mark paths to which these tools may be of help, but we do not let\n> projects to automatically enable them in the cloned repository. The\n> projects must _tell_ the user how to run the last step (e.g. \"There\n> is a tools/setup-my-clone script shipped with the source; running it\n> will add necessary configurations to work better with our project\").\n> \n> I do not think usefulness of diff.orderfile is being questioned, but\n> I think it is something we should treat just like any other thing\n> that affects repository configuration. A .gitorderfile that allows\n> the project to behave as if we allowed to auto-enable just one thing\n> in the clone, while not allowing others, a source of issues and\n> unnecessary headaches later.\n\nThanks for writing this out. That was exactly what I was trying to imply\nwith my final statement, but you said it much better. :)\n\n> Besides, diff-order is *not* the only order that matters in the use\n> of the system, and we _will_ regret the name \".gitorderfile\" later,\n> as people would start making noises about forcing ls-files and other\n> things to also show the list following that order.\n\nI'd also agree with this.\n\n-Peff\n"},{"id":"324377","messageId":"CAGZ79kbgypimtWE32SnDrG-QWT6gF3WGxR5mi785F_rwvRPOuA@mail.gmail.com","threadId":"46361","inReplyTo":"20170713155923.a2nissoyczvewoh3@sigill.intra.peff.net","subject":"Re: [PATCH] RFC: Introduce '.gitorderfile'","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2017-07-13T17:30:59Z","receivedAt":"2017-07-13T17:31:05Z","isPatch":true,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Thu, Jul 13, 2017 at 8:59 AM, Jeff King wrote:\n>> This triggers two reactions for me:\n>>\n>> (a) We should totally do that.\n>\n>> (b) It's a rabbit hole to go down.\n>\n> And yes, I had both of those reactions, too. We've had the\n> \"project-level .gitconfig\" discussion many times over the years. And it\n> generally comes back to \"you can ship a snippet of config and then give\n> people a script which adds it to their repo\".\n\nI see this \"project-level .gitconfig\" via the .gitmodules file.\nSee GITMODULES(5), anything except submodule..path is\njust project-level .gitconfig, so in that sense we already threw out the\nbaby with the bathwater. I think we want to be extra careful to not add\nmore possible options into the .gitmodules file, now that we established\na strong stance on not shipping a project-level .gitconfig.\n\nThanks,\nStefan\n"},{"id":"324378","messageId":"20170713173259.GA30081@google.com","threadId":"46361","inReplyTo":"CAGZ79kbgypimtWE32SnDrG-QWT6gF3WGxR5mi785F_rwvRPOuA@mail.gmail.com","subject":"Re: [PATCH] RFC: Introduce '.gitorderfile'","fromName":"Brandon Williams","fromEmail":"bmwill@google.com","sentAt":"2017-07-13T17:32:59Z","receivedAt":"2017-07-13T17:33:07Z","isPatch":true,"sender":{"key":"bwilliams.eng@gmail.com","avatar":null},"body":"On 07/13, Stefan Beller wrote:\n> On Thu, Jul 13, 2017 at 8:59 AM, Jeff King wrote:\n> >> This triggers two reactions for me:\n> >>\n> >> (a) We should totally do that.\n> >\n> >> (b) It's a rabbit hole to go down.\n> >\n> > And yes, I had both of those reactions, too. We've had the\n> > \"project-level .gitconfig\" discussion many times over the years. And it\n> > generally comes back to \"you can ship a snippet of config and then give\n> > people a script which adds it to their repo\".\n> \n> I see this \"project-level .gitconfig\" via the .gitmodules file.\n> See GITMODULES(5), anything except submodule..path is\n> just project-level .gitconfig, so in that sense we already threw out the\n> baby with the bathwater. I think we want to be extra careful to not add\n> more possible options into the .gitmodules file, now that we established\n> a strong stance on not shipping a project-level .gitconfig.\n\nI'm trying to work on cleaning up the submodule-config a bit and as a\nresult I should be able to make it more difficult to ship more\nproject-level configurations in .gitmodules\n\n-- \nBrandon Williams\n"},{"id":"324415","messageId":"xmqqr2xkw3qt.fsf@gitster.mtv.corp.google.com","threadId":"46361","inReplyTo":"CAGZ79kbgypimtWE32SnDrG-QWT6gF3WGxR5mi785F_rwvRPOuA@mail.gmail.com","subject":"Re: [PATCH] RFC: Introduce '.gitorderfile'","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-07-13T19:12:10Z","receivedAt":"2017-07-13T19:12:17Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Stefan Beller writes:\n\n> On Thu, Jul 13, 2017 at 8:59 AM, Jeff King wrote:\n>>> This triggers two reactions for me:\n>>>\n>>> (a) We should totally do that.\n>>\n>>> (b) It's a rabbit hole to go down.\n>>\n>> And yes, I had both of those reactions, too. We've had the\n>> \"project-level .gitconfig\" discussion many times over the years. And it\n>> generally comes back to \"you can ship a snippet of config and then give\n>> people a script which adds it to their repo\".\n>\n> I see this \"project-level .gitconfig\" via the .gitmodules file.\n> See GITMODULES(5), anything except submodule..path is\n> just project-level .gitconfig,...\n\nThey were from day one meant as a suggestion made by the project.\nYou do not have to follow them and you are free to update them,\ni.e. after \"submodule init\" copied URL to point at a closer mirror,\nfor example.\n"},{"id":"324417","messageId":"CAGZ79kao8=L33jqSFdmYp4NhKfCKDmoqYWvCzuMJ2+Pfq=SYEA@mail.gmail.com","threadId":"46361","inReplyTo":"xmqqr2xkw3qt.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH] RFC: Introduce '.gitorderfile'","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2017-07-13T19:20:09Z","receivedAt":"2017-07-13T19:20:15Z","isPatch":true,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Thu, Jul 13, 2017 at 12:12 PM, Junio C Hamano wrote:\n> Stefan Beller writes:\n>\n>> On Thu, Jul 13, 2017 at 8:59 AM, Jeff King wrote:\n>>>> This triggers two reactions for me:\n>>>>\n>>>> (a) We should totally do that.\n>>>\n>>>> (b) It's a rabbit hole to go down.\n>>>\n>>> And yes, I had both of those reactions, too. We've had the\n>>> \"project-level .gitconfig\" discussion many times over the years. And it\n>>> generally comes back to \"you can ship a snippet of config and then give\n>>> people a script which adds it to their repo\".\n>>\n>> I see this \"project-level .gitconfig\" via the .gitmodules file.\n>> See GITMODULES(5), anything except submodule..path is\n>> just project-level .gitconfig,...\n>\n> They were from day one meant as a suggestion made by the project.\n> You do not have to follow them and you are free to update them,\n> i.e. after \"submodule init\" copied URL to point at a closer mirror,\n> for example.\n\nThe URL is somewhat special as its copying into the .git/config\nalso marks the submodule as interesting (no matter if the URL is\nchanged by the user).\n\nThe point I was trying to make is best demonstrated in\nt5526-fetch-submodules.sh:\n\n> ok 7 - using fetchRecurseSubmodules=true in .gitmodules recurses into submodules\n> ok 8 - --no-recurse-submodules overrides .gitmodules config\n> ok 9 - using fetchRecurseSubmodules=false in .git/config overrides setting in .gitmodules\n\nThey were not suggestions, but defaults dictated by the project.\n\nIf the user did not change their config, they did as the project\nsaid. I was not there on day one to remember if they are merely\nmeant as suggestions, but their behavior is asserting.\n"},{"id":"324442","messageId":"xmqq8tjsukrn.fsf@gitster.mtv.corp.google.com","threadId":"46361","inReplyTo":"CAGZ79kao8=L33jqSFdmYp4NhKfCKDmoqYWvCzuMJ2+Pfq=SYEA@mail.gmail.com","subject":"Re: [PATCH] RFC: Introduce '.gitorderfile'","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-07-13T20:47:24Z","receivedAt":"2017-07-13T20:47:30Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Stefan Beller writes:\n\n> The point I was trying to make is best demonstrated in\n> t5526-fetch-submodules.sh:\n>\n>> ok 7 - using fetchRecurseSubmodules=true in .gitmodules recurses into submodules\n>> ok 8 - --no-recurse-submodules overrides .gitmodules config\n>> ok 9 - using fetchRecurseSubmodules=false in .git/config overrides setting in .gitmodules\n>\n> They were not suggestions, but defaults dictated by the project.\n\nYeah, and that is why I kept thinking that recurse-submodules may be\na huge mistake.\n"}]}