* [PATCH] [TopGit] Check for pre-commit hook existence.
From: Russell Steicke @ 2008-08-03 14:14 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20080803031424.GV32184@machine.or.cz>
Running tg in a repo without an active pre-commit hook fails
saying
grep: .git/hooks/pre-commit: No such file or directory
cat: .git/hooks/pre-commit: No such file or directory
Even "tg help" does this! So add extra checks for existence
of the pre-commit hook.
---
tg.sh | 10 ++++++----
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/tg.sh b/tg.sh
index 56c5709..15005db 100644
--- a/tg.sh
+++ b/tg.sh
@@ -21,9 +21,11 @@ die()
setup_hook()
{
hook_call="\"\$(tg --hooks-path)\"/$1 \"\$@\""
- if fgrep -q "$hook_call" "$git_dir/hooks/$1"; then
- # Another job well done!
- return
+ if [ -x "$git_dir/hooks/$1" ]; then
+ if fgrep -q "$hook_call" "$git_dir/hooks/$1"; then
+ # Another job well done!
+ return
+ fi
fi
# Prepare incanation
if [ -x "$git_dir/hooks/$1" ]; then
@@ -35,7 +37,7 @@ setup_hook()
{
echo "#!/bin/sh"
echo "$hook_call"
- cat "$git_dir/hooks/$1"
+ [ -x "$git_dir/hooks/$1" ] && cat "$git_dir/hooks/$1"
} >"$git_dir/hooks/$1+"
chmod a+x "$git_dir/hooks/$1+"
mv "$git_dir/hooks/$1+" "$git_dir/hooks/$1"
--
1.6.0.rc1
--
Russell Steicke
-- Fortune says:
I got the bill for my surgery. Now I know what those doctors were
wearing masks for.
-- James Boren
^ permalink raw reply related
* [PATCH] git-name-rev: don't use printf without format
From: René Scharfe @ 2008-08-03 13:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Pieter de Bie, Git Mailinglist, Johannes Schindelin
In-Reply-To: <7vfxpnmgkc.fsf@gitster.siamese.dyndns.org>
printf() without an explicit format string is not a good coding practise,
unless the printed string is guaranteed to not contain percent signs. While
fixing this, we might as well combine the calls to fwrite() and printf().
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
---
builtin-name-rev.c | 12 +++++-------
1 files changed, 5 insertions(+), 7 deletions(-)
diff --git a/builtin-name-rev.c b/builtin-name-rev.c
index 7055ac3..08c8aab 100644
--- a/builtin-name-rev.c
+++ b/builtin-name-rev.c
@@ -189,6 +189,7 @@ static void name_rev_line(char *p, struct name_ref_data *data)
unsigned char sha1[40];
const char *name = NULL;
char c = *(p+1);
+ int p_len = p - p_start + 1;
forty = 0;
@@ -204,13 +205,10 @@ static void name_rev_line(char *p, struct name_ref_data *data)
if (!name)
continue;
- if (data->name_only) {
- fwrite(p_start, p - p_start + 1 - 40, 1, stdout);
- printf(name);
- } else {
- fwrite(p_start, p - p_start + 1, 1, stdout);
- printf(" (%s)", name);
- }
+ if (data->name_only)
+ printf("%.*s%s", p_len - 40, p_start, name);
+ else
+ printf("%.*s (%s)", p_len, p_start, name);
p_start = p + 1;
}
}
^ permalink raw reply related
* Re: [PATCH] gitweb: ref markers link to named shortlogs
From: Petr Baudis @ 2008-08-03 13:20 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Jakub Narebski
In-Reply-To: <cb7bb73a0808030614v260dea2ek6757b7a22b13afa2@mail.gmail.com>
On Sun, Aug 03, 2008 at 03:14:09PM +0200, Giuseppe Bilotta wrote:
> On Sun, Aug 3, 2008 at 2:03 PM, Petr Baudis <pasky@suse.cz> wrote:
> > (ii) I think you should decide on the type of the action based
> > on the object type of the ref; actually, any kind of object type can be
> > ref'd, and for tags you would rather want tag view, etc. (The tag view
> > actually sucks and should behave more like git show tag - i.e. append
> > the appropriate view after the tag info - but that is different matter.)
>
> Funny that. My original plan was to have a different action depending
> on tag (I tried shortlog for tag and commitdiff for branch). And since
> I I had no idea what kind of action to use for 'generic' refs, I left
> them out. Then I had second thoughts and started using shortlog for
> both heads and tags, and collapsed the code but still kept the generic
> refs out of the way. So maybe we can use shortlog as default action
> and single out tags (and whatever else we'll find to need a different
> action)?
What's wrong with my proposed approach to choose actoin based on object
type of the ref?
--
Petr "Pasky" Baudis
The next generation of interesting software will be done
on the Macintosh, not the IBM PC. -- Bill Gates
^ permalink raw reply
* Re: [PATCH] gitweb: ref markers link to named shortlogs
From: Giuseppe Bilotta @ 2008-08-03 13:14 UTC (permalink / raw)
To: Petr Baudis; +Cc: git, Jakub Narebski
In-Reply-To: <20080803120350.GW32184@machine.or.cz>
On Sun, Aug 3, 2008 at 2:03 PM, Petr Baudis <pasky@suse.cz> wrote:
> On Sat, Aug 02, 2008 at 05:39:14PM +0200, Giuseppe Bilotta wrote:
>> This patch turns ref markers for tags and heads into links to
>> shortlog/refname. Appropriate changes are made in the CSS to prevent ref
>> markers to be annoyingly blue and underlined.
>>
>> Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
>
> I think this is good idea in principle, but
>
> (i) Why not do this for all the refs?
>
> (ii) I think you should decide on the type of the action based
> on the object type of the ref; actually, any kind of object type can be
> ref'd, and for tags you would rather want tag view, etc. (The tag view
> actually sucks and should behave more like git show tag - i.e. append
> the appropriate view after the tag info - but that is different matter.)
Funny that. My original plan was to have a different action depending
on tag (I tried shortlog for tag and commitdiff for branch). And since
I I had no idea what kind of action to use for 'generic' refs, I left
them out. Then I had second thoughts and started using shortlog for
both heads and tags, and collapsed the code but still kept the generic
refs out of the way. So maybe we can use shortlog as default action
and single out tags (and whatever else we'll find to need a different
action)?
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* Re: [PATCH] Update to it.po
From: Paolo Ciarrocchi @ 2008-08-03 12:16 UTC (permalink / raw)
To: Michele Ballabio; +Cc: spearce, git
In-Reply-To: <200808031349.03170.barra_cuda@katamail.com>
On Sun, Aug 3, 2008 at 1:49 PM, Michele Ballabio
<barra_cuda@katamail.com> wrote:
> On Sunday 03 August 2008, Paolo Ciarrocchi wrote:
>> Some fairly simply changes to it.po
>>
>>
>> Signed-off-by: Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com>
>> ---
>
> [...]
>
>> po/it.po | 13 ++++++-------
>> 1 files changed, 6 insertions(+), 7 deletions(-)
>
> BTW, I think you posted a patch against git-gui-i18n.git, but that repo is
> way behind git-gui.git and not updated for a while.
Ops... I thought that was still the right process...
> Here is a patch against current master (attached to prevent encoding issues).
>
> The strings missing translation now is "Buckets". I know what
> it means but I can't came up with a translation that I like.
Confused. Even in the repo i used buckets was the only missing translation.
If you look at my patch:
#: lib/choose_repository.tcl:628
msgid "buckets"
-msgstr ""
+msgstr "buckets"
you'll notice that we agree on not translating that word :)
That said, I'd like too see the following hunk be part of your patch as well:
#: lib/spellcheck.tcl:80
-#, fuzzy
msgid "Unrecognized spell checker"
-msgstr "Correttore ortografico sconosciuto"
+msgstr "Correttore ortografico non riconosciuto"
Can you please clarify how you are working on the po file?
I was used to use gtransalator and I'm a bit confused by hunks like
the following:
-#: lib/option.tcl:192
+#: lib/option.tcl:194
Thanks.
--
Paolo
http://paolo.ciarrocchi.googlepages.com/
^ permalink raw reply
* Re: [PATCH] git-svn.perl: Strip ChangeLog bits.
From: Jan Nieuwenhuizen @ 2008-08-03 12:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Petr Baudis, git
In-Reply-To: <7v4p63dstc.fsf@gitster.siamese.dyndns.org>
On za, 2008-08-02 at 14:13 -0700, Junio C Hamano wrote:
> Perhaps doing something like this a (admittedly slightly) better option?
> It allows you to choose from a canned set, or give a series of s///
> rewriting rules (or whatever you would want to have in the custom function)..
Yes, this is (a bit) much nicer, thanks.
I fixed the function to actually return the log entry, renamed it to
'gnu', as it--although this is ooo's silly convention--is a GNU style
ChangeLog that is being stripped, added it to the 'rebase' command,
added some doco and a test.
Jan.
Signed-off-by: Jan Nieuwenhuizen <janneke@gnu.org>
---
Documentation/RelNotes-1.6.0.txt | 3 +
Documentation/git-svn.txt | 4 +
git-svn.perl | 36 ++++++++-
t/t9125-git-svn-clean-changelog.sh | 171 ++++++++++++++++++++++++++++++++++++
4 files changed, 213 insertions(+), 1 deletions(-)
create mode 100644 t/t9125-git-svn-clean-changelog.sh
diff --git a/Documentation/RelNotes-1.6.0.txt b/Documentation/RelNotes-1.6.0.txt
index 2542cf5..917b05a 100644
--- a/Documentation/RelNotes-1.6.0.txt
+++ b/Documentation/RelNotes-1.6.0.txt
@@ -206,6 +206,9 @@ Updates since v1.5.6
* "git-svn dcommit" is now aware of auto-props setting the subversion user
has.
+* git-svn can process changelog entries in order to produce nicer
+ commit messages with the new option --clean-changelog=gnu.
+
* You can tell "git status -u" to even more aggressively omit checking
untracked files with --untracked-files=no.
diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index f230125..653d1fc 100644
--- a/Documentation/git-svn.txt
+++ b/Documentation/git-svn.txt
@@ -118,6 +118,10 @@ accept. However, '--fetch-all' only fetches from the current
Like 'git-rebase'; this requires that the working tree be clean
and have no uncommitted changes.
+--clean-changelog=gnu;;
+ Manipulate SVN commit log messages to produce clean commit
+ messages. Supported formats are: 'gnu', which strips
+ GNU ChangeLog bits.
-l;;
--local;;
Do not fetch remotely; only run 'git-rebase' against the
diff --git a/git-svn.perl b/git-svn.perl
index cf6dbbc..fe4d147 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -66,7 +66,7 @@ my ($_stdin, $_help, $_edit,
$_version, $_fetch_all, $_no_rebase,
$_merge, $_strategy, $_dry_run, $_local,
$_prefix, $_no_checkout, $_url, $_verbose,
- $_git_format);
+ $_git_format, $_clean_changelog, $_clean_log_message);
$Git::SVN::_follow_parent = 1;
my %remote_opts = ( 'username=s' => \$Git::SVN::Prompt::_username,
'config-dir=s' => \$Git::SVN::Ra::config_dir,
@@ -109,9 +109,11 @@ my %cmd = (
fetch => [ \&cmd_fetch, "Download new revisions from SVN",
{ 'revision|r=s' => \$_revision,
'fetch-all|all' => \$_fetch_all,
+ 'clean-changelog=s' => \$_clean_changelog,
%fc_opts } ],
clone => [ \&cmd_clone, "Initialize and fetch revisions",
{ 'revision|r=s' => \$_revision,
+ 'clean-changelog=s' => \$_clean_changelog,
%fc_opts, %init_opts } ],
init => [ \&cmd_init, "Initialize a repo for tracking" .
" (requires URL argument)",
@@ -178,6 +180,7 @@ my %cmd = (
'local|l' => \$_local,
'fetch-all|all' => \$_fetch_all,
'dry-run|n' => \$_dry_run,
+ 'clean-changelog=s' => \$_clean_changelog,
%fc_opts } ],
'commit-diff' => [ \&cmd_commit_diff,
'Commit a diff between two trees',
@@ -238,6 +241,34 @@ my $rv = GetOptions(%opts, 'help|H|h' => \$_help, 'version|V' => \$_version,
$Git::SVN::default_repo_id = $_[1] });
exit 1 if (!$rv && $cmd && $cmd ne 'log');
+my %canned_changelog_cleaner =
+(
+ 'gnu' => sub {
+ local ($_) = @_;
+ s/(^|\n)\s*((\n|\s)*(199[0-9]|20[0-1][0-9])(-[0-9]{2}){2}\s+.*<.*>\s*\n\s+)?/$1/g;
+ s/(^|\n)\* /\n$1/g;
+ s/^[\n\s]*//;
+ s/[\n\s]*$//;
+ s/\n\s*/ /g if length ($_) < 81;
+ $_ . "\n";
+ }
+);
+
+if (defined $_clean_changelog) {
+ if (exists $canned_changelog_cleaner{$_clean_changelog}) {
+ $_clean_log_message = $canned_changelog_cleaner{$_clean_changelog};
+ } elsif ($_clean_changelog ne '') {
+ $_clean_log_message = eval "
+ sub { local(\$_) = \@_; $_clean_changelog; return \$_; }
+ ";
+ if ($@) {
+ die "$!: $_clean_changelog";
+ }
+ } else {
+ die "$_clean_changelog: unknown way to clean log message";
+ }
+}
+
usage(0) if $_help;
version() if $_version;
usage(1) unless defined $cmd;
@@ -2463,6 +2494,9 @@ sub make_log_entry {
close $un or croak $!;
$log_entry{date} = parse_svn_date($log_entry{date});
+ if ($_clean_log_message) {
+ $log_entry{log} = $_clean_log_message->($log_entry{log});
+ }
$log_entry{log} .= "\n";
my $author = $log_entry{author} = check_author($log_entry{author});
my ($name, $email) = defined $::users{$author} ? @{$::users{$author}}
diff --git a/t/t9125-git-svn-clean-changelog.sh b/t/t9125-git-svn-clean-changelog.sh
new file mode 100644
index 0000000..1a7c5e1
--- /dev/null
+++ b/t/t9125-git-svn-clean-changelog.sh
@@ -0,0 +1,171 @@
+#!/bin/sh
+#
+# Copyright (c) 2008 Jan Nieuwenhuizen <janneke@gnu.org>
+
+test_description='git-svn fetch --clean-changelog'
+
+. ./lib-git-svn.sh
+
+cat > dumpfile.svn <<EOF
+SVN-fs-dump-format-version: 2
+
+UUID: 3e54420c-6148-11dd-bf80-b901c556354a
+
+Revision-number: 0
+Prop-content-length: 56
+Content-length: 56
+
+K 8
+svn:date
+V 27
+2008-08-03T10:38:00.279529Z
+PROPS-END
+
+Revision-number: 1
+Prop-content-length: 231
+Content-length: 231
+
+K 7
+svn:log
+V 128
+2008-08-03 Jan Nieuwenhuizen <janneke@gnu.org>
+
+ * one: New file. This adds the \`one' file to the svn
+ repository.
+
+
+K 10
+svn:author
+V 7
+janneke
+K 8
+svn:date
+V 27
+2008-08-03T10:42:21.211246Z
+PROPS-END
+
+Node-path: one
+Node-kind: file
+Node-action: add
+Prop-content-length: 10
+Text-content-length: 4
+Text-content-md5: 5bbf5a52328e7439ae6e719dfe712200
+Content-length: 14
+
+PROPS-END
+one
+
+
+Revision-number: 2
+Prop-content-length: 217
+Content-length: 217
+
+K 7
+svn:log
+V 114
+2008-08-03 Jan Nieuwenhuizen <janneke@gnu.org>
+
+ * one: Change to numeral.
+ * /path/to/two (foo, bar): Update.
+
+
+K 10
+svn:author
+V 7
+janneke
+K 8
+svn:date
+V 27
+2008-08-03T10:47:11.023749Z
+PROPS-END
+
+Node-path: one
+Node-kind: file
+Node-action: change
+Text-content-length: 2
+Text-content-md5: b026324c6904b2a9cb4b88d6d61c81d1
+Content-length: 2
+
+1
+
+
+Node-path: two
+Node-kind: file
+Node-action: add
+Prop-content-length: 10
+Text-content-length: 4
+Text-content-md5: c193497a1a06b2c72230e6146ff47080
+Content-length: 14
+
+PROPS-END
+two
+
+
+Revision-number: 3
+Prop-content-length: 192
+Content-length: 192
+
+K 7
+svn:log
+V 90
+ * three: Add yet another commit that is too long to fit on one
+line, i.e., 81 chars.
+
+
+K 10
+svn:author
+V 7
+janneke
+K 8
+svn:date
+V 27
+2008-08-03T10:51:21.214317Z
+PROPS-END
+
+Node-path: three
+Node-kind: file
+Node-action: add
+Prop-content-length: 10
+Text-content-length: 6
+Text-content-md5: febe6995bad457991331348f7b9c85fa
+Content-length: 16
+
+PROPS-END
+three
+
+
+EOF
+
+test_expect_success 'load svn dumpfile' 'svnadmin load "$PWD/svnrepo" < dumpfile.svn'
+test_expect_success 'clone revision from svn' 'git-svn clone --clean-changelog=gnu -r0 "file://$PWD/svnrepo" test-git'
+test_expect_success 'fetch revision from svn' '(cd test-git && git-svn fetch --clean-changelog=gnu)'
+test_expect_success 'rebase revision from svn' '(cd test-git && git-svn rebase --clean-changelog=gnu)'
+test_expect_success 'get log' '(cd test-git && git log | grep -Ev "^(commit|Author)" > git-log.output)'
+
+cat > git-log.expect << EOF
+Date: Sun Aug 3 10:51:21 2008 +0000
+
+ three: Add yet another commit that is too long to fit on one
+ line, i.e., 81 chars.
+
+
+ git-svn-id: file://$PWD/svnrepo@3 3e54420c-6148-11dd-bf80-b901c556354a
+
+Date: Sun Aug 3 10:47:11 2008 +0000
+
+ one: Change to numeral. /path/to/two (foo, bar): Update.
+
+
+ git-svn-id: file://$PWD/svnrepo@2 3e54420c-6148-11dd-bf80-b901c556354a
+
+Date: Sun Aug 3 10:42:21 2008 +0000
+
+ one: New file. This adds the \`one' file to the svn repository.
+
+
+ git-svn-id: file://$PWD/svnrepo@1 3e54420c-6148-11dd-bf80-b901c556354a
+EOF
+
+test_expect_success 'git svn clone/fetch --changelog=gnu' 'cmp git-log.expect test-git/git-log.output'
+
+test_done
--
1.6.0.rc0.44.g67270
--
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien | http://www.lilypond.org
^ permalink raw reply related
* Re: [PATCH] gitweb: ref markers link to named shortlogs
From: Petr Baudis @ 2008-08-03 12:03 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Jakub Narebski
In-Reply-To: <1217691554-10407-1-git-send-email-giuseppe.bilotta@gmail.com>
On Sat, Aug 02, 2008 at 05:39:14PM +0200, Giuseppe Bilotta wrote:
> This patch turns ref markers for tags and heads into links to
> shortlog/refname. Appropriate changes are made in the CSS to prevent ref
> markers to be annoyingly blue and underlined.
>
> Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
I think this is good idea in principle, but
(i) Why not do this for all the refs?
(ii) I think you should decide on the type of the action based
on the object type of the ref; actually, any kind of object type can be
ref'd, and for tags you would rather want tag view, etc. (The tag view
actually sucks and should behave more like git show tag - i.e. append
the appropriate view after the tag info - but that is different matter.)
--
Petr "Pasky" Baudis
The next generation of interesting software will be done
on the Macintosh, not the IBM PC. -- Bill Gates
^ permalink raw reply
* Re: [ANNOUNCE] TopGit - A different patch queue manager
From: Petr Baudis @ 2008-08-03 12:02 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git
In-Reply-To: <20080803072726.GB32057@genesis.frugalware.org>
On Sun, Aug 03, 2008 at 09:27:26AM +0200, Miklos Vajna wrote:
> Heh, no please. I have a porcelain called 'dg'[0] after 'darcs-git', which
> imitates some of the darcs UI, but operating on a git repo. ;-)
>
> [0] http://tinyurl.com/5lfs5g, http://tinyurl.com/6pb772
Oh, good to know. I was considering naming this 'dg' as a pun on 'cg'
(though only half-seriously ;).
Petr "Pasky" Baudis
^ permalink raw reply
* Re: gitweb status for 1.6.0?
From: Petr Baudis @ 2008-08-03 12:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jakub Narebski, git, Shawn O. Pearce
In-Reply-To: <7vvdyjcdj8.fsf@gitster.siamese.dyndns.org>
On Sat, Aug 02, 2008 at 02:28:27PM -0700, Junio C Hamano wrote:
> There have been a handful gitweb patches on the list recently (I think
> they were all post -rc0 feature enhancements, but I may be mistaken). I'm
> wondering what their status are. Does any of them matter in the current
> cycle?
I think these are all feature enhancements and I'd rather wait with them
for 1.6.1 (and I'm preparing to dump quite a few my gitweb patches afer
1.6.0 is out as well ;).
--
Petr "Pasky" Baudis
The next generation of interesting software will be done
on the Macintosh, not the IBM PC. -- Bill Gates
^ permalink raw reply
* Re: More on git over HTTP POST
From: H. Peter Anvin @ 2008-08-03 11:42 UTC (permalink / raw)
To: david; +Cc: Shawn O. Pearce, Junio C Hamano, Git Mailing List
In-Reply-To: <alpine.DEB.1.10.0808030105510.22058@asgard.lang.hm>
david@lang.hm wrote:
>
> actually, it's not just a matter of not getting 'past this dark age of
> the Internet', it's an issue that so many people are tunneling
> _everyting_ over http (including the bad guys tunneling malware) that
> proxies are getting more aggressive then they have ever been before in
> pulling apart the payload and analysing it before letting it get through
> to the far side.
>
... which is of course because of said proxies that this is happening, too.
There are too many idiots out there building "security software" and
running IT departments, that's really the bottom line.
By the way, I want to say *thank you* to Shawn for tackling this
project: this has been a major issue for kernel.org, and getting
something like this deployed would be incredibly helpful.
-hpa
^ permalink raw reply
* Re: [PATCH] Update to it.po
From: Michele Ballabio @ 2008-08-03 11:49 UTC (permalink / raw)
To: Paolo Ciarrocchi, spearce; +Cc: git
In-Reply-To: <20080803121131.589e672b@paolo-desktop>
[-- Attachment #1: Type: text/plain, Size: 587 bytes --]
On Sunday 03 August 2008, Paolo Ciarrocchi wrote:
> Some fairly simply changes to it.po
>
>
> Signed-off-by: Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com>
> ---
[...]
> po/it.po | 13 ++++++-------
> 1 files changed, 6 insertions(+), 7 deletions(-)
BTW, I think you posted a patch against git-gui-i18n.git, but that repo is
way behind git-gui.git and not updated for a while.
Here is a patch against current master (attached to prevent encoding issues).
The strings missing translation now is "Buckets". I know what
it means but I can't came up with a translation that I like.
[-- Attachment #2: 0001-git-gui-update-po-it.po.patch.gz --]
[-- Type: application/x-gzip, Size: 8749 bytes --]
^ permalink raw reply
* Re: [RFC 2/2] Add Git-aware CGI for Git-aware smart HTTP transport
From: H. Peter Anvin @ 2008-08-03 11:38 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <1217748317-70096-2-git-send-email-spearce@spearce.org>
Shawn O. Pearce wrote:
> +#define hex(a) (hexchar[(a) & 15])
> +static void chunked_write(const char *fmt, ...)
> +{
> + static const char hexchar[] = "0123456789abcdef";
> + va_list args;
> + unsigned n;
> +
> + va_start(args, fmt);
> + n = vsnprintf(buffer + 6, sizeof(buffer) - 8, fmt, args);
> + va_end(args);
> + if (n >= sizeof(buffer) - 8)
> + die("protocol error: impossibly long line");
> +
> + if (can_chunk) {
> + unsigned len = n + 4, b = 4;
> +
> + buffer[4] = '\r';
> + buffer[5] = '\n';
> + buffer[n + 6] = '\r';
> + buffer[n + 7] = '\n';
> +
> + while (n > 0) {
> + buffer[--b] = hex(n);
> + n >>= 4;
> + len++;
> + }
> +
> + safe_write(1, buffer + b, len);
> + } else
> + safe_write(1, buffer + 6, n);
> +}
Maybe I am slightly confused, but I thought handling HTTP chunking for
HTTP/1.1+ clients was usually done by Apache above the level of the CGI
script?
-hpa
^ permalink raw reply
* Re: More on git over HTTP POST
From: H. Peter Anvin @ 2008-08-03 11:29 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <20080803041014.GD27465@spearce.org>
Shawn O. Pearce wrote:
>
> IOW I had thought we were past this dark age of the Internet.
>
If we were, there wouldn't be a need for this project at all. The whole
purpose of it is to deal with corporate proxies that try to prevent
actual communication because of "security", and it's really hard to
predict what utterly arbitrary heuristics they have applied.
-hpa
^ permalink raw reply
* Re: More on git over HTTP POST
From: H. Peter Anvin @ 2008-08-03 11:31 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Git Mailing List
In-Reply-To: <20080803041258.GE27465@spearce.org>
Shawn O. Pearce wrote:
>
> But from the client side perspective the chunked transfer encoding
> is used only to avoid generating in advance and producing the
> content-length header. I fully expect the encoding to disappear
> (e.g. in a proxy, or in the HTTP client library) before any sort
> of Git code gets its fingers on the data.
>
> Hence to your other remark, I _do not_ rely upon the encoding
> boundaries to remain intact. That is why there is Git pkt-line
> encodings inside of the HTTP data stream. We can rely on the
> pkt-line encoding being present, even if the HTTP chunks were
> moved around (or removed entirely) by a proxy.
>
Excellent. I did not mean that as criticism, obviously, I just wanted
that to be clear.
HTTP/1.1 does chunked encoding, and HTTP/1.0 does terminate on
connection close; both serve the same purpose.
-hpa
^ permalink raw reply
* [PATCH] git-gui: add a part about format strings in po/README
From: Michele Ballabio @ 2008-08-03 11:12 UTC (permalink / raw)
To: Paolo Ciarrocchi; +Cc: spearce, git
In-Reply-To: <20080803121131.589e672b@paolo-desktop>
This should help tranlators that need to reorder words and strings.
Original explanation by Christian Stimming.
Also remove unneeded backslashes.
Signed-off-by: Michele Ballabio <barra_cuda@katamail.com>
---
On Sunday 03 August 2008, Paolo Ciarrocchi wrote:
> Shawn,
> a simple make in the git-gui-i18n repository fails with the following msg:
> paolo@paolo-desktop:~/git-gui-i18n$ make
> GITGUI_VERSION = 0.9.GITGUI-dirty
> * new locations or Tcl/Tk interpreter
> GEN git-gui
> INDEX lib/
> MSGFMT po/bg.msg 391 translated.
> MSGFMT po/de.msg 383 translated, 5 fuzzy, 3 untranslated.
> MSGFMT po/es.msg 122 translated, 269 untranslated.
> MSGFMT po/fr.msg 391 translated.
> MSGFMT po/hu.msg 391 translated.
> MSGFMT po/it.msg make: *** [po/it.msg] Error 1
>
> Before and after the following patch :-)
I think that's this commit: c6fb29db5a50df150280b641d3c2a6703589b529
(Fixed usage of positional parameters in it.po and ja.po).
It didn't fix anything and was harmful instead.
Maybe this patch could be useful.
po/README | 17 +++++++++++------
1 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/po/README b/po/README
index 5e77a7d..595bbf5 100644
--- a/po/README
+++ b/po/README
@@ -101,7 +101,7 @@ matching msgid lines. A few tips:
"printf()"-like functions. Make sure "%s", "%d", and "%%" in your
translated messages match the original.
- When you have to change the order of words, you can add "<number>\$"
+ When you have to change the order of words, you can add "<number>$"
between '%' and the conversion ('s', 'd', etc.) to say "<number>-th
parameter to the format string is used at this point". For example,
if the original message is like this:
@@ -111,12 +111,17 @@ matching msgid lines. A few tips:
and if for whatever reason your translation needs to say weight first
and then length, you can say something like:
- "WEIGHT IS %2\$d, LENGTH IS %1\$d"
+ "WEIGHT IS %2$d, LENGTH IS %1$d"
- The reason you need a backslash before dollar sign is because
- this is a double quoted string in Tcl language, and without
- it the letter introduces a variable interpolation, which you
- do not want here.
+ A format specification with a '*' (asterisk) refers to *two* arguments
+ instead of one, hence the succeeding argument number is two higher
+ instead of one. So, a message like this
+
+ "%s ... %*i of %*i %s (%3i%%)"
+
+ is equivalent to
+
+ "%1$s ... %2$*i of %4$*i %6$s (%7$3i%%)"
- A long message can be split across multiple lines by ending the
string with a double quote, and starting another string on the next
--
1.6.0.rc1
^ permalink raw reply related
* Re: Missing pieces for 1.6.0 on MinGW?
From: Johannes Schindelin @ 2008-08-03 10:45 UTC (permalink / raw)
To: Johannes Sixt, Steve Haslam; +Cc: Junio C Hamano, Steffen Prohaska, git
In-Reply-To: <1217754985.4895776973fda@webmail.nextra.at>
Hi,
On Sun, 3 Aug 2008, Johannes Sixt wrote:
> (2) the non-builtins in $(bindir) don't set argv0_path, and consequently
> don't find ETC_GITCONFIG.
>
> (3) the 'mingw_main undefined' error is still a mystery. I'm about to
> send a preprocessed file to Steffen (it's a bit large, even compressed,
> so I'll do that in a private mail).
For both issues, IMHO Steve's patches should be superior, as they (with my
proposed lookup_program_in_path()) would not only make relative
ETC_GITCONFIG work on MinGW, but everywhere else, too. Obsoleting
mingw_main, of course.
Ciao,
Dscho
^ permalink raw reply
* Re: Missing pieces for 1.6.0 on MinGW?
From: Steffen Prohaska @ 2008-08-03 10:17 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, Johannes Schindelin, git
In-Reply-To: <1217754985.4895776973fda@webmail.nextra.at>
On Aug 3, 2008, at 11:16 AM, Johannes Sixt wrote:
> Zitat von Junio C Hamano <gitster@pobox.com>:
>> Just a quick question before the weekend ends and -rc2 gets
>> tagged. (I
>> lost track of that argv0 vs bin/git vs libexec/git-core/git-foo
>> discussion).
>>
>> Are there any missing but necessary patches we need before 1.6.0 for
>> MinGW?
>
> Yes, there are some open issues:
>
> (1) git-gui was fixed for the msysgit installer, but it broke for
> me; but I
> think I know where to fix it.
I now recognized that not all hunks that I have in 4msysgit were applied
by Shawn. See separate mail
http://article.gmane.org/gmane.comp.version-control.git/91221
> (2) the non-builtins in $(bindir) don't set argv0_path, and
> consequently don't
> find ETC_GITCONFIG.
Setting argv0_path correctly wouldn't help alone. The relative
path to $prefix is different in $prefix/bin and
$prefix/libexec/git-core. Thus, we cannot do the same computation.
system_path() would need to check from which directory the computation
starts.
> (3) the 'mingw_main undefined' error is still a mystery. I'm about
> to send a
> preprocessed file to Steffen (it's a bit large, even compressed, so
> I'll do
> that in a private mail).
ok.
Steffen
^ permalink raw reply
* [PATCH] Update to it.po
From: Paolo Ciarrocchi @ 2008-08-03 10:11 UTC (permalink / raw)
To: spearce, git, barra_cuda
Some fairly simply changes to it.po
Signed-off-by: Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com>
---
Shawn,
a simple make in the git-gui-i18n repository fails with the following msg:
paolo@paolo-desktop:~/git-gui-i18n$ make
GITGUI_VERSION = 0.9.GITGUI-dirty
* new locations or Tcl/Tk interpreter
GEN git-gui
INDEX lib/
MSGFMT po/bg.msg 391 translated.
MSGFMT po/de.msg 383 translated, 5 fuzzy, 3 untranslated.
MSGFMT po/es.msg 122 translated, 269 untranslated.
MSGFMT po/fr.msg 391 translated.
MSGFMT po/hu.msg 391 translated.
MSGFMT po/it.msg make: *** [po/it.msg] Error 1
Before and after the following patch :-)
po/it.po | 13 ++++++-------
1 files changed, 6 insertions(+), 7 deletions(-)
diff --git a/po/it.po b/po/it.po
index 197e6fa..aa3ed13 100644
--- a/po/it.po
+++ b/po/it.po
@@ -10,12 +10,12 @@ msgstr ""
"Project-Id-Version: git-gui\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2008-03-14 07:18+0100\n"
-"PO-Revision-Date: 2008-03-17 14:12+0100\n"
-"Last-Translator: Michele Ballabio <barra_cuda@katamail.com>\n"
+"PO-Revision-Date: 2008-08-03 11:59+0200\n"
+"Last-Translator: Paolo Ciarrocchi <Paolo.Ciarrocchi@gmail.com>\n"
"Language-Team: Italian <tp@lists.linux.it>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
-"Content-Transfer-Encoding: 8bit\n"
+"Content-Transfer-Encoding: 8bit"
#: git-gui.sh:41 git-gui.sh:634 git-gui.sh:648 git-gui.sh:661 git-gui.sh:744
#: git-gui.sh:763
@@ -1022,7 +1022,7 @@ msgstr "Calcolo oggetti"
#: lib/choose_repository.tcl:628
msgid "buckets"
-msgstr ""
+msgstr "buckets"
#: lib/choose_repository.tcl:652
#, tcl-format
@@ -1910,16 +1910,14 @@ msgid "Spell checker silently failed on startup"
msgstr "Il correttore ortografico ha riportato un errore all'avvio"
#: lib/spellcheck.tcl:80
-#, fuzzy
msgid "Unrecognized spell checker"
-msgstr "Correttore ortografico sconosciuto"
+msgstr "Correttore ortografico non riconosciuto"
#: lib/spellcheck.tcl:180
msgid "No Suggestions"
msgstr "Nessun suggerimento"
#: lib/spellcheck.tcl:381
-#, fuzzy
msgid "Unexpected EOF from spell checker"
msgstr "Il correttore ortografico ha mandato un EOF inaspettato"
@@ -1994,3 +1992,4 @@ msgstr "Utilizza 'thin pack' (per connessioni lente)"
#: lib/transport.tcl:168
msgid "Include tags"
msgstr "Includi etichette"
+
--
1.5.6.rc1.21.g03300
^ permalink raw reply related
* Re: Missing pieces for 1.6.0 on MinGW?
From: Björn Steinbrink @ 2008-08-03 10:10 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, Steffen Prohaska, Johannes Schindelin, git
In-Reply-To: <1217754985.4895776973fda@webmail.nextra.at>
On 2008.08.03 11:16:25 +0200, Johannes Sixt wrote:
> (3) the 'mingw_main undefined' error is still a mystery. I'm about to send a
> preprocessed file to Steffen (it's a bit large, even compressed, so I'll do
> that in a private mail).
FWIW, gcc 4.3 complains about such function declarations:
x.c:4: error: invalid storage class for function ‘foo’
Seems that gcc complains about that since 4.0, and linking failed with
older versions under some circumstances.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12738
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17205
Björn
^ permalink raw reply
* Re: [PATCH 1/3] git-gui: Adapt discovery of oguilib to execdir 'libexec/git-core'
From: Steffen Prohaska @ 2008-08-03 10:09 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Git Mailing List, Shawn O. Pearce
In-Reply-To: <1217756103.48957bc76eda2@webmail.nextra.at>
On Aug 3, 2008, at 11:35 AM, Johannes Sixt wrote:
> Zitat von Steffen Prohaska <prohaska@zib.de>:
>>
>> On Jul 27, 2008, at 11:24 PM, Shawn O. Pearce wrote:
>>
>>> Steffen Prohaska <prohaska@zib.de> wrote:
>>>> The new execdir has is two levels below the root directory, while
>>>> the old execdir 'bin' was only one level below. This commit
>>>> adapts the discovery of oguilib that uses relative paths
>>>> accordingly.
>>> ...
>>>> diff --git a/git-gui/git-gui.sh b/git-gui/git-gui.sh
>>>> index 940677c..baccd57 100755
>>>> --- a/git-gui/git-gui.sh
>>>> +++ b/git-gui/git-gui.sh
>>>> @@ -52,7 +52,9 @@ catch {rename send {}} ; # What an evil
>>>> concept...
>>>> set oguilib {@@GITGUI_LIBDIR@@}
>>>> set oguirel {@@GITGUI_RELATIVE@@}
>>>> if {$oguirel eq {1}} {
>>>> - set oguilib [file dirname [file dirname [file normalize $argv0]]]
>>>> + set oguilib [file dirname \
>>>> + [file dirname \
>>>> + [file dirname [file normalize $argv0]]]]
>>>> set oguilib [file join $oguilib share git-gui lib]
>>>
>>> Hmmph. This actually comes up incorrectly on my system. The issue
>>> appears to be `git --exec-path` gives me $prefix/libexec/git-core,
>>> and git-gui installs its library into $prefix/libexec/share, which
>>> is wrong. It should have gone to $prefix/share.
>>
>> I am not seeing this problem because I am installing using the
>> toplevel makefile, which sets and exports sharedir to $prefix/share.
>>
>>
>>> I wonder if this is better. Your other two patches seem fine.
>>>
>>> --8<--
>>> [PATCH] git-gui: Correct installation of library to be $prefix/share
>>>
>>> We always wanted the library for git-gui to install into the
>>> $prefix/share directory, not $prefix/libexec/share. All of
>>> the files in our library are platform independent and may
>>> be reused across systems, like any other content stored in
>>> the share directory.
>>>
>>> Our computation of where our library should install to was broken
>>> when git itself started installing to $prefix/libexec/git-core,
>>> which was one level down from where we expected it to be.
>>>
>>> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
>>> ---
>>> Makefile | 3 +++
>>> 1 files changed, 3 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/Makefile b/Makefile
>>> index b19fb2d..f72ab6c 100644
>>> --- a/Makefile
>>> +++ b/Makefile
>>> @@ -32,6 +32,9 @@ endif
>>> ifndef gitexecdir
>>> gitexecdir := $(shell git --exec-path)
>>> endif
>>> +ifeq (git-core,$(notdir $(gitexecdir)))
>>> + gitexecdir := $(patsubst %/,%,$(dir $(gitexecdir)))
>>> +endif
>>
>> But gitexecdir has the correct value, no? gitexecdir is used
>> at several places in the makefile. It seems wrong to strip
>> 'git-core' from gitexecdir. But I must admit that I do not
>> understand all the details of git-gui's Makefile. So maybe
>> you know better.
>>
>> Isn't only the computation of sharedir based on gitexecdir wrong?
>>
>>> ifndef sharedir
>>> sharedir := $(dir $(gitexecdir))share
>>
>>
>> and could be replaced with this (instead of your patch):
>>
>> ifndef sharedir
>> +ifeq (git-core,$(notdir $(gitexecdir)))
>> + sharedir := $(dir $(patsubst %/,%,$(dir $(gitexecdir))))share
>> +else
>> sharedir := $(dir $(gitexecdir))share
>> endif
>> +endif
>
> This is not good enough in my environment.
This only fixes the installation directory.
> I run git-gui effectivly with
>
> wish $prefix/libexec/git-core/git-gui
>
> (and I have $PATH set up to contain $bindir, but not $gitexecdir),
> and this
> needs the original hunk with the three [file dirname ... ], because
> $argv0
> points to $prefix/libexec/git-core/git-gui.
The original hunk fixes the discovery of oguilib, i.e.
from $prefix/libexec/git-core/git-gui to $prefix/share/git-gui/lib
I didn't recognize that the the 'three [file dinames ...]' have
not been applied because I had this change already in 4msysgit
(and still have). Apologies for not checking this more carefully.
> I thought I understood what's going on, but I don't anymore.
>
> Mybe the relative discovery of oguilib must be conditional on the
> "git-core"
> part as well, just like you discover sharedir?
Hmm... you are right. If we want to maintain compatibility
with *both* directory layouts, obviously all computations
that depend on the layout need to be conditional on it.
Steffen
^ permalink raw reply
* Re: [PATCH 1/3] git-gui: Adapt discovery of oguilib to execdir 'libexec/git-core'
From: Johannes Sixt @ 2008-08-03 9:35 UTC (permalink / raw)
To: Steffen Prohaska, Shawn O. Pearce; +Cc: git
In-Reply-To: <AF6C526A-57ED-4386-A4CF-5260D82026B7@zib.de>
Zitat von Steffen Prohaska <prohaska@zib.de>:
>
> On Jul 27, 2008, at 11:24 PM, Shawn O. Pearce wrote:
>
> > Steffen Prohaska <prohaska@zib.de> wrote:
> >> The new execdir has is two levels below the root directory, while
> >> the old execdir 'bin' was only one level below. This commit
> >> adapts the discovery of oguilib that uses relative paths
> >> accordingly.
> > ...
> >> diff --git a/git-gui/git-gui.sh b/git-gui/git-gui.sh
> >> index 940677c..baccd57 100755
> >> --- a/git-gui/git-gui.sh
> >> +++ b/git-gui/git-gui.sh
> >> @@ -52,7 +52,9 @@ catch {rename send {}} ; # What an evil concept...
> >> set oguilib {@@GITGUI_LIBDIR@@}
> >> set oguirel {@@GITGUI_RELATIVE@@}
> >> if {$oguirel eq {1}} {
> >> - set oguilib [file dirname [file dirname [file normalize $argv0]]]
> >> + set oguilib [file dirname \
> >> + [file dirname \
> >> + [file dirname [file normalize $argv0]]]]
> >> set oguilib [file join $oguilib share git-gui lib]
> >
> > Hmmph. This actually comes up incorrectly on my system. The issue
> > appears to be `git --exec-path` gives me $prefix/libexec/git-core,
> > and git-gui installs its library into $prefix/libexec/share, which
> > is wrong. It should have gone to $prefix/share.
>
> I am not seeing this problem because I am installing using the
> toplevel makefile, which sets and exports sharedir to $prefix/share.
>
>
> > I wonder if this is better. Your other two patches seem fine.
> >
> > --8<--
> > [PATCH] git-gui: Correct installation of library to be $prefix/share
> >
> > We always wanted the library for git-gui to install into the
> > $prefix/share directory, not $prefix/libexec/share. All of
> > the files in our library are platform independent and may
> > be reused across systems, like any other content stored in
> > the share directory.
> >
> > Our computation of where our library should install to was broken
> > when git itself started installing to $prefix/libexec/git-core,
> > which was one level down from where we expected it to be.
> >
> > Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
> > ---
> > Makefile | 3 +++
> > 1 files changed, 3 insertions(+), 0 deletions(-)
> >
> > diff --git a/Makefile b/Makefile
> > index b19fb2d..f72ab6c 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -32,6 +32,9 @@ endif
> > ifndef gitexecdir
> > gitexecdir := $(shell git --exec-path)
> > endif
> > +ifeq (git-core,$(notdir $(gitexecdir)))
> > + gitexecdir := $(patsubst %/,%,$(dir $(gitexecdir)))
> > +endif
>
> But gitexecdir has the correct value, no? gitexecdir is used
> at several places in the makefile. It seems wrong to strip
> 'git-core' from gitexecdir. But I must admit that I do not
> understand all the details of git-gui's Makefile. So maybe
> you know better.
>
> Isn't only the computation of sharedir based on gitexecdir wrong?
>
> > ifndef sharedir
> > sharedir := $(dir $(gitexecdir))share
>
>
> and could be replaced with this (instead of your patch):
>
> ifndef sharedir
> +ifeq (git-core,$(notdir $(gitexecdir)))
> + sharedir := $(dir $(patsubst %/,%,$(dir $(gitexecdir))))share
> +else
> sharedir := $(dir $(gitexecdir))share
> endif
> +endif
This is not good enough in my environment. I run git-gui effectivly with
wish $prefix/libexec/git-core/git-gui
(and I have $PATH set up to contain $bindir, but not $gitexecdir), and this
needs the original hunk with the three [file dirname ... ], because $argv0
points to $prefix/libexec/git-core/git-gui.
I thought I understood what's going on, but I don't anymore.
Mybe the relative discovery of oguilib must be conditional on the "git-core"
part as well, just like you discover sharedir?
-- Hannes
^ permalink raw reply
* Re: Missing pieces for 1.6.0 on MinGW?
From: Johannes Sixt @ 2008-08-03 9:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Steffen Prohaska, Johannes Schindelin, git
In-Reply-To: <7vljzfkzkv.fsf@gitster.siamese.dyndns.org>
Zitat von Junio C Hamano <gitster@pobox.com>:
> Just a quick question before the weekend ends and -rc2 gets tagged. (I
> lost track of that argv0 vs bin/git vs libexec/git-core/git-foo
> discussion).
>
> Are there any missing but necessary patches we need before 1.6.0 for
> MinGW?
Yes, there are some open issues:
(1) git-gui was fixed for the msysgit installer, but it broke for me; but I
think I know where to fix it.
(2) the non-builtins in $(bindir) don't set argv0_path, and consequently don't
find ETC_GITCONFIG.
(3) the 'mingw_main undefined' error is still a mystery. I'm about to send a
preprocessed file to Steffen (it's a bit large, even compressed, so I'll do
that in a private mail).
Item (1) I expect to work on later today, but needs some investigation by
Steffen and perhaps Shawn. (2) is probably a minor issue. (3) is, well, a
mystery, although Steffen's patch works for me, too. Nevertheless, I'd like to
know why my original approach does not always work.
-- Hannes
^ permalink raw reply
* Re: Missing pieces for 1.6.0 on MinGW?
From: Steffen Prohaska @ 2008-08-03 8:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, Johannes Schindelin, git
In-Reply-To: <7vljzfkzkv.fsf@gitster.siamese.dyndns.org>
On Aug 2, 2008, at 9:05 PM, Junio C Hamano wrote:
> Just a quick question before the weekend ends and -rc2 gets tagged.
> (I
> lost track of that argv0 vs bin/git vs libexec/git-core/git-foo
> discussion).
I haven't found time to work on this and I also haven't observed
any progress made by others.
> Are there any missing but necessary patches we need before 1.6.0 for
> MinGW?
So we don't have patches, although we still have the problem
discussed last weekend.
Unfortunately, I cannot promise that I'll find time the next couple
of days to work on the issue. I propose you just continue the
release cycle without waiting for MinGW.
Steffen
^ permalink raw reply
* [RFC PATCH (GITK)] gitk: Allow overriding the default commit.
From: Alexander Gavrilov @ 2008-08-03 8:49 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
In-Reply-To: <bb6f213e0807310541s383c2938q91543a1c57a4d71f@mail.gmail.com>
Date: Sun, 27 Jul 2008 08:18:27 +0400
Other GUI tools may occasionally need to start
gitk and make it automatically select a certain
commit. This patch supports doing it through the
environment or command line.
Using the environment allows graceful degradation of
the tool when used with an old version of gitk:
unsupported command line options cause it to die.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
---
On Thursday 31 July 2008 16:41:20 Alexander Gavrilov wrote:
> I have a patch WIP that allows specifying a commit on the command line
> to select instead of the head (I need it to enhance the git gui blame
> UI). It makes the function somewhat more intelligent. I'll submit it
> as soon as this series is sorted out.
I decided to send it now.
-- Alexander
gitk | 25 ++++++++++++++++++++++++-
1 files changed, 24 insertions(+), 1 deletions(-)
diff --git a/gitk b/gitk
index d093a39..2da885d 100755
--- a/gitk
+++ b/gitk
@@ -416,10 +416,12 @@ proc stop_rev_list {view} {
}
proc reset_pending_select {selid} {
- global pending_select mainheadid
+ global pending_select mainheadid selectheadid
if {$selid ne {}} {
set pending_select $selid
+ } elseif {$selectheadid ne {}} {
+ set pending_select $selectheadid
} else {
set pending_select $mainheadid
}
@@ -1607,6 +1609,7 @@ proc getcommit {id} {
proc readrefs {} {
global tagids idtags headids idheads tagobjid
global otherrefids idotherrefs mainhead mainheadid
+ global selecthead selectheadid
foreach v {tagids idtags headids idheads otherrefids idotherrefs} {
catch {unset $v}
@@ -1653,6 +1656,12 @@ proc readrefs {} {
set mainhead [string range $thehead 11 end]
}
}
+ set selectheadid {}
+ if {$selecthead ne {}} {
+ catch {
+ set selectheadid [exec git rev-parse --verify $selecthead]
+ }
+ }
}
# skip over fake commits
@@ -9863,6 +9872,13 @@ if {![file isdirectory $gitdir]} {
exit 1
}
+set selecthead {}
+set selectheadid {}
+
+if {[info exists env(GITK_SELECT_ID)]} {
+ set selecthead $env(GITK_SELECT_ID)
+}
+
set revtreeargs {}
set cmdline_files {}
set i 0
@@ -9874,6 +9890,9 @@ foreach arg $argv {
set cmdline_files [lrange $argv [expr {$i + 1}] end]
break
}
+ "--select-commit=*" {
+ set selecthead [string range $arg 16 end]
+ }
"--argscmd=*" {
set revtreeargscmd [string range $arg 10 end]
}
@@ -9884,6 +9903,10 @@ foreach arg $argv {
incr i
}
+if {$selecthead eq "HEAD"} {
+ set selecthead {}
+}
+
if {$i >= [llength $argv] && $revtreeargs ne {}} {
# no -- on command line, but some arguments (other than --argscmd)
if {[catch {
--
1.5.6.3.18.gfe82
^ permalink raw reply related
* [RFC] gitattributes on a bare repo
From: Giuseppe Bilotta @ 2008-08-03 8:34 UTC (permalink / raw)
To: git
Hello all,
I realized recently that gitattributes don't work on a bare repo. It's
easy to see why (no .gitattributes file to look into) and the
'official' solution is to use .git/info/attributes for that, which has
the obvious problem of being local and not carried over to other repos
(so that e.g. you have to recreate it and keep it up to date on remote
repos too).
I was discussing this on IRC with pasky and he suggested that the best
way to approach the matter was to use the .gitattributes from the
relevant head. For example, a diff-tree would use the first
.gitattributes from the first tree-ish parameter. I have actually
looked into implementing this myself, but I'm afraid my git mojo isn't
strong enough yet.
A similar discussion would hold of course for .gitignore and the
corresponding info/excludes file.
I'm not sure how widespread the need for such a possibility (using
.gitignore and .gitattributes on bare repos) is, but at least
.gitattributes it would allow gitweb to use the correct diff
funcnames.
--
Giuseppe "Oblomov" Bilotta
^ 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