For folks who want to follow along with the 64-bit e2fsprogs
integration effort.
- Ted
--- Begin Message ---
On Tue, Feb 03, 2009 at 02:27:54AM -0500, Valerie Aurora Henson wrote:
> Hey Ted,
>
> Eric said something about my 64-bit patches being against the wrong
> branch. What should I base them against? My goal is to get some
> subset of the patches into some branch in your repo - I'm happy with
> any branch and any number.
Not your fault; the issue was the "pu" branch hadn't been updated in a
long time, and it had some 64-bit patches that you needed to base your
work on. So you did the right thing; it was just that the "pu" branch
was based on somethig around the time of e2fpsrogs 1.41.1, and there
had been a lot of other fix-ups that had gone in since then.
I thought you were out due to your shoulder surgery, so I've already
rebased your patches; to see what I've done, take a look at:
http://github.com/tytso/e2fsprogs-64bit/tree/master
git://github.com/tytso/e2fsprogs-64bit.git
(This was my excuse to play with github; previously I had used
git.or.cz for the ext4 patch queue).
This is a patch series based off of e2fsprogs 1.41.4. It includes the
'pu' proposed update patches, plus your patches, rebased against the
latest e2fsprogs development head.
It is a patch series because some of the patches clearly need cleanup
and refactorization. For example, you had fixed some bugs in Jose's
64-bit_mke2fs_cleanup patch, that should be merged into his patch.
For another, what's up with "0031-temporary-check-about-to-checksum-
conversion.patch"? :-)
I also suspect there may be places where I've added some old interface
since 1.41.1 that would therefore not be caught in your patches, which
is another reason why the patches will need updating after the
rebasing effort.
So... the way I use this patch set is via a tool called "guilt":
git://git.kernel.org/pub/scm/linux/kernel/git/jsipek/guilt.git
http://git.kernel.org/?p=linux/kernel/git/jsipek/guilt.git
Works just like quilt, in that you can use "guilt push", "guilt pop",
etc. I like it because as you push and pop commits, they are real
commits in git, so I can review them via "git log", and make sure the
commit changelogs make sense. "git grep" works, "git log -p", "git
log --stat", etc.
If you want to use guilt, after installing it, do:
% cd /usr/projects/e2fsprogs <---- replace w/ your e2fsprogs repo
% mkdir .git/patches; pushd .git/patches
% git clone git://github.com/tytso/e2fsprogs-64bit.git shared-64bit
% cp /dev/null shared-64bit/status
% popd
% ln -s .git/patches/shared-64bit patches <---- optional, for convenience
% git checkout -b shared-64bit v1.41.4
% guilt push -a
You can also use quilt if you like, in that case, just drop the
contents of the patch tree repo in the top-level "patches" directory.
If you sign up to github, I'll add you to the access list so you can
also push updates to the patch queue. That way we can work together
on cleaning up the patch series, and as things are ready at the
beginning of the queue, I'll merge it into mainline and then we can
delete them from the patch series.
This is the workflow that we developed for the ext4 patch queue, and
it worked really well, with Mingming, Eric,and I having access to the
ext4 patch queue for kernel patches. That way they could queue up
their patches, and afterwards multiple people could edit and refine
the patches so they could be made ready to be pushed into mainline.
IIRC Eric uses guilt, although Mingming prefers to use raw quilt.
Either works.
Sound like a plan?
- Ted
--- End Message ---
