threads / discuss / 20000

git-svn producing "invalid author/committer line"

Subject: git-svn producing "invalid author/committer line"

## tl;dr

4 messages between Jul 2, 2009 and Jul 5, 2009.

replies: 3people: 3as markdown or json

esskov@oncable.dk· Jul 2, 2009, 09:09 UTC · lore
	Hi,

We have an SVN repository with a number of projects in its /trunk. Different people have r/w-access to different subsets of these projects.

When I "git-svn fetch" this repo's trunk there will be some revisions that I don't have access to. In SVN log they show up as empty change-sets with unspecified author. In the resulting git repo, git-fsck says "error in commit 92cf6ec3a55fbbfbf5aea7f0937e4b49470b9112: invalid author/committer line", and - as a consequence I guess - git-gc aborts.

$ git show 92cf6
commit 92cf6ec3a55fbbfbf5aea7f0937e4b49470b9112
Author: (no author) <(no author)@xxxx>
Date:   Thu Jan 1 00:00:00 1970 +0000

I tried to run "git filter-branch --prune-empty -- --all", to simply discard these empty commits, but the problem remains.

After some googling I found a possible work-around, using the --authors-file option of git-svn to map the "no author" into something less invalid, but I suppose that would require the list to contain every other committer as well?

Could I somehow make "git-svn fetch" skip these empty commits, corresponding to revisions that the SVN user doesn't have access to?

Cheers,
	Esben
Eric Wong· Jul 3, 2009, 04:28 UTC · re: esskov@oncable.dk · lore

Re: git-svn producing "invalid author/committer line"

esskov@oncable.dk wrote:
Show 16 quoted lines
> 	Hi,
> 
> We have an SVN repository with a number of projects in its /trunk.
> Different people have r/w-access to different subsets of these projects. 
> 
> When I "git-svn fetch" this repo's trunk there will be some revisions that
> I don't have access to. In SVN log they show up as empty change-sets with
> unspecified author. 
> In the resulting git repo, git-fsck says "error in commit
> 92cf6ec3a55fbbfbf5aea7f0937e4b49470b9112: invalid author/committer line",
> and - as a consequence I guess - git-gc aborts.
> 
> $ git show 92cf6
> commit 92cf6ec3a55fbbfbf5aea7f0937e4b49470b9112
> Author: (no author) <(no author)@xxxx>
> Date:   Thu Jan 1 00:00:00 1970 +0000

Actually, it's not the author, but the date == 0 that fsck.c has an issue with. Proposed patch to {fsck,commit}.c coming.

Show 10 quoted lines
> I tried to run "git filter-branch --prune-empty -- --all", to simply
> discard these empty commits, but the problem remains. 
> 
> After some googling I found a possible work-around, using the
> --authors-file option of git-svn to map the "no author" into something
> less invalid, but I suppose that would require the list to contain every
> other committer as well?
> 
> Could I somehow make "git-svn fetch" skip these empty commits,
> corresponding to revisions that the SVN user doesn't have access to?

You can pass '-r<begin>:<end>' in a way similar to "svn log" to skip commits:

  git svn fetch -r5:200
-- 
Eric Wong
Eric Wong· Jul 3, 2009, 04:34 UTC · re: Eric Wong · lore

[PATCH] Allow the Unix epoch to be a valid commit date

It is common practice to use the Unix epoch as a fallback date when a suitable date is not available. This is true of git svn and possibly other importing tools that import non-git history into git.

Instead of clobbering established strtoul() error reporting semantics with our own, preserve the strtoul() error value of ULONG_MAX for fsck.c to handle.

Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
 commit.c |    6 +-----
 fsck.c   |    2 +-
 2 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/commit.c b/commit.c
index aa3b35b..a47fb4d 100644
--- a/commit.c
+++ b/commit.c
@@ -50,7 +50,6 @@ struct commit *lookup_commit(const unsigned char *sha1)
 
 static unsigned long parse_commit_date(const char *buf, const char *tail)
 {
-	unsigned long date;
 	const char *dateptr;
 
 	if (buf + 6 >= tail)
@@ -73,10 +72,7 @@ static unsigned long parse_commit_date(const char *buf, const char *tail)
 	if (buf >= tail)
 		return 0;
 	/* dateptr < buf && buf[-1] == '\n', so strtoul will stop at buf-1 */
-	date = strtoul(dateptr, NULL, 10);
-	if (date == ULONG_MAX)
-		date = 0;
-	return date;
+	return strtoul(dateptr, NULL, 10);
 }
 
 static struct commit_graft **commit_graft;
diff --git a/fsck.c b/fsck.c
index 511b82c..89278c1 100644
--- a/fsck.c
+++ b/fsck.c
@@ -229,7 +229,7 @@ static int fsck_commit(struct commit *commit, fsck_error error_func)
 	struct commit_graft *graft;
 	int parents = 0;
 
-	if (!commit->date)
+	if (commit->date == ULONG_MAX)
 		return error_func(&commit->object, FSCK_ERROR, "invalid author/committer line");
 
 	if (memcmp(buffer, "tree ", 5))

-- 
Eric Wong
Junio C Hamano· Jul 5, 2009, 19:27 UTC · re: Eric Wong · lore

Re: [PATCH] Allow the Unix epoch to be a valid commit date

Eric Wong <normalperson@yhbt.net> writes:
Show 10 quoted lines
> It is common practice to use the Unix epoch as a fallback date
> when a suitable date is not available.  This is true of git svn
> and possibly other importing tools that import non-git history
> into git.
>
> Instead of clobbering established strtoul() error reporting
> semantics with our own, preserve the strtoul() error value
> of ULONG_MAX for fsck.c to handle.
>
> Signed-off-by: Eric Wong <normalperson@yhbt.net>
Makes sense.  Will queue.
Thanks.

← back to recent threads