* [Q] what to do when waitpid() returns ECHILD under signal(SIGCHLD, SIG_IGN)?
From: Junio C Hamano @ 2006-06-19 23:49 UTC (permalink / raw)
To: git; +Cc: Linus Torvalds
Somebody I met last week in Japan reported that the socks client
he uses to cross the firewall to connect to git:// port from his
company environment seems to do signal(SIGCHLD, SIG_IGN) before
spawning git. When "git clone" is invoked this way, we get a
mysterious failure.
I can reproduce the problem without using funny socks client
like this:
: gitster; trap '' SIGCHLD
: gitster; git clone git://git.kernel.org/pub/scm/git/git.git/ foo.git
error: waitpid failed (No child processes)
fetch-pack from 'git://git.kernel.org/pub/scm/git/git.git/' failed.
: gitster; ls foo.git
ls: foo.git: No such file or directory
We could work this around by having signal(SIGCHLD, SIG_DFL)
upfront in git.c::main(), but I am wondering what the standard
practice for programs that use waitpid() call. Do they protect
themselves from this in order to reliably obtain child exit
status? Or do they simply consider it is a user error to run a
program that use waitpid() with SIGCHLD ignored?
http://www.opengroup.org/onlinepubs/009695399/functions/waitpid.html
explicitly says this is an expected behaviour, so barfing upon
ECHILD sounds like a bug on our part.
^ permalink raw reply
* [PATCH] Read configuration also from $HOME/.gitconfig
From: Johannes Schindelin @ 2006-06-19 23:48 UTC (permalink / raw)
To: git, junkiot
This patch is based on Pasky's, with three notable differences:
- I did not yet update the documentation
- I named it .gitconfig, not .gitrc
- git-repo-config does not barf when a unique key is overridden locally
The last means that if you have something like
[alias]
l = log --stat -M
in ~/.gitconfig, and
[alias]
l = log --stat -M next..
in $GIT_DIR/config, then
git-repo-config alias.l
returns only one value, namely the value from $GIT_DIR/config.
If you set the environment variable GIT_CONFIG, $HOME/.gitconfig is not
read, and neither $GIT_DIR/config, but $GIT_CONFIG instead.
If you set GIT_CONFIG_LOCAL instead, it is interpreted instead of
$GIT_DIR/config, but $HOME/.gitconfig is still read.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
config.c | 34 +++++++++++++++++++++++++---------
repo-config.c | 39 +++++++++++++++++++++++++++++++++------
2 files changed, 58 insertions(+), 15 deletions(-)
diff --git a/config.c b/config.c
index 69aa05f..edbe5ed 100644
--- a/config.c
+++ b/config.c
@@ -317,17 +317,33 @@ int git_config_from_file(config_fn_t fn,
int git_config(config_fn_t fn)
{
- const char *filename = git_path("config");
- /* Forward-compatibility cue: $GIT_CONFIG makes git read _only_
- * the given config file, $GIT_CONFIG_LOCAL will make it process
- * it in addition to the global config file, the same way it would
- * the per-repository config file otherwise. */
- if (getenv("GIT_CONFIG")) {
- filename = getenv("GIT_CONFIG");
- } else if (getenv("GIT_CONFIG_LOCAL")) {
+ int ret = 0;
+ char *repo_config = NULL;
+ const char *home = NULL, *filename;
+
+ /* $GIT_CONFIG makes git read _only_ the given config file,
+ * $GIT_CONFIG_LOCAL will make it process it in addition to the
+ * global config file, the same way it would the per-repository
+ * config file otherwise. */
+ filename = getenv("GIT_CONFIG");
+ if (!filename) {
+ home = getenv("HOME");
filename = getenv("GIT_CONFIG_LOCAL");
+ if (!filename)
+ filename = repo_config = strdup(git_path("config"));
}
- return git_config_from_file(fn, filename);
+
+ if (home) {
+ const char *user_config = strdup(mkpath("%s/.gitconfig", home));
+ if (access(user_config, R_OK) > 0)
+ ret = git_config_from_file(fn, user_config);
+ free(user_config);
+ }
+
+ ret += git_config_from_file(fn, filename);
+ if (repo_config)
+ free(repo_config);
+ return ret;
}
/*
diff --git a/repo-config.c b/repo-config.c
index 08fc4cc..03f108f 100644
--- a/repo-config.c
+++ b/repo-config.c
@@ -64,7 +64,22 @@ static int show_config(const char* key_,
static int get_value(const char* key_, const char* regex_)
{
+ int ret = -1;
char *tl;
+ char *global = NULL, *repo_config = NULL;
+ const char *local;
+
+ local = getenv("GIT_CONFIG");
+ if (!local) {
+ const char *home = getenv("HOME");
+ local = getenv("GIT_CONFIG_LOCAL");
+ if (!local)
+ local = repo_config;
+ else
+ local = repo_config = strdup(git_path("config"));
+ if (home)
+ global = strdup(mkpath("%s/.gitconfig", home));
+ }
key = strdup(key_);
for (tl=key+strlen(key)-1; tl >= key && *tl != '.'; --tl)
@@ -76,7 +91,7 @@ static int get_value(const char* key_, c
key_regexp = (regex_t*)malloc(sizeof(regex_t));
if (regcomp(key_regexp, key, REG_EXTENDED)) {
fprintf(stderr, "Invalid key pattern: %s\n", key_);
- return -1;
+ goto free_strings;
}
}
@@ -89,11 +104,16 @@ static int get_value(const char* key_, c
regexp = (regex_t*)malloc(sizeof(regex_t));
if (regcomp(regexp, regex_, REG_EXTENDED)) {
fprintf(stderr, "Invalid pattern: %s\n", regex_);
- return -1;
+ goto free_strings;
}
}
- git_config(show_config);
+ if (do_all && global)
+ git_config_from_file(show_config, global);
+ git_config_from_file(show_config, local);
+ if (!do_all && !seen && global)
+ git_config_from_file(show_config, global);
+
free(key);
if (regexp) {
regfree(regexp);
@@ -101,9 +121,16 @@ static int get_value(const char* key_, c
}
if (do_all)
- return !seen;
-
- return (seen == 1) ? 0 : 1;
+ ret = !seen;
+ else
+ ret = (seen == 1) ? 0 : 1;
+
+free_strings:
+ if (repo_config)
+ free(repo_config);
+ if (global)
+ free(global);
+ return ret;
}
int main(int argc, const char **argv)
--
1.4.0.g6685
^ permalink raw reply related
* Re: [PATCH] Fix setting config variables with an alternative GIT_CONFIG
From: Johannes Schindelin @ 2006-06-19 23:46 UTC (permalink / raw)
To: git, junkio
In-Reply-To: <Pine.LNX.4.63.0606200050150.26329@wbgn013.biozentrum.uni-wuerzburg.de>
Hi,
On Tue, 20 Jun 2006, Johannes Schindelin wrote:
> + config_filename = getenv("GIT_CONFIG_LOCAL");
> + if (!config_filename) {
> + config_filename = getenv("GIT_CONFIG");
Oops. At the other places, GIT_CONFIG overrides GIT_CONFIG_LOCAL, so these
two must be exchanged in the patch.
Sorry,
Dscho
^ permalink raw reply
* git-svn: don't use the --rmdir feature with SVN libs
From: Eric Wong @ 2006-06-19 23:34 UTC (permalink / raw)
To: git
It's very broken when committing. It's off by default, and somehow my
tests didn't catch it. I'll fix it ASAP tonight.
Sorry if anybody else hit it before I did.
--
Eric Wong
^ permalink raw reply
* [PATCH] Initialize lock_file struct to all zero.
From: Johannes Schindelin @ 2006-06-19 22:55 UTC (permalink / raw)
To: git, junkio
hold_lock_file_for_update() relies on that.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
Bugs like this drive you crazy. You make a little change elsewhere,
and all of a sudden, a test of git-update-index fails (since the
lock file is never removed).
builtin-update-index.c | 2 +-
builtin-write-tree.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/builtin-update-index.c b/builtin-update-index.c
index 325cd09..829ed23 100644
--- a/builtin-update-index.c
+++ b/builtin-update-index.c
@@ -490,7 +490,7 @@ int cmd_update_index(int argc, const cha
git_config(git_default_config);
/* We can't free this memory, it becomes part of a linked list parsed atexit() */
- lock_file = xmalloc(sizeof(struct lock_file));
+ lock_file = xcalloc(1, sizeof(struct lock_file));
newfd = hold_lock_file_for_update(lock_file, get_index_file());
if (newfd < 0)
diff --git a/builtin-write-tree.c b/builtin-write-tree.c
index c3aac36..8c151da 100644
--- a/builtin-write-tree.c
+++ b/builtin-write-tree.c
@@ -16,7 +16,7 @@ int write_tree(unsigned char *sha1, int
int entries, was_valid, newfd;
/* We can't free this memory, it becomes part of a linked list parsed atexit() */
- struct lock_file *lock_file = xmalloc(sizeof(struct lock_file));
+ struct lock_file *lock_file = xcalloc(1, sizeof(struct lock_file));
newfd = hold_lock_file_for_update(lock_file, get_index_file());
--
1.4.0.g9833
^ permalink raw reply related
* [PATCH] Fix setting config variables with an alternative GIT_CONFIG
From: Johannes Schindelin @ 2006-06-19 22:51 UTC (permalink / raw)
To: git, junkio
When setting a config variable, git_config_set() ignored the variables
GIT_CONFIG and GIT_CONFIG_LOCAL. Now, when GIT_CONFIG_LOCAL is set, it
will write to that file. If not, GIT_CONFIG is checked, and only as a
fallback, the change is written to $GIT_DIR/config.
Add a test for it, and also future-proof the test for the upcoming
$HOME/.gitconfig support.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
config.c | 15 ++++++++++++---
t/Makefile | 2 +-
t/t1300-repo-config.sh | 24 ++++++++++++++++++++++++
3 files changed, 37 insertions(+), 4 deletions(-)
diff --git a/config.c b/config.c
index d46eb6d..69aa05f 100644
--- a/config.c
+++ b/config.c
@@ -500,10 +500,19 @@ int git_config_set_multivar(const char*
int i, dot;
int fd = -1, in_fd;
int ret;
- char* config_filename = strdup(git_path("config"));
- char* lock_file = strdup(git_path("config.lock"));
+ char* config_filename;
+ char* lock_file;
const char* last_dot = strrchr(key, '.');
+ config_filename = getenv("GIT_CONFIG_LOCAL");
+ if (!config_filename) {
+ config_filename = getenv("GIT_CONFIG");
+ if (!config_filename)
+ config_filename = git_path("config");
+ }
+ config_filename = strdup(config_filename);
+ lock_file = strdup(mkpath("%s.lock", config_filename));
+
/*
* Since "key" actually contains the section name and the real
* key name separated by a dot, we have to know where the dot is.
@@ -610,7 +619,7 @@ int git_config_set_multivar(const char*
* As a side effect, we make sure to transform only a valid
* existing config file.
*/
- if (git_config(store_aux)) {
+ if (git_config_from_file(store_aux, config_filename)) {
fprintf(stderr, "invalid config file\n");
free(store.key);
if (store.value_regex != NULL) {
diff --git a/t/Makefile b/t/Makefile
index 5495985..632c55f 100644
--- a/t/Makefile
+++ b/t/Makefile
@@ -19,7 +19,7 @@ endif
all: $(T) clean
$(T):
- @echo "*** $@ ***"; '$(SHELL_PATH_SQ)' $@ $(GIT_TEST_OPTS)
+ @echo "*** $@ ***"; GIT_CONFIG=.git/config '$(SHELL_PATH_SQ)' $@ $(GIT_TEST_OPTS)
clean:
rm -fr trash
diff --git a/t/t1300-repo-config.sh b/t/t1300-repo-config.sh
index 8260d57..0de2497 100755
--- a/t/t1300-repo-config.sh
+++ b/t/t1300-repo-config.sh
@@ -309,5 +309,29 @@ EOF
test_expect_success 'new variable inserts into proper section' 'cmp .git/config expect'
+cat > other-config << EOF
+[ein]
+ bahn = strasse
+EOF
+
+cat > expect << EOF
+ein.bahn=strasse
+EOF
+
+GIT_CONFIG=other-config git-repo-config -l > output
+
+test_expect_success 'alternative GIT_CONFIG' 'cmp output expect'
+
+GIT_CONFIG=other-config git-repo-config anwohner.park ausweis
+
+cat > expect << EOF
+[ein]
+ bahn = strasse
+[anwohner]
+ park = ausweis
+EOF
+
+test_expect_success '--set in alternative GIT_CONFIG' 'cmp other-config expect'
+
test_done
--
1.4.0.g275f-dirty
^ permalink raw reply related
* Re: [PATCH] rebase: Allow merge strategies to be used when rebasing
From: Junio C Hamano @ 2006-06-19 21:55 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <20060619213951.GA6987@hand.yhbt.net>
Eric Wong <normalperson@yhbt.net> writes:
> Junio C Hamano <junkio@cox.net> wrote:
>
>> - You kept the original "format-patch piped to am" workflow
>> optionally working.
>
> I left it as the default, too. I figured that it's best not
> to change the default (and most likely faster) behavior of
> something people rely on.
I should have said: "You kept ... working, which is good".
>> I think the three-way merge you would want here is not between B
>> and G using E as the pivot, but between B and G using A as the
>> pivot. That's how cherry-pick and revert works. I would
>> leverage the interface that is one level lower for this -- the
>> strategy modules themselves.
>>
>> git-merge-$strategy $cmt^ -- HEAD $cmt
>
> Changing the 'git-merge $strategy_args "rebase-merge: $cmt" HEAD "$cmt"'
> line in call_merge() to this seems to have broken more tests.
Oh, that is to be expected if you changed git-merge -s recursive
with git-merge-recursive without other changes. The former
makes a commit (which your original patch later used to create a
separate commit chain and discarded); the latter does not make a
commit but expects the caller to create a commit out of the
resulting index file.
> I'm not an expert at merging strategies by any measure, I've just
> trusted merge-recursive to Do The Right Thing(TM) more often than not,
> and use rerere to avoid repeating work.
I was originally hoping that rebasing would just be a matter of
listing sequence of commits to be ported onto a new base and
running "git-cherry-pick" on each of them in sequence. Now
cherry-pick does not use merge machinery (hence does not use
git-merge-recursive), but if we change that then updating rebase
would be pretty much straightforward. It just needs a UI layer
to guide the user through recovery process when the merge does
not resolve cleanly in the middle, no?
^ permalink raw reply
* Re: [PATCH] rebase: Allow merge strategies to be used when rebasing
From: Eric Wong @ 2006-06-19 21:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd5d63k7f.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Eric Wong <normalperson@yhbt.net> writes:
>
> > This solves the problem of rebasing local commits against an
> > upstream that has renamed files.
>
> I think leveraging the merge strategy to perform rebase is
> sound, but the selection of merge base for this purpose is quite
> different from the regular merge, and I think unfortunately this
> patch is probably wrong in letting git-merge choose the merge
> base.
>
> But let's mention other things as well.
>
> - You kept the original "format-patch piped to am" workflow
> optionally working.
I left it as the default, too. I figured that it's best not
to change the default (and most likely faster) behavior of
something people rely on.
> - You check if merge or patch was used for failed rebase and
> follow the appropriate codepath while resuming, which is
> good.
>
> - The list of commits you generate with tac seem to include
> merge commit -- you may want to give --no-merges to
> rev-list.
Good point, I'll change it.
> - I do not think we use "tac" elsewhere -- is it portable
> enough?
Nope. perl -e 'print reverse <>' is equivalent and we already use
plenty of perl.
> - Exiting with success unconditionally after "git am" feels
> wrong. I would do "exit $?" instead of "exit 0" there.
Oops, I'll change that, too.
> Suppose you have this commit ancestry graph:
>
> ----------------------------------------------------------------
> Example: git-rebase --onto master A topic
>
> A---B---C topic B'--C' topic
> / --> /
> D---E---F---G master D---E---F---G master
> ----------------------------------------------------------------
>
> This is slightly different from the one at the beginning of the
> script. The idea is A turned out to be not so cool, and we
> would want to drop it.
>
> > +call_merge () {
> > + cmt="$(cat $dotest/`printf %0${prec}d $1`)"
> > + echo "$cmt" > "$dotest/current"
> > + git-merge $strategy_args "rebase-merge: $cmt" HEAD "$cmt" \
> > + || die "$MRESOLVEMSG"
> > +}
>
> call_merge is first called with B in cmt, and HEAD is pointing
> at G. But the merge in this function makes a merge between B
> and G, taking the effect of E->A.
>
> I think the three-way merge you would want here is not between B
> and G using E as the pivot, but between B and G using A as the
> pivot. That's how cherry-pick and revert works. I would
> leverage the interface that is one level lower for this -- the
> strategy modules themselves.
>
> git-merge-$strategy $cmt^ -- HEAD $cmt
Changing the 'git-merge $strategy_args "rebase-merge: $cmt" HEAD "$cmt"'
line in call_merge() to this seems to have broken more tests.
I'm not an expert at merging strategies by any measure, I've just
trusted merge-recursive to Do The Right Thing(TM) more often than not,
and use rerere to avoid repeating work.
I'm not entirely sure I want (or fully understand how) to support
cherry-picking/revert with this, as I've already dropped --skip when
--merge was in use.
I'll think about this some more when I'm less distracted.
> The strategy modules take merge base(s), double-dash as the
> separator, our head and the other head. They do not make commit
> themselves (instead they leave working tree and index in
> committable state) and signal the results with their exit
> status:
>
> 0 -- success
> 1 -- conflicts
> 2 -- did not handle the merge at all
Cool, that's good.
--
Eric Wong
^ permalink raw reply
* Re: Add specialized object allocator
From: Junio C Hamano @ 2006-06-19 21:38 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0606191327240.5498@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Mon, 19 Jun 2006, Junio C Hamano wrote:
>>
>> Impressed. I wonder if we want to deal with any_object
>> structure as well.
>
> Well, it would certainly be very easily doable, but none of the core code
> actually uses it, so it wasn't even on my radar.
I think the definition of "the core" in your earlier message was
"stuff I [jc: Linus] use myself", and I think the above
statement is in line with that definition.
It is hereby officially declared that commit walkers are not
part of the core ;-).
Even the commit walker uses lookup_unknown only for the starting
object and all the rest are of known type, so it does not help
even if we did "union any_object" that much.
^ permalink raw reply
* Re: [PATCH] Fix git to be (more) ANSI C99 compliant.
From: Florian Forster @ 2006-06-19 21:21 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0606180946090.5498@g5.osdl.org>
[-- Attachment #1: Type: text/plain, Size: 1256 bytes --]
On Sun, Jun 18, 2006 at 09:50:37AM -0700, Linus Torvalds wrote:
> > While most of this patch fixes void-pointer arithmetic
>
> This one I disagree with. Doing arithmetic on "void *" is _really_ useful,
Agreed: If you want to walk over the memory pointed to by a void-pointer
you want to do that byte-wise in the great majority of all cases.
> and I think most compilers end up supporting it either to be
> compatible with gcc, or just because it's hard to not do it.
Now this statement I don't agree with. (And by that I don't mean I
assume it to be false.)
I didn't start writing the patch because I like C99 so much. In fact, in
my opinion it introduces some possibilities I'd rather not have in C
because people might actually use them. But by default the Sun cc
complains about void-pointer arithmetic and I feel awkward to force the
compiler to accept broken code.
Maybe Rene Scharfe's method (as used in the patch to git-tar-tree) is a
good way around it? There are no explicit casts involved and standard-
compliant compilers like it, too. The downside is that you have two
variables for the same thing/memory.
Regards,
-octo
--
Florian octo Forster
Hacker in training
GnuPG: 0x91523C3D
http://verplant.org/
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Add specialized object allocator
From: Linus Torvalds @ 2006-06-19 20:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vejxl9bi0.fsf@assigned-by-dhcp.cox.net>
On Mon, 19 Jun 2006, Junio C Hamano wrote:
>
> Impressed. I wonder if we want to deal with any_object
> structure as well.
Well, it would certainly be very easily doable, but none of the core code
actually uses it, so it wasn't even on my radar.
Linus
^ permalink raw reply
* Re: [PATCH] Make CSS file gitweb/gitweb.css more readable
From: Junio C Hamano @ 2006-06-19 20:14 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e76qbi$tt9$1@sea.gmane.org>
Jakub, I've been applying your patches after hand-fixing but it
appears that there is serious whitespace breakage on the mail
path somewhere between you and the mailing list. Please check
your MUA.
For example:
> div.title, a.title {
> - display:block; padding:6px 8px;
> - font-weight:bold; background-color:#edece6; text-decoration:none; color:#000000;
The original indents these two lines with a TAB.
I'll hand-munge your patch again and will clean-up the
indentation and push the result out as part of "next" sometime
later.
Also I've removed the commented out "padding-left" in div.pre.
^ permalink raw reply
* Re: Add specialized object allocator
From: Junio C Hamano @ 2006-06-19 19:44 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0606191028540.5498@g5.osdl.org>
Impressed. I wonder if we want to deal with any_object
structure as well.
^ permalink raw reply
* [PATCH] Fix t8001-annotate and t8002-blame for ActiveState Perl
From: Dennis Stosberg @ 2006-06-19 19:40 UTC (permalink / raw)
To: Alex Riesen; +Cc: Junio C Hamano, git
In-Reply-To: <81b0412b0606190935g67581ebucf172acb36e53b02@mail.gmail.com>
There seems to be at least one implementation of Perl which requires the
user to specify an extension for backup files.
Reported by Alex Riesen.
Signed-off-by: Dennis Stosberg <dennis@stosberg.net>
---
What system and what version of ActivePerl do you use? I have just
tried ActivePerl 5.8.8 on Solaris and it does _not_ force the user
to make backups.
t/annotate-tests.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/t/annotate-tests.sh b/t/annotate-tests.sh
index c04f0e1..03ed081 100644
--- a/t/annotate-tests.sh
+++ b/t/annotate-tests.sh
@@ -111,7 +111,7 @@ test_expect_success \
test_expect_success \
'some edit' \
- 'perl -pi -e "s/^1A.*\n$//; s/^3A/99/" file &&
+ 'perl -p -i.orig -e "s/^1A.*\n$//; s/^3A/99/" file &&
GIT_AUTHOR_NAME="D" git commit -a -m "edit"'
test_expect_success \
--
1.4.0
^ permalink raw reply related
* [PATCH] Make CSS file gitweb/gitweb.css more readable
From: Jakub Narebski @ 2006-06-19 18:27 UTC (permalink / raw)
To: git
Taken from git://git.xmms.se/xmms2/gitweb-xmms2.git
commit 561262030d58a6325f500b36d836dbe02a5abc68
"Make CSS readable" by Daniel Svensson, with extra
parts removed and consistent whitespace usage.
---
gitweb/gitweb.css | 273 +++++++++++++++++++++++++++++++++++++++++++----------
1 files changed, 223 insertions(+), 50 deletions(-)
72888c0a080d95117d54dc9578dc2a0de7b19abd
diff --git a/gitweb/gitweb.css b/gitweb/gitweb.css
index 5900916..9d91426 100644
--- a/gitweb/gitweb.css
+++ b/gitweb/gitweb.css
@@ -1,58 +1,231 @@
body {
- font-family: sans-serif; font-size: 12px; border:solid #d9d8d1; border-width:1px;
- margin:10px; background-color:#ffffff; color:#000000;
-}
-a { color:#0000cc; }
-a:hover, a:visited, a:active { color:#880000; }
-div.page_header { height:25px; padding:8px; font-size:18px; font-weight:bold; background-color:#d9d8d1; }
-div.page_header a:visited, a.header { color:#0000cc; }
-div.page_header a:hover { color:#880000; }
-div.page_nav { padding:8px; }
-div.page_nav a:visited { color:#0000cc; }
-div.page_path { padding:8px; border:solid #d9d8d1; border-width:0px 0px 1px}
-div.page_footer { height:17px; padding:4px 8px; background-color: #d9d8d1; }
-div.page_footer_text { float:left; color:#555555; font-style:italic; }
-div.page_body { padding:8px; }
+ font-family: sans-serif;
+ font-size: 12px;
+ border:solid #d9d8d1;
+ border-width: 1px;
+ margin: 10px;
+ background-color: #ffffff;
+ color: #000000;
+}
+
+a {
+ color: #0000cc;
+}
+
+a:hover, a:visited, a:active {
+ color: #880000;
+}
+
+div.page_header {
+ height: 25px;
+ padding: 8px;
+ font-size: 18px;
+ font-weight: bold;
+ background-color: #d9d8d1;
+}
+
+div.page_header a:visited, a.header {
+ color: #0000cc;
+}
+
+div.page_header a:hover {
+ color: #880000;
+}
+
+div.page_nav {
+ padding:8px;
+}
+
+div.page_nav a:visited {
+ color: #0000cc;
+}
+
+div.page_path {
+ padding: 8px;
+ border: solid #d9d8d1;
+ border-width: 0px 0px 1px;
+}
+
+div.page_footer {
+ height: 17px;
+ padding: 4px 8px;
+ background-color: #d9d8d1;
+}
+
+div.page_footer_text {
+ float: left;
+ color: #555555;
+ font-style: italic;
+}
+
+div.page_body {
+ padding: 8px;
+}
+
div.title, a.title {
- display:block; padding:6px 8px;
- font-weight:bold; background-color:#edece6; text-decoration:none; color:#000000;
+ display: block;
+ padding: 6px 8px;
+ font-weight: bold;
+ background-color: #edece6;
+ text-decoration: none;
+ color: #000000;
+}
+
+a.title:hover {
+ background-color: #d9d8d1;
+}
+
+div.title_text {
+ padding: 6px 0px;
+ border: solid #d9d8d1;
+ border-width: 0px 0px 1px;
}
-a.title:hover { background-color: #d9d8d1; }
-div.title_text { padding:6px 0px; border: solid #d9d8d1; border-width:0px 0px 1px; }
-div.log_body { padding:8px 8px 8px 150px; }
-span.age { position:relative; float:left; width:142px; font-style:italic; }
+
+div.log_body {
+ padding: 8px 8px 8px 150px;
+}
+
+span.age {
+ position: relative;
+ float: left;
+ width: 142px;
+ font-style:italic;
+}
+
div.log_link {
- padding:0px 8px;
- font-size:10px; font-family:sans-serif; font-style:normal;
- position:relative; float:left; width:136px;
-}
-div.list_head { padding:6px 8px 4px; border:solid #d9d8d1; border-width:1px 0px 0px; font-style:italic; }
-a.list { text-decoration:none; color:#000000; }
-a.list:hover { text-decoration:underline; color:#880000; }
-a.text { text-decoration:none; color:#0000cc; }
-a.text:visited { text-decoration:none; color:#880000; }
-a.text:hover { text-decoration:underline; color:#880000; }
-table { padding:8px 4px; }
-th { padding:2px 5px; font-size:12px; text-align:left; }
-tr.light:hover { background-color:#edece6; }
-tr.dark { background-color:#f6f6f0; }
-tr.dark:hover { background-color:#edece6; }
-td { padding:2px 5px; font-size:12px; vertical-align:top; }
-td.link { padding:2px 5px; font-family:sans-serif; font-size:10px; }
-div.pre { font-family:monospace; font-size:12px; white-space:pre; }
-div.diff_info { font-family:monospace; color:#000099; background-color:#edece6; font-style:italic; }
-div.index_include { border:solid #d9d8d1; border-width:0px 0px 1px; padding:12px 8px; }
-div.search { margin:4px 8px; position:absolute; top:56px; right:12px }
-a.linenr { color:#999999; text-decoration:none }
+ padding: 0px 8px;
+ font-size: 10px;
+ font-family: sans-serif;
+ font-style:normal;
+ position: relative;
+ float: left;
+ width: 136px;
+}
+
+div.list_head {
+ padding: 6px 8px 4px;
+ border: solid #d9d8d1;
+ border-width: 1px 0px 0px;
+ font-style: italic;
+}
+
+a.list {
+ text-decoration: none;
+ color: #000000;
+}
+
+a.list:hover {
+ text-decoration: underline;
+ color: #880000;
+}
+
+a.text {
+ text-decoration: none;
+ color: #0000cc;
+}
+
+a.text:visited {
+ text-decoration: none;
+ color: #880000;
+}
+
+a.text:hover {
+ text-decoration: underline;
+ color: #880000;
+}
+
+table {
+ padding: 8px 4px;
+}
+
+th {
+ padding: 2px 5px;
+ font-size: 12px;
+ text-align: left;
+}
+
+tr.light:hover {
+ background-color: #edece6;
+}
+
+tr.dark {
+ background-color: #f6f6f0;
+}
+
+tr.dark:hover {
+ background-color: #edece6;
+}
+
+
+td {
+ padding: 2px 5px;
+ font-size: 12px;
+ vertical-align:top;
+}
+
+td.link {
+ padding: 2px 5px;
+ font-family: sans-serif;
+ font-size: 10px;
+}
+
+div.pre {
+ font-family: monospace;
+ font-size: 12px;
+ white-space: pre;
+ /* padding-left: 5px; */
+}
+
+div.diff_info {
+ font-family: monospace;
+ color: #000099;
+ background-color: #edece6;
+ font-style: italic;
+}
+
+div.index_include {
+ border: solid #d9d8d1;
+ border-width: 0px 0px 1px;
+ padding: 12px 8px;
+}
+
+div.search {
+ margin: 4px 8px;
+ position: absolute;
+ top: 56px;
+ right: 12px
+}
+
+a.linenr {
+ color: #999999;
+ text-decoration: none
+}
+
a.rss_logo {
- float:right; padding:3px 0px; width:35px; line-height:10px;
- border:1px solid; border-color:#fcc7a5 #7d3302 #3e1a01 #ff954e;
- color:#ffffff; background-color:#ff6600;
- font-weight:bold; font-family:sans-serif; font-size:10px;
- text-align:center; text-decoration:none;
+ float: right;
+ padding: 3px 0px;
+ width: 35px;
+ line-height: 10px;
+ border: 1px solid;
+ border-color: #fcc7a5 #7d3302 #3e1a01 #ff954e;
+ color: #ffffff;
+ background-color: #ff6600;
+ font-weight: bold;
+ font-family: sans-serif;
+ font-size: 10px;
+ text-align: center;
+ text-decoration: none;
+}
+
+a.rss_logo:hover {
+ background-color: #ee5500;
}
-a.rss_logo:hover { background-color:#ee5500; }
+
span.tag {
- padding:0px 4px; font-size:10px; font-weight:normal;
- background-color:#ffffaa; border:1px solid; border-color:#ffffcc #ffee00 #ffee00 #ffffcc;
+ padding: 0px 4px;
+ font-size: 10px;
+ font-weight: normal;
+ background-color: #ffffaa;
+ border: 1px solid;
+ border-color: #ffffcc #ffee00 #ffee00 #ffffcc;
}
--
1.3.0
^ permalink raw reply related
* Re: Add specialized object allocator
From: Linus Torvalds @ 2006-06-19 18:10 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0606191028540.5498@g5.osdl.org>
On Mon, 19 Jun 2006, Linus Torvalds wrote:
>
> It also allows us to track some basic statistics about object
> allocations. For example, for the mozilla import, it shows
> object usage as follows:
>
> blobs: 627629 (14710 kB)
> trees: 1119035 (34969 kB)
> commits: 196423 (8440 kB)
> tags: 1336 (46 kB)
Btw, this is the trivial additional patch to allow you to say
git --report rev-list --all --objects > /dev/null
and have it report object allocation usage after the op.
Useful? Probably not. It was useful for me to verify that everything
looked ok (and while I knew we had more trees than blobs, it's actually
interesting to see how projects differ.
The "git" tree, for example, has more blobs than trees: because it's a
fairly flat development tree, a commit that changes more than one file
will generate more new blobs than it generates trees.
In contrast, the kernel has about 30% more trees than blobs (but since
trees have the extra data/size fields, 30% extra trees take 75% more space
than blobs).
The mozilla import has a _lot_ more trees than blobs (80% more trees, and
they use up more than twice as much memory). It's probably a pretty deep
tree structure and/or they often commit changes to single files deep into
the tree).
Linus
----
diff --git a/git.c b/git.c
index 329ebec..6149499 100644
--- a/git.c
+++ b/git.c
@@ -271,6 +271,10 @@ int main(int argc, const char **argv, ch
puts(git_exec_path());
exit(0);
}
+ if (!strcmp(cmd, "report")) {
+ atexit(alloc_report);
+ continue;
+ }
cmd_usage(0, NULL, NULL);
}
argv[0] = cmd;
^ permalink raw reply related
* Add specialized object allocator
From: Linus Torvalds @ 2006-06-19 17:44 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List
This creates a simple specialized object allocator for basic
objects.
This avoids wasting space with malloc overhead (metadata and
extra alignment), since the specialized allocator knows the
alignment, and that objects, once allocated, are never freed.
It also allows us to track some basic statistics about object
allocations. For example, for the mozilla import, it shows
object usage as follows:
blobs: 627629 (14710 kB)
trees: 1119035 (34969 kB)
commits: 196423 (8440 kB)
tags: 1336 (46 kB)
and the simpler allocator shaves off about 2.5% off the memory
footprint off a "git-rev-list --all --objects", and is a bit
faster too.
[ Side note: this concludes the series of "save memory in object storage".
The thing is, there simply isn't much more to be saved on the objects.
Doing "git-rev-list --all --objects" on the mozilla archive has a final
total RSS of 131498 pages for me: that's about 513MB. Of that, the
object overhead is now just 56MB, the rest is going somewhere else (put
another way: the fact that this patch shaves off 2.5% of the total
memory overhead, considering that objects are now not much more than 10%
of the total shows how big the wasted space really was: this makes
object allocations much more memory- and time-efficient).
I haven't looked at where the rest is, but I suspect the bulk of it is
just the pack-file loading. It may be that we should pack the tree
objects separately from the blob objects: for git-rev-list --objects, we
don't actually ever need to even look at the blobs, but since trees and
blobs are interspersed in the pack-file, we end up not being dense in
the tree accesses, so we end up looking at more pages than we strictly
need to.
So with a 535MB pack-file, it's entirely possible - even likely - that
most of the remaining RSS is just the mmap of the pack-file itself. We
don't need to map in _all_ of it, but we do end up mapping a fair
amount. ]
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
---
Makefile | 2 +-
alloc.c | 51 +++++++++++++++++++++++++++++++++++++++++++++++++++
blob.c | 2 +-
cache.h | 11 +++++++++++
commit.c | 2 +-
tag.c | 2 +-
tree.c | 2 +-
7 files changed, 67 insertions(+), 5 deletions(-)
diff --git a/Makefile b/Makefile
index ea8cd28..0887945 100644
--- a/Makefile
+++ b/Makefile
@@ -216,7 +216,7 @@ LIB_OBJS = \
server-info.o setup.o sha1_file.o sha1_name.o strbuf.o \
tag.o tree.o usage.o config.o environment.o ctype.o copy.o \
fetch-clone.o revision.o pager.o tree-walk.o xdiff-interface.o \
- $(DIFF_OBJS)
+ alloc.o $(DIFF_OBJS)
BUILTIN_OBJS = \
builtin-log.o builtin-help.o builtin-count.o builtin-diff.o builtin-push.o \
diff --git a/alloc.c b/alloc.c
new file mode 100644
index 0000000..65ec0cc
--- /dev/null
+++ b/alloc.c
@@ -0,0 +1,51 @@
+/*
+ * alloc.c - specialized allocator for internal objects
+ *
+ * Copyright (C) 2006 Linus Torvalds
+ *
+ * The standard malloc/free wastes too much space for objects, partly because
+ * it maintains all the allocation infrastructure (which isn't needed, since
+ * we never free an object descriptor anyway), but even more because it ends
+ * up with maximal alignment because it doesn't know what the object alignment
+ * for the new allocation is.
+ */
+#include "cache.h"
+#include "object.h"
+#include "blob.h"
+#include "tree.h"
+#include "commit.h"
+#include "tag.h"
+
+#define BLOCKING 1024
+
+#define DEFINE_ALLOCATOR(name) \
+static unsigned int name##_allocs; \
+struct name *alloc_##name##_node(void) \
+{ \
+ static int nr; \
+ static struct name *block; \
+ \
+ if (!nr) { \
+ nr = BLOCKING; \
+ block = xcalloc(BLOCKING, sizeof(struct name)); \
+ } \
+ nr--; \
+ name##_allocs++; \
+ return block++; \
+}
+
+DEFINE_ALLOCATOR(blob);
+DEFINE_ALLOCATOR(tree);
+DEFINE_ALLOCATOR(commit);
+DEFINE_ALLOCATOR(tag);
+
+#define REPORT(name) \
+ fprintf(stderr, "%10s: %8u (%zu kB)\n", #name, name##_allocs, name##_allocs*sizeof(struct name) >> 10)
+
+void alloc_report(void)
+{
+ REPORT(blob);
+ REPORT(tree);
+ REPORT(commit);
+ REPORT(tag);
+}
diff --git a/blob.c b/blob.c
index 7377008..496f270 100644
--- a/blob.c
+++ b/blob.c
@@ -8,7 +8,7 @@ struct blob *lookup_blob(const unsigned
{
struct object *obj = lookup_object(sha1);
if (!obj) {
- struct blob *ret = xcalloc(1, sizeof(struct blob));
+ struct blob *ret = alloc_blob_node();
created_object(sha1, &ret->object);
ret->object.type = TYPE_BLOB;
return ret;
diff --git a/cache.h b/cache.h
index 7fcb6d4..eaa5c0c 100644
--- a/cache.h
+++ b/cache.h
@@ -384,4 +384,15 @@ extern void setup_pager(void);
int decode_85(char *dst, char *line, int linelen);
void encode_85(char *buf, unsigned char *data, int bytes);
+/* alloc.c */
+struct blob;
+struct tree;
+struct commit;
+struct tag;
+extern struct blob *alloc_blob_node(void);
+extern struct tree *alloc_tree_node(void);
+extern struct commit *alloc_commit_node(void);
+extern struct tag *alloc_tag_node(void);
+extern void alloc_report(void);
+
#endif /* CACHE_H */
diff --git a/commit.c b/commit.c
index 5914200..0fa1198 100644
--- a/commit.c
+++ b/commit.c
@@ -84,7 +84,7 @@ struct commit *lookup_commit(const unsig
{
struct object *obj = lookup_object(sha1);
if (!obj) {
- struct commit *ret = xcalloc(1, sizeof(struct commit));
+ struct commit *ret = alloc_commit_node();
created_object(sha1, &ret->object);
ret->object.type = TYPE_COMMIT;
return ret;
diff --git a/tag.c b/tag.c
index 9191333..5f70a5b 100644
--- a/tag.c
+++ b/tag.c
@@ -19,7 +19,7 @@ struct tag *lookup_tag(const unsigned ch
{
struct object *obj = lookup_object(sha1);
if (!obj) {
- struct tag *ret = xcalloc(1, sizeof(struct tag));
+ struct tag *ret = alloc_tag_node();
created_object(sha1, &ret->object);
ret->object.type = TYPE_TAG;
return ret;
diff --git a/tree.c b/tree.c
index 64422fd..1023655 100644
--- a/tree.c
+++ b/tree.c
@@ -129,7 +129,7 @@ struct tree *lookup_tree(const unsigned
{
struct object *obj = lookup_object(sha1);
if (!obj) {
- struct tree *ret = xcalloc(1, sizeof(struct tree));
+ struct tree *ret = alloc_tree_node();
created_object(sha1, &ret->object);
ret->object.type = TYPE_TREE;
return ret;
^ permalink raw reply related
* Re: [PATCH] cvsimport: ignore CVSPS_NO_BRANCH and impossible branches
From: Salikh Zakirov @ 2006-06-19 16:20 UTC (permalink / raw)
Cc: git
In-Reply-To: <7vzmgb8plx.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Martin Langhoff <martin@catalyst.net.nz> writes:
>
>> cvsps output often contains references to CVSPS_NO_BRANCH, commits that it
>> could not trace to a branch. Ignore that branch.
>>
>> Additionally, cvsps will sometimes draw circular relationships between
>> branches -- where two branches are recorded as opening from the other.
>> In those cases, and where the ancestor branch hasn't been seen, ignore
>> it.
>
> This sounds more like an workaround than a real fix to me,
> although I'd apply it for now. I see Yann is collecting cvsps
> patches but maybe there will be a real fix soonish?
#CVSPS_NO_BRANCH is the identifier that CVSPS gives to the unnamed branches.
Unnamed branches appear when the branch tag is removed or moved forcefully.
The following short script reproduces the CVS repository with unnamed branches.
In my opinion, ignoring #CVSPS_NO_BRANCH in git-cvsimport is the most sensible
thing to do, because the branch was abandoned in the CVS in the first place.
I had to preprocess cvsps output to cut out CVSPS_NO_BRANCH commits anyway.
I vote for including the Martin's patch.
Creating CVS repository with unnamed branch
--8<--
export CVSROOT=$PWD/cvsroot
cvs init
cvs checkout .
mkdir a
cvs add a
cd a
vim a.txt
cvs add a.txt
cvs commit -m "added a.txt" a.txt
cvs tag -b br1
cvs update -r br1
echo "br1 update" >> a.txt
cvs commit -m "br1 update" a.txt
cvs update -A
echo "HEAD update" >> a.txt
cvs commit -m "HEAD update" a.txt
cvs tag -d br1
cvs tag -b br1
cvs tag -d -B br1
cvs tag -b br1
cvs update -r br1
echo "branch update, once more" >> a.txt
cvs commit -m "2nd branch update" a.txt
------
and corresponding CVSPS output is
--8<--
$ cvsps -A
WARNING: revision 1.1.2.1 of file a.txt on unnamed branch
---------------------
PatchSet 1
Date: 2006/06/19 20:10:09
Author: sszakiro
Branch: HEAD
Tag: (none)
Log:
added a.txt
Members:
a.txt:INITIAL->1.1
---------------------
PatchSet 2
Date: 2006/06/19 20:10:45
Author: sszakiro
Branch: #CVSPS_NO_BRANCH
Ancestor branch: HEAD
Tag: (none)
Log:
br1 update
Members:
a.txt:1.1->1.1.2.1
---------------------
PatchSet 3
Date: 2006/06/19 20:11:18
Author: sszakiro
Branch: HEAD
Tag: (none)
Log:
HEAD update
Members:
a.txt:1.1->1.2
---------------------
PatchSet 4
Date: 2006/06/19 20:12:07
Author: sszakiro
Branch: br1
Ancestor branch: HEAD
Tag: (none)
Log:
2nd branch update
Members:
a.txt:1.2->1.2.2.1
------
^ permalink raw reply
* Re: [PATCH] Make t8001-annotate and t8002-blame more portable
From: Alex Riesen @ 2006-06-19 16:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Dennis Stosberg, git
In-Reply-To: <7v3be218ri.fsf@assigned-by-dhcp.cox.net>
On 6/18/06, Junio C Hamano <junkio@cox.net> wrote:
> > + 'perl -pi -e "s/^1A.*\n$//; s/^3A/99/" file &&
activestate perl again: doesn't work without giving a backup file extension,
like this: perl -pi.bak -e ...
^ permalink raw reply
* Re: simple use case scenario for --read-tree and --write-tree with --prefix option
From: Aneesh Kumar @ 2006-06-19 15:50 UTC (permalink / raw)
To: Petr Baudis; +Cc: Junio C Hamano, git
In-Reply-To: <20060619135343.GP2609@pasky.or.cz>
On 6/19/06, Petr Baudis <pasky@suse.cz> wrote:
> Dear diary, on Mon, Jun 19, 2006 at 09:58:31AM CEST, I got a letter
> where Aneesh Kumar <aneesh.kumar@gmail.com> said that...
> > cd test
> >
> > kvaneesh@satan:/tmp/test$ git read-tree --prefix=test1/ $(cat
> > test1/.git/refs/heads/master)
> > fatal: failed to unpack tree object c6c049d03f0bee0ac546ff6e436d5f6f3a5f4864
> >
> > But the above command doesn't work for me. I guess i am missing something.
>
> You need to do a fetch to your /tmp/test repository first.
>
Ok that made the --read-tree part work. But the log or whatchanged
commands doesn't gets me the history of changes with resepect to the
files added. Now i remember this is in a way simillar to gitweb
history not shown. But then using the --full-history option with git
log also doesn't show the details of history with respect to the
files.
This is what i did
git fetch ./test2/
git read-tree --prefix=test2/ $(cat test2/.git/refs/heads/master)
Now if i look at .git/objects/ I can see commit objects with respect
to changes for test2/a
-aneesh
^ permalink raw reply
* Re: simple use case scenario for --read-tree and --write-tree with --prefix option
From: Petr Baudis @ 2006-06-19 13:53 UTC (permalink / raw)
To: Aneesh Kumar; +Cc: Junio C Hamano, git
In-Reply-To: <cc723f590606190058w2d7481ecsaded46095aee2355@mail.gmail.com>
Dear diary, on Mon, Jun 19, 2006 at 09:58:31AM CEST, I got a letter
where Aneesh Kumar <aneesh.kumar@gmail.com> said that...
> cd test
>
> kvaneesh@satan:/tmp/test$ git read-tree --prefix=test1/ $(cat
> test1/.git/refs/heads/master)
> fatal: failed to unpack tree object c6c049d03f0bee0ac546ff6e436d5f6f3a5f4864
>
> But the above command doesn't work for me. I guess i am missing something.
You need to do a fetch to your /tmp/test repository first.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
A person is just about as big as the things that make them angry.
^ permalink raw reply
* Re: git-rebase nukes multiline comments
From: Matthias Hopf @ 2006-06-19 9:54 UTC (permalink / raw)
To: git, xorg
In-Reply-To: <20060619093623.GA15209@suse.de>
On Jun 19, 06 11:36:23 +0200, Matthias Hopf wrote:
> On Jun 16, 06 12:55:43 -0500, David Kowis wrote:
> O-key. Did this work w/o a blank line as well? Then we can assume this
Ignore my ignorance. I really should *read* before answering...
Sorry
Matthias
--
Matthias Hopf <mhopf@suse.de> __ __ __
Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ mat@mshopf.de
Phone +49-911-74053-715 __) |_| __) |__ labs www.mshopf.de
^ permalink raw reply
* Re: git-rebase nukes multiline comments
From: Matthias Hopf @ 2006-06-19 9:53 UTC (permalink / raw)
To: git
In-Reply-To: <7vwtbgbsax.fsf@assigned-by-dhcp.cox.net>
On Jun 16, 06 16:21:26 -0700, Junio C Hamano wrote:
> Having said that, I would say it is a bug. We should be able to
> rebase, cherry-pick and/or rebase a patch with an arbitrary
> binary garbage in the commit log message (I think the latter two
> command do). But because of the reason (2) above, it is very
> low on my priority to change it.
I understand. Many thanks for your explainations. I think this intended
log format should be documented somewhere, that would help a lot. I
don't think that many developers using git in CVS style know about this
convention.
Said that, I assume git nuking the multiline comment was a bug in 1.3.1
that has been (somewhat ;) solved.
Matthias
--
Matthias Hopf <mhopf@suse.de> __ __ __
Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ mat@mshopf.de
Phone +49-911-74053-715 __) |_| __) |__ labs www.mshopf.de
^ permalink raw reply
* Re: git-rebase nukes multiline comments
From: Matthias Hopf @ 2006-06-19 9:36 UTC (permalink / raw)
To: git; +Cc: xorg
In-Reply-To: <4492F09F.9080906@shlrm.org>
On Jun 16, 06 12:55:43 -0500, David Kowis wrote:
> > I'm new to git, but I tried what you said.
> > my git log:
> > commit c846bea8c61bec7cf0f7688c48abc42577b9ac7f
> > Author: David Kowis <dkowis@kain.org>
> > Date: Fri Jun 16 12:20:08 2006 -0500
> >
> > this is a multi
> >
> > line comment
> > with three lines
> >
> >
> > I'm using git 1.4.0. It added a blank line in there...
O-key. Did this work w/o a blank line as well? Then we can assume this
solved in 1.4.0. Now there's still the question whether the log messages
in the upstream archive can be restored...
> I'm going to note that the xorg ML cc doesn't work for anyone not
> subscribed... You may miss out on replies.
I'm subscribed here as well :-)
I just CC'ed xorg so people over there know about the issue as well.
CU
Matthias
--
Matthias Hopf <mhopf@suse.de> __ __ __
Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ mat@mshopf.de
Phone +49-911-74053-715 __) |_| __) |__ labs www.mshopf.de
^ permalink raw reply
* Re: [PATCH 1/7] Remove ranges from switch statements.
From: linux @ 2006-06-19 9:17 UTC (permalink / raw)
To: git, octo, tihirvon
> Yes, but isalnum(ch) even better ;)
And if you want to get fancy, there's plenty of room in git's sane_ctype
array for an additional punctuation bit to catch the [./-] cases.
Note also that technically the set of unreserved characters in URIs
(according to rfc2396 section 2.3) is
unreserved = alphanum | mark
mark = "-" | "_" | "." | "!" | "~" | "*" | "'" | "(" | ")"
The complementary set of characters that should be quoted is defined as well:
(2.2)
Many URI include components consisting of or delimited by, certain
special characters. These characters are called "reserved", since
their usage within the URI component is limited to their reserved
purpose. If the data for a URI component would conflict with the
reserved purpose, then the conflicting data must be escaped before
forming the URI.
reserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" |
"$" | ","
(2.4.3)
The angle-bracket "<" and ">" and double-quote (") characters are
excluded because they are often used as the delimiters around URI in
text documents and protocol fields. The character "#" is excluded
because it is used to delimit a URI from a fragment identifier in URI
references (Section 4). The percent character "%" is excluded because
it is used for the encoding of escaped characters.
delims = "<" | ">" | "#" | "%" | <">
Other characters are excluded because gateways and other transport
agents are known to sometimes modify such characters, or they are
used as delimiters.
unwise = "{" | "}" | "|" | "\" | "^" | "[" | "]" | "`"
E.g. (the following change is placed in the public domain):
diff --git a/ctype.c b/ctype.c
index 56bdffa..01724d1 100644
--- a/ctype.c
+++ b/ctype.c
@@ -8,16 +8,17 @@ #include "cache.h"
#define SS GIT_SPACE
#define AA GIT_ALPHA
#define DD GIT_DIGIT
+#define MM GIT_URIMARK /* Legal URI "marks", RFC2396 section 2.3, plus / */
unsigned char sane_ctype[256] = {
0, 0, 0, 0, 0, 0, 0, 0, 0, SS, SS, 0, 0, SS, 0, 0, /* 0-15 */
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, /* 16-15 */
- SS, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, /* 32-15 */
+ SS, MM, 0, 0, 0, 0, 0, MM, MM, MM, MM, 0, 0, MM, MM, MM, /* 32-15 */
DD, DD, DD, DD, DD, DD, DD, DD, DD, DD, 0, 0, 0, 0, 0, 0, /* 48-15 */
0, AA, AA, AA, AA, AA, AA, AA, AA, AA, AA, AA, AA, AA, AA, AA, /* 64-15 */
- AA, AA, AA, AA, AA, AA, AA, AA, AA, AA, AA, 0, 0, 0, 0, 0, /* 80-15 */
+ AA, AA, AA, AA, AA, AA, AA, AA, AA, AA, AA, 0, 0, 0, 0, MM, /* 80-15 */
0, AA, AA, AA, AA, AA, AA, AA, AA, AA, AA, AA, AA, AA, AA, AA, /* 96-15 */
- AA, AA, AA, AA, AA, AA, AA, AA, AA, AA, AA, 0, 0, 0, 0, 0, /* 112-15 */
+ AA, AA, AA, AA, AA, AA, AA, AA, AA, AA, AA, 0, 0, 0, MM, 0, /* 112-15 */
/* Nothing in the 128.. range */
};
diff --git a/git-compat-util.h b/git-compat-util.h
index 5d543d2..7b4feae 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -138,11 +138,14 @@ extern unsigned char sane_ctype[256];
#define GIT_SPACE 0x01
#define GIT_DIGIT 0x02
#define GIT_ALPHA 0x04
+#define GIT_URIMARK 0x08
#define sane_istest(x,mask) ((sane_ctype[(unsigned char)(x)] & (mask)) != 0)
#define isspace(x) sane_istest(x,GIT_SPACE)
#define isdigit(x) sane_istest(x,GIT_DIGIT)
#define isalpha(x) sane_istest(x,GIT_ALPHA)
#define isalnum(x) sane_istest(x,GIT_ALPHA | GIT_DIGIT)
+/* Git extension - is character okay in URI (rfc2396, section 2.3), plus / */
+#define isuri(x) sane_istest(x,GIT_ALPHA | GIT_DIGIT | GIT_URIMARK)
#define tolower(x) sane_case((unsigned char)(x), 0x20)
#define toupper(x) sane_case((unsigned char)(x), 0)
^ 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