As a committer, of course you can process the pull requests in whatever order makes best sense. If you need to, you can rebase each pull request before you merge it. Usually it will rebase without conflicts.
If you are fond of using github’s “Merge pull request” button, you’ll have to let that one go. You simply can’t use that if you’re committing into Apache. Sorry! Julian > On Apr 18, 2016, at 6:51 PM, Jignesh Patel <[email protected]> wrote: > >> Please give me an example of something that may be painful. > > We have to go back to each PR and issue them back again in the same order. I > don’t see an easy way to do this in github (e.g. reopen a closed PR against a > new repo). Maybe I’m missing something. > >>> The cloning came somewhat of a surprise and caught us in the middle of a >>> sequence >>> of PR that are targeting a milestone that is about 10 days off (getting >>> TPC-H running >>> end-to-end before the students get off to the end-of semester sprint). >> >> Sure. But the cloning has little to do with PRs. Basically there's a >> state of the repo >> on ASF and Your side. That state needs to be synchronized (manually) one last >> time right before you all decide to cut over and start using ASF Git >> as a single source >> of truth. That part is super simple and has little to do with PRs. > > Ok — let me dig though this and understand it better. > > Cheers, > Jignesh
