Binary files in format-patch

Hello,

I'm using "git format-patch" to generate messages for a code review
mailing list. It work fine except when we have binary files involved.
Their contents are not relevant for us, and doesn't help much in a
mailing list. Taking a peek at the code I've found out this:

In commit e47f306d4bf964def1a0b29e8f7cea419471dffd (short name: "git
format-patch: make --binary on by default"), we add a new restriction
on the possible options to format-patch: if you don't specify --text,
it enables --binary. But looking at today's code, we have a path that
is never taken for format-patch, in function builtin_diff (diff.c), at
lines 1423 to 1433. The fprintf doesn't ever happen, because if it's
TEXT, it dumps the contents verbatim, if it's BINARY, it encodes (to
some baseXX) the files/diff.

Wouldn't be nice to allow this code path to happen via some
--omit-binary / --no-binary option to be checked in cmd_format_patch?
(I could provide a patch for this, if you think it's a good idea).

Or should I try to solve my problem by other means (post-processing
the patches, building my own with git-diff)?


Cheers,
  Caio Marcelo

Caio Marcelo [off-list ref] wrote:

I'm using "git format-patch" to generate messages for a code review
mailing list. It work fine except when we have binary files involved.
Their contents are not relevant for us, and doesn't help much in a
mailing list. Taking a peek at the code I've found out this:

Why then are they committed in Git and being modified?  If the
files aren't relevant, why are they tracked?
 
-- 
Shawn.

 > Their contents are not relevant for us, and doesn't help much in a
 > mailing list. Taking a peek at the code I've found out this:

 Why then are they committed in Git and being modified?  If the
 files aren't relevant, why are they tracked?

Sorry, I wasn't very clear there. The binary content is mostly icons,
that get added and updated now and then, so outside of the scope of
our code review mailing list -- but relevant to the project itself.
(The patches themselves are accessible by other means other than the
ML too, so reviewers can pull and get proper versions).

Considering that, any of the proposed solutions make more sense now? :-)


Cheers,
  Caio Marcelo

tisdagen den 6 maj 2008 00.55.06 skrev Caio Marcelo:

Hello,

I'm using "git format-patch" to generate messages for a code review
mailing list. It work fine except when we have binary files involved.
Their contents are not relevant for us, and doesn't help much in a
mailing list. Taking a peek at the code I've found out this:

In commit e47f306d4bf964def1a0b29e8f7cea419471dffd (short name: "git
format-patch: make --binary on by default"), we add a new restriction
on the possible options to format-patch: if you don't specify --text,
it enables --binary. But looking at today's code, we have a path that
is never taken for format-patch, in function builtin_diff (diff.c), at
lines 1423 to 1433. The fprintf doesn't ever happen, because if it's
TEXT, it dumps the contents verbatim, if it's BINARY, it encodes (to
some baseXX) the files/diff.

Wouldn't be nice to allow this code path to happen via some
--omit-binary / --no-binary option to be checked in cmd_format_patch?
(I could provide a patch for this, if you think it's a good idea).

Sounds reasonable.  I'd say --no-binary is the right one here.

-- robin

 > Wouldn't be nice to allow this code path to happen via some
 > --omit-binary / --no-binary option to be checked in cmd_format_patch?
 > (I could provide a patch for this, if you think it's a good idea).

 Sounds reasonable.  I'd say --no-binary is the right one here.

Commited a patch couple a days ago. Could anyone take a look? I've
tried to reduce the changes to a minimum.


Cheers,
  Caio Marcelo

 Commited a patch couple a days ago. Could anyone take a look? I've

Ops.. I didn't only commited but also sent to this mailing list ;-)


Cheers,
  Caio Marcelo