This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: gdb.git mirror is broken
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.