Re: Converting commits to patch files? HEAD vs HEAD^
From: Linus Torvalds <torvalds@osdl.org>
Date: 2016-06-15 22:42:01
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