I think that you're thinking about something else.
For a time, GitHub themselves were making mirrors of all of our Git
repositories. Mirrors were, unfortunately, never really considered
first class by GitHub and badly broken. Other than to poke GitHub
admins every few days, there was nothing that we could do, so we
asked them to discontinue the process.
We've gone through a few iterations of pruning. We killed off some
website repos that had been mirrored in error. We also killed off a
bunch of repositories that had no forks. We've been working through
the remaining mirrors (those with forks), but it's been slow going.
Wwayne
On 30/03/16 09:28 AM, Ed Willink wrote:
Hi
Sadly this is not true for all projects.
There were severe synchronization problems between Eclipse and
GitHub that could not be resolved from the Eclipse end and so
GitHub support was discontinued; for some projects this was with
extreme prejuduce, for other it just happens to still work.
Thus https://github.com/eclipse/qvtd/network
became a 404, while https://github.com/eclipse/ocl/network
remains.
(The 404 is perhaps better than the VERY stale content that was
available.)
Regards
Ed Willink
On 30/03/2016 08:08, Stefan Xenos
wrote:
You don't strictly need the official project to be
on github in order to fork it there. I do most of my work on a
JDT core fork hosted on github, and the fact that the original
is on eclipse.org
hasn't been a blocker.
Isnt one of the key advantages of Github vs Eclipse
that you can fork a repo in the first place and then
produce a commit and a pull request. In Eclipse you can
only keep private copies of the Git repo on your local
machine/private repo but no public copies at Eclipse….
christian
I’m been working
with several GitHub-hosted projects, and I’m not a
fan. My 2¢:
- Reviewing sends out reams of email messages:
Github sends an email immediately on each
comment, and there’s no way to batch your
changes. The only workaround is to have your
team members turn off notifications and post a
final message where you name them individually
to say ‘finished my code review’.
- There’s no way to indicate summary
disagreement that other reviewers can see like
Gerrit’s -1 or -2.
- It results in people ignoring review
comments from others, only to discover
that the author has decided to rework the
approach based on the comments.
- There’s a tradeoff in how you update a pull
request (PR; a changeset in Gerrit terms).
You can use “—amend” and force up a new
version, which at least marks the previous
commits as stale, though the review comments
still show. Or you can put your changes in
new commits, so that changes are easily
discerned, but then newcomers to the PR walk
through the historical record.
- And beware that Travis doesn’t
re-evaluate updates to a PR
- When you merge a PR, it’s not clear what is
actually committed to the log message.
- Opaque identifiers in commit messages (e.g.,
“Closes #105”) seem to reference issues, but
sometimes PRs?
What I do like:
- Markdown almost everywhere; I really wish we
had this in Bugzilla and Gerrit
- Being able to search the repository is
great.
- Being able to see more code above and below
in the PR is helpful.
- Being able to drag in images/screenshots is
great.
Brian.
-------------------------------------------------------------
compeople AG
Untermainanlage 8
60329 Frankfurt/Main
fon: +49 (0) 69 / 27 22 18 0
fax: +49 (0) 69 / 27 22 18 22
web: www.compeople.de
Vorstand: Jürgen Wiesmaier
Aufsichtsratsvorsitzender: Christian Glanz
Sitz der Gesellschaft: Frankfurt/Main
Handelsregister Frankfurt HRB 56759
USt-IdNr. DE207665352
-------------------------------------------------------------
_______________________________________________
eclipse.org-committers mailing list
eclipse.org-committers@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse.org-committers
IMPORTANT: Membership in this list is generated by processes
internal to the Eclipse Foundation. To be permanently
removed from this list, you must contact emo@xxxxxxxxxxx to request removal.
_______________________________________________
eclipse.org-committers mailing list
eclipse.org-committers@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse.org-committers
IMPORTANT: Membership in this list is generated by processes internal to the Eclipse Foundation. To be permanently removed from this list, you must contact emo@xxxxxxxxxxx to request removal.
_______________________________________________
eclipse.org-committers mailing list
eclipse.org-committers@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse.org-committers
IMPORTANT: Membership in this list is generated by processes internal to the Eclipse Foundation. To be permanently removed from this list, you must contact emo@xxxxxxxxxxx to request removal.
--
Wayne Beaton on behalf of the Eclipse Management Organization
@waynebeaton
The Eclipse Foundation
|