Hello everyone, As part of moving toward mainline, I''ve changed the Btrfs repositories over to git. So far I''ve only converted the unstable repositories (thanks to some help from David Woodhouse, who already had -git forms of things). The progs-unstable repo is a direct clone of David''s git repo. The kernel one has btrfs grafted into fs/btrfs. All compatibility code for older kernels has been removed. I''ll construct repos in git of btrfs as a stand alone module, and that will include the compatibility code. These git repos are not yet final, I may rebase them or redo them. But, all new patches are going into them instead of the mercurial repos. Please give them a look and let me know if I''ve messed up the conversion: Kernel: http://git.kernel.org/?p=linux/kernel/git/mason/btrfs-unstable.git;a=summary Progs: http://git.kernel.org/?p=linux/kernel/git/mason/btrfs-progs-unstable.git;a=summary -chris -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, 2008-09-24 at 15:02 -0400, Chris Mason wrote:> Hello everyone, > > As part of moving toward mainline, I''ve changed the Btrfs repositories > over to git. So far I''ve only converted the unstable repositories > (thanks to some help from David Woodhouse, who already had -git forms of > things). > > The progs-unstable repo is a direct clone of David''s git repo. The > kernel one has btrfs grafted into fs/btrfs. All compatibility code for > older kernels has been removed. > > I''ll construct repos in git of btrfs as a stand alone module, and that > will include the compatibility code. > > These git repos are not yet final, I may rebase them or redo them. But, > all new patches are going into them instead of the mercurial repos. >Well, after some hints from Linus I''ve rebased these about 4 times now. The new changesets are generally cleaner and are setup properly under fs/btrfs. So, if you were using a tree pulled before Thursday afternoon, please delete it and clone again. The btrfs-progs repo is unchanged.> Kernel: > > http://git.kernel.org/?p=linux/kernel/git/mason/btrfs-unstable.git;a=summary > > Progs: > > http://git.kernel.org/?p=linux/kernel/git/mason/btrfs-progs-unstable.git;a=summary >-chris -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> Well, after some hints from Linus I''ve rebased these about 4 times now. > The new changesets are generally cleaner and are setup properly under > fs/btrfs.Can you publish these hints somewhere? - z -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, 2008-09-25 at 14:25 -0700, Zach Brown wrote:> > Well, after some hints from Linus I''ve rebased these about 4 times now. > > The new changesets are generally cleaner and are setup properly under > > fs/btrfs. > > Can you publish these hints somewhere?Step one was to have all the changes from hg in git. David Woodhouse has been maintaining git copies of the btrfs repos for a while, so that part was done for me. Most of the hints come from man git-filter-branch. Here''s what was wrong with the btrfs repos. 1) The btrfs repo had .hgtags and .hginore files in the changeset history. This wasn''t horrible, but not too pretty. 2) Almost none of the changesets had Signed-off-by 3) The filenames needed to be rewritten under fs/btrfs. ---- For 1) the man page said to: git filter-branch --index-filter ´git rm -f --cached filename´ HEAD Which certainly did print output, but didn''t actually change the changesets. Instead I used the slightly slower suggestion: git filter-branch -f --tree-filter ´rm -f filename´ HEAD For 2) I made a script that added a signed-off-by from me for any changeset that didn''t have it. myfilter is called with the old commit message on stdin and the new message is taken from stdout. git filter-branch -f --msg-filter myfilter HEAD For 3) Linus provided a pretty little piece of bash: #!/bin/sh exists=$(git ls-files fs/btrfs/) [ -z "$exists" ] && git ls-files --stage | awk -F ''\t'' ''{ print "0 0000000000000000000000000000000000000000\t" $2 "\n" $1 "\tfs/btrfs/" $2 }'' | git update-index --index-info You toss this into a script and then run: git filter-branch -f --index-filter hack-from-linus HEAD At this point you should have shiny new commits in a git repo, all pretending to be under fs/btrfs. You merge them into a git repo from mainline and all should be good. Linus requested that I not merge at a random changeset of the day, but use a real release. He also asked that I not pull from mainline into the linux btrfs repo (a backwards merge) because that makes gitk make ugly pictures. In general unless there''s a conflict there''s no need to update the mainline side of the btrfs repo. -chris -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html