* Re: [PATCH] Make Git accept absolute path names for files within the work tree
From: Jeff King @ 2007-12-04 1:43 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: Junio C Hamano, Anatol Pomozov, git, Linus Torvalds
In-Reply-To: <200712032153.31322.robin.rosenberg.lists@dewire.com>
On Mon, Dec 03, 2007 at 09:53:30PM +0100, Robin Rosenberg wrote:
> code did not pass). Like Linus, this code does not resolve symlinks,
> but I forgot to state that it is by design. It solves my problem and
By design meaning "I didn't feel like implemening it because I do not
personally care" or "I have some reason not to resolve symlinks"?
-Peff
^ permalink raw reply
* [PATCH] t9600: require cvsps 2.1 to perform tests
From: Jeff King @ 2007-12-04 1:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: gitzilla, Johannes Schindelin, git
In-Reply-To: <7vir3fe54c.fsf@gitster.siamese.dyndns.org>
git-cvsimport won't run at all with less than cvsps 2.1, because it
lacks the -A flag. But there's no point in preventing people who have an
old cvsps from running the full testsuite.
Tested-by: A Large Angry SCM <gitzilla@gmail.com>
Signed-off-by: Jeff King <peff@peff.net>
---
On Mon, Dec 03, 2007 at 03:21:55PM -0800, Junio C Hamano wrote:
> Jeff, would you want to further amend the patch to use "say" as Hannes
> suggested to make it look nicer?
Here it is.
t/t9600-cvsimport.sh | 20 ++++++++++++++++++--
1 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/t/t9600-cvsimport.sh b/t/t9600-cvsimport.sh
index 08f0f2a..7706430 100755
--- a/t/t9600-cvsimport.sh
+++ b/t/t9600-cvsimport.sh
@@ -3,13 +3,29 @@
test_description='git-cvsimport basic tests'
. ./test-lib.sh
-if ! ( type cvs && type cvsps ) >/dev/null 2>&1
+if ! type cvs >/dev/null 2>&1
then
- test_expect_success 'skipping cvsimport tests, cvs/cvsps not found' ''
+ say 'skipping cvsimport tests, cvs not found'
test_done
exit
fi
+cvsps_version=`cvsps -h 2>&1 | sed -ne 's/cvsps version //p'`
+case "$cvsps_version" in
+2.1)
+ ;;
+'')
+ say 'skipping cvsimport tests, cvsps not found'
+ test_done
+ exit
+ ;;
+*)
+ say 'skipping cvsimport tests, cvsps too old'
+ test_done
+ exit
+ ;;
+esac
+
CVSROOT=$(pwd)/cvsroot
export CVSROOT
# for clean cvsps cache
--
1.5.3.7.2070.g88cf2-dirty
^ permalink raw reply related
* Re: [PATCH] hg-to-git: do not include the branch name as the first line of commit msg
From: Junio C Hamano @ 2007-12-04 1:20 UTC (permalink / raw)
To: Mark Drago; +Cc: stelian, gitster, git
In-Reply-To: <4751A036.1080209@gmail.com>
Mark Drago <markdrago@gmail.com> writes:
> Signed-off-by: Mark Drago <markdrago@gmail.com>
> ---
> contrib/hg-to-git/hg-to-git.py | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/contrib/hg-to-git/hg-to-git.py b/contrib/hg-to-git/hg-to-git.py
> index 7a1c3e4..6bff49b 100755
> --- a/contrib/hg-to-git/hg-to-git.py
> +++ b/contrib/hg-to-git/hg-to-git.py
> @@ -158,7 +158,7 @@ for cset in range(int(tip) + 1):
> mparent = None
>
> (fdcomment, filecomment) = tempfile.mkstemp()
> - csetcomment = os.popen('hg log -r %d -v | grep -v ^changeset: | grep -v ^parent: | grep -v ^user: | grep -v ^date | grep -v ^files: | grep -v ^description: | grep -v ^tag:' % cset).read().strip()
> + csetcomment = os.popen('hg log -r %d -v | grep -v ^changeset: | grep -v ^parent: | grep -v ^user: | grep -v ^date | grep -v ^files: | grep -v ^description: | grep -v ^tag: | grep -v ^branch:' % cset).read().strip()
> os.write(fdcomment, csetcomment)
> os.close(fdcomment)
Isn't this one of the ugliest lines in the whole git.git project, I have
to wonder?
I also wonder missing colon after "date" is a bug from the original
version, and assuming that it is, how about doing something less error
prone like this?
def included(line):
keywords = ('changeset', 'parent', 'user', 'date', 'files',
'description', 'tag', 'branch')
for kw in keywords:
if line.startswith(kw + ':'):
return 0
return 1
hglog = os.popen('hg log -r %d -v' % cset).read();
csetcomment = '\n'.join(filter(included, hglog.split('\n'))).strip()
If you are excluding _all_ of the <word>: header lines, the "included"
function may have to become cleverer but much simpler by doing something
like:
import re
header_re = re.compile(r'^\w+:')
def included(line):
return not header_re.match(line)
^ permalink raw reply
* Re: [PATCH] install-sh from automake does not like -m without delimiting space
From: Junio C Hamano @ 2007-12-04 1:02 UTC (permalink / raw)
To: Robert Schiele; +Cc: git, spearce
In-Reply-To: <20071201170540.GS11347@schiele.dyndns.org>
Robert Schiele <rschiele@gmail.com> writes:
> The install-sh script as shipped with automake requires a space between
> the -m switch and its argument. Since this is also the regular way of
> doing it with other install implementations this change inserts the
> missing space in all makefiles.
I do not think this is risky, so I'll take it but please yell if it
breaks some existing setups.
I'll ask Shawn to do that part separately.
Thanks.
^ permalink raw reply
* Re: [PATCH] xdiff-interface.c (buffer_is_binary): Remove buffer size limitation
From: Johannes Schindelin @ 2007-12-04 1:00 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Dmitry V. Levin, Junio C Hamano, Git Mailing List
In-Reply-To: <alpine.LFD.0.9999.0712031559480.8458@woody.linux-foundation.org>
Hi,
On Mon, 3 Dec 2007, Linus Torvalds wrote:
> On Tue, 4 Dec 2007, Dmitry V. Levin wrote:
> >
> > Average file size in the linux-2.6.23.9 kernel tree is 10944 bytes,
>
> Don't do "average" sizes. That's an almost totally meaningless number.
>
> "Average" makes sense if you have some kind of gaussian distribution or
> similar.
To enhance on that: Gaussian is symmetric, which cannot be the proper
distribution for anything that is non-negative.
I see so many mis-applications of statistics/probability theory in my day
job that I cannot resist pointing people to the Poisson distribution here
(in whose context "average" actually makes kind of sense).
But back to the problem: if you have a truly binary file, then _every_
byte (absent further information, of course) has a probability of 1/256 of
being 0.
Which means that if a file is binary, but is unusual enough to have that
property only for half of the first 8192 bytes, you get a probability of
1 - 1 / 256^4096 = 1 - 1 / 2 ^ 32768 that the current test succeeds.
I fail to see how this test can possibly fail for the average case.
So if it fails only for special cases, we are probably (in the common, not
the mathematical, sense) better off asking those people encountering them
to add git-attributes for the files.
IMHO that is not asking for too much.
Ciao,
Dscho
^ permalink raw reply
* Re: v1.5.4 plans
From: Russell @ 2007-12-04 0:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk5nwu51x.fsf@gitster.siamese.dyndns.org>
On Dec 3, 2007 7:04 AM, Junio C Hamano <gitster@pobox.com> wrote:
> * We have already removed svnimport without giving a deprecation notice
> in the release notes of the previous feature release, which was bad.
> Maybe the users will forgive us. Maybe not.
Ah, that explains that. I was in the middle of importing the open2x
project into a git repo. It's a large tree which looks like it
includes several copies of linux 2.4, and importing is taking several
days. Occasionally the svn connection times out or something, and I
just restart it and it continues. In the middle of that I built and
installed git 1.5.3.7 and was surprised when git-svnimport wasn't
there the next time I tried to restart it. Back to 1.5.3.6 for now.
I see there's a thread about using a git-svnimport tree with git-svn,
so I'll do that.
Oh, and you're forgiven. :)
--
Virus found in this message.
^ permalink raw reply
* Re: What's in git-gui.git
From: Miklos Vajna @ 2007-12-04 0:29 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20071203041010.GT14735@spearce.org>
[-- Attachment #1: Type: text/plain, Size: 693 bytes --]
On Sun, Dec 02, 2007 at 11:10:10PM -0500, "Shawn O. Pearce" <spearce@spearce.org> wrote:
> The following changes since gitgui-0.9.0 are now in my git-gui
> master branch. I'm considering tagging a 0.9.1 release next week.
The following changes since commit 6f4ec3aa29450f4fa5af3cd8f6593d46d80aa909:
Christian Stimming (1):
Update German translation. 100% completed.
are available in the git repository at:
git://repo.or.cz/git-gui/git-gui-i18n.git mob
Miklos Vajna (1):
Update Hungarian translation. 100% completed.
po/hu.po | 682 +++++++++++++++++++++++++++++++++-----------------------------
1 files changed, 362 insertions(+), 320 deletions(-)
thanks,
- VMiklos
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] xdiff-interface.c (buffer_is_binary): Remove buffer size limitation
From: Linus Torvalds @ 2007-12-04 0:00 UTC (permalink / raw)
To: Dmitry V. Levin; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <20071203215007.GA14697@basalt.office.altlinux.org>
On Tue, 4 Dec 2007, Dmitry V. Levin wrote:
>
> Average file size in the linux-2.6.23.9 kernel tree is 10944 bytes,
Don't do "average" sizes. That's an almost totally meaningless number.
"Average" makes sense if you have some kind of gaussian distribution or
similar. File sizes tend to be exponential distributions, and what makes
much more sense is to look at the median. That doesn't show the effect of
a few larger files, and also gives you a much better "half the files are
smaller than x" idea.
And the median filesize for the kernel is just a few bytes over 4k.
Of the 23,000+ files in the current kernel, about 15,500 are less than
8kB. And 17,179 are smaller than the 10944 bytes you mention.
I'd argue that 8kB (or even 4kB) is probably a good number for things like
that: it catches the bulk of all files in their entirety, but it *avoids*
spending tons of time on the (few) really large files.
Linus
^ permalink raw reply
* Re: Fix UTF Encoding issue
From: Jakub Narebski @ 2007-12-03 23:37 UTC (permalink / raw)
To: Benjamin Close
Cc: Ismail Dönmez, Martin Koegler, Junio C Hamano,
Alexandre Julliard, git
In-Reply-To: <20071203230432.GA1337@wolf.clearchain.com>
On Tue, 4 Dec 2007, Benjamin Close wrote:
> On Tue, Dec 04, 2007 at 12:20:26AM +0200, Ismail Donmez wrote:
> >
> > Can you try the attached patch?
>
> I confirm that the patch corrects the problem.
>
> Without it I get the Cannot decode string error. With it gitweb
> displays correctly.
But the patch _avoids_ issue (des not convert owner to utf8), rather
than solving it, if I understand it correctly. What if gecos is in
utf-8?
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: Fix UTF Encoding issue
From: Benjamin Close @ 2007-12-03 23:04 UTC (permalink / raw)
To: Ismail D??nmez
Cc: Jakub Narebski, Martin Koegler, Junio C Hamano,
Alexandre Julliard, git, Perl Unicode Mailing List, Dan Kogai
In-Reply-To: <200712040020.26773.ismail@pardus.org.tr>
On Tue, Dec 04, 2007 at 12:20:26AM +0200, Ismail D??nmez wrote:
> Monday 03 December 2007 Tarihinde 23:46:24 yazm????t??:
> > Jakub Narebski wrote:
> > > On Mon, 3 Dec 2007, Martin Koegler wrote:
> > >> On Mon, Dec 03, 2007 at 04:06:48AM -0800, Jakub Narebski wrote:
> > >>> Ismail D??nmez <ismail@pardus.org.tr> writes:
> > >>>> Monday 03 December 2007 Tarihinde 12:14:43 yazm??t?:
> > >>>>> Benjamin Close <Benjamin.Close@clearchain.com> writes:
> > >>>>>> - eval { $res = decode_utf8($str, Encode::FB_CROAK); };
> > >>>>>> - if (defined $res) {
> > >>>>>> - return $res;
> > >>>>>> - } else {
> > >>>>>> - return decode($fallback_encoding, $str, Encode::FB_DEFAULT);
> > >>>>>> - }
> > >>>>>> + eval { return ($res = decode_utf8($str, Encode::FB_CROAK)); };
> > >>>>>> + return decode($fallback_encoding, $str, Encode::FB_DEFAULT);
> > >>>>>> }
> > >>
> > >> This version is broken on Debian sarge and etch. Feeding a UTF-8 and a
> > >> latin1 encoding of the same character sequence yields to different
> > >> results.
> >
> > For the record, this was on a debian sid machine.
> >
> > #perl --version
> > This is perl, v5.8.8 built for x86_64-linux-gnu-thread-multi
> >
> > and the result of not using the original patch was:
> >
> > <h1>Software error:</h1>
> > <pre>Cannot decode string with wide characters at
> > /usr/lib/perl/5.8/Encode.pm line 166. </pre>
>
> Can you try the attached patch?
I confirm that the patch corrects the problem.
Without it I get the Cannot decode string error. With it gitweb displays
correctly.
Cheers,
Benjamin
^ permalink raw reply
* Re: make test failure with latest master
From: A Large Angry SCM @ 2007-12-03 23:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Johannes Schindelin, git
In-Reply-To: <7vir3fe54c.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> A Large Angry SCM <gitzilla@gmail.com> writes:
[...]
>> Acked-by: A Large Angry SCM <gitzilla@gmail.com>
>
> It would be Tested-by: in a stricter sense of the word but thanks for
> testing.
Tested-by: A Large Angry SCM <gitzilla@gmail.com>
^ permalink raw reply
* Re: [PATCH] xdiff-interface.c (buffer_is_binary): Remove buffer size limitation
From: Junio C Hamano @ 2007-12-03 23:24 UTC (permalink / raw)
To: Dmitry V. Levin; +Cc: Git Mailing List
In-Reply-To: <20071203215007.GA14697@basalt.office.altlinux.org>
"Dmitry V. Levin" <ldv@altlinux.org> writes:
> On Sat, Dec 01, 2007 at 11:46:52AM -0800, Junio C Hamano wrote:
>> On Sat, Dec 01, 2007 at 07:01:13PM +0300, Dmitry V. Levin wrote:
>>
>> > When checking buffer for NUL byte, do not limit size of buffer we check.
>> > Otherwise we break git-rebase: git-format-patch may generate output which
>> > git-mailinfo cannot handle properly.
>>
>> I think this is tackling a valid problem but it is a wrong solution.
>> The change penalizes text changes which is the majority, just in case
>> there is an unusual change that has an embedded NUL far into the file
>> (iow, exception).
>
> Penalizes?
> Average file size in the linux-2.6.23.9 kernel tree is 10944 bytes,
> FIRST_FEW_BYTES limit is 8000 bytes.
I really wish we were living in a simpler time, back when I could just
say "we optimize for the kernel" and did not have to be worried about
getting laughed at.
^ permalink raw reply
* Re: make test failure with latest master
From: Junio C Hamano @ 2007-12-03 23:21 UTC (permalink / raw)
To: gitzilla; +Cc: Jeff King, Johannes Schindelin, git, gitster
In-Reply-To: <47548CEC.6010701@gmail.com>
A Large Angry SCM <gitzilla@gmail.com> writes:
> Jeff King wrote:
>> On Sun, Dec 02, 2007 at 11:41:10PM +0000, Johannes Schindelin wrote:
>>
>>>> Attached is the output of
>>>>
>>>> ./t9600-cvsimport.sh --verbose >/tmp/9600_out.txt 2>&1
>>>>
>>> Unfortunately you attached the interesting part, so I cannot quote
>>> it here. Seems that your cvsps does not understand the "-A"
>>> option. So it looks like it is too old.
>
> [Ignoring gitte's declaration that the core of git is dependent on CVS]
>
>> Yes, the changelog indicates that -A was added in 2.1, and he is running
>> 2.0rc1.
>>
>> We can do something like this, though it feels a bit hack-ish and will
>> need updated for new cvsps versions (a less lazy or more clever shell
>> coder than me could do a nice >= version comparator).
>
> The patch "fixes" the issue for me.
>
>> -- >8 --
>> t9600: require cvsps 2.1 to perform tests
>>
>> git-cvsimport won't run at all with less than cvsps 2.1, because it
>> lacks the -A flag. But there's no point in preventing people who have an
>> old cvsps from running the full testsuite.
>>
>> Signed-off-by: Jeff King <peff@peff.net>
>
> Acked-by: A Large Angry SCM <gitzilla@gmail.com>
It would be Tested-by: in a stricter sense of the word but thanks for
testing.
Jeff, would you want to further amend the patch to use "say" as Hannes
suggested to make it look nicer?
^ permalink raw reply
* Re: make test failure with latest master
From: A Large Angry SCM @ 2007-12-03 23:10 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Schindelin, git, gitster
In-Reply-To: <20071203015954.GB8322@coredump.intra.peff.net>
Jeff King wrote:
> On Sun, Dec 02, 2007 at 11:41:10PM +0000, Johannes Schindelin wrote:
>
>>> Attached is the output of
>>>
>>> ./t9600-cvsimport.sh --verbose >/tmp/9600_out.txt 2>&1
>>>
>> Unfortunately you attached the interesting part, so I cannot quote it
>> here. Seems that your cvsps does not understand the "-A" option. So it
>> looks like it is too old.
[Ignoring gitte's declaration that the core of git is dependent on CVS]
> Yes, the changelog indicates that -A was added in 2.1, and he is running
> 2.0rc1.
>
> We can do something like this, though it feels a bit hack-ish and will
> need updated for new cvsps versions (a less lazy or more clever shell
> coder than me could do a nice >= version comparator).
The patch "fixes" the issue for me.
> -- >8 --
> t9600: require cvsps 2.1 to perform tests
>
> git-cvsimport won't run at all with less than cvsps 2.1, because it
> lacks the -A flag. But there's no point in preventing people who have an
> old cvsps from running the full testsuite.
>
> Signed-off-by: Jeff King <peff@peff.net>
Acked-by: A Large Angry SCM <gitzilla@gmail.com>
^ permalink raw reply
* Re: [PATCH] Make Git accept absolute path names for files within the work tree
From: Junio C Hamano @ 2007-12-03 23:03 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: Jeff King, Anatol Pomozov, git, Linus Torvalds
In-Reply-To: <200712032153.31322.robin.rosenberg.lists@dewire.com>
Robin Rosenberg <robin.rosenberg.lists@dewire.com> writes:
> I will not surrender to the fierce competion on this subject. Here is
> an update with hopefully correct test cases this time.
Yay, that's the spirit!
> ... Like Linus, this code does not resolve symlinks,
> but I forgot to state that it is by design.
Perhaps state it in the commit log message?
> static const char *add_prefix(const char *prefix, const char *path)
> {
> + return prefix_path(prefix, prefix ? strlen(prefix) : 0, path);
> }
Ok; prefix_path can get NULL prefix (not complaining; just a reminder in
the following discussion).
> diff --git a/setup.c b/setup.c
> index 2c7b5cb..1f0ec79 100644
> --- a/setup.c
> +++ b/setup.c
> @@ -4,9 +4,62 @@
> static int inside_git_dir = -1;
> static int inside_work_tree = -1;
>
> +static
> +const char *strip_work_tree_path(const char *prefix, int len, const char *path)
Style. "static" not on its own line.
> +{
> + const char *work_tree = get_git_work_tree();
> + int n = strlen(work_tree);
Preconditions.
* prefix could be NULL or path to the subdirectory the user's
non-absolute path should be relative to, expressed as a relative path
to the top of the work tree, including a trailing slash. len is the
length of the prefix string.
* path was determined by the caller to be absolute.
* It is assumed that get_git_work_tree() always gives absolute path,
and without trailing slash.
* Does prefix always NULL if we are at the top, and never "", I wonder.
But lets assume that, too.
> + if (strncmp(path, work_tree, n))
> + return path;
If the given path is outside the work tree, return absolute as-is.
After this point we know path matches the work tree
> + if (!prefix && !path[n])
> + return path + n;
If we are at the top of the work tree and path names the top of the work
tree, then we return "".
> + if (!prefix) {
> + if (path[n] == '/')
> + return path + n + 1;
If we are at the top of the work tree and the path names the top of the
work tree followed by a slash and then something, that is a path inside
the work tree. Return relative to the top of the work tree.
> + else
> + if (path[n])
> + return path;
> + else
> + return path + n;
> + }
Style. "else if" would give you shallower indentation. We know path[n]
was not slash, and if it is not NUL then path is not inside the work
tree but is a neighbour (e.g. worktree is /a/b and path is /a/bc).
Return absolute. Otherwise the path names the top of the work tree
itself so we return "".
Now at this point, we know we are in a subdirectory, because the above
if (!prefix) part always return. So the test for prefix here is
unnecessary.
> + if (prefix && !path[n])
> + return path;
If we are in a subdirectory, and path names the top of the work tree, we
return it as-is (i.e. absolute). This feels a bit inconsistent with the
part that follows, which tries to make things relative by using "../",
doesn't it?
> + if (strncmp(path + n + 1, prefix, len - 1)) {
For !prefix case we have determined path is not merely a neighbour, but
we haven't checked that in this codepath. If the parameters were like
this:
path = /axbc/e
work_tree = /a
n = 2
prefix = bc/
len = 3
this check says "fine, path is under prefix and we won't add ../
uplevels". You need to have
if (path[n] != '/')
return path;
before this strncmp() for it to work, don't you?
In addition, by comparing (len - 1) excluding the trailing slash of
prefix, I think you would let
path = /a/bcye
slip through as well. That is inside the work_tree but outside of your
prefix.
> + fprintf(stderr,"prefix mismatch\n");
Stray debugging fprintf.
> + char *np;
> + int i;
> + int d=0;
Style "d = 0" (and "decl after statement").
> + for (i = 0; i < len; ++i)
Style. Distracts the reader by forcing him to wonder needlessly if
there is a particular reason for pre-increment of i instead of the usual
post-increment.
> + if (prefix[i] == '/')
> + d++;
> + np = xmalloc(strlen(path + n) + d * 3 + 1);
At this point (assuming that the above if (strncmp()) rejected the path
outside the prefix correctly), we know that we would need to go d levels
up to reach the top of the work tree.
> + for (i=0; i < d * 3; i += 3)
Style. "i = 0".
> + strcpy(np + i, "../");
> + strcpy(np + i, path + n + 1);
As path+n+1 is relative to the work tree, this will make it relative,
which is good.
> + path = np;
> + return np;
> + }
Assuming the if (strncmp()) above correctly handled the path outside
prefix, we are dealing with the path that is inside prefix at this
point. (len+n) is the length of the prefix directory expressed as an
absolute path.
> + if (path[len + n] == '/')
> + return path + len + n + 1;
So strip the absolute prefix would make the result relative to the
prefix directory. Nice.
> + else
> + if (path[len + n])
> + return path;
The same comment on "else if" applies. path[len+n] was not slash so
path was not inside the prefix after all. Oops? The "if outside
prefix we uplevel with ../" logic above should have handled this case
and we should not be here.
> + else
> + return path + len + n;
> +}
path[len+n] was NUL, which means taht the user named the prefix
directory, and we return "".
Isn't this _overly_ complicated? I think what this function wants to do
is:
* See if path is outside the work tree, and return absolute if so.
* Come up with the absolute path for the prefix (if NULL then that is
the same as work tree) directory, without a trailing slash, and call
it X.
* Is path the same as the X? If so, "" is what you want.
* Is path a prefix of the "X/"? If so strip "X/" and return.
* Find the longuest common leading directory of path and "X/" and call
it "C/". Note that this is guaranteed to be inside work tree because
we rejected paths outside work tree upfront.
* Count slashes between "C/" and "X/" and come up with necessary
uplevel "../". Strip "C/" from path and prepend the uplevel.
^ permalink raw reply
* Re: [PATCH] fast-export: rename the signed tag mode 'ignore' to 'verbatim'
From: Johannes Schindelin @ 2007-12-03 22:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0712032243450.27959@racer.site>
Hi,
On Mon, 3 Dec 2007, Johannes Schindelin wrote:
> The name 'verbatim' describes much better what this mode does with
> signed tags. While at it, fix the documentation what it actually
> does.
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> ---
Maybe you want to squash this, too (sorry, I sent the patch too soon,
although the mode "ignore" is still accepted, and thus, the test
succeeded):
-- snipsnap --
[PATCH] fast-export: test "verbatim", not "ignore"
The signed-tag-mode "ignore" was renamed to "verbatim", and although we
still accept "ignore" as a synonym, it is better to test "verbatim".
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
t/t9301-fast-export.sh | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/t/t9301-fast-export.sh b/t/t9301-fast-export.sh
index e9c9fe6..f09bfb1 100755
--- a/t/t9301-fast-export.sh
+++ b/t/t9301-fast-export.sh
@@ -106,9 +106,9 @@ test_expect_success 'signed-tags=abort' '
'
-test_expect_success 'signed-tags=ignore' '
+test_expect_success 'signed-tags=verbatim' '
- git fast-export --signed-tags=ignore sign-your-name > output &&
+ git fast-export --signed-tags=verbatim sign-your-name > output &&
grep PGP output
'
^ permalink raw reply related
* Re: [PATCH] Simplify crud() in ident.c
From: Luke Lu @ 2007-12-03 22:55 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Alex Riesen, git, Junio C Hamano
In-Reply-To: <m3lk8bv8du.fsf@roke.D-201>
On Dec 3, 2007, at 12:19 PM, Jakub Narebski wrote:
> Perhaps simplier, but isn't it slower?
Actually it's faster on modern cpu with deep pipelines. The following
is simple test on my macbookpro (repeated 3 times and picked lowest
one):
$ time ./crudtest 1000000000
old crud...
real 0m0.856s
user 0m0.839s
sys 0m0.011s
$ time ./crudtest 1000000000 simple
new crud...
real 0m0.431s
user 0m0.421s
sys 0m0.007s
Note: it's compiled with gcc -O2. -O3 gives the same timing; -O:
simple crud has the same timing while the old crud is 10x slower; -O0
(off): the simple code is 50% slower than old crud (note: 10x less
iterations):
$ time ./crudtest0 100000000
old crud...
real 0m0.659s
user 0m0.638s
sys 0m0.008s
$ time ./crudtest0 100000000 simple
new crud...
real 0m1.175s
user 0m1.149s
sys 0m0.014s
Since the default CFLAGS in git Makefile has -O2, the simple/new code
is faster by default.
__Luke
^ permalink raw reply
* Re: [PATCH] Allow ':/<oneline-prefix>' syntax to work with save_commit_buffer == 0
From: Johannes Schindelin @ 2007-12-03 22:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git
In-Reply-To: <7vhcizh38y.fsf@gitster.siamese.dyndns.org>
Hi,
On Mon, 3 Dec 2007, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> > ---
> >
> > On Mon, 3 Dec 2007, Jeff King wrote:
> >
> > > On Mon, Dec 03, 2007 at 10:55:15AM +0000, Johannes Schindelin wrote:
> > >
> > > > But then, my patch also works when save_commit_buffer == 0.
> > > > But I can refactor this into its own patch, since it really is
> > > > a separate issue.
> > >
> > > Agreed.
> >
> > Here we go.
>
> The log message is a bit lacking. I would have expected "git-show
> command can take ':/prefix' as an argument to name a commit whose
> subject begins with the prefix, but git-foobar command didn't and
> instead errored out. This fixes it so that ':/prefix' syntax can be
> used for any command that wants to take a commit object name".
Sorry. Can I ask you to amend the commit message with this?
-- snip --
Earlier, ':/<oneline-prefix>' would not work (i.e. die) with commands that
set save_commit_buffer = 0, such as blame, describe, pack-objects, reflog
and bundle.
Fix this.
-- snap --
Thanks,
Dscho
^ permalink raw reply
* Re: [PATCH] Simplify crud() in ident.c
From: David Kastrup @ 2007-12-03 22:52 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Alex Riesen, git, Junio C Hamano
In-Reply-To: <Pine.LNX.4.64.0712032247140.27959@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Mon, 3 Dec 2007, Alex Riesen wrote:
>
>> Johannes Schindelin, Mon, Dec 03, 2007 21:47:09 +0100:
>> > On Mon, 3 Dec 2007, Alex Riesen wrote:
>> > > + return c <= 32 ||
>> > > + c == '.' ||
>> > > + c == ',' ||
>> > > + c == ':' ||
>> > > + c == ';' ||
>> > > + c == '<' ||
>> > > + c == '>' ||
>> > > + c == '"' ||
>> > > + c == '\'';
>> >
>> > Or enhance ctype.c.
>> >
>>
>> That's be nice, but the "crud" conflicts with existing classification,
>> so I'd have to change the is*-macros as well. Don't feel like it.
>>
>> I believe the code is never in hotpath anyway so the shorter the
>> better.
>
> Really?
>
> return !!strchr(".,:;<>\"\\", c);
What happened to c <= 32?
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: [PATCH] Simplify crud() in ident.c
From: Johannes Schindelin @ 2007-12-03 22:48 UTC (permalink / raw)
To: Alex Riesen; +Cc: git, Junio C Hamano
In-Reply-To: <20071203213702.GD17671@steel.home>
Hi,
On Mon, 3 Dec 2007, Alex Riesen wrote:
> Johannes Schindelin, Mon, Dec 03, 2007 21:47:09 +0100:
> > On Mon, 3 Dec 2007, Alex Riesen wrote:
> > > + return c <= 32 ||
> > > + c == '.' ||
> > > + c == ',' ||
> > > + c == ':' ||
> > > + c == ';' ||
> > > + c == '<' ||
> > > + c == '>' ||
> > > + c == '"' ||
> > > + c == '\'';
> >
> > Or enhance ctype.c.
> >
>
> That's be nice, but the "crud" conflicts with existing classification,
> so I'd have to change the is*-macros as well. Don't feel like it.
>
> I believe the code is never in hotpath anyway so the shorter the
> better.
Really?
return !!strchr(".,:;<>\"\\", c);
Ciao,
Dscho
^ permalink raw reply
* [PATCH] fast-export: rename the signed tag mode 'ignore' to 'verbatim'
From: Johannes Schindelin @ 2007-12-03 22:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwsrvh4vx.fsf@gitster.siamese.dyndns.org>
The name 'verbatim' describes much better what this mode does with
signed tags. While at it, fix the documentation what it actually
does.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
On Mon, 3 Dec 2007, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > But the original author already admitted that the original
> > naming was stupid...
>
> Ok, send in updates, please.
Alright...
Documentation/git-fast-export.txt | 4 ++--
builtin-fast-export.c | 8 ++++----
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/Documentation/git-fast-export.txt b/Documentation/git-fast-export.txt
index 073ff7f..fd3d571 100644
--- a/Documentation/git-fast-export.txt
+++ b/Documentation/git-fast-export.txt
@@ -26,14 +26,14 @@ OPTIONS
Insert 'progress' statements every <n> objects, to be shown by
gitlink:git-fast-import[1] during import.
---signed-tags=(ignore|warn|strip|abort)::
+--signed-tags=(verbatim|warn|strip|abort)::
Specify how to handle signed tags. Since any transformation
after the export can change the tag names (which can also happen
when excluding revisions) the signatures will not match.
+
When asking to 'abort' (which is the default), this program will die
when encountering a signed tag. With 'strip', the tags will be made
-unsigned, with 'ignore', they will be silently ignored (i.e. not exported)
+unsigned, with 'verbatim', they will be silently exported
and with 'warn', they will be exported, but you will see a warning.
diff --git a/builtin-fast-export.c b/builtin-fast-export.c
index 72be45d..2136aad 100755
--- a/builtin-fast-export.c
+++ b/builtin-fast-export.c
@@ -23,15 +23,15 @@ static const char *fast_export_usage[] = {
};
static int progress;
-static enum { IGNORE, WARN, STRIP, ABORT } signed_tag_mode = ABORT;
+static enum { VERBATIM, WARN, STRIP, ABORT } signed_tag_mode = ABORT;
static int parse_opt_signed_tag_mode(const struct option *opt,
const char *arg, int unset)
{
if (unset || !strcmp(arg, "abort"))
signed_tag_mode = ABORT;
- else if (!strcmp(arg, "ignore"))
- signed_tag_mode = IGNORE;
+ else if (!strcmp(arg, "verbatim") || !strcmp(arg, "ignore"))
+ signed_tag_mode = VERBATIM;
else if (!strcmp(arg, "warn"))
signed_tag_mode = WARN;
else if (!strcmp(arg, "strip"))
@@ -270,7 +270,7 @@ static void handle_tag(const char *name, struct tag *tag)
warning ("Exporting signed tag %s",
sha1_to_hex(tag->object.sha1));
/* fallthru */
- case IGNORE:
+ case VERBATIM:
break;
case STRIP:
message_size = signature + 1 - message;
--
1.5.3.7.2120.g1a32
^ permalink raw reply related
* Re: Fix UTF Encoding issue
From: Ismail Dönmez @ 2007-12-03 22:20 UTC (permalink / raw)
To: Benjamin Close
Cc: Jakub Narebski, Martin Koegler, Junio C Hamano,
Alexandre Julliard, git, Perl Unicode Mailing List, Dan Kogai
In-Reply-To: <47547930.5070603@clearchain.com>
[-- Attachment #1: Type: text/plain, Size: 1392 bytes --]
Monday 03 December 2007 Tarihinde 23:46:24 yazmıştı:
> Jakub Narebski wrote:
> > On Mon, 3 Dec 2007, Martin Koegler wrote:
> >> On Mon, Dec 03, 2007 at 04:06:48AM -0800, Jakub Narebski wrote:
> >>> Ismail Dönmez <ismail@pardus.org.tr> writes:
> >>>> Monday 03 December 2007 Tarihinde 12:14:43 yazm??t?:
> >>>>> Benjamin Close <Benjamin.Close@clearchain.com> writes:
> >>>>>> - eval { $res = decode_utf8($str, Encode::FB_CROAK); };
> >>>>>> - if (defined $res) {
> >>>>>> - return $res;
> >>>>>> - } else {
> >>>>>> - return decode($fallback_encoding, $str, Encode::FB_DEFAULT);
> >>>>>> - }
> >>>>>> + eval { return ($res = decode_utf8($str, Encode::FB_CROAK)); };
> >>>>>> + return decode($fallback_encoding, $str, Encode::FB_DEFAULT);
> >>>>>> }
> >>
> >> This version is broken on Debian sarge and etch. Feeding a UTF-8 and a
> >> latin1 encoding of the same character sequence yields to different
> >> results.
>
> For the record, this was on a debian sid machine.
>
> #perl --version
> This is perl, v5.8.8 built for x86_64-linux-gnu-thread-multi
>
> and the result of not using the original patch was:
>
> <h1>Software error:</h1>
> <pre>Cannot decode string with wide characters at
> /usr/lib/perl/5.8/Encode.pm line 166. </pre>
Can you try the attached patch?
--
Never learn by your mistakes, if you do you may never dare to try again.
[-- Attachment #2: utf8-username.patch --]
[-- Type: text/x-diff, Size: 313 bytes --]
--- gitweb/gitweb.perl 2007-11-28 11:33:14.000000000 +0200
+++ gitweb/gitweb.perl 2007-11-28 11:33:42.000000000 +0200
@@ -2159,7 +2159,7 @@
}
my $owner = $gcos;
$owner =~ s/[,;].*$//;
- return to_utf8($owner);
+ return $owner;
}
## ......................................................................
^ permalink raw reply
* Re: [PATCH] Allow HTTP proxy to be overridden in config
From: Sam Vilain @ 2007-12-03 21:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, francois
In-Reply-To: <7vhcj387jh.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> In that sense, I think http.proxy configuration variable does not go far
> enough, even though it might be a step in the right direction. Perhaps
> use your configuration variable http.proxy (or "core.environment") to
> define the global default, with remote.$name.httpproxy to override it?
Sure, why not.
Subject: [PATCH] Add remote.<name>.proxy
As well as allowing a default proxy option, allow it to be set
per-remote.
Signed-off-by: Sam Vilain <sam.vilain@catalyst.net.nz>
---
Documentation/config.txt | 8 +++++++-
remote.c | 2 ++
remote.h | 5 +++++
transport.c | 3 +++
4 files changed, 17 insertions(+), 1 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 7e6c02a..831df58 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -545,7 +545,8 @@ access method.
http.proxy::
Override the HTTP proxy, normally configured using the 'http_proxy'
- environment variable (see gitlink:curl[1]).
+ environment variable (see gitlink:curl[1]). This can be overridden
+ on a per-remote basis; see remote.<name>.proxy
http.sslVerify::
Whether to verify the SSL certificate when fetching or pushing
@@ -695,6 +696,11 @@ remote.<name>.url::
The URL of a remote repository. See gitlink:git-fetch[1] or
gitlink:git-push[1].
+remote.<name>.proxy::
+ For remotes that require curl (http, https and ftp), the URL to
+ the proxy to use for that remote. Set to the empty string to
+ disable proxying for that remote.
+
remote.<name>.fetch::
The default set of "refspec" for gitlink:git-fetch[1]. See
gitlink:git-fetch[1].
diff --git a/remote.c b/remote.c
index bec2ba1..94df314 100644
--- a/remote.c
+++ b/remote.c
@@ -278,6 +278,8 @@ static int handle_config(const char *key, const char *value)
} else if (!strcmp(subkey, ".tagopt")) {
if (!strcmp(value, "--no-tags"))
remote->fetch_tags = -1;
+ } else if (!strcmp(subkey, ".proxy")) {
+ remote->fetch_refspec = xstrdup(value);
}
return 0;
}
diff --git a/remote.h b/remote.h
index 878b4ec..2268558 100644
--- a/remote.h
+++ b/remote.h
@@ -25,6 +25,11 @@ struct remote {
const char *receivepack;
const char *uploadpack;
+
+ /*
+ * for curl remotes only
+ */
+ const char *proxy;
};
struct remote *remote_get(const char *name);
diff --git a/transport.c b/transport.c
index 43b9e7c..c62ec88 100644
--- a/transport.c
+++ b/transport.c
@@ -463,6 +463,9 @@ static struct ref *get_refs_via_curl(const struct transport *transport)
curl_easy_setopt(slot->curl, CURLOPT_WRITEFUNCTION, fwrite_buffer);
curl_easy_setopt(slot->curl, CURLOPT_URL, refs_url);
curl_easy_setopt(slot->curl, CURLOPT_HTTPHEADER, NULL);
+ if (transport->remote->proxy) {
+ curl_easy_setopt(slot->curl, CURLOPT_PROXY, transport->remote->proxy);
+ }
if (start_active_slot(slot)) {
run_active_slot(slot);
if (results.curl_result != CURLE_OK) {
--
1.5.3.5
^ permalink raw reply related
* Re: [PATCH] xdiff-interface.c (buffer_is_binary): Remove buffer size limitation
From: Dmitry V. Levin @ 2007-12-03 21:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vlk8e42qb.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1.1: Type: text/plain, Size: 986 bytes --]
On Sat, Dec 01, 2007 at 11:46:52AM -0800, Junio C Hamano wrote:
> On Sat, Dec 01, 2007 at 07:01:13PM +0300, Dmitry V. Levin wrote:
>
> > When checking buffer for NUL byte, do not limit size of buffer we check.
> > Otherwise we break git-rebase: git-format-patch may generate output which
> > git-mailinfo cannot handle properly.
>
> I think this is tackling a valid problem but it is a wrong solution.
> The change penalizes text changes which is the majority, just in case
> there is an unusual change that has an embedded NUL far into the file
> (iow, exception).
Penalizes?
Average file size in the linux-2.6.23.9 kernel tree is 10944 bytes,
FIRST_FEW_BYTES limit is 8000 bytes.
Well, I prefer slightly penalized but working properly git-rebase.
Attached test case demonstrates how current git-rebase can just run
successfully but produce a wrong result.
P.S. The real life example where you can hit this git-rebase problem is
GNU .info files.
--
ldv
[-- Attachment #1.2: t3408-rebase-binary-correctness.sh --]
[-- Type: application/x-sh, Size: 506 bytes --]
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Fix UTF Encoding issue
From: Benjamin Close @ 2007-12-03 21:46 UTC (permalink / raw)
To: Jakub Narebski
Cc: Martin Koegler, Ismail Dönmez, Junio C Hamano,
Alexandre Julliard, git, Perl Unicode Mailing List, Dan Kogai
In-Reply-To: <200712031802.55514.jnareb@gmail.com>
Jakub Narebski wrote:
> On Mon, 3 Dec 2007, Martin Koegler wrote:
>
>> On Mon, Dec 03, 2007 at 04:06:48AM -0800, Jakub Narebski wrote:
>>
>>> Ismail Dönmez <ismail@pardus.org.tr> writes:
>>>
>>>> Monday 03 December 2007 Tarihinde 12:14:43 yazm??t?:
>>>>
>>>>> Benjamin Close <Benjamin.Close@clearchain.com> writes:
>>>>>
>>>>>> - eval { $res = decode_utf8($str, Encode::FB_CROAK); };
>>>>>> - if (defined $res) {
>>>>>> - return $res;
>>>>>> - } else {
>>>>>> - return decode($fallback_encoding, $str, Encode::FB_DEFAULT);
>>>>>> - }
>>>>>> + eval { return ($res = decode_utf8($str, Encode::FB_CROAK)); };
>>>>>> + return decode($fallback_encoding, $str, Encode::FB_DEFAULT);
>>>>>> }
>>>>>>
>> This version is broken on Debian sarge and etch. Feeding a UTF-8 and a latin1
>> encoding of the same character sequence yields to different results.
>>
>
>
For the record, this was on a debian sid machine.
#perl --version
This is perl, v5.8.8 built for x86_64-linux-gnu-thread-multi
and the result of not using the original patch was:
<h1>Software error:</h1>
<pre>Cannot decode string with wide characters at /usr/lib/perl/5.8/Encode.pm line 166.
</pre>
I haven't tried the other solutions tested here.
>> eval { $res = decode_utf8(...); }
>> if ($@)
>> return decode(...);
>> return $res
>>
>> or
>>
>> eval { $res = decode_utf8(...); }
>> if (defined $res)
>> return $res;
>> else
>> return decode(...);
>>
>> show the same (wrong) behaviour on Debian sarge. They do not always
>> decode non UTF-8 characters correctly, eg.
>> #öäü does not work
>> #äöüä does work
>>
>> On Debian etch, both versions are working.
>>
>
> I don't know enough Perl to decide if it is a bug in gitweb usage
> of decode_utf8, if it is a bug in your version of Encode, or if it
> is bug in Encode.
>
> Send copy of this mail to maintainers of Encode perl module.
>
Ismail do you know if sid was also broken?
^ 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