Re: [bug?] git-format-patch produces a 0-byte long patch for the first commit

On Mon, 23 Mar 2009, Thomas Rast wrote:

Guennadi Liakhovetski wrote:

quoted

mkdir x
cd x
git-init
echo hi > greating
git-commit -a

[...]

quoted

git-format-patch HEAD^ produces an error, 

There is no HEAD^ in this case.  HEAD is always the currently checked
out commit.  Since it has a root commit, it has no parent, so you
cannot apply ^ ("the first parent of") to it.  Similarly, HEAD~2 will
not work if HEAD~1 has no parent, etc.

Yes, I can understand this, still from the high-level PoV, this looks 
inconsistent:

git-format-patch HEAD

never produces anything, which means for me, I'm trying to extract commits 
for a 0-length range.

git-format-patch HEAD^

Usually produces the "current" or the "last" commit - except if you're 
currently on the first commit... But I'm not insisting on this one - maybe 
you're right, it just _does_ look weird.

Just try to forget about the meaning of the command. You are somewhere on 
the commit timeline. You enter "some" command, which usually produces 
exactly one - the most recent commit. So, I would expect this to work 
always when there is at least one commit in the tree.

So, maybe it would make sense to refer to the point before-the-root-commit 
every time root's parent is requested?

quoted

git-format-patch -1 produces a 0-byte long patch.

That is admittedly weird and probably deserves a fix and/or suggestion
to use --root.

I'm not sure what else I can add to the explanations I gave on IRC.

Thanks for answering again, I just wanted to make sure this "weirdness" 
doesn't get lost, and possibly gets fixed. I think, you suggested yourself 
to post to the list, so I did.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer