On 1/11/20 10:54 AM, Richard Earnshaw (lists) wrote:
On 11/01/2020 15:41, Segher Boessenkool wrote:
Hi Richard,

On Thu, Jan 09, 2020 at 04:50:03PM +0000, 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.

I haven't been able to test it yet, but it does look like it will work.

+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>

It may help to show the resulting config file instead of (or in addition
to) git-config commands to manipulate that.  The config file is (or can
be) much more readable than those commands (shorter lines, less quoting).
You can also organise it, put in comments, and even *debug it*!  And
*understand it* in general!  Wow, what a concept :-)

I wanted to describe it in the 'official' git way.  Tweaking the
contents of your .git/config file is not really sanctioned, even though
we all do it. :-)


+<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

(typo)

Already fixed, didn't seem like it was worth reposting just for that.


+upstream source
+
+<blockquote><pre>
+git config branch.ARM/arm-9-branch.merge refs/vendors/ARM/heads/arm-9-branch
+</pre></blockquote>
+
+Pull operations will now correctly track the upstream branch.

Do you also need to set branch.<name>.remote?  Or is that done correctly
already?  Or is that not needed if you have only one remote?

Yes.

However, on reflection, I'm not sure about that bit anyway.  I may
remote it entirely.



+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.

Will be *force-pushed* to the server.  This may not be expected or
wanted.

Why would people want to name their local branches "me/thing" instead
of just "thing", btw?  You could just use

   push = thing:users/<name>/heads/thing

You could do that instead, but then you need a push line for every
branch.  The me/<shared-branch> trick means that anything named me/*
will automatically get sent to the right place if pushed upstream.

I'd go with +refs/heads/*:refs/users/<userid>/heads/*

and then use

git push origin mybranch

I'm unlikely to want to push multiple branches at once.

Jason

Reply via email to