Re: github mirror of lilypond?

[David Kastrup]

"Jürgen Reuter" <address@hidden> writes:

>    Hi all,
>
>    +1 (at least) from me for for:
>
>    * Having a smooth integration of git repository, review process and
>    verify build.  If this is (as I conclude from the discussions) not
>    possible with hosting the git repository on savannah, then please
>    consider hosting the repository on a different platform.
>
>    * Using Gerrit as review system (maybe unless you know of another
>    system with equally smooth integration with git; but I do not know of
>    any such system).  I am using Gerrit (the "old" version) at work and I
>    am fully satisfied with its integration with git and Jenkins.
>    I still have here ~12 mostly small commits (tiny fixes / features,
>    clean-ups, code doc clarifications, etc.) lying around locally on my
>    machine for several years.  I did not push them so far as I was (and
>    still am) really scared about the time that I have to invest to get
>    these commits through this complex process, especially as I expect at
>    least some of the commits not to pass in the first go, but expecting
>    possibly controversial reviews.
>    Maybe the current process feels not that complex if you are committing
>    regularly.  But I perceive it as complex, especially with respect to
>    the time that I fear to have to put into the process rather than being
>    productive, given my very limited time budget.  And I think, other
>    people perceive it similarly.

File: lilypond-contributor.info,  Node: How to make a patch,  Next: Emailing 
patches,  Up: Patches

How to make a patch
...................

If you want to share your changes with other contributors and
developers, you need to generate _patches_ from your commits.  We prefer
it if you follow the instructions in *note Uploading a patch for
review::.  However, we present an alternate method here.

   You should always run ‘git pull -r’ (translators should leave off the
‘-r’) before doing this to ensure that your patches are as current as
possible.

   Once you have made one or more commits in your local repository, and
pulled the most recent commits from the remote branch, you can generate
patches from your local commits with the command:

     git format-patch origin

   The ‘origin’ argument refers to the remote tracking branch at
‘git.sv.gnu.org’.  This command generates a separate patch for each
commit that’s in the current branch but not in the remote branch.
Patches are placed in the current working directory and will have names
that look something like this:

     0001-Doc-Fix-typos.patch
     0002-Web-Remove-dead-links.patch
     ⋮

   Send an email (must be less than 64 KB) to <address@hidden>
briefly explaining your work, with the patch files attached.
Translators should send patches to <address@hidden>.  After
your patches are reviewed, the developers may push one or more of them
to the main repository or discuss them with you.

>    And of course, a big thank you to all of you that do all the great
>    work, that I really appreciate!  But to attract more developers and /
>    or re-animate retired developers, I am pretty sure that the process has
>    to be simplified for potential "casual" committers like me that will
>    contribute only now and then.

The above does not look all that complex to me.

-- 
David Kastrup