<p>Note: If no explicit refspec is found, (that is neither\r
on the command line nor in any Push line of the\r
corresponding remotes file---see below), then all the\r
-refs that exist both on the local side and on the remote\r
+heads that exist both on the local side and on the remote\r
side are updated.</p>\r
<p><tt>tag <tag></tt> means the same as <tt>refs/tags/<tag>:refs/tags/<tag></tt>.</p>\r
<p>A parameter <ref> without a colon pushes the <ref> from the source\r
<dd>\r
<p>\r
Instead of naming each ref to push, specifies that all\r
- refs be pushed.\r
+ refs under <tt>$GIT_DIR/refs/heads/</tt> be pushed.\r
</p>\r
</dd>\r
<dt>\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 06-Sep-2007 08:52:20 UTC\r
+Last updated 19-Sep-2007 02:27:19 UTC\r
</div>\r
</div>\r
</body>\r
Note: If no explicit refspec is found, (that is neither
on the command line nor in any Push line of the
corresponding remotes file---see below), then all the
-refs that exist both on the local side and on the remote
+heads that exist both on the local side and on the remote
side are updated.
+
`tag <tag>` means the same as `refs/tags/<tag>:refs/tags/<tag>`.
\--all::
Instead of naming each ref to push, specifies that all
- refs be pushed.
+ refs under `$GIT_DIR/refs/heads/` be pushed.
\--tags::
All refs under `$GIT_DIR/refs/tags` are pushed, in
<dd>\r
<p>\r
Instead of explicitly specifying which refs to update,\r
- update all refs that locally exist.\r
+ update all heads that locally exist.\r
</p>\r
</dd>\r
<dt>\r
<p>With <em>--all</em> flag, all refs that exist locally are transferred to\r
the remote side. You cannot specify any <em><ref></em> if you use\r
this flag.</p>\r
-<p>Without <em>--all</em> and without any <em><ref></em>, the refs that exist\r
+<p>Without <em>--all</em> and without any <em><ref></em>, the heads that exist\r
both on the local side and on the remote side are updated.</p>\r
<p>When one or more <em><ref></em> are specified explicitly, it can be either a\r
single pattern, or a pair of such pattern separated by a colon\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 19-Jul-2007 02:09:54 UTC\r
+Last updated 19-Sep-2007 02:27:20 UTC\r
</div>\r
</div>\r
</body>\r
\--all::
Instead of explicitly specifying which refs to update,
- update all refs that locally exist.
+ update all heads that locally exist.
\--force::
Usually, the command refuses to update a remote ref that
the remote side. You cannot specify any '<ref>' if you use
this flag.
-Without '--all' and without any '<ref>', the refs that exist
+Without '--all' and without any '<ref>', the heads that exist
both on the local side and on the remote side are updated.
When one or more '<ref>' are specified explicitly, it can be either a
<h2>DESIGN PHILOSOPHY</h2>\r
<div class="sectionbody">\r
<p>Merge tracking in Subversion is lacking and doing branched development\r
-with Subversion is cumbersome as a result. git-svn does not do\r
-automated merge/branch tracking by default and leaves it entirely up to\r
-the user on the git side. git-svn does however follow copy\r
-history of the directory that it is tracking, however (much like\r
-how <em>svn log</em> works).</p>\r
+with Subversion can be cumbersome as a result. While git-svn can track\r
+copy history (including branches and tags) for repositories adopting a\r
+standard layout, it cannot yet represent merge history that happened\r
+inside git back upstream to SVN users. Therefore it is advised that\r
+users keep history as linear as possible inside git to ease\r
+compatibility with SVN (see the CAVEATS section below).</p>\r
</div>\r
<h2>CAVEATS</h2>\r
<div class="sectionbody">\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 29-Aug-2007 07:30:59 UTC\r
+Last updated 19-Sep-2007 02:27:20 UTC\r
</div>\r
</div>\r
</body>\r
DESIGN PHILOSOPHY
-----------------
Merge tracking in Subversion is lacking and doing branched development
-with Subversion is cumbersome as a result. git-svn does not do
-automated merge/branch tracking by default and leaves it entirely up to
-the user on the git side. git-svn does however follow copy
-history of the directory that it is tracking, however (much like
-how 'svn log' works).
+with Subversion can be cumbersome as a result. While git-svn can track
+copy history (including branches and tags) for repositories adopting a
+standard layout, it cannot yet represent merge history that happened
+inside git back upstream to SVN users. Therefore it is advised that
+users keep history as linear as possible inside git to ease
+compatibility with SVN (see the CAVEATS section below).
CAVEATS
-------
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 19-Jul-2007 02:10:08 UTC\r
+Last updated 19-Sep-2007 02:27:20 UTC\r
</div>\r
</div>\r
</body>\r
allowed-groups, to describe which heads can be pushed into by
whom. The format of each file would look like this:
- refs/heads/master junio
+ refs/heads/master junio
refs/heads/cogito$ pasky
- refs/heads/bw/ linus
- refs/heads/tmp/ *
- refs/tags/v[0-9]* junio
+ refs/heads/bw/.* linus
+ refs/heads/tmp/.* .*
+ refs/tags/v[0-9].* junio
With this, Linus can push or create "bw/penguin" or "bw/zebra"
or "bw/panda" branches, Pasky can do only "cogito", and JC can
projects / git.git / commitdiff