On Thu, Sep 24, 2020 at 10:10:16PM -0700, Chris Webster wrote: > > Definitely not worth > > it compared to your solution for a PR, but maybe worth it if it lets us > > do the same thing for arbitrary branches. > > The PR solution works because fixed values are available from GitHub > (both repos are present and accounted for). A push action for > branches could have issues with the state of the GitHub repo versus > the local repo. What happens if the base branch is not current on > GitHub? Is HEAD reliable? What if the branch has been re-used with a > back-merge? How do you limit the check in this case? Based on my > demonstrated lack of knowledge these concerns may be addressable. Hmm, good points. The case I was most worried about was branches based on older points in history, but as long as master keeps moving forward, we'd be OK there (at least in the local case where we have all of the commits; not sure about the shallow-exclude I mentioned above). And in the case of git.git, I think we're pretty safe. "master" gets pushed along with "seen". But not necessarily so in other repositories. If I base a new topic on Junio's "master" and then push it up, it may be far ahead of my "master" (and in fact, I don't even have a "master" in my personal repo). GGG PRs figure this out because that repo is a fork of git/git, and it looks at the master of the parent repo as the base for the PR. So probably we could do something similar, but this is starting to get rather tricky. I think you've convinced me that it's not easy to just adapt this to handle any branch. Let's punt on that idea for now (unless somebody feels like digging further on it, of course) and move forward with doing this for the PR case as your patch does. -Peff
