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

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

[Guennadi Liakhovetski]

Hi,

I noticed some special "features" of the first git commit, which seem at 
least inconsistent to me, even though I've got some explanations on IRC.

E.g., the sequence

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

produces a 0-byte long patch. git-format-patch HEAD^ produces an error, 
whereas with more than one commit it produces tha last patch. Yes, I know 
about "--root" and that it does allow to extract the very first commit.

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

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

[Thomas Rast]

[-- Attachment #1: Type: text/plain, Size: 669 bytes --]

Guennadi Liakhovetski wrote:
> mkdir x
> cd x
> git-init
> echo hi > greating
> git-commit -a
[...]
> 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.

> 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.

-- 
Thomas Rast
trast@{inf,student}.ethz.ch

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

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

[Guennadi Liakhovetski]

On Mon, 23 Mar 2009, Thomas Rast wrote:

> Guennadi Liakhovetski wrote:
> > mkdir x
> > cd x
> > git-init
> > echo hi > greating
> > git-commit -a
> [...]
> > 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?

> > 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

[PATCH] Documentation: format-patch --root clarifications

[Thomas Rast]

Users were confused about the meaning and use of the --root option.
Notably, since 68c2ec7 (format-patch: show patch text for the root
commit, 2009-01-10), --root has nothing to do with showing the patch
text for the root commit any more.

Shorten and clarify the corresponding paragraph in the DESCRIPTION
section, document --root under OPTIONS, and add an explicit note that
root commits are formatted regardless.

Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---

Guennadi Liakhovetski wrote:
> On Mon, 23 Mar 2009, Thomas Rast wrote:
> 
> > > 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 finally got around to looking at this again.  The 0-byte patch issue
is fixed since 1.6.2 (68c2ec7 mentioned above), so the above no longer
applies.  The patch merely tries to make this clearer in the
documentation.

> 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.

It's not like this is voodoo, the problem is that you're reading a
different meaning into the observable behaviour than what the revision
walker does.

First, note that rule 1 in the git-format-patch manpage simply states
that specifying a single <commit> is equivalent to specifying the
range '<commit>..', i.e., '<commit>..HEAD'.

With that out of the way, turn to man git-rev-list and note that
'<commit>..HEAD' is another way of spelling '^<commit> HEAD'.  Which
means to list all commits that are reachable from HEAD, but not
<commit>.  Thus, in *linear* history, 'HEAD^..' always means the
current commit, but that's just a special case.  If you're on a merge
commit, 'HEAD^..' only excludes commits reachable from the *first*
parent of the merge, so (unless the merge was trivial) this range
actually contains more than one commit.

And it should become clearer that in order to reach (and thus
include/exclude) anything, both ends of the revision range must
exist.  So if there is no parent of the current commit (i.e., it is a
root), you cannot use the HEAD^ syntax.

Admittedly, the special handling of <since> in git-format-patch
differs from all(?) other revision walking commands (log, rev-list,
bundle, fast-export).


 Documentation/git-format-patch.txt |   21 ++++++++++++---------
 1 files changed, 12 insertions(+), 9 deletions(-)

diff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt
index c2eb5fa..c105925 100644
--- a/Documentation/git-format-patch.txt
+++ b/Documentation/git-format-patch.txt
@@ -40,15 +40,11 @@ There are two ways to specify which commits to operate on.
    REVISIONS" section in linkgit:git-rev-parse[1]) means the
    commits in the specified range.
 
-A single commit, when interpreted as a <revision range>
-expression, means "everything that leads to that commit", but
-if you write 'git format-patch <commit>', the previous rule
-applies to that command line and you do not get "everything
-since the beginning of the time".  If you want to format
-everything since project inception to one commit, say "git
-format-patch \--root <commit>" to make it clear that it is the
-latter case.  If you want to format a single commit, you can do
-this with "git format-patch -1 <commit>".
+The first rule takes precedence in the case of a single <commit>.  To
+apply the second rule, i.e., format everything since the beginning of
+history up until <commit>, use the '\--root' option: "git format-patch
+\--root <commit>".  If you want to format only <commit> itself, you
+can do this with "git format-patch -1 <commit>".
 
 By default, each output file is numbered sequentially from 1, and uses the
 first line of the commit message (massaged for pathname safety) as
@@ -182,6 +178,13 @@ not add any suffix.
 	applied.  By default the contents of changes in those files are
 	encoded in the patch.
 
+--root::
+	Treat the revision argument as a <revision range>, even if it
+	is just a single commit (that would normally be treated as a
+	<since>).  Note that root commits included in the specified
+	range are always formatted as creation patches, independently
+	of this flag.
+
 CONFIGURATION
 -------------
 You can specify extra mail header lines to be added to each message
-- 
1.6.2.1.558.ge131

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

[Jeff King]

On Mon, Mar 23, 2009 at 11:34:07AM +0100, Guennadi Liakhovetski wrote:

> mkdir x
> cd x
> git-init
> echo hi > greating
> git-commit -a
> git-format-patch -1
> 
> produces a 0-byte long patch. git-format-patch HEAD^ produces an error, 
> whereas with more than one commit it produces tha last patch. Yes, I know 
> about "--root" and that it does allow to extract the very first commit.

What version of git are you using? I believe the 0-byte diff has been
fixed since git 1.6.1.1.

-Peff

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

[Guennadi Liakhovetski]

On Tue, 24 Mar 2009, Jeff King wrote:

> On Mon, Mar 23, 2009 at 11:34:07AM +0100, Guennadi Liakhovetski wrote:
> 
> > mkdir x
> > cd x
> > git-init
> > echo hi > greating
> > git-commit -a
> > git-format-patch -1
> > 
> > produces a 0-byte long patch. git-format-patch HEAD^ produces an error, 
> > whereas with more than one commit it produces tha last patch. Yes, I know 
> > about "--root" and that it does allow to extract the very first commit.
> 
> What version of git are you using? I believe the 0-byte diff has been
> fixed since git 1.6.1.1.

Mine is still 1.5.4, if it's already fixed in the meantime - all the 
better!

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

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

[Johannes Schindelin]

Hi,

On Tue, 24 Mar 2009, Guennadi Liakhovetski wrote:

> On Tue, 24 Mar 2009, Jeff King wrote:
> 
> > On Mon, Mar 23, 2009 at 11:34:07AM +0100, Guennadi Liakhovetski wrote:
> > 
> > > mkdir x
> > > cd x
> > > git-init
> > > echo hi > greating
> > > git-commit -a
> > > git-format-patch -1
> > > 
> > > produces a 0-byte long patch. git-format-patch HEAD^ produces an 
> > > error, whereas with more than one commit it produces tha last patch. 
> > > Yes, I know about "--root" and that it does allow to extract the 
> > > very first commit.
> > 
> > What version of git are you using? I believe the 0-byte diff has been 
> > fixed since git 1.6.1.1.
> 
> Mine is still 1.5.4, if it's already fixed in the meantime - all the 
> better!

There is the off-chance that somewhere in those 3127 commits between 
v1.5.4 and v1.6.1.1, not only this bug is fixed.  You might be surprised 
;-)

Seriously again, in a project that moves as fast as Git, you should always 
test with a recent version, and v1.5.1 -- being over one year old -- does 
not account for recent.

Ciao,
Dscho

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

[Guennadi Liakhovetski]

On Tue, 24 Mar 2009, Johannes Schindelin wrote:

> Hi,
> 
> On Tue, 24 Mar 2009, Guennadi Liakhovetski wrote:
> 
> > On Tue, 24 Mar 2009, Jeff King wrote:
> > 
> > > On Mon, Mar 23, 2009 at 11:34:07AM +0100, Guennadi Liakhovetski wrote:
> > > 
> > > > mkdir x
> > > > cd x
> > > > git-init
> > > > echo hi > greating
> > > > git-commit -a
> > > > git-format-patch -1
> > > > 
> > > > produces a 0-byte long patch. git-format-patch HEAD^ produces an 
> > > > error, whereas with more than one commit it produces tha last patch. 
> > > > Yes, I know about "--root" and that it does allow to extract the 
> > > > very first commit.
> > > 
> > > What version of git are you using? I believe the 0-byte diff has been 
> > > fixed since git 1.6.1.1.
> > 
> > Mine is still 1.5.4, if it's already fixed in the meantime - all the 
> > better!
> 
> There is the off-chance that somewhere in those 3127 commits between 
> v1.5.4 and v1.6.1.1, not only this bug is fixed.  You might be surprised 
> ;-)
> 
> Seriously again, in a project that moves as fast as Git, you should always 
> test with a recent version, and v1.5.1 -- being over one year old -- does 
> not account for recent.

Sorry, didn't mention, I also tested with 1.6.0.6 - still was there.

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