Jeff Garzik's guide doesn't appear to explain how to get patches back
out of the system.
I've successfully commited a set of changes.
# git diff HEAD^ HEAD
This command will produce a diff of the changes I've made. What is
the HEAD^? Does it refer to the commit before the last one made?
If I've made several commits, I'd like to be able to gather several
together and produce a patch file. Better still, I'd like to be able
to pick a set of discontiguous commits an bundle them into a single
patch. Ought I be using tags?
Finally, given that the upstream repository is git, what is the way to
push commits upstream?
On Fri, 8 Jul 2005, Marc Singer wrote:
# git diff HEAD^ HEAD
This command will produce a diff of the changes I've made. What is
the HEAD^? Does it refer to the commit before the last one made?
Yes. The core tools don't understand this syntax, but most of the helper
scripts use "git-rev-parse" to parse arguments, and then you have the
"extended syntax" which allows short SHA1 names and "parenting".
HEAD^ is the "first parent of HEAD". You could also have written it
"HEAD^1", although the number is really only relevant if you have a merge,
and you want to specify the _other_ side, ie "HEAD^2" is the "second
parent of HEAD".
If you want to have the parent of the parent, write HEAD^^.
Now, to confuse things, a "^" at the _beginning_ of the name means
something else: it means "not", and it used to do ranges.
If I've made several commits, I'd like to be able to gather several
together and produce a patch file. Better still, I'd like to be able
to pick a set of discontiguous commits an bundle them into a single
patch. Ought I be using tags?
You can use tags, but you can just do
git log
and pick out the commit ID's from there and use those too.
"git-whatchanged -p" is also useful to see what's been going on. And
"gitk", of course.
Finally, given that the upstream repository is git, what is the way to
push commits upstream?
You can do
git push destination
(which I just added today), which is just the same thing as
"git-send-pack".
BUT NOTE! It only works for destinations that _you_ control, though. You
can't push to others - you can only push to your own repositories, and
then wait for others to pull from them. Ie, the normal reason to use
"git-send-pack" or "git push" is because you do the work on a private
machine, and then you want to push it out to a public one (still yours),
and send an email to people saying "please pull from so-and-so".
Linus