Re: What's cooking in git.git (Jun 2010, #04; Wed, 23)

["Ævar Arnfjörð Bjarmason" <avarab@gmail.com>]

On Wed, Jun 23, 2010 at 22:09, Junio C Hamano <gitster@pobox.com> 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@gmail.com>)

  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@gmail.com>).

   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@gmail.com> 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@drmicha.warpmail.net>.

 * perl libs: perl -w + use warnings is redundant
   (<1274460741-9674-1-git-send-email-avarab@gmail.com>).

   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@gmail.com>).

   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