> So, we now merge PRs through GitHub and then only merge the release branches locally manually afterwards?
I don't really know if that is what caused the problem and I wouldn't say that any particular way of merging is the policy and that's not the approach that I take. I was mentioning it more because I've tried to edit PRs before just by switching branches in GitHub and seen the problems it can form if you don't notice what it's doing. Of course even doing git manually, you could inadvertently cross the branches so I guess we just need to be careful with what buttons we press or what we type. In any case, mistakes happen so not a big deal. It would be nice though to know sooner if a problem occurred. Funny it took so long for it to be noticed. The only real policy we have is that the merge flow goes 3.4-dev -> 3.5-dev to master and that feature branches are based on HEAD of the target branch (i.e we don't merge a base branch into a feature branch, we rebase the feature branch on the base branch). > I always merged PRs manually if they didn't target master so I could push all affected releases branches together (via `git push --atomic origin master 3.5-dev` ha - as much as i know about git, there's always something new to learn. --atomic is a flag i don't think i've ever noticed, but now that i've read about that, that seems really smart. hate getting half way through a push and then end up with "non-fast-forward" failure. > But merging through GitHub and then afterwards merging only the release branches locally is of course a bit simpler, especially when merging multiple PRs at the same time, e.g., from Dependabot. I don't really like the GitHub buttons that much - almost never use them myself. what you were doing seems fine to me. For third-party PRs (like dependabot) I always bring those in locally: git fetch origin pull/1234/head:pr-1234 which creates a branch called pr-1234 for the GitHub pull request #1234. I can then test that and merge or cherry-pick as I desire. On Thu, Sep 2, 2021 at 4:09 AM Florian Hockmann <[email protected]> wrote: > So, we now merge PRs through GitHub and then only merge the release > branches locally manually afterwards? > I always merged PRs manually if they didn't target master so I could push > all affected releases branches together (via `git push --atomic origin > master 3.5-dev` to ensure that they are in sync). > But merging through GitHub and then afterwards merging only the release > branches locally is of course a bit simpler, especially when merging > multiple PRs at the same time, e.g., from Dependabot. > > But good that we are in a valid state again with 3.5-dev, thanks for > taking care of that! > > -----Ursprüngliche Nachricht----- > Von: Stephen Mallette <[email protected]> > Gesendet: Mittwoch, 1. September 2021 15:54 > An: [email protected] > Betreff: Re: branches crossed > > Ok - I think the issue is resolved now. 3.5-dev is now open for business. > For now we still have 3.5-dev-busted (which is the state 3.5-dev was in > when we realized it was bad) and 3.5-dev-august-23 which was Florian's > local working state that did not seem to look corrupted somehow. I imagine > that after we release 3.5.2 we can get rid of both of these branches as > they will definitely have no use at that point. > > Please be sure to fetch/reset your 3.5-dev branch if you have one locally: > > git fetch origin > git checkout 3.5-dev > git reset --hard origin/3.5-dev > > I thought I knew what happened to the branches yesterday but as I look > today I'm not seeing what I saw so clearly yesterday. At this point, I'd > just say to take care of merging through GitHub as I could imagine a > scenario where changes were based on master and a PR was issued. During the > review period, it's realized that it should have targeted 3.5 dev so the > merge is pointed there without rebaseing the change back to 3.5-dev. That > would basically merge master into 3.5-dev. <shrug> still not completely > sure if that actually happened, but it's a good trap that i've almost > stumbled into in the past that would have produced this situation. > welp....moving forward now! > > > > On Wed, Sep 1, 2021 at 9:26 AM Stephen Mallette <[email protected]> > wrote: > > > Your branch looks a little strange. While it definitely seems to have > > no mix up with master, it also seems to lack things I expected to > > see.......anyway, let's leave your branch there for a bit for safety > sake. > > Glad you had that. Resetting the branch now......... > > > > On Wed, Sep 1, 2021 at 3:02 AM Florian Hockmann > > <[email protected]> > > wrote: > > > >> > One caveat to that - Florian, I had a bit of trouble sorting > >> > through > >> your dependabot merges. I assume dependabot will just create fresh > >> PRs for you to merge when we force push this to 3.5-dev? > >> you could just merge them in again? > >> > >> Yes, that shouldn't be a problem. > >> > >> It looks like you already have a good basis for 3.5-dev with your > >> 3.5-dev-rebuild but just in case it could still help: I have checked > >> out a version of 3.5-dev locally from August 23 that still looks > >> good. It only misses the 3 most recent commits (not counting merge > >> commits). If you want to use it, I pushed it as 3.5-dev-august-23. > >> Otherwise, we can just delete the branch again. > >> > >> -----Ursprüngliche Nachricht----- > >> Von: Stephen Mallette <[email protected]> > >> Gesendet: Dienstag, 31. August 2021 21:52 > >> An: [email protected] > >> Betreff: Re: branches crossed > >> > >> I've rebuilt the 3.5-dev branch as: > >> > >> https://github.com/apache/tinkerpop/tree/3.5-dev-rebuild > >> > >> and I'm running the docker tests on it now but a preliminary build > >> worked fine. It should have all the commits that 3.5-dev should have > >> without the ones destined for master only. One caveat to that - > >> Florian, I had a bit of trouble sorting through your dependabot > >> merges. I assume dependabot will just create fresh PRs for you to merge > when we force push this to 3.5-dev? > >> you could just merge them in again? > >> > >> I'd like to quickly turn this around and get 3.5-dev operational > >> again, so I will look to replace 3.5-dev with the git history of > >> 3.5-dev-rebuild tomorrow and then do a no-op merge to master > >> (specifically with "git merge 3.5-dev --strategy=ours" - I think > >> that's the best way, if you know something better please let me > >> know). I'd expect to send a quick note to dev to be ready for the > >> change right before I do it and then it will be fixed. I see no > >> reason to keep a backup of 3.5-dev as it's basically just a copy of > master at this point. > >> > >> > >> > >> On Tue, Aug 31, 2021 at 11:25 AM Stephen Mallette > >> <[email protected]> > >> wrote: > >> > >> > Looks like 3.5-dev is suddenly even with master. No idea how/when > >> > that happened. Trying to figure it out, but if anyone knows what > >> > might have gone wrong, please yell. > >> > > >> > >> > >
