Re: [wwwdocs] Git transition - how to access private user and vendor branches
Segher Boessenkool wrote: On Sun, Jan 12, 2020 at 01:31:13PM +, Iain Sandoe wrote: Segher Boessenkool wrote: 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. That's a weird setting imo. Potentially destroying your own work *is* dangerous :-) Pretty much anything you mess up locally in Git can be easily restored. Restoring remote branches can be much harder. To start with, this requires knowing *what* to restore, which can require direct access to the remote repository, or its backups. So doing an unexpected non-ff push is probably not a good idea. You can also add a "+" manually when you want to overwrite the remote branch, or configure your setup to always do that for certain branches. (FAOD) I wasn’t suggesting to add the ‘+’ (I never set anything to force push) just commenting that putting one’s own work in a separate namespace isn’t a bad plan. It all depends on personal preference and work habits, of course. But I think it isn't the best idea to recommend people take up dangerous habits :-) 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? If you haven't configured push rules for your remote, you get what you have in "push.default" for that remote. Since Git 2.0 the default has been "push.default = simple", and no non-ff pushes are allowed by default anyway? I guess it makes some sense to group together locally the branches you have in users/ on our shared server. But then "me/" is not a great name :-) no, I usually duplicate the ‘userid’. Iain
Re: [wwwdocs] Git transition - how to access private user and vendor branches
On Sun, Jan 12, 2020 at 01:31:13PM +, Iain Sandoe wrote: > Segher Boessenkool wrote: > > 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. That's a weird setting imo. Potentially destroying your own work *is* dangerous :-) Pretty much anything you mess up locally in Git can be easily restored. Restoring remote branches can be much harder. To start with, this requires knowing *what* to restore, which can require direct access to the remote repository, or its backups. So doing an unexpected non-ff push is probably not a good idea. You can also add a "+" manually when you want to overwrite the remote branch, or configure your setup to always do that for certain branches. It all depends on personal preference and work habits, of course. But I think it isn't the best idea to recommend people take up dangerous habits :-) > 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? If you haven't configured push rules for your remote, you get what you have in "push.default" for that remote. Since Git 2.0 the default has been "push.default = simple", and no non-ff pushes are allowed by default anyway? I guess it makes some sense to group together locally the branches you have in users/ on our shared server. But then "me/" is not a great name :-) Segher
Re: [wwwdocs] Git transition - how to access private user and vendor branches
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 +, 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 + + +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/*" + 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. :-) + +git checkout -b ARM/arm-9-branch origin/ARM/arm-9-branch + + +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 + + +git config branch.ARM/arm-9-branch.merge refs/vendors/ARM/heads/arm-9-branch + + +Pull operations will now correctly track the upstream branch. Do you also need to set branch..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 + + +git config --add remote.origin.fetch "+refs/users/my-userid/heads/*:refs/remotes/origin/me/*" + + +then you can also add + +git config --add remote.origin.push "+refs/heads/me/*:refs/users/my-userid/heads/*" + +and then any push from a branch that begins with me/ 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//heads/thing You could do that instead, but then you need a push line for every branch. The me/ 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//heads/* and then use git push origin mybranch I'm unlikely to want to push multiple branches at once. Jason
Re: [wwwdocs] Git transition - how to access private user and vendor branches
Segher Boessenkool wrote: > Hi Richard, > > On Thu, Jan 09, 2020 at 04:50:03PM +, 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 >> + >> + >> +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/*" >> + > > 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 :-) > >> + >> +git checkout -b ARM/arm-9-branch origin/ARM/arm-9-branch >> + >> + >> +then change the merge property for the branch to corectly identify the > > (typo) > >> +upstream source >> + >> + >> +git config branch.ARM/arm-9-branch.merge refs/vendors/ARM/heads/arm-9-branch >> + >> + >> +Pull operations will now correctly track the upstream branch. > > Do you also need to set branch..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 >> + >> + >> +git config --add remote.origin.fetch >> "+refs/users/my-userid/heads/*:refs/remotes/origin/me/*" >> + >> + >> +then you can also add >> + >> +git config --add remote.origin.push >> "+refs/heads/me/*:refs/users/my-userid/heads/*" >> + >> +and then any push from a branch that begins with me/ 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//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
Re: [wwwdocs] Git transition - how to access private user and vendor branches
On 11/01/2020 15:41, Segher Boessenkool wrote: > Hi Richard, > > On Thu, Jan 09, 2020 at 04:50:03PM +, 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 >> + >> + >> +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/*" >> + > > 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. :-) > >> + >> +git checkout -b ARM/arm-9-branch origin/ARM/arm-9-branch >> + >> + >> +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 >> + >> + >> +git config branch.ARM/arm-9-branch.merge refs/vendors/ARM/heads/arm-9-branch >> + >> + >> +Pull operations will now correctly track the upstream branch. > > Do you also need to set branch..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 >> + >> + >> +git config --add remote.origin.fetch >> "+refs/users/my-userid/heads/*:refs/remotes/origin/me/*" >> + >> + >> +then you can also add >> + >> +git config --add remote.origin.push >> "+refs/heads/me/*:refs/users/my-userid/heads/*" >> + >> +and then any push from a branch that begins with me/ 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//heads/thing You could do that instead, but then you need a push line for every branch. The me/ 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.
Re: [wwwdocs] Git transition - how to access private user and vendor branches
Hi Richard, On Thu, Jan 09, 2020 at 04:50:03PM +, 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 > + > + > +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/*" > + 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 :-) > + > +git checkout -b ARM/arm-9-branch origin/ARM/arm-9-branch > + > + > +then change the merge property for the branch to corectly identify the (typo) > +upstream source > + > + > +git config branch.ARM/arm-9-branch.merge refs/vendors/ARM/heads/arm-9-branch > + > + > +Pull operations will now correctly track the upstream branch. Do you also need to set branch..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 > + > + > +git config --add remote.origin.fetch > "+refs/users/my-userid/heads/*:refs/remotes/origin/me/*" > + > + > +then you can also add > + > +git config --add remote.origin.push > "+refs/heads/me/*:refs/users/my-userid/heads/*" > + > +and then any push from a branch that begins with me/ 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//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
Re: [wwwdocs] Git transition - how to access private user and vendor branches
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. Checking in a change Example check-in session Creating and using branches + Private user and Vendor branches TipsTricks around your account @@ -407,6 +408,73 @@ svn cp svn+ssh://username@gcc.gnu.org/svn/gcc/trunk \ do not copy the entire set of ChangeLog entries. Just use something like "Merge from mainline" or similar. + +Private user and vendor branches + +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. + + + Private user branches live +in refs/users/username/heads with tags +in refs/users/username/tags. + Vendor branches live +in refs/vendors/vendor-name/heads with tags +in refs/vendors/vendor-name/tags. + + +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 + + +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/*" + + +this will cause git pull to fetch all the additional +branches and make them available locally +under remotes/origin/IBM and will also add any tags under +the sub-namespace IBM. + +Setting up a tracking branch for one of the upstream vendor branches +is slightly more complicated as git branch +--set-upstream-to 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 +arm-9-branch use something like: + + +git checkout -b ARM/arm-9-branch origin/ARM/arm-9-branch + + +then change the merge property for the branch to corectly identify the +upstream source + + +git config branch.ARM/arm-9-branch.merge refs/vendors/ARM/heads/arm-9-branch +git config branch.ARM/arm-9-branch.remote origin + + +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 + + +git config --add remote.origin.fetch "+refs/users/my-userid/heads/*:refs/remotes/origin/me/*" + + +then you can also add + +git config --add remote.origin.push "+refs/heads/me/*:refs/users/my-userid/heads/*" + +and then any push from a branch that begins with me/ will be pushed to the private area. + TipsTricks around your account
[wwwdocs] Git transition - how to access private user and vendor branches
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. diff --git a/htdocs/svnwrite.html b/htdocs/svnwrite.html index a1346be1..4873991a 100644 --- a/htdocs/svnwrite.html +++ b/htdocs/svnwrite.html @@ -25,6 +25,7 @@ maintainers and significant developers. Checking in a change Example check-in session Creating and using branches + Private user and Vendor branches TipsTricks around your account @@ -407,6 +408,72 @@ svn cp svn+ssh://username@gcc.gnu.org/svn/gcc/trunk \ do not copy the entire set of ChangeLog entries. Just use something like "Merge from mainline" or similar. + +Private user and vendor branches" + +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. + + + Private user branches live +in refs/users/username/heads with tags +in refs/users/username/tags. + Vendor branches live +in refs/vendors/vendor-name/heads with tags +in refs/vendors/vendor-name/tags. + + +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 + + +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/*" + + +this will cause git pull to fetch all the additional +branches and make them available locally +under remotes/origin/IBM and will also add any tags under +the sub-namespace IBM. + +Setting up a tracking branch for one of the upstream vendor branches +is slightly more complicated as git branch +--set-upstream-to 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 +arm-9-branch use something like: + + +git checkout -b ARM/arm-9-branch origin/ARM/arm-9-branch + + +then change the merge property for the branch to corectly identify the +upstream source + + +git config branch.ARM/arm-9-branch.merge refs/vendors/ARM/heads/arm-9-branch + + +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 + + +git config --add remote.origin.fetch "+refs/users/my-userid/heads/*:refs/remotes/origin/me/*" + + +then you can also add + +git config --add remote.origin.push "+refs/heads/me/*:refs/users/my-userid/heads/*" + +and then any push from a branch that begins with me/ will be pushed to the private area. + TipsTricks around your account
