* Re: What's cooking in git.git (Jan 2009, #07; Wed, 28)
From: Jeff King @ 2009-01-30 4:51 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Pieter de Bie, Junio C Hamano, git
In-Reply-To: <bd6139dc0901290420x1216a399w656e4d1622178a06@mail.gmail.com>
On Thu, Jan 29, 2009 at 01:20:20PM +0100, Sverre Rabbelier wrote:
> > It wouldn't help the case of "somebody
> > else pushed some content that you want to pull", but like you said, I
> > think the primary workflow is that you immediately push after cloning
> > the empty repo.
>
> Also, the only way to support the "somebody else pushed already"
> workflow would be to assume the user wants to name the branch
> 'master', which might not be the case at all.
You could make a guess that they will use "master", and if you are
wrong, it behaves as now. But if you are right, "git pull" pulls down
master automatically.
But that is getting a little confusing. So let's push this "git push
--track" idea to completion and see how people like it.
-Peff
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2009, #07; Wed, 28)
From: Jeff King @ 2009-01-30 4:59 UTC (permalink / raw)
To: Nico -telmich- Schottelius
Cc: Pieter de Bie, Sverre Rabbelier, Junio C Hamano, git
In-Reply-To: <20090129120455.GD3027@denkbrett.schottelius.org>
On Thu, Jan 29, 2009 at 01:04:55PM +0100, Nico -telmich- Schottelius wrote:
> I must confess, as a user I would like to do
>
> 1. create local repo
>
> 2. create a remote
>
> 3. push it
>
> I don't care about creating empty repos somewhere:
> My aim is to publish my work, that's it.
I think people have asked for that before, too. The fundamental problem
is that we don't necessarily know how to create the remote repo, or even
have permissions to do so.
If your transport is vanilla ssh, then in theory we could turn
"host:path.git" into "ssh host 'GIT_DIR=path.git git init'". But for
other transports we are out of luck. And for hosting sites like github,
we are out of luck, as you use the web interface to make a new repo.
> 1.2. When creating a new repo, it would be helpful if I can directly add a
> description: git init [description] would be nice to have
I don't think there is any fundamental reason not to allow more setup of
internal .git/* files through 'init'. In most cases, you could just as
easily "echo description >.git/description" afterwards, but it might be
slightly more convenient if you are ssh'ing to do it all in one shot.
> 2.1. I (as a user) understand that I need to create a remote where I have to
> push to. It would be helpful to specify --track-this/--merge-this to
> have it automatically connected to the current branch
git remote add -t master origin $URL ?
> 3.1. I would really like to see something like git push
> --create[-if-not-exists]. This makes sense for me, but could also
> be a global configuration option (push.autocreate = true|false).
I think this would be better as a feature of "git remote". I.e.:
git remote add --create -t master origin $URL
but again, we can only sanely do creation magic in a subset of cases.
Which is why I think nobody has implemented it so far.
-Peff
^ permalink raw reply
* [PATCH] Don't try to reclose in command_close_bidi_pipe
From: Yuval Kogman @ 2009-01-30 4:59 UTC (permalink / raw)
To: git; +Cc: Yuval Kogman
Some commands require their standard input to be closed (like
git-commit-tree). This patch changes command_close_bidi_pipe so no
longer tries to close already closed handles, resulting in an error.
---
perl/Git.pm | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/perl/Git.pm b/perl/Git.pm
index 7d7f2b1..283bba8 100644
--- a/perl/Git.pm
+++ b/perl/Git.pm
@@ -422,6 +422,7 @@ sub command_close_bidi_pipe {
local $?;
my ($pid, $in, $out, $ctx) = @_;
foreach my $fh ($in, $out) {
+ next unless defined(fileno($fh));
unless (close $fh) {
if ($!) {
carp "error closing pipe: $!";
--
1.6.1
^ permalink raw reply related
* Re: [PATCH] push: Learn to set up branch tracking with '--track'
From: Jeff King @ 2009-01-30 5:09 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, gitster
In-Reply-To: <alpine.DEB.1.00.0901300127450.3586@pacific.mpi-cbg.de>
On Fri, Jan 30, 2009 at 01:28:38AM +0100, Johannes Schindelin wrote:
> > Something like the patch below (which is obviously missing all of the
> > infrastructure for doing this optionally, but is meant to illustrate
> > what I'm talking about).
>
> Except that you miss http:// and rsync:// protocols. Those were the
> reasons I did not touch send-pack.
You didn't comment on the part of my email where I said exactly that,
but that I think this is still the right path forward.
Pushing through those protocols is sorely in need of update (actually,
I thought rsync was all but dead at this point). But http push is
missing the update of tracking refs, the usual status output (it still
has the "Maybe you are not up-to-date and need to pull first?" message
that was removed from send-pack a year and a half ago), and who knows
what other tweaks made to do_send_pack (which it appears to have been
copy-and-pasted from in 2006) in the last few years.
So either we don't care about http-push being consistent with send-pack,
and it is OK to have this feature in one but not the other. Or we do,
and we really need to clean up the current divergence.
-Peff
^ permalink raw reply
* Re: gitk run from subdir and "find commit touching paths"
From: Matt Graham @ 2009-01-30 5:56 UTC (permalink / raw)
To: Sitaram Chamarty; +Cc: git
In-Reply-To: <slrngnug78.877.sitaramc@sitaramc.homelinux.net>
On Tue, Jan 27, 2009 at 12:14, Sitaram Chamarty <sitaramc@gmail.com> wrote:
> If I run gitk from a subdirectory, and then try to find a
> commit touching a path, it doesn't work. No movement of
> cursor on "Next/Prev".
>
> Running from the main project directory makes it work ok --
> you can go "Next" or "Prev" finding other commits that
> touched the same path.
>
> Is this a known problem? I couldn't find it in the mailing
> list archives.
Hi,
I get this too. My repos are small enough that I'm usually able to
just cd to the root dir and rerun gitk.
^ permalink raw reply
* Re: [PATCH] Switch receive.denyCurrentBranch to "refuse"
From: Johannes Sixt @ 2009-01-30 7:17 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, gitster
In-Reply-To: <alpine.DEB.1.00.0901300133070.3586@pacific.mpi-cbg.de>
Johannes Schindelin schrieb:
> + error("refusing to update checked out branch: %s\n"
> + "if you know what you are doing, you can allow it by "
> + "setting\n\n"
> + "\tgit config receive.denyCurrentBranch true\n", name);
Oh, fscking hell, I should have screamed out loudly when Jeff named this
option "denyCurrentBranch" instead of "allowCurrentBranch". It's all too
easy to fall into the trap, like you here.
Sigh.
-- J we-don't-need-no-double-negations 6t
^ permalink raw reply
* Re: [PATCH] Switch receive.denyCurrentBranch to "refuse"
From: Jeff King @ 2009-01-30 7:34 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Johannes Schindelin, git, gitster
In-Reply-To: <4982A99C.6070301@viscovery.net>
On Fri, Jan 30, 2009 at 08:17:48AM +0100, Johannes Sixt wrote:
> Johannes Schindelin schrieb:
> > + error("refusing to update checked out branch: %s\n"
> > + "if you know what you are doing, you can allow it by "
> > + "setting\n\n"
> > + "\tgit config receive.denyCurrentBranch true\n", name);
>
> Oh, fscking hell, I should have screamed out loudly when Jeff named this
> option "denyCurrentBranch" instead of "allowCurrentBranch". It's all too
> easy to fall into the trap, like you here.
Sorry. ;P
On the other hand, you also missed the boat on receive.denyDeletes and
receive.denyNonFastForwards.
-Peff
^ permalink raw reply
* Re: [PATCH v2 3/5] chain kill signals for cleanup functions
From: Jeff King @ 2009-01-30 7:55 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, git
In-Reply-To: <20090122060235.GC30133@coredump.intra.peff.net>
On Thu, Jan 22, 2009 at 01:02:35AM -0500, Jeff King wrote:
> diff --git a/test-sigchain.c b/test-sigchain.c
> new file mode 100644
> index 0000000..8747dea
> --- /dev/null
> +++ b/test-sigchain.c
> [...]
> +int main(int argc, char **argv) {
> + sigchain_push(SIGINT, one);
> + sigchain_push(SIGINT, two);
> + sigchain_push(SIGINT, three);
> + raise(SIGINT);
> + return 0;
> +}
The signal-handling test was failing on my Solaris auto-build. After
much painful debugging, it seems that when running without a controlling
terminal (such as under cron), the signal handler for terminal related
signals (including SIGINT) is initialized to SIG_IGN. Thus after popping
all of our signal handlers, we restore the SIG_IGN, the program is _not_
killed by the signal, and the test fails.
One fix would be to just "signal(SIGINT, SIG_DFL)" at the top. But I
think it makes the test cleaner to just switch to a more reliable
signal. The patch would look something like what is below. But I need to
know what exit code Windows generates for SIGTERM. Johannes?
---
diff --git a/t/t0005-signals.sh b/t/t0005-signals.sh
index 9707af7..09f855a 100755
--- a/t/t0005-signals.sh
+++ b/t/t0005-signals.sh
@@ -12,7 +12,7 @@ EOF
test_expect_success 'sigchain works' '
test-sigchain >actual
case "$?" in
- 130) true ;; # POSIX w/ SIGINT=2
+ 143) true ;; # POSIX w/ SIGTERM=15
3) true ;; # Windows
*) false ;;
esac &&
diff --git a/test-sigchain.c b/test-sigchain.c
index 8747dea..42db234 100644
--- a/test-sigchain.c
+++ b/test-sigchain.c
@@ -14,9 +14,9 @@ X(three)
#undef X
int main(int argc, char **argv) {
- sigchain_push(SIGINT, one);
- sigchain_push(SIGINT, two);
- sigchain_push(SIGINT, three);
- raise(SIGINT);
+ sigchain_push(SIGTERM, one);
+ sigchain_push(SIGTERM, two);
+ sigchain_push(SIGTERM, three);
+ raise(SIGTERM);
return 0;
}
^ permalink raw reply related
* Re: [PATCH v2 3/5] chain kill signals for cleanup functions
From: Johannes Sixt @ 2009-01-30 8:13 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20090130075552.GA27716@coredump.intra.peff.net>
Jeff King schrieb:
> One fix would be to just "signal(SIGINT, SIG_DFL)" at the top. But I
> think it makes the test cleaner to just switch to a more reliable
> signal. The patch would look something like what is below. But I need to
> know what exit code Windows generates for SIGTERM. Johannes?
The same as with SIGINT: 3.
-- Hannes
^ permalink raw reply
* Re: [PATCH v2 3/5] chain kill signals for cleanup functions
From: Jeff King @ 2009-01-30 8:21 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, git
In-Reply-To: <4982B68C.2070207@viscovery.net>
On Fri, Jan 30, 2009 at 09:13:00AM +0100, Johannes Sixt wrote:
> Jeff King schrieb:
> > One fix would be to just "signal(SIGINT, SIG_DFL)" at the top. But I
> > think it makes the test cleaner to just switch to a more reliable
> > signal. The patch would look something like what is below. But I need to
> > know what exit code Windows generates for SIGTERM. Johannes?
>
> The same as with SIGINT: 3.
Hmm. Clever.
Junio, can you apply this on top of the jk/signal-cleanup topic?
-- >8 --
Subject: [PATCH] t0005: use SIGTERM for sigchain test
The signal tests consists of checking that each of our
handlers is executed, and that the test program was killed
by the final signal. We arbitrarily used SIGINT as the kill
signal.
However, some platforms (notably Solaris) will default
SIGINT to SIG_IGN if there is no controlling terminal. In
that case, we don't end up killing the program with the
final signal and the test fails.
This is a problem since the test script should not depend
on outside factors; let's use SIGTERM instead, which should
behave consistently.
Signed-off-by: Jeff King <peff@peff.net>
---
t/t0005-signals.sh | 2 +-
test-sigchain.c | 8 ++++----
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/t/t0005-signals.sh b/t/t0005-signals.sh
index 9707af7..09f855a 100755
--- a/t/t0005-signals.sh
+++ b/t/t0005-signals.sh
@@ -12,7 +12,7 @@ EOF
test_expect_success 'sigchain works' '
test-sigchain >actual
case "$?" in
- 130) true ;; # POSIX w/ SIGINT=2
+ 143) true ;; # POSIX w/ SIGTERM=15
3) true ;; # Windows
*) false ;;
esac &&
diff --git a/test-sigchain.c b/test-sigchain.c
index 8747dea..42db234 100644
--- a/test-sigchain.c
+++ b/test-sigchain.c
@@ -14,9 +14,9 @@ X(three)
#undef X
int main(int argc, char **argv) {
- sigchain_push(SIGINT, one);
- sigchain_push(SIGINT, two);
- sigchain_push(SIGINT, three);
- raise(SIGINT);
+ sigchain_push(SIGTERM, one);
+ sigchain_push(SIGTERM, two);
+ sigchain_push(SIGTERM, three);
+ raise(SIGTERM);
return 0;
}
--
1.6.1.2.420.ga6a64.dirty
^ permalink raw reply related
* Re: question re dcommit problem
From: Nico -telmich- Schottelius @ 2009-01-30 8:42 UTC (permalink / raw)
To: David Mann; +Cc: git
In-Reply-To: <49824650.2070209@epstudiossoftware.com>
[-- Attachment #1: Type: text/plain, Size: 539 bytes --]
David Mann [Thu, Jan 29, 2009 at 07:14:08PM -0500]:
> I created a git repository from my svn repository, later uploaded it to
> GitHub, and after some branching and merging, can no longer dcommit back
> to the svn repository. [...]
Iirc git svn does not support merges. You've to use git rebase or
update through the svn server.
Sincerly,
Nico
--
Think about Free and Open Source Software (FOSS).
http://nico.schottelius.org/documentations/foss/the-term-foss/
PGP: BFE4 C736 ABE5 406F 8F42 F7CF B8BE F92A 9885 188C
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCH 1/2] fsck: HEAD is part of refs
From: Junio C Hamano @ 2009-01-30 9:12 UTC (permalink / raw)
To: Linus Torvalds; +Cc: H. Peter Anvin, Ingo Molnar, Git Mailing List
In-Reply-To: <alpine.LFD.2.00.0901291512260.3054@localhost.localdomain>
By default we looked at all refs but not HEAD. The only thing that
made fsck not lose sight of comments that are only reachable from a
detached HEAD was the reflog for the HEAD.
This fixes it, with a new test.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
* This is unrelated to Peter's "missing blob", but should be an obviously
right thing to do.
builtin-fsck.c | 13 ++++++++-----
t/t1450-fsck.sh | 18 ++++++++++++++++++
2 files changed, 26 insertions(+), 5 deletions(-)
create mode 100755 t/t1450-fsck.sh
diff --git a/builtin-fsck.c b/builtin-fsck.c
index aecc828..2cfff43 100644
--- a/builtin-fsck.c
+++ b/builtin-fsck.c
@@ -23,6 +23,7 @@ static int check_full;
static int check_strict;
static int keep_cache_objects;
static unsigned char head_sha1[20];
+static const char *head_points_at;
static int errors_found;
static int write_lost_and_found;
static int verbose;
@@ -473,6 +474,8 @@ static int fsck_handle_ref(const char *refname, const unsigned char *sha1, int f
static void get_default_heads(void)
{
+ if (head_points_at && !is_null_sha1(head_sha1))
+ fsck_handle_ref("HEAD", head_sha1, 0, NULL);
for_each_ref(fsck_handle_ref, NULL);
if (include_reflogs)
for_each_reflog(fsck_handle_reflog, NULL);
@@ -512,14 +515,13 @@ static void fsck_object_dir(const char *path)
static int fsck_head_link(void)
{
- unsigned char sha1[20];
int flag;
int null_is_error = 0;
- const char *head_points_at = resolve_ref("HEAD", sha1, 0, &flag);
if (verbose)
fprintf(stderr, "Checking HEAD link\n");
+ head_points_at = resolve_ref("HEAD", head_sha1, 0, &flag);
if (!head_points_at)
return error("Invalid HEAD");
if (!strcmp(head_points_at, "HEAD"))
@@ -528,7 +530,7 @@ static int fsck_head_link(void)
else if (prefixcmp(head_points_at, "refs/heads/"))
return error("HEAD points to something strange (%s)",
head_points_at);
- if (is_null_sha1(sha1)) {
+ if (is_null_sha1(head_sha1)) {
if (null_is_error)
return error("HEAD: detached HEAD points at nothing");
fprintf(stderr, "notice: HEAD points to an unborn branch (%s)\n",
@@ -624,8 +626,9 @@ int cmd_fsck(int argc, const char **argv, const char *prefix)
heads = 0;
for (i = 0; i < argc; i++) {
const char *arg = argv[i];
- if (!get_sha1(arg, head_sha1)) {
- struct object *obj = lookup_object(head_sha1);
+ unsigned char sha1[20];
+ if (!get_sha1(arg, sha1)) {
+ struct object *obj = lookup_object(sha1);
/* Error is printed by lookup_object(). */
if (!obj)
diff --git a/t/t1450-fsck.sh b/t/t1450-fsck.sh
new file mode 100755
index 0000000..5166566
--- /dev/null
+++ b/t/t1450-fsck.sh
@@ -0,0 +1,18 @@
+#!/bin/sh
+
+test_description='git fsck random collection of tests'
+
+. ./test-lib.sh
+
+test_expect_success setup '
+ test_commit A &&
+ git checkout HEAD^0 &&
+ test_commit B &&
+ git reflog expire --expire=now --all
+'
+
+test_expect_success 'HEAD is part of refs' '
+ test 0 = $(git fsck | wc -l)
+'
+
+test_done
--
1.6.1.2.312.g5be3c
^ permalink raw reply related
* [PATCH 2/2] fsck: check loose objects from alternate object stores by default
From: Junio C Hamano @ 2009-01-30 9:13 UTC (permalink / raw)
To: Linus Torvalds; +Cc: H. Peter Anvin, Ingo Molnar, Git Mailing List
In-Reply-To: <alpine.LFD.2.00.0901291512260.3054@localhost.localdomain>
"git fsck" used to validate only loose objects that are local and nothing
else by default. This is not just too little when a repository is
borrowing objects from other object stores, but also caused the
connectivity check to mistakenly declare loose objects borrowed from them
to be missing.
The rationale behind the default mode that validates only loose objects is
because these objects are still young and more unlikely to have been
pushed to other repositories yet. That holds for loose objects borrowed
from alternate object stores as well.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
* This implements your earlier suggestion. We might want to say where
the corrupt object was found when fsck_sha1() reports problems, but
that is an issue that already exists when the command is run with
--full.
builtin-fsck.c | 21 ++++++++++++---------
t/t1450-fsck.sh | 16 ++++++++++++++--
2 files changed, 26 insertions(+), 11 deletions(-)
diff --git a/builtin-fsck.c b/builtin-fsck.c
index 2cfff43..64dffa5 100644
--- a/builtin-fsck.c
+++ b/builtin-fsck.c
@@ -586,6 +586,7 @@ static struct option fsck_opts[] = {
int cmd_fsck(int argc, const char **argv, const char *prefix)
{
int i, heads;
+ struct alternate_object_database *alt;
errors_found = 0;
@@ -597,17 +598,19 @@ int cmd_fsck(int argc, const char **argv, const char *prefix)
fsck_head_link();
fsck_object_dir(get_object_directory());
+
+ prepare_alt_odb();
+ for (alt = alt_odb_list; alt; alt = alt->next) {
+ char namebuf[PATH_MAX];
+ int namelen = alt->name - alt->base;
+ memcpy(namebuf, alt->base, namelen);
+ namebuf[namelen - 1] = 0;
+ fsck_object_dir(namebuf);
+ }
+
if (check_full) {
- struct alternate_object_database *alt;
struct packed_git *p;
- prepare_alt_odb();
- for (alt = alt_odb_list; alt; alt = alt->next) {
- char namebuf[PATH_MAX];
- int namelen = alt->name - alt->base;
- memcpy(namebuf, alt->base, namelen);
- namebuf[namelen - 1] = 0;
- fsck_object_dir(namebuf);
- }
+
prepare_packed_git();
for (p = packed_git; p; p = p->next)
/* verify gives error messages itself */
diff --git a/t/t1450-fsck.sh b/t/t1450-fsck.sh
index 5166566..6e64e44 100755
--- a/t/t1450-fsck.sh
+++ b/t/t1450-fsck.sh
@@ -5,9 +5,9 @@ test_description='git fsck random collection of tests'
. ./test-lib.sh
test_expect_success setup '
- test_commit A &&
+ test_commit A fileA one &&
git checkout HEAD^0 &&
- test_commit B &&
+ test_commit B fileB two &&
git reflog expire --expire=now --all
'
@@ -15,4 +15,16 @@ test_expect_success 'HEAD is part of refs' '
test 0 = $(git fsck | wc -l)
'
+test_expect_success 'loose objects borrowed from alternate are not missing' '
+ mkdir another &&
+ (
+ cd another &&
+ git init &&
+ echo ../../../.git/objects >.git/objects/info/alternates &&
+ test_commit C fileC one &&
+ git fsck >out &&
+ ! grep "missing blob" out
+ )
+'
+
test_done
--
1.6.1.2.312.g5be3c
^ permalink raw reply related
* Re: [PATCH 1/2] fsck: HEAD is part of refs
From: Johannes Sixt @ 2009-01-30 9:27 UTC (permalink / raw)
To: Junio C Hamano
Cc: Linus Torvalds, H. Peter Anvin, Ingo Molnar, Git Mailing List
In-Reply-To: <7veiylb1in.fsf_-_@gitster.siamese.dyndns.org>
Junio C Hamano schrieb:
> By default we looked at all refs but not HEAD. The only thing that
> made fsck not lose sight of comments that are only reachable from a
> detached HEAD was the reflog for the HEAD.
>
> This fixes it, with a new test.
[...]
> +test_expect_success setup '
> + test_commit A &&
> + git checkout HEAD^0 &&
> + test_commit B &&
> + git reflog expire --expire=now --all
> +'
> +
> +test_expect_success 'HEAD is part of refs' '
> + test 0 = $(git fsck | wc -l)
I'm scratching my head over this. This test succeeds even without the
change... (Tested with a34a9db.)
-- Hannes
^ permalink raw reply
* [PATCH] builtin-blame.c: Use utf8_strwidth for author's names
From: Geoffrey Thomas @ 2009-01-30 9:41 UTC (permalink / raw)
To: git; +Cc: Geoffrey Thomas
In-Reply-To: <1233308489-2656-1-git-send-email-geofft@mit.edu>
From: Geoffrey Thomas <geofft@mit.edu>
git blame misaligns output if a author's name has a differing display width and
strlen; for instance, an accented Latin letter that takes two bytes to encode
will cause the rest of the line to be shifted to the left by one. To fix this,
use utf8_strwidth instead of strlen (and compute the padding ourselves, since
printf doesn't know about UTF-8).
Signed-off-by: Geoffrey Thomas <geofft@mit.edu>
---
builtin-blame.c | 7 ++++---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/builtin-blame.c b/builtin-blame.c
index aae14ef..2941fc0 100644
--- a/builtin-blame.c
+++ b/builtin-blame.c
@@ -19,6 +19,7 @@
#include "string-list.h"
#include "mailmap.h"
#include "parse-options.h"
+#include "utf8.h"
static char blame_usage[] = "git blame [options] [rev-opts] [rev] [--] file";
@@ -1619,9 +1620,9 @@ static void emit_other(struct scoreboard *sb, struct blame_entry *ent, int opt)
ent->s_lno + 1 + cnt);
if (!(opt & OUTPUT_NO_AUTHOR))
- printf(" (%-*.*s %10s",
- longest_author, longest_author,
+ printf(" (%s%*s %10s",
ci.author,
+ longest_author - utf8_strwidth(ci.author), "",
format_time(ci.author_time,
ci.author_tz,
show_raw_time));
@@ -1755,7 +1756,7 @@ static void find_alignment(struct scoreboard *sb, int *option)
if (!(suspect->commit->object.flags & METAINFO_SHOWN)) {
suspect->commit->object.flags |= METAINFO_SHOWN;
get_commit_info(suspect->commit, &ci, 1);
- num = strlen(ci.author);
+ num = utf8_strwidth(ci.author);
if (longest_author < num)
longest_author = num;
}
--
1.5.6.5
^ permalink raw reply related
* [PATCH] utf8: add utf8_strwidth()
From: Geoffrey Thomas @ 2009-01-30 9:41 UTC (permalink / raw)
To: git; +Cc: Geoffrey Thomas
From: Geoffrey Thomas <geofft@mit.edu>
I'm about to use this pattern more than once, so make it a common function.
Signed-off-by: Geoffrey Thomas <geofft@mit.edu>
---
utf8.c | 12 ++++++++++++
utf8.h | 1 +
2 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/utf8.c b/utf8.c
index dc37353..a2d888d 100644
--- a/utf8.c
+++ b/utf8.c
@@ -246,6 +246,18 @@ int utf8_width(const char **start, size_t *remainder_p)
return git_wcwidth(ch);
}
+/*
+ * Returns the total number of columns required by a null-terminated
+ * string.
+ */
+size_t utf8_strwidth(const char *string)
+{
+ size_t width = 0;
+ while (string && *string)
+ width += utf8_width(&string, NULL);
+ return width;
+}
+
int is_utf8(const char *text)
{
while (*text) {
diff --git a/utf8.h b/utf8.h
index 98cce1b..1ae3450 100644
--- a/utf8.h
+++ b/utf8.h
@@ -5,6 +5,7 @@ typedef unsigned int ucs_char_t; /* assuming 32bit int */
ucs_char_t pick_one_utf8_char(const char **start, size_t *remainder_p);
int utf8_width(const char **start, size_t *remainder_p);
+size_t utf8_strwidth(const char *string);
int is_utf8(const char *text);
int is_encoding_utf8(const char *name);
--
1.5.6.5
^ permalink raw reply related
* Re: Appropriateness of git for digital video production versioning
From: Christian MICHON @ 2009-01-30 10:13 UTC (permalink / raw)
To: Charles Earl; +Cc: git
In-Reply-To: <8c4a72800901290736p4952e53byddca243f300dd8af@mail.gmail.com>
On Thu, Jan 29, 2009 at 4:36 PM, Charles Earl <charles.cearl@gmail.com> wrote:
> Hi,
> Are there past instances of git having been adapted to support version
> control of digital media production workflow?
> I'm evaluating CMS and versioning systems for the backend of a SaaS
> for digital media production workflow.
> The bulk of content stored is binary data -- there have been posts on
> this about integration of various binary diff implemetations with git.
> The versioning of metadata, scripts, project structure seems to argue
> for applicability of system such as git -- these fit the paradigm of
> traditional scm.
> Example content is from media production suites such as Adobe After
> Effects/Premier: video, compositions, etc.
> I'd also like the object storage to be in S3/Amazon BlockStore or
> similar remote stores.
> Charles
> --
for what it's worth (call me crazy, call me sick), I used msysgit only
on the project files from Windows Movie Maker (not on the media files,
but the timeline and my personal cuts, etc...).
it works perfectly, so (whatever system you're using) my advice would
be identify the small files and formats saved by your video editing
software (I see xml files are usually used there), only add these in
the git repository and make sure the video inputs and outputs files
are in .gitignore
doing so, you have a fast and cheap tracker of your timeline edition,
splitting and joining of video files.
HIH
--
Christian
--
http://detaolb.sourceforge.net/, a linux distribution for Qemu with Git inside !
^ permalink raw reply
* Re: [topgit] shared topic branch
From: martin f krafft @ 2009-01-30 10:15 UTC (permalink / raw)
To: Fabien Thomas, git
In-Reply-To: <111E5FDD-FC51-4DD2-9959-676003CD7A61@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 863 bytes --]
also sprach Fabien Thomas <thomas.fabien@gmail.com> [2009.01.27.0823 +0100]:
> on the git side:
> the + will overwrite all remote location branche named with that pattern
> ?
+ simply allows non-fast-forwards. See git-push(1). And that's on
the local side, not the remote. Which is what you want.
> if i'm not up to date and i start a push with the "+" will
> overwrite the central repo with my local branch. (overwrite of my
> central repo master branch and my topics)
please reproduce the problem and paste the complete transcript of
what you are doing: commands and output, as well as the output of
git branch -av before and after.
--
martin | http://madduck.net/ | http://two.sentenc.es/
"now, bring me that horizon."
-- captain jack sparrow
spamtraps: madduck.bogus@madduck.net
[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: segfault when cloning over https
From: Jan Kasprzak @ 2009-01-30 10:43 UTC (permalink / raw)
To: Daniel Stenberg; +Cc: git
In-Reply-To: <alpine.DEB.1.10.0901291944030.5789@yvahk2.pbagnpgbe.fr>
Daniel Stenberg wrote:
: On Thu, 29 Jan 2009, Jan Kasprzak wrote:
:
: >without problems, but when I change http to https, it either segfaults or
: >fails with heap corruption detected:
:
: >/lib64/libnsspem.so[0x7f845f3ee9c4]
: >/lib64/libnss3.so[0x7f846210dc4d]
: >/lib64/libnss3.so(PK11_CreateGenericObject+0x42)[0x7f846210ded2]
: >/usr/lib64/libcurl.so.4[0x14b129]
:
: This is a libcurl built to use a Fedora-patched NSS library for the SSL
: stuff. You could try to build your own libcurl with a different SSL library
: to see if that works fine, as then we could narrow this down a bit...
Good guess! When I manually rebuild libcurl without nss and
with SSL, it works. I have forwarded this to Fedora bugzilla as
https://bugzilla.redhat.com/show_bug.cgi?id=483222
Thanks,
-Yenya
--
| Jan "Yenya" Kasprzak <kas at {fi.muni.cz - work | yenya.net - private}> |
| GPG: ID 1024/D3498839 Fingerprint 0D99A7FB206605D7 8B35FCDE05B18A5E |
| http://www.fi.muni.cz/~kas/ Journal: http://www.fi.muni.cz/~kas/blog/ |
>> If you find yourself arguing with Alan Cox, you’re _probably_ wrong. <<
>> --James Morris in "How and Why You Should Become a Kernel Hacker" <<
^ permalink raw reply
* Re: [PATCH 1/2] Missing && in t/t7001.sh.
From: Matthieu Moy @ 2009-01-30 10:36 UTC (permalink / raw)
To: git
In-Reply-To: <1233309819-777-?= =?ISO-8859-1?Q?1-git-send-email?= =?ISO-8859-1?Q?-=0E=10>
^N^P@imag.fr writes:
^^^^
(Sorry for the bad From: header line. I must have typed something
weird at the git send-email prompt, while I thought I had just typed
"enter")
--
Matthieu
^ permalink raw reply
* Finding the name of the parent branch?
From: Pascal Obry @ 2009-01-30 10:56 UTC (permalink / raw)
To: Git Mailing List
I want to find the name of the parent branch in a script. What is the best way?
o---o---o---C
/
o---o---o---B
/
---o---o---o---o---o---A
For B I want to get A and for C I want to get B.
All this can be found in gitk, but from a script I did not found a
good solution.
Any idea?
Thanks.
Pascal.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595
^ permalink raw reply
* [PATCH 1/5] pack-check.c: minor formatting fix to match coding style
From: Junio C Hamano @ 2009-01-30 11:05 UTC (permalink / raw)
To: git
In-Reply-To: <1233313517-24208-1-git-send-email-gitster@pobox.com>
Adjust misaligned columns and multi-line comments that violate our coding
style before touching this file.
Also fix an obvious typo.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
pack-check.c | 21 ++++++++++++---------
1 files changed, 12 insertions(+), 9 deletions(-)
diff --git a/pack-check.c b/pack-check.c
index 90c33b1..2c5f521 100644
--- a/pack-check.c
+++ b/pack-check.c
@@ -4,7 +4,7 @@
struct idx_entry
{
- off_t offset;
+ off_t offset;
const unsigned char *sha1;
unsigned int nr;
};
@@ -43,7 +43,7 @@ int check_pack_crc(struct packed_git *p, struct pack_window **w_curs,
}
static int verify_packfile(struct packed_git *p,
- struct pack_window **w_curs)
+ struct pack_window **w_curs)
{
off_t index_size = p->index_size;
const unsigned char *index_base = p->index_data;
@@ -54,7 +54,8 @@ static int verify_packfile(struct packed_git *p,
int err = 0;
struct idx_entry *entries;
- /* Note that the pack header checks are actually performed by
+ /*
+ * Note that the pack header checks are actually performed by
* use_pack when it first opens the pack file. If anything
* goes wrong during those checks then the call will die out
* immediately.
@@ -72,21 +73,23 @@ static int verify_packfile(struct packed_git *p,
git_SHA1_Final(sha1, &ctx);
pack_sig = use_pack(p, w_curs, pack_sig_ofs, NULL);
if (hashcmp(sha1, pack_sig))
- err = error("%s SHA1 checksum mismatch",
- p->pack_name);
+ err = error("%s SHA1 checksum mismatch", p->pack_name);
if (hashcmp(index_base + index_size - 40, pack_sig))
- err = error("%s SHA1 does not match its inddex",
- p->pack_name);
+ err = error("%s SHA1 does not match its index", p->pack_name);
unuse_pack(w_curs);
- /* Make sure everything reachable from idx is valid. Since we
+ /*
+ * Make sure everything reachable from idx is valid. Since we
* have verified that nr_objects matches between idx and pack,
* we do not do scan-streaming check on the pack file.
*/
nr_objects = p->num_objects;
entries = xmalloc((nr_objects + 1) * sizeof(*entries));
entries[nr_objects].offset = pack_sig_ofs;
- /* first sort entries by pack offset, since unpacking them is more efficient that way */
+ /*
+ * First sort entries by pack offset, since unpacking them is more
+ * efficient that way.
+ */
for (i = 0; i < nr_objects; i++) {
entries[i].sha1 = nth_packed_object_sha1(p, i);
if (!entries[i].sha1)
--
1.6.1.2.312.g5be3c
^ permalink raw reply related
* [PATCH 0/5] fsck updates
From: Junio C Hamano @ 2009-01-30 11:05 UTC (permalink / raw)
To: git; +Cc: Linus Torvalds
These go on top of the previous two patches I sent earlier.
Junio C Hamano (5):
pack-check.c: minor formatting fix to match coding style
verify_pack(): allow a quicker verification for a pack with version 2 idx
verify-pack: add --quick
fsck: three levels of validation
[squash] fsck: revert --quick to the default and introduce --medium
builtin-fsck.c | 13 ++++++++++---
builtin-verify-pack.c | 10 +++++++---
http-push.c | 2 +-
http-walker.c | 2 +-
pack-check.c | 36 ++++++++++++++++++++++++------------
pack.h | 5 ++++-
6 files changed, 47 insertions(+), 21 deletions(-)
^ permalink raw reply
* [PATCH 2/5] verify_pack(): allow a quicker verification for a pack with version 2 idx
From: Junio C Hamano @ 2009-01-30 11:05 UTC (permalink / raw)
To: git
In-Reply-To: <1233313517-24208-2-git-send-email-gitster@pobox.com>
This adds an extra flag parameter to verify_pack() so that the caller can
affect what kind of checks are performed.
For a packfile, we always validate its whole SHA-1 checksum and the pack
header. By default, we make sure that we can unpack all the objects in
the packfile, and the unpacked data actually matches their object name.
In addition, for a pack with version 2 idx that has per-object CRC, we
verify their CRC checksum match what is recorded.
By specifying VERIFY_PACK_QUICK, you can omit the expensive per-object
unpacking and object name validation. Per-object CRC check that is done
for objects in a pack with version 2 idx file is still performed as it is
inexpensive.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin-fsck.c | 2 +-
builtin-verify-pack.c | 2 +-
http-push.c | 2 +-
http-walker.c | 2 +-
pack-check.c | 17 +++++++++++++----
pack.h | 5 ++++-
6 files changed, 21 insertions(+), 9 deletions(-)
diff --git a/builtin-fsck.c b/builtin-fsck.c
index 64dffa5..8dc7881 100644
--- a/builtin-fsck.c
+++ b/builtin-fsck.c
@@ -614,7 +614,7 @@ int cmd_fsck(int argc, const char **argv, const char *prefix)
prepare_packed_git();
for (p = packed_git; p; p = p->next)
/* verify gives error messages itself */
- verify_pack(p);
+ verify_pack(p, 0);
for (p = packed_git; p; p = p->next) {
uint32_t j, num;
diff --git a/builtin-verify-pack.c b/builtin-verify-pack.c
index 25a29f1..42ae406 100644
--- a/builtin-verify-pack.c
+++ b/builtin-verify-pack.c
@@ -93,7 +93,7 @@ static int verify_one_pack(const char *path, int verbose)
return error("packfile %s not found.", arg);
install_packed_git(pack);
- err = verify_pack(pack);
+ err = verify_pack(pack, 0);
if (verbose) {
if (err)
diff --git a/http-push.c b/http-push.c
index 59037df..0cd2926 100644
--- a/http-push.c
+++ b/http-push.c
@@ -809,7 +809,7 @@ static void finish_request(struct transfer_request *request)
lst = &((*lst)->next);
*lst = (*lst)->next;
- if (!verify_pack(target))
+ if (!verify_pack(target, 0))
install_packed_git(target);
else
remote->can_update_info_refs = 0;
diff --git a/http-walker.c b/http-walker.c
index 0dbad3c..7f314b0 100644
--- a/http-walker.c
+++ b/http-walker.c
@@ -797,7 +797,7 @@ static int fetch_pack(struct walker *walker, struct alt_base *repo, unsigned cha
lst = &((*lst)->next);
*lst = (*lst)->next;
- if (verify_pack(target))
+ if (verify_pack(target, 0))
return -1;
install_packed_git(target);
diff --git a/pack-check.c b/pack-check.c
index 2c5f521..256370c 100644
--- a/pack-check.c
+++ b/pack-check.c
@@ -42,8 +42,8 @@ int check_pack_crc(struct packed_git *p, struct pack_window **w_curs,
return data_crc != ntohl(*index_crc);
}
-static int verify_packfile(struct packed_git *p,
- struct pack_window **w_curs)
+static int verify_packfile(struct packed_git *p, struct pack_window **w_curs,
+ unsigned flag)
{
off_t index_size = p->index_size;
const unsigned char *index_base = p->index_data;
@@ -78,6 +78,12 @@ static int verify_packfile(struct packed_git *p,
err = error("%s SHA1 does not match its index", p->pack_name);
unuse_pack(w_curs);
+ if ((flag & VERIFY_PACK_QUICK) && p->index_version <= 1) {
+ warning("contents not checked for %s as its .idx does not have CRC",
+ p->pack_name);
+ return err;
+ }
+
/*
* Make sure everything reachable from idx is valid. Since we
* have verified that nr_objects matches between idx and pack,
@@ -114,6 +120,9 @@ static int verify_packfile(struct packed_git *p,
sha1_to_hex(entries[i].sha1),
p->pack_name, (uintmax_t)offset);
}
+
+ if (flag & VERIFY_PACK_QUICK)
+ continue;
data = unpack_entry(p, entries[i].offset, &type, &size);
if (!data) {
err = error("cannot unpack %s from %s at offset %"PRIuMAX"",
@@ -134,7 +143,7 @@ static int verify_packfile(struct packed_git *p,
return err;
}
-int verify_pack(struct packed_git *p)
+int verify_pack(struct packed_git *p, unsigned flag)
{
off_t index_size;
const unsigned char *index_base;
@@ -157,7 +166,7 @@ int verify_pack(struct packed_git *p)
p->pack_name);
/* Verify pack file */
- err |= verify_packfile(p, &w_curs);
+ err |= verify_packfile(p, &w_curs, flag);
unuse_pack(&w_curs);
return err;
diff --git a/pack.h b/pack.h
index a883334..b9e381c 100644
--- a/pack.h
+++ b/pack.h
@@ -57,7 +57,10 @@ struct pack_idx_entry {
extern char *write_idx_file(char *index_name, struct pack_idx_entry **objects, int nr_objects, unsigned char *sha1);
extern int check_pack_crc(struct packed_git *p, struct pack_window **w_curs, off_t offset, off_t len, unsigned int nr);
-extern int verify_pack(struct packed_git *);
+
+#define VERIFY_PACK_QUICK 01
+extern int verify_pack(struct packed_git *, unsigned flag);
+
extern void fixup_pack_header_footer(int, unsigned char *, const char *, uint32_t, unsigned char *, off_t);
extern char *index_pack_lockfile(int fd);
--
1.6.1.2.312.g5be3c
^ permalink raw reply related
* [PATCH 3/5] verify-pack: add --quick
From: Junio C Hamano @ 2009-01-30 11:05 UTC (permalink / raw)
To: git
In-Reply-To: <1233313517-24208-3-git-send-email-gitster@pobox.com>
This teaches "git verify-pack" a new option --quick, to trigger the
VERIFY_PACK_QUICK option.
"git fsck" is a more familiar command, and it checks more things at once
than "git verify-pack", and the case you do want to use the latter is when
really want a deep verification of a single pack. For this reason, I do
not think anybody would want to actually use this option, but it was an
easy way to benchmark the change.
For a 32M packfile from the git repository on my AMD64X2:
$ /usr/bin/time ./git-verify-pack $THE_PACKFILE
22.16user 0.18system 0:22.35elapsed 100%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+44166minor)pagefaults 0swaps
$ /usr/bin/time ./git-verify-pack --quick $THE_PACKFILE
0.43user 0.02system 0:00.45elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+11569minor)pagefaults 0swaps
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin-verify-pack.c | 10 +++++++---
1 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/builtin-verify-pack.c b/builtin-verify-pack.c
index 42ae406..fdc04d1 100644
--- a/builtin-verify-pack.c
+++ b/builtin-verify-pack.c
@@ -54,12 +54,13 @@ static void show_pack_info(struct packed_git *p)
chain_histogram[0], chain_histogram[0] > 1 ? "s" : "");
}
-static int verify_one_pack(const char *path, int verbose)
+static int verify_one_pack(const char *path, int verbose, int quick)
{
char arg[PATH_MAX];
int len;
struct packed_git *pack;
int err;
+ unsigned flag = (quick ? VERIFY_PACK_QUICK : 0);
len = strlcpy(arg, path, PATH_MAX);
if (len >= PATH_MAX)
@@ -93,7 +94,7 @@ static int verify_one_pack(const char *path, int verbose)
return error("packfile %s not found.", arg);
install_packed_git(pack);
- err = verify_pack(pack, 0);
+ err = verify_pack(pack, flag);
if (verbose) {
if (err)
@@ -112,6 +113,7 @@ static const char verify_pack_usage[] = "git-verify-pack [-v] <pack>...";
int cmd_verify_pack(int argc, const char **argv, const char *prefix)
{
int err = 0;
+ int quick = 0;
int verbose = 0;
int no_more_options = 0;
int nothing_done = 1;
@@ -121,13 +123,15 @@ int cmd_verify_pack(int argc, const char **argv, const char *prefix)
if (!no_more_options && argv[1][0] == '-') {
if (!strcmp("-v", argv[1]))
verbose = 1;
+ else if (!strcmp("--quick", argv[1]))
+ quick = 1;
else if (!strcmp("--", argv[1]))
no_more_options = 1;
else
usage(verify_pack_usage);
}
else {
- if (verify_one_pack(argv[1], verbose))
+ if (verify_one_pack(argv[1], verbose, quick))
err = 1;
discard_revindex();
nothing_done = 0;
--
1.6.1.2.312.g5be3c
^ permalink raw reply related
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