gdb.git mirror is broken

gdb.git mirror is broken

[H.J. Lu]

Hi Jim,

gdb.git mirror at

http://sources.redhat.com/git/gdb.git

is broken. The problems are

1: "cpu" directory is missing.
2.  Top level files and gdb/gdbserver, bfd, sim, include directories
haven't been updated  since 2009-09-16.

Thanks.


-- 
H.J.

RE: gdb.git mirror is broken

[Pierre Muller]

 This explains the problems
I also get when trying to test my patches
on gcc16.


Pierre Muller
Pascal language support maintainer for GDB



> -----Message d'origine-----
> De : gdb-owner@sourceware.org [mailto:gdb-owner@sourceware.org] De la
> part de H.J. Lu
> Envoyé : Tuesday, October 06, 2009 2:31 AM
> À : meyering@redhat.com
> Cc : GDB
> Objet : gdb.git mirror is broken
> 
> Hi Jim,
> 
> gdb.git mirror at
> 
> http://sources.redhat.com/git/gdb.git
> 
> is broken. The problems are
> 
> 1: "cpu" directory is missing.
> 2.  Top level files and gdb/gdbserver, bfd, sim, include directories
> haven't been updated  since 2009-09-16.
> 
> Thanks.
> 
> 
> --
> H.J.

Re: gdb.git mirror is broken

[Jim Meyering]

H.J. Lu wrote:
> Hi Jim,
>
> gdb.git mirror at
>
> http://sources.redhat.com/git/gdb.git
>
> is broken. The problems are
>
> 1: "cpu" directory is missing.
> 2.  Top level files and gdb/gdbserver, bfd, sim, include directories
> haven't been updated  since 2009-09-16.

Hi H.J.

When I check out gdb using CVS, via this,
(as recommended here http://www.gnu.org/software/gdb/current/)

    cvs -z3 -d :pserver:anoncvs@sourceware.org:/cvs/src co gdb

That created a single directory named "src/", containing no
top level files:

    $ ls src
    CVS/  config/  etc/  include/  libdecnumber/  opcodes/   sim/
    bfd/  cpu/     gdb/  intl/     libiberty/     readline/  texinfo/

This suggests that something is wrong with CVS.

Has someone been changing the modules file that
describes what you get when you check out gdb from CVS?

Is there a better way to checkout from CVS?

Just to confirm, I checked it out again (same exact command, also into
a new empty directory), and this time, I got all of the expected files.

If similar things happen during the mirroring process,
that could well explain the problem.

At first, I suspected the recent changes in my mirroring script
to mirror binutils to git, but for the problem to date
back to Sept 16, I now wonder if it's something else.

I'm investigating...

Re: gdb.git mirror is broken

[Jim Meyering]

H.J. Lu wrote:

> Hi Jim,
>
> gdb.git mirror at
>
> http://sources.redhat.com/git/gdb.git
>
> is broken. The problems are
>
> 1: "cpu" directory is missing.

The cpu directory has always been excluded from the cvs-to-git mirroring
of gdb.  Would you like it to be included starting now?

Re: gdb.git mirror is broken

[Jim Meyering]

H.J. Lu wrote:

> Hi Jim,
>
> gdb.git mirror at
>
> http://sources.redhat.com/git/gdb.git
>
> is broken. The problems are
>
> 1: "cpu" directory is missing.

Considering cpu/ has never been included in a gdb.git mirror
(it's been explicitly excluded from the beginning), it may
make sense to reconvert the repository from scratch, in order
to include that directory and all of its history.

However, that would have the disadvantage of changing all
existing SHA1 commit values -- which might cause problems with
the likes of archer.git.

> 2.  Top level files and gdb/gdbserver, bfd, sim, include directories
> haven't been updated  since 2009-09-16.

I don't know what caused the process to stop mirroring
those directories.  It could be a bug in cvsps, git-cvsimport,
my script, git-push, or even rsync.

IMHO, the best would be to remove CVS from the loop.
Leading up to that, I propose the following:

  I will re-convert all of gdb's CVS history to git (using parsecvs),
  not excluding the cpu/ directory this time.  Then, I will add checks
  to my mirroring script to notify me if git and CVS checkouts ever
  diverge.

Note that the initial conversion is via parsecvs,
yet incrementals are via my scripts, which rely on git-cvsimport
(which in turn relies on cvsps).

If anyone is interested in switching primary GDB development
to git, once such a new repository is in place and deemed stable,
I urge you to dump CVS.  While the conversion tools are not always
reliable, I can assure you that git itself has been amazingly reliable
for years.

---------------------------------------
If you want to keep existing SHA1 commits (say for archer),
yet continue with minimal disruption, and you don't mind
omitting the history of cpu/ for now, I can easily plop
all of cpu/ and the missing bits of the out-of-sync directories
into gdb.git via a single commit.  That will make it so a git
clone and a cvs checkout produce identical (modulo CVS/ dirs)
hierarchies.  And who knows, maybe it'll make it so changes
to offending directories will once again be tracked via the
mirroring mechanism.

It looks like I'll have to adjust my mirroring script to
incur still more overhead (space and time) to verify cvs/git
consistency, regardless...

Also, please be aware that this is a mostly-extracurricular project.

Re: gdb.git mirror is broken

[H.J. Lu]

On Tue, Oct 6, 2009 at 12:38 AM, Jim Meyering <jim@meyering.net> wrote:
> H.J. Lu wrote:
>
>> Hi Jim,
>>
>> gdb.git mirror at
>>
>> http://sources.redhat.com/git/gdb.git
>>
>> is broken. The problems are
>>
>> 1: "cpu" directory is missing.
>
> Considering cpu/ has never been included in a gdb.git mirror
> (it's been explicitly excluded from the beginning), it may
> make sense to reconvert the repository from scratch, in order
> to include that directory and all of its history.
>
> However, that would have the disadvantage of changing all
> existing SHA1 commit values -- which might cause problems with
> the likes of archer.git.

I didn't realize that cpu was excluded on purpose. I just
did a comparison between gdb tree checked out from CVS
and gdb tree checked out from git. I don't mind leaving it as is.

>> 2.  Top level files and gdb/gdbserver, bfd, sim, include directories
>> haven't been updated  since 2009-09-16.
>
> I don't know what caused the process to stop mirroring
> those directories.  It could be a bug in cvsps, git-cvsimport,
> my script, git-push, or even rsync.
>
> IMHO, the best would be to remove CVS from the loop.
> Leading up to that, I propose the following:
>
>  I will re-convert all of gdb's CVS history to git (using parsecvs),
>  not excluding the cpu/ directory this time.  Then, I will add checks
>  to my mirroring script to notify me if git and CVS checkouts ever
>  diverge.

I am enclosing my script at the end of this email. It diffs
all ChangLogs between 2 gdb trees.

> Note that the initial conversion is via parsecvs,
> yet incrementals are via my scripts, which rely on git-cvsimport
> (which in turn relies on cvsps).
>
> If anyone is interested in switching primary GDB development
> to git, once such a new repository is in place and deemed stable,
> I urge you to dump CVS.  While the conversion tools are not always
> reliable, I can assure you that git itself has been amazingly reliable
> for years.
>

It sounds a good idea. But don't we need to switch src tree to git, not
just gdb tree? I don't mind checking out the whole src tree. But we
need a way to build only gcc, gdb, binutils, .... even though there are
more packages.

Thanks.

-- 
H.J.
---
#! /bin/sh

gdb=$1

cl="
./etc/ChangeLog
./gdb/gdbserver/ChangeLog
./gdb/ChangeLog
./gdb/testsuite/ChangeLog
./gdb/doc/ChangeLog
./intl/ChangeLog
./bfd/ChangeLog
./bfd/doc/ChangeLog
./libdecnumber/ChangeLog
./readline/examples/rlfe/ChangeLog
./ChangeLog
./opcodes/ChangeLog
./libiberty/ChangeLog
./config/ChangeLog
./cpu/ChangeLog
./sim/frv/ChangeLog
./sim/arm/ChangeLog
./sim/mcore/ChangeLog
./sim/m32r/ChangeLog
./sim/mips/ChangeLog
./sim/d10v/ChangeLog
./sim/cr16/ChangeLog
./sim/h8300/ChangeLog
./sim/ChangeLog
./sim/sh/ChangeLog
./sim/m68hc11/ChangeLog
./sim/testsuite/frv-elf/ChangeLog
./sim/testsuite/mips64el-elf/ChangeLog
./sim/testsuite/d10v-elf/ChangeLog
./sim/testsuite/ChangeLog
./sim/testsuite/sim/mips/ChangeLog
./sim/testsuite/sim/cr16/ChangeLog
./sim/testsuite/sim/h8300/ChangeLog
./sim/testsuite/sim/sh/ChangeLog
./sim/testsuite/sim/sh64/ChangeLog
./sim/testsuite/sim/sh64/media/ChangeLog
./sim/testsuite/sim/sh64/compact/ChangeLog
./sim/testsuite/m32r-elf/ChangeLog
./sim/igen/ChangeLog
./sim/iq2000/ChangeLog
./sim/ppc/ChangeLog
./sim/v850/ChangeLog
./sim/mn10300/ChangeLog
./sim/sh64/ChangeLog
./sim/erc32/ChangeLog
./sim/common/ChangeLog
./sim/m32c/ChangeLog
./include/gdb/ChangeLog
./include/elf/ChangeLog
./include/opcode/ChangeLog
./include/coff/ChangeLog
./include/aout/ChangeLog
./include/ChangeLog
./include/nlm/ChangeLog
"

for f in $cl
do
  diff -up $f $gdb/$f
done

Re: gdb.git mirror is broken

[Jim Meyering]

H.J. Lu wrote:

> On Tue, Oct 6, 2009 at 12:38 AM, Jim Meyering <jim@meyering.net> wrote:
>> H.J. Lu wrote:
>>
>>> Hi Jim,
>>>
>>> gdb.git mirror at
>>>
>>> http://sources.redhat.com/git/gdb.git
>>>
>>> is broken. The problems are
>>>
>>> 1: "cpu" directory is missing.
>>
>> Considering cpu/ has never been included in a gdb.git mirror
>> (it's been explicitly excluded from the beginning), it may
>> make sense to reconvert the repository from scratch, in order
>> to include that directory and all of its history.
>>
>> However, that would have the disadvantage of changing all
>> existing SHA1 commit values -- which might cause problems with
>> the likes of archer.git.
>
> I didn't realize that cpu was excluded on purpose. I just
> did a comparison between gdb tree checked out from CVS
> and gdb tree checked out from git. I don't mind leaving it as is.
>
>>> 2.  Top level files and gdb/gdbserver, bfd, sim, include directories
>>> haven't been updated  since 2009-09-16.
>>
>> I don't know what caused the process to stop mirroring
>> those directories.  It could be a bug in cvsps, git-cvsimport,
>> my script, git-push, or even rsync.
>>
>> IMHO, the best would be to remove CVS from the loop.
>> Leading up to that, I propose the following:
>>
>>  I will re-convert all of gdb's CVS history to git (using parsecvs),
>>  not excluding the cpu/ directory this time.  Then, I will add checks
>>  to my mirroring script to notify me if git and CVS checkouts ever
>>  diverge.
>
> I am enclosing my script at the end of this email. It diffs
> all ChangLogs between 2 gdb trees.
>
>> Note that the initial conversion is via parsecvs,
>> yet incrementals are via my scripts, which rely on git-cvsimport
>> (which in turn relies on cvsps).
>>
>> If anyone is interested in switching primary GDB development
>> to git, once such a new repository is in place and deemed stable,
>> I urge you to dump CVS.  While the conversion tools are not always
>> reliable, I can assure you that git itself has been amazingly reliable
>> for years.
>>
>
> It sounds a good idea. But don't we need to switch src tree to git, not
> just gdb tree? I don't mind checking out the whole src tree. But we
> need a way to build only gcc, gdb, binutils, .... even though there are
> more packages.

When gdb was the only project using this cvs-to-git
mirroring, the status of these shared directories didn't
really matter.  Now that binutils also has a git mirror,
perhaps we should think ahead to the day if/when everyone
is using git and not CVS.

Since some directories are shared between projects, one way would
be to make each directory into its own git repository.
Then, a separate gdb.git repository would include them
via a git submodule.

The way this would work is that gdb would record an SHA1 (that's about all
a git submodule does) telling which bfd commit it is currently using.
If bfd/ development is in a particularly unstable period, you may
want to keep gdb's submodule pointing at some commit from before the
disruptive changes started.  Once bfd things stabilize, you would run a
command telling git to record a newer bfd/ SHA1 in the gdb repository,
and then you'd commit that meta-change.

Here's an example of such a commit in coreutils, where
I make it use the latest changes from gnulib:

    http://git.sv.gnu.org/cgit/coreutils.git/commit/?id=3c40fdfba612a0fad259de29adaeaf7554cfaf33

If I need to make a change in gnulib, I don't change
coreutils/gnulib/, but rather make the change in a separate
git clone'd gnulib tree, commit, and then push.  Once I've
pushed, I can then go back to my coreutils tree and tell
it to sync from the latest upstream.  I run this command:

  git syncsub

which is just an alias for:

  git submodule foreach git pull origin master

And then commit the result.

Re: gdb.git mirror is broken

[Joseph S. Myers]

On Tue, 6 Oct 2009, Jim Meyering wrote:

> perhaps we should think ahead to the day if/when everyone
> is using git and not CVS.

The day when each project can choose its version control system, and 
change between systems, independently and without needing to change in 
sync with other projects, sounds much better to me.  That there is any 
link at all between the development of GDB and Cygwin, for example, is a 
defect in the present system that should be fixed by the move of either 
project to another system.

> If I need to make a change in gnulib, I don't change
> coreutils/gnulib/, but rather make the change in a separate

First and foremost, as I said in 
<http://sourceware.org/ml/binutils/2009-05/msg00117.html>, version control 
should make common tasks easy.  That means a single command in a binutils 
checkout to commit both a BFD change and the testcases in the ld 
testsuite, for example.  What things look like underneath is less 
important, and the exact spelling of the command is less important - but 
if it doesn't look like a single repository for common use cases like 
that, something is seriously wrong.

Version control should also make mistakes hard - it should be hard to 
check in an incomplete patch by accident, or think you have checked in a 
change when it has not gone where it should, for example, and extremely 
hard to break the repository.

(Advocates of any change also still need to work out the detailed designs, 
as I noted in <http://sourceware.org/ml/binutils/2009-05/msg00213.html>.)

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: gdb.git mirror is broken

[Jim Meyering]

Joseph S. Myers wrote:
> On Tue, 6 Oct 2009, Jim Meyering wrote:
>
>> perhaps we should think ahead to the day if/when everyone
>> is using git and not CVS.
>
> The day when each project can choose its version control system, and
> change between systems, independently and without needing to change in
> sync with other projects, sounds much better to me.  That there is any
> link at all between the development of GDB and Cygwin, for example, is a
> defect in the present system that should be fixed by the move of either
> project to another system.
>
>> If I need to make a change in gnulib, I don't change
>> coreutils/gnulib/, but rather make the change in a separate
>
> First and foremost, as I said in
> <http://sourceware.org/ml/binutils/2009-05/msg00117.html>, version control
> should make common tasks easy.  That means a single command in a binutils
> checkout to commit both a BFD change and the testcases in the ld
> testsuite, for example.  What things look like underneath is less
> important, and the exact spelling of the command is less important - but
> if it doesn't look like a single repository for common use cases like
> that, something is seriously wrong.
>
> Version control should also make mistakes hard - it should be hard to
> check in an incomplete patch by accident, or think you have checked in a
> change when it has not gone where it should, for example, and extremely
> hard to break the repository.
>
> (Advocates of any change also still need to work out the detailed designs,
> as I noted in <http://sourceware.org/ml/binutils/2009-05/msg00213.html>.)

No pressure from me.
I barely have time to help with the technical side of things,
so if you want someone willing to invest in advocacy I'm not your man.

Re: gdb.git mirror is broken

[Joseph S. Myers]

On Tue, 6 Oct 2009, Jim Meyering wrote:

> No pressure from me.
> I barely have time to help with the technical side of things,
> so if you want someone willing to invest in advocacy I'm not your man.

I don't want advocacy, but *technical design*.  Technical design based 
around showing how common tasks translate to a proposed new system, 
existing scripts are converted and common errors are made harder.  
Technical design that demonstrates that the usual tasks for people making 
occasional changes are at least as easy and intuitive as now.  Technical 
design that shows how the breakage that is the subject of the present 
thread will not be possible in the proposed system.  (No doubt it will 
also make additional things possible for version control experts, but the 
people proposing designs need to think in normal user terms.)

Personally I think a single repository for GDB and binutils together, with 
configure options for building only one or the other, might be a 
reasonable approach (with other projects left to move from CVS or not at 
their own choice and in their own time), but that's not the level of 
design needed here; it doesn't even address how to handle gdbtk.  For 
shared toplevel files, libiberty etc., I think it would be reasonable to 
do things in a DVCSly pure way and have no master repository and scripts 
automatically merging commits from one repository to another (possibly 
using a different version control system), or to declare GCC the master 
for all files present there and disallow non-automatic commits to the 
shared files on the mainline of other repositories.  But a detailed design 
would need to demonstrate such scripts working in practice.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: gdb.git mirror is broken

[Matt Rice]

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

On Tue, Oct 6, 2009 at 7:26 AM, Joseph S. Myers <joseph@codesourcery.com> wrote:
>
> First and foremost, as I said in
> <http://sourceware.org/ml/binutils/2009-05/msg00117.html>, version control
> should make common tasks easy.  That means a single command in a binutils
> checkout to commit both a BFD change and the testcases in the ld
> testsuite, for example.  What things look like underneath is less
> important, and the exact spelling of the command is less important - but
> if it doesn't look like a single repository for common use cases like
> that, something is seriously wrong.

here is one way we could achieve the 'single commit across bfd and ld
testsuite' case,

by splitting bfd out, then subtree-merging it back in,
then doing a subtree merge to the separated bfd, when binutils changes...

one of the downsides to this is it is going to create alot of merge
commits which looks kind of funky in the separated bfd's gitk,

but assuming that we don't give anybody write access to the separated
bfd, we could do this automatically and assume there will be no
conflicts I imagine....

this script takes quite a while to run (for the initial splitting) and
a bit of disk space...

If we want to keep gdb in both the binutils and the separate module
though that creates some things to decide like which version is the
canonical one which developers should commit to, unless people feel
like merging it by hand...

the subtree merge isn't really something i'm that terribly familiar
with, but it seems to work, i haven't done a whole lot of repository
verification though.

[-- Attachment #2: git-split.sh --]
[-- Type: application/x-sh, Size: 2544 bytes --]

Re: gdb.git mirror is broken

[Matt Rice]

On Tue, Oct 6, 2009 at 9:29 PM, Matt Rice <ratmice@gmail.com> wrote:
<snip>

> by splitting bfd out, then subtree-merging it back in,
> then doing a subtree merge to the separated bfd, when binutils changes...
>
> one of the downsides to this is it is going to create alot of merge
> commits which looks kind of funky in the separated bfd's gitk,

<snip>
It just occurred to me that when merging from the large combined tree
back into the split out subtrees, assuming that these simply track the
main tree and nobody is given write access
I believe we can safely

$ git fetch binutils
$ git rebase -s subtree binutils/master

instead of the
$ git merge -s subtree binutils/master

without worrying about rebase rewriting commits, since it is strictly a sink.
instead of git merge -s subtree and avoid all of these merge commits

Re: gdb.git mirror is broken

[Tom Tromey]

>>>>> "Jim" == Jim Meyering <jim@meyering.net> writes:

Jim> Since some directories are shared between projects, one way would
Jim> be to make each directory into its own git repository.
Jim> Then, a separate gdb.git repository would include them
Jim> via a git submodule.

I thought that submodules could not be used to share files in the
top-level directory.  This is why I think submodules are not a viable
solution for src -- anything in that directory is shared, not only by
all the src projects, but also by gcc.

Tom

Re: gdb.git mirror is broken

[Jim Meyering]

Tom Tromey wrote:
>>>>>> "Jim" == Jim Meyering <jim@meyering.net> writes:
> Jim> Since some directories are shared between projects, one way would
> Jim> be to make each directory into its own git repository.
> Jim> Then, a separate gdb.git repository would include them
> Jim> via a git submodule.
>
> I thought that submodules could not be used to share files in the
> top-level directory.  This is why I think submodules are not a viable
> solution for src -- anything in that directory is shared, not only by
> all the src projects, but also by gcc.

You can put the top-level files in their own repository and make that
a submodule, then have either a VC'd symlink for each file (ugly, and
not as maintainable, IMHO) or a bootstrap/autogen.sh-style script that
creates the links.

Re: gdb.git mirror is broken

[Joel Brobecker]

> If anyone is interested in switching primary GDB development
> to git, once such a new repository is in place and deemed stable,
> I urge you to dump CVS.  While the conversion tools are not always
> reliable, I can assure you that git itself has been amazingly reliable
> for years.

I think we're not quite ready to switch to any other version management
system right now, unfortunately. But I strongly support a switch to git.
The problem is that, for this to happen, we will have to agree to some
adjustments in one way or the other, because we won't have partial
checkouts anymore.  This will need to be discussed by the maintainers
of the various projects that are part of src, and getting an agreement
might not be an easy task, especially across projects and with using
just email... Several of us in the GDB project are very motivated in
that direction, so as soon as things quiet down a bit, we'll try to
come up with a plan and start discussing it seriously.

-- 
Joel

Re: gdb.git mirror is broken

[Eli Zaretskii]

> Date: Tue, 6 Oct 2009 08:45:37 -0700
> From: Joel Brobecker <brobecker@adacore.com>
> Cc: "H.J. Lu" <hjl.tools@gmail.com>, Tom Tromey <tromey@redhat.com>, 	GDB <gdb@sourceware.org>
> 
> > If anyone is interested in switching primary GDB development
> > to git, once such a new repository is in place and deemed stable,
> > I urge you to dump CVS.  While the conversion tools are not always
> > reliable, I can assure you that git itself has been amazingly reliable
> > for years.
> 
> I think we're not quite ready to switch to any other version management
> system right now, unfortunately. But I strongly support a switch to git.

git is a PITA on Windows, which is a major issue for me.

Re: gdb.git mirror is broken

[Joel Brobecker]

> git is a PITA on Windows, which is a major issue for me.

Oh? git has been working great on Windows for me. Which git are you
using? I've been using the one from cygwin.

-- 
Joel

Re: gdb.git mirror is broken

[Eli Zaretskii]

> Date: Tue, 6 Oct 2009 12:00:59 -0700
> From: Joel Brobecker <brobecker@adacore.com>
> Cc: jim@meyering.net, hjl.tools@gmail.com, tromey@redhat.com, 	gdb@sourceware.org
> 
> > git is a PITA on Windows, which is a major issue for me.
> 
> Oh? git has been working great on Windows for me. Which git are you
> using? I've been using the one from cygwin.

That's the point: I don't use Cygwin and don't want to install one.
The only other port of git is based on MSYS, which in many ways has
the same problems as Cygwin, as far as I'm concerned.

Re: gdb.git mirror is broken

[Joel Brobecker]

> That's the point: I don't use Cygwin and don't want to install one.
> The only other port of git is based on MSYS, which in many ways has
> the same problems as Cygwin, as far as I'm concerned.

It would be useful to explain what the same problems are, because
I am still in the dark as to what they are.

If git is not an option because you can't find a client that works
for you, then the only other realistic option we have is SVN. Do you
know of a SVN client that works for you?

-- 
Joel

Re: gdb.git mirror is broken

[Tom Tromey]

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

Joel> If git is not an option because you can't find a client that works
Joel> for you, then the only other realistic option we have is SVN.

We could run git-cvsserver.

Tom

Re: gdb.git mirror is broken

[Eli Zaretskii]

> From: Tom Tromey <tromey@redhat.com>
> Cc: Eli Zaretskii <eliz@gnu.org>, jim@meyering.net, hjl.tools@gmail.com,
>         gdb@sourceware.org
> Date: Tue, 06 Oct 2009 16:03:13 -0600
> 
> >>>>> "Joel" == Joel Brobecker <brobecker@adacore.com> writes:
> 
> Joel> If git is not an option because you can't find a client that works
> Joel> for you, then the only other realistic option we have is SVN.
> 
> We could run git-cvsserver.

If it allows write access, fine with me.

Re: gdb.git mirror is broken

[Eli Zaretskii]

> Date: Tue, 6 Oct 2009 14:10:40 -0700
> From: Joel Brobecker <brobecker@adacore.com>
> Cc: jim@meyering.net, hjl.tools@gmail.com, tromey@redhat.com,
> 	gdb@sourceware.org
> 
> > That's the point: I don't use Cygwin and don't want to install one.
> > The only other port of git is based on MSYS, which in many ways has
> > the same problems as Cygwin, as far as I'm concerned.
> 
> It would be useful to explain what the same problems are, because
> I am still in the dark as to what they are.

In a nutshell, the problem is having a heavyweight package installed
with incompatible versions of all the tools I use every day (in their
native w32 ports).

> If git is not an option because you can't find a client that works
> for you, then the only other realistic option we have is SVN. Do you
> know of a SVN client that works for you?

SVN is fine.

Re: gdb.git mirror is broken

[Tom Tromey]

Jim> However, that would have the disadvantage of changing all
Jim> existing SHA1 commit values -- which might cause problems with
Jim> the likes of archer.git.

I would rather avoid breaking archer.git.
Do we really need to make this change?  If so, why?

Tom

Re: gdb.git mirror is broken

[Jim Meyering]

Tom Tromey wrote:
> Jim> However, that would have the disadvantage of changing all
> Jim> existing SHA1 commit values -- which might cause problems with
> Jim> the likes of archer.git.
>
> I would rather avoid breaking archer.git.
> Do we really need to make this change?  If so, why?

Sounds unnecessary, now.
Initially, it sounded like H.J. required cpu/ as a subdirectory of gdb.