* Re: [PATCH 3/3] Remove unsupported C99 style struct initializers in git-archive.
From: Shawn Pearce @ 2006-11-05 7:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd582uz5b.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
>
> > +static struct archiver_desc
> > +{
> > + const char *name;
> > + write_archive_fn_t write_archive;
> > + parse_extra_args_fn_t parse_extra;
> > +} archivers[] = {
> > + { "tar", write_tar_archive, NULL },
> > + { "zip", write_zip_archive, parse_extra_zip_args },
> > };
>
> If this were a struct with bazillions of fields I might have had
> trouble swallowing the change, but this is so small that it is
> no brainer.
Right; if it was larger I would have been in trouble. :-)
> I think this actually is an improvement.
>
> > static int run_remote_archiver(const char *remote, int argc,
> > @@ -88,7 +86,10 @@ static int init_archiver(const char *nam
> >
> > for (i = 0; i < ARRAY_SIZE(archivers); i++) {
> > if (!strcmp(name, archivers[i].name)) {
> > - memcpy(ar, &archivers[i], sizeof(struct archiver));
> > + memset(ar, 0, sizeof(*ar));
> > + ar->name = archivers[i].name;
> > + ar->write_archive = archivers[i].write_archive;
> > + ar->parse_extra = archivers[i].parse_extra;
>
> But is this change really needed? Shouldn't a structure
> assignment just work?
No, they are different structs...
Which I did to reduce the size of the initializer (see above)
so that it was a no brainer for you to swallow. :-)
--
^ permalink raw reply
* Re: [PATCH 3/3] Remove unsupported C99 style struct initializers in git-archive.
From: Junio C Hamano @ 2006-11-05 7:32 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20061105053723.GC4193@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> +static struct archiver_desc
> +{
> + const char *name;
> + write_archive_fn_t write_archive;
> + parse_extra_args_fn_t parse_extra;
> +} archivers[] = {
> + { "tar", write_tar_archive, NULL },
> + { "zip", write_zip_archive, parse_extra_zip_args },
> };
If this were a struct with bazillions of fields I might have had
trouble swallowing the change, but this is so small that it is
no brainer.
I think this actually is an improvement.
> static int run_remote_archiver(const char *remote, int argc,
> @@ -88,7 +86,10 @@ static int init_archiver(const char *nam
>
> for (i = 0; i < ARRAY_SIZE(archivers); i++) {
> if (!strcmp(name, archivers[i].name)) {
> - memcpy(ar, &archivers[i], sizeof(struct archiver));
> + memset(ar, 0, sizeof(*ar));
> + ar->name = archivers[i].name;
> + ar->write_archive = archivers[i].write_archive;
> + ar->parse_extra = archivers[i].parse_extra;
But is this change really needed? Shouldn't a structure
assignment just work?
^ permalink raw reply
* [PATCH 2/2] Remove SIMPLE_PROGRAMS and make git-daemon a normal program.
From: Shawn O. Pearce @ 2006-11-05 7:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vveluuzzi.fsf@assigned-by-dhcp.cox.net>
Some platforms (Solaris in particular) appear to require -lz as
part of the link line for git-daemon, due to it linking against
sha1_file.o and that module requiring inflate/deflate support.
So its time to retire SIMPLE_PROGRAMS and move its last remaining
member into the standard PROGRAMS list, allowing it to link against
all libraries used by the rest of Git.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
My earlier git-daemon -lz fix, but rewritten to address
Junio's suggestion of just removing SIMPLE_PROGRAMS...
Makefile | 14 ++------------
1 files changed, 2 insertions(+), 12 deletions(-)
diff --git a/Makefile b/Makefile
index 1cc9f58..7c3860a 100644
--- a/Makefile
+++ b/Makefile
@@ -187,15 +187,12 @@ SCRIPTS = $(patsubst %.sh,%,$(SCRIPT_SH)
$(patsubst %.py,%,$(SCRIPT_PYTHON)) \
git-cherry-pick git-status git-instaweb
-# The ones that do not have to link with lcrypto, lz nor xdiff.
-SIMPLE_PROGRAMS = \
- git-daemon$X
-
# ... and all the rest that could be moved out of bindir to gitexecdir
PROGRAMS = \
git-convert-objects$X git-fetch-pack$X git-fsck-objects$X \
git-hash-object$X git-index-pack$X git-local-fetch$X \
git-merge-base$X \
+ git-daemon$X \
git-merge-index$X git-mktag$X git-mktree$X git-patch-id$X \
git-peek-remote$X git-receive-pack$X \
git-send-pack$X git-shell$X \
@@ -217,7 +214,7 @@ BUILT_INS = \
$(patsubst builtin-%.o,git-%$X,$(BUILTIN_OBJS))
# what 'all' will build and 'install' will install, in gitexecdir
-ALL_PROGRAMS = $(PROGRAMS) $(SIMPLE_PROGRAMS) $(SCRIPTS) \
+ALL_PROGRAMS = $(PROGRAMS) $(SCRIPTS) \
git-merge-recur$X
# Backward compatibility -- to be removed after 1.0
@@ -486,11 +483,9 @@ ifdef NEEDS_LIBICONV
endif
ifdef NEEDS_SOCKET
EXTLIBS += -lsocket
- SIMPLE_LIB += -lsocket
endif
ifdef NEEDS_NSL
EXTLIBS += -lnsl
- SIMPLE_LIB += -lnsl
endif
ifdef NO_D_TYPE_IN_DIRENT
BASIC_CFLAGS += -DNO_D_TYPE_IN_DIRENT
@@ -737,11 +732,6 @@ endif
git-%$X: %.o $(GITLIBS)
$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) $(LIBS)
-$(SIMPLE_PROGRAMS) : $(LIB_FILE)
-$(SIMPLE_PROGRAMS) : git-%$X : %.o
- $(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \
- $(LIB_FILE) $(SIMPLE_LIB)
-
ssh-pull.o: ssh-fetch.c
ssh-push.o: ssh-upload.c
git-local-fetch$X: fetch.o
--
^ permalink raw reply related
* [PATCH 1/2] Use ULONG_MAX rather than implicit cast of -1.
From: Shawn O. Pearce @ 2006-11-05 7:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20061105071805.GA4506@spearce.org>
At least one (older) version of the Solaris C compiler won't allow
'unsigned long x = -1' without explicitly casting -1 to a type of
unsigned long. So instead use ULONG_MAX, which is really the
correct constant anyway.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
This is a resend of my earlier patch in in this same thread...
builtin-apply.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin-apply.c b/builtin-apply.c
index db7cdce..aad5526 100644
--- a/builtin-apply.c
+++ b/builtin-apply.c
@@ -43,7 +43,7 @@ static int apply_verbosely;
static int no_add;
static int show_index_info;
static int line_termination = '\n';
-static unsigned long p_context = -1;
+static unsigned long p_context = ULONG_MAX;
static const char apply_usage[] =
"git-apply [--stat] [--numstat] [--summary] [--check] [--index] [--cached] [--apply] [--no-add] [--index-info] [--allow-binary-replacement] [--reverse] [--reject] [--verbose] [-z] [-pNUM] [-CNUM] [--whitespace=<nowarn|warn|error|error-all|strip>] <patch>...";
--
1.4.3.3.g9621
^ permalink raw reply related
* Re: [PATCH 1/3] Apply obvious numerical cast for stupid C compilers.
From: Shawn Pearce @ 2006-11-05 7:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v3b8ywewj.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
>
> > At least one (older) version of the Solaris C compiler won't allow
> > 'unsigned long x = -1' without explicitly casting -1 to a type of
> > unsigned long. As annoying as it may be to explicitly perform the
> > cast the compiler is right; -1 is not an unsigned value.
>
> Is the compiler really _right_? The usual integral promotion
> rules should apply if it claims to be a C compiler, I would
> think.
I'm rusty on my C; but I would expect an error if I tried to assign
a clearly negative value into an unsigned value, especially in a
case like this. It could be compiler is wrong, but as a programmer
I'd want to know I wrote something stupid like that, because maybe
the variable should have been signed. :-)
> But I think the code actually wants ULONG_MAX there. Is that
> symbolic constant available at the point of offending
> initialization with the header files we already include, I
> wonder.
Yes, I agree. I almost changed it to ULONG_MAX but didn't since
the original author felt -1 was the better choice here. *shrug*
For what its worth ULONG_MAX works on my Mac OS X system.
Tomorrow when I have access to that "broken" platform again I'll
try ULONG_MAX and see if it compiles there.
--
^ permalink raw reply
* Re: [PATCH 2/3] Include -lz when linking git-daemon.
From: Junio C Hamano @ 2006-11-05 7:14 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20061105053615.GB4193@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> Some platforms (Solaris in particular) appear to require -lz as
> part of the link line for git-daemon, due to it linking against
> sha1_file.o and that module requiring inflate/deflate support.
We once tried to stay away from linking sha1_file into daemon,
but it appears we were not successful.
Honestly speaking, I think SIMPLE_PROGRAMS outlived its
usefulness. How about moving git-daemon to PROGRAMS list and
get rid of SIMPLE_ stuff from the Makefile?
^ permalink raw reply
* Re: [PATCH 1/3] Apply obvious numerical cast for stupid C compilers.
From: Junio C Hamano @ 2006-11-05 7:06 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20061105053544.GA4193@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> At least one (older) version of the Solaris C compiler won't allow
> 'unsigned long x = -1' without explicitly casting -1 to a type of
> unsigned long. As annoying as it may be to explicitly perform the
> cast the compiler is right; -1 is not an unsigned value.
Is the compiler really _right_? The usual integral promotion
rules should apply if it claims to be a C compiler, I would
think.
But I think the code actually wants ULONG_MAX there. Is that
symbolic constant available at the point of offending
initialization with the header files we already include, I
wonder.
In other words, how about this patch instead?
-- >8 --
diff --git a/builtin-apply.c b/builtin-apply.c
index db7cdce..aad5526 100644
--- a/builtin-apply.c
+++ b/builtin-apply.c
@@ -43,7 +43,7 @@ static int apply_verbosely;
static int no_add;
static int show_index_info;
static int line_termination = '\n';
-static unsigned long p_context = -1;
+static unsigned long p_context = ULONG_MAX;
static const char apply_usage[] =
"git-apply [--stat] [--numstat] [--summary] [--check] [--index] [--cached] [--apply] [--no-add] [--index-info] [--allow-binary-replacement] [--reverse] [--reject] [--verbose] [-z] [-pNUM] [-CNUM] [--whitespace=<nowarn|warn|error|error-all|strip>] <patch>...";
^ permalink raw reply related
* [PATCH 2/2] git-svn: don't die on rebuild when --upgrade is specified
From: Eric Wong @ 2006-11-05 5:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Eric Wong
In-Reply-To: <11627058712379-git-send-email-normalperson@yhbt.net>
--copy-remote and --upgrade are rarely (never?) used together,
so if --copy-remote is specified, that means the user really
wanted to copy the remote ref, and we should fail if that fails.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
git-svn.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index cc3335a..4a56f18 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -3139,7 +3139,7 @@ sub copy_remote_ref {
my $ref = "refs/remotes/$GIT_SVN";
if (safe_qx('git-ls-remote', $origin, $ref)) {
sys(qw/git fetch/, $origin, "$ref:$ref");
- } else {
+ } elsif ($_cp_remote && !$_upgrade) {
die "Unable to find remote reference: ",
"refs/remotes/$GIT_SVN on $origin\n";
}
--
1.4.3.3.ga126
^ permalink raw reply related
* [PATCH 1/2] git-svn: avoid printing filenames of files we're not tracking
From: Eric Wong @ 2006-11-05 5:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Eric Wong
This is purely an aesthetic change, we already skip importing of
files that don't affect the subdirectory we import.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
git-svn.perl | 9 ++++-----
1 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index 37ecc51..cc3335a 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -2662,11 +2662,12 @@ sub libsvn_connect {
}
sub libsvn_get_file {
- my ($gui, $f, $rev) = @_;
+ my ($gui, $f, $rev, $chg) = @_;
my $p = $f;
if (length $SVN_PATH > 0) {
return unless ($p =~ s#^\Q$SVN_PATH\E/##);
}
+ print "\t$chg\t$f\n" unless $_q;
my ($hash, $pid, $in, $out);
my $pool = SVN::Pool->new;
@@ -2769,8 +2770,7 @@ sub libsvn_fetch {
$pool->clear;
}
foreach (@amr) {
- print "\t$_->[0]\t$_->[1]\n" unless $_q;
- libsvn_get_file($gui, $_->[1], $rev)
+ libsvn_get_file($gui, $_->[1], $rev, $_->[0]);
}
close $gui or croak $?;
return libsvn_log_entry($rev, $author, $date, $msg, [$last_commit]);
@@ -2848,8 +2848,7 @@ sub libsvn_traverse {
if (defined $files) {
push @$files, $file;
} else {
- print "\tA\t$file\n" unless $_q;
- libsvn_get_file($gui, $file, $rev);
+ libsvn_get_file($gui, $file, $rev, 'A');
}
}
}
--
1.4.3.3.ga126
^ permalink raw reply related
* [PATCH 3/3] Remove unsupported C99 style struct initializers in git-archive.
From: Shawn O. Pearce @ 2006-11-05 5:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
At least one older version of the Solaris C compiler doesn't support
the newer C99 style struct initializers. To allow Git to compile
on those systems use an archive description struct which is easier
to initialize without the C99 struct initializer syntax.
Also since the archives array is not used by anyone other than
archive.c we can make it static.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
archive.h | 2 --
builtin-archive.c | 23 ++++++++++++-----------
2 files changed, 12 insertions(+), 13 deletions(-)
diff --git a/archive.h b/archive.h
index 16dcdb8..6838dc7 100644
--- a/archive.h
+++ b/archive.h
@@ -25,8 +25,6 @@ struct archiver {
parse_extra_args_fn_t parse_extra;
};
-extern struct archiver archivers[];
-
extern int parse_archive_args(int argc,
const char **argv,
struct archiver *ar);
diff --git a/builtin-archive.c b/builtin-archive.c
index 9177379..2df1a84 100644
--- a/builtin-archive.c
+++ b/builtin-archive.c
@@ -15,16 +15,14 @@
static const char archive_usage[] = \
"git-archive --format=<fmt> [--prefix=<prefix>/] [--verbose] [<extra>] <tree-ish> [path...]";
-struct archiver archivers[] = {
- {
- .name = "tar",
- .write_archive = write_tar_archive,
- },
- {
- .name = "zip",
- .write_archive = write_zip_archive,
- .parse_extra = parse_extra_zip_args,
- },
+static struct archiver_desc
+{
+ const char *name;
+ write_archive_fn_t write_archive;
+ parse_extra_args_fn_t parse_extra;
+} archivers[] = {
+ { "tar", write_tar_archive, NULL },
+ { "zip", write_zip_archive, parse_extra_zip_args },
};
static int run_remote_archiver(const char *remote, int argc,
@@ -88,7 +86,10 @@ static int init_archiver(const char *nam
for (i = 0; i < ARRAY_SIZE(archivers); i++) {
if (!strcmp(name, archivers[i].name)) {
- memcpy(ar, &archivers[i], sizeof(struct archiver));
+ memset(ar, 0, sizeof(*ar));
+ ar->name = archivers[i].name;
+ ar->write_archive = archivers[i].write_archive;
+ ar->parse_extra = archivers[i].parse_extra;
rv = 0;
break;
}
--
^ permalink raw reply related
* [PATCH 2/3] Include -lz when linking git-daemon.
From: Shawn O. Pearce @ 2006-11-05 5:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Some platforms (Solaris in particular) appear to require -lz as
part of the link line for git-daemon, due to it linking against
sha1_file.o and that module requiring inflate/deflate support.
This wasn't made platform-specific in the Makefile as the existing
use of -lz in every other (non git-daemon) application is also
not platform-specific.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
Makefile | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/Makefile b/Makefile
index 1cc9f58..9f10054 100644
--- a/Makefile
+++ b/Makefile
@@ -317,6 +317,7 @@ BUILTIN_OBJS = \
GITLIBS = $(LIB_FILE) $(XDIFF_LIB)
EXTLIBS = -lz
+SIMPLE_LIB = -lz
#
# Platform specific tweaks
--
1.4.3.3.g9621
^ permalink raw reply related
* [PATCH 1/3] Apply obvious numerical cast for stupid C compilers.
From: Shawn O. Pearce @ 2006-11-05 5:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
At least one (older) version of the Solaris C compiler won't allow
'unsigned long x = -1' without explicitly casting -1 to a type of
unsigned long. As annoying as it may be to explicitly perform the
cast the compiler is right; -1 is not an unsigned value.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
builtin-apply.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin-apply.c b/builtin-apply.c
index db7cdce..d7b3cea 100644
--- a/builtin-apply.c
+++ b/builtin-apply.c
@@ -43,7 +43,7 @@ static int apply_verbosely;
static int no_add;
static int show_index_info;
static int line_termination = '\n';
-static unsigned long p_context = -1;
+static unsigned long p_context = (unsigned long)-1;
static const char apply_usage[] =
"git-apply [--stat] [--numstat] [--summary] [--check] [--index] [--cached] [--apply] [--no-add] [--index-info] [--allow-binary-replacement] [--reverse] [--reject] [--verbose] [-z] [-pNUM] [-CNUM] [--whitespace=<nowarn|warn|error|error-all|strip>] <patch>...";
--
1.4.3.3.g9621
^ permalink raw reply related
* Re: Bash completion Issue?
From: Shawn Pearce @ 2006-11-05 4:28 UTC (permalink / raw)
To: Alan Chandler; +Cc: git
In-Reply-To: <200611050033.07716.alan@chandlerfamily.org.uk>
Alan Chandler <alan@chandlerfamily.org.uk> wrote:
> Well I have something like this (with git 1.4.3.3)
>
> # 'git' bash completion and library routines used by porcelain completions.
> #
> # Copyright (c) Paolo Giarrusso, 2005
> # Copyright (c) Ben Clifford, 2005
> #
> # The master version is available at:
> # http://www.hawaga.org.uk/gitcompletion.git
Maybe you can nicely ask the Debian maintainer to switch to using
use the completion script that is actually shipped with git 1.4.3.3?
--
^ permalink raw reply
* Re: [PATCH/RFC] Documentation: Two more git-rebase --onto examples
From: Junio C Hamano @ 2006-11-05 1:08 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200611042205.58212.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> I asked for comments because I'm not native English speaker and I'm not
> sure about correctness of descriptions of added examples.
Ok.
> +More useful example of --onto option usage include transplanting feature
> +branch from one development branch to other, for example change to branch
> +based off "next" branch:
By "more" do you mean the following examples are more useful
than the one before, or having larger number of examples adds to
the usefulness of the document overall?
How about:
Here is how you would transplant a topic branch based on one
branch to another, to pretend that you forked the topic branch
from the latter branch, using `rebase --onto`.
First let's assume your 'topic' is based on branch 'next'.
------------
o---o---o---o---o master
\
o---o---o---o---o next
\
o---o---o topic
------------
We would want to make 'topic' forked from branch
'master', like this:
> +------------
> + o---o---o---o---o master
> + | \
> + | o'--o'--o' topic
> + \
> + o---o---o---o---o next
> +------------
> +
> +We can get this using the following command:
> +
> + git-rebase --onto master next topic
> +
> +
> +Yet another example of use for --onto option is to rebase part of
> +branch. If we have the following situation:
This looks the same as the original example for --onto; I would
either drop it or replace it something of different flavor.
What I find myself doing more is to reorder without using StGIT.
When I have this:
1---2---3---4 topic
and 2 is a bit half-baked, and I would want to have:
1---3'--4'--2' topic
I would usually do this while on "topic":
git tag -f CG ;# "commit goal"
git rebase --onto CG~3 CG~2 ;# plant 3 4 on top of 1
git cherry-pick CG~2
git diff CG ;# verify that the result matches
In ascii art, that is:
3'--4'
/
1---2---3---4 CG
then
3'--4'--2' topic
/
1---2---3---4 CG
^ permalink raw reply
* Re: Bash completion Issue?
From: Alan Chandler @ 2006-11-05 0:33 UTC (permalink / raw)
To: git
In-Reply-To: <20061104184120.GB2311@spearce.org>
On Saturday 04 November 2006 18:41, Shawn Pearce wrote:
> Alan Chandler <alan@chandlerfamily.org.uk> wrote:
...
> > In debian, there seems to be a directory /etc/bash_completion.d with
> > files for each of the packages, and the debian git packages have entries
> > in there. So I assume they are derived from the completion work
> > mentioned on this list.
>
> What completion script is it? The one that is now shipped as part
> of Git has a header of the following, and resides in git.git as
> contrib/completion/git-completion.bash:
>
> #
> # bash completion support for core Git.
> #
> # Copyright (C) 2006 Shawn Pearce
> # Conceptually based on gitcompletion (http://gitweb.hawaga.org.uk/).
> #
Well I have something like this (with git 1.4.3.3)
# 'git' bash completion and library routines used by porcelain completions.
#
# Copyright (c) Paolo Giarrusso, 2005
# Copyright (c) Ben Clifford, 2005
#
# The master version is available at:
# http://www.hawaga.org.uk/gitcompletion.git
>
> > What seems strange to me is that nobody else has mentioned this before
> > now.
>
> Maybe because you have a different completion script?
Seems like it might be:-(
--
Alan Chandler
^ permalink raw reply
* Re: If I were redoing git from scratch...
From: Linus Torvalds @ 2006-11-04 23:15 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: Shawn Pearce, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0611041436050.25218@g5.osdl.org>
On Sat, 4 Nov 2006, Linus Torvalds wrote:
>
> In addition to that, we need one pointer per hash entry, and in order to
> keep the hash list size down we need that hash array to be about 25% free,
> so say 1.5 pointers per object: ~6 bytes or ~12 bytes depending on whether
> it's a 32- or 64-bit architecture.
Btw, one of the things I considered (but rejected as being _too_ far out
for now) during the memory shrinking thing was to make both 32-bit and
64-bit entities use a 32-bit hash table entry.
The way to do that would be to instead of using a pointer, use a 32-bit
integer where the low ~10 bits are an index into the allocation buffer
(since we batch allocations), and the rest of the bits would be an index
into which batch-buffer it is.
Exactly because 8 bytes per hash entry is actually right now a big part of
the object memory allocation overhead on 64-bit architectures, and cutting
it down to just 4 bytes would help save memory.
I never got around to it, if only because I actually just compile my
user-land git stuff as 32-bit, even on my ppc64 system. And partly because
I had shrunk the object allocations enough that I just felt pretty happy
with it anyway, and the change would have been pretty painful. But on
64-bit architectures, the hash table right now is about a third of the
whole memory overhead of the object database, and cutting it down by half
would actually be noticeable.
^ permalink raw reply
* Re: If I were redoing git from scratch...
From: Linus Torvalds @ 2006-11-04 22:44 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: Shawn Pearce, Junio C Hamano, git
In-Reply-To: <200611042329.46556.robin.rosenberg.lists@dewire.com>
On Sat, 4 Nov 2006, Robin Rosenberg wrote:
>
> The overhead is eigth bytes per object on a 32-bit platform and 16 on a 64-bit
> platform for Sun's JDK. The granularity is eight bytes in both cases.
Note that the object structure itself is just 24 bytes (regardless of
whether we're on a 32-bit or 64-bit architecture).
In addition to that, we need one pointer per hash entry, and in order to
keep the hash list size down we need that hash array to be about 25% free,
so say 1.5 pointers per object: ~6 bytes or ~12 bytes depending on whether
it's a 32- or 64-bit architecture.
So 8 or 16 bytes overhead per object is roughly a 25% or 50% pure
overhead. In contrast, right now we have pretty much _zero_ overhead (we
do end up having some malloc cost, but since we batch them, it's on the
order of a few bytes per _thousand_ objects, so we're talking fractions of
a percent).
Of course, the memory footprint isn't _just_ the objects, but it's a big
part of it, for some important apps (not just repack, but git-send-pack
obviously also has this). So on a git server, keeping the memory use down
is likely the #1 concern - even if the server might have gigabytes of RAM.
^ permalink raw reply
* Re: If I were redoing git from scratch...
From: Robin Rosenberg @ 2006-11-04 22:29 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Linus Torvalds, Junio C Hamano, git
In-Reply-To: <20061104191651.GC2517@spearce.org>
lördag 04 november 2006 20:16 skrev Shawn Pearce:
> But trying to abstractly represent an object in Java the same
> way that it is represented in Git costs a huge amount of memory.
> Java is at least 16 bytes of overhead per object, before you get to
> store anything in it.
The overhead is eigth bytes per object on a 32-bit platform and 16 on a 64-bit
platform for Sun's JDK. The granularity is eight bytes in both cases.
^ permalink raw reply
* [PATCH/RFC] Documentation: Two more git-rebase --onto examples
From: Jakub Narebski @ 2006-11-04 21:05 UTC (permalink / raw)
To: git
Added example of transplantig feature branch from one development
branch (for example "next") into the other development branch (for
example "master").
Added example of rebasing part of branch, or transplanting feature
branch from the tip of other feature branch to the development branch
the second feature branch started from.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
I asked for comments because I'm not native English speaker and I'm not
sure about correctness of descriptions of added examples.
P.S. Perhaps we should separate the part dealing with CONFLICT(contents)
into separate documentation file, and include it as needed (for example
alsop in git-push(1)).
Documentation/git-rebase.txt | 55 ++++++++++++++++++++++++++++++++++++++++++
1 files changed, 55 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
index 10f2924..1308d2f 100644
--- a/Documentation/git-rebase.txt
+++ b/Documentation/git-rebase.txt
@@ -65,6 +65,61 @@ would be:
D---E---F---G master
------------
+More useful example of --onto option usage include transplanting feature
+branch from one development branch to other, for example change to branch
+based off "next" branch:
+
+------------
+ o---o---o---o---o master
+ \
+ o---o---o---o---o next
+ \
+ o---o---o topic
+------------
+
+to being a branch based off "master" branch as shown below:
+
+------------
+ o---o---o---o---o master
+ | \
+ | o'--o'--o' topic
+ \
+ o---o---o---o---o next
+------------
+
+We can get this using the following command:
+
+ git-rebase --onto master next topic
+
+
+Yet another example of use for --onto option is to rebase part of
+branch. If we have the following situation:
+
+------------
+ H---I---J topicB
+ /
+ E---F---G topicA
+ /
+ A---B---C---D master
+------------
+
+then the command
+
+ git-rebase --onto master topicA topicB
+
+would give us the following situation:
+
+------------
+ H'--I'--J' topicB
+ /
+ | E---F---G topicA
+ |/
+ A---B---C---D master
+------------
+
+with "topicB" branch based off "master".
+
+
In case of conflict, git-rebase will stop at the first problematic commit
and leave conflict markers in the tree. You can use git diff to locate
the markers (<<<<<<) and make edits to resolve the conflict. For each
--
1.4.3.3
^ permalink raw reply related
* Re: If I were redoing git from scratch...
From: Shawn Pearce @ 2006-11-04 19:16 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0611040829040.25218@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> wrote:
> or for somebody who re-implements git in Java (where
> performance isn't going to be the major issue anyway, and you probably do
> "small" things like "commit" and "diff", and never do full-database things
> like "git repack"), _then_ you can happily look at having something
> fancier. Right now, it's too easy to just look at cumbersome interfaces,
> and forget about the fact that those interfaces is sometimes what allows
> us to practically do some things in the first place.
Yes and no. :-)
As the only person here who has hacked on some of Git and also
reimplemented the core on disk data structures in Java I can say
I mostly agree with Linus.
Abstractions like the repository (to allow different GIT_DIRs to
be used in the same process) isn't really a big deal and is not
a large impact on performance. They could be implemented in the
current C core.
But trying to abstractly represent an object in Java the same
way that it is represented in Git costs a huge amount of memory.
Java is at least 16 bytes of overhead per object, before you get to
store anything in it. Translation: Linus is right, doing a real
implementation of "git repack" in Java is nuts. It would barely
be able to handle git.git, let alone linux.git or mozilla.git.
--
^ permalink raw reply
* Re: git bug? + question
From: Shawn Pearce @ 2006-11-04 19:07 UTC (permalink / raw)
To: Sean; +Cc: Junio C Hamano, git, Miles Bader, Karl Hasselström
In-Reply-To: <20061104103325.bfb5e33e.seanlkml@sympatico.ca>
Sean <seanlkml@sympatico.ca> wrote:
> All that remains is coming to some consensus on which set of options
> should be enabled for new Git users. Once someone is up to speed, they
> can enable whichever options support their workflow. But once they've
> enabled those options, Git should do it's best to support that workflow
> without a lot of manual intervention most of the time. That's what
> the options I was suggesting would do for some workflows.
Agreed.
Since I already have to spell out the entire clone command line
(including URL) for my users asking them to also include a few
options (such as the hypothetical "--only vmdvt,vmtip -n") is not
a problem. As in my workflow could be in the more "advanced user"
category. :-)
--
^ permalink raw reply
* Re: git bug? + question
From: Shawn Pearce @ 2006-11-04 19:05 UTC (permalink / raw)
To: Josef Weidendorfer
Cc: Sean, Junio C Hamano, Miles Bader, git, Karl Hasselström
In-Reply-To: <200611041852.23867.Josef.Weidendorfer@gmx.de>
Josef Weidendorfer <Josef.Weidendorfer@gmx.de> wrote:
> On Saturday 04 November 2006 06:03, Shawn Pearce wrote:
> > After reading your reply you are probably correct. I can see there
> > may be workflows that want every remote branch also created as a
> > local branch.
> >
> > I could certainly live with a command line option to clone, e.g.:
> >
> > git clone --only vmdvt,vmtip user@host:/path...
>
> Still missing here: What branch should be checked out after
> cloning?
Ah.
I probably should have also stated that my users should be doing
-n as well with git clone, then using git checkout -b to create
a new branch from one of the refs they did clone. (Reason is we
strictly follow a topic branch model of development, with even the
developer's local branches beginning with their initials.)
But you have a good point. Cloning with say --only as I show above
might be confusing as its not defined what branch to checkout after
the clone.
> Perhaps it is better to extend git-checkout to allow to do the
> correct thing when the user specifies a read-only branch from
> refs/remotes. E.g. with refs/remotes/origin/vmdvt,
>
> git checkout origin/vmdvt
>
> should create a new local branch refs/heads/vmdvt which forks
> from remotes/origin/vmdvt (and abort with
> error if refs/heads/vmdvt already exists without being the local
> development branch for remotes/origin/vmdvt)
Yes, that would work for our workflow. I won't try to speak about
anyone else's.
I'd also say that if the local branch (refs/heads/vmdvt) exists and
if `git pull . origin/vmdvt` is going to be a fast-forward that the
fast-forward should happen during the checkout. That way after the
checkout is complete you really do have what is in origin/vmdvt,
but are sitting on a local branch.
--
^ permalink raw reply
* [PATCH 2/2] Added bash completion support for git-reset.
From: Shawn O. Pearce @ 2006-11-04 18:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Completion for the --hard/--soft/--mixed modes of operation as
well as a ref name for <commit-ish> can be very useful and save
some fingers.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
contrib/completion/git-completion.bash | 9 +++++++++
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index b7b8a43..a3fbb90 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -271,6 +271,13 @@ _git_push ()
esac
}
+_git_reset ()
+{
+ local cur="${COMP_WORDS[COMP_CWORD]}"
+ local opt="--mixed --hard --soft"
+ COMPREPLY=($(compgen -W "$opt $(__git_refs .)" -- "$cur"))
+}
+
_git_show ()
{
local cur="${COMP_WORDS[COMP_CWORD]}"
@@ -304,6 +311,7 @@ _git ()
ls-tree) _git_ls_tree ;;
pull) _git_pull ;;
push) _git_push ;;
+ reset) _git_reset ;;
show) _git_show ;;
show-branch) _git_log ;;
whatchanged) _git_log ;;
@@ -332,6 +340,7 @@ complete -o default -o nospace -F _git_l
complete -o default -F _git_merge_base git-merge-base
complete -o default -o nospace -F _git_pull git-pull
complete -o default -o nospace -F _git_push git-push
+complete -o default -F _git_reset git-reset
complete -o default -F _git_show git-show
complete -o default -o nospace -F _git_log git-whatchanged
--
^ permalink raw reply related
* [PATCH 1/2] Added completion support for git-branch.exe.
From: Shawn O. Pearce @ 2006-11-04 18:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
On Cygwin a user might complete the new git-branch builtin as
git-branch.exe, at which point bash requires a new completion
registration for the command.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
contrib/completion/git-completion.bash | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index b074f4f..b7b8a43 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -339,6 +339,7 @@ complete -o default -o nospace -F _git_l
# when the user has tab-completed the executable name and consequently
# included the '.exe' suffix.
#
+complete -o default -F _git_branch git-branch.exe
complete -o default -o nospace -F _git_cat_file git-cat-file.exe
complete -o default -o nospace -F _git_diff git-diff.exe
complete -o default -o nospace -F _git_diff_tree git-diff-tree.exe
--
1.4.3.3.g1a30
^ permalink raw reply related
* Re: Bash completion Issue?
From: Shawn Pearce @ 2006-11-04 18:41 UTC (permalink / raw)
To: Alan Chandler; +Cc: git
In-Reply-To: <200611041236.59989.alan@chandlerfamily.org.uk>
Alan Chandler <alan@chandlerfamily.org.uk> wrote:
> When I type a normal command on the bash command line (say emacs) followed by
> the partial directory name the completion completes the directory and then
> adds a slash. If I type a git command (say git update-index) with the same
> partial directory name it completes the directory, but then adds a space. I
> have to backspace, manually add the slash, before continuing with the next
> directory or filename.
Hmm. I just tried 'git update-index' and it completed here for
me as you want it to (this is with the current stock Git bash
completion support).
However we do some funny things when completing into trees. E.g. the
completion support for 'git ls-tree man:man<tab>' may seem a little
strange but it works well for my fingers. I've never really had
any problem with it.
I think the only way we differ from normal bash completion is we
sometimes don't add a space after fully completing a path name.
Usually the user has to type the space in by hand.
> In debian, there seems to be a directory /etc/bash_completion.d with files for
> each of the packages, and the debian git packages have entries in there. So
> I assume they are derived from the completion work mentioned on this list.
What completion script is it? The one that is now shipped as part
of Git has a header of the following, and resides in git.git as
contrib/completion/git-completion.bash:
#
# bash completion support for core Git.
#
# Copyright (C) 2006 Shawn Pearce
# Conceptually based on gitcompletion (http://gitweb.hawaga.org.uk/).
#
> What seems strange to me is that nobody else has mentioned this before now.
Maybe because you have a different completion script?
--
^ 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