On Wed, Jun 23, 2010 at 22:09, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Here are the topics that have been cooking.
Here are topics that I've submitted that haven't made it into a
"What's cooking" post, but which I consider ready for inclusion.
Since I'm not sure whether they've been rejected, ignored or just
forgotten I'm listing them here. It'd be nice to get an update on
their status so I can act appropriately on my end.
* git-am: Ignore whitespace before patches
(<1273944188-9472-1-git-send-email-avarab@xxxxxxxxx>)
Junio commented:
Actually cut-and-paste is often a major source of whitespace breakage
(including tabs silently being expanded), and I personally think a patch
like this to encourage the practice is going in a wrong direction.
my reply:
What it does is enable the GMail -> download -> git-am workflow. GMail
(and doubtless countless other) E-Mail providers introduce whitespace
at the beginning of raw E-Mail messages, while otherwise leaving them
intact.
That patch just makes git-am smarter while harming nothing. Given
the fuzzy behavior of E-Mail programs I think it should be included,
and generally that patch detection should try harder before failing.
* Remove editor-specific droppings from .gitignore
(<1274061883-18043-1-git-send-email-avarab@xxxxxxxxx>).
Micro-cleanup that removes the (as far as I can see) only case
where .gitignore isn't ignoring something generated by the build
system. Context:
On Mon, May 17, 2010 at 01:35, Jonathan Nieder <jrnieder@xxxxxxxxx> wrote:
> Michael J Gruber wrote:
>
>> Does the git build process call format-patch? No! The .gitignore we
>> distribute is meant for things the build process creates
>
> Ah, true. I seem to remember a thread long ago about whether to
> include editor droppings in .gitignore, but I can’t find it in
> the git or lkml archive.
>
> git’s .gitignore does not include .*.swp, \#*#, *~, indeed.
Thanks both of you, I stand corrected. Anyway, I guess this is a bug
then. It's the only thing ignored by Git's various .gitignore files
that isn't created by the build system.
The patch was acked by Michael J Gruber <git@xxxxxxxxxxxxxxxxxxxx>.
* perl libs: perl -w + use warnings is redundant
(<1274460741-9674-1-git-send-email-avarab@xxxxxxxxx>).
A minor cleanup of our Perl code, uses lexical warnings instead of
global warnings in code that's known to require Perl 5.6.0 or
later. Doesn't change behavior but uses the recommended Perl form.
* sha1_file: Show the the type and path to corrupt objects
(<1276174021-9544-1-git-send-email-avarab@xxxxxxxxx>).
Make the error message for git-cat-file's (and other blog accessor
functions) more specific. From the commit message:
Change the error message that's displayed when we encounter corrupt
objects to be more specific. We now print the type (loose or packed)
of corrupted objects, along with the full path to the file in
question.
Before:
$ git cat-file blob 909ef997367880aaf2133bafa1f1a71aa28e09df
fatal: object 909ef997367880aaf2133bafa1f1a71aa28e09df is corrupted
After:
$ git cat-file blob 909ef997367880aaf2133bafa1f1a71aa28e09df
fatal: loose object 909ef997367880aaf2133bafa1f1a71aa28e09df
(stored in .git/objects/90/9ef997367880aaf2133bafa1f1a71aa28e09df) is
corrupted
Knowing the path helps to quickly analyze what's wrong:
$ file .git/objects/90/9ef997367880aaf2133bafa1f1a71aa28e09df
.git/objects/90/9ef997367880aaf2133bafa1f1a71aa28e09df: empty
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html