From: Junio C Hamano <junkio@cox.net>
To: git@vger.kernel.org
Subject: Re: [PATCH] binary patch.
Date: Fri, 05 May 2006 13:50:24 -0700 [thread overview]
Message-ID: <7vmzdww60f.fsf@assigned-by-dhcp.cox.net> (raw)
In-Reply-To: <Pine.LNX.4.64.0605051605340.6713@iabervon.org> (Daniel Barkalow's message of "Fri, 5 May 2006 16:33:55 -0400 (EDT)")
Daniel Barkalow <barkalow@iabervon.org> writes:
> On Fri, 5 May 2006, Junio C Hamano wrote:
>
>> But "binaryness" affects only certain operations that extract
>> the data (e.g. diff and grep) and not others (e.g. fetch).
>> Also, it makes sense to being able to retroactively mark a blob,
>> which was not marked as such originally, is a binary. So I do
>> not think it should be recorded in the object header.
>
> Why do you think it makes sense to retroactively mark a blob with things
> like binariness or MIME type? To the extent that the information is not
> possible to extract from the blob contents, it seems to me to be a
> permanent aspect of the blob. And I could see having blobs with the same
> content but different type information (that one is a ZIP archive, while
> this one is a OpenDocument file), and tools may care how they were
> specified, and the user would want to be able to track how they had
> historically been marked, if the system allows them to be marked at all.
>
> Of course, there's still the issue of how this info is generated for a new
> blob; I think it should live in the index for tracked files and come from
> a .gitignore-style file for new files. (For that matter, there could be a
> .gitmetadata file, which would handle "ignore" as well as binary and
> whatever other info you want to produce about your not-previously-tracked
> files.)
I think Nico's solution (compromise?) is the right and most
practical one.
next prev parent reply other threads:[~2006-05-05 20:50 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-05-04 23:52 [PATCH] binary patch Junio C Hamano
2006-05-05 2:47 ` Nicolas Pitre
2006-05-05 6:47 ` Junio C Hamano
2006-05-05 10:15 ` Junio C Hamano
2006-05-05 15:41 ` Nicolas Pitre
2006-05-05 17:38 ` Junio C Hamano
2006-05-05 18:33 ` Nicolas Pitre
2006-05-05 19:23 ` Junio C Hamano
2006-05-05 20:07 ` Nicolas Pitre
2006-05-05 20:33 ` Daniel Barkalow
2006-05-05 20:50 ` Junio C Hamano [this message]
2006-05-06 7:40 ` Junio C Hamano
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=7vmzdww60f.fsf@assigned-by-dhcp.cox.net \
--to=junkio@cox.net \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.