> > [Overly long lines are not appreciated around here.] Thanks for the feedback, is there an email client or tool that can format the lines correctly? > > > > > We 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. > > > > Do you mean by "parent branch" what people usually call "upstream > > branch" (i.e. when that branch on the other side gains more commits > > independent from what you have been working on, then you would want to > > rebase your work on top of the updated state of that branch on the > > other side) around here? > > I suspect the question is in regards to "What branch did I create my local branch from?", especially given the pull request reference. Yes, this is what I meant. > > In other words, when I locally do: > git checkout --no-track -b bturner-some-bugfix origin/release/5.16 > > 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" > 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.) > > > 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). > > You can right now give meta data of your choice with --push-option to > the push command. The Gerrit system makes use of that already. However, > this would not be intrinsic to Git, but the serve needs to react on > those options. And it should be in good company with suitable client > tools. @Eckhard, is that documented somewhere? I don't see it on https://git-scm.com/docs/git-push/1.6.4.1 > > Take care, > Eckhard > > Best regards, > Bryan Turner > > [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 > > > > > Perhaps "git help glossary", look > > for "upstream branch" and start from there? The entry mentions the > > configuration variables used to keep track of that information, which > > are described in "git help config", I think. > > > > > 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? > > > > Regardless of what is being proposed, this is often not a very useful > > question. Something worth doing for yourself is worth doing whether > > others also find it useful ;-) And others usually do not have enough > > information to judge if such a change is welcome until seeing it in a > > bit more concrete form. I wanted to get a some thoughts before I worked out the details. The feature is of little use if no one is using the version of git with it since most everyone uses standard distros of git. > > 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. > > 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. Multiple branches can have the same commit, but only one branch can be checked out at once, right? Then the parent branch would be the branch you were on when you ran checkout -b. That branch might change and no longer be of use, but it seems like in practice that is not the case. New features are usually created off of a local branch and then PR'd back to the upstream version of that branch. Thanks! Eric ________________________________________ From: Eckhard Maaß <eckhard.s.maass@xxxxxxxxxxxxxx> Sent: Monday, July 1, 2019 1:40 PM To: Bryan Turner Cc: gitster@xxxxxxxxx; Eric Kulcyk; git@xxxxxxxxxxxxxxx Subject: Re: Tracking parent branches in Git On Mon, Jul 01, 2019 at 12:48:16PM -0700, Bryan Turner wrote: > 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). You can right now give meta data of your choice with --push-option to the push command. The Gerrit system makes use of that already. However, this would not be intrinsic to Git, but the serve needs to react on those options. And it should be in good company with suitable client tools. Take care, Eckhard
