On Tue, Jul 02, 2019 at 11:52:35AM -0700, Bryan Turner wrote: > Sorry, I should have clarified my "--no-track" in my original message > when I provided the example. I did "--no-track" because if I push > "bturner-some-bugfix" to a server, I'm likely going to do something > like "git push -u origin bturner-some-bugfix" so that my local > "bturner-some-bugfix" branch will track the remote version of itself. > At that point, the remote-tracking information would change from > "release/5.16" to "bturner-some-bugfix" (without any sort of warning, > for whatever that's worth), effectively "losing" the ancestry. > > The other issue is that my local remote-tracking information doesn't > help the server I'm talking to; it's not shareable. Assuming I could > use remote-tracking to track ancestry, there's still no way to > communicate that to the server so that it could know, when I go to > create a pull request for "bturner-some-bugfix", that it's tracking > "release/5.16" in my local repository. I think the real problem with all of this feature request is that it's all presuming a particular workflow, and git is currently *not* strongly opinionated about the workflow. So for example, if I create a local branch against origin/release/5.16 with a series of fixes, and I'm pushing to a gerrit server for review, I might need to do something like this: git push gerrit HEAD:refs/for/release/5.16%r=reviewer@xxxxxxxxxxx,%cc=kernel-reviewers@xxxxxxxxxxx So the fact that we've recorded the information about the parent branch when doing a "git checkout -b bugfix origin/release/5.16" is part of the puzzle, but the other part of the puzzle is knowing what the destination server is going to want or need. Internally at $WORK we have our own internal script that does this automatically, so I just have to run something like "kdt mail -r reviewer@xxxxxxxxxxx", but it's always going to be very workflow-independent. > I could certainly be misunderstanding the request, but I think it's > asking for something less ephemeral--and more shareable--than > remote-tracking, and it seems logical to want to be able to retain > ancestry while still using remote-tracking setup such that local > branches still track the remote version of themselves, rather than > some other (albeit related) branch. In order for it to be shareable, we have to make some very strong assumptions about workflow. It gets worse when people pull from more than one tree, or there is a series of subtrees. For example, suppose the 2nd-level lieutenant has a "net" tree, and the 3rd-level lieutenants have a "sctp" and a "ipsec" tree. Now let's assume that there is some common infrastructure branch that both 3rd-level lieutenants need to build off of that comes from some other 2nd-level tree, and so for that development cycle, they first pull from the top-level tree, and then both 3rd level trees merge in a branch from the "mm" tree, but then they will be both be sending pull request emails to the "net" tree. There will be a whole series of git pulls and git merges that will be in flight, and just for yucks, let's suppose some trees are do patch review via email, and some trees are doing patch review via gerrit, and yet other trees have their maintainer do a quick cursory review at "git pull" time after the tree sends a git pull request. What sort of shareable context should git --- which is ignorant of all of these arrangements --- be preserving? And presenting to whom? And for what goal/purpose? - Ted
