Thomas Braun writes:
> - The internally used algorithm for generating patch text is based on
> xdiff and its states in [1]
>
> > The output format of the binary patch file is proprietary
> > (and binary) and it is basically a collection of copy and insert
> > commands [..]
>
> which mea
The -G option of log looks for the differences whose patch text
contains added/removed lines that match regex.
Currently -G looks also into patches of binary files (which
according to [1]) is binary as well.
This has a couple of issues:
- It makes the pickaxe search slow. In a proprietary
> Junio C Hamano hat am 29. November 2018 um 08:22
> geschrieben:
>
>
> Junio C Hamano writes:
>
> >> +test_expect_success 'log -G ignores binary files' '
> >> + git checkout --orphan orphan1 &&
> >> + printf "a\0a
> Junio C Hamano hat am 29. November 2018 um 08:10
> geschrieben:
>
>
> Thomas Braun writes:
>
> > Subject: Re: [PATCH v2] log -G: Ignore binary files
>
> s/Ig/ig/; (will locally munge--this alone is no reason to reroll).
Done.
> The code changes looked s
added/removed lines that match regex.
> >
> > As the concept of patch text only makes sense for text files, we need to
> > ignore binary files when searching with -G as well.
> >
> > The -S option of log looks for differences that changes
> > the number of occu
Junio C Hamano writes:
>> +test_expect_success 'log -G ignores binary files' '
>> +git checkout --orphan orphan1 &&
>> +printf "a\0a" >data.bin &&
>> +git add data.bin &&
>> +git commit -m "me
Thomas Braun writes:
> Subject: Re: [PATCH v2] log -G: Ignore binary files
s/Ig/ig/; (will locally munge--this alone is no reason to reroll).
The code changes looked sensible.
> diff --git a/t/t4209-log-pickaxe.sh b/t/t4209-log-pickaxe.sh
> index 844df760f7..5c3e2a16b2 100755
> -
On Wed, Nov 28 2018, Thomas Braun wrote:
Looks much better this time around.
> The -G option of log looks for the differences whose patch text
> contains added/removed lines that match regex.
>
> As the concept of patch text only makes sense for text files, we need to
> igno
The -G option of log looks for the differences whose patch text
contains added/removed lines that match regex.
As the concept of patch text only makes sense for text files, we need to
ignore binary files when searching with -G as well.
The -S option of log looks for differences that changes
the
> Ævar Arnfjörð Bjarmason hat am 22. November 2018 um 11:16
> geschrieben:
[...]
> >
> > +test_expect_success 'log -G ignores binary files' '
> > + rm -rf .git &&
> > + git init &&
> > + printf "a\0b" >data.b
t; >> contains added/removed lines that match regex.
> >>
> >> The concept of differences only makes sense for text files, therefore
> >> we need to ignore binary files when searching with -G as well.
> >
> > What about partial text/partial binary files?
>
e pointer. I've updated the commit message.
> > diff --git a/t/t4209-log-pickaxe.sh b/t/t4209-log-pickaxe.sh
> > index 42cc8afd8b..d430f6f2f9 100755
> > --- a/t/t4209-log-pickaxe.sh
> > +++ b/t/t4209-log-pickaxe.sh
> > @@ -128,4 +128,15 @@ test_expect_success
etion)
> > in a file.
> >
> > Add a test to ensure that we keep looking into binary files with -S
> > as changing that would break backwards compatibility in unexpected ways.
> >
> > Signed-off-by: Thomas Braun
> > ---
> > t/t4209-log-pickaxe.sh |
> Ævar Arnfjörð Bjarmason hat am 22. November 2018 um 11:16
> geschrieben:
[...]
> >
> > +test_expect_success 'log -G ignores binary files' '
> > + rm -rf .git &&
> > + git init &&
> > + printf "a\0b" >data.b
; DIFF_PICKAXE_KIND_G) &&
> > + ((!textconv_one && diff_filespec_is_binary(o->repo, p->one)) ||
> > +(!textconv_two && diff_filespec_is_binary(o->repo, p->two
> > + return 0;
>
> If the user passes "-a&qu
only makes sense for text files, therefore
> > we need to ignore binary files when searching with -G as well.
> >
> > Signed-off-by: Thomas Braun
> > ---
> > Documentation/gitdiffcore.txt | 2 +-
> > diffcore-pickaxe.c| 5 +
> >
iles, therefore
>> we need to ignore binary files when searching with -G as well.
>
> What about partial text/partial binary files?
Good point. You'd use "-a" (or "--text") to tell the diff machinery
to treat the contents as text, and the new logic must pay attention
to that command line option.
On Wed, Nov 21, 2018 at 1:08 PM Thomas Braun
wrote:
>
> The -G option of log looks for the differences whose patch text
> contains added/removed lines that match regex.
>
> The concept of differences only makes sense for text files, therefore
> we need to ignore binary files w
Jeff King writes:
>> +if ((o->pickaxe_opts & DIFF_PICKAXE_KIND_G) &&
>> +((!textconv_one && diff_filespec_is_binary(o->repo, p->one)) ||
>> + (!textconv_two && diff_filespec_is_binary(o->repo, p->two
>>
Ævar Arnfjörð Bjarmason writes:
> On Wed, Nov 21 2018, Thomas Braun wrote:
>
>> The -S option of log looks for differences that changes the
>> number of occurrences of the specified string (i.e. addition/deletion)
>> in a file.
>>
> ...
> This should just be part of 1/2 since the behavior is cha
On Thu, Nov 22, 2018 at 11:16:38AM +0100, Ævar Arnfjörð Bjarmason wrote:
> > +test_expect_success 'log -G looks into binary files with textconv filter' '
> > + rm -rf .git &&
> > + git init &&
> > + echo "* diff=bin" >
> + (!textconv_two && diff_filespec_is_binary(o->repo, p->two
> + return 0;
If the user passes "-a" to treat binary files as text, we should
probably skip the binary check. I think we'd need to check
"o->flags.text" here.
&
>
On Wed, Nov 21 2018, Thomas Braun wrote:
> The -G option of log looks for the differences whose patch text
> contains added/removed lines that match regex.
>
> The concept of differences only makes sense for text files, therefore
> we need to ignore binary files when searchin
On Wed, Nov 21 2018, Thomas Braun wrote:
> The -S option of log looks for differences that changes the
> number of occurrences of the specified string (i.e. addition/deletion)
> in a file.
>
> Add a test to ensure that we keep looking into binary files with -S
> as changin
/t4209-log-pickaxe.sh
> @@ -128,4 +128,15 @@ test_expect_success 'log -G looks into binary files with
> textconv filter' '
> test_cmp actual expected
> '
>
> +test_expect_success 'log -S looks into binary files' '
> + rm
Thomas Braun writes:
> The -G option of log looks for the differences whose patch text
> contains added/removed lines that match regex.
>
> The concept of differences only makes sense for text files, therefore
> we need to ignore binary files when searching with -G as well.
&g
Based on the previous discussion in [1] I've prepared patches which teach
log -G to ignore binary files. log -S keeps its behaviour but got a test to
ensure that.
Feedback welcome!
[1]:
https://public-inbox.org/git/7a0992eb-adb9-a7a1-cfaa-3384bc4d3...@virtuell-zuhause.de/
Thomas Bra
The -G option of log looks for the differences whose patch text
contains added/removed lines that match regex.
The concept of differences only makes sense for text files, therefore
we need to ignore binary files when searching with -G as well.
Signed-off-by: Thomas Braun
---
Documentation
The -S option of log looks for differences that changes the
number of occurrences of the specified string (i.e. addition/deletion)
in a file.
Add a test to ensure that we keep looking into binary files with -S
as changing that would break backwards compatibility in unexpected ways.
Signed-off
Based on the previous discussion in [1] I've prepared patches which teach
log -G to ignore binary files. log -S keeps its behaviour but got a test to
ensure that.
Feedback welcome!
[1]:
https://public-inbox.org/git/7a0992eb-adb9-a7a1-cfaa-3384bc4d3...@virtuell-zuhause.de/
PS: This i
On September 13, 2018 1:52 PM, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> > "Randall S. Becker" writes:
> >
> >> The scenario is slightly different.
> >> 1. Person A gives me a new binary file-1 with fingerprint A1. This
> >> goes into git unchanged.
> >> 2. Person B gives me binary file
Junio C Hamano writes:
> "Randall S. Becker" writes:
>
>> The scenario is slightly different.
>> 1. Person A gives me a new binary file-1 with fingerprint A1. This goes into
>> git unchanged.
>> 2. Person B gives me binary file-2 with fingerprint B2. This does not go
>> into git yet.
>> 3. We at
On September 13, 2018 11:03 AM, Junio C Hamano wrote:
> "Randall S. Becker" writes:
>
> > The scenario is slightly different.
> > 1. Person A gives me a new binary file-1 with fingerprint A1. This
> > goes into git unchanged.
> > 2. Person B gives me binary file-2 with fingerprint B2. This does n
"Randall S. Becker" writes:
> The scenario is slightly different.
> 1. Person A gives me a new binary file-1 with fingerprint A1. This goes into
> git unchanged.
> 2. Person B gives me binary file-2 with fingerprint B2. This does not go
> into git yet.
> 3. We attempt a git diff between the commi
On September 12, 2018 7:00 PM, Junio C Hamano wrote:
> "Randall S. Becker" writes:
>
> >> author is important to our process. My objective is to keep the
> >> original file 100% exact as supplied and then ignore any changes to
> >> the metadata that I don't care about (like Creator) if the remain
"Randall S. Becker" writes:
>> author is important to our process. My objective is to keep the original file
>> 100% exact as supplied and then ignore any changes to the metadata that I
>> don't care about (like Creator) if the remainder of the file is the same.
That will *not* work. If person
On September 12, 2018 4:54 PM, I wrote:
> On September 12, 2018 4:48 PM, Johannes Sixt wrote:
> > Am 12.09.18 um 21:16 schrieb Randall S. Becker:
> > > I feel really bad asking this, and I should know the answer, and yet.
> > >
> > > I have a binary file that needs to go into a repo intact (unchang
> -Original Message-
> From: git-ow...@vger.kernel.org On Behalf
> Of Johannes Sixt
> Sent: September 12, 2018 4:48 PM
> To: Randall S. Becker
> Cc: git@vger.kernel.org
> Subject: Re: [Question] Signature calculation ignoring parts of binary files
>
> A
Am 12.09.18 um 21:16 schrieb Randall S. Becker:
I feel really bad asking this, and I should know the answer, and yet.
I have a binary file that needs to go into a repo intact (unchanged). I also
have a program that interprets the contents, like a textconv, that can
output the relevant portions o
I feel really bad asking this, and I should know the answer, and yet.
I have a binary file that needs to go into a repo intact (unchanged). I also
have a program that interprets the contents, like a textconv, that can
output the relevant portions of the file in whatever format I like - used
for di
On Thu, Jul 19, 2018 at 12:05:00AM +0200, René Scheibe wrote:
> Code:
> -
> #!/bin/bash
>
> # setup repository
> git init --quiet repo
> cd repo
>
> echo '*.bin binary -delta' > .gitattributes
> git add .gitattributes
> git comm
Hi,
I was wondering why "git clone" seems to not respect "-delta" in .gitattributes.
*Reproduction*
I prepared a test repository with:
- git v2.17.1
- .gitattributes containing "*.bin binary -delta"
- 10 commits with a 10 MB random binary file
Code:
---
ly works but it would be more clean to just have git ignore the
>> binary files from the get go.
>>
>
> Sure it'd be more convenient for you. But there are loads of possible
> combinations, and the idea of what constitutes unwanted files is
> hugely variable
On Fri, May 18, 2018 at 4:31 AM, Anmol Sethi wrote:
> This definitely works but it would be more clean to just have git ignore the
> binary files from the get go.
>
Sure it'd be more convenient for you. But there are loads of possible
combinations, and the idea of what consti
d, May 16, 2018 at 5:45 PM, Anmol Sethi wrote:
> >>> I think it’d be great to have an option to have git ignore binary
> >>> files. My
> >> repositories are always source only, committing a binary is always a
> mistake.
> >> At the moment, I have to configu
This definitely works but it would be more clean to just have git ignore the
binary files from the get go.
> On May 16, 2018, at 11:18 PM, Jacob Keller wrote:
>
> On Wed, May 16, 2018 at 5:45 PM, Anmol Sethi wrote:
>> I think it’d be great to have an option to have git ignore b
eat to have an option to have git ignore binary files. My
>> repositories are always source only, committing a binary is always a mistake.
>> At the moment, I have to configure the .gitignore to ignore every binary file
>> and that gets tedious. Having git ignore all binary fi
On May 16, 2018 11:18 PM, Jacob Keller
> On Wed, May 16, 2018 at 5:45 PM, Anmol Sethi wrote:
> > I think it’d be great to have an option to have git ignore binary files. My
> repositories are always source only, committing a binary is always a mistake.
> At the moment, I have t
On Wed, May 16, 2018 at 5:45 PM, Anmol Sethi wrote:
> I think it’d be great to have an option to have git ignore binary files. My
> repositories are always source only, committing a binary is always a mistake.
> At the moment, I have to configure the .gitignore to ignore every bi
I think it’d be great to have an option to have git ignore binary files. My
repositories are always source only, committing a binary is always a mistake.
At the moment, I have to configure the .gitignore to ignore every binary file
and that gets tedious. Having git ignore all binary files would
On 20/07/2017 22:40, Junio C Hamano wrote:
> Igor Djordjevic writes:
>> On 20/07/2017 09:41, Volodymyr Sendetskyi wrote:
>>> It is known, that git handles badly storing binary files in its
>>> repositories at all.
>>> This is especially about large files: e
Igor Djordjevic writes:
> On 20/07/2017 09:41, Volodymyr Sendetskyi wrote:
>> It is known, that git handles badly storing binary files in its
>> repositories at all.
>> This is especially about large files: even without any changes to
>> these files, their copies are
Hi Volodymyr,
On 20/07/2017 09:41, Volodymyr Sendetskyi wrote:
> It is known, that git handles badly storing binary files in its
> repositories at all.
> This is especially about large files: even without any changes to
> these files, their copies are snapshotted on each com
On Thu, Jul 20, 2017 at 12:41 AM, Volodymyr Sendetskyi
wrote:
> It is known, that git handles badly storing binary files in its
> repositories at all.
> This is especially about large files: even without any changes to
> these files, their copies are snapshotted on each com
> On 20 Jul 2017, at 09:41, Volodymyr Sendetskyi wrote:
>
> It is known, that git handles badly storing binary files in its
> repositories at all.
> This is especially about large files: even without any changes to
> these files, their copies are snapshotted on ea
On Thu, Jul 20, 2017 at 10:41:48AM +0300, Volodymyr Sendetskyi wrote:
> It is known, that git handles badly storing binary files in its
> repositories at all.
[...]
> So the question is: why not implementing some feature, that would
> somehow handle this problem?
[...]
Have you exam
On Thu, Jul 20, 2017 at 12:41 AM, Volodymyr Sendetskyi
wrote:
> It is known, that git handles badly storing binary files in its
> repositories at all.
> This is especially about large files: even without any changes to
> these files, their copies are snapshotted on each com
It is known, that git handles badly storing binary files in its
repositories at all.
This is especially about large files: even without any changes to
these files, their copies are snapshotted on each commit. So even
repositories with a small amount of code can grove very fast in size
if they
Am 03.03.2017 um 17:07 schrieb Junio C Hamano:
> Jeff King writes:
>
>> On Thu, Mar 02, 2017 at 05:36:17PM -0800, Junio C Hamano wrote:
>> ...
>>>> Is that on purpose?
>>>
>>> No, it's a mere oversight (as I do not think I never even thought
&
Jeff King writes:
> On Thu, Mar 02, 2017 at 05:36:17PM -0800, Junio C Hamano wrote:
> ...
>> > Is that on purpose?
>>
>> No, it's a mere oversight (as I do not think I never even thought
>> about special casing binary
>> files from day one,
On Thu, Mar 02, 2017 at 05:36:17PM -0800, Junio C Hamano wrote:
> On Thu, Mar 2, 2017 at 4:52 PM, Thomas Braun
> wrote:
> >
> > I happen to have quite large binary files in my repos.
> >
> > Today I realized that a line like
> > git log -G a
> >
On Thu, Mar 2, 2017 at 4:52 PM, Thomas Braun
wrote:
>
> I happen to have quite large binary files in my repos.
>
> Today I realized that a line like
> git log -G a
> searches also files found to be binary (or explicitly marked as binary).
>
> Is that on purpose?
No, it&
Hi,
I happen to have quite large binary files in my repos.
Today I realized that a line like
git log -G a
searches also files found to be binary (or explicitly marked as binary).
Is that on purpose?
The documentation of "-G" states
"Look for differences whose patch text contain
Douglas Cox writes:
>> This may or may not be related to the symptom
>> you are observing (if it is, then you would see a packfile created
>> in objects/pack/, not in loose objects in object/??/ directories).
>
> No, the file is loose (it's in .git/objects/eb in this case). This is
> seen immedia
fied in .gitattributes per wildcard similar to how -delta can be
>> used. This way we would still be able to get compression for
>> text/source files, while still getting the speed of skipping
>> compression for binary files that do not compress well.
>>
>> Has there
is also global. Ideally it would be
> great if there was a separate 'compression' attribute that could be
> specified in .gitattributes per wildcard similar to how -delta can be
> used. This way we would still be able to get compression for
> text/source files, while still getting the
I was doing some experiments today with large-ish (100-200MB) binary
files and was trying to determine the best configuration for Git. Here
are the steps and timings I saw:
git init Test
cp .../largemovie.mp4 .
time git add largemovie.mp4
This took 6.5s for a 200MB file.
This file compressed a
resource files.
On Mon, Apr 25, 2016 at 7:46 PM, Torsten Bögershausen wrote:
> On 25.04.16 16:11, Kirill Likhodedov wrote:
>> Hi,
>>
>> I wonder if it is possible both to have LFs in all and only text files in
>> working trees, and keep Git’s binary files auto-detectio
On 25.04.16 16:11, Kirill Likhodedov wrote:
> Hi,
>
> I wonder if it is possible both to have LFs in all and only text files in
> working trees, and keep Git’s binary files auto-detection?
>
> To be more precise:
> * we want all text files to be checked out in LF;
&g
Hi,
I wonder if it is possible both to have LFs in all and only text files in
working trees, and keep Git’s binary files auto-detection?
To be more precise:
* we want all text files to be checked out in LF;
* we don’t want force people to set “core.autocrlf” to false, preferring to
keep this
On Fri, Nov 27, 2015 at 03:14:58PM +0100, Johannes Schindelin wrote:
> On Wed, 25 Nov 2015, Andrzej Borucki wrote:
>
> > How git detects that file is binary? This must be safe because it not
> > allowed to change line breaks in binary files.
> > Binary files can co
Hi Andrzej,
On Wed, 25 Nov 2015, Andrzej Borucki wrote:
> How git detects that file is binary? This must be safe because it not
> allowed to change line breaks in binary files.
> Binary files can contain byte 0 (zero), but:
> - 16 bit UTF also can contain zero
> - short binar
test_cmp is intended to produce diff output for human consumption. The
input in one instance in t9300-fast-import.sh are binary files, however.
Use test_cmp_bin to compare the files.
This was noticed because on Windows we have a special implementation of
test_cmp in pure bash code (to ignore
Am 12.09.2014 um 19:58 schrieb Junio C Hamano:
> Johannes Sixt writes:
>
>> test_cmp is intended to produce diff output for human consumption. The
>> input in one instance in t9300-fast-import.sh are binary files, however.
>> Use cmp to compare the files.
>
> Tha
Johannes Sixt writes:
> test_cmp is intended to produce diff output for human consumption. The
> input in one instance in t9300-fast-import.sh are binary files, however.
> Use cmp to compare the files.
Thanks.
>
> This was noticed because on Windows we have a special im
test_cmp is intended to produce diff output for human consumption. The
input in one instance in t9300-fast-import.sh are binary files, however.
Use cmp to compare the files.
This was noticed because on Windows we have a special implementation of
test_cmp in pure bash code (to ignore differences
On Thu, Jul 31, 2014 at 3:31 PM, Philip Oakley wrote:
> I thought it worth bring to the list's attention a recent article on
> CodeProject that may be of interest to those looking at splitting binary
> files into deterministic hunks.
>
> http://www.codeproject.com/Articles/80
I thought it worth bring to the list's attention a recent article on
CodeProject that may be of interest to those looking at splitting binary
files into deterministic hunks.
http://www.codeproject.com/Articles/801608/Using-a-rolling-hash-to-break-up-binary-files
It's based on
wrote:
> Stepan Kasal writes:
> > test_cmp() is primarily meant to compare text files (and display the
> > difference for debug purposes).
> >
> > Raw "cmp" is better suited to compare binary files (tar, zip, etc.).
> >
> > On MinGW, test_cmp is a she
Stepan Kasal writes:
> test_cmp() is primarily meant to compare text files (and display the
> difference for debug purposes).
>
> Raw "cmp" is better suited to compare binary files (tar, zip, etc.).
>
> On MinGW, test_cmp is a shell function mingw_test_cmp that tri
test_cmp() is primarily meant to compare text files (and display the
difference for debug purposes).
Raw "cmp" is better suited to compare binary files (tar, zip, etc.).
On MinGW, test_cmp is a shell function mingw_test_cmp that tries to
read both files into environment, stripping CR
Hi Stephan,
Am 04.06.2014 14:42, schrieb Stepan Kasal:
> On Wed, Jun 04, 2014 at 02:13:44PM +0200, Thomas Braun wrote:
>> Wouldn't a function like test_cmp_bin() be better suited for all?
>
> I also considered it. The advantage is that is shows that
> this intentionally differs from test_cmp.
>
>
Hello Thomas,
On Wed, Jun 04, 2014 at 02:13:44PM +0200, Thomas Braun wrote:
> Wouldn't a function like test_cmp_bin() be better suited for all?
I also considered it. The advantage is that is shows that
this intentionally differs from test_cmp.
> The windows folks can then use cmp inside test_cm
Am 04.06.2014 13:42, schrieb Stepan Kasal:
> test_cmp() is primarily meant to compare text files (and display the
> difference for debug purposes).
>
> Raw "cmp" is better suited to compare binary files (tar, zip, etc.).
>
> On MinGW, test_cmp is a shell function
test_cmp() is primarily meant to compare text files (and display the
difference for debug purposes).
Raw "cmp" is better suited to compare binary files (tar, zip, etc.).
On MinGW, test_cmp is a shell function mingw_test_cmp that tries to
read both files into environment, stripping CR
Hi,
On Fri, May 16, 2014 at 04:29:58AM -0400, Jeff King wrote:
> [..] I hope I did not sound like "blame Stepan, he was screwed up".
no, you did not, it was ok.
> From msysgit's perspective, they may or may not want to revert the patch
> that they already have. That is a _separate_ issue, and I
On Fri, May 16, 2014 at 10:19:57AM +0200, Stepan Kasal wrote:
> On Thu, May 15, 2014 at 03:22:26PM -0400, Jeff King wrote:
> > As the person who is proposing the patch for git.git, I would hope
> > Stepan would follow up on such review and confirm whether or not it is
> > still needed.
>
> well,
Hello,
On Thu, May 15, 2014 at 03:22:26PM -0400, Jeff King wrote:
> As the person who is proposing the patch for git.git, I would hope
> Stepan would follow up on such review and confirm whether or not it is
> still needed.
well, I try to. (I verified that "less -I" works in msysGit before
submi
On Thu, May 15, 2014 at 07:42:00PM +0200, Johannes Schindelin wrote:
> > Hrm. Is this patch still necessary? In the time since this patch was
> > written, we did 0826579 (grep: load file data after checking
> > binary-ness, 2012-02-02)
>
> I have no time to test this but I trust that you made sur
Hi Peff,
On Wed, 14 May 2014, Jeff King wrote:
> On Wed, May 14, 2014 at 05:44:19PM +0200, Stepan Kasal wrote:
>
> > From: Johannes Schindelin
> > Date: Mon, 8 Nov 2010 16:10:43 +0100
> >
> > Incidentally, this makes grep -I respect the "binary" attribute (actually,
> > the "-text" attribute,
Jeff King writes:
> On Wed, May 14, 2014 at 05:44:19PM +0200, Stepan Kasal wrote:
>
>> From: Johannes Schindelin
>> Date: Mon, 8 Nov 2010 16:10:43 +0100
>>
>> Incidentally, this makes grep -I respect the "binary" attribute (actually,
>> the "-text" attribute, but "binary" implies that).
>>
>>
On Wed, May 14, 2014 at 10:52:28AM -0700, Junio C Hamano wrote:
> I do not think checking 'text' is the right way to do this. The
> attribute controls the eof normalization, and people sometimes want
> to keep CRLF terminated files in the repository no matter what the
> platform is (an example I
On Wed, May 14, 2014 at 05:44:19PM +0200, Stepan Kasal wrote:
> From: Johannes Schindelin
> Date: Mon, 8 Nov 2010 16:10:43 +0100
>
> Incidentally, this makes grep -I respect the "binary" attribute (actually,
> the "-text" attribute, but "binary" implies that).
>
> Since the attributes are not t
Stepan Kasal writes:
> From: Johannes Schindelin
> Date: Mon, 8 Nov 2010 16:10:43 +0100
>
> Incidentally, this makes grep -I respect the "binary" attribute (actually,
> the "-text" attribute, but "binary" implies that).
>
> Since the attributes are not thread-safe, we now need to switch off
> th
From: Johannes Schindelin
Date: Mon, 8 Nov 2010 16:10:43 +0100
Incidentally, this makes grep -I respect the "binary" attribute (actually,
the "-text" attribute, but "binary" implies that).
Since the attributes are not thread-safe, we now need to switch off
threading if -I was passed.
Signed-off
e --abort".
>
> The patch is very large, 882453899 bytes.
>
> The patch also includes many binary files.
>
> Extracting the content around and before line 7330213 and up to the
> next diff header in the patch I see this:
>
> perl -lne'print "$.\t$_" i
tinue".
If you prefer to skip this patch, run "git rebase --skip" instead.
To check out the original branch and stop rebasing, run "git rebase --abort".
The patch is very large, 882453899 bytes.
The patch also includes many binary files.
Extracting the content around and
Oj W wrote:
> Change a binary file whose filename contains an ampersand, then view
> the commitdiff page in gitweb.
>
> Git outputs a message like "Binary files a/b&w.dll and b/b&w.dll differ"
>
> Gitweb format_diff_from_to_header() doesn't notice anyth
Change a binary file whose filename contains an ampersand, then view
the commitdiff page in gitweb.
Git outputs a message like "Binary files a/b&w.dll and b/b&w.dll differ"
Gitweb format_diff_from_to_header() doesn't notice anything in that
output which needs escaping, an
Jeff King writes:
>> I use git mostly for game-development which means I have to deal with
>> a lot of binary files (images, sound files etc).
>>
>> When I came to a point where I had run image optimization on a
>> branch, I wanted to know of course how much sm
1 - 100 of 104 matches
Mail list logo
