On 6 December 2016 at 10:34, René J.V. Bertin wrote: > On Monday December 5 2016 22:52:51 Lawrence Velázquez wrote: > >> Fetching from a fork does not download the full history. Only the >> objects that are not in your repository are fetched. > > That implies adding the fork as another remote with the associated > house-keeping afterwards?
No. You can do: USER=some-username REMOTEBR=remote-branch-name LOCALBR=local-branch-name git fetch https://github.com/$USER/macports-ports.git $REMOTEBR git checkout -b $LOCALBR FETCH_HEAD # git rebase master > Not that it's directly relevant to the topic at hand, but how many committers > are there? https://trac.macports.org/wiki/MacPortsDevelopers > It would be very good to get more committers involved in the revision process. While I agree with that, it's all voluntary work. > I'm not sure how; the peer review process as used in scientific publication > comes to mind (oh, the fond memories...), where an "editor" (ideally picked > by the author) requests timely reviews from a number of referees. Question is > of course who those editors would be, and who'd appoint them. The huge difference is that people involved in scientific journals (either as authors, reviewers or editors) often have a monetary interest in one way or another (ok, in realy the publisher has the biggest interest and all others are free workers for the publisher, but let's not get this off-topic). Doing scientific publishing is essential to get sufficient "points" to stay on the payrole at institutes and universities around the world. For me MacPorts is exactly the opposite: a distraction that makes me do *LESS* of what counts for my career (and sometimes even bites off my time at work). Getting random assignments that I don't understand / don't know how to test / don't have time to work on / or am not interested to do, would probably backfire and would hardly help. What we *do* miss though is some easier browsing through trac tickets. With thousands of tickets open and zero overview of which tickets: - only need the final OK and commit from a reviewer - are waiting for maintainer's approval (and are already due for committing) - don't get committed because the non-maintainer is too polite/kind and doesn't want the maintainer to get angry due to a non-authorized commit - need someone to solve a potentially trivial problem - just need someone to take 5 minutes to finish the work - need an agreement of *how* to implement things - just need tedious, but otherwise trivial work - ... >>> Side-ways related: maybe the Git/PR wiki topic could say a word or two >>> about when a rebase request might be made before a PR can be merged. >> >>Huh? > > The how to work with git wiki topic about pull requests ("Updating your > fork") states something like "we might ask you to rebase your changes on top > of our current master branch". A bit of explanation when and why such a > request might occur won't hurt. I can explain here, but someone needs to edit the page. When someone submits a pull request (let's assume that it's already perfect) and a committer fetches it, rebases it and commits it to the master, then the PR is not automatically linked to the commit (if rebasing happens in the meantime). Alternatives are: (a) press the rebase button on the website (b) force push to the branch of PR (c) ask the author to rebase (d) accept the fact that the two are not linked Problems: (a) Committer's email is "random" rather than usern...@macports.org (b) The one submitting the PR has to allow this (not everyone is happy with it) (c) Timing. It's basically impossible to assure that even after the author rebases, some committer will pick it up and commit it fast enough (= before another commit flies in). (d) The obvious. PR will be marked as Closed (rejected?) rather than Merged. >From the perspective of GIT updating (rebasing) the PR is not really required, it's just the workflow at GitHub that's flawed. I cannot find the relevant "quasi-upstream" ticket right now, but an example would be https://github.com/todogroup/gh-issues/issues/40 Mojca