On 10/30/2007 11:53 AM, Robert P. J. Day wrote:
what is the recipe (and i'm sure there is one) for starting with a
stock kernel tree and making a record of a set of potentially
cumulative patches? as in, starting with stock tree:
1) make some changes
2) "git diff" to record that particular change
Well, "git diff" just _shows_ you the diff between your working directory
and that which is "recorded", it doesn't record/commit anything.
"git -p diff" (and/or git status) is a good way to check that the changes
you made are indeed what you want to commit and then yes, to record you'd
then do do a "git commit -a" (maybe adding -s to automate the Signed-off).
After you've commited, a "git show" (that is, "git show HEAD") will get you
the patch including the changelog.
???
3) make some *further* changes
4) record the differential patch between the last one and this one
Since you've commited your last changes, at this point "git diff" will show
those further changes only. If all well, you commit again...
5) ... repeat as long as i want ...
i'm guessing that, between steps 2) and 3), i would have to, what,
"commit" the current patch so that it doesn't show up in the next "git
diff". and, finally, i want to reset my cloned repo all the way back
to its initial state, with no changes. "revert", i'm guessing.
revert, or reset. I generally don't use revert, but just really throw away
the stuff that I want gone with reset.
git reset --hard HEAD^
will reset your repo to the state it was in at commit HEAD^, which is the
commit before the HEAD commit. You can repeat that several times, or do it
in one step with "git reset --hard HEAD~n", with n the number of commits you
want to throw away.
Never type any new git command without first typing
git command --help
by the way...
p.s. i don't know much about the "quilt" utility but i've been told that
might be what i'm looking for as well. thanks for any guidance.
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.
YMMV, but I'd keep quilt to patch _management_, not patch creation. You can
ofcourse work in anything you want and then publish the result as a quilt
stack though...
Rene.
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ
