> Agreed - we have very significant annotations of specific git hashes
> left and right to double-check the re-basing work; anything that
> hinders
> that process in the next months is incredibly under-appreciated.
>
> So - if it's just a few harmless warnings - we should leave it for
On Sun, 2012-11-18 at 18:32 -0600, Norbert Thiebaud wrote:
> 1/ this is harmless
> 2/ this certainly is not worth the extreme pain of a git-rewrite
Agreed - we have very significant annotations of specific git hashes
left and right to double-check the re-basing work; anything that hinders
On Sun, Nov 18, 2012 at 4:34 PM, Enrico Weigelt wrote:
>
>
> Did a little bit more research:
>
> git fsck on a fresh clone spits out long list of broken commit errors:
> (far more than 50 lines)
>
> error in commit edc18425b8c2455c5f0d172126156d90e7c06eb2: invalid
> author/committer line - missi
Did a little bit more research:
git fsck on a fresh clone spits out long list of broken commit errors:
(far more than 50 lines)
error in commit edc18425b8c2455c5f0d172126156d90e7c06eb2: invalid
author/committer line - missing space before email
error in commit 10ab5aa3953d58f3430819a990250741a
On Sun, Nov 18, 2012 at 10:24 AM, Enrico Weigelt wrote:
> Hi folks,
>
> while trying to push to github, I've encountered trouble with
> broken commits: github always runs fsck on post-receive,
> which fails due to broken commit metadata, and upload will
> be rejected. See commit
>
> 144c7a2e1d
Hi folks,
while trying to push to github, I've encountered trouble with
broken commits: github always runs fsck on post-receive,
which fails due to broken commit metadata, and upload will
be rejected. See commit
144c7a2e1d711e13422a5c84b34ac33b1d940034
Optimally, we should correct this, but
