diff options
Diffstat (limited to 'rules')
| -rw-r--r-- | rules/source_repositories.mdwn | 148 |
1 files changed, 2 insertions, 146 deletions
diff --git a/rules/source_repositories.mdwn b/rules/source_repositories.mdwn index 21419393..8215af3b 100644 --- a/rules/source_repositories.mdwn +++ b/rules/source_repositories.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2007, 2008, 2009 Free Software Foundation, +[[!meta copyright="Copyright © 2007, 2008, 2009, 2010 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable @@ -9,148 +9,4 @@ Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled [[GNU Free Documentation License|/fdl]]."]]"""]] -Git repositories on Savannah: <http://git.savannah.gnu.org/cgit/hurd/>. - -# Branches - -Members of the [[Hurd_Savannah_group|savannah_group]] are allowed to create -branches without formal permission: - - * named `SAVANNAH_LOGIN/BASE_BRANCH[-TOPIC]` for private general-purpose or - topic branches, respectively, or - * named `BASE_BRANCH-TOPIC` for public topic branches basing on - `BASE_BRANCH`. - -`TOPIC` shall be a suitable tag describing the branch's main concern. These -tags can be applied recursively (`TOPIC-SUBTOPIC-SUBSUBTOPIC`). - -*private* vs. *public* does, of course, in this scenario not mean visibility, -but instead authority: *private* branches are those that the user -`SAVANNAH_LOGIN` has authority over, whereas *public* branches are open for -every committer to install changes on. The private branches are those that you -would typically host on your own machine and publish through your own web -server, but we offer that you can instead do this from the centralized Savannah -repository, as a number of people don't have an always-accessible web server -running on their own machines. - -Examples: - - * GNU Mach - - * `master` -- the mainline branch - * `master-oskit` -- port to OSKit; branched off of `master` at some point - * `master-gdb_stubs` -- add support for GDB stubs; branched off of - `master` at some point - - * libpthread - - * `master` -- the mainline branch - * `master-viengoos` -- port to Viengoos; branched off of `master` at some - point - * `master-viengoos-on-bare-metal` -- port to Viengoos running on bare - metal; branched off of `master-viengoos` at some point - - * unionfs - - * `master` -- the mainline branch - * `master-unionmount` -- develop `unionmount` based on `unionfs`' master - branch - -To give a concrete example, the latter one was created like this: - - $ git clone --no-checkout ssh://git.savannah.gnu.org/srv/git/hurd/unionfs.git - $ cd unionfs/ - $ git checkout -b master-unionmount origin/master - $ ... - $ git push master-unionmount - -## Merging - -Merging between Git branches is trivial, at least as long as no conflicts -arise. - -Due to this, you are encouraged to freely make use of separate branches for -different working topics, as this really faciliates concentrating on one -specific working topic. - -You are encouraged to regularely merge from the respective mainline branches -(`BASE_BRANCH`; should be `master` in most cases) into your working branches, -and ensure that your modifications are still fine in the context of new -mainline changes. - -Merging from working branches into the mainline branches will usually be done -by one of the project administrators, unless negotiated otherwise. For this to -happen, the copyright of your changes has to be assigned to the Free Software -Foundation; read about the -[[copyright_assignment_process|savannah_group#copyright_assignment]]. - -It is explicitly encouraged to *merge* changes from working branches into the -mainline branches (as opposed to *rebase* them on top), as the former mode -easily allows to determine the context under which a patch has been developed. - -# Tags - -Equivalent rules apply. - -# Behavior - -Try to not introduce spurious, unneeded changes, e.g., whitespace changes. - -Adhere to the coding conventions that are already used. These are usually the -[GNU Coding Standards](http://www.gnu.org/prep/standards/html_node/) for stuff -written by ourselves, including new files, of course. - -GNU Mach code is largely based on external code. Don't GNU-ify it, as this -would make merging external patches unnecessarily difficult. - -## Commit messages - -We no longer maintain parallel `ChangeLog` and commit messages. When needed, -the `ChangeLog` files can be created automatically from the commit messages. - -Commit messages have this mandatory format: - - One-line summary. - Blank line. - ChangeLog-like list of changes, but without leading tabs. - -The header line of each former `ChangeLog` snippet (DATE NAME EMAIL) is no -longer to be included in the commit message, and instead the author and -committer of a change, together with the dates, will be maintained natively by -Git. - -Example: - - commit 3054666a46e0142cacef895c13edb4391435c722 - Author: Some One <someone@example.com> - AuthorDate: Thu Jun 11 15:59:55 2005 +0000 - Commit: Some One <someone@example.com> - CommitDate: Thu Jun 11 15:59:55 2005 +0000 - - Frobnicate the foo. - - * frob.c (foo): Frob it. - * oldfoo.c [OLD] (oldfoo): Likewise. - [OLD_OLD_FOO] (oofoo): Permute every second word with itself, and - beginning with the tenth line, every third one also. Pure - nonsense. - -Read about how to write [GNU-style `ChangeLog` -messages](http://www.gnu.org/prep/standards/html_node/Change-Logs.html). - -Don't waste time writing exhaustive `ChangeLog`-like commit messages for, e.g., -debugging stuff that will be removed again before merging your development -branch into the mainline. Sometimes the one-line summary might already -suffice. But please do write something. - -## Behavior on *private* branches - -Even though you are said to be the owner of branches tagged with your -`SAVANNAH_LOGIN`, it is generally nevertheless good to not do history-rewriting -stuff and the like (`git rebase` and friends), as others may in turn be basing -their work on your private branches. - -We could establish a branch-tagging policy for branches that others should -expect their history possibly to be rewritten. This may be useful for branches -that are only meant for aggregating the changes of (several) development -branches, like an imaginary `master-proposed_for_general_testing` branch. +[[!meta redir=/source_repositories]] |