git is live

git is live

[Tom Tromey]

Hi everybody.  Git is now live and the master repository for binutils
and gdb.


Maybe I made some enormous mistake!  While I'd prefer to be finished
with this project, if there is a mistake, please be reassured that we
have not taken any truly irreversible action.  CVS commits are disabled,
but all the data is still there.

I hope you feel reassured now.


Pedro pointed out today that the history of the existing repository is
weird around the point at which the src repository is stitched onto the
older devo repository.  "Weird" here means that there are some commits
that delete nearly everything, only to have it all restored a commit or
two later.  I spent some time trying to fix this; but in fact, far too
much time, and in the end I decided that we will just have to live with
it.


It was pointed out to me on irc that not everybody has already used git.
I'm reliably informed that this is a good git book, and it is available
online:

    http://git-scm.com/book

I'm sure there are others as well.

A couple of small hints.  You will want to set your username and email
address in your git config before pushing your first commit.  I'm sure
the book explains this early on.

I've set things up to reject "non-fast-forward" merge commits to master.
What this means is that if you commit something and try to push, and
then it fails, you will want to "git pull --rebase", or use "git rebase
-i", before trying again.  This is basically analogous to "cvs
update"ing before trying to commit again.


I named the new repository "binutils-gdb".  First, sorry to all who
backed "src".  I was swayed by the hue and cry to choose a URL whose
importance is undeniable despite the second argument to git clone.
Second, gdbers, I chose the name alphabetically.

The URLs:

    git://sourceware.org/git/binutils-gdb.git
    ssh://sourceware.org/git/binutils-gdb.git

I believe only the latter form allows pushing.


Please report any problems to me or to the list.  I'll be around fixing
any problems.  You can also join us on #gdb and ask git questions if you
like.

I still have a few final tasks to do for the transition, but nothing too
pressing.  E.g., I will check in my changes to the gdbadmin scripts
soon, when I'm readier to debug them; but meanwhile they will pull from
CVS without harm.

Tom

Re: git is live

[Andreas Schwab]

Tom Tromey <tromey@redhat.com> writes:

> Maybe I made some enormous mistake!  While I'd prefer to be finished
> with this project, if there is a mistake, please be reassured that we
> have not taken any truly irreversible action.  CVS commits are disabled,
> but all the data is still there.

If we find any mistakes later they could be corrected with replace
objects.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: git is live

[Jonas Maebe]

On 22 Oct 2013, at 09:01, Tom Tromey wrote:

> It was pointed out to me on irc that not everybody has already used git.
> I'm reliably informed that this is a good git book, and it is available
> online:
> 
>    http://git-scm.com/book
> 
> I'm sure there are others as well.

This is a quite good overview in case you're already familiar with svn: http://git.or.cz/course/svn.html


Jonas

Re: git is live

[Christian Groessler]

On 10/22/13 09:01, Tom Tromey wrote:
> The URLs:
>
>      git://sourceware.org/git/binutils-gdb.git
>      ssh://sourceware.org/git/binutils-gdb.git
>
> I believe only the latter form allows pushing.
>

I'm getting

$ git clone ssh://sourceware.org/git/binutils-gdb.git binutils-write
Cloning into 'binutils-write'...
Permission denied (publickey).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.
$


regards,
chris

Re: git is live

[Andreas Schwab]

Christian Groessler <chris@groessler.org> writes:

> $ git clone ssh://sourceware.org/git/binutils-gdb.git binutils-write
> Cloning into 'binutils-write'...
> Permission denied (publickey).

Try ssh sourceware.org alive.  This is an ssh setup problem.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: git is live

[Christian Groessler]

On 10/22/13 10:10, Andreas Schwab wrote:
> Christian Groessler <chris@groessler.org> writes:
>
>> $ git clone ssh://sourceware.org/git/binutils-gdb.git binutils-write
>> Cloning into 'binutils-write'...
>> Permission denied (publickey).
> Try ssh sourceware.org alive.  This is an ssh setup problem.


Oops, yes, sorry. My user name is diffferent on sourceware.org.

regards,
chris

Re: git is live

[Mark Kettenis]

> From: Tom Tromey <tromey@redhat.com>
> Date: Tue, 22 Oct 2013 01:01:40 -0600
> 
> Hi everybody.  Git is now live and the master repository for binutils
> and gdb.

Guess my neighbours will have to deal with significantly more cursing
from now on ;).

> Maybe I made some enormous mistake!  While I'd prefer to be finished
> with this project, if there is a mistake, please be reassured that we
> have not taken any truly irreversible action.  CVS commits are disabled,
> but all the data is still there.

Been travelling and still have a significant mail backlog.  So
apologies if the following question has already been answered.

Can the CVS repository remain online for the foreseeable future?  I
have various cvs trees with uncommitted patches sitting around and
being able to use cvs diff in those trees would help me in carrying
them over into git.

Thanks,

Mark

Re: git is live

[Tom Tromey]

>>>>> "Mark" == Mark Kettenis <mark.kettenis@xs4all.nl> writes:

Mark> Can the CVS repository remain online for the foreseeable future?  I
Mark> have various cvs trees with uncommitted patches sitting around and
Mark> being able to use cvs diff in those trees would help me in carrying
Mark> them over into git.

As far as I'm concerned, it can remain alive forever.
We do have very many cvsweb URLs sitting there in bugzilla.
In any case we certainly cannot decommission CVS until all the other
projects have either migrated off or been declared dead.

Tom

Re: git is live

[Eli Zaretskii]

> Date: Tue, 22 Oct 2013 10:04:22 +0200 (CEST)
> From: Mark Kettenis <mark.kettenis@xs4all.nl>
> CC: gdb@sourceware.org, binutils@sourceware.org
> 
> > From: Tom Tromey <tromey@redhat.com>
> > Date: Tue, 22 Oct 2013 01:01:40 -0600
> > 
> > Hi everybody.  Git is now live and the master repository for binutils
> > and gdb.
> 
> Guess my neighbours will have to deal with significantly more cursing
> from now on ;).

Don't hesitate to ask questions instead.

FWIW (and I know it's not worth too much), I can share a few minor
hints about setting things up (a few aliases, workflow) that make my
life of a very occasional git user much simpler and safer.

Re: git is live

[Richard Sandiford]

Tom Tromey <tromey@redhat.com> writes:
> Hi everybody.  Git is now live and the master repository for binutils
> and gdb.

Many many thanks for doing this.

Richard

Re: git is live

[Fred Cooke]

Tom, although the commits that remove/readd all files are ugly, git is
smart enough to reuse the blobs, so they don't really do any harm. IE,
don't feel too bad about it :-) And thanks! A lot. I'll actually feel
motivated (as opposed to disgusted) to get some contributions in now!
Just need to find the time. I have to. And soon.

On Tue, Oct 22, 2013 at 11:59 AM, Richard Sandiford
<rsandifo@linux.vnet.ibm.com> wrote:
> Tom Tromey <tromey@redhat.com> writes:
>> Hi everybody.  Git is now live and the master repository for binutils
>> and gdb.
>
> Many many thanks for doing this.
>
> Richard
>

Re: git is live

[Tom Tromey]

>>>>> "Fred" == Fred Cooke <fred.cooke@gmail.com> writes:

Fred> Tom, although the commits that remove/readd all files are ugly, git is
Fred> smart enough to reuse the blobs, so they don't really do any harm. IE,
Fred> don't feel too bad about it :-)

The specific problem is that git blame doesn't track through the weird
commits; and I know Pedro does this somewhat more often than other
people, and would have liked to see the real history, instead of having
to manually go back before April 1999.

Fred> And thanks! A lot. I'll actually feel motivated (as opposed to
Fred> disgusted)

I will send you a list of source files not to read :)

Tom

Re: git is live

[Fred Cooke]

Source files can be gradually fixed or improved, CVS is broken for
life ;-) Would appreciate the list, there may be some entertainment in
there :-p

On Tue, Oct 22, 2013 at 5:20 PM, Tom Tromey <tromey@redhat.com> wrote:
>>>>>> "Fred" == Fred Cooke <fred.cooke@gmail.com> writes:
>
> Fred> Tom, although the commits that remove/readd all files are ugly, git is
> Fred> smart enough to reuse the blobs, so they don't really do any harm. IE,
> Fred> don't feel too bad about it :-)
>
> The specific problem is that git blame doesn't track through the weird
> commits; and I know Pedro does this somewhat more often than other
> people, and would have liked to see the real history, instead of having
> to manually go back before April 1999.
>
> Fred> And thanks! A lot. I'll actually feel motivated (as opposed to
> Fred> disgusted)
>
> I will send you a list of source files not to read :)
>
> Tom

Re: git is live

[Pedro Alves]

On 10/22/2013 04:20 PM, Tom Tromey wrote:
>>>>>> "Fred" == Fred Cooke <fred.cooke@gmail.com> writes:
> 
> Fred> Tom, although the commits that remove/readd all files are ugly, git is
> Fred> smart enough to reuse the blobs, so they don't really do any harm. IE,
> Fred> don't feel too bad about it :-)
> 
> The specific problem is that git blame doesn't track through the weird
> commits; and I know Pedro does this somewhat more often than other
> people, and would have liked to see the real history, instead of having
> to manually go back before April 1999.

Yeah.  Oh well, not a show stopper.  Maybe I'll find a way to tell
git to treat a range of commits as a single commit for blame/log
purposes, so that "git blame" punches through that hole.

In any case, I'm deeply, immensely grateful that we've switched away
from CVS.  Many many thanks for doing all this.

-- 
Pedro Alves

Re: git is live

[Jeff Law]

On 10/22/13 11:44, Pedro Alves wrote:
> On 10/22/2013 04:20 PM, Tom Tromey wrote:
>
> In any case, I'm deeply, immensely grateful that we've switched away
> from CVS.  Many many thanks for doing all this.
Likewise.  I don't work on GDB much anymore, but I still occasionally 
find myself inside binutils.  So this change is *much* appreciated.

Now if I could just get GCC to switch from SVN to GIT I could forget 
everything I know about CVS and SVN ;-)

Jeff

Re: git is live

[Tom Tromey]

Jeff> Now if I could just get GCC to switch from SVN to GIT I could forget
Jeff> everything I know about CVS and SVN ;-)

It can't be that hard technically -- there is already a mirror; GCC
doesn't face the various difficulties that "src" did; and you can grab
our commit/bugzilla integration script.  Getting agreement OTOH...

Tom

Re: git is live

[Jeff Law]

On 10/22/13 11:51, Tom Tromey wrote:
> Jeff> Now if I could just get GCC to switch from SVN to GIT I could forget
> Jeff> everything I know about CVS and SVN ;-)
>
> It can't be that hard technically -- there is already a mirror; GCC
> doesn't face the various difficulties that "src" did; and you can grab
> our commit/bugzilla integration script.  Getting agreement OTOH...
It's *far* more of a political exercise than a technical exercise :(

git-svn helps ease the pain, but I'd really prefer move strictly to GIT.

jeff

Re: git is live

[Jan-Benedict Glaw]

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

On Tue, 2013-10-22 11:49:30 -0600, Jeff Law <law@redhat.com> wrote:
> Now if I could just get GCC to switch from SVN to GIT I could forget
> everything I know about CVS and SVN ;-)

Based on the GCC GIT mirror, it's quite simple to integrate the SVN
server back into that git repo (to be able to use git-svn):

	http://gcc.gnu.org/wiki/GitMirror

A must-read for everybody who wants to forget about SVN details :)

MfG, JBG

-- 
      Jan-Benedict Glaw      jbglaw@lug-owl.de              +49-172-7608481
Signature of:              Alles sollte so einfach wie möglich gemacht sein.
the second  :                          Aber nicht einfacher.  (Einstein)

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: git is live

[Andreas Schwab]

Pedro Alves <palves@redhat.com> writes:

> Yeah.  Oh well, not a show stopper.  Maybe I'll find a way to tell
> git to treat a range of commits as a single commit for blame/log
> purposes, so that "git blame" punches through that hole.

You can do that with grafts or replace objects (which can change your
view of the commit graph by pretending that a commit has a different
parent).

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: git is live

[Eli Zaretskii]

> From: Richard Sandiford <rsandifo@linux.vnet.ibm.com>
> Cc: GDB Development <gdb@sourceware.org>,        Binutils Development <binutils@sourceware.org>
> Date: Tue, 22 Oct 2013 10:59:04 +0100
> 
> Tom Tromey <tromey@redhat.com> writes:
> > Hi everybody.  Git is now live and the master repository for binutils
> > and gdb.
> 
> Many many thanks for doing this.

Seconded.

Re: git is live

[Jan-Benedict Glaw]

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

On Tue, 2013-10-22 10:59:04 +0100, Richard Sandiford <rsandifo@linux.vnet.ibm.com> wrote:
> Tom Tromey <tromey@redhat.com> writes:
> > Hi everybody.  Git is now live and the master repository for binutils
> > and gdb.
> 
> Many many thanks for doing this.

Full ACK!

Git makes things way easier to work with. My own helper scripts are
already changed; and I'm, too, rolling out the change to the build
robot slaves one-by-one. (Don't want to hit the GIT server too hard.)

Thanks A LOT!

MfG, JBG

-- 
      Jan-Benedict Glaw      jbglaw@lug-owl.de              +49-172-7608481
 Signature of:                    Don't believe in miracles: Rely on them!
 the second  :

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: git is live

[Cary Coutant]

> The URLs:
>
>     git://sourceware.org/git/binutils-gdb.git
>     ssh://sourceware.org/git/binutils-gdb.git

Thanks, Tom!

Does anyone know if it's possible to switch my existing git repos
(cloned from the old mirror at sourceware.org/git/binutils) to the new
one? Or is it best to clone from scratch?

-cary

Re: git is live

[Pedro Alves]

On 10/22/2013 07:41 PM, Cary Coutant wrote:
>> The URLs:
>>
>>     git://sourceware.org/git/binutils-gdb.git
>>     ssh://sourceware.org/git/binutils-gdb.git
> 
> Thanks, Tom!
> 
> Does anyone know if it's possible to switch my existing git repos
> (cloned from the old mirror at sourceware.org/git/binutils) to the new
> one? Or is it best to clone from scratch?

What I did was first was:

  git add remote binutils-gdb ssh://sourceware.org/git/binutils-gdb.git

and then:

  git fetch binutils-gdb

But, git appeared to hang, making no progress.  It wouldn't even
start fetching.  stracing git, it looked like git was checking
if the existing remotes and the new remote share ancestry/commits,
a commit/rountrip at a time.  That'd take forever.  So what I
did next was:

Created a fresh clone from scratch:

  $ mkdir binutils-gdb
  $ cd binutils-gdb
  $ git clone ssh://sourceware.org/git/binutils-gdb.git src

Then I went back to my old git repo checkout, and added a
remote pointing to the new local checkout:

  $ cd ../../my-old-git-repos-checkout-dir/src
  $ git remote add binutils-gdb /local/path/to/fresh/binutils-gdb/src
  $ git fetch binutils-gdb

Now the same "does the new remote share commits/ancentry"
process ended in seconds, because it was all local, and git
started fetching the new repo/remote in a matter of seconds.

So now I did:

  $ git remote set-url binutils-gdb ssh://sourceware.org/git/binutils-gdb.git

to reset the remote url back to the real remote url, rather than
the temporary clone directory.

Voila.  Then I did:

  $ git fetch binutils-gdb

once more, and that worked as expected.

From there on, I've just been switching to by local
branches that were based on the old git mirror, and rebased
them on top of binutils-gdb/master.

I then renamed my "upstream" remote to "old-cvs-mirror",
and my "binutils-gdb" remote to "upstream".  :-)

Dunno if there's an easier way, but that worked nicely
for me, and it only took a few minutes.

-- 
Pedro Alves

Re: git is live

[Tom Tromey]

Pedro> Dunno if there's an easier way, but that worked nicely
Pedro> for me, and it only took a few minutes.

What I've been doing is:

In my old gdb.git, look at a branch I want to preserve.
Find the branchpoint of the branch.
Then, find the corresponding commit in the new repository and make a
branch rooted there.  Check out this branch.

In the old repository:

    git format-patch -k --stdout BRANCH-POINT..BRANCH-NAME > /tmp/P

In the new repository:

    git am -k < /tmp/P

Then I push the new branch to my gitorious repository.

So far that's worked quite nicely.

Tom

Re: git is live

[Cary Coutant]

> Created a fresh clone from scratch:
>
>   $ mkdir binutils-gdb
>   $ cd binutils-gdb
>   $ git clone ssh://sourceware.org/git/binutils-gdb.git src
>
> Then I went back to my old git repo checkout, and added a
> remote pointing to the new local checkout:
>
>   $ cd ../../my-old-git-repos-checkout-dir/src
>   $ git remote add binutils-gdb /local/path/to/fresh/binutils-gdb/src
>   $ git fetch binutils-gdb
>
> Now the same "does the new remote share commits/ancentry"
> process ended in seconds, because it was all local, and git
> started fetching the new repo/remote in a matter of seconds.
>
> So now I did:
>
>   $ git remote set-url binutils-gdb ssh://sourceware.org/git/binutils-gdb.git
>
> to reset the remote url back to the real remote url, rather than
> the temporary clone directory.
>
> Voila.  Then I did:
>
>   $ git fetch binutils-gdb
>
> once more, and that worked as expected.
>
> From there on, I've just been switching to by local
> branches that were based on the old git mirror, and rebased
> them on top of binutils-gdb/master.

I got this far with no problems (thanks!), but my old branches don't
seem to have any common commits with the new binutils-gdb/master. Are
you doing the rebase with an explicit merge-base (e.g., "git branch
new-branch binutils-gdb/master;  git rebase --onto new-branch
old-master old-branch")? Or should "git rebase binutils-gdb/master
old-branch" work? (I'm hesitant to try that.)

-cary

Re: git is live

[asmwarrior]

On 2013-10-29 6:35, Cary Coutant wrote:
> with an explicit merge-base (e.g., "git branch
> new-branch binutils-gdb/master;  git rebase --onto new-branch
> old-master old-branch")? Or should "git rebase binutils-gdb/master
> old-branch" work? (I'm hesitant to try that.)
I suggest you read the two post:
New git repository coming - https://sourceware.org/ml/gdb/2013-10/msg00145.html
git switchover complete - https://sourceware.org/ml/gdb/2013-10/msg00150.html
So, a refresh new clone is necessary.

Yuanhui Zhang

Re: git is live

[Tom Tromey]

Cary> I got this far with no problems (thanks!), but my old branches don't
Cary> seem to have any common commits with the new binutils-gdb/master. Are
Cary> you doing the rebase with an explicit merge-base (e.g., "git branch
Cary> new-branch binutils-gdb/master;  git rebase --onto new-branch
Cary> old-master old-branch")? Or should "git rebase binutils-gdb/master
Cary> old-branch" work? (I'm hesitant to try that.)

You want git rebase --onto.

I did it using "git format-patch" followed by "git am" the first time.
The second time I did Pedro's approach and used "git rebase --onto".
Both of these worked great, though some manual labor is needed.
(Actually the second time I wrote a script to automate it: using git
merge-base to find the root of a branch and then looking up the
corresponding commit in the new tree -- but for reasons I don't know it
only worked for about half of my branches.)

Tom

Re: git is live

[Cary Coutant]

> You want git rebase --onto.
>
> I did it using "git format-patch" followed by "git am" the first time.
> The second time I did Pedro's approach and used "git rebase --onto".
> Both of these worked great, though some manual labor is needed.
> (Actually the second time I wrote a script to automate it: using git
> merge-base to find the root of a branch and then looking up the
> corresponding commit in the new tree -- but for reasons I don't know it
> only worked for about half of my branches.)

Yeah, I tried rebase --onto for one branch, and format-patch for
another. Both worked fine, but the fetch-and-rebase approach imports a
whole commit history dating back to the beginning of time into the new
repo. It seems like it'll be easier to make sure I don't leak old
commit history from the old repo into the new one with format-patch.
I'm not sure how much I've bloated my repo just from fetching the one
branch -- presumably it's not a lot, since the content store is based
on hashes, but I might reclone and compare sizes just to see. (Maybe a
git gc will clean things up, too.)

-cary

Re: git is live

[Pedro Alves]

On 10/29/2013 06:12 PM, Cary Coutant wrote:

> I'm not sure how much I've bloated my repo just from fetching the one
> branch -- presumably it's not a lot, since the content store is based
> on hashes, but I might reclone and compare sizes just to see.

...

> (Maybe a > git gc will clean things up, too.)

That's my expectation.

Note you can list branches you might have still based on the
old git cvs mirror repo with e.g.,:

$ git branch --contains 14cd51f7793a9ce07bc435069f57269450141363

That's the hash of the initial commit in the old git cvs mirror.

(myself, I've put that in a 'git-gdb-old-branches' script for
convenience.)

Do:

$ git branch -a --contains 14cd51f7793a9ce07bc435069f57269450141363

to include remote branches in the query.

Once that gives the empty set, garbage collection should
be able to shrink your repo.

I have remotes pointing to other people's random repos based
off the git/cvs mirror out there, so I expect it'll be a
long while before that'll ever happen for me.  But I'm really
not worried about that myself.

-- 
Pedro Alves

Re: git is live

[Tom Tromey]

Cary> (Maybe a > git gc will clean things up, too.)

Pedro> That's my expectation.

It will but you will have to clear the reflog first for best results.
When doing the grafting stuff I did:

    git reflog expire --expire=now --all
    git gc --prune=now --aggressive

--aggressive takes a lot of time though.

What I did is make a combined repository for the rebasing.  Then I
pushed everything, cloned a new repository and fetched from my gitorious
repository, and finally deleted my combined repository.

Tom

Re: git is live

[Yao Qi]

On 10/29/2013 06:35 AM, Cary Coutant wrote:
> I got this far with no problems (thanks!), but my old branches don't
> seem to have any common commits with the new binutils-gdb/master. Are
> you doing the rebase with an explicit merge-base (e.g., "git branch
> new-branch binutils-gdb/master;  git rebase --onto new-branch
> old-master old-branch")? Or should "git rebase binutils-gdb/master
> old-branch" work? (I'm hesitant to try that.)

'git rebase --onto new-branch BRANCH_POINT old-branch' works for me. 
BRANCH_POINT is the commit id of master that your old-branch is created 
against.

I switched my origin to the new repo, and do 'git rebase --onto master 
BRANCH_POINT old-branch' for my every local branch, but have to check 
BRANCH_POINT manually for every local branch.

-- 
Yao (齐尧)

Re: git is live

[Pedro Alves]

On 10/28/2013 10:35 PM, Cary Coutant wrote:

> I got this far with no problems (thanks!), but my old branches don't
> seem to have any common commits with the new binutils-gdb/master. Are
> you doing the rebase with an explicit merge-base (e.g., "git branch
> new-branch binutils-gdb/master;  git rebase --onto new-branch
> old-master old-branch")? Or should "git rebase binutils-gdb/master
> old-branch" work? (I'm hesitant to try that.)

Yeah, as others have said, use "git rebase --onto new-branch".

I actually use stgit myself, so I do "stg rebase $BRANCH", which
rebases the patch series (applied or not) on top of any
branch (IOW, it already does the equivalent of --onto) so
this question doesn't even arise for me.

-- 
Pedro Alves

Re: git is live

[Andrew Pinski]

On Tue, Oct 22, 2013 at 12:01 AM, Tom Tromey <tromey@redhat.com> wrote:
> Hi everybody.  Git is now live and the master repository for binutils
> and gdb.
>
>
> Maybe I made some enormous mistake!  While I'd prefer to be finished
> with this project, if there is a mistake, please be reassured that we
> have not taken any truly irreversible action.  CVS commits are disabled,
> but all the data is still there.
>
> I hope you feel reassured now.
>
>
> Pedro pointed out today that the history of the existing repository is
> weird around the point at which the src repository is stitched onto the
> older devo repository.  "Weird" here means that there are some commits
> that delete nearly everything, only to have it all restored a commit or
> two later.  I spent some time trying to fix this; but in fact, far too
> much time, and in the end I decided that we will just have to live with
> it.
>
>
> It was pointed out to me on irc that not everybody has already used git.
> I'm reliably informed that this is a good git book, and it is available
> online:
>
>     http://git-scm.com/book
>
> I'm sure there are others as well.
>
> A couple of small hints.  You will want to set your username and email
> address in your git config before pushing your first commit.  I'm sure
> the book explains this early on.
>
> I've set things up to reject "non-fast-forward" merge commits to master.
> What this means is that if you commit something and try to push, and
> then it fails, you will want to "git pull --rebase", or use "git rebase
> -i", before trying again.  This is basically analogous to "cvs
> update"ing before trying to commit again.
>
>
> I named the new repository "binutils-gdb".  First, sorry to all who
> backed "src".  I was swayed by the hue and cry to choose a URL whose
> importance is undeniable despite the second argument to git clone.
> Second, gdbers, I chose the name alphabetically.
>
> The URLs:
>
>     git://sourceware.org/git/binutils-gdb.git
>     ssh://sourceware.org/git/binutils-gdb.git
>
> I believe only the latter form allows pushing.
>
>
> Please report any problems to me or to the list.  I'll be around fixing
> any problems.  You can also join us on #gdb and ask git questions if you
> like.

It is not listed on https://sourceware.org/git/ page.

Thanks,
Andrew Pinski

>
> I still have a few final tasks to do for the transition, but nothing too
> pressing.  E.g., I will check in my changes to the gdbadmin scripts
> soon, when I'm readier to debug them; but meanwhile they will pull from
> CVS without harm.
>
> Tom

Re: git is live

[Tom Tromey]

Andrew> It is not listed on https://sourceware.org/git/ page.

Frank fixed this.

Tom

Re: git is live

[DJ Delorie]

Tom Tromey <tromey@redhat.com> writes:
> CVS commits are disabled, but all the data is still there.

Note that this has broken my robo-merge scripts for libiberty.  I hope
that cvs's libiberty/ and include/ can be re-enabled, assuming there are
other users of libiberty left in src.

Either way, my robo-merge scripts do not support git and I have no plans
on migrating them (/me dislikes git).  I've given Tom copies (at his
request) so he can adapt them to the new repo.

Re: git is live

[Tom Tromey]

>>>>> "DJ" == DJ Delorie <dj@redhat.com> writes:

DJ> Tom Tromey <tromey@redhat.com> writes:
>> CVS commits are disabled, but all the data is still there.

DJ> Note that this has broken my robo-merge scripts for libiberty.  I hope
DJ> that cvs's libiberty/ and include/ can be re-enabled, assuming there are
DJ> other users of libiberty left in src.

Sure, I'll fix that tomorrow.

DJ> Either way, my robo-merge scripts do not support git and I have no plans
DJ> on migrating them (/me dislikes git).  I've given Tom copies (at his
DJ> request) so he can adapt them to the new repo.

Coming soon.

Tom

Re: git is live

[Fred Cooke]

Tom is there an official Binutils/GDB or even GNU Github account? I
believe you can setup auto mirrors there, or at least special mirrors.
That'd be a nice way to take the load off of sourceware and get an
auto backup :-) Of course, everyone has a backup now, so the chances
of losing everything are zero :-)

On Tue, Oct 22, 2013 at 10:42 PM, Tom Tromey <tromey@redhat.com> wrote:
>>>>>> "DJ" == DJ Delorie <dj@redhat.com> writes:
>
> DJ> Tom Tromey <tromey@redhat.com> writes:
>>> CVS commits are disabled, but all the data is still there.
>
> DJ> Note that this has broken my robo-merge scripts for libiberty.  I hope
> DJ> that cvs's libiberty/ and include/ can be re-enabled, assuming there are
> DJ> other users of libiberty left in src.
>
> Sure, I'll fix that tomorrow.
>
> DJ> Either way, my robo-merge scripts do not support git and I have no plans
> DJ> on migrating them (/me dislikes git).  I've given Tom copies (at his
> DJ> request) so he can adapt them to the new repo.
>
> Coming soon.
>
> Tom

Re: git is live

[Tom Tromey]

>>>>> "Fred" == Fred Cooke <fred.cooke@gmail.com> writes:

Fred> Tom is there an official Binutils/GDB or even GNU Github account?

Not that I know of.

Fred> I believe you can setup auto mirrors there, or at least special
Fred> mirrors.

If someone wants to manage that, it is fine by me.

Tom

Re: git is live

[Fred Cooke]

I just had a quick poke around, you have to ask github staff to set it
up, and it has to be someone official asking. That ain't me :-) gcc
has one, one of the most popular, actually, someone involved with it
will know, perhaps they're watching this thread?

https://github.com/mirrors

On Tue, Oct 22, 2013 at 10:50 PM, Tom Tromey <tromey@redhat.com> wrote:
>>>>>> "Fred" == Fred Cooke <fred.cooke@gmail.com> writes:
>
> Fred> Tom is there an official Binutils/GDB or even GNU Github account?
>
> Not that I know of.
>
> Fred> I believe you can setup auto mirrors there, or at least special
> Fred> mirrors.
>
> If someone wants to manage that, it is fine by me.
>
> Tom

Re: git is live

[Sergio Durigan Junior]

On Tuesday, October 22 2013, Fred Cooke wrote:

> Tom is there an official Binutils/GDB or even GNU Github account? I
> believe you can setup auto mirrors there, or at least special mirrors.
> That'd be a nice way to take the load off of sourceware and get an
> auto backup :-) Of course, everyone has a backup now, so the chances
> of losing everything are zero :-)

I keep a mirror at Gitorious.  It is not official, and it is at
Gitorious because of the many issues regarding Github and proprietary
things.  The mirror is:

<https://gitorious.org/gdb>

It is still tracking the old gdb.git repo, but I plan to update it when
I have time.

-- 
Sergio

Re: git is live

[Tom Tromey]

DJ> Note that this has broken my robo-merge scripts for libiberty.  I hope
DJ> that cvs's libiberty/ and include/ can be re-enabled, assuming there are
DJ> other users of libiberty left in src.

I fixed this.  I believe only 'include' was disabled.  'libiberty' isn't
(and apparently never was) mentioned in the commitinfo file.

Tom

Re: git is live

[DJ Delorie]

Thanks!

Re: git is live

[John Darrington]

On Tue, Oct 22, 2013 at 01:01:40AM -0600, Tom Tromey wrote:
     Hi everybody.  Git is now live and the master repository for binutils
     and gdb.


Can you then please update the information at http://www.gnu.org/software/binutils/
Otherwise nobody will ever know.

Thanks.


J'

-- 
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.

Re: git is live

[Tom Tromey]

>>>>> "John" == John Darrington <john@darrington.wattle.id.au> writes:

John> Can you then please update the information at
John> http://www.gnu.org/software/binutils/
John> Otherwise nobody will ever know.

I updated http://sourceware.org/binutils/.
I don't have access to update the GNU page.

Tom

Re: git is live

[John Darrington]

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

On Wed, Oct 23, 2013 at 07:13:55AM -0600, Tom Tromey wrote:
     >>>>> "John" == John Darrington <john@darrington.wattle.id.au> writes:
     
     John> Can you then please update the information at
     John> http://www.gnu.org/software/binutils/
     John> Otherwise nobody will ever know.
     
     I don't have access to update the GNU page.
     
     Tom

I contacted the GNU webmasters about this.  They 
said "We update these pages on request from the developers".
Could you then please make such a request to them?

It might also be a good idea to suggest a better system than this.
Most GNU projects update their own pages rather than request the
webmasters every time they need something changed.  I'm sure if
you asked them they would give you access.

Thanks

John



-- 
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: git is live

[Andreas Schwab]

John Darrington <john@darrington.wattle.id.au> writes:

> It might also be a good idea to suggest a better system than this.
> Most GNU projects update their own pages rather than request the
> webmasters every time they need something changed.  I'm sure if
> you asked them they would give you access.

AFAIK the gnu.org webpages are hosted in the savannah binutils project.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: git is live

[Paul Smith]

On Thu, 2013-10-24 at 09:30 +0200, Andreas Schwab wrote:
> John Darrington <john@darrington.wattle.id.au> writes:
> 
> > It might also be a good idea to suggest a better system than this.
> > Most GNU projects update their own pages rather than request the
> > webmasters every time they need something changed.  I'm sure if
> > you asked them they would give you access.
> 
> AFAIK the gnu.org webpages are hosted in the savannah binutils project.

FYI the way the GNU project web pages work is that there's a separate
web CVS repository on Savannah for each project (binutils has one and
GDB has one) containing the content of the project directory, including
index.html, the manual, etc.

Anyone with proper SSH keys registered with the Savannah project to
commit to that CVS repository can update the web pages.  You just check
out a copy of the pages, change them, and "cvs commit" and the web site
is automatically updated.

Re: git is live

[Joel Brobecker]

> I contacted the GNU webmasters about this.  They 
> said "We update these pages on request from the developers".
> Could you then please make such a request to them?
> 
> It might also be a good idea to suggest a better system than this.
> Most GNU projects update their own pages rather than request the
> webmasters every time they need something changed.  I'm sure if
> you asked them they would give you access.

I agree that it's not ideal to ask the GNU webmaster team to update
the page. It would seam a little incredible to me that nobody from
the binutils team would have enough credentials to make the update.
Is that true?

-- 
Joel

Re: git is live

[Tom Tromey]

Joel> I agree that it's not ideal to ask the GNU webmaster team to update
Joel> the page. It would seam a little incredible to me that nobody from
Joel> the binutils team would have enough credentials to make the update.
Joel> Is that true?

According to savannah, the gdb list is:

Project Member	Elfyn McBratney <beu> 	Set to private
Project Administrator	Joel Brobecker <brobecke> 	Set to private
Project Administrator	Eli Zaretskii <eliz> 	View Skills
Project Administrator	Jan Kratochvil <lace> 	Set to private
Project Administrator	Pedro Alves <palves> 	Set to private


And the binutils list is:

Project Administrator	Daniel Jacobowitz <drow> 	Set to private
Project Member	Nick Clifton <nickclifton> 	Set to private
Project Member	Tristan Gingold <tgingold> 	Set to private


If nobody on these lists wants to do it, let me know and I will apply to
get the needed savannah permissions myself.

Tom

Re: git is live

[Tristan Gingold]

On Oct 24, 2013, at 3:52 PM, Tom Tromey <tromey@redhat.com> wrote:

> Joel> I agree that it's not ideal to ask the GNU webmaster team to update
> Joel> the page. It would seam a little incredible to me that nobody from
> Joel> the binutils team would have enough credentials to make the update.
> Joel> Is that true?
> 
> According to savannah, the gdb list is:
> 
> Project Member	Elfyn McBratney <beu> 	Set to private
> Project Administrator	Joel Brobecker <brobecke> 	Set to private
> Project Administrator	Eli Zaretskii <eliz> 	View Skills
> Project Administrator	Jan Kratochvil <lace> 	Set to private
> Project Administrator	Pedro Alves <palves> 	Set to private
> 
> 
> And the binutils list is:
> 
> Project Administrator	Daniel Jacobowitz <drow> 	Set to private
> Project Member	Nick Clifton <nickclifton> 	Set to private
> Project Member	Tristan Gingold <tgingold> 	Set to private
> 
> 
> If nobody on these lists wants to do it, let me know and I will apply to
> get the needed savannah permissions myself.

I will do it for binutils.

> 
> Tom

Re: git is live

[Tristan Gingold]

On Oct 24, 2013, at 4:05 PM, Tristan Gingold <gingold@adacore.com> wrote:

> 
> On Oct 24, 2013, at 3:52 PM, Tom Tromey <tromey@redhat.com> wrote:
> 
>> Joel> I agree that it's not ideal to ask the GNU webmaster team to update
>> Joel> the page. It would seam a little incredible to me that nobody from
>> Joel> the binutils team would have enough credentials to make the update.
>> Joel> Is that true?
>> 
>> According to savannah, the gdb list is:
>> 
>> Project Member	Elfyn McBratney <beu> 	Set to private
>> Project Administrator	Joel Brobecker <brobecke> 	Set to private
>> Project Administrator	Eli Zaretskii <eliz> 	View Skills
>> Project Administrator	Jan Kratochvil <lace> 	Set to private
>> Project Administrator	Pedro Alves <palves> 	Set to private
>> 
>> 
>> And the binutils list is:
>> 
>> Project Administrator	Daniel Jacobowitz <drow> 	Set to private
>> Project Member	Nick Clifton <nickclifton> 	Set to private
>> Project Member	Tristan Gingold <tgingold> 	Set to private
>> 
>> 
>> If nobody on these lists wants to do it, let me know and I will apply to
>> get the needed savannah permissions myself.
> 
> I will do it for binutils.

Done.

Re: git is live

[Joel Brobecker]

> >> If nobody on these lists wants to do it, let me know and I will apply to
> >> get the needed savannah permissions myself.
> > 
> > I will do it for binutils.

And just to be clear - it was my understanding from the initial email
that the work needed was on the binutils side only. But I am otherwise
available to do any necessary updates!

-- 
Joel

Re: git is live

[Tom Tromey]

>>>>> "Joel" == Joel Brobecker <brobecker@adacore.com> writes:

>> >> If nobody on these lists wants to do it, let me know and I will apply to
>> >> get the needed savannah permissions myself.
>> > 
>> > I will do it for binutils.

Joel> And just to be clear - it was my understanding from the initial email
Joel> that the work needed was on the binutils side only. But I am otherwise
Joel> available to do any necessary updates!

I committed to the sourceware htdocs for gdb.
I don't have access to the savannah bits.
So I think it is still needed there.

Tom

Re: git is live

[Joel Brobecker]

> Joel> And just to be clear - it was my understanding from the initial email
> Joel> that the work needed was on the binutils side only. But I am otherwise
> Joel> available to do any necessary updates!
> 
> I committed to the sourceware htdocs for gdb.
> I don't have access to the savannah bits.
> So I think it is still needed there.

Ah yes, of course! OK, patch pushed to savannah as well (thank you,
git cvsimport, git cvsexport :-) ).

It'd be nice if we could switch those to git too. I will look into
that after the release.

-- 
Joel

Re: git is live

[Fred Cooke]

"It'd be nice if we could switch those to git too. I will look into
that after the release."

I was thinking the same thing, but it took immense self control not to
say anything. Glad you did :-)

On Thu, Oct 24, 2013 at 7:52 PM, Joel Brobecker <brobecker@adacore.com> wrote:
>> Joel> And just to be clear - it was my understanding from the initial email
>> Joel> that the work needed was on the binutils side only. But I am otherwise
>> Joel> available to do any necessary updates!
>>
>> I committed to the sourceware htdocs for gdb.
>> I don't have access to the savannah bits.
>> So I think it is still needed there.
>
> Ah yes, of course! OK, patch pushed to savannah as well (thank you,
> git cvsimport, git cvsexport :-) ).
>
> It'd be nice if we could switch those to git too. I will look into
> that after the release.
>
> --
> Joel

Re: git is live

[Paul Smith]

On Fri, 2013-10-25 at 05:07 +0200, Fred Cooke wrote:
> "It'd be nice if we could switch those to git too. I will look into
> that after the release."
> 
> I was thinking the same thing, but it took immense self control not to
> say anything. Glad you did :-)

Assuming you're talking about the web site CVS archives on Savannah,
this issue is raised about every month or so on the GNU lists.  It
always ends the same way (so far): the infrastructure in Savannah and
the FSF servers (which are not at all tightly coupled and are managed by
completely different groups of people, IIUC) for automatic update of the
web site is built completely around CVS and CVS triggers.  There is
little interest on either side in trying to support multiple SCM systems
for managing the web pages, for the limited amount of added benefit (the
web pages are not updated very often so it's not seen as a big problem).

Changing this behavior would involve a lot of coordination between the
different teams, and any attempt to support Git would also mean people
using Mercurial, Bazaar, etc. on Savannah would want to have their
systems supported, etc.  Anyway, that's been the feeling up until this
point.

On the other hand I'm sure many projects would be happy if you succeeded
in getting Git support for the web pages!

Re: git is live

[Joel Brobecker]

> Assuming you're talking about the web site CVS archives on Savannah,
> this issue is raised about every month or so on the GNU lists.  It
> always ends the same way (so far):
[...]

That solves that half of the discussion :). Thanks for the summary.

We probably stand a better chance to at least transition the
sourceware.org side. Even if savannah remains with CVS, which
sounds reasonable based on your summary, we'd still gain a little
bit, as it would simplify my procedure for pushing/mirroring
other people's updates from sourceware to savannah. This is
because I use "git cvsimport" to import other people's changes
into my git mirror, in order to be able to "cvsexportcommit" it
to savannah. That step, for some reason, has always been
temperamental, probably because I've never taken the time
necessary to really make it work for incremental updates
mixed with my own.

-- 
Joel

Re: git is live

[John Darrington]

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

On Fri, Oct 25, 2013 at 04:38:48PM +0400, Joel Brobecker wrote:
     > Assuming you're talking about the web site CVS archives on Savannah,
     > this issue is raised about every month or so on the GNU lists.  It
     > always ends the same way (so far):
     [...]
     
     That solves that half of the discussion :). Thanks for the summary.
     
     We probably stand a better chance to at least transition the
     sourceware.org side. Even if savannah remains with CVS, which
     sounds reasonable based on your summary, we'd still gain a little
     bit, as it would simplify my procedure for pushing/mirroring
     other people's updates from sourceware to savannah. This is
     because I use "git cvsimport" to import other people's changes
     into my git mirror, in order to be able to "cvsexportcommit" it
     to savannah. That step, for some reason, has always been
     temperamental, probably because I've never taken the time
     necessary to really make it work for incremental updates
     mixed with my own.
     

Why have two different web sites?  Have one as the canonical site, and make the other
redirect to it.

J'

-- 
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

web sites (was: Re: git is live)

[Paul Smith]

On Fri, 2013-10-25 at 19:25 +0200, John Darrington wrote:
> Why have two different web sites?  Have one as the canonical site, and
> make the other redirect to it.

The GNU project definitely will want to preserve the gnu.org page: they
prefer to have www.gnu.org/software/<pkg>/ resolve to something
appropriate.  It could be just an overview and point to the other site
for details, I guess: I'm not sure what the politics are there.  I'm not
sure what the history is behind the other site so I can't speak to that.


One note: the gnu.org site would be a lot nicer if it used the standard
template HTML.  Compare, for example:

http://www.gnu.org/software/make/
  vs.
http://www.gnu.org/software/gdb/

Ditto for binutils.  In addition to the standard look and feel stuff, it
uses SSI to allow changing of banners for announcements etc.

It turns out to be quite simple to make your GNU site match the rest.
You can get this via CVS:

cvs -d :pserver:anonymous@cvs.sv.gnu.org:/web/www co www/server/standards

then look at the boilerplate.html file and replace the appropriate bits
with info on your project (there are good directions embedded in
comments in the HTML file), then replace your project's web CVS
index.html with the result.

For the second and subsequent times where you want to update your
project's page, you can use the patch-from-parent script (also available
at the above site).  Or do it by hand; it's usually not a big deal.

Re: git is live

[Gary Benson]

Tom Tromey wrote:
> Hi everybody.  Git is now live and the master repository for
> binutils and gdb.

This is awesome, thanks for doing it!

Gary

-- 
http://gbenson.net/

Re: git is live

[Peter Bergner]

On Tue, 2013-10-22 at 01:01 -0600, Tom Tromey wrote:
> The URLs:
> 
>     git://sourceware.org/git/binutils-gdb.git
>     ssh://sourceware.org/git/binutils-gdb.git

Ok, it's probably getting old, but I'll add my thanks
for switching us over.  Now to my question...

From a policy standpoint, are we going to allow vendor branches
in the git repo like glibc does?  I'm hoping the answer is yes. :)
We didn't allow it before due to it seems CVS issues, but with git,
it should now be easy.

Peter

Re: git is live

[Ian Lance Taylor]

On Fri, Oct 25, 2013 at 6:51 AM, Peter Bergner <bergner@vnet.ibm.com> wrote:
> On Tue, 2013-10-22 at 01:01 -0600, Tom Tromey wrote:
>> The URLs:
>>
>>     git://sourceware.org/git/binutils-gdb.git
>>     ssh://sourceware.org/git/binutils-gdb.git
>
> Ok, it's probably getting old, but I'll add my thanks
> for switching us over.  Now to my question...
>
> >From a policy standpoint, are we going to allow vendor branches
> in the git repo like glibc does?  I'm hoping the answer is yes. :)
> We didn't allow it before due to it seems CVS issues, but with git,
> it should now be easy.

GCC has always allowed vendor branches.  I don't see any reason that
binutils/gdb should prohibit them.  Obviously all the code has to be
under the GPL or some other explicitly permitted license.

Ian

Re: git is live

[Richard Earnshaw]

On 25/10/13 14:55, Ian Lance Taylor wrote:
> On Fri, Oct 25, 2013 at 6:51 AM, Peter Bergner <bergner@vnet.ibm.com> wrote:
>> On Tue, 2013-10-22 at 01:01 -0600, Tom Tromey wrote:
>>> The URLs:
>>>
>>>     git://sourceware.org/git/binutils-gdb.git
>>>     ssh://sourceware.org/git/binutils-gdb.git
>>
>> Ok, it's probably getting old, but I'll add my thanks
>> for switching us over.  Now to my question...
>>
>> >From a policy standpoint, are we going to allow vendor branches
>> in the git repo like glibc does?  I'm hoping the answer is yes. :)
>> We didn't allow it before due to it seems CVS issues, but with git,
>> it should now be easy.
> 
> GCC has always allowed vendor branches.  I don't see any reason that
> binutils/gdb should prohibit them.  Obviously all the code has to be
> under the GPL or some other explicitly permitted license.

I believe the GCC policy is that the code must also be assigned to the
FSF, just as it would be for trunk.

R.

Re: git is live

[Joel Brobecker]

> > GCC has always allowed vendor branches.  I don't see any reason that
> > binutils/gdb should prohibit them.  Obviously all the code has to be
> > under the GPL or some other explicitly permitted license.
> 
> I believe the GCC policy is that the code must also be assigned to the
> FSF, just as it would be for trunk.

Outside of the policy, I am starting to rethink the policy of
allowing vendor branches. For centralized version control systems
such as SVN, it makes sense, because there is no other choice.

But for decentralized systems such as git, I think vendor branches
could be just as easily hosted elsewhere.  With git, it's really easy
for anyone to host it somewhere, and publish its location. It's also
equally easy for anyone interested in the work to add that location
a remote, and fetch from it.

We could allow exceptions on a case-by-case basis; for instance
we'd allow it if some contributor was constrained by his employer.

But otherwise, everyone who uses the default "fetch" ends up
fetching everything, including vendor branches that they are
not interested in.

-- 
Joel

Re: git is live

[Eli Zaretskii]

> Date: Thu, 14 Nov 2013 15:11:40 +0400
> From: Joel Brobecker <brobecker@adacore.com>
> Cc: Ian Lance Taylor <iant@google.com>,	Peter Bergner <bergner@vnet.ibm.com>,	Tom Tromey <tromey@redhat.com>,	GDB Development <gdb@sourceware.org>,	Binutils Development <binutils@sourceware.org>,	Tulio Magno Quites Machado Filho <tuliom@linux.ibm.com>
> 
> > > GCC has always allowed vendor branches.  I don't see any reason that
> > > binutils/gdb should prohibit them.  Obviously all the code has to be
> > > under the GPL or some other explicitly permitted license.
> > 
> > I believe the GCC policy is that the code must also be assigned to the
> > FSF, just as it would be for trunk.
> 
> Outside of the policy, I am starting to rethink the policy of
> allowing vendor branches. For centralized version control systems
> such as SVN, it makes sense, because there is no other choice.
> 
> But for decentralized systems such as git, I think vendor branches
> could be just as easily hosted elsewhere.  With git, it's really easy
> for anyone to host it somewhere, and publish its location. It's also
> equally easy for anyone interested in the work to add that location
> a remote, and fetch from it.

Obviously, this discussion only has sense if the branch is hosted by
sourceware.  Otherwise, what could we do to prevent J. R. Hacker from
publishing a branch from her own machine?

Re: git is live

[Ian Lance Taylor]

On Thu, Nov 14, 2013 at 8:38 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Joel Brobecker <brobecker@adacore.com>
>>
>> But for decentralized systems such as git, I think vendor branches
>> could be just as easily hosted elsewhere.  With git, it's really easy
>> for anyone to host it somewhere, and publish its location. It's also
>> equally easy for anyone interested in the work to add that location
>> a remote, and fetch from it.
>
> Obviously, this discussion only has sense if the branch is hosted by
> sourceware.  Otherwise, what could we do to prevent J. R. Hacker from
> publishing a branch from her own machine?

Nothing.  But I don't see why that matters.

I'm mildly in favor of permitting vendor branches on gcc.gnu.org for a
different reason: it encourages vendors with GCC extensions to make
those extensions readily available to everybody.  If we require
vendors to handle their own hosting, we will inevitably have some who
simply decide not to bother.

Ian

Re: git is live

[Eli Zaretskii]

> Date: Thu, 14 Nov 2013 08:55:04 -0800
> From: Ian Lance Taylor <iant@google.com>
> Cc: Joel Brobecker <brobecker@adacore.com>, Richard Earnshaw <rearnsha@arm.com>, 
> 	Peter Bergner <bergner@vnet.ibm.com>, Tom Tromey <tromey@redhat.com>, gdb <gdb@sourceware.org>, 
> 	Binutils <binutils@sourceware.org>, 
> 	Tulio Magno Quites Machado Filho <tuliom@linux.ibm.com>
> 
> On Thu, Nov 14, 2013 at 8:38 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> >> From: Joel Brobecker <brobecker@adacore.com>
> >>
> >> But for decentralized systems such as git, I think vendor branches
> >> could be just as easily hosted elsewhere.  With git, it's really easy
> >> for anyone to host it somewhere, and publish its location. It's also
> >> equally easy for anyone interested in the work to add that location
> >> a remote, and fetch from it.
> >
> > Obviously, this discussion only has sense if the branch is hosted by
> > sourceware.  Otherwise, what could we do to prevent J. R. Hacker from
> > publishing a branch from her own machine?
> 
> Nothing.  But I don't see why that matters.

I was replying to Joel, who said (see above): "for decentralized
systems such as git, I think vendor branches could be just as easily
hosted elsewhere.  With git, it's really easy for anyone to host it
somewhere, and publish its location."

> I'm mildly in favor of permitting vendor branches on gcc.gnu.org for a
> different reason: it encourages vendors with GCC extensions to make
> those extensions readily available to everybody.  If we require
> vendors to handle their own hosting, we will inevitably have some who
> simply decide not to bother.

That's the crux of the issue.  Mentioning private hosting just steers
the discussion away from that issue, which was my point.

Re: git is live

[H.J. Lu]

On Thu, Nov 14, 2013 at 8:55 AM, Ian Lance Taylor <iant@google.com> wrote:
>
> I'm mildly in favor of permitting vendor branches on gcc.gnu.org for a
> different reason: it encourages vendors with GCC extensions to make
> those extensions readily available to everybody.  If we require
> vendors to handle their own hosting, we will inevitably have some who
> simply decide not to bother.
>

I'd like to see vendor branches on sourceware.

-- 
H.J.

Re: git is live

[Joel Brobecker]

> I'd like to see vendor branches on sourceware.

Can you explain why this would be a good thing for the project?

-- 
Joel

Re: git is live

[Andrew Pinski]

On Thu, Nov 14, 2013 at 10:14 AM, Joel Brobecker <brobecker@adacore.com> wrote:
>> I'd like to see vendor branches on sourceware.
>
> Can you explain why this would be a good thing for the project?

Ian described it the best of why GCC allows it:
> I'm mildly in favor of permitting vendor branches on gcc.gnu.org for a
> different reason: it encourages vendors with GCC extensions to make
> those extensions readily available to everybody.  If we require
> vendors to handle their own hosting, we will inevitably have some who
> simply decide not to bother.

I think the same is true of gdb and binutils to some extend.  And yes
most of the vendors have patches on top of the base versions of gdb,
binutils and gcc.

Thanks,
Andrew Pinski

>
> --
> Joel

Re: git is live

[Joel Brobecker]

> > I'm mildly in favor of permitting vendor branches on gcc.gnu.org for a
> > different reason: it encourages vendors with GCC extensions to make
> > those extensions readily available to everybody.  If we require
> > vendors to handle their own hosting, we will inevitably have some who
> > simply decide not to bother.
> 
> I think the same is true of gdb and binutils to some extend.  And yes
> most of the vendors have patches on top of the base versions of gdb,
> binutils and gcc.

OK, I can see this being true, indeed.

-- 
Joel

Re: git is live

[Fred Cooke]

What drives the desire for that, though? With git you can publish your
own branches as you see fit, and link them to who ever is relevant.
Adding a lot of branches to the central repository is just a form of
clutter, even if it is otherwise harmless. There's no real reason to,
unlike with CVS/SVN where that was the ONLY way. With Git it makes
absolute sense to keep these separate but share history, on some other
host. This way the official repository contains just that, official
code, and branches, ie, a "trunk" of some sort, and release/bug fix
branches, and tags thereof. Nothing more. Of course, my opinion is
worth what you paid for it, and isn't important. :-)

On Fri, Oct 25, 2013 at 3:51 PM, Peter Bergner <bergner@vnet.ibm.com> wrote:
> On Tue, 2013-10-22 at 01:01 -0600, Tom Tromey wrote:
>> The URLs:
>>
>>     git://sourceware.org/git/binutils-gdb.git
>>     ssh://sourceware.org/git/binutils-gdb.git
>
> Ok, it's probably getting old, but I'll add my thanks
> for switching us over.  Now to my question...
>
> >From a policy standpoint, are we going to allow vendor branches
> in the git repo like glibc does?  I'm hoping the answer is yes. :)
> We didn't allow it before due to it seems CVS issues, but with git,
> it should now be easy.
>
> Peter
>
>
>
>

Re: git is live

[Peter Bergner]

On Fri, 2013-10-25 at 16:09 +0200, Fred Cooke wrote:
> What drives the desire for that, though? With git you can publish your
> own branches as you see fit, and link them to who ever is relevant.

I agree that from a technical standpoint, hosting a branch elsewhere
is possible with git.  In my case, company policy doesn't allow it
without jumping through some painful hoops.  However, I am free to
create branches in the upstream repo... as long as the project
allows it.


Peter

Re: git is live

[Fred Cooke]

That's a real shame. A possible and wasteful (resource wise) solution
might be to have a second url/repo binutlils-gdb-contrib or whatever.
If done locally on the same server, it could share hard links and not
take up much space, but I can see the majority hating this idea, and
that's fair enough.

On Fri, Oct 25, 2013 at 6:40 PM, Peter Bergner <bergner@vnet.ibm.com> wrote:
> On Fri, 2013-10-25 at 16:09 +0200, Fred Cooke wrote:
>> What drives the desire for that, though? With git you can publish your
>> own branches as you see fit, and link them to who ever is relevant.
>
> I agree that from a technical standpoint, hosting a branch elsewhere
> is possible with git.  In my case, company policy doesn't allow it
> without jumping through some painful hoops.  However, I am free to
> create branches in the upstream repo... as long as the project
> allows it.
>
>
> Peter
>
>

Re: git is live

[Peter Bergner]

On Fri, 2013-10-25 at 18:49 +0200, Fred Cooke wrote:
> That's a real shame. A possible and wasteful (resource wise) solution
> might be to have a second url/repo binutlils-gdb-contrib or whatever.
> If done locally on the same server, it could share hard links and not
> take up much space, but I can see the majority hating this idea, and
> that's fair enough.

Well if there was an official project repo for branches separate
from the development repo, I could use that.  I'm just not free
to use something outside of the project itself.

Peter

Re: git is live

[Tom Tromey]

Peter> Well if there was an official project repo for branches separate
Peter> from the development repo, I could use that.  I'm just not free
Peter> to use something outside of the project itself.

It's fine to just use the main repository.  There is no big downside to
it.

Tom

Re: git is live

[Tom Tromey]

Peter> From a policy standpoint, are we going to allow vendor branches
Peter> in the git repo like glibc does?  I'm hoping the answer is yes. :)
Peter> We didn't allow it before due to it seems CVS issues, but with git,
Peter> it should now be easy.

My understanding is that gdb followed "gcc rules" here: any maintainer
could make a branch provided the branch guidelines were followed.

See

    https://sourceware.org/gdb/wiki/Internals%20Experimental-Branches

I think the reason nobody really made branches is just because CVS made
it hard.

I'm hosting my personal branches on gitorious, though.
That way I can opt out of the policies that I find onerous.

Tom

Re: git is live

[Peter Bergner]

On Fri, 2013-10-25 at 10:00 -0600, Tom Tromey wrote:
> My understanding is that gdb followed "gcc rules" here: any maintainer
> could make a branch provided the branch guidelines were followed.
> 
> See
> 
>     https://sourceware.org/gdb/wiki/Internals%20Experimental-Branches

Great!


> I think the reason nobody really made branches is just because CVS made
> it hard.

Right, that was my understanding as well, I just wanted to be sure
there wasn't another reason due to some policy decision I was unaware
of.  It seems not, and since you and Ian both seem to say it should be
ok and I'm guessing Alan won't object, I will assume this is ok.
Thanks!


Peter

Re: git is live

[Alan Modra]

I tried to push some testsuite changes today, and got

remote: ld/testsuite/ld-powerpc/tlsexe.r:50: trailing whitespace.
remote: + +03 +\.tdata \.dynamic \.opd \.got \.plt 
remote: ld/testsuite/ld-powerpc/tlsexe.r:90: trailing whitespace.
remote: +.* SECTION +LOCAL +DEFAULT +13 
...
remote: error: hook declined to update refs/heads/master

I agree that it's good to reject trailing whitespace generally, but
the testsuite is a little special.  We're matching tool output.  If,
as in this example, readelf emits trailing whitespace then we
shouldn't need to write a regex to match it.  Can this be fixed
easily?

-- 
Alan Modra
Australia Development Lab, IBM

Re: git is live

[Alan Modra]

On Wed, Oct 30, 2013 at 08:53:32AM +1030, Alan Modra wrote:
> I tried to push some testsuite changes today, and got
> 
> remote: ld/testsuite/ld-powerpc/tlsexe.r:50: trailing whitespace.
> remote: + +03 +\.tdata \.dynamic \.opd \.got \.plt 
> remote: ld/testsuite/ld-powerpc/tlsexe.r:90: trailing whitespace.
> remote: +.* SECTION +LOCAL +DEFAULT +13 
> ...
> remote: error: hook declined to update refs/heads/master
> 
> I agree that it's good to reject trailing whitespace generally, but
> the testsuite is a little special.  We're matching tool output.  If,
> as in this example, readelf emits trailing whitespace then we
> shouldn't need to write a regex to match it.  Can this be fixed
> easily?

Come to think of it, maybe no trailing whitespace in the testsuite
isn't such a bad thing.  If the testsuite matched all trailing spaces
with " *" then the bar to updating readelf and objdump -d to not emit
trailing spaces is that much lower.

-- 
Alan Modra
Australia Development Lab, IBM

Re: git is live

[Tom Tromey]

>>>>> "Alan" == Alan Modra <amodra@gmail.com> writes:

Alan> I tried to push some testsuite changes today, and got
Alan> remote: ld/testsuite/ld-powerpc/tlsexe.r:50: trailing whitespace.
Alan> remote: + +03 +\.tdata \.dynamic \.opd \.got \.plt 
Alan> remote: ld/testsuite/ld-powerpc/tlsexe.r:90: trailing whitespace.
Alan> remote: +.* SECTION +LOCAL +DEFAULT +13 
Alan> ...
Alan> remote: error: hook declined to update refs/heads/master

Alan> I agree that it's good to reject trailing whitespace generally, but
Alan> the testsuite is a little special.  We're matching tool output.  If,
Alan> as in this example, readelf emits trailing whitespace then we
Alan> shouldn't need to write a regex to match it.  Can this be fixed
Alan> easily?

Yeah.  I didn't intend to have this feature enabled.
I will look into it tomorrow.

Tom

Re: git is live

[Tom Tromey]

>>>>> "Tom" == Tom Tromey <tromey@redhat.com> writes:

Tom> Yeah.  I didn't intend to have this feature enabled.
Tom> I will look into it tomorrow.

I've fixed this and tweaked a few other settings related to the "update"
script as well.

Tom

Re: git is live

[H.J. Lu]

On Tue, Oct 22, 2013 at 12:01 AM, Tom Tromey <tromey@redhat.com> wrote:
> Hi everybody.  Git is now live and the master repository for binutils
> and gdb.
>
>
> Maybe I made some enormous mistake!  While I'd prefer to be finished
> with this project, if there is a mistake, please be reassured that we
> have not taken any truly irreversible action.  CVS commits are disabled,
> but all the data is still there.
>
> I hope you feel reassured now.
>
>
> Pedro pointed out today that the history of the existing repository is
> weird around the point at which the src repository is stitched onto the
> older devo repository.  "Weird" here means that there are some commits
> that delete nearly everything, only to have it all restored a commit or
> two later.  I spent some time trying to fix this; but in fact, far too
> much time, and in the end I decided that we will just have to live with
> it.
>
>
> It was pointed out to me on irc that not everybody has already used git.
> I'm reliably informed that this is a good git book, and it is available
> online:
>
>     http://git-scm.com/book
>
> I'm sure there are others as well.
>
> A couple of small hints.  You will want to set your username and email
> address in your git config before pushing your first commit.  I'm sure
> the book explains this early on.
>
> I've set things up to reject "non-fast-forward" merge commits to master.
> What this means is that if you commit something and try to push, and
> then it fails, you will want to "git pull --rebase", or use "git rebase
> -i", before trying again.  This is basically analogous to "cvs
> update"ing before trying to commit again.
>
>
> I named the new repository "binutils-gdb".  First, sorry to all who
> backed "src".  I was swayed by the hue and cry to choose a URL whose
> importance is undeniable despite the second argument to git clone.
> Second, gdbers, I chose the name alphabetically.
>
> The URLs:
>
>     git://sourceware.org/git/binutils-gdb.git
>     ssh://sourceware.org/git/binutils-gdb.git
>
> I believe only the latter form allows pushing.
>
>
> Please report any problems to me or to the list.  I'll be around fixing
> any problems.  You can also join us on #gdb and ask git questions if you
> like.
>
> I still have a few final tasks to do for the transition, but nothing too
> pressing.  E.g., I will check in my changes to the gdbadmin scripts
> soon, when I'm readier to debug them; but meanwhile they will pull from
> CVS without harm.
>
> Tom

I can't push my branch:

# git push origin hjl/pr12639:hjl/pr12639
Counting objects: 12, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (7/7), done.
Writing objects: 100% (7/7), 1.23 KiB | 0 bytes/s, done.
Total 7 (delta 5), reused 0 (delta 0)
remote: fatal: Invalid revision range
0000000000000000000000000000000000000000..6346639c66e5244e588d341f8f96c817cdf03741
remote: fatal: Invalid revision range
0000000000000000000000000000000000000000..6346639c66e5244e588d341f8f96c817cdf03741
remote: dirname: missing operand
remote: Try `dirname --help' for more information.
To ssh://hjl@sourceware.org/git/binutils-gdb.git
 * [new branch]      hjl/pr12639 -> hjl/pr12639


-- 
H.J.

Re: git is live

[Tom Tromey]

>>>>> "HJ" == H J Lu <hjl.tools@gmail.com> writes:

HJ> I can't push my branch:

Actually, the push did go through.

binutils-gdb.git uses the post-receive and update hooks.
These hooks can't prevent a push.

HJ> remote: fatal: Invalid revision range
HJ> 0000000000000000000000000000000000000000..6346639c66e5244e588d341f8f96c817cdf03741
HJ> remote: dirname: missing operand

I'm looking into the bug.

HJ>  * [new branch]      hjl/pr12639 -> hjl/pr12639

FWIW this is how you can tell it worked.

Tom

Re: git is live

[Tom Tromey]

Tom> I'm looking into the bug.

I checked in a patch which should fix at least the second instance and
the "dirname" thing.  I made post-receive-email only use the fallback
list for branch creation and deletion, which seemed reasonable to me.

Tom

Re: git is live

[H.J. Lu]

On Tue, Nov 5, 2013 at 6:46 AM, Tom Tromey <tromey@redhat.com> wrote:
> Tom> I'm looking into the bug.
>
> I checked in a patch which should fix at least the second instance and
> the "dirname" thing.  I made post-receive-email only use the fallback
> list for branch creation and deletion, which seemed reasonable to me.
>
> Tom

Another problem.  Checkin no longer shows up in bug report:

https://sourceware.org/bugzilla/show_bug.cgi?id=16130

-- 
H.J.

Re: git is live

[Will Newton]

On 6 November 2013 17:01, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Tue, Nov 5, 2013 at 6:46 AM, Tom Tromey <tromey@redhat.com> wrote:
>> Tom> I'm looking into the bug.
>>
>> I checked in a patch which should fix at least the second instance and
>> the "dirname" thing.  I made post-receive-email only use the fallback
>> list for branch creation and deletion, which seemed reasonable to me.
>>
>> Tom
>
> Another problem.  Checkin no longer shows up in bug report:
>
> https://sourceware.org/bugzilla/show_bug.cgi?id=16130

FWIW it seems to work for gdb but not binutils:

e.g.  https://sourceware.org/bugzilla/show_bug.cgi?id=12866


-- 
Will Newton
Toolchain Working Group, Linaro

Re: git is live

[Tom Tromey]

HJ> Another problem.  Checkin no longer shows up in bug report:
HJ> https://sourceware.org/bugzilla/show_bug.cgi?id=16130

It was a buglet in post-receive-email.
I've checked in a fix.

Tom

Re: git is live

[H.J. Lu]

On Wed, Nov 6, 2013 at 9:21 AM, Tom Tromey <tromey@redhat.com> wrote:
> HJ> Another problem.  Checkin no longer shows up in bug report:
> HJ> https://sourceware.org/bugzilla/show_bug.cgi?id=16130
>
> It was a buglet in post-receive-email.
> I've checked in a fix.

When I pushed a tag, I got thousands of

remote: Wide character in print at
/sourceware/infra/bin/email-to-bugzilla line 57, <STDIN> line 79285.

I had to kill "git push --tags".


-- 
H.J.

Re: git is live

[H.J. Lu]

On Wed, Nov 6, 2013 at 9:21 AM, Tom Tromey <tromey@redhat.com> wrote:
> HJ> Another problem.  Checkin no longer shows up in bug report:
> HJ> https://sourceware.org/bugzilla/show_bug.cgi?id=16130
>
> It was a buglet in post-receive-email.
> I've checked in a fix.
>
> Tom

It doesn't work for gas checkin.  This commit:

https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=9f4e1fadf3e75b8aa37744d2b06b29f8d6d1ca93

didn't show up in:

http://www.sourceware.org/bugzilla/show_bug.cgi?id=16140

-- 
H.J.

Re: git is live

[Tom Tromey]

>>>>> "HJ" == H J Lu <hjl.tools@gmail.com> writes:

HJ> It doesn't work for gas checkin.  This commit:

HJ> https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=9f4e1fadf3e75b8aa37744d2b06b29f8d6d1ca93

HJ> didn't show up in:

HJ> http://www.sourceware.org/bugzilla/show_bug.cgi?id=16140

I see it here:

https://sourceware.org/bugzilla/show_bug.cgi?id=16140#c2

Tom

Re: git is live

[H.J. Lu]

On Fri, Nov 8, 2013 at 10:15 AM, Tom Tromey <tromey@redhat.com> wrote:
>>>>>> "HJ" == H J Lu <hjl.tools@gmail.com> writes:
>
> HJ> It doesn't work for gas checkin.  This commit:
>
> HJ> https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=9f4e1fadf3e75b8aa37744d2b06b29f8d6d1ca93
>
> HJ> didn't show up in:
>
> HJ> http://www.sourceware.org/bugzilla/show_bug.cgi?id=16140
>
> I see it here:
>
> https://sourceware.org/bugzilla/show_bug.cgi?id=16140#c2
>
> Tom

It took about 20 minutes.

-- 
H.J.

Re: git is live

[Tom Tromey]

HJ> It took about 20 minutes.

The updating is done by sending an email.
How long it takes depends on the mail system on sourceware.

Tom

Re: git is live

[Paul Smith]

On Fri, 2013-11-08 at 10:22 -0800, H.J. Lu wrote:
> > I see it here:
> >
> > https://sourceware.org/bugzilla/show_bug.cgi?id=16140#c2
> >
> > Tom
> 
> It took about 20 minutes.

It also appears to have been added twice...?

Re: git is live

[Tom Tromey]

Paul> It also appears to have been added twice...?

The two messages refer to two different commits.

Tom

Re: git is live

[Andreas Schwab]

Tom Tromey <tromey@redhat.com> writes:

> Paul> It also appears to have been added twice...?
>
> The two messages refer to two different commits.

It would be easier to notice if they would mention the branch.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: git is live

[Tom Tromey]

Tom> The two messages refer to two different commits.

Andreas> It would be easier to notice if they would mention the branch.

Good idea.  I checked in a patch that should fix this.

Tom

Re: git is live

[Andrew Pinski]

On Tue, Oct 22, 2013 at 12:01 AM, Tom Tromey <tromey@redhat.com> wrote:
> Hi everybody.  Git is now live and the master repository for binutils
> and gdb.
>
>
> Maybe I made some enormous mistake!  While I'd prefer to be finished
> with this project, if there is a mistake, please be reassured that we
> have not taken any truly irreversible action.  CVS commits are disabled,
> but all the data is still there.
>
> I hope you feel reassured now.
>
>
> Pedro pointed out today that the history of the existing repository is
> weird around the point at which the src repository is stitched onto the
> older devo repository.  "Weird" here means that there are some commits
> that delete nearly everything, only to have it all restored a commit or
> two later.  I spent some time trying to fix this; but in fact, far too
> much time, and in the end I decided that we will just have to live with
> it.
>
>
> It was pointed out to me on irc that not everybody has already used git.
> I'm reliably informed that this is a good git book, and it is available
> online:
>error: refs/tags/x86_64versiong3 does not point to a valid object!

>     http://git-scm.com/book
>
> I'm sure there are others as well.
>
> A couple of small hints.  You will want to set your username and email
> address in your git config before pushing your first commit.  I'm sure
> the book explains this early on.
>
> I've set things up to reject "non-fast-forward" merge commits to master.
> What this means is that if you commit something and try to push, and
> then it fails, you will want to "git pull --rebase", or use "git rebase
> -i", before trying again.  This is basically analogous to "cvs
> update"ing before trying to commit again.
>
>
> I named the new repository "binutils-gdb".  First, sorry to all who
> backed "src".  I was swayed by the hue and cry to choose a URL whose
> importance is undeniable despite the second argument to git clone.
> Second, gdbers, I chose the name alphabetically.
>
> The URLs:
>
>     git://sourceware.org/git/binutils-gdb.git
>     ssh://sourceware.org/git/binutils-gdb.git
>
> I believe only the latter form allows pushing.

When I do a git clone of the first URL I get a lot of errors:
error: refs/tags/x86_64versiong3 does not point to a valid object!
error: refs/tags/w32api-2_2 does not point to a valid object!
.....

Thanks,
Andrew Pinski


>
>
> Please report any problems to me or to the list.  I'll be around fixing
> any problems.  You can also join us on #gdb and ask git questions if you
> like.
>
> I still have a few final tasks to do for the transition, but nothing too
> pressing.  E.g., I will check in my changes to the gdbadmin scripts
> soon, when I'm readier to debug them; but meanwhile they will pull from
> CVS without harm.
>
> Tom

Re: git is live

[Peter Bergner]

On Wed, 2013-11-06 at 11:41 -0800, Andrew Pinski wrote:
> >     git://sourceware.org/git/binutils-gdb.git
> >     ssh://sourceware.org/git/binutils-gdb.git
> >
> > I believe only the latter form allows pushing.
> 
> When I do a git clone of the first URL I get a lot of errors:
> error: refs/tags/x86_64versiong3 does not point to a valid object!
> error: refs/tags/w32api-2_2 does not point to a valid object!

I was seeing the same thing.  It went away when I upgraded to
a newer git version (I was using 1.7.1).  Segher looked into
and here are his comments from #gcc:

<segher> in 1.6.5 an optimisation was introduced that has the server not
         send everything it has on any clone, but only what you ask to clone
<segher> it forgot to ask for the tags it seems; it was fixed in 1.7.4 or so
<segher> so affected versions end up with a clone where the objects for those
         tags are missing, and will error whenever you try to use them.
         otherwise no problem


Peter