{"thread":{"id":"51414","subject":"Tracking parent branches in Git","startedAt":"2019-07-01T18:50:48Z","lastAt":"2019-07-03T15:58:21Z","messageCount":13,"participants":["Eric Kulcyk","Junio C Hamano","Bryan Turner","rsbecker@nexbridge.com","Eckhard Maaß","Andreas Krey","Philip Oakley","Theodore Ts'o"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"378424","messageId":"DM5PR00MB040845755401A07E5C90251CF1F90@DM5PR00MB0408.namprd00.prod.outlook.com","threadId":"51414","inReplyTo":null,"subject":"Tracking parent branches in Git","fromName":"Eric Kulcyk","fromEmail":"eric.kulcyk@microsoft.com","sentAt":"2019-07-01T18:50:43Z","receivedAt":"2019-07-01T18:50:48Z","isPatch":false,"sender":{"key":"eric.kulcyk@microsoft.com","avatar":null},"body":"Hello,\n\nWe would like to track parent branches so that creating pull requests can automatically determine the correct branch to merge against. I understand that this would require tracking more information than is currently available right now in git. Also, it seems that if some cases, it is not possible to determine a parent branch, in which case it would just be empty/null. If I made a change to track the parent branch for each branch, would this feature be accepted/welcomed as part of git, even if it off by default?\n\nThanks,\nEric\n\n:(){:|:&};:"},{"id":"378428","messageId":"xmqqpnmt5z19.fsf@gitster-ct.c.googlers.com","threadId":"51414","inReplyTo":"DM5PR00MB040845755401A07E5C90251CF1F90@DM5PR00MB0408.namprd00.prod.outlook.com","subject":"Re: Tracking parent branches in Git","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2019-07-01T19:34:58Z","receivedAt":"2019-07-01T19:35:03Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Eric Kulcyk writes:\n\n[Overly long lines are not appreciated around here.]\n\n> We would like to track parent branches so that creating pull\n> requests can automatically determine the correct branch to merge\n> against. I understand that this would require tracking more\n> information than is currently available right now in git. Also,\n> it seems that if some cases, it is not possible to determine a\n> parent branch, in which case it would just be empty/null.\n\nDo you mean by \"parent branch\" what people usually call \"upstream\nbranch\" (i.e. when that branch on the other side gains more commits\nindependent from what you have been working on, then you would want\nto rebase your work on top of the updated state of that branch on\nthe other side) around here? Perhaps \"git help glossary\", look\nfor \"upstream branch\" and start from there? The entry mentions the\nconfiguration variables used to keep track of that information,\nwhich are described in \"git help config\", I think.\n\n> If I made a change to track the parent branch for each branch,\n> would this feature be accepted/welcomed as part of git, even if it\n> off by default?\n\nRegardless of what is being proposed, this is often not a very\nuseful question. Something worth doing for yourself is worth doing\nwhether others also find it useful ;-) And others usually do not\nhave enough information to judge if such a change is welcome until\nseeing it in a bit more concrete form.\n\nThanks.\n\n"},{"id":"378429","messageId":"CAGyf7-EBs_cRB5R7RyQhX0ZDNqLZWVJEYEtqkGRGJykRqKKTvA@mail.gmail.com","threadId":"51414","inReplyTo":"xmqqpnmt5z19.fsf@gitster-ct.c.googlers.com","subject":"Re: Tracking parent branches in Git","fromName":"Bryan Turner","fromEmail":"bturner@atlassian.com","sentAt":"2019-07-01T19:48:16Z","receivedAt":"2019-07-01T19:48:29Z","isPatch":false,"sender":{"key":"bturner@atlassian.com","avatar":"https://gravatar.com/avatar/16bcf3167981c1ef7c804e502642366d888a35b0d0b0a4ca01fdc442aa1acb1e?d=mp&s=160"},"body":"On Mon, Jul 1, 2019 at 12:35 PM Junio C Hamano wrote:\n>\n> Eric Kulcyk writes:\n>\n> [Overly long lines are not appreciated around here.]\n>\n> > We would like to track parent branches so that creating pull\n> > requests can automatically determine the correct branch to merge\n> > against. I understand that this would require tracking more\n> > information than is currently available right now in git. Also,\n> > it seems that if some cases, it is not possible to determine a\n> > parent branch, in which case it would just be empty/null.\n>\n> Do you mean by \"parent branch\" what people usually call \"upstream\n> branch\" (i.e. when that branch on the other side gains more commits\n> independent from what you have been working on, then you would want\n> to rebase your work on top of the updated state of that branch on\n> the other side) around here?\n\nI suspect the question is in regards to \"What branch did I create my\nlocal branch from?\", especially given the pull request reference.\n\nIn other words, when I locally do:\ngit checkout --no-track -b bturner-some-bugfix origin/release/5.16\n\nrelease/5.16 is the \"parent branch\" of my bugfix branch and, when I\npush my branch and try to open a pull request, release/5.16 is a\n_likely_ target for where I'd want to merge it. There may be a remote\nin the name, a la \"origin\" in my example, or it might be created on\ntop of some other local branch. It's a common feature request for\nBitbucket Server[1], for example, to automatically select the \"right\"\ntarget branch for a new pull request based on the ancestry of the\nbranch in question--except branches have no ancestry. (This sort of\nmetadata could potentially offer some benefits for building commit\ngraphs (referring to UI treatments for visualizing the DAG, rather\nthan Git's \"commit-graph\" functionality), depending on how it was\nimplemented, since it would make branch points more stable.)\n\nSince branches are ephemeral names and have no intrinsic metadata of\ntheir own (unlike, say, annotated tags or commits), I suspect\nimplementing something like this may be more complicated than it might\ninitially appear, especially if said metadata needs to be communicated\nto remote repositories (which implies it might require changes to the\nwire protocol as well).\n\nBest regards,\nBryan Turner\n\n[1] https://jira.atlassian.com/browse/BSERV-7116\n\n>\n> Perhaps \"git help glossary\", look\n> for \"upstream branch\" and start from there? The entry mentions the\n> configuration variables used to keep track of that information,\n> which are described in \"git help config\", I think.\n>\n> > If I made a change to track the parent branch for each branch,\n> > would this feature be accepted/welcomed as part of git, even if it\n> > off by default?\n>\n> Regardless of what is being proposed, this is often not a very\n> useful question. Something worth doing for yourself is worth doing\n> whether others also find it useful ;-) And others usually do not\n> have enough information to judge if such a change is welcome until\n> seeing it in a bit more concrete form.\n>\n> Thanks.\n>\n"},{"id":"378430","messageId":"007d01d53049$4db5bec0$e9213c40$@nexbridge.com","threadId":"51414","inReplyTo":"CAGyf7-EBs_cRB5R7RyQhX0ZDNqLZWVJEYEtqkGRGJykRqKKTvA@mail.gmail.com","subject":"RE: Tracking parent branches in Git","fromName":"","fromEmail":"rsbecker@nexbridge.com","sentAt":"2019-07-01T20:12:06Z","receivedAt":"2019-07-01T20:12:38Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On July 1, 2019 3:48 PM, Bryan Turner wrote:\nOn Mon, Jul 1, 2019 at 12:35 PM Junio C Hamano wrote:\n>\n> Eric Kulcyk writes:\n>\n> [Overly long lines are not appreciated around here.]\n>\n> > We would like to track parent branches so that creating pull \n> > requests can automatically determine the correct branch to merge \n> > against. I understand that this would require tracking more \n> > information than is currently available right now in git. Also, it \n> > seems that if some cases, it is not possible to determine a parent \n> > branch, in which case it would just be empty/null.\n>\n> Do you mean by \"parent branch\" what people usually call \"upstream \n> branch\" (i.e. when that branch on the other side gains more commits \n> independent from what you have been working on, then you would want to \n> rebase your work on top of the updated state of that branch on the \n> other side) around here?\n\nI suspect the question is in regards to \"What branch did I create my local branch from?\", especially given the pull request reference.\n\nIn other words, when I locally do:\ngit checkout --no-track -b bturner-some-bugfix origin/release/5.16\n\nrelease/5.16 is the \"parent branch\" of my bugfix branch and, when I push my branch and try to open a pull request, release/5.16 is a _likely_ target for where I'd want to merge it. There may be a remote in the name, a la \"origin\" in my example, or it might be created on top of some other local branch. It's a common feature request for Bitbucket Server[1], for example, to automatically select the \"right\"\ntarget branch for a new pull request based on the ancestry of the branch in question--except branches have no ancestry. (This sort of metadata could potentially offer some benefits for building commit graphs (referring to UI treatments for visualizing the DAG, rather than Git's \"commit-graph\" functionality), depending on how it was implemented, since it would make branch points more stable.)\n\nSince branches are ephemeral names and have no intrinsic metadata of their own (unlike, say, annotated tags or commits), I suspect implementing something like this may be more complicated than it might initially appear, especially if said metadata needs to be communicated to remote repositories (which implies it might require changes to the wire protocol as well).\n\nBest regards,\nBryan Turner\n\n[1] https://jira.atlassian.com/browse/BSERV-7116\n\n>\n> Perhaps \"git help glossary\", look\n> for \"upstream branch\" and start from there? The entry mentions the \n> configuration variables used to keep track of that information, which \n> are described in \"git help config\", I think.\n>\n> > If I made a change to track the parent branch for each branch, would \n> > this feature be accepted/welcomed as part of git, even if it off by \n> > default?\n>\n> Regardless of what is being proposed, this is often not a very useful \n> question. Something worth doing for yourself is worth doing whether \n> others also find it useful ;-) And others usually do not have enough \n> information to judge if such a change is welcome until seeing it in a \n> bit more concrete form.\n\nWas there not, at some point in recent history (2019), a discussion about storing extra arbitrary data associated with a branch or other objects? My thought for satisfying what Eric was originally proposing is to store the root commit associated with the original branch HEAD when checkout -b/branch was done to create the branch. Presumably another datum could store the branch that the branch HEAD was on, but that may not be unique - which is a root part of the problem with this request, although it might be something that the user could select/specify - not sure how - at branch creation. \n\nBut aside from that both of the above are transient relative to the new branch and by the time you wanted to create a Pull Request, the information you originally wanted could irrelevant - at least to git. If I was the product manager on this, I would suggest going to GitLab, GitHub, or BitBucket and asking for some augmented capability of branch creation, that stores the data for future Pull Request management - instead of doing this in core git because of the transient nature of the relationship between a branch and a commit.\n\nMy $0.02.\nRandall\n\n"},{"id":"378446","messageId":"20190701204017.GA7537@esm","threadId":"51414","inReplyTo":"CAGyf7-EBs_cRB5R7RyQhX0ZDNqLZWVJEYEtqkGRGJykRqKKTvA@mail.gmail.com","subject":"Re: Tracking parent branches in Git","fromName":"Eckhard Maaß","fromEmail":"eckhard.s.maass@googlemail.com","sentAt":"2019-07-01T20:40:17Z","receivedAt":"2019-07-01T20:40:22Z","isPatch":false,"sender":{"key":"eckhard.s.maass@googlemail.com","avatar":"https://avatars.githubusercontent.com/u/21984134?v=4"},"body":"On Mon, Jul 01, 2019 at 12:48:16PM -0700, Bryan Turner wrote:\n> Since branches are ephemeral names and have no intrinsic metadata of\n> their own (unlike, say, annotated tags or commits), I suspect\n> implementing something like this may be more complicated than it might\n> initially appear, especially if said metadata needs to be communicated\n> to remote repositories (which implies it might require changes to the\n> wire protocol as well).\n\nYou can right now give meta data of your choice with --push-option to\nthe push command. The Gerrit system makes use of that already. However,\nthis would not be intrinsic to Git, but the serve needs to react on\nthose options. And it should be in good company with suitable client\ntools.\n\nTake care,\nEckhard\n"},{"id":"378448","messageId":"DM5PR00MB040870EB598E4E7B0CC1765DF1F90@DM5PR00MB0408.namprd00.prod.outlook.com","threadId":"51414","inReplyTo":"20190701204017.GA7537@esm","subject":"Re: Tracking parent branches in Git","fromName":"Eric Kulcyk","fromEmail":"eric.kulcyk@microsoft.com","sentAt":"2019-07-01T20:58:02Z","receivedAt":"2019-07-01T20:58:07Z","isPatch":false,"sender":{"key":"eric.kulcyk@microsoft.com","avatar":null},"body":"> > [Overly long lines are not appreciated around here.]\n\nThanks for the feedback, is there an email client or tool\nthat can format the lines correctly?\n> >\n> > > We would like to track parent branches so that creating pull\n> > > requests can automatically determine the correct branch to merge\n> > > against. I understand that this would require tracking more\n> > > information than is currently available right now in git. Also, it\n> > > seems that if some cases, it is not possible to determine a parent\n> > > branch, in which case it would just be empty/null.\n> >\n> > Do you mean by \"parent branch\" what people usually call \"upstream\n> > branch\" (i.e. when that branch on the other side gains more commits\n> > independent from what you have been working on, then you would want to\n> > rebase your work on top of the updated state of that branch on the\n> > other side) around here?\n>\n> I suspect the question is in regards to \"What branch did I create my local branch from?\", especially given the pull request reference.\n\nYes, this is what I meant.\n>\n> In other words, when I locally do:\n> git checkout --no-track -b bturner-some-bugfix origin/release/5.16\n>\n> release/5.16 is the \"parent branch\" of my bugfix branch and, when I push my branch and try to open a pull request, release/5.16 is a _likely_ target for where I'd want to merge it. There may be a remote in the name, a la \"origin\" in my example, or it might be created on top of some other local branch. It's a common feature request for Bitbucket Server[1], for example, to automatically select the \"right\"\n> target branch for a new pull request based on the ancestry of the branch in question--except branches have no ancestry. (This sort of metadata could potentially offer some benefits for building commit graphs (referring to UI treatments for visualizing the DAG, rather than Git's \"commit-graph\" functionality), depending on how it was implemented, since it would make branch points more stable.)\n>\n> > Since branches are ephemeral names and have no intrinsic metadata of\n> > their own (unlike, say, annotated tags or commits), I suspect\n> > implementing something like this may be more complicated than it might\n> > initially appear, especially if said metadata needs to be communicated\n> > to remote repositories (which implies it might require changes to the\n> > wire protocol as well).\n>\n> You can right now give meta data of your choice with --push-option to\n> the push command. The Gerrit system makes use of that already. However,\n> this would not be intrinsic to Git, but the serve needs to react on\n> those options. And it should be in good company with suitable client\n> tools.\n\n@Eckhard, is that documented somewhere? I don't see it on\nhttps://git-scm.com/docs/git-push/1.6.4.1\n\n>\n> Take care,\n> Eckhard\n>\n> Best regards,\n> Bryan Turner\n>\n> [1] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjira.atlassian.com%2Fbrowse%2FBSERV-7116&data=02%7C01%7CEric.kulcyk%40microsoft.com%7Ca780a740f5894ba5ce6508d6fe607317%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636976088301830933&sdata=1KrFM%2BLcKoa3FCc1F86jIVZBrIUGi%2B6ad7CuA8ekAUY%3D&reserved=0\n>\n> >\n> > Perhaps \"git help glossary\", look\n> > for \"upstream branch\" and start from there? The entry mentions the\n> > configuration variables used to keep track of that information, which\n> > are described in \"git help config\", I think.\n> >\n> > > If I made a change to track the parent branch for each branch, would\n> > > this feature be accepted/welcomed as part of git, even if it off by\n> > > default?\n> >\n> > Regardless of what is being proposed, this is often not a very useful\n> > question. Something worth doing for yourself is worth doing whether\n> > others also find it useful ;-) And others usually do not have enough\n> > information to judge if such a change is welcome until seeing it in a\n> > bit more concrete form.\n\nI wanted to get a some thoughts before I worked out the details.\nThe feature is of little use if no one is using the version of git with it\nsince most everyone uses standard distros of git.\n>\n> Was there not, at some point in recent history (2019), a discussion about storing extra arbitrary data associated with a branch or other objects? My thought for satisfying what Eric was originally proposing is to store the root commit associated with the original branch HEAD when checkout -b/branch was done to create the branch. Presumably another datum could store the branch that the branch HEAD was on, but that may not be unique - which is a root part of the problem with this request, although it might be something that the user could select/specify - not sure how - at branch creation.\n>\n> But aside from that both of the above are transient relative to the new branch and by the time you wanted to create a Pull Request, the information you originally wanted could irrelevant - at least to git. If I was the product manager on this, I would suggest going to GitLab, GitHub, or BitBucket and asking for some augmented capability of branch creation, that stores the data for future Pull Request management - instead of doing this in core git because of the transient nature of the relationship between a branch and a commit.\n\nMultiple branches can have the same commit, but only one branch can\nbe checked out at once, right? Then the parent branch would be the\nbranch you were on when you ran checkout -b. That branch might change\nand no longer be of use, but it seems like in practice that is not the case.\nNew features are usually created off of a local branch and then PR'd\nback to the upstream version of that branch.\n\nThanks!\nEric\n\n________________________________________\nFrom: Eckhard Maaß \nSent: Monday, July 1, 2019 1:40 PM\nTo: Bryan Turner\nCc: gitster@pobox.com; Eric Kulcyk; git@vger.kernel.org\nSubject: Re: Tracking parent branches in Git\n\nOn Mon, Jul 01, 2019 at 12:48:16PM -0700, Bryan Turner wrote:\n> Since branches are ephemeral names and have no intrinsic metadata of\n> their own (unlike, say, annotated tags or commits), I suspect\n> implementing something like this may be more complicated than it might\n> initially appear, especially if said metadata needs to be communicated\n> to remote repositories (which implies it might require changes to the\n> wire protocol as well).\n\nYou can right now give meta data of your choice with --push-option to\nthe push command. The Gerrit system makes use of that already. However,\nthis would not be intrinsic to Git, but the serve needs to react on\nthose options. And it should be in good company with suitable client\ntools.\n\nTake care,\nEckhard\n"},{"id":"378450","messageId":"DM5PR00MB04088CD7E4C7E2B4BC1E7140F1F90@DM5PR00MB0408.namprd00.prod.outlook.com","threadId":"51414","inReplyTo":"DM5PR00MB040870EB598E4E7B0CC1765DF1F90@DM5PR00MB0408.namprd00.prod.outlook.com","subject":"Re: Tracking parent branches in Git","fromName":"Eric Kulcyk","fromEmail":"eric.kulcyk@microsoft.com","sentAt":"2019-07-01T21:04:23Z","receivedAt":"2019-07-01T21:04:29Z","isPatch":false,"sender":{"key":"eric.kulcyk@microsoft.com","avatar":null},"body":"\n> > You can right now give meta data of your choice with --push-option to\n> > the push command. The Gerrit system makes use of that already. However,\n> > this would not be intrinsic to Git, but the serve needs to react on\n> > those options. And it should be in good company with suitable client\n> > tools.\n\n> @Eckhard, is that documented somewhere? I don't see it on \n> https://git-scm.com/docs/git-push/1.6.4.1\n\nInterestingly a Google search for git --push-option turns up old documentation first,\nI found the newer docs. Don't you still need a way to store this data locally?\nFor instance, a wrapper around git checkout could record the branch.\nHowever, you would be unable to use vanilla git check out if you want to do rely upon the data.\n\n\n\n\n\n\n\n\n\n\nFrom: Eric Kulcyk\n\nSent: Monday, July 1, 2019 1:58 PM\n\nTo: Eckhard Maaß; Bryan Turner\n\nCc: gitster@pobox.com; git@vger.kernel.org\n\nSubject: Re: Tracking parent branches in Git\n\n \n\n\n> > [Overly long lines are not appreciated around here.]\n\n\n\nThanks for the feedback, is there an email client or tool\n\nthat can format the lines correctly?\n\n> >\n\n> > > We would like to track parent branches so that creating pull\n\n> > > requests can automatically determine the correct branch to merge\n\n> > > against.  I understand that this would require tracking more\n\n> > > information than is currently available right now in git.  Also, it\n\n> > > seems that if some cases, it is not possible to determine a parent\n\n> > > branch, in which case it would just be empty/null.\n\n> >\n\n> > Do you mean by \"parent branch\" what people usually call \"upstream\n\n> > branch\" (i.e. when that branch on the other side gains more commits\n\n> > independent from what you have been working on, then you would want to\n\n> > rebase your work on top of the updated state of that branch on the\n\n> > other side) around here?\n\n>\n\n> I suspect the question is in regards to \"What branch did I create my local branch from?\", especially given the pull request reference.\n\n\n\nYes, this is what I meant.\n\n>\n\n> In other words, when I locally do:\n\n> git checkout --no-track -b bturner-some-bugfix origin/release/5.16\n\n>\n\n> release/5.16 is the \"parent branch\" of my bugfix branch and, when I push my branch and try to open a pull request, release/5.16 is a _likely_ target for where I'd want to merge it. There may be a remote in the name, a la \"origin\" in my example, or it might\n be created on top of some other local branch. It's a common feature request for Bitbucket Server[1], for example, to automatically select the \"right\"\n\n> target branch for a new pull request based on the ancestry of the branch in question--except branches have no ancestry. (This sort of metadata could potentially offer some benefits for building commit graphs (referring to UI treatments for visualizing the\n DAG, rather than Git's \"commit-graph\" functionality), depending on how it was implemented, since it would make branch points more stable.)\n\n>\n\n> > Since branches are ephemeral names and have no intrinsic metadata of\n\n> > their own (unlike, say, annotated tags or commits), I suspect\n\n> > implementing something like this may be more complicated than it might\n\n> > initially appear, especially if said metadata needs to be communicated\n\n> > to remote repositories (which implies it might require changes to the\n\n> > wire protocol as well).\n\n>\n\n> You can right now give meta data of your choice with --push-option to\n\n> the push command. The Gerrit system makes use of that already. However,\n\n> this would not be intrinsic to Git, but the serve needs to react on\n\n> those options. And it should be in good company with suitable client\n\n> tools.\n\n\n\n@Eckhard, is that documented somewhere?  I don't see it on\n\nhttps://git-scm.com/docs/git-push/1.6.4.1\n\n\n\n>\n\n> Take care,\n\n> Eckhard\n\n>\n\n> Best regards,\n\n> Bryan Turner\n\n>\n\n> [1] \nhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjira.atlassian.com%2Fbrowse%2FBSERV-7116&data=02%7C01%7CEric.kulcyk%40microsoft.com%7Ca780a740f5894ba5ce6508d6fe607317%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636976088301830933&sdata=1KrFM%2BLcKoa3FCc1F86jIVZBrIUGi%2B6ad7CuA8ekAUY%3D&reserved=0\n\n>\n\n> >\n\n> > Perhaps \"git help glossary\", look\n\n> > for \"upstream branch\" and start from there?  The entry mentions the\n\n> > configuration variables used to keep track of that information, which\n\n> > are described in \"git help config\", I think.\n\n> >\n\n> > > If I made a change to track the parent branch for each branch, would\n\n> > > this feature be accepted/welcomed as part of git, even if it off by\n\n> > > default?\n\n> >\n\n> > Regardless of what is being proposed, this is often not a very useful\n\n> > question.  Something worth doing for yourself is worth doing whether\n\n> > others also find it useful ;-)  And others usually do not have enough\n\n> > information to judge if such a change is welcome until seeing it in a\n\n> > bit more concrete form.\n\n\n\nI wanted to get a some thoughts before I worked out the details.\n\nThe feature is of little use if no one is using the version of git with it\n\nsince most everyone uses standard distros of git.\n\n>\n\n> Was there not, at some point in recent history (2019), a discussion about storing extra arbitrary data associated with a branch or other objects? My thought for satisfying what Eric was originally proposing is to store the root commit associated with the\n original branch HEAD when checkout -b/branch was done to create the branch. Presumably another datum could store the branch that the branch HEAD was on, but that may not be unique - which is a root part of the problem with this request, although it might be\n something that the user could select/specify - not sure how - at branch creation.\n\n>\n\n> But aside from that both of the above are transient relative to the new branch and by the time you wanted to create a Pull Request, the information you originally wanted could irrelevant - at least to git. If I was the product manager on this, I would suggest\n going to GitLab, GitHub, or BitBucket and asking for some augmented capability of branch creation, that stores the data for future Pull Request management - instead of doing this in core git because of the transient nature of the relationship between a branch\n and a commit.\n\n\n\nMultiple branches can have the same commit, but only one branch can\n\nbe checked out at once, right?  Then the parent branch would be the\n\nbranch you were on when you ran checkout -b.  That branch might change\n\nand no longer be of use, but it seems like in practice that is not the case.\n\nNew features are usually created off of a local branch and then PR'd\n\nback to the upstream version of that branch.\n\n\n\nThanks!\n\nEric\n\n\n\n________________________________________\n\nFrom: Eckhard Maaß \n\nSent: Monday, July 1, 2019 1:40 PM\n\nTo: Bryan Turner\n\nCc: gitster@pobox.com; Eric Kulcyk; git@vger.kernel.org\n\nSubject: Re: Tracking parent branches in Git\n\n\n\nOn Mon, Jul 01, 2019 at 12:48:16PM -0700, Bryan Turner wrote:\n\n> Since branches are ephemeral names and have no intrinsic metadata of\n\n> their own (unlike, say, annotated tags or commits), I suspect\n\n> implementing something like this may be more complicated than it might\n\n> initially appear, especially if said metadata needs to be communicated\n\n> to remote repositories (which implies it might require changes to the\n\n> wire protocol as well).\n\n\n\nYou can right now give meta data of your choice with --push-option to\n\nthe push command. The Gerrit system makes use of that already. However,\n\nthis would not be intrinsic to Git, but the serve needs to react on\n\nthose options. And it should be in good company with suitable client\n\ntools.\n\n\n\nTake care,\n\nEckhard\n\n"},{"id":"378474","messageId":"20190702064252.GA26953@inner.h.apk.li","threadId":"51414","inReplyTo":"CAGyf7-EBs_cRB5R7RyQhX0ZDNqLZWVJEYEtqkGRGJykRqKKTvA@mail.gmail.com","subject":"Re: Tracking parent branches in Git","fromName":"Andreas Krey","fromEmail":"a.krey@gmx.de","sentAt":"2019-07-02T06:42:52Z","receivedAt":"2019-07-02T06:48:57Z","isPatch":false,"sender":{"key":"a.krey@gmx.de","avatar":"https://avatars.githubusercontent.com/u/37810?v=4"},"body":"On Mon, 01 Jul 2019 12:48:16 +0000, Bryan Turner wrote:\n...\n> In other words, when I locally do:\n> git checkout --no-track -b bturner-some-bugfix origin/release/5.16\n> \n> release/5.16 is the \"parent branch\" of my bugfix branch and, when I\n> push my branch and try to open a pull request, release/5.16 is a\n> _likely_ target for where I'd want to merge it.\n\nWe have simply conventionalized this - the parent relation is in\nthe branch names. Your bugfix branch would be release/5.16/bturner-some-bugfix\n(in the central repo; we don't care how you name it locally), and, because\nref storage, the parent would be release/5.16/master.\n\nYou'd just do\n\n git create-br release/5.16/bturner-some-bugfix\n\nand it would be branched off the corresponding /master, be checked\nout, and tracking already been set up. Likewise we have a\n\n git update\n\nwhich looks at the upstream name, deduces the parent, and pulls\nthat in, with a suitable commit message. Finally,\n\n git mkpullreq\n\ncreates a pull request from the current to the parent branch.\n\n(I would like to have a way to make bitbucket server use the same\nconvention for the default pull request target.)\n\n- Andreas\n\n-- \n\"Totally trivial. Famous last words.\"\nFrom: Linus Torvalds \nDate: Fri, 22 Jan 2010 07:29:21 -0800\n"},{"id":"378484","messageId":"77a2b000-f1dc-6f3e-54db-abd227ce6163@iee.org","threadId":"51414","inReplyTo":"007d01d53049$4db5bec0$e9213c40$@nexbridge.com","subject":"Re: Tracking parent branches in Git","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2019-07-02T09:23:50Z","receivedAt":"2019-07-02T09:23:55Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"On 01/07/2019 21:12, rsbecker@nexbridge.com wrote:\n> On July 1, 2019 3:48 PM, Bryan Turner wrote:\n> On Mon, Jul 1, 2019 at 12:35 PM Junio C Hamano wrote:\n>> Eric Kulcyk writes:\n>>\n>> [Overly long lines are not appreciated around here.]\n>>\n>>> We would like to track parent branches so that creating pull\n>>> requests can automatically determine the correct branch to merge\n>>> against. I understand that this would require tracking more\n>>> information than is currently available right now in git. Also, it\n>>> seems that if some cases, it is not possible to determine a parent\n>>> branch, in which case it would just be empty/null.\n>> Do you mean by \"parent branch\" what people usually call \"upstream\n>> branch\" (i.e. when that branch on the other side gains more commits\n>> independent from what you have been working on, then you would want to\n>> rebase your work on top of the updated state of that branch on the\n>> other side) around here?\n> I suspect the question is in regards to \"What branch did I create my local branch from?\", especially given the pull request reference.\n>\n> In other words, when I locally do:\n> git checkout --no-track -b bturner-some-bugfix origin/release/5.16\n>\n> release/5.16 is the \"parent branch\" of my bugfix branch and, when I push my branch and try to open a pull request, release/5.16 is a _likely_ target for where I'd want to merge it. There may be a remote in the name, a la \"origin\" in my example, or it might be created on top of some other local branch. It's a common feature request for Bitbucket Server[1], for example, to automatically select the \"right\"\n> target branch for a new pull request based on the ancestry of the branch in question--except branches have no ancestry. (This sort of metadata could potentially offer some benefits for building commit graphs (referring to UI treatments for visualizing the DAG, rather than Git's \"commit-graph\" functionality), depending on how it was implemented, since it would make branch points more stable.)\n>\n> Since branches are ephemeral names and have no intrinsic metadata of their own (unlike, say, annotated tags or commits), I suspect implementing something like this may be more complicated than it might initially appear, especially if said metadata needs to be communicated to remote repositories (which implies it might require changes to the wire protocol as well).\n>\n> Best regards,\n> Bryan Turner\n>\n> [1] https://jira.atlassian.com/browse/BSERV-7116\n>\n>> Perhaps \"git help glossary\", look\n>> for \"upstream branch\" and start from there? The entry mentions the\n>> configuration variables used to keep track of that information, which\n>> are described in \"git help config\", I think.\n>>\n>>> If I made a change to track the parent branch for each branch, would\n>>> this feature be accepted/welcomed as part of git, even if it off by\n>>> default?\n>> Regardless of what is being proposed, this is often not a very useful\n>> question. Something worth doing for yourself is worth doing whether\n>> others also find it useful ;-) And others usually do not have enough\n>> information to judge if such a change is welcome until seeing it in a\n>> bit more concrete form.\n> Was there not, at some point in recent history (2019), a discussion about storing extra arbitrary data associated with a branch or other objects? My thought for satisfying what Eric was originally proposing is to store the root commit associated with the original branch HEAD when checkout -b/branch was done to create the branch. Presumably another datum could store the branch that the branch HEAD was on, but that may not be unique - which is a root part of the problem with this request, although it might be something that the user could select/specify - not sure how - at branch creation.\n>\n> But aside from that both of the above are transient relative to the new branch and by the time you wanted to create a Pull Request, the information you originally wanted could irrelevant - at least to git. If I was the product manager on this, I would suggest going to GitLab, GitHub, or BitBucket and asking for some augmented capability of branch creation, that stores the data for future Pull Request management - instead of doing this in core git because of the transient nature of the relationship between a branch and a commit.\n>\n> My $0.02.\n> Randall\n>\n From the Git side, maybe one could simply populate the branch \ndescription with the commit oid and branched-from name at the time of \nbranch creation (no doubt set as a core.option).\nThe field is already there and almost never used - there's no easy way \n(via git command) to populate the description anyway. Plus its a local \nfield, keeping Git distributed.\n--\nPhilip\n"},{"id":"378506","messageId":"xmqqef3849v6.fsf@gitster-ct.c.googlers.com","threadId":"51414","inReplyTo":"77a2b000-f1dc-6f3e-54db-abd227ce6163@iee.org","subject":"Re: Tracking parent branches in Git","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2019-07-02T17:36:13Z","receivedAt":"2019-07-02T17:36:22Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Philip Oakley writes:\n\n>> I suspect the question is in regards to \"What branch did I create\n>> my local branch from?\", especially given the pull request\n>> reference.\n>>\n>> In other words, when I locally do:\n>> git checkout --no-track -b bturner-some-bugfix origin/release/5.16\n>>\n>> release/5.16 is the \"parent branch\" of my bugfix branch...\n>> ...\n> From the Git side, maybe one could simply populate the branch\n> description with the commit oid and branched-from name at the time of\n> branch creation (no doubt set as a core.option).\n> The field is already there and almost never used - there's no easy way\n> (via git command) to populate the description anyway. Plus its a local\n> field, keeping Git distributed.\n\nI do not think you want branch.description to get mixed-up in this.\n\nIn this whole thread, I have been wondering if I am missing\nsomething crucial, but now I am deeply puzzled why after many people\nmade comments, nobody raises a question about the \"--no-track\" thing\nin the early message in the thread.\n\nIf you do not add that, i.e.\n\n\t$ git checout -t -b bturner-some-bugfix origin/release/5.16\n \n(note that I added '-t' for illustration, but it should be on by\ndefault when starting from origin/), then you'd get in\nyour configuration file these recorded:\n\n\t$ git config --get-regexp 'branch\\.bturner-some-bugfix\\..*'\n\tbranch.bturner-some-bugfix.remote origin\n\tbranch.bturner-some-bugfix.merge refs/heads/release/5.16\n\nYou created 'bturner-some-bugfix' branch out of the 'release/5.16'\nbranch taken from the remote whose name is 'origin'. \n\nIs that different from the answer to the question being sought?\nWhat am I missing???\n\n"},{"id":"378510","messageId":"CAGyf7-GhD50Dy0O7JjV4vTyQfFcifyKzeYDS_HtAXy604HxqVQ@mail.gmail.com","threadId":"51414","inReplyTo":"xmqqef3849v6.fsf@gitster-ct.c.googlers.com","subject":"Re: Tracking parent branches in Git","fromName":"Bryan Turner","fromEmail":"bturner@atlassian.com","sentAt":"2019-07-02T18:52:35Z","receivedAt":"2019-07-02T18:52:48Z","isPatch":false,"sender":{"key":"bturner@atlassian.com","avatar":"https://gravatar.com/avatar/16bcf3167981c1ef7c804e502642366d888a35b0d0b0a4ca01fdc442aa1acb1e?d=mp&s=160"},"body":"On Tue, Jul 2, 2019 at 10:36 AM Junio C Hamano wrote:\n>\n> In this whole thread, I have been wondering if I am missing\n> something crucial, but now I am deeply puzzled why after many people\n> made comments, nobody raises a question about the \"--no-track\" thing\n> in the early message in the thread.\n>\n> If you do not add that, i.e.\n>\n> $ git checout -t -b bturner-some-bugfix origin/release/5.16\n>\n> (note that I added '-t' for illustration, but it should be on by\n> default when starting from origin/), then you'd get in\n> your configuration file these recorded:\n>\n> $ git config --get-regexp 'branch\\.bturner-some-bugfix\\..*'\n> branch.bturner-some-bugfix.remote origin\n> branch.bturner-some-bugfix.merge refs/heads/release/5.16\n>\n> You created 'bturner-some-bugfix' branch out of the 'release/5.16'\n> branch taken from the remote whose name is 'origin'.\n>\n> Is that different from the answer to the question being sought?\n> What am I missing???\n\nSorry, I should have clarified my \"--no-track\" in my original message\nwhen I provided the example. I did \"--no-track\" because if I push\n\"bturner-some-bugfix\" to a server, I'm likely going to do something\nlike \"git push -u origin bturner-some-bugfix\" so that my local\n\"bturner-some-bugfix\" branch will track the remote version of itself.\nAt that point, the remote-tracking information would change from\n\"release/5.16\" to \"bturner-some-bugfix\" (without any sort of warning,\nfor whatever that's worth), effectively \"losing\" the ancestry.\n\nThe other issue is that my local remote-tracking information doesn't\nhelp the server I'm talking to; it's not shareable. Assuming I could\nuse remote-tracking to track ancestry, there's still no way to\ncommunicate that to the server so that it could know, when I go to\ncreate a pull request for \"bturner-some-bugfix\", that it's tracking\n\"release/5.16\" in my local repository.\n\nI could certainly be misunderstanding the request, but I think it's\nasking for something less ephemeral--and more shareable--than\nremote-tracking, and it seems logical to want to be able to retain\nancestry while still using remote-tracking setup such that local\nbranches still track the remote version of themselves, rather than\nsome other (albeit related) branch.\n\nBest regards,\nBryan Turner\n"},{"id":"378515","messageId":"20190702192412.GE3032@mit.edu","threadId":"51414","inReplyTo":"CAGyf7-GhD50Dy0O7JjV4vTyQfFcifyKzeYDS_HtAXy604HxqVQ@mail.gmail.com","subject":"Re: Tracking parent branches in Git","fromName":"Theodore Ts'o","fromEmail":"tytso@mit.edu","sentAt":"2019-07-02T19:24:12Z","receivedAt":"2019-07-02T19:24:34Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Tue, Jul 02, 2019 at 11:52:35AM -0700, Bryan Turner wrote:\n> Sorry, I should have clarified my \"--no-track\" in my original message\n> when I provided the example. I did \"--no-track\" because if I push\n> \"bturner-some-bugfix\" to a server, I'm likely going to do something\n> like \"git push -u origin bturner-some-bugfix\" so that my local\n> \"bturner-some-bugfix\" branch will track the remote version of itself.\n> At that point, the remote-tracking information would change from\n> \"release/5.16\" to \"bturner-some-bugfix\" (without any sort of warning,\n> for whatever that's worth), effectively \"losing\" the ancestry.\n> \n> The other issue is that my local remote-tracking information doesn't\n> help the server I'm talking to; it's not shareable. Assuming I could\n> use remote-tracking to track ancestry, there's still no way to\n> communicate that to the server so that it could know, when I go to\n> create a pull request for \"bturner-some-bugfix\", that it's tracking\n> \"release/5.16\" in my local repository.\n\nI think the real problem with all of this feature request is that it's\nall presuming a particular workflow, and git is currently *not*\nstrongly opinionated about the workflow.\n\nSo for example, if I create a local branch against origin/release/5.16\nwith a series of fixes, and I'm pushing to a gerrit server for review,\nI might need to do something like this:\n\n git push gerrit HEAD:refs/for/release/5.16%r=reviewer@example.com,%cc=kernel-reviewers@example.com\n\nSo the fact that we've recorded the information about the parent\nbranch when doing a \"git checkout -b bugfix origin/release/5.16\" is\npart of the puzzle, but the other part of the puzzle is knowing what\nthe destination server is going to want or need. Internally at $WORK\nwe have our own internal script that does this automatically, so I\njust have to run something like \"kdt mail -r reviewer@example.com\",\nbut it's always going to be very workflow-independent.\n\n> I could certainly be misunderstanding the request, but I think it's\n> asking for something less ephemeral--and more shareable--than\n> remote-tracking, and it seems logical to want to be able to retain\n> ancestry while still using remote-tracking setup such that local\n> branches still track the remote version of themselves, rather than\n> some other (albeit related) branch.\n\nIn order for it to be shareable, we have to make some very strong\nassumptions about workflow. It gets worse when people pull from more\nthan one tree, or there is a series of subtrees.\n\nFor example, suppose the 2nd-level lieutenant has a \"net\" tree, and\nthe 3rd-level lieutenants have a \"sctp\" and a \"ipsec\" tree. Now let's\nassume that there is some common infrastructure branch that both\n3rd-level lieutenants need to build off of that comes from some other\n2nd-level tree, and so for that development cycle, they first pull\nfrom the top-level tree, and then both 3rd level trees merge in a\nbranch from the \"mm\" tree, but then they will be both be sending pull\nrequest emails to the \"net\" tree.\n\nThere will be a whole series of git pulls and git merges that will be\nin flight, and just for yucks, let's suppose some trees are do patch\nreview via email, and some trees are doing patch review via gerrit,\nand yet other trees have their maintainer do a quick cursory review at\n\"git pull\" time after the tree sends a git pull request.\n\nWhat sort of shareable context should git --- which is ignorant of all\nof these arrangements --- be preserving? And presenting to whom? And\nfor what goal/purpose?\n\n\t\t\t\t\t\t- Ted\n"},{"id":"378545","messageId":"06b74350-0846-91c1-0198-c2bcabd20084@iee.org","threadId":"51414","inReplyTo":"20190702192412.GE3032@mit.edu","subject":"Re: Tracking parent branches in Git","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2019-07-03T15:58:17Z","receivedAt":"2019-07-03T15:58:21Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"On 02/07/2019 20:24, Theodore Ts'o wrote:\n> I think the real problem with all of this feature request is that it's\n> all presuming a particular workflow, and git is currently*not*\n> strongly opinionated about the workflow.\nI'd suggest that git does have a clear preference for a workflow that is \nbased on the \"upstream\" view. (e.g. see 'rebase')\n\nWhile Git tries to avoid being opinionated, it does develop a bias of \navoiding various common workflows, to the point that they are not even \nwell named.\n\nIn particular, we have a number of variants of the triangular workflow, \nsuch as having a personal github fork, and a then also a maintainer's \nrepo to complete the triangle [which is even worse for those supporting \nGit-for-Windows because of two level maintenance cascade, with different \ncompilation and OS requirements..]. Having three 'origins' is no fun.\n\nThere was an attempt to document a triangular flow a while back, but it \nwasn't actually that one. e.g. [1])\n\nThe other preference aspect is the tendency to expect users to 'support \nthe machine' (e.g. the assume-unchanged file flag, which is commonly \nmisunderstood), rather than having a clarity about when Git will support \nthe user. Here we (they) are looking for the human readable name of the \nbranch that they forked from (and is likely to have been extended \nsince), rather than the oid hash of the fork point, though that is \nclearly useful and should be recorded with the branch name as it is \nimmutable.\n\nI am cautious about support for Gerrit on the basis that it could \naccidentally reinforce a centralised workflow (to the detriment of \ndistributed operation), which should be avoided strongly as a deliberate \nbias.\n\nHowever the desire to _locally_ record the branch name that the current \nbranch was created from is something I would support (which is why I \nsuggested the unused branch description...).\n\nPhilip\n\n[1] \nhttps://public-inbox.org/git/5A8F8EE0162B49818813DAEFD68F61DA@PhilipOakley/\n\n(sorry for any delays, I'm still in catch-up mode)\n"}]}