* [PATCH] Fix quote_path when called with negative length.
From: Pierre Habouzit @ 2007-12-03 9:06 UTC (permalink / raw)
To: David Symonds; +Cc: Junio C Hamano, git
In-Reply-To: <ee77f5c20712021539r3075fc57ld6a4cec737e6043d@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3238 bytes --]
When the len passed was -1, relative paths shortening was broken, resulting
in too long paths.
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
---
On Sun, Dec 02, 2007 at 11:39:59PM +0000, David Symonds wrote:
> On Dec 3, 2007 9:04 AM, Junio C Hamano <gitster@pobox.com> wrote:
> > Please do not take this as the final decision made by the Emperor, whose
> > subjects now must follow. This is a sanity-check to see if everybody is
> > on the same page.
> >
> > I am not the Emperor anyway ;-)
> >
>
> > Topics not in 'master' yet but should be in v1.5.4
> > --------------------------------------------------
> >
> > I think the following should go in, along with what we already have in
> > 'master':
>
> Can we add the git-status/git-checkout relative path stuff that's
> currently been sitting in 'next'? It would be a good step forward for
> usability.
Speaking of which, there is this irritating bug in git status that
let it show too long paths in the first chunk (the "tracked files"
one).
The previous version of the function was avoiding very hard to
compute "in" length, and had quite convoluted code because of that.
I now compute it at the beginning. The real issue was the:
while (prefix[off] && off < len && prefix[off] == in[off])
line, when len is negative, the shortening never happens. I could
have fixed it using ((len < 0 && in[off]) || off < len), but I
disliked the resulting code, so I went for this.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
wt-status.c | 31 +++++++++++++------------------
1 files changed, 13 insertions(+), 18 deletions(-)
diff --git a/wt-status.c b/wt-status.c
index 0e0439f..eb2cbea 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -84,30 +84,25 @@ static void wt_status_print_trailer(struct wt_status *s)
static char *quote_path(const char *in, int len,
struct strbuf *out, const char *prefix)
{
- if (len > 0)
- strbuf_grow(out, len);
+ int pos = 0;
+
+ if (len < 0)
+ len = strlen(in);
+ strbuf_grow(out, len);
strbuf_setlen(out, 0);
if (prefix) {
int off = 0;
while (prefix[off] && off < len && prefix[off] == in[off])
- if (prefix[off] == '/') {
- prefix += off + 1;
- in += off + 1;
- len -= off + 1;
- off = 0;
- } else
- off++;
-
- for (; *prefix; prefix++)
- if (*prefix == '/')
+ if (prefix[off++] == '/')
+ pos = off;
+ while (prefix[off])
+ if (prefix[off++] == '/')
strbuf_addstr(out, "../");
}
- for (; (len < 0 && *in) || len > 0; in++, len--) {
- int ch = *in;
-
- switch (ch) {
+ for (; pos < len; pos++) {
+ switch (in[pos]) {
case '\n':
strbuf_addstr(out, "\\n");
break;
@@ -115,8 +110,8 @@ static char *quote_path(const char *in, int len,
strbuf_addstr(out, "\\r");
break;
default:
- strbuf_addch(out, ch);
- continue;
+ strbuf_addch(out, in[pos]);
+ break;
}
}
--
1.5.3.7.2065.g3d18-dirty
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply related
* Re: [PATCH] Allow HTTP proxy to be overridden in config
From: Andreas Ericsson @ 2007-12-03 9:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Sam Vilain, git, francois
In-Reply-To: <7vhcj387jh.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
>
> [Footnote]
>
> *1* git(7) calls "git" itself as "git potty". Is this word still used?
> I also notice that Andreas's name is misspelled there.
AFAIR I sort of invented that to disambiguate git-the-program from
git-the-project while working on writing the program in C. I haven't
heard/seen it a lot since then, except on a few occasions where it
helped serve that same purpose.
I also misspelled my own name in that patch. Perhaps it's time I
corrected that.
---%<---%<---%<---
From: Andreas Ericsson <ae@op5.se>
Subject: [PATCH] Correct typo in Documentation/git.txt
Signed-off-by: Andreas Ericsson <ae@op5.se>
---
diff --git a/Documentation/git.txt b/Documentation/git.txt
index 9ff4659..6c98ab2 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -536,7 +536,7 @@ Authors
-------
* git's founding father is Linus Torvalds <torvalds@osdl.org>.
* The current git nurse is Junio C Hamano <gitster@pobox.com>.
-* The git potty was written by Andres Ericsson <ae@op5.se>.
+* The git potty was written by Andreas Ericsson <ae@op5.se>.
* General upbringing is handled by the git-list <git@vger.kernel.org>.
Documentation
---%<---%<---%<---
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply related
* Re: Pack several linear commits into one
From: Peter Baumann @ 2007-12-03 9:28 UTC (permalink / raw)
To: Jacob Kroon; +Cc: git
In-Reply-To: <c0d4c9e90712030106u40b871ecjd5f7b8d078c8be36@mail.gmail.com>
On Mon, Dec 03, 2007 at 10:06:11AM +0100, Jacob Kroon wrote:
> Hi,
>
> Is there a tool for repacking several linear commits into one single ?
>
> Please CC me since I'm not a subscriber to the list.
>
Look for git merge --squash or git cherry-pick --no-commit
-Peter
^ permalink raw reply
* Re: Pack several linear commits into one
From: Jakub Narebski @ 2007-12-03 9:32 UTC (permalink / raw)
To: Jacob Kroon; +Cc: git
In-Reply-To: <c0d4c9e90712030106u40b871ecjd5f7b8d078c8be36@mail.gmail.com>
"Jacob Kroon" <jacob.kroon@gmail.com> writes:
> Is there a tool for repacking several linear commits into one single ?
You can use either "git rebase --interactive" and replace 'pick' with
'squash', or (simpler for replacing all the commits by one big commit)
"git merge --squash". See documentation for details.
Note that if you want remove those 'several linear commits', you
better not have them published yet.
> Please CC me since I'm not a subscriber to the list.
You can read this list via archives, or using NNTP interface (in news
reader):
nntp://news.gmane.org/gmane.comp.version-control.git
--
Jakub Narebski
ShadeHawk on #git
Poland
^ permalink raw reply
* Re: What's in git-gui.git
From: Miklos Vajna @ 2007-12-03 9:42 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Junio C Hamano
In-Reply-To: <20071203041010.GT14735@spearce.org>
[-- Attachment #1: Type: text/plain, Size: 633 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.
>
> gitweb: http://repo.or.cz/w/git-gui.git
> clone: git://repo.or.cz/git-gui.git
> http://repo.or.cz/r/git-gui.git
the README says that one should push translation updates to the mob
branch of git-gui-i18n.git, but if i'm not wrong de.po is newer in
gui-gui.git than the one in git-gui-i18n.git. have i missed something or
the README is just a bit outdated?
thanks,
- VMiklos
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Many things pushed out to 'master'
From: Junio C Hamano @ 2007-12-03 10:00 UTC (permalink / raw)
To: git
In-Reply-To: <7vabosse23.fsf@gitster.siamese.dyndns.org>
I've merged a handful topics that have been cooking in 'next' to
'master'. Except for a few big topics still in 'next', this brings the
tip of 'master' much closer to what will become 1.5.4.
As always has been promised, the tip of 'master' is designed to be more
stable than any released version without introducing regression, and we
need to test how true that is from time to time ;-).
Please keep the fixes flowing. The next batch will be "commit in C" and
"add --patch" series.
^ permalink raw reply
* Fix UTF Encoding issue
From: Benjamin Close @ 2007-12-03 10:02 UTC (permalink / raw)
To: git
>From 83042abf3967b455953cddeab43e33c1d59c6f03 Mon Sep 17 00:00:00 2001
From: Benjamin Close <Benjamin.Close@clearchain.com>
Date: Sun, 2 Dec 2007 15:09:00 -0800
Subject: [PATCH] Gitweb: Fix encoding to always translate rather than
sometimes fail
When performing the utf translation don't test if $res is defined.
It appears that it is defined even when the conversion fails. This causes
failures on the writing of the output stream which is expecting UTF.
Instead, immediately return if conversion is successful else force
the translation to the fallback encoding
---
gitweb/gitweb.perl | 8 ++------
1 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 491a3f4..00bbcdf 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -696,12 +696,8 @@ sub validate_refname {
sub to_utf8 {
my $str = shift;
my $res;
- 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);
}
# quote unsafe chars, but keep the slash, even when it's not
--
1.5.3.6
^ permalink raw reply related
* Re: [PATCH] Make git status usage say git status instead of git commit
From: David Kastrup @ 2007-12-03 10:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn Bohrer, git
In-Reply-To: <7vir3gqr3d.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Shawn Bohrer <shawn.bohrer@gmail.com> writes:
>
>> As a side question, should the usage information also use the non
>> dash notation of the command since it is deprecated? I noticed all
>> of the other commands are presently using the dash form, so I left it
>> as is for now.
>
> Wise choice. We would probably want to clean them up at the same time
> early post 1.5.4.
Deprecating the dash form will probably mean that we need to think up
(and document) a rationale for
man git-commit
I actually have typed something like
man git commit
a number of times already with obvious results. Finger memory.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: Fix UTF Encoding issue
From: Junio C Hamano @ 2007-12-03 10:14 UTC (permalink / raw)
To: Benjamin Close; +Cc: git
In-Reply-To: <4753D419.80503@clearchain.com>
Benjamin Close <Benjamin.Close@clearchain.com> writes:
>>From 83042abf3967b455953cddeab43e33c1d59c6f03 Mon Sep 17 00:00:00 2001
> From: Benjamin Close <Benjamin.Close@clearchain.com>
> Date: Sun, 2 Dec 2007 15:09:00 -0800
> Subject: [PATCH] Gitweb: Fix encoding to always translate rather than
> sometimes fail
>
> When performing the utf translation don't test if $res is defined.
> It appears that it is defined even when the conversion fails. This causes
> failures on the writing of the output stream which is expecting UTF.
> @@ -696,12 +696,8 @@ sub validate_refname {
> sub to_utf8 {
> my $str = shift;
> my $res;
> - 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 is funny.
I thought the standard catch ... throw idiom in Perl was to do the above
like this:
my $res;
eval { $res = decode_utf8($str, Encode::FB_CROAK); };
if ($@) {
return decode($fallback_encoding, $str, Encode::FB_DEFAULT);
}
return $res;
(alternatively, you can assign return value of eval {} to $res).
^ permalink raw reply
* Re: [PATCH] Make git status usage say git status instead of git commit
From: Miklos Vajna @ 2007-12-03 10:21 UTC (permalink / raw)
To: David Kastrup; +Cc: Junio C Hamano, Shawn Bohrer, git
In-Reply-To: <854pf0hyy3.fsf@lola.goethe.zz>
[-- Attachment #1: Type: text/plain, Size: 402 bytes --]
On Mon, Dec 03, 2007 at 11:09:24AM +0100, David Kastrup <dak@gnu.org> wrote:
> Deprecating the dash form will probably mean that we need to think up
> (and document) a rationale for
>
> man git-commit
>
> I actually have typed something like
>
> man git commit
>
> a number of times already with obvious results. Finger memory.
that's why we have git help commit :)
- VMiklos
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] git-stash: Display help message if git-stash is run with wrong sub-commands
From: Johannes Schindelin @ 2007-12-03 10:25 UTC (permalink / raw)
To: Wayne Davison; +Cc: Kevin Leung, Git ML
In-Reply-To: <20071203061617.GB1976@blorf.net>
Hi,
On Sun, 2 Dec 2007, Wayne Davison wrote:
> On Mon, Dec 03, 2007 at 10:34:05AM +0800, Kevin Leung wrote:
> > +USAGE='[ | save | list | show | apply | clear ]'
>
> It seems strange to me that git stash is using sub-sub-command words
> instead of options. Would it make more sense to be more like git branch
> and have a list be indicated by -l, etc.?
But those are not really options, are they? They are commands, which
exclude each other. And even if they are sub-sub-commands, why should we
not rather fix "git branch" to support a sane syntax, too?
We could even put some general support into parse-options.[ch] for
sub-commands.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Reorder msgfmt command-line arguments.
From: Johannes Schindelin @ 2007-12-03 10:35 UTC (permalink / raw)
To: brian m. carlson; +Cc: git
In-Reply-To: <20071203012631.GA22450@crustytoothpaste.ath.cx>
Hi,
On Mon, 3 Dec 2007, brian m. carlson wrote:
> Any program using getopt or getopt_long will stop processing options
> once a non-option argument has been encountered, if POSIXLY_CORRECT is
> set.
So have you tested that msgfmt indeed does not work with the present
command line?
Besides, you probably want to send this as a git-gui patch: based on
git-gui.git, not git.git, and Cc'ed to Shawn Pearce.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Make git status usage say git status instead of git commit
From: Florian Weimer @ 2007-12-03 10:15 UTC (permalink / raw)
To: git
In-Reply-To: <854pf0hyy3.fsf@lola.goethe.zz>
* David Kastrup:
> Deprecating the dash form will probably mean that we need to think up
> (and document) a rationale for
>
> man git-commit
>
> I actually have typed something like
>
> man git commit
>
> a number of times already with obvious results. Finger memory.
It's also a bit strange to have a git-commit(1) manpage when there is no
git-commit on the path.
^ permalink raw reply
* Re: [PATCH] Do check_repository_format() early
From: Johannes Schindelin @ 2007-12-03 10:44 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Junio C Hamano, git
In-Reply-To: <fcaeb9bf0712022003w4a3df0f0j21a5b23f3f073597@mail.gmail.com>
Hi,
On Mon, 3 Dec 2007, Nguyen Thai Ngoc Duy wrote:
> The patch's behaviour is barf if the repository version is too new.
> The list of files that use setup_git_directory_gently is not long. I
> am going to have a look over the files before amending the patch again
> to make it only barf if nongit_ok is NULL.
In the interest of least surprise, _gently() should not ignore a too new
repository format. It is also keeping the semantics simpler, which is
good for users like me.
So I'd test it with "git apply", just because it is the first on the list.
Something like
-- snip --
cat > patch << EOF
diff a/empty-file b/empty-file
--- a/empty-file
+++ b/empty-file
@@ -0,0 +1,1 @@
+narf
EOF
test_expect_success '_gently() respects repositoryversion' '
mkdir way_too_new &&
(cd way_too_new &&
git init &&
git config core.repositoryFormatVersion 999999 &&
: > empty-file &&
! git apply < ../patch 2> error.out &&
grep "git repo version" error.out &&
! test -s empty-file
'
-- snap --
Hmm?
Ciao,
Dscho
^ permalink raw reply
* committing only selected diff's of a file
From: Erik Colson @ 2007-12-03 10:03 UTC (permalink / raw)
To: git
Hello,
Does Git allow to commit only selected patches from inside 1 file ?
I'm coming from a darcs world where this is supported...
Probably it is supported in Git too, but I can't figure out how :-/
Thanks for help
--
Erik
^ permalink raw reply
* Re: [PATCH/RFC] Use regex for :/ matching
From: Johannes Schindelin @ 2007-12-03 10:55 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20071203043258.GA16658@coredump.intra.peff.net>
Hi,
On Sun, 2 Dec 2007, Jeff King wrote:
> The sha1 syntax :/ used to be a strict prefix match.
> Instead, let's use a regular expression, which can save on
> typing. E.g.,
>
> git show :/"object name: introduce ':/<oneline prefix>'"
>
> vs
>
> git show :/introduce..:/.oneline
Heh:
http://repo.or.cz/w/git/dscho.git?a=commitdiff;h=2546cd9732bb8d4bc1d2485ba7bbc1d5c8bac935
Except that I did not support ".." (does yours?), _and_ that my patch is
not as nice as yours.
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.
Ciao,
Dscho
^ permalink raw reply
* Re: committing only selected diff's of a file
From: Miklos Vajna @ 2007-12-03 11:07 UTC (permalink / raw)
To: Erik Colson; +Cc: git
In-Reply-To: <4753D465.10802@ecocode.net>
[-- Attachment #1: Type: text/plain, Size: 525 bytes --]
On Mon, Dec 03, 2007 at 11:03:17AM +0100, Erik Colson <eco@ecocode.net>
wrote:
> Does Git allow to commit only selected patches from inside 1 file ?
> I'm coming from a darcs world where this is supported...
> Probably it is supported in Git too, but I can't figure out how :-/
git add -i
(i also wrote a wrapper for people who come from darcs:
http://git.frugalware.org/repos/pacman-tools/darcs-git.py
but it contains many hacks so i don't want to advertise it too much as
others on this list will burn me :) )
- VMiklos
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: committing only selected diff's of a file
From: Jakub Narebski @ 2007-12-03 11:09 UTC (permalink / raw)
To: Erik Colson; +Cc: git
In-Reply-To: <4753D465.10802@ecocode.net>
Erik Colson <eco@ecocode.net> writes:
> Does Git allow to commit only selected patches from inside 1 file ?
> I'm coming from a darcs world where this is supported...
> Probably it is supported in Git too, but I can't figure out how :-/
Use "git add --interactive" or "git gui" (the latter requires Tcl/Tk).
--
Jakub Narebski
^ permalink raw reply
* Re: Many things pushed out to 'master'
From: Johannes Schindelin @ 2007-12-03 11:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vbq98jdy5.fsf_-_@gitster.siamese.dyndns.org>
Hi,
On Mon, 3 Dec 2007, Junio C Hamano wrote:
> I've merged a handful topics that have been cooking in 'next' to
> 'master'. Except for a few big topics still in 'next', this brings the
> tip of 'master' much closer to what will become 1.5.4.
I usually run off next + patches, so I do not know if fast-export already
made it to "master".
But I remembered that you requested a mode for signed tags where they
would just be copied. I just realised while implementing "verbatim" that
"ignore" does just that. Maybe we should rename this mode to "verbatim"?
And maybe you want to make it the default (even if I think that this will
result in more surprise moments than the current mode which aborts).
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Allow HTTP proxy to be overridden in config
From: Johannes Schindelin @ 2007-12-03 11:13 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Junio C Hamano, Sam Vilain, git, francois
In-Reply-To: <4753C7AD.3000406@op5.se>
Hi,
On Mon, 3 Dec 2007, Andreas Ericsson wrote:
> Junio C Hamano wrote:
> >
> > [Footnote]
> >
> > *1* git(7) calls "git" itself as "git potty". Is this word still used?
> > I also notice that Andreas's name is misspelled there.
>
>
> AFAIR I sort of invented that to disambiguate git-the-program from
> git-the-project while working on writing the program in C. I haven't
> heard/seen it a lot since then, except on a few occasions where it
> helped serve that same purpose.
I always spell it "git wrapper".
Ciao,
Dscho
^ permalink raw reply
* [PATCH] git-archimport: Don't include the first line of the tla log message if it's the same as the summary.
From: Russell @ 2007-12-03 11:23 UTC (permalink / raw)
To: git
I have a few gnu arch (tla) archives that I've been converting to git
repositories. In many of the revisions in those archives, I have used
the ``-L msg'' flag to tla to specify the log message on the command
line. This results in the summary field of the revision being
duplicated in the first line of the log message. When I then use
git-archimport to make a git repo with the tla history, this line
appears twice in the git log message, which is ugly.
This patch drops the first line of the log message if it is identical
to the summary field.
---
git-archimport.perl | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/git-archimport.perl b/git-archimport.perl
index 9a7a906..cdf7a11 100755
--- a/git-archimport.perl
+++ b/git-archimport.perl
@@ -833,6 +833,10 @@ sub parselog {
}
}
+ # Drop the first line of the log if it's the same as the summary.
+ if ($ps->{summary}->[0] eq $log->[0]) {
+ shift @$log;
+ }
# drop leading empty lines from the log message
while (@$log && $log->[0] eq '') {
shift @$log;
--
1.5.3.7.966.g1c46-dirty
--
Virus found in this message.
^ permalink raw reply related
* Re: Fix UTF Encoding issue
From: Ismail Dönmez @ 2007-12-03 11:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Benjamin Close, git
In-Reply-To: <7v7ijwjd9o.fsf@gitster.siamese.dyndns.org>
Monday 03 December 2007 Tarihinde 12:14:43 yazmıştı:
> Benjamin Close <Benjamin.Close@clearchain.com> writes:
> >>From 83042abf3967b455953cddeab43e33c1d59c6f03 Mon Sep 17 00:00:00 2001
> >
> > From: Benjamin Close <Benjamin.Close@clearchain.com>
> > Date: Sun, 2 Dec 2007 15:09:00 -0800
> > Subject: [PATCH] Gitweb: Fix encoding to always translate rather than
> > sometimes fail
> >
> > When performing the utf translation don't test if $res is defined.
> > It appears that it is defined even when the conversion fails. This causes
> > failures on the writing of the output stream which is expecting UTF.
> > @@ -696,12 +696,8 @@ sub validate_refname {
> > sub to_utf8 {
> > my $str = shift;
> > my $res;
> > - 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 is funny.
>
> I thought the standard catch ... throw idiom in Perl was to do the above
> like this:
>
> my $res;
> eval { $res = decode_utf8($str, Encode::FB_CROAK); };
> if ($@) {
> return decode($fallback_encoding, $str, Encode::FB_DEFAULT);
> }
> return $res;
I think this is correct, but the current code in gitweb doesn't look correct
since it checks for $res and not $@.
Regards,
ismail
--
Never learn by your mistakes, if you do you may never dare to try again.
^ permalink raw reply
* Re: [PATCH v4] Allow update hooks to update refs on their own.
From: Johannes Schindelin @ 2007-12-03 11:47 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Steven Grimm, git, Junio C Hamano
In-Reply-To: <20071203040108.GS14735@spearce.org>
Hi,
On Sun, 2 Dec 2007, Shawn O. Pearce wrote:
> Steven Grimm <koreth@midwinter.com> wrote:
> > This is useful in cases where a hook needs to modify an incoming commit
> > in some way, e.g., fixing whitespace errors, adding an annotation to
> > the commit message, noting the location of output from a profiling tool,
> > or committing to an svn repository using git-svn.
> ...
> > +/* Update hook exit code: hook has updated ref on its own */
> > +#define EXIT_CODE_REF_UPDATED 100
>
> Hmm. I would actually rather move the ref locking to before we run
> the update hook, so the ref is locked *while* the hook executes.
Would that not mean that you cannot use update-ref to update the ref,
since that wants to use the same lock?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Make git status usage say git status instead of git commit
From: Eyvind Bernhardsen @ 2007-12-03 12:04 UTC (permalink / raw)
To: Florian Weimer; +Cc: git
In-Reply-To: <877ijww0d3.fsf@mid.deneb.enyo.de>
On 3. des. 2007, at 11.15, Florian Weimer wrote:
> * David Kastrup:
>
>> Deprecating the dash form will probably mean that we need to think up
>> (and document) a rationale for
>>
>> man git-commit
>>
>> I actually have typed something like
>>
>> man git commit
>>
>> a number of times already with obvious results. Finger memory.
>
> It's also a bit strange to have a git-commit(1) manpage when there
> is no
> git-commit on the path.
No stranger than having a perlfunc(1) manpage. bash-builtins is in
section 7, maybe git-* should be moved there? Of course, then git
wouldn't have any manpages in section 1 at all.
Eyvind
^ permalink raw reply
* Re: Fix UTF Encoding issue
From: Jakub Narebski @ 2007-12-03 12:06 UTC (permalink / raw)
To: Ismail Dönmez
Cc: Junio C Hamano, Martin Koegler, Alexandre Julliard,
Benjamin Close, git
In-Reply-To: <200712031332.36187.ismail@pardus.org.tr>
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);
>>> }
>>
>> I thought the standard catch ... throw idiom in Perl was to do the above
>> like this:
>>
>> my $res;
>> eval { $res = decode_utf8($str, Encode::FB_CROAK); };
>> if ($@) {
>> return decode($fallback_encoding, $str, Encode::FB_DEFAULT);
>> }
>> return $res;
>
> I think this is correct, but the current code in gitweb doesn't look correct
> since it checks for $res and not $@.
First version of the patch was created by Martin Koegler. I have
participated in creating the version which is now in gitweb, but I
have to say that I wrote it based on decode_utf8
documentation... which doesn't necessarily agree with facts :-(
I'm all for the "throw idion" version. Ack.
--
Jakub Narebski
^ 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