On 10/31/2007 09:57 AM, Ramagudi Naziir wrote:
On 10/31/07, Rene Herman <rene.herman@xxxxxxxxxxxx> wrote:
Quilt is tool to manage a stack of patches. You push and pop patches
and there's always one on top. I've used it a while, but did not find
it to be very handy for managing trees you do actual development in.
Working on anything but the patch on top of the stack is somewhere
between impossible and ill adviced with it, and I frequently found
myself realizing I needed to work on earlier patches a bit more. You
then have to pop everything that's on top, work, commit, push all the
others again (and suffering maybe massive recompiles due to touching
many files...) and so on.
This is the same problem I have with git (I have never tried quilt). How
can you work an an earlier patch in git ? I also do exactly what you said
- I pop everything on top... work.. commit.. push back all others... do
you have a way to do this otherwise using git ?
Well, firstly, I use seperate branches for most anything. My master branch
tracks linus' tree but I'm only on that branch when I want to upgrade to a
new upstream which I don't do daily or anything. I branch off for anything
conceptually seperate and have a "local" branch that pulls in all the other
branches that contains work I want to compile, and which generates the
kernel I run.
I usually branch of at a full release:
<at the master branch>
git branch foo v2.6.23
git branch bar v2.6.23
git branch local v2.6.23
git checkout foo
<work on foo>
git checkout bar
<work on bar>
git checkout local
git pull . foo
git pull . bar
Now, admittedly, more often than not switching branches triggers unwelcome
amounts of recompiles as well (kbuild/make should really grow a checksum
based change detection or I should start using ccache).
The bit above where I complained about the stacking nature of quilt for me
is actually mostly solved by this already since the popping/pushing was for
me mostly caused by going to work on a different feature which now resides
in a different branch -- the new topic is a "git checkout topic" away and
within one single topic, the top-most patch does tend to be the one you want
to work on.
git reset --soft HEAD^
<fix>
git commit -a -c ORIG_HEAD
is what I'd use for that. If I already pulled the branch into that "local"
merge branch, I'd also reset that one to before pulling the branch in, but
this doesn't normally happen. If instead of using reset, you'd use revert,
you wouldn't need to worry about that.
Simpler still is just not resetting/reverting anything but simply placing a
fix on top (which ofcourse also works for fixes intended for non-HEAD
commits). When you publish the tree/branch you have the problem of
advertising your chaotic nature through the history if you do this, but I
haven't been publishing -- and better, with the help of git reset you can
shuffle quite a few things around after the fact anyway:
<work>
git commit -a -m "snoovelmuz: crank up regel widget"
<ah crap>
git commit -a -m "snoovelmuz: forgot the crank"
<oh shit>
git commit -a -m "snoozelmuz: _regel_ widget I said"
<sigh>
git reset --soft HEAD~3
git commit -a -m "snoozelwuz: crank up regel widget"
At this point, noone's any the wiser about me needing three attempts to get
that right. Ha!
If you do really want to redo patches that are further down even within a
single topic, git doesn't provide much added value over any other system I
believe, but I suspect that you just have lots of unrelated stuff and
haven't been making extensive use of branching?
Rene.
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ
