This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: glibc-ports-merge branch available for testing


"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.  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

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

(In Git parlance, a fast-forward merge is a merge of a branch that's a
direct descendent of the branch into which it's being merged, so the
"merge" is done by just applying all the new commits without creating a
new merge commit.)

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]