* Re: [PATCH 3/5] refactor userdiff textconv code
From: Jeff King @ 2008-10-24 13:51 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git, Junio C Hamano, Matthieu Moy
In-Reply-To: <4901762A.3090003@viscovery.net>
On Fri, Oct 24, 2008 at 09:15:54AM +0200, Johannes Sixt wrote:
> +cat >expect.typechange <<'EOF'
> +Binary files a/file and /dev/null differ
> +diff --git a/file b/file
> +new file mode 120000
> +index ad8b3d2..67be421
> +--- /dev/null
> ++++ b/file
> +@@ -0,0 +1 @@
> ++frotz
> +\ No newline at end of file
> +EOF
Actually, I don't think this is right. The typechange has been broken
into two parts: the removal of the file contents and the addition of the
symlink. So the first part _should_ use the textconv, since it is just
comparing the file contents to /dev/null. But the second part should
not, since it is by definition just the text of the symlink. Ditto for
gitlinks, which have a special text representation. So how about this?
-- >8 --
only textconv regular files
We treat symlinks as text containing the results of the
symlink, so it doesn't make much sense to text-convert them.
Similarly gitlink components just end up as the text
"Subproject commit $sha1", which we should leave intact.
Note that a typechange may be broken into two parts: the
removal of the old part and the addition of the new. In that
case, we _do_ show the textconv for any part which is the
addition or removal of a file we would ordinarily textconv,
since it is purely acting on the file contents.
Signed-off-by: Jeff King <peff@peff.net>
---
diff.c | 3 +++
t/t4030-diff-textconv.sh | 28 ++++++++++++++++++++++++++++
2 files changed, 31 insertions(+), 0 deletions(-)
diff --git a/diff.c b/diff.c
index 52feba7..ce1317d 100644
--- a/diff.c
+++ b/diff.c
@@ -289,6 +289,9 @@ static int diff_filespec_textconv(struct diff_filespec *one)
if (!DIFF_FILE_VALID(one))
return 0;
+ if (!S_ISREG(one->mode))
+ return 0;
+
diff_filespec_load_driver(one);
if (!one->driver->textconv)
return 0;
diff --git a/t/t4030-diff-textconv.sh b/t/t4030-diff-textconv.sh
index e456746..a5cd99b 100755
--- a/t/t4030-diff-textconv.sh
+++ b/t/t4030-diff-textconv.sh
@@ -19,6 +19,22 @@ cat >expect.text <<'EOF'
+1
EOF
+cat >expect.typechange <<'EOF'
+--- a/file
++++ /dev/null
+@@ -1,2 +0,0 @@
+-0
+-1
+diff --git a/file b/file
+new file mode 120000
+index ad8b3d2..67be421
+--- /dev/null
++++ b/file
+@@ -0,0 +1 @@
++frotz
+\ No newline at end of file
+EOF
+
cat >hexdump <<'EOF'
#!/bin/sh
perl -e '$/ = undef; $_ = <>; s/./ord($&)/ge; print $_' "$1"
@@ -75,4 +91,16 @@ test_expect_success 'format-patch produces binary' '
test_cmp expect.binary actual
'
+# make a symlink the hard way that works on symlink-challenged file systems
+test_expect_failure 'textconv does not act on symlinks' '
+ echo -n frotz > file &&
+ git add file &&
+ git ls-files -s | sed -e s/100644/120000/ |
+ git update-index --index-info &&
+ git commit -m typechange &&
+ git show >diff &&
+ find_diff <diff >actual &&
+ test_cmp expect.typechange actual
+'
+
test_done
--
1.6.0.3.523.ge05eb.dirty
^ permalink raw reply related
* Re: git adds some text file as binary file by mistake
From: Michael J Gruber @ 2008-10-24 13:51 UTC (permalink / raw)
To: Ping Yin; +Cc: Git Mailing List
In-Reply-To: <46dff0320810240630s5cbfa62esd10a9da45ce37bf8@mail.gmail.com>
Ping Yin venit, vidit, dixit 24.10.2008 15:30:
> On Fri, Oct 24, 2008 at 8:54 PM, Michael J Gruber
> <git@drmicha.warpmail.net> wrote:
>> Ping Yin venit, vidit, dixit 24.10.2008 14:37:
>>> So what should i do if i want it added as text file?
>> You should give us more detail on the file ;)
>> What's the extension, what's the typical content? It may be a simple
>> matter of specifying attributes.
>> Do ordinary diff and grep recognize your files as text?
>>
>> Michael
>>
>
> It's just an xml file. I guess maybe there are some hidden characters
> at the beginning. I will figure it out later because i have no access
> to that file right now.
Maybe it's in an encoding which is not available on the machine you're
using git on?
> I'm just ask this problem in general sense. So is there a general way
> to specify whether a file is text or binary?
Bruce suggested a good read. To save you some time: You want to say
*.xml diff
or
*.xml diff crlf
in one of the attributes files, depending on whether you want git to
possibly translate line endings (which depends on other settings also).
Note that the "content type" of the file plays a role only for diffs and
stats, not for the actual storage (except for, possibly, crlf conversion).
Cheers,
Michael
^ permalink raw reply
* Re: What's cooking in git.git (Oct 2008, #05; Wed, 22)
From: Jakub Narebski @ 2008-10-24 13:45 UTC (permalink / raw)
To: git
In-Reply-To: <7v8wsf50ne.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> * gb/gitweb-pathinfo (Tue Oct 21 21:34:54 2008 +0200) 5 commits
> - gitweb: generate parent..current URLs
> - gitweb: parse parent..current syntax from PATH_INFO
> - gitweb: use_pathinfo filenames start with /
> - gitweb: generate project/action/hash URLs
> - gitweb: parse project/action/hash_base:filename PATH_INFO
>
> Seventh iteration; hopefully the usual gitweb gangs will give quick
> comments and ack to push this out to 'next' soon.
If I remember correctly v7 is mainly cosmetic changes, and I have
acked all or almost all of the equivalent patches from v6.
> * gb/refactor-pathinfo (Fri Oct 10 20:42:26 2008 +0200) 1 commit
> + gitweb: refactor input parameters parse/validation
>
> A major cleanup on the way gitweb parses its input arguments.
> Future gitweb patches to add more arguments into the PATH_INFO
> depend upon this initial cleanup work.
Nice.
> * jn/gitweb-customlinks (Sun Oct 12 00:02:32 2008 +0200) 1 commit
> - gitweb: Better processing format string in custom links in navbar
>
> Waiting for some sort of response from Pasky.
>
> * jc/gitweb-fix-cloud-tag (Tue Oct 14 21:27:12 2008 -0700) 1 commit
> + Fix reading of cloud tags
>
> Request-for-review-and-ack sent; waiting for response.
It would be nice to have those two...
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: git adds some text file as binary file by mistake
From: Bruce Stephens @ 2008-10-24 13:34 UTC (permalink / raw)
To: Ping Yin; +Cc: Michael J Gruber, Git Mailing List
In-Reply-To: <46dff0320810240630s5cbfa62esd10a9da45ce37bf8@mail.gmail.com>
"Ping Yin" <pkufranky@gmail.com> writes:
[...]
> I'm just ask this problem in general sense. So is there a general way
> to specify whether a file is text or binary?
Yes: gitattributes(5).
^ permalink raw reply
* Re: git adds some text file as binary file by mistake
From: Ping Yin @ 2008-10-24 13:30 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Git Mailing List
In-Reply-To: <4901C58D.4010309@drmicha.warpmail.net>
On Fri, Oct 24, 2008 at 8:54 PM, Michael J Gruber
<git@drmicha.warpmail.net> wrote:
> Ping Yin venit, vidit, dixit 24.10.2008 14:37:
>> So what should i do if i want it added as text file?
>
> You should give us more detail on the file ;)
> What's the extension, what's the typical content? It may be a simple
> matter of specifying attributes.
> Do ordinary diff and grep recognize your files as text?
>
> Michael
>
It's just an xml file. I guess maybe there are some hidden characters
at the beginning. I will figure it out later because i have no access
to that file right now.
I'm just ask this problem in general sense. So is there a general way
to specify whether a file is text or binary?
--
Ping Yin
^ permalink raw reply
* Re: git adds some text file as binary file by mistake
From: Michael J Gruber @ 2008-10-24 12:54 UTC (permalink / raw)
To: Ping Yin; +Cc: Git Mailing List
In-Reply-To: <46dff0320810240537i4f0d86b9p56def9ef6a69c180@mail.gmail.com>
Ping Yin venit, vidit, dixit 24.10.2008 14:37:
> So what should i do if i want it added as text file?
You should give us more detail on the file ;)
What's the extension, what's the typical content? It may be a simple
matter of specifying attributes.
Do ordinary diff and grep recognize your files as text?
Michael
^ permalink raw reply
* Re: [PATCH 3/5] refactor userdiff textconv code
From: Jeff King @ 2008-10-24 12:40 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git, Junio C Hamano, Matthieu Moy
In-Reply-To: <4901762A.3090003@viscovery.net>
On Fri, Oct 24, 2008 at 09:15:54AM +0200, Johannes Sixt wrote:
> What do we do when symlinks are involved? Pilot error? Or should we
> exclude them from textconv (and diff.*.command, for that matter)
> at all times? See a test case below.
Hrm, I hadn't really considered that. I would guess they should not be
excluded from diff.*.command; the external driver gets the mode, so it
is free to represent symlinks in whatever way it wants.
But clearly they are going to always be text, so there is no point in
textconv'ing them.
> +cat >expect.typechange <<'EOF'
> +Binary files a/file and /dev/null differ
> +diff --git a/file b/file
> +new file mode 120000
> +index ad8b3d2..67be421
> +--- /dev/null
> ++++ b/file
> +@@ -0,0 +1 @@
> ++frotz
> +\ No newline at end of file
> +EOF
> +
I find this output a bit confusing, since it actually breaks it into a
deletion and an addition. But I guess that is orthogonal to the textconv
issue, and intended. I don't think I've ever actually needed to diff a
symlink before.
-Peff
^ permalink raw reply
* git adds some text file as binary file by mistake
From: Ping Yin @ 2008-10-24 12:37 UTC (permalink / raw)
To: Git Mailing List
So what should i do if i want it added as text file?
--
Ping Yin
^ permalink raw reply
* Re: [RFC] Zit: the git-based single file content tracker
From: Giuseppe Bilotta @ 2008-10-24 12:15 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Jean-Luc Herren, git
In-Reply-To: <200810241332.32487.jnareb@gmail.com>
On Fri, Oct 24, 2008 at 1:32 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> On Fri, 24 Oct 2008, Giuseppe Bilotta wrote:
>> On Fri, Oct 24, 2008 at 12:31 PM, Jakub Narebski <jnareb@gmail.com> wrote:
>>> By the way RCS which I use for version control of single files use
>>> both approaches: it can store 'file,v' alongside 'file' (just like
>>> your '.zit.file/' or '.file.git/'), but it can also store files on
>>> per-directory basis in 'RCS/' subdirectory (proposed '.zit/file/' or
>>> '.zit/file.git/' solution)
>>
>> Indeed, there's not particular reason why both solutions shouldn't be
>> available. [...]
>
>> The only problem then is priority. When looking for a file's repo, do
>> we look at .file.git first, or .zit/file.git? How does RCS behave in
>> this case?
>
> rcsintro(1) states:
>
> If you don't want to clutter your working directory with RCS files, create
> a subdirectory called RCS in your working directory, and move all your RCS
> files there. RCS commands will look *first* into that directory to find
> needed files.
Cool. I pushed changes to this end to git.oblomov.eu/zit --now zit
will look for .zit/file.git first, then for .file.git; if neither is
found, and .zit/ exists, the repo is set to .zit/file.git, otherwise
it's set to .file.git
You can either manually mkdir .zit, or use zit init that does exactly
the same thing.
>>> By the way, it would be nice to have VC interface for Emacs for Zit...
>>
>> I'm afraid someone else will have to take care of that, since Emacs is
>> not really something I use.
>
> I'll try to hack it using contrib/emacs/vc-git.el as a base...
Cool, thanks.
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* Re: [RFC] Zit: the git-based single file content tracker
From: Jakub Narebski @ 2008-10-24 11:32 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: Jean-Luc Herren, git
In-Reply-To: <cb7bb73a0810240352u28bab2b5p907065680985270a@mail.gmail.com>
On Fri, 24 Oct 2008, Giuseppe Bilotta wrote:
> On Fri, Oct 24, 2008 at 12:31 PM, Jakub Narebski <jnareb@gmail.com> wrote:
>> "Giuseppe Bilotta" <giuseppe.bilotta@gmail.com> writes:
>>> On Fri, Oct 24, 2008 at 1:23 AM, Jean-Luc Herren <jlh@gmx.ch> wrote:
>>>> If you decide against a shared repository, maybe you want to
>>>> consider to not use ".zit.file/", but ".zit/file/" as the
>>>> repository? This would reduce the clutter to a single directory,
>>>> just like with ".git". And moving files around wouldn't be that
>>>> much complicated.
>>>
>>> Right. I'll give that a shot.
>>
>> By the way RCS which I use for version control of single files use
>> both approaches: it can store 'file,v' alongside 'file' (just like
>> your '.zit.file/' or '.file.git/'), but it can also store files on
>> per-directory basis in 'RCS/' subdirectory (proposed '.zit/file/' or
>> '.zit/file.git/' solution)
>
> Indeed, there's not particular reason why both solutions shouldn't be
> available. [...]
> The only problem then is priority. When looking for a file's repo, do
> we look at .file.git first, or .zit/file.git? How does RCS behave in
> this case?
rcsintro(1) states:
If you don't want to clutter your working directory with RCS files, create
a subdirectory called RCS in your working directory, and move all your RCS
files there. RCS commands will look *first* into that directory to find
needed files.
>> By the way, it would be nice to have VC interface for Emacs for Zit...
>
> I'm afraid someone else will have to take care of that, since Emacs is
> not really something I use.
I'll try to hack it using contrib/emacs/vc-git.el as a base...
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [RFC] Zit (v2): the git-based single file content tracker
From: Giuseppe Bilotta @ 2008-10-24 11:01 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <m34p32i83f.fsf@localhost.localdomain>
On Fri, Oct 24, 2008 at 12:43 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> Giuseppe Bilotta <giuseppe.bilotta@gmail.com> writes:
>
>> The reworked Zit ( git://git.oblomov.eu/zit ) works by creating
>> .file.git/ to track file's history. .file.git/info/excludes is
>> initialized to the very strong '*' pattern to ensure that things such
>> as git status etc only consider the actually tracked file.
> [...]
>
> Could you add it to Git Wiki page:
> http://git.or.cz/gitwiki/InterfacesFrontendsAndTools
>
> I think that the project is interesting enough to be added there
> even if it is still in beta, or even alpha, stage.
Ah, good idea. Done, in Version Control Interface layers section
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* Re: [RFC] Zit: the git-based single file content tracker
From: Giuseppe Bilotta @ 2008-10-24 10:52 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Jean-Luc Herren, git
In-Reply-To: <m38wsei8ne.fsf@localhost.localdomain>
On Fri, Oct 24, 2008 at 12:31 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> "Giuseppe Bilotta" <giuseppe.bilotta@gmail.com> writes:
>> On Fri, Oct 24, 2008 at 1:23 AM, Jean-Luc Herren <jlh@gmx.ch> wrote:
>
>> > If you decide against a shared repository, maybe you want to
>> > consider to not use ".zit.file/", but ".zit/file/" as the
>> > repository? This would reduce the clutter to a single directory,
>> > just like with ".git". And moving files around wouldn't be that
>> > much complicated.
>>
>> Right. I'll give that a shot.
>
> By the way RCS which I use for version control of single files use
> both approaches: it can store 'file,v' alongside 'file' (just like
> your '.zit.file/' or '.file.git/'), but it can also store files on
> per-directory basis in 'RCS/' subdirectory (proposed '.zit/file/' or
> '.zit/file.git/' solution)
Indeed, there's not particular reason why both solutions shouldn't be
available. I'll think about implementing it this way:
$ zit init
will indicate that we want to track many files, and thus it will
create a .zit directory under which RCS files will be available.
$ zit track somefile
will start tracking somefile by setting up .zit/somefile.git if .zit
is available or .somefile.git otherwise.
The only problem then is priority. When looking for a file's repo, do
we look at .file.git first, or .zit/file.git? How does RCS behave in
this case?
> By the way, it would be nice to have VC interface for Emacs for Zit...
I'm afraid someone else will have to take care of that, since Emacs is
not really something I use.
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* Re: [RFC] Zit (v2): the git-based single file content tracker
From: Jakub Narebski @ 2008-10-24 10:43 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git
In-Reply-To: <gdqbta$rhe$1@ger.gmane.org>
Giuseppe Bilotta <giuseppe.bilotta@gmail.com> writes:
> The reworked Zit ( git://git.oblomov.eu/zit ) works by creating
> .file.git/ to track file's history. .file.git/info/excludes is
> initialized to the very strong '*' pattern to ensure that things such
> as git status etc only consider the actually tracked file.
[...]
Could you add it to Git Wiki page:
http://git.or.cz/gitwiki/InterfacesFrontendsAndTools
I think that the project is interesting enough to be added there
even if it is still in beta, or even alpha, stage.
P.S. Currently I cannot access git.or.cz for some reason (it is
up for everyone else, and even for me on different remote machine).
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [RFC] Zit: the git-based single file content tracker
From: Jakub Narebski @ 2008-10-24 10:31 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: Jean-Luc Herren, git
In-Reply-To: <cb7bb73a0810232355u6de0479cyc260c80227f44e59@mail.gmail.com>
"Giuseppe Bilotta" <giuseppe.bilotta@gmail.com> writes:
> On Fri, Oct 24, 2008 at 1:23 AM, Jean-Luc Herren <jlh@gmx.ch> wrote:
> > If you decide against a shared repository, maybe you want to
> > consider to not use ".zit.file/", but ".zit/file/" as the
> > repository? This would reduce the clutter to a single directory,
> > just like with ".git". And moving files around wouldn't be that
> > much complicated.
>
> Right. I'll give that a shot.
By the way RCS which I use for version control of single files use
both approaches: it can store 'file,v' alongside 'file' (just like
your '.zit.file/' or '.file.git/'), but it can also store files on
per-directory basis in 'RCS/' subdirectory (proposed '.zit/file/' or
'.zit/file.git/' solution)
By the way, it would be nice to have VC interface for Emacs for Zit...
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] git-svn: change dashed git-config to git config
From: Eric Wong @ 2008-10-24 9:15 UTC (permalink / raw)
To: Deskin Miller; +Cc: git
In-Reply-To: <20081023192134.GB8320@euler>
Deskin Miller <deskinm@umich.edu> wrote:
> ---
> When testing git-svn changes, I'll often use git-svn.perl directly on a
> repository of mine, to see how things work. Recently I had this happen:
>
> $ git-svn.perl info
> Use of uninitialized value in scalar chomp at ../git/git-svn.perl line 1202.
> Use of uninitialized value in concatenation (.) or string at ../git/git-svn.perl line 1203.
>
> but the expected output showed up correctly, giving the SVN-like info.
>
> git svn info appeared to work just fine though, despite there being essentially
> no difference between the two. However, if I do the following, this is what I
> see:
>
> $ env /usr/libexec/git-core/git-svn info
> Can't exec "git-config": No such file or directory at /usr/libexec/git-core/git-svn line 1202.
> Use of uninitialized value in scalar chomp at /usr/libexec/git-core/git-svn line 1202.
>
> Again, the SVN info would still appear.
>
> Regardless, I think we want to change this call to use the non-dashed form.
Thanks Deskin,
Acked-by: Eric Wong <normalperson@yhbt.net>
> Deskin Miller
>
> git-svn.perl | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/git-svn.perl b/git-svn.perl
> index 33e1b50..2e68c68 100755
> --- a/git-svn.perl
> +++ b/git-svn.perl
> @@ -1126,7 +1126,7 @@ sub read_repo_config {
> my $v = $opts->{$o};
> my ($key) = ($o =~ /^([a-zA-Z\-]+)/);
> $key =~ s/-//g;
> - my $arg = 'git-config';
> + my $arg = 'git config';
> $arg .= ' --int' if ($o =~ /[:=]i$/);
> $arg .= ' --bool' if ($o !~ /[:=][sfi]$/);
> if (ref $v eq 'ARRAY') {
> --
> 1.6.0.2.554.g3041b
^ permalink raw reply
* Re: [PATCH] git-svn: don't escape tilde ('~') for http(s) URLs
From: Eric Wong @ 2008-10-24 9:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Björn Steinbrink, git, jsogo
In-Reply-To: <7viqrkv4vd.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> Eric Wong <normalperson@yhbt.net> writes:
> > Junio C Hamano <gitster@pobox.com> wrote:
> >> The patch may make a path with '~' work, but it (neither in the patch text
> >> nor in the commit log message) does not have much to give readers enough
> >> confidence that the code after the patch is the _final_ one, as opposed to
> >> being just a band-aid for a single symptom that happened to have been
> >> discovered this time.
> >
> > This is definitely a band-aid fix until I or somebody else takes the
> > time to figure out:
> >
> > 1. exactly which characters need to be escaped
> > 2. for which protocols those characters need to be escaped
> > 3. which part(s) of the URI they need to be escaped for
> > (repository root vs SVN path)
> > 4. which versions of SVN needs more (or less) escaping rules
> >
> > (I vote for somebody else, especially for #4 :)
>
> Item 3. above disturbs me. Do you mean that in:
>
> https://sucs.org/~welshbyte/svn/backuptool/trunk/foo~bar.txt
>
> the two tildes might have to be sent to libsvn-perl differently?
Yes, something like this is unfortunately a possibility (as is
having to worry about this at all in git-svn).
> Even if that is the case, I am inclined suggest taking the patch in the
> meantime as an interim workaround, with the understanding that we know the
> patch improves the situation for the tilde before welshbyte and even
> though we do not know if the patch regresses for the latter one between
> foo and bar, it would be much rarer to have tilde in such places.
>
> Care to come up with an updated log message?
From aa4f2cdcf64934e13886fabb3b5e986a5cda79f6 Mon Sep 17 00:00:00 2001
From: Eric Wong <normalperson@yhbt.net>
Date: Tue, 21 Oct 2008 14:12:15 -0700
Subject: [PATCH] git-svn: don't escape tilde ('~') for http(s) URLs
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
This change only fixes the tilde case in the repository URL. A
more comprehensive set of escaping rules and tests will be
needed in the future for complete compatibility when using
uncommon characters.
Thanks to Jose Carlos Garcia Sogo and Björn Steinbrink for the
bug report.
On 2008.10.18 23:39:19 +0200, Björn Steinbrink wrote:
> Hi,
>
> Jose Carlos Garcia Sogo reported on #git that a git-svn clone of this
> svn repo fails for him:
> https://sucs.org/~welshbyte/svn/backuptool/trunk
>
> I can reproduce that here with:
> git-svn version 1.6.0.2.541.g46dc1.dirty (svn 1.5.1)
>
> The error message I get is:
> Apache got a malformed URI: Unusable URI: it does not refer to this
> repository at /usr/local/libexec/git-core/git-svn line 4057
>
> strace revealed that git-svn url-encodes ~ while svn does not do that.
>
> For svn we have:
> write(5, "<S:update-report send-all=\"true\" xmlns:S=\"svn:\">
> <S:src-path>https://sucs.org/~welshbyte/svn/backuptool/trunk</S:src-path>...
>
> While git-svn shows:
> write(7, "<S:update-report send-all=\"true\" xmlns:S=\"svn:\">
> <S:src-path>https://sucs.org/%7Ewelshbyte/svn/backuptool/trunk</S:src-path>...
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
git-svn.perl | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index ef6d773..a97049a 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -852,7 +852,7 @@ sub escape_uri_only {
my ($uri) = @_;
my @tmp;
foreach (split m{/}, $uri) {
- s/([^\w.%+-]|%(?![a-fA-F0-9]{2}))/sprintf("%%%02X",ord($1))/eg;
+ s/([^~\w.%+-]|%(?![a-fA-F0-9]{2}))/sprintf("%%%02X",ord($1))/eg;
push @tmp, $_;
}
join('/', @tmp);
@@ -3537,7 +3537,7 @@ sub repo_path {
sub url_path {
my ($self, $path) = @_;
if ($self->{url} =~ m#^https?://#) {
- $path =~ s/([^a-zA-Z0-9_.-])/uc sprintf("%%%02x",ord($1))/eg;
+ $path =~ s/([^~a-zA-Z0-9_.-])/uc sprintf("%%%02x",ord($1))/eg;
}
$self->{url} . '/' . $self->repo_path($path);
}
@@ -3890,7 +3890,7 @@ sub escape_uri_only {
my ($uri) = @_;
my @tmp;
foreach (split m{/}, $uri) {
- s/([^\w.%+-]|%(?![a-fA-F0-9]{2}))/sprintf("%%%02X",ord($1))/eg;
+ s/([^~\w.%+-]|%(?![a-fA-F0-9]{2}))/sprintf("%%%02X",ord($1))/eg;
push @tmp, $_;
}
join('/', @tmp);
--
Eric Wong
^ permalink raw reply related
* Re: clean/smudge filters for pdf files
From: Michael J Gruber @ 2008-10-24 8:44 UTC (permalink / raw)
To: SLONIK.AZ; +Cc: Pierre Habouzit, git
In-Reply-To: <ee2a733e0810231840u1aed8455w7e4c461e2565ad08@mail.gmail.com>
Little addition to my previous reply:
Multivalent apparently almost get's there. After 2 iterations most of
the uncompressed file is stable, except for some binary blob at the end.
Alas, it's Java and not even completely open source.
Michael
^ permalink raw reply
* Re: [PATCH 3/7] gitk: Allow starting gui blame for a specific line.
From: Alexander Gavrilov @ 2008-10-24 8:13 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
In-Reply-To: <18688.26370.467724.404768@cargo.ozlabs.ibm.com>
On Thursday 23 October 2008 15:58:58 Paul Mackerras wrote:
> > + # Now scan the lines to determine offset within the hunk
> > + set parent {}
> > + set dline 0
> > + set s_lno [lindex [split $s_lix "."] 0]
> > +
> > + for {set i $line} {$i > $s_lno} {incr i -1} {
> > + set c_line [$ctext get $i.0 "$i.0 + 1 lines"]
> > + if {$parent eq {}} {
> > + # find first preceeding line that belongs to some parent
> > + for {set j 0} {$j < [llength $old_lines]} {incr j} {
> > + set code [string index $c_line $j]
> > + if {$code ne {-} && $code ne { }} continue
> > + if {$code eq { } && $parent ne {}} continue
> > + set parent $j
> > + if {$code eq {-}} break
> > + }
> > + }
>
> This part worries me a bit. If the user clicks on a line where all
> the $code values are "+" then I think we should blame the current
> commit. Either that, or we disable the context menu item before
> posting it if the user clicks on a line that starts with all "+"
> characters (as many "+" as there are parents).
Good point. How about this variant? I renamed the menu item, and
changed the code to blame the current commit if:
- The display is in the tree mode, or
- The line is added relative to all parents, or
- Diff analysis failed
I also fixed a bug in processing of deleted lines in combined diffs,
and made the parent selection code more readable (hopefully).
--- >8 ---
From: Alexander Gavrilov <angavrilov@gmail.com>
Subject: [PATCH] gitk: Allow starting gui blame for a specific line.
Adds a context menu item to the diff viewer pane that
calls blame, focusing it on the clicked line. In case
of combined diffs, it also automatically deduces which
parent is to be blamed. Lines added by the diff are
blamed on the current commit itself.
The context menu itself is added by this patch. It is
possible to populate it with commands from the flist
menu.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
---
gitk | 148 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
1 files changed, 146 insertions(+), 2 deletions(-)
diff --git a/gitk b/gitk
index f6a3e10..6fbd6bb 100755
--- a/gitk
+++ b/gitk
@@ -2249,6 +2249,7 @@ proc makewindow {} {
bind $cflist <ButtonRelease-1> {treeclick %W %x %y}
global ctxbut
bind $cflist $ctxbut {pop_flist_menu %W %X %Y %x %y}
+ bind $ctext $ctxbut {pop_diff_menu %W %X %Y %x %y}
set maincursor [. cget -cursor]
set textcursor [$ctext cget -cursor]
@@ -2291,6 +2292,13 @@ proc makewindow {} {
{mc "Blame parent commit" command {external_blame 1}}
}
$flist_menu configure -tearoff 0
+
+ global diff_menu
+ set diff_menu .diffctxmenu
+ makemenu $diff_menu {
+ {mc "Blame this line" command {external_blame_diff}}
+ }
+ $diff_menu configure -tearoff 0
}
# Windows sends all mouse wheel events to the current focused window, not
@@ -2993,6 +3001,34 @@ proc pop_flist_menu {w X Y x y} {
tk_popup $flist_menu $X $Y
}
+proc find_ctext_fileinfo {line} {
+ global ctext_file_names ctext_file_lines
+
+ set ok [bsearch $ctext_file_lines $line]
+ set tline [lindex $ctext_file_lines $ok]
+
+ if {$ok >= [llength $ctext_file_lines] || $line < $tline} {
+ return {}
+ } else {
+ return [list [lindex $ctext_file_names $ok] $tline]
+ }
+}
+
+proc pop_diff_menu {w X Y x y} {
+ global ctext diff_menu flist_menu_file
+ global diff_menu_txtpos diff_menu_line
+ global diff_menu_filebase
+
+ stopfinding
+ set diff_menu_txtpos [split [$w index "@$x,$y"] "."]
+ set diff_menu_line [lindex $diff_menu_txtpos 0]
+ set f [find_ctext_fileinfo $diff_menu_line]
+ if {$f eq {}} return
+ set flist_menu_file [lindex $f 0]
+ set diff_menu_filebase [lindex $f 1]
+ tk_popup $diff_menu $X $Y
+}
+
proc flist_hl {only} {
global flist_menu_file findstring gdttype
@@ -3099,7 +3135,96 @@ proc external_diff {} {
}
}
-proc external_blame {parent_idx} {
+proc find_hunk_blamespec {base line} {
+ global ctext
+
+ # Find and parse the hunk header
+ set s_lix [$ctext search -backwards -regexp ^@@ "$line.0 lineend" $base.0]
+ if {$s_lix eq {}} return
+
+ set s_line [$ctext get $s_lix "$s_lix + 1 lines"]
+ if {![regexp {^@@@*(( -\d+(,\d+)?)+) \+(\d+)(,\d+)? @@} $s_line \
+ s_line old_specs osz osz1 new_line nsz]} {
+ return
+ }
+
+ # base lines for the parents
+ set base_lines [list $new_line]
+ foreach old_spec [lrange [split $old_specs " "] 1 end] {
+ if {![regexp -- {-(\d+)(,\d+)?} $old_spec \
+ old_spec old_line osz]} {
+ return
+ }
+ lappend base_lines $old_line
+ }
+
+ # Now scan the lines to determine offset within the hunk
+ set parent {}
+ set dline 0
+ set s_lno [lindex [split $s_lix "."] 0]
+
+ for {set i $line} {$i > $s_lno} {incr i -1} {
+ set c_line [$ctext get $i.0 "$i.0 + 1 lines"]
+ # Determine if the line is removed
+ set chunk [string range $c_line 0 [llength $base_lines]-2]
+ set removed_idx [string first "-" $chunk]
+ # Choose a parent index
+ if {$parent eq {}} {
+ if {$removed_idx >= 0} {
+ set parent $removed_idx
+ incr parent
+ } else {
+ set unchanged_idx [string first " " $chunk]
+ if {$unchanged_idx >= 0} {
+ set parent $unchanged_idx
+ incr parent
+ } else {
+ # blame the current commit
+ set parent 0
+ }
+ }
+ }
+ # then count other lines that belong to it
+ if {$parent > 0} {
+ set code [string index $c_line $parent-1]
+ if {$code eq "-" || ($removed_idx < 0 && $code ne "+")} {
+ incr dline
+ }
+ } else {
+ if {$removed_idx < 0} {
+ incr dline
+ }
+ }
+ }
+
+ if {$parent eq {}} { set parent 0 }
+ incr dline [lindex $base_lines $parent]
+ return [list $parent $dline]
+}
+
+proc external_blame_diff {} {
+ global currentid diffmergeid cmitmode
+ global diff_menu_txtpos diff_menu_line
+ global diff_menu_filebase flist_menu_file
+
+ if {$cmitmode eq "tree"} {
+ set parent_idx 0
+ set line [expr {$diff_menu_line - $diff_menu_filebase - 1}]
+ } else {
+ set hinfo [find_hunk_blamespec $diff_menu_filebase $diff_menu_line]
+ if {$hinfo ne {}} {
+ set parent_idx [lindex $hinfo 0]
+ set line [lindex $hinfo 1]
+ } else {
+ set parent_idx 0
+ set line 0
+ }
+ }
+
+ external_blame $parent_idx $line
+}
+
+proc external_blame {parent_idx {line {}}} {
global flist_menu_file
global nullid nullid2
global parentlist selectedline currentid
@@ -3115,7 +3240,12 @@ proc external_blame {parent_idx} {
return
}
- if {[catch {exec git gui blame $base_commit $flist_menu_file &} err]} {
+ set cmdline [list git gui blame]
+ if {$line ne {} && $line > 1} {
+ lappend cmdline "--line=$line"
+ }
+ lappend cmdline $base_commit $flist_menu_file
+ if {[catch {eval exec $cmdline &} err]} {
error_popup "[mc "git gui blame: command failed:"] $err"
}
}
@@ -6364,6 +6494,7 @@ proc gettreeline {gtf id} {
proc showfile {f} {
global treefilelist treeidlist diffids nullid nullid2
+ global ctext_file_names ctext_file_lines
global ctext commentend
set i [lsearch -exact $treefilelist($diffids) $f]
@@ -6387,6 +6518,8 @@ proc showfile {f} {
filerun $bf [list getblobline $bf $diffids]
$ctext config -state normal
clear_ctext $commentend
+ lappend ctext_file_names $f
+ lappend ctext_file_lines [lindex [split $commentend "."] 0]
$ctext insert end "\n"
$ctext insert end "$f\n" filesep
$ctext config -state disabled
@@ -6447,6 +6580,7 @@ proc mergediff {id} {
proc getmergediffline {mdf id np} {
global diffmergeid ctext cflist mergemax
global difffilestart mdifffd treediffs
+ global ctext_file_names ctext_file_lines
global diffencoding
$ctext conf -state normal
@@ -6465,6 +6599,8 @@ proc getmergediffline {mdf id np} {
lappend difffilestart $here
lappend treediffs($id) $fname
add_flist [list $fname]
+ lappend ctext_file_names $fname
+ lappend ctext_file_lines [lindex [split $here "."] 0]
set diffencoding [get_path_encoding $fname]
set l [expr {(78 - [string length $fname]) / 2}]
set pad [string range "----------------------------------------" 1 $l]
@@ -6733,11 +6869,13 @@ proc setinlist {var i val} {
proc makediffhdr {fname ids} {
global ctext curdiffstart treediffs
+ global ctext_file_names
set i [lsearch -exact $treediffs($ids) $fname]
if {$i >= 0} {
setinlist difffilestart $i $curdiffstart
}
+ set ctext_file_names [lreplace $ctext_file_names end end $fname]
set l [expr {(78 - [string length $fname]) / 2}]
set pad [string range "----------------------------------------" 1 $l]
$ctext insert $curdiffstart "$pad $fname $pad" filesep
@@ -6746,6 +6884,7 @@ proc makediffhdr {fname ids} {
proc getblobdiffline {bdf ids} {
global diffids blobdifffd ctext curdiffstart
global diffnexthead diffnextnote difffilestart
+ global ctext_file_names ctext_file_lines
global diffinhdr treediffs
global diffencoding
@@ -6763,6 +6902,8 @@ proc getblobdiffline {bdf ids} {
# start of a new file
$ctext insert end "\n"
set curdiffstart [$ctext index "end - 1c"]
+ lappend ctext_file_names ""
+ lappend ctext_file_lines [lindex [split $curdiffstart "."] 0]
$ctext insert end "\n" filesep
# If the name hasn't changed the length will be odd,
# the middle char will be a space, and the two bits either
@@ -6899,6 +7040,7 @@ proc nextfile {} {
proc clear_ctext {{first 1.0}} {
global ctext smarktop smarkbot
+ global ctext_file_names ctext_file_lines
global pendinglinks
set l [lindex [split $first .] 0]
@@ -6912,6 +7054,8 @@ proc clear_ctext {{first 1.0}} {
if {$first eq "1.0"} {
catch {unset pendinglinks}
}
+ set ctext_file_names {}
+ set ctext_file_lines {}
}
proc settabs {{firstab {}}} {
--
1.6.0.20.g6148bc
^ permalink raw reply related
* Re: clean/smudge filters for pdf files
From: Michael J Gruber @ 2008-10-24 8:10 UTC (permalink / raw)
To: SLONIK.AZ; +Cc: Pierre Habouzit, git
In-Reply-To: <ee2a733e0810231840u1aed8455w7e4c461e2565ad08@mail.gmail.com>
Leo Razoumov venit, vidit, dixit 24.10.2008 03:40:
> On 10/23/08, Pierre Habouzit <madcoder@debian.org> wrote:
>> On Thu, Oct 23, 2008 at 07:44:39PM +0000, Leo Razoumov wrote:
>> > I am trying to improve storage efficiency for PDF files in a git repo.
>> > Following earlier discussions in this list I am trying to set up
>> > proper clean/smudge filters. What follows is my current setup
>> >
>> > # in ~/.gitconfig
>> > [filter "pdf"]
>> > clean = "pdftk - output - uncompress"
>> > smudge = "pdftk - output - compress"
>> >
>> > # in .gitattributes
>> > *.pdf filter=pdf
>> >
>> > Unfortunately, it seems as though that pdftk uncompress followed by
>> > pdftk compress do not leave the file invariant. I tried several
>> > uncompress+compress iterations and the file still keep changing (the
>> > size though stays the same).
>> > Is there any other alternative way to store PDF files in git repo more
>> > efficiently?
>> > Any alternative to pdftk on Linux?
>>
>>
>> actually it uses some kind of zlib algorithm so that's pretty normal you
>> don't have the same result with a packer. Maybe one could write a tool
>> like pristine-tar for that purpose.
>>
>
> With zlib you get the same deterministic result as long as you use the
> same zlib packer and unpacker. With pdftk compress/uncompress seem not
> to form a bijection pair. This issue was briefly discussed on this
> list back in April 2008 but no resolution emerged.
For a different file format I use the pair "gzip -c, gunzip -c" without
any problems, so zlib is not a problem. I do see the effect that
checkouts on different machines may have different compressed files
(same gzip version), but this is a non-issue.
Your experience with pdftk confirms mine. It shuffles things around
becauses it parses the files into objects and then writes them out again
in possibly different order. This is no problem for pdf because it uses
"pointers" (it's a bijection up to reordering), but it's a weird design,
and complicates things for us.
I'm still looking for something viable, I'll let list know when I've
found something...
Michael
^ permalink raw reply
* Re: git performance
From: Pete Harlan @ 2008-10-24 7:55 UTC (permalink / raw)
To: Edward Ned Harvey; +Cc: git
In-Reply-To: <000901c93490$e0c40ed0$a24c2c70$@com>
Edward Ned Harvey wrote:
> > Yes, it does stat all the files. How many files are you talking about,
> > and what platform? From a warm cache on Linux, the 23,000 files kernel
> > repo takes about a tenth of a second to stat all files for me (and this
>
> I'm talking about 40-50,000 files, on multi-user production linux,
> which means the cache is never warm, except when I'm benchmarking.
> Specifically RHEL 4 with the files on NFS mount. Cold cache "svn
> st" takes ~10 mins. Warm cache 20-30 sec. Surprisingly to me,
I did some tests with a repo with ~32k files, and git was slightly
slower than svn with a cold cache (10.2s vs 8.4s), and around twice as
fast with a warm cache (.5s vs 1s).
Git 1.6.0.2, svn 1.4.6. Cache made cold with
"echo 1 >/proc/sys/vm/drop_caches". Timings best of 5 runs.
(I did various benchmarks with svn 1.5.3 also, but there's something
awfully wrong with svn 1.5.x's merging, which takes pathologically
long compared with 1.4 (minutes instead of seconds), and it wasn't
noticeably faster than 1.4 at anything I tested.)
> performance was approx the same for files on local disk versus NFS.
10 minutes seems like a crazy amount of time for 40-50k files. If you
didn't say you'd tested it on local disks, it would really sound like
a bad NFS interaction more than an svn problem.
> Out of curiosity, what are they talking about, when they say "git is
> fast?"
In my comparisons between svn and git, the operation "checkout
revision N of the tree" (i.e., "svn update -r 40000" vs "git checkout
302c7476") took five minutes on subversion and ten seconds using git.
The tests were all local, so git wasn't benefiting from being a DVCS,
it was just eerily fast on some things. Svn was even that slow when
the revisions were 1 commit different, if it was a large enough
commit.
I don't check out whole revisions like that very often, but switching
between branches is a similar operation. It doesn't usually take five
minutes in svn but it's an interruption, and with git it isn't.
For almost everything I tried git was faster, but status wasn't really
one of them. The compelling cases were the number of things that were
faster _enough_ to no longer be an interruption, and being a DVCS, and
rebase, and rebase -i, and gitk, and a smarter blame, and
branching/merging support like it's something you'd do all day long,
not just when you were forced to.
HTH,
--Pete
^ permalink raw reply
* Re: [PATCH] Only update the cygwin-related configuration during state auto-setup
From: Alex Riesen @ 2008-10-24 7:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Mark Levedahl, spearce, dpotapov, git
In-Reply-To: <7viqri35dq.fsf@gitster.siamese.dyndns.org>
2008/10/24 Junio C Hamano <gitster@pobox.com>:
> Perhaps we should use a separate variable as the original patch did, in:
>
> http://article.gmane.org/gmane.comp.version-control.git/97987
>
> How about doing it like this instead?
I like this. Will start testing it over next european night, as soon as
the current test run finishes. In about 6 hours, that is :-/
^ permalink raw reply
* Re: [PATCH 3/5] refactor userdiff textconv code
From: Johannes Sixt @ 2008-10-24 7:15 UTC (permalink / raw)
To: Jeff King; +Cc: git, Junio C Hamano, Matthieu Moy
In-Reply-To: <20081024025330.GC2831@coredump.intra.peff.net>
Jeff King schrieb:
> This patch moves the text conversion to a
> diff_filespec_textconv function; this function can be called
> to insert the text-converted contents of the file into the
> filespec. These contents will survive through any
> diff_populate_filespec calls, meaning that it is safe to
> pass the resulting filespec to other diff functions which
> will look at the content.
What do we do when symlinks are involved? Pilot error? Or should we
exclude them from textconv (and diff.*.command, for that matter)
at all times? See a test case below.
> Also, I'm happy to hear comments on which functionality should get
> text-converted. I think I like seeing the --stat report the binary
> changes.
At this time I also think that it is enough to apply textconv only
to generate diffs.
Test case follows:
diff --git a/t/t4030-diff-textconv.sh b/t/t4030-diff-textconv.sh
index e456746..dab4338 100755
--- a/t/t4030-diff-textconv.sh
+++ b/t/t4030-diff-textconv.sh
@@ -19,6 +19,18 @@ cat >expect.text <<'EOF'
+1
EOF
+cat >expect.typechange <<'EOF'
+Binary files a/file and /dev/null differ
+diff --git a/file b/file
+new file mode 120000
+index ad8b3d2..67be421
+--- /dev/null
++++ b/file
+@@ -0,0 +1 @@
++frotz
+\ No newline at end of file
+EOF
+
cat >hexdump <<'EOF'
#!/bin/sh
perl -e '$/ = undef; $_ = <>; s/./ord($&)/ge; print $_' "$1"
@@ -75,4 +87,16 @@ test_expect_success 'format-patch produces binary' '
test_cmp expect.binary actual
'
+# make a symlink the hard way that works on symlink-challenged file systems
+test_expect_failure 'textconv does not kick in if there is a type change' '
+ echo -n frotz > file &&
+ git add file &&
+ git ls-files -s | sed -e s/100644/120000/ |
+ git update-index --index-info &&
+ git commit -m typechange &&
+ git show >diff &&
+ find_diff <diff >actual &&
+ test_cmp expect.typechange actual
+'
+
test_done
^ permalink raw reply related
* Re: [RFC] Zit (v2): the git-based single file content tracker
From: Giuseppe Bilotta @ 2008-10-24 7:14 UTC (permalink / raw)
To: david; +Cc: git
In-Reply-To: <alpine.DEB.1.10.0810232314490.20238@asgard.lang.hm>
On Fri, Oct 24, 2008 at 8:21 AM, <david@lang.hm> wrote:
> On Thu, 23 Oct 2008, Giuseppe Bilotta wrote:
>
>> I decided to give the simpler GIT_DIR approach another go.
>>
>> The reworked Zit ( git://git.oblomov.eu/zit ) works by creating
>> .file.git/ to track file's history. .file.git/info/excludes is
>> initialized to the very strong '*' pattern to ensure that things such
>> as git status etc only consider the actually tracked file.
>>
>> The obvious advantage over the previous implementation is that we
>> don't rely on fragile and non-portable hardlinks. The disadvantage
>> is that something really bad can happen if a command fails to obey
>> GIT_DIR or GIT_WORK_TREE correctly.
>
> this is a very interesting approach.
>
> the thought that hit me as I finidhed reading this thread is that we are
> very close to having the full continum of file/repository combinations
>
> 1. everything in the dir is part of one repository (the normal git case)
>
> 2. some of all of the individual files in a dir is it's own repository (the
> zit case)
>
> 3. the in-between case where you can have multiple repositories that can
> have multiple files in them.
>
> how hard would it be to extend zit to support case #3?
>
> offhand I can see it complicating the task of figuring out which repository
> to use for a file, but what else?
I haven't tried this yet, but I think it should be possible without
much problems. The important thing to keep in mind is that the second
parameter to zit (for all commands but zit init) 'only' identifies the
repository, and the filename parameter is NOT passed to git. The only
exceptions are zit add and git commit, and I'm having second thoughts
on add. Anyway, you can always use the 'raw' version of a command to
guarantee that only GIT_DIR and GIT_WORK_TREE are set, thus:
$ zit rawadd somefile -f someotherfile
will force-add someotherfile to somefile's repo. (Force adding is
required because of the blanket exclude.) Of course, it would be
interesting adding to zit the capability to do
$ zit diff someotherfile
to make it guess that it should use somefile's repo. This is possible
with some symlinks for the git repos, probably.
I'll have a look into it.
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* Re: [PATCH 4/5] userdiff: require explicitly allowing textconv
From: Johannes Sixt @ 2008-10-24 7:04 UTC (permalink / raw)
To: Jeff King; +Cc: git, Junio C Hamano, Matthieu Moy
In-Reply-To: <20081024025553.GD2831@coredump.intra.peff.net>
Jeff King schrieb:
> This introduces a new diff options, ALLOW_TEXTCONV, which
> controls this behavior. It is off by default, but is
> explicitly turned on for the "log" family of commands, as
> well as the "diff" porcelain.
...
> Johannes, you had mentioned some heuristics. Maybe you would like to
> take a stab at implementing them on top of this?
I'll put it on my todo list for this weekend.
-- Hannes
^ permalink raw reply
* Re: [PATCH 3/4] diff: introduce diff.<driver>.binary
From: Johannes Sixt @ 2008-10-24 7:02 UTC (permalink / raw)
To: Jeff King; +Cc: git, Junio C Hamano, Matthieu Moy
In-Reply-To: <20081024024631.GA20365@coredump.intra.peff.net>
Thank you for picking up the topic again and continuing on it. Your series
works nicely here, even without setting diff.*.binary.
-- Hannes
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox