[IMP] git.rst formatting for direct on-git viewing

* replaced sphinx :guilabel: directive by a simple strong
* moved rendered notes to non-rendered comments, not that I expect anybody to
  care or help /emo
* remove an explicit code-block directive by a simple ::
This commit is contained in:
Xavier Morel 2014-05-15 14:23:08 +02:00
parent 8fce83d30d
commit 2ea0cfcfb8
1 changed files with 16 additions and 17 deletions

View File

@ -14,7 +14,7 @@ it will will ask a few questions and create a local copy.
.. note:: if the repository is private, you have to download it manually then .. note:: if the repository is private, you have to download it manually then
execute it wherever you want your working copy to be created, go to execute it wherever you want your working copy to be created, go to
https://github.com/odoo/odoo/blob/master/checkout.sh then click the https://github.com/odoo/odoo/blob/master/checkout.sh then click the
:guilabel:`Raw` button. **Raw** button.
Git concepts Git concepts
------------ ------------
@ -83,25 +83,26 @@ Basic development workflow
- merge the remote branch into the local one with ``git merge --no-ff - merge the remote branch into the local one with ``git merge --no-ff
origin/trunk`` origin/trunk``
.. note::
* should we promote rebase? That would lead to cleaner histories, but
if the branch is already pushed it requires force-pushing since the
branch can't be fast-forwarded
* git automatically creates a merge commit, should we configure merge
with --no-commit?
* make --no-ff the default in the config script?
* warn about ``git pull``? It is ~ ``git fetch; git merge`` and should
probably be avoided
* to push the branch to the development repository, use ``git push -u dev * to push the branch to the development repository, use ``git push -u dev
<branchname>``, this will automatically create a branch called <branchname>``, this will automatically create a branch called
``<branchname>`` on dev. Next time around you do not have to use ``-u`` ``<branchname>`` on dev. Next time around you do not have to use ``-u``
* once the feature is done, create a pull request * once the feature is done, create a pull request
.. note:: CLI tools? .. should we promote rebase? That would lead to cleaner histories, but if the
branch is already pushed it requires force-pushing since the branch can't
be fast-forwarded
.. note:: format for specifying issues? e.g. closes #42? .. git automatically creates a merge commit, should we configure merge with
--no-commit?
.. make --no-ff the default in the config script?
.. warn about ``git pull``? It is ~ ``git fetch; git merge`` and should
probably be avoided
.. CLI tools?
.. format for specifying issues? e.g. closes #42?
Tasks Tasks
----- -----
@ -120,9 +121,7 @@ a few differences:
* ``git log``'s second positional argument is a path (file or * ``git log``'s second positional argument is a path (file or
directory). Because both are optional, if both a revision and a file match directory). Because both are optional, if both a revision and a file match
the revision will be selected. It is recommended to use ``--`` before a file the revision will be selected. It is recommended to use ``--`` before a file
path: path::
.. code-block:: console
git log -- filepath git log -- filepath