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
Converting kernel svn to git
We've been talking about this for at least 6 years, and it's well past
time to do it.
(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 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/
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
Ben.
--
Ben Hutchings
If God had intended Man to program,
we'd have been born with serial I/O ports.
signature.asc
Description: This is a digitally signed message part
