Re: Acceptance criteria for the git conversion

On 09/03/2015 02:59 AM, Trevor Saunders wrote: On Tue, Sep 01, 2015 at 06:06:33PM +0200, Andreas Schwab wrote: "Eric S. Raymond" writes: There is no way to maintain those links for git, so yes, you want to keep a read-only Subversion instance around. The mapping can also be put in some git

Re: Acceptance criteria for the git conversion

On Thu, 3 Sep 2015, shmeel gutl wrote: > I am working from a clone of the current git repository. Is there an automated > procedure that will enable me to switch to the new repository and still keep > all of the commit history of my local branches? Well, the "git fetch" command I proposed in

Re: Acceptance criteria for the git conversion

"Eric S. Raymond" writes: > (I'm pretty sure there's also a way to do this using the obscure "git bundle" > feature, but I've never learned it in detail.) git bundle cannot help here because it cannot rewrite commits. It's just an implementation of the git protocol over some unspecified file tr

Re: Acceptance criteria for the git conversion

shmeel gutl writes: > I am working from a clone of the current git repository. Is there an > automated procedure that will enable me to switch to the new repository > and still keep all of the commit history of my local branches? The easiest way to do that is to fetch the new repository into you

Re: Acceptance criteria for the git conversion

shmeel gutl : > On 01-Sep-15 01:54 PM, Eric S. Raymond wrote: > >What kind of mechanical transformation or hand-editing would add value for > >you? > I am working from a clone of the current git repository. Is there an > automated procedure that will enable me to switch to the new repository and >

Re: Acceptance criteria for the git conversion

On 01-Sep-15 01:54 PM, Eric S. Raymond wrote: What kind of mechanical transformation or hand-editing would add value for you? I am working from a clone of the current git repository. Is there an automated procedure that will enable me to switch to the new repository and still keep all of the co

Re: Acceptance criteria for the git conversion

On Tue, Sep 01, 2015 at 06:06:33PM +0200, Andreas Schwab wrote: > "Eric S. Raymond" writes: > > > There is no way to maintain those links for git, so yes, you want to > > keep a read-only Subversion instance around. > > The mapping can also be put in some git notes tree for use by bugzilla. > Th

Re: Acceptance criteria for the git conversion

On Tue, 1 Sep 2015, David Malcolm wrote: > Caution: this script performs numerous URL GETs on gcc.gnu.org; > it caches everything, but the first time you run it, the cache > will be cold. (So please be careful!) It may be better to rsync the whole archive (gcc.gnu.org::gcc-patches-ml-archive) f

Re: Acceptance criteria for the git conversion

David Malcolm : > > Still, if anyone else is brave enough to write a script that will munch > > through gcc-patches producing committer/date/subject-line triples, I'll > > give it a try. > > I don't think committer/date/subject-line triples are adequate: the > dates are unlikely to match up, for o

Re: Acceptance criteria for the git conversion

On Tue, 2015-09-01 at 11:30 -0400, Eric S. Raymond wrote: > Joseph Myers : > > With 227369 revisions I don't think adding git-style summary lines is > > really practical without some very reliable automation to match commits to > > corresponding gcc-patches messages (whose Subject: headers would

Re: Acceptance criteria for the git conversion

On Tue, 1 Sep 2015, Mikhail Maltsev wrote: > Actually, I did not propose to alter the repository history. I just > meant to say that if .c -> .cc renaming is still planned, it could be > done right after conversion, as a normal commit, or, perhaps series of > commits on trunk and active develop

Re: Acceptance criteria for the git conversion

On 09/01/2015 08:11 PM, Joseph Myers wrote: > On Tue, 1 Sep 2015, Richard Earnshaw wrote: > >> Renaming the files during the conversion is clearly *not* the right >> thing to do: it would break all builds of old code. > > Indeed. Ideally the tree objects in the git conversion should have > exac

Re: Acceptance criteria for the git conversion

On Tue, 1 Sep 2015, Eric S. Raymond wrote: > Joseph Myers : > > Indeed. Ideally the tree objects in the git conversion should have > > exactly the same contents as SVN commits, and so be shared with the > > git-svn history to reduce the eventual repository size (except where there > > are defe

Re: Acceptance criteria for the git conversion

Joseph Myers : > Indeed. Ideally the tree objects in the git conversion should have > exactly the same contents as SVN commits, and so be shared with the > git-svn history to reduce the eventual repository size (except where there > are defects in the git-svn history, or the git conversion fixe

Re: Acceptance criteria for the git conversion

On Tue, 1 Sep 2015, Richard Earnshaw wrote: > Renaming the files during the conversion is clearly *not* the right > thing to do: it would break all builds of old code. Indeed. Ideally the tree objects in the git conversion should have exactly the same contents as SVN commits, and so be shared w

Re: Acceptance criteria for the git conversion

"Eric S. Raymond" writes: > There is no way to maintain those links for git, so yes, you want to > keep a read-only Subversion instance around. The mapping can also be put in some git notes tree for use by bugzilla. That would only need to be set up once. Andreas. -- Andreas Schwab, SUSE Labs

Re: Acceptance criteria for the git conversion

David Malcolm : > > What kind of mechanical transformation or hand-editing would add value for > >you? > > Will the resulting git commits have some kind of metadata identifying > the corresponding SVN revision? That's what the --legacy option does. I think Jason plans to use it. I've noted prev

Re: Acceptance criteria for the git conversion

Joseph Myers : > With 227369 revisions I don't think adding git-style summary lines is > really practical without some very reliable automation to match commits to > corresponding gcc-patches messages (whose Subject: headers would be the > natural choice for such summary lines) In this case

Re: Acceptance criteria for the git conversion

On Tue, Sep 1, 2015 at 10:26 AM, Mikhail Maltsev wrote: > On 09/01/2015 01:54 PM, Eric S. Raymond wrote: >> With the machinery for the git conversion now in reasonable shape, it's >> time to ask GCC's developers in general: what do you want this >> conversion to accomplish? > There was some discu

Re: Acceptance criteria for the git conversion

On 01/09/15 15:26, Mikhail Maltsev wrote: > On 09/01/2015 01:54 PM, Eric S. Raymond wrote: >> With the machinery for the git conversion now in reasonable shape, it's >> time to ask GCC's developers in general: what do you want this >> conversion to accomplish? > There was some discussion concernin

Re: Acceptance criteria for the git conversion

On 09/01/2015 01:54 PM, Eric S. Raymond wrote: > With the machinery for the git conversion now in reasonable shape, it's > time to ask GCC's developers in general: what do you want this > conversion to accomplish? There was some discussion concerning file renaming: https://gcc.gnu.org/ml/gcc/2015-

Re: Acceptance criteria for the git conversion

On Tue, 2015-09-01 at 06:54 -0400, Eric S. Raymond wrote: > With the machinery for the git conversion now in reasonable shape, it's > time to ask GCC's developers in general: what do you want this > conversion to accomplish? > > There are some obvious things we might expect it to accomplish, like

Re: Acceptance criteria for the git conversion

Joseph Myers writes: > On Tue, 1 Sep 2015, Eric S. Raymond wrote: > >> As a trivial example of the possibilities, sometimes when I do conversions >> I fix obvious comment typos. I generally have to edit the comment history >> anyway >> to tweak comments that don't have git-style summary lines int

Re: Acceptance criteria for the git conversion

On Tue, 1 Sep 2015, Eric S. Raymond wrote: > As a trivial example of the possibilities, sometimes when I do conversions > I fix obvious comment typos. I generally have to edit the comment history > anyway > to tweak comments that don't have git-style summary lines into shape, so > fixing typos is

Acceptance criteria for the git conversion

With the machinery for the git conversion now in reasonable shape, it's time to ask GCC's developers in general: what do you want this conversion to accomplish? There are some obvious things we might expect it to accomplish, like (1) Encouraging people to do finer-grained commits because the ope