git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jannis Pohlmann <jannis.pohlmann@codethink.co.uk>
To: git@vger.kernel.org
Subject: Problems with unrecognized headers in git bundles
Date: Wed, 22 Feb 2012 16:05:45 +0000	[thread overview]
Message-ID: <4F451259.7010304@codethink.co.uk> (raw)

Hi,

creating bundles from some repositories seems to lead to bundles with 
incorrectly formatted headers, at least with git >= 1.7.2. When cloning 
from such bundles, git prints the following error/warning:

   $ git clone perl-clone.bundle perl-clone
   Cloning into 'perl-clone'...
   warning: unrecognized header: --work around mangled archname on...

This can be reproduced easily with git from any version >= 1.7.2 or from 
master, using the following steps:

   git clone git://perl5.git.perl.org/perl.git perl
   GIT_DIR=perl/.git git bundle create perl-clone.bundle --all
   git clone perl-clone.bundle perl-clone

The content of the bundle is:

   # v2 git bundle
   -- work around mangled archname on win32 while finding...
   39ec54a59ce332fc44e553f4e5eeceef88e8369e refs/heads/blead
   39ec54a59ce332fc44e553f4e5eeceef88e8369e refs/remotes/origin/HEAD
   ...

The "--work around mangled archname..." line is rather long, so I've 
omitted most of it. What it contains is a series of commit messages all 
combined into a single line. It appears that this line is the problem 
because it's neither a comment (like '#v2 git bundle') nor a SHA1 
followed by a ref name.

Note that this problem does not occur with all repositories. A bundle 
created from a test repository with a single text file and just one 
commit does not have this problem.

Note also that "git clone <bundle> <dest>" does not fail with corrupted 
bundles if the git version is something like 1.7.2 or 1.7.7.6. Those 
version print the above warning but still succeed in cloning. "git 
clone" from master however treats this as an error and fails.

Without any knowledge of how git works internally, I would assume that 
this is either a bug in how bundles are created, or a hint at a slightly 
broken perl repository (other's have the same thing though, perhaps it 
is because of a conversion from another SCM software to git in the 
past). Does this sound reasonable?

Is there a way to work around this or fix it properly? I'm not sure what 
lead to the decision to no longer ignore unrecognized headers in git 
master, would it be sensible to revert this change if nothing can be 
done to solve this during bundle creation?

   - Jannis

             reply	other threads:[~2012-02-22 16:52 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-22 16:05 Jannis Pohlmann [this message]
2012-02-22 19:34 ` [PATCH 1/2] bundle: put strbuf_readline_fd in strbuf.c with adjustments Thomas Rast
2012-02-22 19:34   ` [PATCH 2/2] bundle: use a strbuf to scan the log for boundary commits Thomas Rast
2012-02-22 20:22     ` Junio C Hamano
2012-02-22 20:25       ` Thomas Rast
2012-02-22 20:50         ` Junio C Hamano
2012-02-22 21:00         ` Jeff King
2012-02-22 20:55     ` Jeff King
2012-02-22 22:10       ` Johannes Sixt
2012-02-23  3:20     ` Junio C Hamano
2012-02-23  3:38     ` Junio C Hamano
2012-02-23  9:42       ` [PATCH v2 0/4] Making an elephant out of a getline() bug Thomas Rast
2012-02-23  9:42         ` [PATCH v2 1/4] strbuf: improve strbuf_get*line documentation Thomas Rast
2012-02-23 10:08           ` Jeff King
2012-02-23  9:42         ` [PATCH v2 2/4] bundle: put strbuf_readline_fd in strbuf.c with adjustments Thomas Rast
2012-02-23  9:42         ` [PATCH v2 3/4] t5704: match tests to modern style Thomas Rast
2012-02-23 23:36           ` Junio C Hamano
2012-02-23  9:42         ` [PATCH v2 4/4] bundle: use a strbuf to scan the log for boundary commits Thomas Rast
2012-02-23 19:04         ` [PATCH v2 0/4] Making an elephant out of a getline() bug Junio C Hamano
2012-02-22 20:51   ` [PATCH 1/2] bundle: put strbuf_readline_fd in strbuf.c with adjustments Jeff King
2012-02-22 20:25 ` Problems with unrecognized headers in git bundles Øyvind A. Holm
2012-02-22 20:40   ` Øyvind A. Holm
2012-02-23 13:27   ` Erik Faye-Lund

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4F451259.7010304@codethink.co.uk \
    --to=jannis.pohlmann@codethink.co.uk \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).