emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] Git mirrors


From: Nick Dokos
Subject: Re: [O] Git mirrors
Date: Tue, 22 May 2012 02:58:19 -0400

François Pinard <address@hidden> wrote:

> Hi, Org people.
> 
> GitHub has a few niceties, like easy forking, pull requests and such.  I
> notice https://github.com/jwiegley/org-mode in particular, which does
> not seem to be itself a fork of another GitHub repository, so I presume
> it forked directly from the official Git site for Org mode, which itself
> does not provide the same collaboration facilities as GitHub.
> 
> The GitHub home page for John Wiegly says the org-mode project was
> updated two weeks ago, so I suspect it lags on the official Git site.  A
> message on the mailing list speaks of this repository as the home for
> Org-X, so I also suspect this fork is not genuine, and not a way to get
> on GitHub the real, pure, Org mode.
> 

It does not make any difference from where you get it. You can mirror
the org git repo from orgmode.org on github if you want: nothing is
stopping you. Then use the github collaboration tools.

> In the Org project, how commits are usually transmitted?  I would not
> think maintainers are pulling our various repositories in theirs to then
> consider cherry picking, and it would require that we all set up Git
> servers.  We could use GitHub as a way to avoid servers, but it feel
> strange using GitHub to communicate with Org maintainers while they do
> not themselves choose to keep an "official" mirror of Org on GitHub.
> 

That's up to each maintainer: they can apply patches sent as email, or
they can cherry-pick commits from a remote branch if they want.

There is nothing strange about using github to communicate with the
maintainers: set up your clone, create a branch with your modification
and let the maintainers know about it. That's how many linux maintainers
did things while kernel.org was down last year. All that changed for
Linus was that he pulled from a different repo.

OTOH, some maintainers would prefer emailed patches instead; some
wouldn't care one way or the other. If they don't want to touch your
repo, you can't make them, so the best thing to do is ask which is their
preferred method. Or do as Bernt Hansen was doing: submit a patch in
email and also point to a branch that contains that patch (and that
patch alone) on top of a clone of the official git repo. This last
method has the advantage that it tells the maintainer the exact state of
the tree when the patch was applied, which allows problematic merges
to be resolved more easily (see Linus's comments in

 https://plus.google.com/111049168280159033135/posts/Xmycxn7VwHV

for some details - but that's useful mostly for maintainers, not
for patch contributors; otoh, it's always nice to know more than
the absolute minimum necessary.)

> Commits are going to be sent as email apply-able patches?  Maybe this is
> all documented somewhere already, and I just did not read enough?
> 

``Documented'' is probably too strong a word, but once you've been on
the ML for a while, you start discerning the customs of the people
living there: emailed patches is indeed the standard way (not least
because patchwork captures them, so they don't get lost in some old
email thread).

Nick

Disclaimer: I'm not a maintainer, so if I've got things wrong, I hope
one of them will correct me.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]