glibc-ports-merge branch available for testing

[Thomas Schwinge]

Hi!

On Sun, 01 Jul 2012 10:24:33 -0700, Russ Allbery <rra@stanford.edu> wrote:
> "Joseph S. Myers" <joseph@codesourcery.com> writes:
> > On Sun, 1 Jul 2012, Joseph S. Myers wrote:
> 
> >> I've pushed the glibc-ports-merge branch that has the contents of the
> >> ports repository in the ports/ directory.  Please review this and see
> >> if it is as you expect.

Confirming that the branch/tag is identical to what you get from the
2.16.0 *.xz tarballs from <ftp://ftp.gnu.org/gnu/glibc/>.

> >> There is a tag glibc-2.16-ports-merge at the
> >> tip of the branch; that tip revision is expected to become the tip of
> >> master if the merge is OK.
> 
> > I should add: I believe
> 
> > git push origin glibc-ports-merge:refs/heads/master

Even »git push origin [...]:master« works (I use this all the time), as
there already is a master branch existing, and then Git knows what is
meant.

> > is the right way to make this tagged merge commit appear on master, but 
> > let me know if there's something wrong with that.
> 
> This does an implicit fast-forward merge of your local glibc-ports-merge
> branch to master in the remote repository.  It's okay to do it this way,
> but it's mildly confusing (to me at least).  I would instead do:
> 
>     git checkout master
>     git merge glibc-ports-merge
> 
> locally, ensure that Git says that the merge is a fast-forward merge, and,
> if it does, push your master to the remote repository the way that you
> normally would.

But that's always going to give the exactly same results, in my
understanding?  What distinction are you out for?


Grüße,
 Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20120702/1e90bf08/attachment.sig>