Segher Boessenkool <seg...@kernel.crashing.org> 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 :-) > >> +<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) > >> +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? > >> +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?
it’s a way of making things distinct and allows the push rule to be present for them but absent for more dangerous pushes. So if one renames origin to something else e.g. fsf or upstream, and there are no automatic push rules, it’s one more small protection against an accidental push? > You could just use > > push = thing:users/<name>/heads/thing > > (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
