* [PATCH] Calculate $commitsha1 in update() only when needed
From: Pavel Roskin @ 2007-12-08 5:07 UTC (permalink / raw)
To: git
This suppresses unhelpful error messages from git rev-parse during
checkout if the module doesn't exist.
Signed-off-by: Pavel Roskin <proski@gnu.org>
---
git-cvsserver.perl | 12 +++++++-----
1 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/git-cvsserver.perl b/git-cvsserver.perl
index ecded3b..409b301 100755
--- a/git-cvsserver.perl
+++ b/git-cvsserver.perl
@@ -2427,9 +2427,6 @@ sub update
# first lets get the commit list
$ENV{GIT_DIR} = $self->{git_path};
- my $commitsha1 = `git rev-parse $self->{module}`;
- chomp $commitsha1;
-
my $commitinfo = `git cat-file commit $self->{module} 2>&1`;
unless ( $commitinfo =~ /tree\s+[a-zA-Z0-9]{40}/ )
{
@@ -2440,8 +2437,13 @@ sub update
my $git_log;
my $lastcommit = $self->_get_prop("last_commit");
- if (defined $lastcommit && $lastcommit eq $commitsha1) { # up-to-date
- return 1;
+ if (defined $lastcommit) {
+ my $commitsha1 = `git rev-parse $self->{module}`;
+ chomp $commitsha1;
+
+ if ($lastcommit eq $commitsha1) { # up-to-date
+ return 1;
+ }
}
# Start exclusive lock here...
^ permalink raw reply related
* Re: Something is broken in repack
From: Nicolas Pitre @ 2007-12-08 5:12 UTC (permalink / raw)
To: Jon Smirl; +Cc: Git Mailing List
In-Reply-To: <9e4733910712072101k4583c0afsea368253fe1cf706@mail.gmail.com>
On Sat, 8 Dec 2007, Jon Smirl wrote:
> On 12/7/07, Nicolas Pitre <nico@cam.org> wrote:
> > On Fri, 7 Dec 2007, Jon Smirl wrote:
> >
> > > Does the gcc repo contain some giant objects? Why wasn't the memory
> > > freed after their chain was processed?
> >
> > It should be.
> >
> > > Most of the last 10% is being done on a single CPU. There must be a
> > > chain of giant objects that is unbalancing everything.
> >
> > I'm about to send a patch to fix the thread balancing for real this
> > time.
>
> Something is really broken in the last 5% of that repo. I have been
> processing at 97% for 30 minutes without moving to 98%.
This is a clear sign of a problem, indeed.
I'll be away for the weekend, so here's a few things to try out if you
feel like it:
1) Make sure the problem occurs with the thread code disabled. That
would eliminate one variable, and will help for #2.
2) Try bissecting the issue. If you can find an old Git version where
the issue doesn't appear then simply run "git bissect" to find the
exact commit causing the problem. Best with a repo that doesn't take
ages to repack.
3) Compile Git against the dmalloc library in order to identify where
the huge memory leak is happening.
Nicolas
^ permalink raw reply
* On running git via proxy
From: Assim Deodia @ 2007-12-08 5:13 UTC (permalink / raw)
To: git
Hello,
I am a newbie to git. I am running git on my virtual machine which has
the internet access via proxy through the host machine.
I am unable to configure git to run via proxy. system proxy seems not
to be working for git..
Can you please guide me for the same?
--
With Regards
Assim
^ permalink raw reply
* Re: git guidance
From: Valdis.Kletnieks @ 2007-12-08 5:16 UTC (permalink / raw)
To: Al Boldi
Cc: Jakub Narebski, Andreas Ericsson, Johannes Schindelin,
Phillip Susi, Linus Torvalds, Jing Xue, linux-kernel, git
In-Reply-To: <200712080756.21980.a1426z@gawab.com>
[-- Attachment #1: Type: text/plain, Size: 621 bytes --]
On Sat, 08 Dec 2007 07:56:21 +0300, Al Boldi said:
> It probably goes without saying, that gitfs should have some basic
> configuration file to setup its transparent behaviour
But then it's not *truly* transparent, is it?
And that leaves another question - if you make a config file that excludes
all the .o files - then what's backing the .o files? Those data blocks need
to be *someplace*. Maybe you can do something ugly like use unionfs to
combine your gitfs with something else to store the other files...
But at that point, you're probably better off just creating a properly
designed versioning filesystem.
[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]
^ permalink raw reply
* Re: git-bisect feature suggestion: "git-bisect diff"
From: Christian Couder @ 2007-12-08 5:36 UTC (permalink / raw)
To: Ingo Molnar; +Cc: git, Junio C Hamano
In-Reply-To: <20071207093439.GA21896@elte.hu>
Le vendredi 7 décembre 2007, Ingo Molnar a écrit :
> would be nice to have:
>
> git-bisect diff
>
> that enables one to have a look at the currently open bisection window,
> in git-log -p format. This would often be much faster to analyze than
> looking at git-bisect visualize. (and it could also be used in non-GUI
> workflows)
>
> Right now i have this silly git-bisect-diff script:
>
> git-log -p "`git-bisect log | grep good | tail -1 | cut -d' ' -f3`".."\
> `git-bisect log | grep bad | tail -1 | cut -d' ' -f3`"
>
Tell us if you have other scripts or suggestions related to git-bisect.
And thanks for you kind word about it:
http://thread.gmane.org/gmane.linux.kernel.input/3740/focus=3764
Christian.
^ permalink raw reply
* Re: git guidance
From: Martin Langhoff @ 2007-12-08 6:33 UTC (permalink / raw)
To: Al Boldi; +Cc: Linus Torvalds, Jing Xue, linux-kernel, git
In-Reply-To: <200712010950.15628.a1426z@gawab.com>
On Dec 1, 2007 7:50 PM, Al Boldi <a1426z@gawab.com> wrote:
> Not sure what you mean by operationally transparent? It would be transparent
> for the updating client, and the rest of the git-users would need to wait
> for the commit from the updating client; which is ok, as this transparency
> is not meant to change the server-side git-update semantic.
I guess what he means is that when your write to the file -- from your
editor -- it can't be considered a commit. During an editing session
you might write a dozen times, only to commit it once you are happy
(that it compiles, passes tests, etc).
> Sure, you wouldn't want to change the git-engine update semantics, as that
> sits on the server and handles all users. But what the git model is
> currently missing is a client manager. Right now, this is being worked
> around by replicating the git tree on the client, which still doesn't
> provide the required transparency.
If you want a dumb-ish client CVS-style, you can try git-cvsserver.
But the git model is definitely superior -- "replicating the tree on
the client" is not a workaround but a central strategy.
Have you used git and other DSCMs much? From your writing, it sounds
like you may have misunderstood how some of the principles of git work
out in practice.
cheers,
m
^ permalink raw reply
* Re: [PATCH] add status.relativePaths config variable
From: Junio C Hamano @ 2007-12-08 7:34 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Schindelin, Thomas Harning, git
In-Reply-To: <20071207212607.GA11504@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> The output of git-status was recently changed to output
> relative paths. Setting this variable to false restores the
> old behavior for any old-timers that prefer it.
>
> Signed-off-by: Jeff King <peff@peff.net>
> ---
> On Fri, Dec 07, 2007 at 03:49:37PM -0500, Jeff King wrote:
>
>> Personally, I don't like either the "../" or the "./", but I actually
>> think the relative paths are less readable than the full paths in
>> general.
>
> So here is a config option to turn it off; I don't think there should be
> any consistency problems, since git-status output is meant to be
> human-readable (and after all, we just changed it :) ).
I like the general idea (and suspect we might want to make it default to
false to retain the original behaviour, but I'd refrain from suggesting
it, to keep the user experience stable during the upcoming -rc period).
We'd need an update to git-status documentation to mention the variable.
> diff --git a/builtin-commit.c b/builtin-commit.c
> index 18c6323..04b3bf1 100644
> --- a/builtin-commit.c
> +++ b/builtin-commit.c
> @@ -284,8 +284,7 @@ static int run_status(FILE *fp, const char *index_file, const char *prefix)
> {
> struct wt_status s;
>
> - wt_status_prepare(&s);
> - s.prefix = prefix;
> + wt_status_prepare(&s, prefix);
I have been wondering ever since receiving this patch if this is a good
interface change. Was there a problem if instead:
- The implementation of wt_status_prepare(&s) stays as before;
- run_status(), after calling wt_status_prepare(&s), notices the
configuration variable, and sets s.prefix conditionally;
^ permalink raw reply
* Re: [PATCH] add status.relativePaths config variable
From: Junio C Hamano @ 2007-12-08 7:47 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Schindelin, Thomas Harning, git
In-Reply-To: <7vejdxy70p.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> I have been wondering ever since receiving this patch if this is a good
> interface change. Was there a problem if instead:
>
> - The implementation of wt_status_prepare(&s) stays as before;
>
> - run_status(), after calling wt_status_prepare(&s), notices the
> configuration variable, and sets s.prefix conditionally;
Which would make the rewritten patch like this...
-- >8 --
From: Jeff King <peff@peff.net>
Date: Fri, 7 Dec 2007 16:26:07 -0500
Subject: [PATCH] add status.relativePaths config variable
The output of git-status was recently changed to output relative
paths. Setting this variable to false restores the old behavior for
any old-timers that prefer it.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Documentation/config.txt | 6 ++++++
Documentation/git-status.txt | 5 ++++-
builtin-commit.c | 3 ++-
t/t7502-status.sh | 31 +++++++++++++++++++++++++++++++
wt-status.c | 6 ++++++
wt-status.h | 1 +
6 files changed, 50 insertions(+), 2 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 736fcd7..79d51f2 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -762,6 +762,12 @@ showbranch.default::
The default set of branches for gitlink:git-show-branch[1].
See gitlink:git-show-branch[1].
+status.relativePaths::
+ By default, gitlink:git-status[1] shows paths relative to the
+ current directory. Setting this variable to `false` shows paths
+ relative to the repository root (this was the default for git
+ prior to v1.5.4).
+
tar.umask::
This variable can be used to restrict the permission bits of
tar archive entries. The default is 0002, which turns off the
diff --git a/Documentation/git-status.txt b/Documentation/git-status.txt
index b0cb6bc..bd4d787 100644
--- a/Documentation/git-status.txt
+++ b/Documentation/git-status.txt
@@ -42,7 +42,10 @@ template comments, and all the output lines are prefixed with '#'.
The paths mentioned in the output, unlike many other git commands, are
made relative to the current directory, if you are working in a
-subdirectory (this is on purpose, to help cutting and pasting).
+subdirectory (this is on purpose, to help cutting and pasting). You can
+restore the older behaviour of showing the paths as relative to the top
+of the work tree by setting `status.relativepaths` configuration
+variable to `false`.
CONFIGURATION
diff --git a/builtin-commit.c b/builtin-commit.c
index 2ec8223..19297ac 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -285,7 +285,8 @@ static int run_status(FILE *fp, const char *index_file, const char *prefix)
struct wt_status s;
wt_status_prepare(&s);
- s.prefix = prefix;
+ if (wt_status_relative_paths)
+ s.prefix = prefix;
if (amend) {
s.amend = 1;
diff --git a/t/t7502-status.sh b/t/t7502-status.sh
index d6ae69d..9ce50ca 100755
--- a/t/t7502-status.sh
+++ b/t/t7502-status.sh
@@ -88,4 +88,35 @@ test_expect_success 'status with relative paths' '
'
+cat > expect << \EOF
+# On branch master
+# Changes to be committed:
+# (use "git reset HEAD <file>..." to unstage)
+#
+# new file: dir2/added
+#
+# Changed but not updated:
+# (use "git add <file>..." to update what will be committed)
+#
+# modified: dir1/modified
+#
+# Untracked files:
+# (use "git add <file>..." to include in what will be committed)
+#
+# dir1/untracked
+# dir2/modified
+# dir2/untracked
+# expect
+# output
+# untracked
+EOF
+
+test_expect_success 'status without relative paths' '
+
+ git config status.relativePaths false
+ (cd dir1 && git status) > output &&
+ git diff expect output
+
+'
+
test_done
diff --git a/wt-status.c b/wt-status.c
index 05414bb..51c1879 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -8,6 +8,7 @@
#include "revision.h"
#include "diffcore.h"
+int wt_status_relative_paths = 1;
int wt_status_use_color = 0;
static char wt_status_colors[][COLOR_MAXLEN] = {
"", /* WT_STATUS_HEADER: normal */
@@ -400,6 +401,11 @@ int git_status_config(const char *k, const char *v)
if (!prefixcmp(k, "status.color.") || !prefixcmp(k, "color.status.")) {
int slot = parse_status_slot(k, 13);
color_parse(v, k, wt_status_colors[slot]);
+ return 0;
+ }
+ if (!strcmp(k, "status.relativepaths")) {
+ wt_status_relative_paths = git_config_bool(k, v);
+ return 0;
}
return git_default_config(k, v);
}
diff --git a/wt-status.h b/wt-status.h
index 225fb4d..63d50f2 100644
--- a/wt-status.h
+++ b/wt-status.h
@@ -28,6 +28,7 @@ struct wt_status {
int git_status_config(const char *var, const char *value);
int wt_status_use_color;
+int wt_status_relative_paths;
void wt_status_prepare(struct wt_status *s);
void wt_status_print(struct wt_status *s);
--
1.5.3.7-2182-g108b
^ permalink raw reply related
* Re: [PATCH] add status.relativePaths config variable
From: Jeff King @ 2007-12-08 7:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Thomas Harning, git
In-Reply-To: <7vejdxy70p.fsf@gitster.siamese.dyndns.org>
On Fri, Dec 07, 2007 at 11:34:14PM -0800, Junio C Hamano wrote:
> I like the general idea (and suspect we might want to make it default to
> false to retain the original behaviour, but I'd refrain from suggesting
> it, to keep the user experience stable during the upcoming -rc period).
>
> We'd need an update to git-status documentation to mention the variable.
Patch is below; please squash it into the original.
It seems kind of silly to manually write the "Configuration" section for
git-status, though. It would be nice if our config.txt could be
annotated to mention which commands use which config variables, and
git-*.txt could automagically include the right sections.
> > - wt_status_prepare(&s);
> > - s.prefix = prefix;
> > + wt_status_prepare(&s, prefix);
>
> I have been wondering ever since receiving this patch if this is a good
> interface change. Was there a problem if instead:
>
> - The implementation of wt_status_prepare(&s) stays as before;
>
> - run_status(), after calling wt_status_prepare(&s), notices the
> configuration variable, and sets s.prefix conditionally;
That would work fine. My reasoning was: the point of wt_status_prepare
is to initialize the wt_status object. I thought the "whether to use
relative paths based on config" logic should be something that _every_
preparer uses. OTOH, when I wrote it, I never expected that anyone _but_
run_status would call it (I must confess to not really investigating why
git-revert needed it; looks like it is to find a dirty index or working
tree, which is a little silly, since as a side effect we will do a find
on all untracked files).
I am fine with either; your call. Documentation patch is below.
---
diff --git a/Documentation/git-status.txt b/Documentation/git-status.txt
index b0cb6bc..645dc85 100644
--- a/Documentation/git-status.txt
+++ b/Documentation/git-status.txt
@@ -42,7 +42,8 @@ template comments, and all the output lines are prefixed with '#'.
The paths mentioned in the output, unlike many other git commands, are
made relative to the current directory, if you are working in a
-subdirectory (this is on purpose, to help cutting and pasting).
+subdirectory (this is on purpose, to help cutting and pasting). See
+the status.relativePaths config option below.
CONFIGURATION
@@ -53,6 +54,10 @@ mean the same thing and the latter is kept for backward
compatibility) and `color.status.<slot>` configuration variables
to colorize its output.
+If the config variable `status.relativePaths` is set to false, then all
+paths shown are relative to the repository root, not to the current
+directory.
+
See Also
--------
gitlink:gitignore[5]
^ permalink raw reply related
* Re: [PATCH] add status.relativePaths config variable
From: Jeff King @ 2007-12-08 8:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Thomas Harning, git
In-Reply-To: <7vaboly6dv.fsf@gitster.siamese.dyndns.org>
On Fri, Dec 07, 2007 at 11:47:56PM -0800, Junio C Hamano wrote:
> Which would make the rewritten patch like this...
Looks like our patches just crossed paths. Yours looks OK, but we
should add something to the 'configuration' section, and...
> diff --git a/wt-status.h b/wt-status.h
> index 225fb4d..63d50f2 100644
> --- a/wt-status.h
> +++ b/wt-status.h
> @@ -28,6 +28,7 @@ struct wt_status {
>
> int git_status_config(const char *var, const char *value);
> int wt_status_use_color;
> +int wt_status_relative_paths;
> void wt_status_prepare(struct wt_status *s);
> void wt_status_print(struct wt_status *s);
Shouldn't both of these ints be marked "extern"? I'm surprised it worked
at all (or perhaps the part of my brain that stores C linkage issues is
rotting?).
-Peff
^ permalink raw reply
* Re: [PATCH] add status.relativePaths config variable
From: Junio C Hamano @ 2007-12-08 8:05 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Schindelin, Thomas Harning, git
In-Reply-To: <20071208080238.GB4812@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Fri, Dec 07, 2007 at 11:47:56PM -0800, Junio C Hamano wrote:
>
>> Which would make the rewritten patch like this...
>
> Looks like our patches just crossed paths. Yours looks OK, but we
> should add something to the 'configuration' section, and...
>
>> diff --git a/wt-status.h b/wt-status.h
>> index 225fb4d..63d50f2 100644
>> --- a/wt-status.h
>> +++ b/wt-status.h
>> @@ -28,6 +28,7 @@ struct wt_status {
>>
>> int git_status_config(const char *var, const char *value);
>> int wt_status_use_color;
>> +int wt_status_relative_paths;
>> void wt_status_prepare(struct wt_status *s);
>> void wt_status_print(struct wt_status *s);
>
> Shouldn't both of these ints be marked "extern"? I'm surprised it worked
> at all (or perhaps the part of my brain that stores C linkage issues is
> rotting?).
Yes, rotting very much.
^ permalink raw reply
* Re: [PATCH] add status.relativePaths config variable
From: Junio C Hamano @ 2007-12-08 8:14 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Schindelin, Thomas Harning, git
In-Reply-To: <20071208075538.GA4812@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Fri, Dec 07, 2007 at 11:34:14PM -0800, Junio C Hamano wrote:
> ...
>> I have been wondering ever since receiving this patch if this is a good
>> interface change. Was there a problem if instead:
>>
>> - The implementation of wt_status_prepare(&s) stays as before;
>>
>> - run_status(), after calling wt_status_prepare(&s), notices the
>> configuration variable, and sets s.prefix conditionally;
>
> That would work fine. My reasoning was: the point of wt_status_prepare
> is to initialize the wt_status object.
Yes, just like diffopts and revs. They initialize the object to a plain
vanilla defaults, and the caller uses other methods (either direct
assignments to members or by calling helper functions such as
diff_opt_parse() and setup_revisions()) to fill in specialized values.
And s.prefix is very much special case. That's the reasoning behind my
suggestion.
> ..., which is a little silly, since as a side effect we will do a find
> on all untracked files).
Ah, that is probably the side effect of direct rewrite from shell script
to C. We should drop that and replace with what Alex did recently to
git-commit --no-edit codepath.
> I am fine with either; your call. Documentation patch is below.
Thanks. Will take it.
^ permalink raw reply
* Re: [PATCH] Calculate $commitsha1 in update() only when needed
From: Junio C Hamano @ 2007-12-08 8:17 UTC (permalink / raw)
To: Pavel Roskin; +Cc: git
In-Reply-To: <20071208050745.29462.74137.stgit@dv.roinet.com>
Pavel Roskin <proski@gnu.org> writes:
> diff --git a/git-cvsserver.perl b/git-cvsserver.perl
> index ecded3b..409b301 100755
> --- a/git-cvsserver.perl
> +++ b/git-cvsserver.perl
> @@ -2427,9 +2427,6 @@ sub update
> # first lets get the commit list
> $ENV{GIT_DIR} = $self->{git_path};
>
> - my $commitsha1 = `git rev-parse $self->{module}`;
> - chomp $commitsha1;
> -
> my $commitinfo = `git cat-file commit $self->{module} 2>&1`;
> unless ( $commitinfo =~ /tree\s+[a-zA-Z0-9]{40}/ )
> {
Hmm. The first rev-parse could be squelched with 2>/dev/null and then
you can check if it does not match [a-f0-9]{40} and die early before
running "cat-file commit", can't you?
Also the regexp to check "tree" object name above seems quite wrong ;-)
If the purpose of this check is to make sure if the ref points at a
commit object, perhaps...
my $commitsha1 = `git rev-parse --verify $self->{module}^0 2>&1`;
chomp($commitsha1);
if ($commitsha1 !~ /^[0-9a-f]{40}$/) {
die "no such module $self->{module}";
}
Then the other hunk below would become unnecessary, I think.
> @@ -2440,8 +2437,13 @@ sub update
> my $git_log;
> my $lastcommit = $self->_get_prop("last_commit");
>
> - if (defined $lastcommit && $lastcommit eq $commitsha1) { # up-to-date
> - return 1;
> + if (defined $lastcommit) {
> + my $commitsha1 = `git rev-parse $self->{module}`;
> + chomp $commitsha1;
> +
> + if ($lastcommit eq $commitsha1) { # up-to-date
> + return 1;
> + }
> }
>
> # Start exclusive lock here...
^ permalink raw reply
* [OT] perhaps we want to support copied-context diff output
From: Junio C Hamano @ 2007-12-08 8:18 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git, Jon Smirl
In-Reply-To: <alpine.LFD.0.99999.0712072357050.555@xanadu.home>
The patch looks correct, but I have an offtopic comment that does not
have anything to do with the problem being discussed right now.
Nicolas Pitre <nico@cam.org> writes:
> diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
> index 4f44658..5002cc6 100644
> --- a/builtin-pack-objects.c
> +++ b/builtin-pack-objects.c
> @@ -1245,28 +1245,37 @@ static void get_object_details(void)
> ...
> static int type_size_sort(const void *_a, const void *_b)
> {
> const struct object_entry *a = *(struct object_entry **)_a;
> const struct object_entry *b = *(struct object_entry **)_b;
>
> - if (a->type < b->type)
> - return -1;
> if (a->type > b->type)
> - return 1;
> - if (a->hash < b->hash)
> return -1;
> - if (a->hash > b->hash)
> + if (a->type < b->type)
> return 1;
> - if (a->preferred_base < b->preferred_base)
> + if (a->hash > b->hash)
> return -1;
> - if (a->preferred_base > b->preferred_base)
> + if (a->hash < b->hash)
> return 1;
> - if (a->size < b->size)
> + if (a->preferred_base > b->preferred_base)
> return -1;
> + if (a->preferred_base < b->preferred_base)
> + return 1;
> if (a->size > b->size)
> + return -1;
> + if (a->size < b->size)
> return 1;
> - return a > b ? -1 : (a < b); /* newest last */
> + return a < b ? -1 : (a > b); /* newest first */
> }
Before being able to understand what was going on, I had to shuffle the
above patch by duplicating the context lines, prefix them with '-' and
then '+', and grouping preimage lines and postimage lines together, to
come up with this patch:
static int type_size_sort(const void *_a, const void *_b)
{
const struct object_entry *a = *(struct object_entry **)_a;
const struct object_entry *b = *(struct object_entry **)_b;
- if (a->type < b->type)
- return -1;
- if (a->type > b->type)
- return 1;
- if (a->hash < b->hash)
- return -1;
- if (a->hash > b->hash)
- return 1;
- if (a->preferred_base < b->preferred_base)
- return -1;
- if (a->preferred_base > b->preferred_base)
- return 1;
- if (a->size < b->size)
- return -1;
- if (a->size > b->size)
- return 1;
- return a > b ? -1 : (a < b); /* newest last */
+ if (a->type > b->type)
+ return -1;
+ if (a->type < b->type)
+ return 1;
+ if (a->hash > b->hash)
+ return -1;
+ if (a->hash < b->hash)
+ return 1;
+ if (a->preferred_base > b->preferred_base)
+ return -1;
+ if (a->preferred_base < b->preferred_base)
+ return 1;
+ if (a->size > b->size)
+ return -1;
+ if (a->size < b->size)
+ return 1;
+ return a < b ? -1 : (a > b); /* newest first */
}
Perhaps we may want to add "diff -c" (copied context) output format as
an option, which may be easier to read.
A possible alternative with much less impact to our toolset would be to
stay with unified context format but employ some heuristics (e.g. "a
hunk has many small context lines between preimage and postimage pairs")
and rewrite the diff output automatically like what I did by hand above.
The problematic region has 26 lines, among which 9 lines are deleted
material and 9 lines are added material, and it contains 8 isolated
groups of unchanged material, one line each. A heuristics to notice
such excessively large number of groups of unchanged lines compared to
the size of the hunk itself would be reasonably easy to implement.
^ permalink raw reply
* Re: [PATCH 2/3] git-help: add -w|--web option to display html man page in a browser.
From: Junio C Hamano @ 2007-12-08 8:28 UTC (permalink / raw)
To: Christian Couder
Cc: git, Theodore Tso, Jakub Narebski, Alex Riesen, Andreas Ericsson,
Matthieu Moy, Eric Wong
In-Reply-To: <20071202060755.4d6d5ec8.chriscool@tuxfamily.org>
Christian Couder <chriscool@tuxfamily.org> writes:
> diff --git a/help.c b/help.c
> index 0f1cb71..ecc8c66 100644
> --- a/help.c
> +++ b/help.c
> @@ -265,6 +265,12 @@ static void show_info_page(const char *git_cmd)
> execlp("info", "info", page, NULL);
> }
>
> +static void show_html_page(const char *git_cmd)
> +{
> + const char *page = cmd_to_page(git_cmd);
> + execlp("git-browse-help", "git-browse-help", page, NULL);
> +}
> +
This should be execl_git_cmd() to honor GIT_TRACE and to help transition
to bindir != gitexecdir layout, I think.
^ permalink raw reply
* Re: [PATCH] add status.relativePaths config variable
From: Jeff King @ 2007-12-08 8:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Thomas Harning, git
In-Reply-To: <7v63z9y5k2.fsf@gitster.siamese.dyndns.org>
On Sat, Dec 08, 2007 at 12:05:49AM -0800, Junio C Hamano wrote:
> >> index 225fb4d..63d50f2 100644
> >> --- a/wt-status.h
> >> +++ b/wt-status.h
> >> @@ -28,6 +28,7 @@ struct wt_status {
> >>
> >> int git_status_config(const char *var, const char *value);
> >> int wt_status_use_color;
> >> +int wt_status_relative_paths;
> >> void wt_status_prepare(struct wt_status *s);
> >> void wt_status_print(struct wt_status *s);
> >
> > Shouldn't both of these ints be marked "extern"? I'm surprised it worked
> > at all (or perhaps the part of my brain that stores C linkage issues is
> > rotting?).
>
> Yes, rotting very much.
Nope, there's still a little grey matter left. It is not technically
guaranteed by the standard to work, since the declaration in every
source file which includes wt-status.h is a "tentative definition."
Fortunately, the linker is nice enough to figure out what's going on as
long as only one is actually initialized. This is listed in C99 Section
J.5.11 as a "Common extension".
The Summit C FAQ mentions it as well:
http://c-faq.com/decl/decldef.html
So "extern" is better, but apparently not required for any
linkers we care about. Note that omitting "extern" _is_ illegal in C++,
but fortunately we _really_ don't care about those linkers. :)
But at least I'm not totally crazy.
-Peff
^ permalink raw reply
* Re: [PATCH] Calculate $commitsha1 in update() only when needed
From: Pavel Roskin @ 2007-12-08 8:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vtzmtwqff.fsf@gitster.siamese.dyndns.org>
Quoting Junio C Hamano <gitster@pobox.com>:
> Pavel Roskin <proski@gnu.org> writes:
>
>> diff --git a/git-cvsserver.perl b/git-cvsserver.perl
>> index ecded3b..409b301 100755
>> --- a/git-cvsserver.perl
>> +++ b/git-cvsserver.perl
>> @@ -2427,9 +2427,6 @@ sub update
>> # first lets get the commit list
>> $ENV{GIT_DIR} = $self->{git_path};
>>
>> - my $commitsha1 = `git rev-parse $self->{module}`;
>> - chomp $commitsha1;
>> -
>> my $commitinfo = `git cat-file commit $self->{module} 2>&1`;
>> unless ( $commitinfo =~ /tree\s+[a-zA-Z0-9]{40}/ )
>> {
>
> Hmm. The first rev-parse could be squelched with 2>/dev/null and then
> you can check if it does not match [a-f0-9]{40} and die early before
> running "cat-file commit", can't you?
Yes, my impression is that the code in question can be improved a lot.
This is specifically the error message I'd like to see fixed in some
way, as it's confusing to beginners trying to check out the module for
the first time.
$ CVS_SERVER=/home/proski/bin/git-cvsserver cvs -d \
:fork:/home/proski/src/qgit/.git co foo
fatal: ambiguous argument 'foo': unknown revision or path not in the
working tree.
Use '--' to separate paths from revisions
Invalid module 'foo' at /home/proski/bin/git-cvsserver line 2437,
<STDIN> line 15.
cvs [checkout aborted]: end of file from server (consult above
messages if any)
It's possible that the message about "--" makes sense and it should
actually be added in some spaces.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: [OT] perhaps we want to support copied-context diff output
From: Mike Hommey @ 2007-12-08 8:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nicolas Pitre, git, Jon Smirl
In-Reply-To: <7vmyslwqdr.fsf@gitster.siamese.dyndns.org>
> Perhaps we may want to add "diff -c" (copied context) output format as
> an option, which may be easier to read.
Or maybe use the patience diff.
On a testcase I had a few months ago, patience diff would give:
@@ -42,11 +42,10 @@
include $(DEPTH)/config/autoconf.mk
+EXTRA_COMPONENTS = nsKillAll.js
+
include $(topsrcdir)/config/rules.mk
-libs::
- $(INSTALL) $(srcdir)/nsKillAll.js $(DIST)/bin/components
-
clean::
rm -f $(DIST)/bin/components/nsKillAll.js
Where "normal" diff would give:
@@ -42,10 +42,9 @@
include $(DEPTH)/config/autoconf.mk
-include $(topsrcdir)/config/rules.mk
+EXTRA_COMPONENTS = nsKillAll.js
-libs::
- $(INSTALL) $(srcdir)/nsKillAll.js $(DIST)/bin/components
+include $(topsrcdir)/config/rules.mk
clean::
rm -f $(DIST)/bin/components/nsKillAll.js
git outputs the same as the normal diff, bzr and svn seem to use the
patience diff. Mercurial outputs almost the same as bzr and svn:
@@ -42,10 +42,9 @@
include $(DEPTH)/config/autoconf.mk
+EXTRA_COMPONENTS = nsKillAll.js
+
include $(topsrcdir)/config/rules.mk
-
-libs::
- $(INSTALL) $(srcdir)/nsKillAll.js $(DIST)/bin/components
clean::
rm -f $(DIST)/bin/components/nsKillAll.js
Mike
^ permalink raw reply
* Re: [RFC/PATCH] Add a --nosort option to pack-objects
From: Mike Hommey @ 2007-12-08 8:54 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.LFD.0.99999.0712071707250.555@xanadu.home>
On Fri, Dec 07, 2007 at 05:20:59PM -0500, Nicolas Pitre wrote:
> On Fri, 7 Dec 2007, Mike Hommey wrote:
>
> > As you can seen from my other message, I'm *actually* not sure this is
> > really material for git as a VCS. I will add documentation unrelated to
> > --nosort to pack-objects anyways.
>
> Well, I have serious doubts about this patch in the first place.
>
> I think it is simply unneeded.
>
> If you want pack-objects not to change the sort order because you have
> some sorting of your own, externally implemented, then you simply have
> to run git-pack-objects feeding it the list of object SHA1s along with a
> tag of your own which will effectively impose the sorting you want,
> based on that tag.
>
> Objects with the same tag will still be sorted amongst themselves which
> is still a good thing.
>
> for example, you may have something like:
>
> git rev-list --all --objects |
> sed -e 's|foo/logs/.*|LOGS|' |
> git pack-objects ...
>
> This will effectively cluster all foo/logs/* files together for delta
> compression regardless of their actual name. Maybe that's what you
> really want?
I've been thinking about this, but I'm not sure the list won't be
mixed up with the rest of the sort... I'll just try to see what the
sorted list look like...
Mike
^ permalink raw reply
* [PATCH] git-status: documentation improvements
From: Jeff King @ 2007-12-08 9:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
This patch is the result of reading over git-status with an
editorial eye:
- fix a few typo/grammatical errors
- mention untracked output
- present output types in the order they appear from the
command
Signed-off-by: Jeff King <peff@peff.net>
---
This is on top of the documentation patch I sent a few minutes ago.
Documentation/git-status.txt | 25 +++++++++++++------------
1 files changed, 13 insertions(+), 12 deletions(-)
diff --git a/Documentation/git-status.txt b/Documentation/git-status.txt
index 645dc85..a1bb9bd 100644
--- a/Documentation/git-status.txt
+++ b/Documentation/git-status.txt
@@ -12,21 +12,22 @@ SYNOPSIS
DESCRIPTION
-----------
-Examines paths in the working tree that has changes unrecorded
-to the index file, and changes between the index file and the
-current HEAD commit. The former paths are what you _could_
-commit by running 'git add' before running 'git
-commit', and the latter paths are what you _would_ commit by
-running 'git commit'.
-
-If there is no path that is different between the index file and
-the current HEAD commit, the command exits with non-zero
-status.
+Displays paths that have differences between the index file and the
+current HEAD commit, paths that have differences between the working
+tree and the index file, and paths in the working tree that are not
+tracked by git (and are not ignored by gitlink:gitignore[5]). The first
+are what you _would_ commit by running `git commit`; the second and
+third are what you _could_ commit by running `git add` before running
+`git commit`.
The command takes the same set of options as `git-commit`; it
shows what would be committed if the same options are given to
`git-commit`.
+If there is no path that is different between the index file and
+the current HEAD commit (i.e., there is nothing to commit by running
+`git-commit`), the command exits with non-zero status.
+
If any paths have been touched in the working tree (that is,
their modification times have changed) but their contents and
permissions are identical to those in the index file, the command
@@ -38,10 +39,10 @@ contains many paths that have been touched but not modified.
OUTPUT
------
The output from this command is designed to be used as a commit
-template comments, and all the output lines are prefixed with '#'.
+template comment, and all the output lines are prefixed with '#'.
The paths mentioned in the output, unlike many other git commands, are
-made relative to the current directory, if you are working in a
+made relative to the current directory if you are working in a
subdirectory (this is on purpose, to help cutting and pasting). See
the status.relativePaths config option below.
--
1.5.3.7.2187.gb646
^ permalink raw reply related
* Re: [PATCH 2/2] pack-objects: fix threaded load balancing
From: Jeff King @ 2007-12-08 9:18 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, git, Jon Smirl
In-Reply-To: <alpine.LFD.0.99999.0712080000120.555@xanadu.home>
On Sat, Dec 08, 2007 at 12:03:17AM -0500, Nicolas Pitre wrote:
> This patch implements a completely different approach by initially
> splitting the work in large chunks uniformly amongst all threads, and
> whenever a thread is done then it steals half of the remaining work from
> another thread with the largest amount of unprocessed objects.
Yay! This works great on my "pack a few hundred very large objects" repo.
-Peff
^ permalink raw reply
* Re: [PATCH 2/2] shortlog: code restruturing and clean-up
From: Wincent Colaiuta @ 2007-12-08 9:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1197077573-14945-2-git-send-email-gitster@pobox.com>
El 8/12/2007, a las 2:32, Junio C Hamano escribió:
> The code tried to parse and clean-up the author name and the one line
> information in three places (two callers of insert_author_oneline()
> and
> the called function itself), whihc was a mess.
whihc -> which
Cheers,
Wincent
^ permalink raw reply
* Re: git guidance
From: Al Boldi @ 2007-12-08 10:41 UTC (permalink / raw)
To: Valdis.Kletnieks
Cc: Jakub Narebski, Andreas Ericsson, Johannes Schindelin,
Phillip Susi, Linus Torvalds, Jing Xue, linux-kernel, git
In-Reply-To: <7135.1197090987@turing-police.cc.vt.edu>
Valdis.Kletnieks@vt.edu wrote:
> On Sat, 08 Dec 2007 07:56:21 +0300, Al Boldi said:
> > It probably goes without saying, that gitfs should have some basic
> > configuration file to setup its transparent behaviour
>
> But then it's not *truly* transparent, is it?
Don't mistake transparency with some form of auto-heuristic. Transparency
only means that it inserts functionality without impeding your normal
workflow.
> And that leaves another question - if you make a config file that excludes
> all the .o files - then what's backing the .o files? Those data blocks
> need to be *someplace*. Maybe you can do something ugly like use unionfs
> to combine your gitfs with something else to store the other files...
Or any number of other possible implementation scenarios...
> But at that point, you're probably better off just creating a properly
> designed versioning filesystem.
But gitfs is not about designing a versioning filesystem, it's about
designing a transparent interface into git to handle an SCM use-case.
Thanks!
--
Al
^ permalink raw reply
* Re: XML parsing error from gitweb at freedesktop.org
From: Jakub Narebski @ 2007-12-08 10:49 UTC (permalink / raw)
To: Lars Hjemli; +Cc: Adam Mercer, git
In-Reply-To: <8c5c35580712061411k7a40a08el35f31c43add25cb3@mail.gmail.com>
"Lars Hjemli" <hjemli@gmail.com> writes:
> On Dec 6, 2007 10:34 PM, Adam Mercer <ramercer@gmail.com> wrote:
>>
>> as cgit displays the commit OK
>>
>> <http://cgit.freedesktop.org/xorg/xserver/commit/?h=xorg-server-1.2-apple&id=48e6a75fbdd0fee86e364f02ace83f20b312a2b2>
>>
>> leads me to think that the problem lies in gitweb. Could this be a
>> problem with gitweb?
>>
>
> Actually, it's a problem in both cgit and gitweb, but you need to look
> a bit harder to find the error in cgit. It seems that gitweb on
> freedesktop.org doesn't detect a file rename (due to diff.renamelimit
> maybe?), so it shows the full source of the offending files, while in
> cgit you'll need to go from the diff to either the old or the new
> sourcefile to get the same error:
>
> http://cgit.freedesktop.org/xorg/xserver/tree/hw/darwin/quartz/applewmExt.h?h=xorg-server-1.2-apple&id=141f69dc3d8d6e7d8ff65607f43700ac11243041
> http://cgit.freedesktop.org/xorg/xserver/diff/hw/xquartz/applewm.c?h=xorg-server-1.2-apple&id=48e6a75fbdd0fee86e364f02ace83f20b312a2b2
>
> The problem is a number of unencoded ascii char 12.
Strange... I have checked gitweb code, and esc_html used in HTML
version of diff output escapes _all_ control characters ([:cntrl:]).
So ASCII char 12 should be shown as \014 in "cntrl" style.
Ahhh... I see, Freedesktop.org uses some ANCIENT version of gitweb,
from before it was included in git repository.
Try to ask Freedesktop.org admins to upgrade gitweb. Some nice
features include:
* mod_perl compatibility
* ability to display binary files correctly
* gitweb do not use /usr/bin/diff, and do not use temporary files
(and supports renames, typechanges and combined diff format)
* better support for strange characters in contents and in pathnames
* very basic support for submodules
* snapshot support (optional)
* forks support (optional)
* 'next' links in 'commit' and 'commitdiff' view
* optional features: commit search, pickaxe search, snapshots
support,...
--
Jakub Narebski
ShadeHawk on #git
^ permalink raw reply
* Re: Some git performance measurements..
From: Johannes Schindelin @ 2007-12-08 11:05 UTC (permalink / raw)
To: Mike Ralphson
Cc: Steffen Prohaska, Junio C Hamano, Nicolas Pitre, Linus Torvalds,
Jakub Narebski, Git Mailing List
In-Reply-To: <e2b179460712071115k369dddcatb0f6456d0028acbb@mail.gmail.com>
Hi,
On Fri, 7 Dec 2007, Mike Ralphson wrote:
> On Dec 7, 2007 6:37 PM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > On Fri, 7 Dec 2007, Mike Ralphson wrote:
> >
> > > On Dec 7, 2007 1:49 PM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > > > On Fri, 7 Dec 2007, Mike Ralphson wrote:
> > > >
> > > > > I benchmarked 3 alternative qsorts, qsortG [2] was the fastest
> > > > > on my system but has funky licensing, the NetBSD qsort was
> > > > > middle-range and the glibc one the slowest of the three (but
> > > > > that could be due to it being tuned for a "Sun 4/260"). All of
> > > > > them show over 100x speed improvements on a git-status of my
> > > > > main repo (104s -> ~0.7s)
> > > >
> >
> > Okay, sorry, I did not bother reading further when I read "You may use
> > it in anything you like;".
> >
> > But if the author did not respond, it might be a better idea to just
> > reimplement it.
> >
>
> I've just tried the mergesort implementation as used in msysgit and that
> performs faster for me. It's simpler, and compatibly licensed. It looks
> good.
Now I'm confused. You said you tested qsortG, NetBSD qsort and qlibc,
with glibc performing the slowest. Now, 4msysgit's implementation is
based on glibc (Thanks Brian!), so I wonder if you could redo the
performance tests and say if qsortG still is substantially faster than
4msysgit's qsort?
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