[wwwdocs] Git transition - how to access private user and vendor branches

[wwwdocs] Git transition - how to access private user and vendor branches

[Richard Earnshaw (lists)]

[-- Attachment #1: Type: text/plain, Size: 316 bytes --]

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.

[-- Attachment #2: www-vendor.patch --]
[-- Type: text/x-patch, Size: 3583 bytes --]

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.</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&amp;Tricks around your account</a></li>
 </ol>
 
@@ -407,6 +408,72 @@ 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
+</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&amp;Tricks around your account</h2>
 

Re: [wwwdocs] Git transition - how to access private user and vendor branches

[Richard Earnshaw (lists)]

[-- Attachment #1: Type: text/plain, Size: 473 bytes --]

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.

[-- Attachment #2: www-vendor.patch --]
[-- Type: text/x-patch, Size: 3631 bytes --]

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&amp;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&amp;Tricks around your account</h2>
 

Re: [wwwdocs] Git transition - how to access private user and vendor branches

[Segher Boessenkool]

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

Re: [wwwdocs] Git transition - how to access private user and vendor branches

[Richard Earnshaw (lists)]

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.

Re: [wwwdocs] Git transition - how to access private user and vendor branches

[Iain Sandoe]

Segher Boessenkool <segher@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

Re: [wwwdocs] Git transition - how to access private user and vendor branches

[Jason Merrill]

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

Re: [wwwdocs] Git transition - how to access private user and vendor branches

[Segher Boessenkool]

On Sun, Jan 12, 2020 at 01:31:13PM +0000, Iain Sandoe wrote:
> Segher Boessenkool <segher@kernel.crashing.org> 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

[Iain Sandoe]

Segher Boessenkool <segher@kernel.crashing.org> wrote:

> On Sun, Jan 12, 2020 at 01:31:13PM +0000, Iain Sandoe wrote:
>> Segher Boessenkool <segher@kernel.crashing.org> 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