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. > > (no "+", I don't rebase the "thing" branch). Hrm, and maybe make an > alias to push a local branch to the server the first time... Completely > untested: > > [alias] > new-user-branch = !git push $1:users/myname/heads/$1 > > (And yes, I know this doesn't work as written if you have tag names > the same as branch names. That *deserves* punishment :-) ) > > > Segher Thanks for the feedback. Also see my scripts for setting up user/vendor stuff that I posted yesterday, it might simplify some of the above setup steps and thus the documentation, but I wrote those scripts after I had written this text. R.
