src.git test repository

src.git test repository

[Tom Tromey]

I've made a src.git test repository for testing.  Please try it out.

The new repository came in much smaller than I thought: 196M.
My checked-out tree is 506M.

You can get it in the usual ways.  I used:

    git clone ssh://sourceware.org/git/src.git

I think "git://" works as well; not sure about http transport.

Note that I made this repository last week, before I did most of the
requested email address updates.


This repository was made by a rather complicated process.  I stitched
together Pedro's git repository holding very old (pre-devo) gdb
releases, a somewhat edited snapshot of devo that I got from Ian and
Nick, and of course "src".

All the helper scripts and associated hacks I wrote are available in a
git repository here:

    https://github.com/tromey/gdb-git-migration

If you're interested in the details, the code is all there.


I believe the "src" CVS repository was created in a funny way.  I could
not find a tag in devo indicating when it was exported, and Stan says
that he remembers importing gdb 4.18 as the baseline.  That's mildly
bad, since it means that the src master was created from a branch; but
on top of that I think that binutils was imported separately, about a
month later.

This means there is no stable baseline onto which to graft the "src"
repository.

So, I chose to use the gdb 4.18 branchpoint from devo as the graft
point.  All revisions on devo's master after this point have been moved
off to a new "devo-after-sourceware-migration" branch.

What this means is that there are some commits around that point that
look a bit odd, and if you need to do archaeology around that point in
1999 then you are going to have to do some extra digging.


The devo snapshot I was given was a bit edited.  It mentions many
branches, most of which I think are not especially relevant -- and many
of which contain no genuinely useful commits.  I chose to filter out
most branches, leaving just a few obviously relevant ones.


This repository has all the configuration bits in it that I expect to
use in the final conversion -- email hooks, bugzilla hooks, etc.  Please
be aware of that if you make any changes.  (I intend to test all these
things live sometime this week.  So far they've only been tested
piecemeal on my machine.)

This is not the final repository.  As I noted above, at least the email
addresses weren't all updated at the time of conversion.  Any changes
you make in this repository will be lost when I reconvert it.  I realize
we're missing a prime opportunity for April Fool's jokes here, but I
didn't want to wait another 6 months.


Please report any problems to me.  I encourage everyone to look through
the history and branches and see whether everything you expect is there;
and to explore the history and see whether I've made any correctable
errors.

Tom

Re: src.git test repository

[Eli Zaretskii]

> From: Tom Tromey <tromey@redhat.com>
> CC: GDB Development <gdb@sourceware.org>
> Date: Mon, 07 Oct 2013 09:19:09 -0600
> 
> I've made a src.git test repository for testing.  Please try it out.

Thanks.

> The new repository came in much smaller than I thought: 196M.
> My checked-out tree is 506M.
> 
> You can get it in the usual ways.  I used:
> 
>     git clone ssh://sourceware.org/git/src.git
> 
> I think "git://" works as well; not sure about http transport.

ssh:// or git+ssh:// (or are they equivalent?)?

Re: src.git test repository

[Tom Tromey]

Tom> I think "git://" works as well; not sure about http transport.

Eli> ssh:// or git+ssh:// (or are they equivalent?)?

I believe ssh and git+ssh are the same thing.
Plain "git://" uses the git protocol.  On sourceware this can only be
used for cloning, not pushing.

Tom

Re: src.git test repository

[H.J. Lu]

On Mon, Oct 7, 2013 at 8:19 AM, Tom Tromey <tromey@redhat.com> wrote:
> I've made a src.git test repository for testing.  Please try it out.
>
> The new repository came in much smaller than I thought: 196M.
> My checked-out tree is 506M.
>
> You can get it in the usual ways.  I used:
>
>     git clone ssh://sourceware.org/git/src.git
>
> I think "git://" works as well; not sure about http transport.
>
> Note that I made this repository last week, before I did most of the
> requested email address updates.
>
>
> This repository was made by a rather complicated process.  I stitched
> together Pedro's git repository holding very old (pre-devo) gdb
> releases, a somewhat edited snapshot of devo that I got from Ian and
> Nick, and of course "src".
>

I noticed that binutils-2_24-branch only has binutils source.
How will binutils-2_25-branch be made?  Will it include gdb
source?


H.J.

Re: src.git test repository

[Tom Tromey]

HJ> I noticed that binutils-2_24-branch only has binutils source.
HJ> How will binutils-2_25-branch be made?  Will it include gdb
HJ> source?

It's up to the binutils developers.

What I recommend is branching the whole repository and then doing
tarball releases of a subset of the branch, using the usual src-release
mechanism.

Tom

Re: src.git test repository

[Iain Sandoe]

Hi Tom,

thanks for doing this!

On 7 Oct 2013, at 17:56, Tom Tromey wrote:

> HJ> I noticed that binutils-2_24-branch only has binutils source.
> HJ> How will binutils-2_25-branch be made?  Will it include gdb
> HJ> source?
> 
> It's up to the binutils developers.
> 
> What I recommend is branching the whole repository and then doing
> tarball releases of a subset of the branch, using the usual src-release
> mechanism.

I had a go this evening (with success) doing the following:

cloned src 
built a sparse checkout by hand for 'binutils'
and built a cross from x86-64-darwin12 -> powerpc-linux-gnu

All seems OK, but I think I lost track of where the discussion had got to on sparse checkouts, building the .git/info/sparse-checkout file by hand is tedious.

somewhere to put the recipes/defaults corresponding to the existing checkouts would be handy.
or did I miss it?
Iain

Re: src.git test repository

[Tom Tromey]

>>>>> "Iain" == Iain Sandoe <iain@codesourcery.com> writes:

Iain> somewhere to put the recipes/defaults corresponding to the existing
Iain> checkouts would be handy.
Iain> or did I miss it?

I don't really think that's a good way to work, or something that should
be supported, so I didn't investigate how to write it.  The way we
discussed on the list is to use top-level configure arguments to disable
building various components.

Tom

Re: src.git test repository

[Iain Sandoe]

Hi Tom,

On 9 Oct 2013, at 02:29, Tom Tromey wrote:

>>>>>> "Iain" == Iain Sandoe <iain@codesourcery.com> writes:
> 
> Iain> somewhere to put the recipes/defaults corresponding to the existing
> Iain> checkouts would be handy.
> Iain> or did I miss it?
> 
> I don't really think that's a good way to work, or something that should
> be supported, so I didn't investigate how to write it.  The way we
> discussed on the list is to use top-level configure arguments to disable
> building various components.

ah, that's the bit I missed - and, indeed, a better solution,
thanks,
Iain

Re: src.git test repository

[Tom Tromey]

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

Tom> I've made a src.git test repository for testing.  Please try it out.

Tom> This repository has all the configuration bits in it that I expect to
Tom> use in the final conversion -- email hooks, bugzilla hooks, etc.  Please
Tom> be aware of that if you make any changes.

One note here is that I am still considering a hook to reject merge
commits.

The rationale for this is that merge commits are ugly, and that it isn't
a big deal to require a rebase before a merge, so that any merge is a
fast-forward.

I think it isn't onerous to follow this rule for all branches -- there
being plenty of options for git hosting where you can go nuts -- but of
course I welcome your considered reasons to think otherwise.

Tom> (I intend to test all these things live sometime this week.  So far
Tom> they've only been tested piecemeal on my machine.)

I've done various test commits and pushes and I think these scripts are
working adequately well.

If you want to see the current format of the commit messages, look at
one of the "cvs" mailing lists.  E.g.:

    https://sourceware.org/ml/gdb-cvs/2013-10/msg00062.html


We can make changes to the format if desired.  I tried to keep pretty
much the same information that was in the old CVS commit message, though
I didn't attempt to exactly mimic the format.


Commits mentioning PRs also go to bugzilla.  See my test PR for an
example:

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

The format for bugzilla can differ from the format for the commit-list
message, but I chose to keep them the same.  Again, changeable.

Tom

Re: src.git test repository

[Joel Brobecker]

> One note here is that I am still considering a hook to reject merge
> commits.
> 
> The rationale for this is that merge commits are ugly, and that it isn't
> a big deal to require a rebase before a merge, so that any merge is a
> fast-forward.

This has my support. We've found at AdaCore that unexperienced users
will often create merges unintentionally, and then push them without
even ever noticing it. The typical case is forgetting to add --rebase
in their "git pull" when they want to push a commit and find that
their repo is out of date.

There will be issues with special-feature development branches, however.
Let's say, for instance, that people want to collaborate on a certain
feature, and use a branch for its development. If development takes
a while, they might want to do regular merges from HEAD... We can adjust
the rule to say that merges are verbotten except on branches whose name
is prefixed by Eg. "topic/".

> I've done various test commits and pushes and I think these scripts are
> working adequately well.

Agreed.

For future enhancements open for consideration (and I may actually take
care of those myself), my only regrets are:

  - we seem to be getting one email per push, instead of one email
    per commit?

  - If we received one email per commit, we could put the subject
    of the commit as the subject of the email

Something that should also be reasonably easy to implement:

  - Style check the revision log to forbid commits if the second
    line (line after subject) is not empty. I have found that
    this assumption is too ingrained everywhere in git, and that
    not respecting it makes things look bad.

-- 
Joel

Re: src.git test repository

[Tom Tromey]

Joel> There will be issues with special-feature development branches, however.
Joel> Let's say, for instance, that people want to collaborate on a certain
Joel> feature, and use a branch for its development. If development takes
Joel> a while, they might want to do regular merges from HEAD... We can adjust
Joel> the rule to say that merges are verbotten except on branches whose name
Joel> is prefixed by Eg. "topic/".

Perhaps just prohibiting them on master is enough?

Joel>   - we seem to be getting one email per push, instead of one email
Joel>     per commit?

I checked, and yeah, this is what happens.

I think I can change that, if you want.

Joel>   - Style check the revision log to forbid commits if the second
Joel>     line (line after subject) is not empty. I have found that
Joel>     this assumption is too ingrained everywhere in git, and that
Joel>     not respecting it makes things look bad.

While I agree that we ought to adopt a more git-ish commit style, this
goes against my early plan of making as few "extra" change to our
processes as possible.  I was leaving all non-essential change proposals
for later, to avoid complicating the switchover.

I guess if enough people +1 the idea I will do it.

Tom

Re: src.git test repository

[Joel Brobecker]

> Joel> There will be issues with special-feature development branches, however.
> Joel> Let's say, for instance, that people want to collaborate on a certain
> Joel> feature, and use a branch for its development. If development takes
> Joel> a while, they might want to do regular merges from HEAD... We can adjust
> Joel> the rule to say that merges are verbotten except on branches whose name
> Joel> is prefixed by Eg. "topic/".
> 
> Perhaps just prohibiting them on master is enough?

We could certainly start with that. I'd maybe also include
known branch patterns, such as the branches used for GDB and
binutils releases.

> Joel>   - we seem to be getting one email per push, instead of one email
> Joel>     per commit?
> 
> I checked, and yeah, this is what happens.
> 
> I think I can change that, if you want.
> 
> Joel>   - Style check the revision log to forbid commits if the second
> Joel>     line (line after subject) is not empty. I have found that
> Joel>     this assumption is too ingrained everywhere in git, and that
> Joel>     not respecting it makes things look bad.
> 
> While I agree that we ought to adopt a more git-ish commit style, this
> goes against my early plan of making as few "extra" change to our
> processes as possible.  I was leaving all non-essential change proposals
> for later, to avoid complicating the switchover.
> 
> I guess if enough people +1 the idea I will do it.

Just to make sure that there is no misunderstanding: I don't think
we should tie these possible enhancements (presented as ideas to
be discussed later), to the actually switch to git. I think the
scripts and emails are already plenty good enough.

So I wouldn't rush on doing anything. When the time comes, and if
some of the the ideas gains ground, I can try helping with at least
some of those.

Likewise for the check preventing merges.

Thanks, Tom :)
-- 
Joel