On Mon, May 20, 2013 at 11:26:57PM -0400, Theodore Ts'o wrote: > The inlinie data patches, which have been updated to the latest master > branch, can be found here: > > https://github.com/tytso/e2fsprogs-inline-patch-queue > > or > > git://github.com/tytso/e2fsprogs-inline-patch-queue.git > > > You can look at the history if you want to see what I've done. The > main thing to note is that while we are maintaining patches in a patch > series, and while we are still trying to clean up the function > interfaces, to fold any changes into parent patches. > > So for example, I've folded all of the gcc -Wall cleanups that had > been in "libext2fs-fix-some-warnings-from-gcc-Wall" into the patches > that introduced the gcc warnings. This makes it easier to review the > patches, since we don't have the problem of a patch which has bugs or > warnings which is fixed in a later patch. > > When I did that, I found a change which was not related to gcc -Wall > cleanups hiding in that patch. > > I think I remember seeing other places where unrelated changes were > glommed together into a single patch. As we find them, we should > split them into separate patches, again for ease of patch maintenance > and improvements. > > Again, my apologies for taking so long in getting these patches out > there. I really wanted to give you some examples in the kind of patch > factoring and interface cleanups that I was hoping for before merging > this support upstream. Unfortuantely, I've been crazy busy these last > few weeks. I had hoped to put more work into this today, but I lost > at least two hours due to a burst gas main which forced the > evacuations of the offices. :-( > > (Turns out it's not just network fibers which emit backhoe pheromones, > gas mains do as well. :-) > > I'll let you take the next whack at improving the patches. My > suggestion is that you create your own github repository, and update > the patches using git. What I generally do is to apply the patches > using guilt (I suggest using v0.35 from git://repo.or.cz/guilt.git) by > pulling down the github repository into an e2fsprogs repository at > ".git/patches/inline". Then take a look at first line of > .git/patches/inline/series, which currently reads: > > # BASE 4cf7a7014a209b82aada9b5d83ecdb9b07e60a1a > > In the top of the e2fsprogs repository, type the commands: > > % pushd .git/patches/inline ; sh timestamps ; popd > % git branch inline 4cf7a7014a209b82aada9b5d83ecdb9b07e60a1a > % git checkout inline > % guilt push -a > > This will apply all of the patches in .git/patches/inline (which you > pulled down from github) to the e2fsprogs tree. You can go back and > forth by using the commands "guilt pop" and "guilt push". To modify a > patch, just edit the e2fsprogs files, and then use the command "guilt > refresh --diffstat" to merge your edits into the patch file. You can > then commit changes to the patch queue by cd'ing into > .git/patches/inline directory, and running standard "git commit" > commands. This way, when you send me an updated set of patches, I can > look at the git log to see what changes you've made. > > Does this make sense? If not, please feel free to send me any > questions you have. Hi Ted, Definitely it makes sense to me. I really appreciate and thank you for your suggestion. Yes, I have used guilt to manage my patches for a long time. That is really useful for me. I will revise every single commit, and improve them. Thanks, - Zheng -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
