On 09/01/2020 16:50, Richard Earnshaw (lists) wrote:
Given the proposed intention to use non-standard refspecs for private
and vendor branches I've written some notes on how to use these.
It would be helpful if someone could do some experiments to ensure that
what I've written works properly for all versions of git, not just the
one I have installed locally.
R.
A minor tweak after testing it myself pushing to the
gcc-reposurgeon-8.git trial
R.
diff --git a/htdocs/svnwrite.html b/htdocs/svnwrite.html
index a1346be1..1b06c495 100644
--- a/htdocs/svnwrite.html
+++ b/htdocs/svnwrite.html
@@ -25,6 +25,7 @@ maintainers and significant developers.</p>
<li><a href="#checkin">Checking in a change</a></li>
<li><a href="#example">Example check-in session</a></li>
<li><a href="#branches">Creating and using branches</a></li>
+ <li><a href="#vendor">Private user and Vendor branches</a></li>
<li><a href="#account">Tips&Tricks around your account</a></li>
</ol>
@@ -407,6 +408,73 @@ svn cp svn+ssh://<i>username</i>@gcc.gnu.org/svn/gcc/trunk \
do not copy the entire set of ChangeLog entries. Just use something
like "Merge from mainline" or similar.</p>
+<hr />
+<h2 id="vendor">Private user and vendor branches</h2>
+
+The GCC git repository is used by many people and the branch and tag
+namespace would become very polluted if all branches lived at the
+top-level naming space. To help minimise the amount of data that
+needs to be fetched the git repository on gcc.gnu.org contains a
+number of private user and vendor branches that developers use to
+share their work. These are not pulled by default, but simple
+configuration steps can give access to them.
+
+<ul>
+ <li>Private user branches live
+ in <code>refs/users/<i>username</i>/heads</code> with tags
+ in <code>refs/users/<i>username</i>/tags</code>.</li>
+ <li>Vendor branches live
+ in <code>refs/vendors/<i>vendor-name</i>/heads</code> with tags
+ in <code>refs/vendors/<i>vendor-name</i>/tags</code>.</li>
+</ul>
+
+To fetch any of these you will need to add a fetch refspec to your
+configuration. For example, to fetch all the IBM vendor branches add to
+your default upstream pull
+
+<blockquote><pre>
+git config --add remote.origin.fetch "+refs/vendors/IBM/heads/*:refs/remotes/origin/IBM/*"
+git config --add remote.origin.fetch "+refs/vendors/IBM/tags/*:refs/tags/IBM/*"
+</pre></blockquote>
+
+this will cause <code>git pull</code> to fetch all the additional
+branches and make them available locally
+under <code>remotes/origin/IBM</code> and will also add any tags under
+the sub-namespace <code>IBM</code>.
+
+Setting up a tracking branch for one of the upstream vendor branches
+is slightly more complicated as <code>git branch
+--set-upstream-to</code> does not work properly. However, it is
+possible to configure the branch information directly. First, check
+out the branch you want to track, for example, to check out the
+<code>arm-9-branch</code> use something like:
+
+<blockquote><pre>
+git checkout -b ARM/arm-9-branch origin/ARM/arm-9-branch
+</pre></blockquote>
+
+then change the merge property for the branch to corectly identify the
+upstream source
+
+<blockquote><pre>
+git config branch.ARM/arm-9-branch.merge refs/vendors/ARM/heads/arm-9-branch
+git config branch.ARM/arm-9-branch.remote origin
+</pre></blockquote>
+
+Pull operations will now correctly track the upstream branch.
+
+It is also possible to set up push operations so that local changes will be pushed to the private namespace. For example, if you mirror your own private git information with
+
+<blockquote><pre>
+git config --add remote.origin.fetch "+refs/users/<i>my-userid</i>/heads/*:refs/remotes/origin/me/*"
+</pre></blockquote>
+
+then you can also add
+<blockquote><pre>
+git config --add remote.origin.push "+refs/heads/me/*:refs/users/<i>my-userid</i>/heads/*"
+</pre></blockquote>
+and then any push from a branch that begins with <code>me/</code> will be pushed to the private area.
+
<hr />
<h2 id="account">Tips&Tricks around your account</h2>
