{"thread":{"id":"56889","subject":"Re: [GIT PULL] per signal_struct coredumps","startedAt":"2021-11-13T19:14:51Z","lastAt":"2021-11-18T09:29:20Z","messageCount":8,"participants":["Linus Torvalds","Junio C Hamano","Ævar Arnfjörð Bjarmason","Eric W. Biederman"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"441071","messageId":"CAHk-=wh8v4OC=9rjFs-QH0evVrGQu+wCVL5gE8Y-uTvqh42XNA@mail.gmail.com","threadId":"56889","inReplyTo":"871r3uy2vw.fsf@disp2133","subject":"Re: [GIT PULL] per signal_struct coredumps","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2021-11-13T19:14:28Z","receivedAt":"2021-11-13T19:14:51Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"[ Coming back to this email because I'm starting to see the light at\nthe end of the merge window tunnel .. ]\n\nAdding the git list to see if somebody has suggestions, and\ntop-posting because the email from Eric is more of \"explanation for\nthe issue\" than anything else, so I'm quoting it at the end for\ncontext.\n\nThe basic issue is how to sanely keep track of a cover letter when you\nhave a branch that you haven't sent out yet, but will ask somebody to\npull. It may still be seeing more testing and development before that\npull happens, though.\n\nThis very much smells of what the \"branch description\" is all about, but\n\n (a) I suspect \"git branch --edit-description\" is not very well known\n\n (b) it works well with \"git request-pull\", but not so much some other\nthings (like copying it into a signed tag)\n\n (c) it makes an unholy mess of your config file if you actually use\nit for extensive explanations (branch descriptions _work_ for\nmulti-line messages, but it really was designed as a one-liner thing).\n\n (d) it doesn't work across repositories (ie multiple developers or\neven just a single developer on multiple machines).\n\nIOW, the \"branch description\" is _kind_ of the right thing, but not really.\n\nThe fake merge _does_ solve all these issues, it just then ends up\nleaving that turd around in the history.\n\nAn empty commit would do it as well, but an empty commit very easily\ngets lost (git rebase etc). The fake merge does have similar issues.\n\nBoth a fake merge, and an empty commit have the advantage that they\nare easy to see and work with (ie \"git log\" and all the other git\nworkflows work very naturally).\n\nComments from git people?\n\n Linus\n\nOn Fri, Nov 5, 2021 at 9:38 AM Eric W. Biederman wrote:\n>\n> Linus Torvalds writes:\n>\n> > On Wed, Nov 3, 2021 at 12:07 PM Eric W. Biederman wrote:\n> >\n> > I've pulled it, but I'm not convinced about that odd extra merge\n> > commit that contains the commentary.\n> >\n> > That's what signed tags are for, and they have that explanation that\n> > then makes it into the merge - plus they have the crypto signature to\n> > show it all comes from you.\n> >\n> > So that would have been the much better model than a fake extra merge.\n> >\n> > But at least that extra merge did have explanations, so at least it\n> > doesn't trigger me on _that_ level.\n>\n> I have been creating those when I place a patchset with an interesting\n> cover letter in a branch. Now with the entire branch being just that\n> patchset, it doesn't make a lot of sense (except as somewhere to store\n> that cover letter so I don't loose it). At other times when there are\n> multiple sets of changes on a single branch I think it makes more sense.\n>\n> Am I missing a better way to preserve the cover letter for the\n> changes when multiple sets of changes land in a single branch?\n>\n> Eric\n"},{"id":"441075","messageId":"xmqqbl2nmemx.fsf@gitster.g","threadId":"56889","inReplyTo":"CAHk-=wh8v4OC=9rjFs-QH0evVrGQu+wCVL5gE8Y-uTvqh42XNA@mail.gmail.com","subject":"Re: [GIT PULL] per signal_struct coredumps","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-11-14T06:32:06Z","receivedAt":"2021-11-14T06:32:12Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> The basic issue is how to sanely keep track of a cover letter when you\n> have a branch that you haven't sent out yet, but will ask somebody to\n> pull. It may still be seeing more testing and development before that\n> pull happens, though.\n>\n> This very much smells of what the \"branch description\" is all about, but\n>\n> (a) I suspect \"git branch --edit-description\" is not very well known\n\nTrue.\n\n\n> (b) it works well with \"git request-pull\", but not so much some other\n> things (like copying it into a signed tag)\n\nI think that is just a matter of programming ;-)\n\n> (c) it makes an unholy mess of your config file if you actually use\n> it for extensive explanations (branch descriptions _work_ for\n> multi-line messages, but it really was designed as a one-liner thing).\n\nNot, really.\n\nThe \"-m\" option similar to \"commit/tag\" is deliberately omitted and\nuse of editor is forced, to encourage better than one-liner\ninformation. cf. b7200e83 (branch: teach --edit-description option,\n2011-09-20).\n\nThe unholy mess is true if you are in the habit of editing .git/config\nin your editor, but that is to be expected if you are storing multi\nparagraph description as a value of a configuration variable.\n\n> (d) it doesn't work across repositories (ie multiple developers or\n> even just a single developer on multiple machines).\n\nThis is the biggest issue.\n\n> IOW, the \"branch description\" is _kind_ of the right thing, but not really.\n\nHaving said all that, quite honestly, as the inventor of the\n\"--edit-description\", I did it as sort of a joke, and not a serious\n\"feature\".\n\n> An empty commit would do it as well, but an empty commit very easily\n> gets lost (git rebase etc). The fake merge does have similar issues.\n\nThese days, I think rebase distinguishes between \"an empty commit\nthat is deliberately empty from the beginning\" and \"a commit that\nwas not empty, but because we are applying on a new base, it has\nbecome unnecessary and empty\", and we can tell the command to drop\nthe latter while keeping the former. So if I were to design a\nrecommended workflow (and add any missing workflow elements), it\nwould be:\n\n - You develop your N-patch series on a branch;\n\n - You conclude with an empty commit that records your cover letter\n material.\n\n - \"git commit\" may want to learn a new option that automatically\n prepares summary of the last N patches in the commit log\n editor, and the option should imply the \"--allow-empty\" option.\n That would help when editing such an empty commit that will\n become the cover letter.\n\n - You repeatedly \"rebase -i\", \"cherry-pick\", etc. to whip your\n branch into shape.\n\n - You can push and fetch such a branch among your machines and your\n group.\n\n - \"git format-patch\" may want to recognize that the topmost commit\n is an empty commit, and use that as the seed material for the\n cover letter.\n\n - If your project's pull request requires a signed tag with cover\n letter material, \"git tag -s\" may want to learn a new option to\n be fed such a branch with N-patch plus the topmost empty commit,\n and tag the last real commit in the topic (i.e. the parent of the\n topmost empty commit) with material taken from the topmost empty\n commit.\n\n> Both a fake merge, and an empty commit have the advantage that they\n> are easy to see and work with (ie \"git log\" and all the other git\n> workflows work very naturally).\n>\n> Comments from git people?\n>\n> Linus\n\nI can see how the above outline would work. I do not know if it\nwould work well for your project, or there are other workflows for\nwhich the above outline would be insufficient.\n\n"},{"id":"441079","messageId":"211114.86h7cft6av.gmgdl@evledraar.gmail.com","threadId":"56889","inReplyTo":"xmqqbl2nmemx.fsf@gitster.g","subject":"Re: [GIT PULL] per signal_struct coredumps","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2021-11-14T09:36:46Z","receivedAt":"2021-11-14T09:50:25Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Sat, Nov 13 2021, Junio C Hamano wrote:\n\n> Linus Torvalds writes:\n>\n>> The basic issue is how to sanely keep track of a cover letter when you\n>> have a branch that you haven't sent out yet, but will ask somebody to\n>> pull. It may still be seeing more testing and development before that\n>> pull happens, though.\n>>\n>> This very much smells of what the \"branch description\" is all about, but\n>>\n>> (a) I suspect \"git branch --edit-description\" is not very well known\n>\n> True.\n>\n>\n>> (b) it works well with \"git request-pull\", but not so much some other\n>> things (like copying it into a signed tag)\n>\n> I think that is just a matter of programming ;-)\n>\n>> (c) it makes an unholy mess of your config file if you actually use\n>> it for extensive explanations (branch descriptions _work_ for\n>> multi-line messages, but it really was designed as a one-liner thing).\n>\n> Not, really.\n>\n> The \"-m\" option similar to \"commit/tag\" is deliberately omitted and\n> use of editor is forced, to encourage better than one-liner\n> information. cf. b7200e83 (branch: teach --edit-description option,\n> 2011-09-20).\n>\n> The unholy mess is true if you are in the habit of editing .git/config\n> in your editor, but that is to be expected if you are storing multi\n> paragraph description as a value of a configuration variable.\n>\n>> (d) it doesn't work across repositories (ie multiple developers or\n>> even just a single developer on multiple machines).\n>\n> This is the biggest issue.\n>\n>> IOW, the \"branch description\" is _kind_ of the right thing, but not really.\n>\n> Having said all that, quite honestly, as the inventor of the\n> \"--edit-description\", I did it as sort of a joke, and not a serious\n> \"feature\".\n>\n>> An empty commit would do it as well, but an empty commit very easily\n>> gets lost (git rebase etc). The fake merge does have similar issues.\n>\n> These days, I think rebase distinguishes between \"an empty commit\n> that is deliberately empty from the beginning\" and \"a commit that\n> was not empty, but because we are applying on a new base, it has\n> become unnecessary and empty\", and we can tell the command to drop\n> the latter while keeping the former. So if I were to design a\n> recommended workflow (and add any missing workflow elements), it\n> would be:\n>\n> - You develop your N-patch series on a branch;\n>\n> - You conclude with an empty commit that records your cover letter\n> material.\n>\n> - \"git commit\" may want to learn a new option that automatically\n> prepares summary of the last N patches in the commit log\n> editor, and the option should imply the \"--allow-empty\" option.\n> That would help when editing such an empty commit that will\n> become the cover letter.\n>\n> - You repeatedly \"rebase -i\", \"cherry-pick\", etc. to whip your\n> branch into shape.\n>\n> - You can push and fetch such a branch among your machines and your\n> group.\n>\n> - \"git format-patch\" may want to recognize that the topmost commit\n> is an empty commit, and use that as the seed material for the\n> cover letter.\n>\n> - If your project's pull request requires a signed tag with cover\n> letter material, \"git tag -s\" may want to learn a new option to\n> be fed such a branch with N-patch plus the topmost empty commit,\n> and tag the last real commit in the topic (i.e. the parent of the\n> topmost empty commit) with material taken from the topmost empty\n> commit.\n>\n>> Both a fake merge, and an empty commit have the advantage that they\n>> are easy to see and work with (ie \"git log\" and all the other git\n>> workflows work very naturally).\n>>\n>> Comments from git people?\n>>\n>> Linus\n>\n> I can see how the above outline would work. I do not know if it\n> would work well for your project, or there are other workflows for\n> which the above outline would be insufficient.\n\nThere's a more general question to be considered here which is how the\nobject model is supposed to keep track of this sort of thing, if at all.\n\nOne solution is (dare I say?) \"git notes\". I.e. if you're keeping a\nnotes/CL about a set of commits you could publish a notes branch where\nthe CL is by convention on the tip of that commit. Now when someone else\n\"takes over\" your branch they'll \"git fetch\" your notes, have set up\napproprite core.{notes,display}Ref, copy your notes into their own note,\nthen edit/amend/publish/push.\n\nSetting that up should be small matter of scripting around existing\ncommands, and should be an improvement on having to manually share or\nextract what's now stored in branch descriptions.\n\nOn the other hand that information is rather unwieldy to deal with, and\n\"notes\" support isn't very widespread on e.g. git hosting sites\n(althougt that's also a chicken & egg problem).\n\nAnother solution that fits nicely into the data model is to consider\nthis the same \"problem\" as PGP signed commits. I.e. an an\n\"x-metadata-cover-letter\" header could be added to the tip commit object\nitself, either an --allow-empty --allow-empty-message commit, or \"git\nmerge --no-ff\" in case the range that CL covers is ambiguous (which in\nthat case would start with the merge base of the two parents).\n\nIf git's going to have some native-ish solution to this problem it\nshould also be considered that what E-Mail based workflows want to do\nwith CL's is analogous to what popular hosting sites are doing with the\ntext field for a PR/MR. I.e. ideally such a cover letter could be\nstored/structured in such a way that if you pushed a branch to open such\na PR/MR the \"cover letter\" could be extracted.\n\nWhich also gets into questions of if that data should be stored\npermanently. I.e. it's a merge commit as described above would the\nperson merging it expect to merge down the parent (i.e. sans\ncoverletter), or if it's stored in the commit object rewrite the commit?\n\nAnd for some text-only cover letters might suffice, but git users in\ngeneral observably upload attachments to explain their commits (say a\nscreenshot of performance numbers). So a design that combined the above\nwith the ability to point at a tree might be preferred.\n"},{"id":"441085","messageId":"87pmr2k68f.fsf@email.froward.int.ebiederm.org","threadId":"56889","inReplyTo":"xmqqbl2nmemx.fsf@gitster.g","subject":"Re: [GIT PULL] per signal_struct coredumps","fromName":"Eric W. Biederman","fromEmail":"ebiederm@xmission.com","sentAt":"2021-11-14T17:16:32Z","receivedAt":"2021-11-14T17:17:42Z","isPatch":false,"sender":{"key":"ebiederm@xmission.com","avatar":"https://avatars.githubusercontent.com/u/7477136?v=4"},"body":"Junio C Hamano writes:\n\n> Linus Torvalds writes:\n>\n>> The basic issue is how to sanely keep track of a cover letter when you\n>> have a branch that you haven't sent out yet, but will ask somebody to\n>> pull. It may still be seeing more testing and development before that\n>> pull happens, though.\n>>\n>> This very much smells of what the \"branch description\" is all about, but\n>>\n>> (a) I suspect \"git branch --edit-description\" is not very well known\n>\n> True.\n>\n>\n>> (b) it works well with \"git request-pull\", but not so much some other\n>> things (like copying it into a signed tag)\n>\n> I think that is just a matter of programming ;-)\n>\n>> (c) it makes an unholy mess of your config file if you actually use\n>> it for extensive explanations (branch descriptions _work_ for\n>> multi-line messages, but it really was designed as a one-liner thing).\n>\n> Not, really.\n>\n> The \"-m\" option similar to \"commit/tag\" is deliberately omitted and\n> use of editor is forced, to encourage better than one-liner\n> information. cf. b7200e83 (branch: teach --edit-description option,\n> 2011-09-20).\n>\n> The unholy mess is true if you are in the habit of editing .git/config\n> in your editor, but that is to be expected if you are storing multi\n> paragraph description as a value of a configuration variable.\n>\n>> (d) it doesn't work across repositories (ie multiple developers or\n>> even just a single developer on multiple machines).\n>\n> This is the biggest issue.\n>\n>> IOW, the \"branch description\" is _kind_ of the right thing, but not really.\n>\n> Having said all that, quite honestly, as the inventor of the\n> \"--edit-description\", I did it as sort of a joke, and not a serious\n> \"feature\".\n>\n>> An empty commit would do it as well, but an empty commit very easily\n>> gets lost (git rebase etc). The fake merge does have similar issues.\n>\n> These days, I think rebase distinguishes between \"an empty commit\n> that is deliberately empty from the beginning\" and \"a commit that\n> was not empty, but because we are applying on a new base, it has\n> become unnecessary and empty\", and we can tell the command to drop\n> the latter while keeping the former. So if I were to design a\n> recommended workflow (and add any missing workflow elements), it\n> would be:\n>\n> - You develop your N-patch series on a branch;\n>\n> - You conclude with an empty commit that records your cover letter\n> material.\n>\n> - \"git commit\" may want to learn a new option that automatically\n> prepares summary of the last N patches in the commit log\n> editor, and the option should imply the \"--allow-empty\" option.\n> That would help when editing such an empty commit that will\n> become the cover letter.\n>\n> - You repeatedly \"rebase -i\", \"cherry-pick\", etc. to whip your\n> branch into shape.\n>\n> - You can push and fetch such a branch among your machines and your\n> group.\n>\n> - \"git format-patch\" may want to recognize that the topmost commit\n> is an empty commit, and use that as the seed material for the\n> cover letter.\n>\n> - If your project's pull request requires a signed tag with cover\n> letter material, \"git tag -s\" may want to learn a new option to\n> be fed such a branch with N-patch plus the topmost empty commit,\n> and tag the last real commit in the topic (i.e. the parent of the\n> topmost empty commit) with material taken from the topmost empty\n> commit.\n\nI think an empty commit at the top of a development branch sounds\nlike a nice place to store the cover letter for a set of changes.\nThat is a related problem but that is not the problem that inspired\nthe no-op merge commits.\n\n\n\nI have not seen addressed the workflow that actually inspired this\nodd thing I am doing. So let me see if I can describe the problem\nthat inspired the merge commit more clearly.\n\nBefore the merge window for v5.17 I expect to be working on\na topic I will loosely call \"do_exit_coredumps_and_signals\".\n\nThere are going to be several changesets (something like):\n\"Move coredumps rendezvous into get_signal\"\n\"Use the same exit code in all implementations of die\"\n\"Use signal short circuit delivery for coredumps\"\n\"Use signal short circuit delivery whenever possible\"\n\"Replace do_exit with a different helper for use by die\"\n\nEach of those will consist of 5-10 patches and need to be individually\nreviewed and depend upon each other. In the roughly 2 months of\ndevelopment time before v5.17 I can expect to get several of those\nchangesets. Each changeset will depend upon the work of the changeset\nbefore.\n\nAs each changeset is reviewed and finalized I expect I will put it on\nthe topic branch with a merge commit containing the description letter.\nThat merge commit will contain a \"Link:\" tag to the posting on the\nmailing list so that people can find the full description.\n\nWhen put into the topic branch after review the commits are frozen\nand ready to be sent to Linus for merging, when the next merge window\nopens.\n\n\n\n\nWhen the development window closes and the merge window opens I will run\n\"git shortlog\" see what is there and write up a description for the\nentire topic branch. Ideally I will put that into a signed tag etc\nbefore I send it to Linus.\n\nIn the case that triggered this conversation I happened to only have a\nsingle changeset with a single merge commit in the topic branch which\nlooks very odd, but that is mot definitely not the case I want to\noptimize for.\n\n\nThe changes I am making are digging through some old grotty areas of the\nkernel. It isn't uncommon for me to be fixing issues that predate git.\nSo it takes some sleuthing and description so that other people can see\nwhat is going on in each of those changes. So I want to preserve the\ndescription of what and what is going on with those changesets as\nmuch as possible.\n\nA big rollup into a single description for Linus of the entire topic\nbranch is necessary, but will generally not contain all of the detail of\nthe cover letters for the patch sets.\n\nI need something like a merge commit rather than an empty commit so\nthat both the start and the end of the series of changes is shown.\n\nNotes probably don't work because I want the description of what is\ngoing to persist and be available to \"git log\". So that the next poor\nsucker who touches the code can have a change of figuring out what\nI was thinking.\n\nIf I have just one fake-merge I would not mind if request-pull or\nsomething incorporated it, but with several I am most definitely going\nto need to edit the message so it is at the 10,000 foot view of the\nentire topic branch, and not at the nitty gritty view of a single patch\nset.\n\n\nThere was only a single changeset in the branch that caused this because\nI am making what is remotely possibly a breaking change and I need to\nget it into a released code base to verify that I am not breaking\nanyone. If I don't need to revert that change then there are very\nsubstantial cleanups I can make in the kernel. So all of the\nadditional changesets have to wait until v5.16 is released before I can\nask Linus to pull them.\n\nWhich meant during this one development cycle I was not able to build\none changeset on top of another changeset because one of the changes is\nsomething of a risk. That is a degenerate case of my normal expected\nwork-flow.\n\n\nEric\n"},{"id":"441259","messageId":"xmqqk0h8bnob.fsf@gitster.g","threadId":"56889","inReplyTo":"87pmr2k68f.fsf@email.froward.int.ebiederm.org","subject":"Re: [GIT PULL] per signal_struct coredumps","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-11-16T06:49:08Z","receivedAt":"2021-11-16T06:49:21Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"ebiederm@xmission.com (Eric W. Biederman) writes:\n\n> I have not seen addressed the workflow that actually inspired this\n> odd thing I am doing. So let me see if I can describe the problem\n> that inspired the merge commit more clearly.\n\nWhere can I learn more about the \"fake\" merge commit (assume I do\nnot know anything more than what Linus wrote in the message to the\ngit mailing list)? Even after re-reading your description twice,\nI get that you are using an extra merge commit as a place to store\nthe cover letter material, I am guessing that one of the parents\n(which one???) is the tip of the finished \"changeset\" (I take the\nword to mean \"one of more commits on the same theme, in a single\nstrand of pearls\"), but I am not sure what the other parent is to\nmake that a \"merge\". If it is \"fake\", I guess that any random point\nin Linus's history would do, but I can understand that the maintainer\nwould complain about such a seemingly unnecessary (back) merge.\n\n> Before the merge window for v5.17 I expect to be working on\n> a topic I will loosely call \"do_exit_coredumps_and_signals\".\n>\n> There are going to be several changesets (something like):\n> \"Move coredumps rendezvous into get_signal\"\n> \"Use the same exit code in all implementations of die\"\n> \"Use signal short circuit delivery for coredumps\"\n> \"Use signal short circuit delivery whenever possible\"\n> \"Replace do_exit with a different helper for use by die\"\n>\n> Each of those will consist of 5-10 patches and need to be individually\n> reviewed and depend upon each other. In the roughly 2 months of\n> development time before v5.17 I can expect to get several of those\n> changesets. Each changeset will depend upon the work of the changeset\n> before.\n\nUp to this point, I think I get what is going on. You've worked\ntogether with your reviewer and came up several patches to achieve\nthe \"Move coredumps rendezvous into get_signal\" task, so now you\nhave one topic branch that forks from some point in Linus's history\nand houses these patches. If \"Use the same exit code\" topic builds\non the \"Move coredumps\" one, the topic branch for the former may\nfork from the tip of the latter.\n\n> As each changeset is reviewed and finalized I expect I will put it on\n> the topic branch with a merge commit containing the description letter.\n\nThis part I do not understand. What is merged into what? The tip\nof the \"Move coredumps\" series of commits gets merged into the\nprevious stable release from Linus or some appropriate point inhis\nhistory, and the topic branch points at that merge?\n\n> That merge commit will contain a \"Link:\" tag to the posting on the\n> mailing list so that people can find the full description.\n\nIf a signed tag were used to store that description and Link,\nwouldn't that be sufficient? Then Linus would pull that signed tag\nto see it is from you, the merge would show which tag was merged and\nwhat the tag said. And we do not see the fake merge---I think the\nmaintainer's complaint and the problem the fake merge brings into\nthe history is that, while one of its parents, namely, the tip of\nthe \"Move coredumps\" series of commits, does have meaning, the other\nparent does not. It can be any ancient commit.\n\nIt _might_ make it a bit more palatable to Linus if the merit of\nusing a merge includes that the other parent can record the fork\npoint of the main series of commits (i.e. the merge will have to be\ncreated with \"merge --no-ff\"), but I still feel that the argument is\nweak, when a signed tag would work better (and I probably am missing\nthe use cases in which fake merges work better than signed tags).\n\n> When put into the topic branch after review the commits are frozen\n> and ready to be sent to Linus for merging, when the next merge window\n> opens.\n>\n> When the development window closes and the merge window opens I will run\n> \"git shortlog\" see what is there and write up a description for the\n> entire topic branch. Ideally I will put that into a signed tag etc\n> before I send it to Linus.\n\nHere, what do you exactly mean by \"the entire topic branch\"? For a\nsingle \"changeset\" like \"Move coredumps\", or all of the changesets?\n\nAssuming that the answer is the former, and assuming that the \"topic\nbranch\" for \"Move coredumps\" look like:\n\n a. it forks from some point in the upstream history;\n\n b. it build one or more commits on it, a single strand of pearls;\n\n c. it is capped with a (fake) merge to merge the above into some\n point in the upstream history;\n\nwhat is missing from the Git toolset to turn the above two into a\nsigned tag that points at the tip of b. (i.e. without the fake\nmerge)? Ideally, after b. is made, don't you want to go directly to\na signed tag, instead of a (fake) merge?\n\n> In the case that triggered this conversation I happened to only have a\n> single changeset with a single merge commit in the topic branch which\n> looks very odd, but that is mot definitely not the case I want to\n> optimize for.\n\nIt is unclear to me why the number of commits in the b. part\nmatters. Be it one or 40, the (fake) merge at the tip seems\nunnecessary, when the whole thing is merged into the upstream\nhistory.\n\nI seriously doubt that I am getting the whole requirement, as it\nseems that \"develop a series of commits on a branch, that may or may\nnot be dependent with each other, and ask the branch to be pulled by\ngiving the description in a signed tag that points at the tip of the\nwork\" should work OK?\n"},{"id":"441264","messageId":"xmqq8rxobj1k.fsf@gitster.g","threadId":"56889","inReplyTo":"87pmr2k68f.fsf@email.froward.int.ebiederm.org","subject":"Re: [GIT PULL] per signal_struct coredumps","fromName":"Junio C Hamano","fromEmail":"junio@pobox.com","sentAt":"2021-11-16T08:29:11Z","receivedAt":"2021-11-16T08:29:43Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> make that a \"merge\". If it is \"fake\", I guess that any random point\n> in Linus's history would do, but I can understand that the maintainer\n> would complain about such a seemingly unnecessary (back) merge.\n\nHaving thought about it a bit more, I am not sure if these merges\nare truly \"fake\", or just a normal part of distributed development.\n\nAs a degenerated case, first I'd imagine you have a patch series\nthat focuses on a single \"theme\". You perfect the patches, you fork\na topic branch from an appropriate \"public\" commit of your upstream\n(e.g. the last stable release from Linus), you add a signed tag at\nthe tip of that topic branch, and you ask a (subsystem) maintainer\nto pull from you. The subsystem maintainer's tree will have series\nof merges to collect work from other people working in the subsystem\n('x'), and the pull from you will create a merge whose first parent\nis one of these 'x' (i.e. the work by the maintainer so far), and\nthe second parent of it is the tip of your work. The merge commit M\ngives a detailed description of what happend on the side branch and\nits mergetag header carries the contents of the tag you created for\nthe pull request.\n\n \\ \\\n ---x---x---M\n / Subsystem maintainer pulls from you\n /\n ...---o---o (your work)\n\nYour next topic, which is a chunk of the same larger theme, may\ndepend on what you did in the commits in this initial series 'o'.\n\n\n \\ \\ \\ \\\n ---x---x---M---x---x---N\n / / Subsystem maintainer pulls from you again\n / /\n ...---o---o---p---p---p (your second batch)\n\n\nEventually, this will be pulled into Linus's tree when the subsystem\nmaintainer is ready to send the whole thing.\n\n Y--- (Linus's tree)\n / Linus pulls from subsystem maintainer\n \\ \\ \\ \\ /\n ---x---x---M---x---x---N (Subsystem maintainer's tree)\n / /\n / /\n ...---o---o---p---p---p (Your tree)\n\nThe above picture only depicts two topics, one directly building on\ntop of the other, from you, but that is simplified merely for\nillustration purposes. The real history may have more topics, some\nare dependent on others, while some are independent.\n\nNow, if you have many related but more or less independent topic\nbranches that will support a larger theme, it would be quite natural\nif you acted as your own \"subsystem\" maintainer, in other words, in\nthe above picture:\n\n . you are in control of not just the bottom line, but in the middle\n line of development;\n\n . you do not have 'x' that merges from other people;\n\n . but you do have M and N, and use these merges just like a\n subsystem maintainer would use to describe the work done in the\n side branches.\n\nand offer 'N' as the tip of a \"larger\" topic that has internal\nstructure, not just a single strand of pearls, by adding a signed\ntag on 'N' and throwing a pull request at Linus (or whoever is\nimmediately above your level).\n\nIs that what happened (as I said, I lack context)? If so, I do not\nsee much problem in the situation. But this assumes that these so\ncalled \"fake\" merges are merging into right first parents.\n\n\n"},{"id":"441329","messageId":"87lf1ob09z.fsf@email.froward.int.ebiederm.org","threadId":"56889","inReplyTo":"xmqq8rxobj1k.fsf@gitster.g","subject":"Re: [GIT PULL] per signal_struct coredumps","fromName":"Eric W. Biederman","fromEmail":"ebiederm@xmission.com","sentAt":"2021-11-16T15:14:32Z","receivedAt":"2021-11-16T15:15:14Z","isPatch":false,"sender":{"key":"ebiederm@xmission.com","avatar":"https://avatars.githubusercontent.com/u/7477136?v=4"},"body":"Junio C Hamano writes:\n\n> Junio C Hamano writes:\n>\n>> make that a \"merge\". If it is \"fake\", I guess that any random point\n>> in Linus's history would do, but I can understand that the maintainer\n>> would complain about such a seemingly unnecessary (back) merge.\n>\n> Having thought about it a bit more, I am not sure if these merges\n> are truly \"fake\", or just a normal part of distributed development.\n>\n> As a degenerated case, first I'd imagine you have a patch series\n> that focuses on a single \"theme\". You perfect the patches, you fork\n> a topic branch from an appropriate \"public\" commit of your upstream\n> (e.g. the last stable release from Linus), you add a signed tag at\n> the tip of that topic branch, and you ask a (subsystem) maintainer\n> to pull from you. The subsystem maintainer's tree will have series\n> of merges to collect work from other people working in the subsystem\n> ('x'), and the pull from you will create a merge whose first parent\n> is one of these 'x' (i.e. the work by the maintainer so far), and\n> the second parent of it is the tip of your work. The merge commit M\n> gives a detailed description of what happend on the side branch and\n> its mergetag header carries the contents of the tag you created for\n> the pull request.\n>\n> \\ \\\n> ---x---x---M\n> / Subsystem maintainer pulls from you\n> /\n> ...---o---o (your work)\n>\n> Your next topic, which is a chunk of the same larger theme, may\n> depend on what you did in the commits in this initial series 'o'.\n>\n>\n> \\ \\ \\ \\\n> ---x---x---M---x---x---N\n> / / Subsystem maintainer pulls from you again\n> / /\n> ...---o---o---p---p---p (your second batch)\n>\n>\n> Eventually, this will be pulled into Linus's tree when the subsystem\n> maintainer is ready to send the whole thing.\n>\n> Y--- (Linus's tree)\n> / Linus pulls from subsystem maintainer\n> \\ \\ \\ \\ /\n> ---x---x---M---x---x---N (Subsystem maintainer's tree)\n> / /\n> / /\n> ...---o---o---p---p---p (Your tree)\n>\n> The above picture only depicts two topics, one directly building on\n> top of the other, from you, but that is simplified merely for\n> illustration purposes. The real history may have more topics, some\n> are dependent on others, while some are independent.\n>\n> Now, if you have many related but more or less independent topic\n> branches that will support a larger theme, it would be quite natural\n> if you acted as your own \"subsystem\" maintainer, in other words, in\n> the above picture:\n>\n> . you are in control of not just the bottom line, but in the middle\n> line of development;\n>\n> . you do not have 'x' that merges from other people;\n>\n> . but you do have M and N, and use these merges just like a\n> subsystem maintainer would use to describe the work done in the\n> side branches.\n>\n> and offer 'N' as the tip of a \"larger\" topic that has internal\n> structure, not just a single strand of pearls, by adding a signed\n> tag on 'N' and throwing a pull request at Linus (or whoever is\n> immediately above your level).\n>\n> Is that what happened (as I said, I lack context)? If so, I do not\n> see much problem in the situation. But this assumes that these so\n> called \"fake\" merges are merging into right first parents.\n\nYes. I write and post the patches with my developer hat on,\nand I merge them with my maintainer hat on, then ultimately I send\nthem to Linus with the same maintainer hat on.\n\n\nThe full email conversation is at:\nhttps://lore.kernel.org/all/878ry512iv.fsf@disp2133/T/#u\n\nHere is where Linus merged the change:\nhttps://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a602285ac11b019e9ce7c3907328e9f95f4967f0\n\nIn this specific case it is a very degenerate case as there was only one\nset of changes.\n\n\nThe one difference from my work flow and the one you described\nis that I haven't reach the point of signing my pull requests.\n\n\nIn general and especially this cycle I intend to have multiple\nchangesets each with their own merge commit delineating them. Short of\nbeing informed of a better way to work.\n\n\nI suspect the conversation is simply because the pull request was\nsufficiently degenerate that things just looked really weird. But I am\nopen to learning otherwise.\n\nEric\n\n\n\n\n"},{"id":"441586","messageId":"xmqqk0h5yfq3.fsf@gitster.g","threadId":"56889","inReplyTo":"xmqq8rxobj1k.fsf@gitster.g","subject":"Re: [GIT PULL] per signal_struct coredumps","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-11-18T09:29:08Z","receivedAt":"2021-11-18T09:29:20Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> Y--- (Linus's tree)\n> / Linus pulls from subsystem maintainer\n> \\ \\ \\ \\ /\n> ---x---x---M---x---x---N (Subsystem maintainer's tree)\n> / /\n> / /\n> ...---o---o---p---p---p (Your tree)\n>\n> The above picture only depicts two topics, one directly building on\n> top of the other, from you, but that is simplified merely for\n> illustration purposes. The real history may have more topics, some\n> are dependent on others, while some are independent.\n>\n> Now, if you have many related but more or less independent topic\n> branches that will support a larger theme, it would be quite natural\n> if you acted as your own \"subsystem\" maintainer, in other words, in\n> ...\n> and offer 'N' as the tip of a \"larger\" topic that has internal\n> structure, not just a single strand of pearls, by adding a signed\n> tag on 'N' and throwing a pull request at Linus (or whoever is\n> immediately above your level).\n> \n> Is that what happened (as I said, I lack context)? If so, I do not\n> see much problem in the situation. But this assumes that these so\n> called \"fake\" merges are merging into right first parents.\n\nAddendum.\n\nIf you have only one topic (i.e. you do not have o-o and p-p-p in\nthe above picture, but just o-o), then it would be quite strange to\ncreate M and offer it to the upstream, as M's first parent, as well\nas the bottom of the o-o chain, would be something the upstream has\nand the merge would look redundant from upstream's point of view, as\nthey will be creating another merge of their tip and M, at which\npoint they'd rather merge the topmost commit in the o-o chain\ndirectly without having to deal with M.\n\n"}]}