public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Segher Boessenkool <segher@kernel.crashing.org>
To: "Richard Earnshaw (lists)" <Richard.Earnshaw@arm.com>
Cc: "gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>,
	       Joseph Myers <joseph@codesourcery.com>
Subject: Re: [wwwdocs] Git transition - how to access private user and vendor branches
Date: Sat, 11 Jan 2020 15:54:00 -0000	[thread overview]
Message-ID: <20200111154130.GD3191@gate.crashing.org> (raw)
In-Reply-To: <01477bd3-5733-8223-8a38-01fd96fafece@arm.com>

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

  parent reply	other threads:[~2020-01-11 15:41 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-09 16:55 Richard Earnshaw (lists)
2020-01-10 11:08 ` Richard Earnshaw (lists)
2020-01-11 15:54 ` Segher Boessenkool [this message]
2020-01-11 16:35   ` Richard Earnshaw (lists)
2020-01-13  0:38     ` Jason Merrill
2020-01-12 19:02   ` Iain Sandoe
2020-01-13  2:15     ` Segher Boessenkool
2020-01-13  9:04       ` Iain Sandoe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200111154130.GD3191@gate.crashing.org \
    --to=segher@kernel.crashing.org \
    --cc=Richard.Earnshaw@arm.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=joseph@codesourcery.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).