Re: Git on Windows, CRLF issues

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Jeff King schrieb:
> On Wed, Apr 23, 2008 at 12:58:57PM +0200, Johannes Sixt wrote:
> 
>> In practice, this is not sufficient. The blob filter must have an
>> opportunity to decide what it wants to do, not just blindly munge every
>> blob. The minimum is a path name, e.g. in $1:
>>
>> 	new=$(git cat-file blob $sha1 |
>> 		$SHELL_PATH -c "$filter_blob" ignored "$path" |
>> 		git hash-object -w --stdin)
> 
> I intentionally left that out, because:
> 
>   - I assumed if you were going to do trickery with pathnames, you
>     should just be doing an index filter
> 
>   - it violates the cache assumption, which is that blob $X is always
>     transformed the same way
> 
> I assume you are wanting to do something like:
> 
>   git filter-branch --blob-filter '
>     case "$1" in
>       *.jpg) cat ;;
>           *) tr a-z A-Z ;;
>     esac
>   '
> 
> Obviously it is unlikely to get the same blob sha1 as "foo.jpg" and
> "foo.txt", but it just feels a little wrong.

Yes, that's how I intended it to work. What's wrong here? The fact that a
user might name a JPEG foo.txt instead of foo.jpg? Or that the same blob
might appear with entirely different names, including different suffixes?
Well, tough luck. Use an index filter. But without any sort of hint what
the blob is about, your original --blob-filter is useless except for the
most simplistic repositories.

-- Hannes
--
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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux