Converting commits to patch files? HEAD vs HEAD^

Converting commits to patch files? HEAD vs HEAD^

[Marc Singer]

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?

Re: Converting commits to patch files? HEAD vs HEAD^

[Linus Torvalds]

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

Re: Converting commits to patch files? HEAD vs HEAD^

[Junio C Hamano]

>>>>> "MS" == Marc Singer <elf@buici.com> writes:

MS> If I've made several commits, I'd like to be able to gather several
MS> together and produce a patch file.  Better still, I'd like to be able
MS> to pick a set of discontiguous commits an bundle them into a single
MS> patch.  Ought I be using tags?

    You ought to be using ...

Oh, I want to say it because the above is what I do all the time
using my Porcelain on GIT, but on the other hand, officially I
am _not_ working on any Porcelain, so... I am in a dilemma.  I
won't talk about that tool I use myself.

Although I have not looked at it myself, you may want to take a
look at StGIT.

"Keeping patches, tracking upstream by primarily updating,
forward porting and e-mail submitting patches" is often the
development model taken by "individual developers", while
"making commits primarily by accepting patches, merging with
repos of other people who have similar aggregator role" is often
the model used by "project leads".

The core GIT (and "git" barebone Porcelain) is geared towards
"project lead" use, and I suspect Cogito would be so to a
certain extent.  By judging only from its description, StGIT,
with its attitude ancestry of quilt, may be more comfortable to
use with "individual developers" mode of operation.

Well, I'd say what I use anyway, and quickly duck ;-)

    You ought to be using ... JIT.

Re: Converting commits to patch files? HEAD vs HEAD^

[Catalin Marinas]

Junio C Hamano <junkio@cox.net> wrote:
>>>>>> "MS" == Marc Singer <elf@buici.com> writes:
> MS> If I've made several commits, I'd like to be able to gather several
> MS> together and produce a patch file.  Better still, I'd like to be able
> MS> to pick a set of discontiguous commits an bundle them into a single
> MS> patch.  Ought I be using tags?
>
> Although I have not looked at it myself, you may want to take a
> look at StGIT.

I still haven't found time to write a tutorial for StGIT (it has a
README but I haven't updated it for some time) but I will try to give
a short description. People familiar with Quilt should not have any
problem with using this tool (it is safer than quilt).

StGIT is well suited for working on trees you do not control (you send
patches and wait for them to be merged and eventually get them from
the remote repository when pulling the latest changes). The advantage
over quilt is that it uses three-way merging and also informs you when
your local patch is empty (i.e., after the patch was fully merged
upstream, quilt just failing to push the patch in this case because of
conflicts).

In general, you clone a repository (Linus' for example) and run
'stg init' to initialise the StGIT specific files.

There is no 'commit' command in StGIT. To make changes, create a patch
with 'stg new <name>' and add some description (can be modified at any
time with the 'refresh --edit' command). You make changes to the files
(or add/rm files) and save them (can be done for an indefinite number
of times) into the current patch with 'stg refresh'. This last command
creates a GIT commit object for the changes between the working tree
and the bottom of the patch (which can be the upstream HEAD if this is
the first patch).

You can create several patches with 'stg new'. A 'git log' command
would show the patches as individual commits. The advantage over a
normal SCM is that you can modify the patch and replace the commit
object with a new one.

To work on a given patch, make it current via the 'stg push/pop'
commands. Note that 'stg push' also allows patch re-ordering.

To pull the latest changes from the upstream respository, do a 'stg
pop -a' (at this point the tree is the same as the one when you last
pulled the remote changes), 'git pull', 'stg push -a'. You can get
conflicts for the latter command if there are overlapping changes or
the patch was modified by the gatekeeper before being merged. Fix the
conflicts, run 'stg resolved/stg refresh' and re-run 'stg push -a' for
the rest of the patches. The 'push' and the 'series' commands notify
you if the patch is empty so that it can safely be removed ('stg
delete <name>').

To send patches upstream (the 'mail' command is not available yet),
you can export the patches with 'stg export' and e-mail manually. You
can create your own template for the exported patch (to include
description, diffstats etc.). An temlate example is given in the
archive, just copy it to the .git/ directory.

Another way to send patches is to ask the gatekeeper to pull from your
tree. Run 'stg push' for all the patches you want to be merged and the
HEAD of your tree would contain the commit objects.

-- 
Catalin