Re: Converting kernel svn to git
On Wed, 2015-08-05 at 12:46 +0100, Ben Hutchings wrote: [...] > Here's where I am with the conversion: > https://anonscm.debian.org/cgit/kernel/temp/ I've made many fixes to the scripts today, and pushed them and the results to there. There's only one bug I'm aware of that I think is necessary to fix (see below). I haven't looked at the hook scripts yet, but I assume that replacing them under git will be quite easy. That leaves .gitignore. How should we set up .gitignore for the root directory when it's already shipped by upstream? Should we strip it from the orig tarball and replace it, or should we patch it (as we already do)? > Known bugs: > > linux.git > - > > Commits tagged 2.6.12-2, 2.6.16-{15,16,17}, 2.6.18.dfsg.1-24etch2, > 2.6.26-{17,20} are detached. Fixed. > Several weird merges in early history. > > Many merges in svn are not recorded in git, but this is presumably due > to lack of mergeinfo in old svn versions. Not fixed, but not that important. > Commit tagged 2.6.24-7 looks like a 4-way merge which shouldn't be > possible in svn! This might be due to svn mergeinfo accumulating > branches. Fixed - all but the first two parents are dropped. > linux-latest.git > > > Tip of wheezy branch is detached from its parent Fixed. > Many merges from sid to wheezy-backports are not recorded Not fixed, but not that important. > No squeeze branch Fixed. > linux-tools.git > --- > > Many merges from sid to trunk are not recorded Not fixed, and I would like to do so as this makes the history rather harder to understand. > firmware-nonfree.git > > > Tip of wheezy branch is detached from its parent Fixed. > What do we do with the sid branch? I made it part of the wheezy branch. > The 0.19 tag is in a firmware-nonfree subdirectory Fixed. > Merge before 0.4+etchnhalf.1 should not be recorded as a merge Not fixed, but not that important. Ben. -- Ben Hutchings Theory and practice are closer in theory than in practice. - John Levine, moderator of comp.compilers signature.asc Description: This is a digitally signed message part
Re: Converting kernel svn to git
On Mon, 2015-08-10 at 13:01 -0700, maximilian attems wrote: > On Thu, Aug 06, 2015 at 06:10:01PM +0100, Ben Hutchings wrote: > > > > No, I want that history and a break in history will just make my life > > harder. If you only want some of the branches you can get those. > > Ok, so let's go for history. > > > > > Known bugs: > > [...] > > > On the other hand, none of the known bugs you mention is a show-stopper > > > for the transition from my side. > > > > Yes but they would be harder to fix later. (git filter-branch is > > powerful but it invalidates everyone else's clones.) > > can you fix some of them in svn (preimport)? or does it need git-filter > changes? > Either git-filter-branch or changes to the svn2git rules. I have most of these fixed now and am adding some more sanity checks. Ben. -- Ben Hutchings I say we take off; nuke the site from orbit. It's the only way to be sure. signature.asc Description: This is a digitally signed message part
Re: Converting kernel svn to git
On Thu, Aug 06, 2015 at 06:10:01PM +0100, Ben Hutchings wrote: > > No, I want that history and a break in history will just make my life > harder. If you only want some of the branches you can get those. Ok, so let's go for history. > > > Known bugs: > [...] > > On the other hand, none of the known bugs you mention is a show-stopper > > for the transition from my side. > > Yes but they would be harder to fix later. (git filter-branch is > powerful but it invalidates everyone else's clones.) can you fix some of them in svn (preimport)? or does it need git-filter changes? -- maks -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150810200147.GA7913@gluino
Re: Converting kernel svn to git
On Wed, 2015-08-05 at 16:01 -0700, maximilian attems wrote: [...] > > I started on a conversion that would include stitching in the upstream > > history for the linux package, but that depends on how we store patches > > in git and there isn't yet an obvious winner there (git-dpm vs git > > -debcherry vs dgit vs ...). If the patches should be applied as git > > commits, then we can't represent all of history because sometimes the > > patches didn't apply. And featuresets don't fit into this at all. > > > > I think that the best thing to do now is to do a straight conversion of > > the debian directory only. We can stitch in upstream later. > > > > Here's where I am with the conversion: > > https://anonscm.debian.org/cgit/kernel/temp/ > > cool. > > One proposition why not keep this as linux-debian-history-git > and start from scratch with what is inside of the latest svn. > This would reduce the number of branches and tags and might > be a cleaner restart. What do you think? No, I want that history and a break in history will just make my life harder. If you only want some of the branches you can get those. > > Known bugs: [...] > On the other hand, none of the known bugs you mention is a show-stopper > for the transition from my side. Yes but they would be harder to fix later. (git filter-branch is powerful but it invalidates everyone else's clones.) Ben. -- Ben Hutchings Sturgeon's Law: Ninety percent of everything is crap. signature.asc Description: This is a digitally signed message part
Re: Converting kernel svn to git
Hello everyone, On Wed, Aug 05, 2015 at 12:46:47PM +0100, Ben Hutchings wrote: > We've been talking about this for at least 6 years, and it's well past > time to do it. thanks a lot Ben for pushing this. > (I think most developers are already using git-svn, but that doesn't > properly handle tags and merges so I've never been able to make use of > it.) I'd be delighted to fully forget svn usage, as git svn is still a foreign git. > I started on a conversion that would include stitching in the upstream > history for the linux package, but that depends on how we store patches > in git and there isn't yet an obvious winner there (git-dpm vs git > -debcherry vs dgit vs ...). If the patches should be applied as git > commits, then we can't represent all of history because sometimes the > patches didn't apply. And featuresets don't fit into this at all. > > I think that the best thing to do now is to do a straight conversion of > the debian directory only. We can stitch in upstream later. > > Here's where I am with the conversion: > https://anonscm.debian.org/cgit/kernel/temp/ cool. One proposition why not keep this as linux-debian-history-git and start from scratch with what is inside of the latest svn. This would reduce the number of branches and tags and might be a cleaner restart. What do you think? > Known bugs: > > linux.git > - > > Commits tagged 2.6.12-2, 2.6.16-{15,16,17}, 2.6.18.dfsg.1-24etch2, > 2.6.26-{17,20} are detached. > > Several weird merges in early history. > > Many merges in svn are not recorded in git, but this is presumably due > to lack of mergeinfo in old svn versions. > > Commit tagged 2.6.24-7 looks like a 4-way merge which shouldn't be > possible in svn! This might be due to svn mergeinfo accumulating > branches. > > linux-latest.git > > > Tip of wheezy branch is detached from its parent > > Many merges from sid to wheezy-backports are not recorded > > No squeeze branch > > linux-tools.git > --- > > Many merges from sid to trunk are not recorded > > firmware-nonfree.git > > > Tip of wheezy branch is detached from its parent > > What do we do with the sid branch? > > The 0.19 tag is in a firmware-nonfree subdirectory > > Merge before 0.4+etchnhalf.1 should not be recorded as a merge On the other hand, none of the known bugs you mention is a show-stopper for the transition from my side. kind regards, -- maks signature.asc Description: Digital signature