Re: gdb.git mirror is broken

[Jim Meyering <jim at meyering dot net>]

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.