* [PATCH v2 0/4] git-remote rename: support branches->config migration
From: Miklos Vajna @ 2008-11-12 17:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Brandon Casey, git
In-Reply-To: <7viqqtshdd.fsf@gitster.siamese.dyndns.org>
On Tue, Nov 11, 2008 at 08:22:38PM -0800, Junio C Hamano <gitster@pobox.com> wrote:
> The function migrate_file() introduced by [2/4] is called for any
> remote definition that did not come from config (by definition, it
> either came from remotes/foo or branches/foo). The function adds the
> entries for the given remote definition to the config file, and then
> removes remotes/foo file if the remote definition came from it. So it
> is a logically consistent change if you only called this function only
> for remote definitions that came from remotes/foo.
>
> But the function is called for a remote definition that originally
> came from branches/foo as well. It happily adds the definition to the
> config, even though it *fails to remove* branches/foo file.
>
> Do you still think 2/4 is a logically contained good change?
OK, here is an updated series, which is supposed to fix this issue. 1/4
and 4/4 is unchanged.
Miklos Vajna (4):
remote: add a new 'origin' variable to the struct
git-remote rename: support remotes->config migration
git-remote rename: support branches->config migration
git-remote: document the migration feature of the rename subcommand
Documentation/git-remote.txt | 4 ++++
builtin-remote.c | 37 +++++++++++++++++++++++++++++++++++++
remote.c | 3 +++
remote.h | 7 +++++++
t/t5505-remote.sh | 33 +++++++++++++++++++++++++++++++++
5 files changed, 84 insertions(+), 0 deletions(-)
^ permalink raw reply
* [PATCH 3/4] git-remote rename: support branches->config migration
From: Miklos Vajna @ 2008-11-12 17:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Brandon Casey, git
In-Reply-To: <cover.1226508805.git.vmiklos@frugalware.org>
This is similar to the remotes->config one, but it makes the
branches->config conversion possible.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
builtin-remote.c | 6 +++++-
t/t5505-remote.sh | 12 ++++++++++++
2 files changed, 17 insertions(+), 1 deletions(-)
diff --git a/builtin-remote.c b/builtin-remote.c
index 4fa64a2..5b525c7 100644
--- a/builtin-remote.c
+++ b/builtin-remote.c
@@ -384,6 +384,8 @@ static int migrate_file(struct remote *remote)
remote->fetch_refspec[i], buf.buf);
if (remote->origin == REMOTE_REMOTES)
path = git_path("remotes/%s", remote->name);
+ else if (remote->origin == REMOTE_BRANCHES)
+ path = git_path("branches/%s", remote->name);
if (path && unlink(path))
warning("failed to remove '%s'", path);
return 0;
@@ -411,7 +413,9 @@ static int mv(int argc, const char **argv)
if (!oldremote)
die("No such remote: %s", rename.old);
- if (!strcmp(rename.old, rename.new) && oldremote->origin == REMOTE_REMOTES)
+ if (!strcmp(rename.old, rename.new) &&
+ (oldremote->origin == REMOTE_REMOTES ||
+ oldremote->origin == REMOTE_BRANCHES))
return migrate_file(oldremote);
newremote = remote_get(rename.new);
diff --git a/t/t5505-remote.sh b/t/t5505-remote.sh
index 1567631..1f59960 100755
--- a/t/t5505-remote.sh
+++ b/t/t5505-remote.sh
@@ -364,4 +364,16 @@ test_expect_success 'migrate a remote from named file in $GIT_DIR/remotes' '
test "$(git config remote.origin.fetch)" = "refs/heads/master:refs/heads/origin")
'
+test_expect_success 'migrate a remote from named file in $GIT_DIR/branches' '
+ git clone one six &&
+ origin_url=$(pwd)/one &&
+ (cd six &&
+ git remote rm origin &&
+ echo "$origin_url" > .git/branches/origin &&
+ git remote rename origin origin &&
+ ! test -f .git/branches/origin &&
+ test "$(git config remote.origin.url)" = "$origin_url" &&
+ test "$(git config remote.origin.fetch)" = "refs/heads/master:refs/heads/origin")
+'
+
test_done
--
1.6.0.2
^ permalink raw reply related
* [PATCH 2/4] git-remote rename: support remotes->config migration
From: Miklos Vajna @ 2008-11-12 17:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Brandon Casey, git
In-Reply-To: <cover.1226508805.git.vmiklos@frugalware.org>
This patch makes it possible to migrate a remote stored in a
$GIT_DIR/remotes/nick file to the configuration file format.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
builtin-remote.c | 33 +++++++++++++++++++++++++++++++++
t/t5505-remote.sh | 21 +++++++++++++++++++++
2 files changed, 54 insertions(+), 0 deletions(-)
diff --git a/builtin-remote.c b/builtin-remote.c
index 1ca6cdb..4fa64a2 100644
--- a/builtin-remote.c
+++ b/builtin-remote.c
@@ -359,6 +359,36 @@ static int read_remote_branches(const char *refname,
return 0;
}
+static int migrate_file(struct remote *remote)
+{
+ struct strbuf buf = STRBUF_INIT;
+ int i;
+ char *path = NULL;
+
+ strbuf_addf(&buf, "remote.%s.url", remote->name);
+ for (i = 0; i < remote->url_nr; i++)
+ if (git_config_set_multivar(buf.buf, remote->url[i], "^$", 0))
+ return error("Could not append '%s' to '%s'",
+ remote->url[i], buf.buf);
+ strbuf_reset(&buf);
+ strbuf_addf(&buf, "remote.%s.push", remote->name);
+ for (i = 0; i < remote->push_refspec_nr; i++)
+ if (git_config_set_multivar(buf.buf, remote->push_refspec[i], "^$", 0))
+ return error("Could not append '%s' to '%s'",
+ remote->push_refspec[i], buf.buf);
+ strbuf_reset(&buf);
+ strbuf_addf(&buf, "remote.%s.fetch", remote->name);
+ for (i = 0; i < remote->fetch_refspec_nr; i++)
+ if (git_config_set_multivar(buf.buf, remote->fetch_refspec[i], "^$", 0))
+ return error("Could not append '%s' to '%s'",
+ remote->fetch_refspec[i], buf.buf);
+ if (remote->origin == REMOTE_REMOTES)
+ path = git_path("remotes/%s", remote->name);
+ if (path && unlink(path))
+ warning("failed to remove '%s'", path);
+ return 0;
+}
+
static int mv(int argc, const char **argv)
{
struct option options[] = {
@@ -381,6 +411,9 @@ static int mv(int argc, const char **argv)
if (!oldremote)
die("No such remote: %s", rename.old);
+ if (!strcmp(rename.old, rename.new) && oldremote->origin == REMOTE_REMOTES)
+ return migrate_file(oldremote);
+
newremote = remote_get(rename.new);
if (newremote && (newremote->url_nr > 1 || newremote->fetch_refspec_nr))
die("remote %s already exists.", rename.new);
diff --git a/t/t5505-remote.sh b/t/t5505-remote.sh
index 0c956ba..1567631 100755
--- a/t/t5505-remote.sh
+++ b/t/t5505-remote.sh
@@ -343,4 +343,25 @@ test_expect_success 'rename a remote' '
test "$(git config branch.master.remote)" = "upstream")
'
+
+cat > remotes_origin << EOF
+URL: $(pwd)/one
+Push: refs/heads/master:refs/heads/upstream
+Pull: refs/heads/master:refs/heads/origin
+EOF
+
+test_expect_success 'migrate a remote from named file in $GIT_DIR/remotes' '
+ git clone one five &&
+ origin_url=$(pwd)/one &&
+ (cd five &&
+ git remote rm origin &&
+ mkdir -p .git/remotes &&
+ cat ../remotes_origin > .git/remotes/origin &&
+ git remote rename origin origin &&
+ ! test -f .git/remotes/origin &&
+ test "$(git config remote.origin.url)" = "$origin_url" &&
+ test "$(git config remote.origin.push)" = "refs/heads/master:refs/heads/upstream" &&
+ test "$(git config remote.origin.fetch)" = "refs/heads/master:refs/heads/origin")
+'
+
test_done
--
1.6.0.2
^ permalink raw reply related
* [PATCH 4/4] git-remote: document the migration feature of the rename subcommand
From: Miklos Vajna @ 2008-11-12 17:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Brandon Casey, git
In-Reply-To: <cover.1226508805.git.vmiklos@frugalware.org>
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
Documentation/git-remote.txt | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-remote.txt b/Documentation/git-remote.txt
index 7b227b3..fad983e 100644
--- a/Documentation/git-remote.txt
+++ b/Documentation/git-remote.txt
@@ -66,6 +66,10 @@ was passed.
Rename the remote named <old> to <new>. All remote tracking branches and
configuration settings for the remote are updated.
++
+In case <old> and <new> are the same, and <old> is a file under
+`$GIT_DIR/remotes` or `$GIT_DIR/branches`, the remote is converted to
+the configuration file format.
'rm'::
--
1.6.0.2
^ permalink raw reply related
* [PATCH 1/4] remote: add a new 'origin' variable to the struct
From: Miklos Vajna @ 2008-11-12 17:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Brandon Casey, git
In-Reply-To: <cover.1226508805.git.vmiklos@frugalware.org>
This allows one to track where was the remote's original source, so that
it's possible to decide if it makes sense to migrate it to the config
format or not.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
remote.c | 3 +++
remote.h | 7 +++++++
2 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/remote.c b/remote.c
index e530a21..cbb3e48 100644
--- a/remote.c
+++ b/remote.c
@@ -201,6 +201,7 @@ static void read_remotes_file(struct remote *remote)
if (!f)
return;
+ remote->origin = REMOTE_REMOTES;
while (fgets(buffer, BUF_SIZE, f)) {
int value_list;
char *s, *p;
@@ -261,6 +262,7 @@ static void read_branches_file(struct remote *remote)
s++;
if (!*s)
return;
+ remote->origin = REMOTE_BRANCHES;
p = s + strlen(s);
while (isspace(p[-1]))
*--p = 0;
@@ -350,6 +352,7 @@ static int handle_config(const char *key, const char *value, void *cb)
if (!subkey)
return error("Config with no key for remote %s", name);
remote = make_remote(name, subkey - name);
+ remote->origin = REMOTE_CONFIG;
if (!strcmp(subkey, ".mirror"))
remote->mirror = git_config_bool(key, value);
else if (!strcmp(subkey, ".skipdefaultupdate"))
diff --git a/remote.h b/remote.h
index d2e170c..a46a5be 100644
--- a/remote.h
+++ b/remote.h
@@ -1,8 +1,15 @@
#ifndef REMOTE_H
#define REMOTE_H
+enum {
+ REMOTE_CONFIG,
+ REMOTE_REMOTES,
+ REMOTE_BRANCHES
+};
+
struct remote {
const char *name;
+ int origin;
const char **url;
int url_nr;
--
1.6.0.2
^ permalink raw reply related
* Re: [PATCH v2] contrib/hooks/post-receive-email: send individual mails to recipients
From: Johannes Sixt @ 2008-11-12 17:08 UTC (permalink / raw)
To: Michael Adam; +Cc: git, Andy Parkins, Junio C Hamano
In-Reply-To: <E1L0Iv1-00BwsF-Jh@intern.SerNet.DE>
Michael Adam schrieb:
> This changes the behaviour of post-receive-email when a list of recipients
> (separated by commas) is specified as hooks.mailinglist. With this modification,
> an individual mail is sent out for each recipient entry in the list, instead
> of sending a single mail with all the recipients in the "To: " field.
I don't think this is well-behaved:
- The load multiplies for the sender (typically a repository server).
- And wouldn't each recipient get a new Message-Id? This would break
threading if further communication takes place among the recipients.
But I may be wrong on both accounts.
-- Hannes
^ permalink raw reply
* Re: Bug: UTF-16, UCS-4 and non-existing encodings for git log result in incorrect behavior
From: Alexander Gavrilov @ 2008-11-12 16:58 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Constantine Plotnikov, git
In-Reply-To: <alpine.DEB.1.00.0811121740120.30769@pacific.mpi-cbg.de>
On Wed, Nov 12, 2008 at 7:42 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> On Wed, 12 Nov 2008, Alexander Gavrilov wrote:
>> On Wed, Nov 12, 2008 at 7:15 PM, Johannes Schindelin
>> <Johannes.Schindelin@gmx.de> wrote:
>> > On Wed, 12 Nov 2008, Constantine Plotnikov wrote:
>> >> Commit encoding is set correctly. The problem is that git log and git
>> >> show do not support the *output* encodings UTF-16 and UCS-4 and
>> >> silently fail in that case instead of reporting the error.
>> >
>> > That looks more like an iconv bug to me. I assume you are using Windows?
>>
>> Iconv has no way to know that git cannot work with ASCII-incompatible
>> encodings, and UTF-16 is incompatible, because it fills the output with
>> loads of zero bytes. Git both truncates messages on these bytes, and
>> forgets inserting them in strings that it produces itself.
>
> Ah, I thought that the issue was that Git would not handle commits in that
> encoding correctly. Instead, it appears that Git cannot work with UTF-16
> _displays_.
Actually, I think that using those encodings in commits is asking for
trouble too, because the encoding conversion is, as far as I remember,
applied to the entire contents of the commit object, and Git,
naturally, doesn't insert any null bytes in the commit headers to
please the decoder. The result is a completely trashed object on
output.
Also, I think that they are generally a poor choice of an encoding for
data transmission, because they are ASCII-incompatible,
stdlib-incompatible, unreliable to loss and addition of single bytes,
and have no way to detect encoding mismatch except by metadata or
heuristics: almost any string of shorts is "valid".
Alexander
^ permalink raw reply
* [PATCH v2] contrib/hooks/post-receive-email: send individual mails to recipients
From: Michael Adam @ 2008-11-12 16:50 UTC (permalink / raw)
To: git; +Cc: Andy Parkins, Junio C Hamano, Michael Adam
This changes the behaviour of post-receive-email when a list of recipients
(separated by commas) is specified as hooks.mailinglist. With this modification,
an individual mail is sent out for each recipient entry in the list, instead
of sending a single mail with all the recipients in the "To: " field.
Signed-off-by: Michael Adam <obnox@samba.org>
---
Sorry, in the first version of the patch, I forgot to
adapt the generate_email_header() function fill the "To"
field only with "$recipient" instad of "$recipients".
Cheers - Michael
contrib/hooks/post-receive-email | 32 ++++++++++++++++++--------------
1 files changed, 18 insertions(+), 14 deletions(-)
diff --git a/contrib/hooks/post-receive-email b/contrib/hooks/post-receive-email
index 28a3c0e..f8bbeab 100644
--- a/contrib/hooks/post-receive-email
+++ b/contrib/hooks/post-receive-email
@@ -169,21 +169,25 @@ generate_email()
describe=$rev
fi
- generate_email_header
+ # loop over the recipients to send individual mails
+ echo $recipients | sed -e 's/\s*,\s*/\n/' | while read recipient
+ do
+ generate_email_header
- # Call the correct body generation function
- fn_name=general
- case "$refname_type" in
- "tracking branch"|branch)
- fn_name=branch
- ;;
- "annotated tag")
- fn_name=atag
- ;;
- esac
- generate_${change_type}_${fn_name}_email
+ # Call the correct body generation function
+ fn_name=general
+ case "$refname_type" in
+ "tracking branch"|branch)
+ fn_name=branch
+ ;;
+ "annotated tag")
+ fn_name=atag
+ ;;
+ esac
+ generate_${change_type}_${fn_name}_email
- generate_email_footer
+ generate_email_footer
+ done
}
generate_email_header()
@@ -191,7 +195,7 @@ generate_email_header()
# --- Email (all stdout will be the email)
# Generate header
cat <<-EOF
- To: $recipients
+ To: $recipient
Subject: ${emailprefix}$projectdesc $refname_type, $short_refname, ${change_type}d. $describe
X-Git-Refname: $refname
X-Git-Reftype: $refname_type
--
1.5.6
^ permalink raw reply related
* [PATCH] contrib/hooks/post-receive-email: document individual mails in comments
From: Michael Adam @ 2008-11-12 16:21 UTC (permalink / raw)
To: git; +Cc: Andy Parkins, Junio C Hamano, Michael Adam
In-Reply-To: <1226506888-2841305-1-git-send-email-obnox@samba.org>
This documents the new behaviour to send individual mails for the
recipient emails in the "Config" section of the comment header.
Signed-off-by: Michael Adam <obnox@samba.org>
---
contrib/hooks/post-receive-email | 6 +++++-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/contrib/hooks/post-receive-email b/contrib/hooks/post-receive-email
index 5deaf28..ecef707 100644
--- a/contrib/hooks/post-receive-email
+++ b/contrib/hooks/post-receive-email
@@ -27,11 +27,15 @@
# ------
# hooks.mailinglist
# This is the list that all pushes will go to; leave it blank to not send
-# emails for every ref update.
+# emails for every ref update. A list of recipient addresses separated
+# by commas may be specified. Each recipient in the list will receive an
+# individual mail.
# hooks.announcelist
# This is the list that all pushes of annotated tags will go to. Leave it
# blank to default to the mailinglist field. The announce emails lists
# the short log summary of the changes since the last annotated tag.
+# Lists of email addresses are treated the same way as in the mailinglists
+# field.
# hooks.envelopesender
# If set then the -f option is passed to sendmail to allow the envelope
# sender address to be set
--
1.5.6
^ permalink raw reply related
* [PATCH] contrib/hooks/post-receive-email: send individual mails to recipients
From: Michael Adam @ 2008-11-12 16:21 UTC (permalink / raw)
To: git; +Cc: Andy Parkins, Junio C Hamano, Michael Adam
This changes the behaviour of post-receive-email when a list of recipients
(separated by commas) is specified as hooks.mailinglist. With this modification,
an individual mail is sent out for each recipient entry in the list, instead
of sending a single mail with all the recipients in the "To: " field.
Signed-off-by: Michael Adam <obnox@samba.org>
---
contrib/hooks/post-receive-email | 30 +++++++++++++++++-------------
1 files changed, 17 insertions(+), 13 deletions(-)
diff --git a/contrib/hooks/post-receive-email b/contrib/hooks/post-receive-email
index 28a3c0e..5deaf28 100644
--- a/contrib/hooks/post-receive-email
+++ b/contrib/hooks/post-receive-email
@@ -169,21 +169,25 @@ generate_email()
describe=$rev
fi
- generate_email_header
+ # loop over the recipients to send individual mails
+ echo $recipients | sed -e 's/\s*,\s*/\n/' | while read recipient
+ do
+ generate_email_header
- # Call the correct body generation function
- fn_name=general
- case "$refname_type" in
- "tracking branch"|branch)
- fn_name=branch
- ;;
- "annotated tag")
- fn_name=atag
- ;;
- esac
- generate_${change_type}_${fn_name}_email
+ # Call the correct body generation function
+ fn_name=general
+ case "$refname_type" in
+ "tracking branch"|branch)
+ fn_name=branch
+ ;;
+ "annotated tag")
+ fn_name=atag
+ ;;
+ esac
+ generate_${change_type}_${fn_name}_email
- generate_email_footer
+ generate_email_footer
+ done
}
generate_email_header()
--
1.5.6
^ permalink raw reply related
* [PATCH fixed] git-svn: Update git-svn to use the ability to place temporary files within repository directory
From: Marten Svanfeldt (dev) @ 2008-11-12 16:38 UTC (permalink / raw)
To: msysgit, git; +Cc: normalperson
In-Reply-To: <491AE935.4040406@svanfeldt.com>
This fixes git-svn within msys where Perl will provide temporary files with path
such as /tmp while the git suit expects native Windows paths.
Signed-off-by: Marten Svanfeldt <developer@svanfeldt.com>
---
Somehow I managed to screw up the last patch when getting it ready for
submission. This patch is a fixed version that actually works.
git-svn.perl | 9 +++++----
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index ef6d773..23ceaff 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -3312,11 +3312,11 @@ sub change_file_prop {
sub apply_textdelta {
my ($self, $fb, $exp) = @_;
- my $fh = Git::temp_acquire('svn_delta');
+ my $fh = $::_repository->temp_acquire('svn_delta');
# $fh gets auto-closed() by SVN::TxDelta::apply(),
# (but $base does not,) so dup() it for reading in close_file
open my $dup, '<&', $fh or croak $!;
- my $base = Git::temp_acquire('git_blob');
+ my $base = $::_repository->temp_acquire('git_blob');
if ($fb->{blob}) {
print $base 'link ' if ($fb->{mode_a} == 120000);
my $size = $::_repository->cat_blob($fb->{blob}, $base);
@@ -3357,7 +3357,8 @@ sub close_file {
warn "$path has mode 120000",
" but is not a link\n";
} else {
- my $tmp_fh = Git::temp_acquire('svn_hash');
+ my $tmp_fh = $::_repository->temp_acquire(
+ 'svn_hash');
my $res;
while ($res = sysread($fh, my $str, 1024)) {
my $out = syswrite($tmp_fh, $str, $res);
@@ -3745,7 +3746,7 @@ sub change_file_prop {
sub _chg_file_get_blob ($$$$) {
my ($self, $fbat, $m, $which) = @_;
- my $fh = Git::temp_acquire("git_blob_$which");
+ my $fh = $::_repository->temp_acquire("git_blob_$which");
if ($m->{"mode_$which"} =~ /^120/) {
print $fh 'link ' or croak $!;
$self->change_file_prop($fbat,'svn:special','*');
--
1.6.0.3.1439.gc9385a
^ permalink raw reply related
* Re: Bug: UTF-16, UCS-4 and non-existing encodings for git log result in incorrect behavior
From: Johannes Schindelin @ 2008-11-12 16:42 UTC (permalink / raw)
To: Alexander Gavrilov; +Cc: Constantine Plotnikov, git
In-Reply-To: <bb6f213e0811120817i20d5c0ajf0c9e289c11387a6@mail.gmail.com>
Hi,
On Wed, 12 Nov 2008, Alexander Gavrilov wrote:
> On Wed, Nov 12, 2008 at 7:15 PM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
>
> > [re Cc:ing the list]
> >
> > On Wed, 12 Nov 2008, Constantine Plotnikov wrote:
> >
> >> On Wed, Nov 12, 2008 at 5:22 PM, Johannes Schindelin
> >> <Johannes.Schindelin@gmx.de> wrote:
> >> >
> >> > On Wed, 12 Nov 2008, Constantine Plotnikov wrote:
> >> >
> >> >> If UTF-16[BE|LE] or UCS-4[BE|LE] encodings are used with git log,
> >> >> the git completes successfully but commit messages and author
> >> >> information are not shown. I suggest that git should fail with
> >> >> fatal error if such zero producing encoding is used.
> >> >>
> >> >> If the incorrect encoding name is used, the git log does not
> >> >> perform any re-encoding, but just display commits in their native
> >> >> encoding. I suggest that git should fail with fatal error in this
> >> >> case as well.
> >> >
> >> > Have you set the correct encoding with i18n.commitEncoding? If
> >> > not, you should not be surprised: Git's default encoding is UTF-8,
> >> > and that fact is well documented, AFAICT.
> >> >
> >> Commit encoding is set correctly. The problem is that git log and git
> >> show do not support the *output* encodings UTF-16 and UCS-4 and
> >> silently fail in that case instead of reporting the error.
> >
> > That looks more like an iconv bug to me. I assume you are using Windows?
>
> Iconv has no way to know that git cannot work with ASCII-incompatible
> encodings, and UTF-16 is incompatible, because it fills the output with
> loads of zero bytes. Git both truncates messages on these bytes, and
> forgets inserting them in strings that it produces itself.
Ah, I thought that the issue was that Git would not handle commits in that
encoding correctly. Instead, it appears that Git cannot work with UTF-16
_displays_.
Yep, I would have expected that.
Ciao,
Dscho
^ permalink raw reply
* Re: Bug: UTF-16, UCS-4 and non-existing encodings for git log result in incorrect behavior
From: Alexander Gavrilov @ 2008-11-12 16:17 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Constantine Plotnikov, git
In-Reply-To: <alpine.DEB.1.00.0811121714280.30769@pacific.mpi-cbg.de>
On Wed, Nov 12, 2008 at 7:15 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> [re Cc:ing the list]
>
> On Wed, 12 Nov 2008, Constantine Plotnikov wrote:
>
>> On Wed, Nov 12, 2008 at 5:22 PM, Johannes Schindelin
>> <Johannes.Schindelin@gmx.de> wrote:
>> >
>> > On Wed, 12 Nov 2008, Constantine Plotnikov wrote:
>> >
>> >> If UTF-16[BE|LE] or UCS-4[BE|LE] encodings are used with git log, the
>> >> git completes successfully but commit messages and author information
>> >> are not shown. I suggest that git should fail with fatal error if such
>> >> zero producing encoding is used.
>> >>
>> >> If the incorrect encoding name is used, the git log does not perform any
>> >> re-encoding, but just display commits in their native encoding. I
>> >> suggest that git should fail with fatal error in this case as well.
>> >
>> > Have you set the correct encoding with i18n.commitEncoding? If not, you
>> > should not be surprised: Git's default encoding is UTF-8, and that fact is
>> > well documented, AFAICT.
>> >
>> Commit encoding is set correctly. The problem is that git log and git
>> show do not support the *output* encodings UTF-16 and UCS-4 and
>> silently fail in that case instead of reporting the error.
>
> That looks more like an iconv bug to me. I assume you are using Windows?
>
Iconv has no way to know that git cannot work with ASCII-incompatible
encodings, and UTF-16 is incompatible, because it fills the output
with loads of zero bytes. Git both truncates messages on these bytes,
and forgets inserting them in strings that it produces itself.
A separate problem is that it allows creating commits with invalid
encoding names, which may be unnoticed for a long time in an
environment with uniform commitencoding settings.
Alexander
^ permalink raw reply
* [PATCH] fix pack.packSizeLimit and --max-pack-size handling
From: Nicolas Pitre @ 2008-11-12 16:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jon Nelson, git
In-Reply-To: <cccedfc60811120712o7fcbf648l9f4b8e6f52e50e39@mail.gmail.com>
First, pack.packSizeLimit and --max-pack-size didn't use the same base
unit which was confusing. They both use MiB now.
Also, if the limit was sufficiently low, having a single object written
could bust the limit (by design), but caused the remaining allowed size
to go negative for subsequent objects, which for an unsigned variable is
a rather huge limit.
Signed-off-by: Nicolas Pitre <nico@cam.org>
---
On Wed, 12 Nov 2008, Jon Nelson wrote:
> I'm using 1.6.0.4 and I've found some weird behavior with
> pack.packSizeLimit and/or --max-pack-size.
>
> Initially, I thought I could just use pack.packSizeLimit and set it to
> (say) 1 to try to limit the size of individual packfiles to 1MiB or
> less. That does not appear to be working.
>
> In one case I performed the following set of commands:
>
> # set pack.packSizeLimit to 20
> git config --global pack.packSizeLimit 20
>
> # verify that it's 20
> git config --get pack.packSizeLimit # verify it's 20
>
> # run gc --prune
> git gc --prune
>
> # show the packfiles
> # I find a *single* 65MB packfile, not a series
> # of 20MB (or less) packfiles.
> ls -la .git/objects/pack/*.pack
>
> # try repack -ad
> git repack -ad
>
> # I find a *single* 65MB packfile, not a series
> # of 20MB (or less) packfiles.
> ls -la .git/objects/pack/*.pack
>
>
> So it would appear that the pack.packSizeLimit param
> is just being ignored??
>
> Then I tested using --max-pack-size explicitly. This works, to a degree.
>
> git repack -ad --max-pack-size 20
>
> # the following shows *4* pack files none larger
> # than (about) 20MB
> ls -la .git/objects/pack/*.pack
>
> # try again with 3MB. This also works.
> git repack -ad --max-pack-size 3
> find .git/objects/pack -name '*.pack' -size +3M -ls # nothing
>
> # try again with 1MB. This does NOT work.
> git repack -ad --max-pack-size 1
>
> # here, I find a *single* 65MB pack file again:
> find .git/objects/pack -name '*.pack' -size +1M -ls
>
> Am I doing something completely wrong with pack.packSizeLimit?
> What is going on with --max-pack-size in the 1MB case?
Does this fix it for you?
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 32dcd64..e7808b8 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1036,9 +1036,9 @@ you can use linkgit:git-index-pack[1] on the *.pack file to regenerate
the `{asterisk}.idx` file.
pack.packSizeLimit::
- The default maximum size of a pack. This setting only affects
- packing to a file, i.e. the git:// protocol is unaffected. It
- can be overridden by the `\--max-pack-size` option of
+ The default maximum size of a pack, expressed in MiB. This
+ setting only affects packing to a file, i.e. the git:// protocol is
+ unaffected. It can be overridden by the `\--max-pack-size` option of
linkgit:git-repack[1].
pager.<cmd>::
diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
index 0c4649c..fdee9c6 100644
--- a/builtin-pack-objects.c
+++ b/builtin-pack-objects.c
@@ -245,8 +245,12 @@ static unsigned long write_object(struct sha1file *f,
type = entry->type;
/* write limit if limited packsize and not first object */
- limit = pack_size_limit && nr_written ?
- pack_size_limit - write_offset : 0;
+ if (!pack_size_limit || !nr_written)
+ limit = 0;
+ else if (pack_size_limit <= write_offset)
+ limit = 1;
+ else
+ limit = pack_size_limit - write_offset;
if (!entry->delta)
usable_delta = 0; /* no delta */
@@ -1844,7 +1848,7 @@ static int git_pack_config(const char *k, const char *v, void *cb)
return 0;
}
if (!strcmp(k, "pack.packsizelimit")) {
- pack_size_limit_cfg = git_config_ulong(k, v);
+ pack_size_limit_cfg = git_config_ulong(k, v) * 1024 * 1024;
return 0;
}
return git_default_config(k, v, cb);
^ permalink raw reply related
* Re: Bug: UTF-16, UCS-4 and non-existing encodings for git log result in incorrect behavior
From: Johannes Schindelin @ 2008-11-12 16:15 UTC (permalink / raw)
To: Constantine Plotnikov; +Cc: git
In-Reply-To: <85647ef50811120727j730cb6e3lf4103c200d042fb9@mail.gmail.com>
Hi,
[re Cc:ing the list]
On Wed, 12 Nov 2008, Constantine Plotnikov wrote:
> On Wed, Nov 12, 2008 at 5:22 PM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> >
> > On Wed, 12 Nov 2008, Constantine Plotnikov wrote:
> >
> >> If UTF-16[BE|LE] or UCS-4[BE|LE] encodings are used with git log, the
> >> git completes successfully but commit messages and author information
> >> are not shown. I suggest that git should fail with fatal error if such
> >> zero producing encoding is used.
> >>
> >> If the incorrect encoding name is used, the git log does not perform any
> >> re-encoding, but just display commits in their native encoding. I
> >> suggest that git should fail with fatal error in this case as well.
> >
> > Have you set the correct encoding with i18n.commitEncoding? If not, you
> > should not be surprised: Git's default encoding is UTF-8, and that fact is
> > well documented, AFAICT.
> >
> Commit encoding is set correctly. The problem is that git log and git
> show do not support the *output* encodings UTF-16 and UCS-4 and
> silently fail in that case instead of reporting the error.
That looks more like an iconv bug to me. I assume you are using Windows?
Ciao,
Dscho
^ permalink raw reply
* EGIT branch checkout errors
From: Chris Dumoulin @ 2008-11-12 15:50 UTC (permalink / raw)
To: git
Using EGIT in Eclipse, I'm able to create a new branch, but not able to
checkout a branch. When I try Team->Branch...->Checkout, nothing
happens, so I launched Eclipse from a terminal to see any output it
might be giving. Here's what I got:
java.lang.reflect.InvocationTargetException
at org.eclipse.jface.operation.ModalContext.run(ModalContext.java:415)
at
org.eclipse.jface.window.ApplicationWindow$1.run(ApplicationWindow.java:758)
at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70)
at
org.eclipse.jface.window.ApplicationWindow.run(ApplicationWindow.java:755)
at
org.eclipse.ui.internal.WorkbenchWindow.run(WorkbenchWindow.java:2487)
at
org.spearce.egit.ui.internal.actions.BranchAction.run(BranchAction.java:53)
at
org.eclipse.team.internal.ui.actions.TeamAction.runWithEvent(TeamAction.java:548)
at
org.eclipse.ui.internal.PluginAction.runWithEvent(PluginAction.java:241)
at
org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection(ActionContributionItem.java:583)
at
org.eclipse.jface.action.ActionContributionItem.access$2(ActionContributionItem.java:500)
at
org.eclipse.jface.action.ActionContributionItem$5.handleEvent(ActionContributionItem.java:411)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1158)
at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3401)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3033)
at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2382)
at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2346)
at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2198)
at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:493)
at
org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:288)
at
org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:488)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
at
org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:113)
at
org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:193)
at
org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
at
org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
at
org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:386)
at
org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:549)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:504)
at org.eclipse.equinox.launcher.Main.run(Main.java:1236)
at org.eclipse.equinox.launcher.Main.main(Main.java:1212)
Caused by: java.lang.NullPointerException
at org.spearce.jgit.lib.GitIndex.addEntry(GitIndex.java:746)
at
org.spearce.jgit.lib.WorkDirCheckout.checkoutTwoTrees(WorkDirCheckout.java:146)
at
org.spearce.jgit.lib.WorkDirCheckout.checkout(WorkDirCheckout.java:137)
at
org.spearce.egit.core.op.BranchOperation.checkoutTree(BranchOperation.java:133)
at org.spearce.egit.core.op.BranchOperation.run(BranchOperation.java:69)
at
org.spearce.egit.ui.internal.actions.BranchAction$1.run(BranchAction.java:58)
at
org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:121)
Any help would be appreciated.
Thanks,
Chris
^ permalink raw reply
* Re: [PATCH] git-diff: Add --staged as a synonym for --cached.
From: Avery Pennarun @ 2008-11-12 15:46 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Jeff King, Junio C Hamano, Björn Steinbrink, David Symonds,
git, Stephan Beyer
In-Reply-To: <alpine.DEB.1.00.0811121205100.30769@pacific.mpi-cbg.de>
On Wed, Nov 12, 2008 at 6:10 AM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Just in case anybody thought about creating tree objects on the fly and
> use their SHA-1s: that won't fly, as you can have unmerged entries in the
> index. So STAGED.. is a _fundamentally_ different thing from HEAD^..
Hmm, I tried it to see, and "git diff --cached branchname" when there
are unmerged entries looks like this (one line):
* Unmerged path /whatever/file
Which is pretty unhelpful anyhow (although I don't know what would be
better). I can think of several ways to produce the same output,
including using a magic SHA-1 that means "unmerged", or using a
different filemode for unmerged files in the tree object, or actually
including all three versions of the file in the tree object, each with
a different mode. I admit that sounds pretty gross, though.
> Maybe we could play tricks with a special staged_commit (pretending to be
> a commit with SHA-1 000000... so that git log STAGED.. would do the same
> as plain git log, the rationale being that STAGED is no commit, so ^STAGED
> should be a nop).
I might have imagined STAGED to be a child commit of HEAD (or rather,
its parents should be the same as if you did 'git commit'), but I
don't really know for sure. In such a case, ^STAGED would definitely
have a meaning.
Have fun,
Avery
^ permalink raw reply
* Re: [PATCH] git-diff: Add --staged as a synonym for --cached.
From: Avery Pennarun @ 2008-11-12 15:39 UTC (permalink / raw)
To: Jeff King
Cc: Johannes Schindelin, Junio C Hamano, Björn Steinbrink,
David Symonds, git, Stephan Beyer
In-Reply-To: <20081112110629.GA20473@coredump.intra.peff.net>
On Wed, Nov 12, 2008 at 6:06 AM, Jeff King <peff@peff.net> wrote:
> On Wed, Nov 12, 2008 at 12:10:57PM +0100, Johannes Schindelin wrote:
>
>> Just in case anybody thought about creating tree objects on the fly and
>> use their SHA-1s: that won't fly, as you can have unmerged entries in the
>> index. So STAGED.. is a _fundamentally_ different thing from HEAD^..
>
> I thought about that at first, too, but the working tree is even more
> painful. You would have to hash every changed file on the filesystem to
> create the tree object.
Is that so bad? You have to read all those files anyway in order to do a diff.
Avery
^ permalink raw reply
* Re: problem with git gui on cygwin.
From: Jim Jensen @ 2008-11-12 15:37 UTC (permalink / raw)
To: git
In-Reply-To: <loom.20081111T155614-227@post.gmane.org>
Jim Jensen <jhjjhjjhj <at> gmail.com> writes:
Some further information:
git gui --trace doesn't seem to do anything.
I copied the tree from the directory it was in :
/cygdrive/c/Docume~1/dad/Desktop/cyghome/javt
to: /javt
and gitk started working.
In this directory git-gui give the following error:
couldn't execute "C:\cygwin\usr\sbin\git-core\git-update-index.exe":
invalid argument
couldn't execute "C:\cygwin\usr\sbin\git-core\git-update-index.exe":
invalid
argument
while executing
"error $err"
(procedure "_open_stdout_stderr" line 16)
invoked from within
"_open_stdout_stderr [concat $opt $cmdp $args"
(procedure "git_read" line 26)
invoked from within
"git_read update-index -q --unmerged --ignore-missing --refresh "
(procedure "rescan" line 39)
invoked from within
"rescan ui_ready"
(procedure "do_rescan" line 2)
invoked from within
"do_rescan"
("after" script)
Any more ideas on things to try?
^ permalink raw reply
* pack.packSizeLimit and --max-pack-size not working?
From: Jon Nelson @ 2008-11-12 15:12 UTC (permalink / raw)
To: git
I'm using 1.6.0.4 and I've found some weird behavior with
pack.packSizeLimit and/or --max-pack-size.
Initially, I thought I could just use pack.packSizeLimit and set it to
(say) 1 to try to limit the size of individual packfiles to 1MiB or
less. That does not appear to be working.
In one case I performed the following set of commands:
# set pack.packSizeLimit to 20
git config --global pack.packSizeLimit 20
# verify that it's 20
git config --get pack.packSizeLimit # verify it's 20
# run gc --prune
git gc --prune
# show the packfiles
# I find a *single* 65MB packfile, not a series
# of 20MB (or less) packfiles.
ls -la .git/objects/pack/*.pack
# try repack -ad
git repack -ad
# I find a *single* 65MB packfile, not a series
# of 20MB (or less) packfiles.
ls -la .git/objects/pack/*.pack
So it would appear that the pack.packSizeLimit param
is just being ignored??
Then I tested using --max-pack-size explicitly. This works, to a degree.
git repack -ad --max-pack-size 20
# the following shows *4* pack files none larger
# than (about) 20MB
ls -la .git/objects/pack/*.pack
# try again with 3MB. This also works.
git repack -ad --max-pack-size 3
find .git/objects/pack -name '*.pack' -size +3M -ls # nothing
# try again with 1MB. This does NOT work.
git repack -ad --max-pack-size 1
# here, I find a *single* 65MB pack file again:
find .git/objects/pack -name '*.pack' -size +1M -ls
Am I doing something completely wrong with pack.packSizeLimit?
What is going on with --max-pack-size in the 1MB case?
--
Jon
^ permalink raw reply
* Change in "git checkout" behaviour between 1.6.0.2 and 1.6.0.3
From: Bruce Stephens @ 2008-11-12 14:36 UTC (permalink / raw)
To: git
The following works fine with 1.6.0.2 and before, but not 1.6.0.3 or
later:
git clone -n git git-test
cd git-test
git checkout -b work v1.6.0.2
When it breaks, the error is:
error: Entry '.gitignore' would be overwritten by merge. Cannot merge.
I'm guessing it's a bug rather than a deliberate change?
^ permalink raw reply
* [PATCH] git-svn: Update git-svn to use the ability to place temporary files within repository directory
From: Marten Svanfeldt (dev) @ 2008-11-12 14:33 UTC (permalink / raw)
To: msysgit, git; +Cc: normalperson
This fixes git-svn within msys where Perl will provide temporary files
with path such as /tmp while the git suit expects native Windows paths.
Signed-off-by: Marten Svanfeldt <developer@svanfeldt.com>
---
git-svn.perl | 9 +++++----
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index ef6d773..f09f981 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -3312,11 +3312,11 @@ sub change_file_prop {
sub apply_textdelta {
my ($self, $fb, $exp) = @_;
- my $fh = Git::temp_acquire('svn_delta');
+ my $fh = $_repository->temp_acquire('svn_delta');
# $fh gets auto-closed() by SVN::TxDelta::apply(),
# (but $base does not,) so dup() it for reading in close_file
open my $dup, '<&', $fh or croak $!;
- my $base = Git::temp_acquire('git_blob');
+ my $base = $_repository->temp_acquire('git_blob');
if ($fb->{blob}) {
print $base 'link ' if ($fb->{mode_a} == 120000);
my $size = $::_repository->cat_blob($fb->{blob}, $base);
@@ -3357,7 +3357,8 @@ sub close_file {
warn "$path has mode 120000",
" but is not a link\n";
} else {
- my $tmp_fh = Git::temp_acquire('svn_hash');
+ my $tmp_fh = $_repository->temp_acquire(
+ 'svn_hash');
my $res;
while ($res = sysread($fh, my $str, 1024)) {
my $out = syswrite($tmp_fh, $str, $res);
@@ -3745,7 +3746,7 @@ sub change_file_prop {
sub _chg_file_get_blob ($$$$) {
my ($self, $fbat, $m, $which) = @_;
- my $fh = Git::temp_acquire("git_blob_$which");
+ my $fh = $_repository->temp_acquire("git_blob_$which");
if ($m->{"mode_$which"} =~ /^120/) {
print $fh 'link ' or croak $!;
$self->change_file_prop($fbat,'svn:special','*');
--
1.6.0.3.1437.g6c121.dirty
^ permalink raw reply related
* Re: Newbie questions regarding jgit
From: Farrukh Najmi @ 2008-11-12 14:33 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: git
In-Reply-To: <491AE2BD.7080103@wellfleetsoftware.com>
BTW, the context for what I am doing is as follows. I am implementing
OASIS ebXML Registry/Repository (RegRep) 4 specs:
<http://www.oasis-open.org/committees/download.php/29972>
I would like to use git for the Repository part of the RegRep while a
relational database will hold the registry part which contains extensive
metadata about repository files. Later I will also evaluate if I can
somehow use git for the Registry part so I can leverage versioning
features of git. I would still need to have the Registry content
duplicated in relational database to support querying of the metadata.
The standard eventually needs to support CheckIn/Checkout and I think a
distributed VCS like git would be very helpful in an implementation.
For those unfamiliar with RegRep as a technology think of it as
providing added value on top of a generic VCS, database or Content
Management system.
For my immediate needs, I need to implement a GitRepository class with
two methods using gjit as shown below. I would appreciate any guidance
and pseudo-code examples on how to implement these methods. Please keep
in mind that I am just getting to know git itself and gjit was key to my
considering git over Mercurial and other distributed VCSs.
public class GitRepositoryManager {
Repository gitRepo;
...
/**
* Gets the content of specified file in git Repo.
*
* @parameter relativePath the relative path in jitRepo for desired
file to get
* @parameter versionName the versionName for the desired file. It
will be unmarshalled from String to ObjectId.
* @return the content of the desired file version packaged as a
DataHandler.
*/
public DataHandler get(String relativePath, String versionName)
throws RepositoryException {
DataHandler dh = null;
...
return dh;
}
/**
* Creates a new version of specified version of file in git Repo.
*
* @parameter relativePath the relative path in jitRepo for desired
file to get
* @parameter versionName the versionName for the desired file. It
will be unmarshalled from String to ObjectId.
* @parameter content the content of the new version for specified
file packaged as a DataHandler.
*/
public void update(String relativePath, String versionName,
DataHandler content) throws RepositoryException {
...
}
}
Farrukh Najmi wrote:
> Jonas Fonseca wrote:
> ...
>>
>>> Now I am wondering where to begin to learn how to do the equivalent
>>> of the
>>> following commands via the gjit Java API:
>>>
>>> * git add /file/
>>> * git rm /file/
>>> * git mv /file
>>> * Whatever is the git way to get a specific version of a file
>>>
>>
>> JGit currently has two APIs for working with the index, which will
>> allow you to add, remove and move data around in the tree. In nbgit I
>> ended up using GitIndex, which I found easier to figure out. As I
>> understand it, in the long run you want to use the DirCache API, but
>> it is still a work in progress.
>>
>
> I am happy to use GitIndex now and switch to DirCache API later when
> it is ready.
> Can I please get some pseudo-code fragments on how to do the use cases
> I identified above?
> The javadoc is still not obvious to me.
>>
>>> I am hoping that there aremore docs, samples, tutorials etc.
>>> somewhere that
>>> I am missing. Thanks for any help you can provide. Some pointers or
>>> code
>>> fragments would be terrific.
>>>
>>
>> I started working on a tutorial for JGit, but didn't get very far so
>> it mostly consists of stub pages.
>>
>> - http://code.google.com/docreader/#p=egit&s=egit&t=JGitTutorial
>>
>> I have been working on moving the tutorial to maven project before
>> starting to write the more code heavy topics. This would make it
>> possible to include code snippets in the tutorial, while also allowing
>> to compile and test the examples.
>>
>
> The wiki is an awesome resource even in its current state. Thank you.
> I would be glad to help contribute improvements to wiki if you give me
> write privilege. What I could do is take the help I get from the list and
> then update wiki carefully as appropriate if you want me to help.
>
> Thanks again to all of you for helping get me bootstrapped with gjit
> and git.
>
--
Regards,
Farrukh Najmi
Web: http://www.wellfleetsoftware.com
^ permalink raw reply
* [PATCH] Git.pm: Make _temp_cache use the repository directory
From: Marten Svanfeldt (dev) @ 2008-11-12 14:28 UTC (permalink / raw)
To: msysgit, git; +Cc: Eric Wong
Update the usage of File::Temp->tempfile to place the temporary files
within the repository directory instead of just letting Perl decide what
directory to use, given there is a repository specified when requesting
the temporary file.
This fixes issues when the Perl in use uses a different format for paths
than in use by native code in the git tools such as msysgit with msys-perl.
Signed-off-by: Marten Svanfeldt <developer@svanfeldt.com>
---
perl/Git.pm | 15 ++++++++++-----
1 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/perl/Git.pm b/perl/Git.pm
index 6aab712..4b71dad 100644
--- a/perl/Git.pm
+++ b/perl/Git.pm
@@ -961,9 +961,7 @@ issue.
=cut
sub temp_acquire {
- my ($self, $name) = _maybe_self(@_);
-
- my $temp_fd = _temp_cache($name);
+ my $temp_fd = _temp_cache(@_);
$TEMP_FILES{$temp_fd}{locked} = 1;
$temp_fd;
@@ -1005,7 +1003,7 @@ sub temp_release {
}
sub _temp_cache {
- my ($name) = @_;
+ my ($self, $name) = _maybe_self(@_);
_verify_require();
@@ -1022,9 +1020,16 @@ sub _temp_cache {
"' was closed. Opening replacement.";
}
my $fname;
+
+ my $tmpdir;
+ if (defined $self) {
+ $tmpdir = $self->repo_path();
+ }
+
($$temp_fd, $fname) = File::Temp->tempfile(
- 'Git_XXXXXX', UNLINK => 1
+ 'Git_XXXXXX', UNLINK => 1, DIR => $tmpdir,
) or throw Error::Simple("couldn't open new temp file");
+
$$temp_fd->autoflush;
binmode $$temp_fd;
$TEMP_FILES{$$temp_fd}{fname} = $fname;
--
1.6.0.3.1437.g6c121.dirty
^ permalink raw reply related
* Re: Bug: UTF-16, UCS-4 and non-existing encodings for git log result in incorrect behavior
From: Johannes Schindelin @ 2008-11-12 14:22 UTC (permalink / raw)
To: Constantine Plotnikov; +Cc: git
In-Reply-To: <85647ef50811120532h778769ddx69f0b111dbad359a@mail.gmail.com>
Hi,
On Wed, 12 Nov 2008, Constantine Plotnikov wrote:
> If UTF-16[BE|LE] or UCS-4[BE|LE] encodings are used with git log, the
> git completes successfully but commit messages and author information
> are not shown. I suggest that git should fail with fatal error if such
> zero producing encoding is used.
>
> If the incorrect encoding name is used, the git log does not perform any
> re-encoding, but just display commits in their native encoding. I
> suggest that git should fail with fatal error in this case as well.
Have you set the correct encoding with i18n.commitEncoding? If not, you
should not be surprised: Git's default encoding is UTF-8, and that fact is
well documented, AFAICT.
Ciao,
Dscho
^ 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