* Re: git-rev-list: make --dense the default (and introduce "--sparse")
From: Junio C Hamano @ 2005-10-26 9:17 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0510251525540.10477@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Tue, 25 Oct 2005, Linus Torvalds wrote:
>>
>> This actually does three things:
>>
>> - make "--dense" the default for git-rev-list...
Heads up.
I have not looked closely into what exactly, but the fourth
thing this does might be to break git-send-pack.
I usually use the tip of "pu" myself, but for tonight, I am
excluding the fetch-pack/upload-pack changes from Johannes when
building git for my own use, and using somewhere in the middle
of "pu" branch. With this "--dense default" patch,
git-send-pack seems to send too few objects. With this patch
reverted, git-send-pack seems to work again.
+ [build] Revert "git-rev-list: make --dense the default (and introduce "--sparse")"
++ [pu^] Merge branch 'js-fat'
++ [pu^^2] Test in git-init-db if the filemode can be trusted
++ [pu~2] Merge branches 'cache-pack', 'lazy-subdir' and 'lt-dense'
++ [pu~2^4] git-rev-list: make --dense the default (and introduce "--sparse")
++ [pu~2^3] Create object subdirectories on demand (phase II)
++ [pu~2^2] Allow caching of generated pack for full cloning.
+++ [master] upload-pack: tighten request validation.
I'll take a look at the issue in the morning unless somebody
else beats me to it.
^ permalink raw reply
* Re: [PATCH] Avoid using dc in git-count-objects
From: Andreas Ericsson @ 2005-10-26 9:23 UTC (permalink / raw)
To: git
In-Reply-To: <7vd5ltcf05.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
>
>>Using dc is not really necessary, since expr understands summing 32 bit
>>signed integers. Which means that git-count-objects will now fail when 2
>>GB of unpacked objects have accumulated.
>
>
> Sorry, but I am not very happy about this patch. "local"
> bashism aside, doesn't this spawn expr for every unpacked
> object?
>
I'd be more worried about the fact that the kilobytes count is way off
as it is. du (at least from coreutils-5.2.1) rounds up to nearest
kilobyte *for each file* when printing kb-count.
Try these:
du -skc .git/objects/?? | grep total
du -skc .git/objects/??/* | grep total
du -sbc .git/objects/?? | grep total
du -sbc .git/objects/??/* | grep total
which will all yield different values.
I have no idea which of those values people expect to get back, so it
might be correct right now, although I doubt it.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: latest stg/git commandline completions code
From: Catalin Marinas @ 2005-10-26 11:34 UTC (permalink / raw)
To: Blaisorblade; +Cc: Ben Clifford, git
In-Reply-To: <200510251905.27768.blaisorblade@yahoo.it>
On 25/10/05, Blaisorblade <blaisorblade@yahoo.it> wrote:
> They _would_ behave like cat, except that Python is slow enough. Half a second
> on a (almost) idle system means seconds and seconds on a busy system, and
> it's pretty frequent that when I don't wait enough for an op. to complete I
> get a traceback from the import statements, which haven't been completed.
That's a thing I should fix in StGIT - trapping the exception
generated by SIGTERM and exiting silently.
> And let's leave Gentoo's emerge alone - I'd say imports can take up to a
> minute.
That's probably because it checks the status of the tree before
importing but this command wouldn't be used to generate the
completion.
--
Catalin
^ permalink raw reply
* Re: 0.99.9 on Saturday next week.
From: Catalin Marinas @ 2005-10-26 11:50 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0510251033310.10477@g5.osdl.org>
On 25/10/05, Linus Torvalds <torvalds@osdl.org> wrote:
> On Tue, 25 Oct 2005, Junio C Hamano wrote:
> > Catalin Marinas <catalin.marinas@gmail.com> writes:
> > > Since the configuration files use the .ini like syntax, is it OK for
> > > StGIT to use the same file, with an "[stgit]" section?
> >
> > I think that is a reasonable thing to do.
>
> Absolutely. The whole thing was _designed_ to be used that way. Any C user
> should be able to just link against config.o without even bothering with
> the rest of git (the only git-specific thing there should be some naming),
> and any script user can either
I use Python for StGIT and it has support for parsing .ini syntax, no
need to use GIT for this (unless the syntax you chose would diverge
too much).
--
Catalin
^ permalink raw reply
* Re: [PATCH] Add git-name-rev
From: Johannes Schindelin @ 2005-10-26 13:10 UTC (permalink / raw)
To: Petr Baudis; +Cc: git, junkio
In-Reply-To: <20051026083625.GD30889@pasky.or.cz>
[PATCH] Add git-name-rev
git-name-rev tries to find nice symbolic names for commits. It does so by
walking the commits from the refs. When the symbolic name is ambiguous, the
following heuristic is applied: Try to avoid too many ~'s, and if two ambiguous
names have the same count of ~'s, take the one whose last number is smaller.
With "--tags", the names are derived only from tags.
With "--stdin", the stdin is parsed, and after every sha1 for which a name
could be found, the name is appended. (Try "git log | git name-rev --stdin".)
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
On Wed, 26 Oct 2005, Petr Baudis wrote:
> I think you should either add this to git-findtags.perl or
> (better) add git-findtags.perl's functionality (i.e. a switch to
> search only in the tags) to this and obsolete/kill
> git-findtags.perl. It is pretty new (from Oct 13) so killing it
> shouldn't break anything.
Ask, and it shall be given you.
Documentation/git-name-rev.txt | 66 +++++++++++
Makefile | 2
name-rev.c | 246 ++++++++++++++++++++++++++++++++++++++++
3 files changed, 313 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-name-rev.txt b/Documentation/git-name-rev.txt
new file mode 100644
index 0000000..e37b0b8
--- /dev/null
+++ b/Documentation/git-name-rev.txt
@@ -0,0 +1,66 @@
+git-name-rev(1)
+===============
+
+NAME
+----
+git-name-rev - Find symbolic names for given revs.
+
+
+SYNOPSIS
+--------
+'git-name-rev' [--tags] ( --all | --stdin | <commitish>... )
+
+DESCRIPTION
+-----------
+Finds symbolic names suitable for human digestion for revisions given in any
+format parsable by git-rev-parse.
+
+
+OPTIONS
+-------
+
+--tags::
+ Do not use branch names, but only tags to name the commits
+
+--all::
+ List all commits reachable from all refs
+
+--stdin::
+ Read from stdin, append "(<rev_name>)" to all sha1's of name'able
+ commits, and pass to stdout
+
+EXAMPLE
+-------
+
+Given a commit, find out where it is relative to the local refs. Say somebody
+wrote you about that phantastic commit 33db5f4d9027a10e477ccf054b2c1ab94f74c85a.
+Of course, you look into the commit, but that only tells you what happened, but
+not the context.
+
+Enter git-name-rev:
+
+------------
+% git name-rev 33db5f4d9027a10e477ccf054b2c1ab94f74c85a
+------------
+
+Now you are wiser, because you know that it happened 940 revisions before v0.99.
+
+Another nice thing you can do is:
+
+------------
+% git log | git name-rev --stdin
+------------
+
+
+Author
+------
+Written by Johannes Schindelin <Johannes.Schindelin@gmx.de>
+
+Documentation
+--------------
+Documentation by Johannes Schindelin.
+
+GIT
+---
+Part of the gitlink:git[7] suite
+
diff --git a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
@@ -122,7 +122,7 @@ PROGRAMS = \
git-unpack-objects$X git-update-index$X git-update-server-info$X \
git-upload-pack$X git-verify-pack$X git-write-tree$X \
git-update-ref$X git-symbolic-ref$X git-check-ref-format$X \
- $(SIMPLE_PROGRAMS)
+ git-name-rev$X $(SIMPLE_PROGRAMS)
# Backward compatibility -- to be removed after 1.0
PROGRAMS += git-ssh-pull$X git-ssh-push$X
diff --git a/name-rev.c b/name-rev.c
new file mode 100644
index 0000000..21fecdf
--- /dev/null
+++ b/name-rev.c
@@ -0,0 +1,246 @@
+#include <stdlib.h>
+#include "cache.h"
+#include "commit.h"
+#include "tag.h"
+#include "refs.h"
+
+static const char name_rev_usage[] =
+ "git-name-rev [--tags] ( --all | --stdin | commitish [commitish...] )\n";
+
+typedef struct rev_name {
+ const char *tip_name;
+ int merge_traversals;
+ int generation;
+} rev_name;
+
+static long cutoff = LONG_MAX;
+
+static void name_rev(struct commit *commit,
+ const char *tip_name, int merge_traversals, int generation,
+ int deref)
+{
+ struct rev_name *name = (struct rev_name *)commit->object.util;
+ struct commit_list *parents;
+ int parent_number = 0;
+
+ if (!commit->object.parsed)
+ parse_commit(commit);
+
+ if (commit->date < cutoff)
+ return;
+
+ if (deref) {
+ char *new_name = xmalloc(strlen(tip_name)+3);
+ strcpy(new_name, tip_name);
+ strcat(new_name, "^0");
+ tip_name = new_name;
+
+ if (generation)
+ die("generation: %d, but deref?", generation);
+ }
+
+ if (name == NULL) {
+ name = xmalloc(sizeof(rev_name));
+ commit->object.util = name;
+ goto copy_data;
+ } else if (name->merge_traversals > merge_traversals ||
+ (name->merge_traversals == merge_traversals &&
+ name->generation > generation)) {
+copy_data:
+ name->tip_name = tip_name;
+ name->merge_traversals = merge_traversals;
+ name->generation = generation;
+ } else
+ return;
+
+ for (parents = commit->parents;
+ parents;
+ parents = parents->next, parent_number++) {
+ if (parent_number > 0) {
+ char *new_name = xmalloc(strlen(tip_name)+8);
+
+ if (generation > 0)
+ sprintf(new_name, "%s~%d^%d", tip_name,
+ generation, parent_number);
+ else
+ sprintf(new_name, "%s^%d", tip_name, parent_number);
+
+ name_rev(parents->item, new_name,
+ merge_traversals + 1 , 0, 0);
+ } else {
+ name_rev(parents->item, tip_name, merge_traversals,
+ generation + 1, 0);
+ }
+ }
+}
+
+static int tags_only = 0;
+
+static int name_ref(const char *path, const unsigned char *sha1)
+{
+ struct object *o = parse_object(sha1);
+ int deref = 0;
+
+ if (tags_only && strncmp(path, "refs/tags/", 10))
+ return 0;
+
+ while (o && o->type == tag_type) {
+ struct tag *t = (struct tag *) o;
+ if (!t->tagged)
+ break; /* broken repository */
+ o = parse_object(t->tagged->sha1);
+ deref = 1;
+ }
+ if (o && o->type == commit_type) {
+ struct commit *commit = (struct commit *)o;
+ const char *p;
+
+ while ((p = strchr(path, '/')))
+ path = p+1;
+
+ name_rev(commit, strdup(path), 0, 0, deref);
+ }
+ return 0;
+}
+
+/* returns a static buffer */
+static const char* get_rev_name(struct object *o)
+{
+ static char buffer[1024];
+ struct rev_name *n = (struct rev_name *)o->util;
+ if (!n)
+ return "undefined";
+
+ if (!n->generation)
+ return n->tip_name;
+
+ snprintf(buffer, sizeof(buffer), "%s~%d", n->tip_name, n->generation);
+
+ return buffer;
+}
+
+int main(int argc, char **argv)
+{
+ struct object_list *revs = NULL;
+ struct object_list **walker = &revs;
+ int as_is = 0, all = 0, transform_stdin = 0;
+
+ setup_git_directory();
+
+ if (argc < 2)
+ usage(name_rev_usage);
+
+ for (--argc, ++argv; argc; --argc, ++argv) {
+ unsigned char sha1[20];
+ struct object *o;
+ struct commit *commit;
+
+ if (!as_is && (*argv)[0] == '-') {
+ if (!strcmp(*argv, "--")) {
+ as_is = 1;
+ continue;
+ } else if (!strcmp(*argv, "--tags")) {
+ tags_only = 1;
+ continue;
+ } else if (!strcmp(*argv, "--all")) {
+ if (argc > 1)
+ die("Specify either a list, or --all, not both!");
+ all = 1;
+ cutoff = 0;
+ continue;
+ } else if (!strcmp(*argv, "--stdin")) {
+ if (argc > 1)
+ die("Specify either a list, or --stdin, not both!");
+ transform_stdin = 1;
+ cutoff = 0;
+ continue;
+ }
+ usage(name_rev_usage);
+ }
+
+ if (get_sha1(*argv, sha1)) {
+ fprintf(stderr, "Could not get sha1 for %s. Skipping.\n",
+ *argv);
+ continue;
+ }
+
+ o = deref_tag(parse_object(sha1));
+ if (!o || o->type != commit_type) {
+ fprintf(stderr, "Could not get commit for %s. Skipping.\n",
+ *argv);
+ continue;
+ }
+
+ commit = (struct commit *)o;
+
+ if (cutoff > commit->date)
+ cutoff = commit->date;
+
+ object_list_append((struct object *)commit, walker);
+ (*walker)->name = *argv;
+ walker = &((*walker)->next);
+ }
+
+ for_each_ref(name_ref);
+
+ if (transform_stdin) {
+ char buffer[2048];
+ char *p, *p_start;
+
+ while (!feof(stdin)) {
+ int forty = 0;
+ p = fgets(buffer, sizeof(buffer), stdin);
+ if (!p)
+ break;
+
+ for (p_start = p; *p; p++) {
+#define ishex(x) (isdigit((x)) || ((x) >= 'a' && (x) <= 'f'))
+ if (!ishex(*p))
+ forty = 0;
+ else if (++forty == 40 &&
+ !ishex(*(p+1))) {
+ unsigned char sha1[40];
+ const char *name = "undefined";
+ char c = *(p+1);
+
+ forty = 0;
+
+ *(p+1) = 0;
+ if (!get_sha1(p - 39, sha1)) {
+ struct object *o =
+ lookup_object(sha1);
+ if (o)
+ name = get_rev_name(o);
+ }
+ *(p+1) = c;
+
+ if (!strcmp(name, "undefined"))
+ continue;
+
+ fwrite(p_start, p - p_start, 1, stdout);
+ fputc('(', stdout);
+ fputs(name, stdout);
+ fputc(')', stdout);
+ p_start = p + 1;
+ }
+ }
+
+ /* flush */
+ if (p_start != p)
+ fwrite(p_start, p - p_start, 1, stdout);
+ }
+ } else if (all) {
+ extern struct object **objs;
+ extern int nr_objs;
+ int i;
+
+ for (i = 0; i < nr_objs; i++)
+ printf("%s %s\n", sha1_to_hex(objs[i]->sha1),
+ get_rev_name(objs[i]));
+ } else
+ for ( ; revs; revs = revs->next)
+ printf("%s %s\n", revs->name, get_rev_name(revs->item));
+
+ return 0;
+}
+
^ permalink raw reply related
* git 565ebbf79f61873042c22a7126d002c104e056f4 broken on OpenBSD
From: Randal L. Schwartz @ 2005-10-26 14:11 UTC (permalink / raw)
To: git
gcc -o sha1_file.o -c -g -O2 -Wall -I/usr/local/include -L/usr/local/lib -Dstrcasestr=gitstrcasestr -DNO_STRCASESTR=1 -DSHA1_HEADER='<openssl/sha.h>' sha1_file.c
sha1_file.c: In function `move_temp_to_file':
sha1_file.c:1247: error: `ENOTSUP' undeclared (first use in this function)
sha1_file.c:1247: error: (Each undeclared identifier is reported only once
sha1_file.c:1247: error: for each function it appears in.)
gmake: *** [sha1_file.o] Error 1
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* [PATCH] Fix cloning (memory corruption)
From: Johannes Schindelin @ 2005-10-26 14:18 UTC (permalink / raw)
To: git, junkio
upload-pack would set create_full_pack=1 if nr_has==0, but would ask later
if nr_needs<MAX_NEEDS. If that proves true, it would ignore create_full_pack,
and arguments would be written into unreserved memory.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
This patch fixes what can be seen in all beauty when executing
git-clone . some_dir
in a repository with lots of branches/tags.
upload-pack.c | 15 ++++++++-------
1 files changed, 8 insertions(+), 7 deletions(-)
applies-to: 764f8a201d063a7b49b07daa3a6e48b0af267162
d05392d3ddfa647552190b73505a738330e492b4
diff --git a/upload-pack.c b/upload-pack.c
index 07c1505..878254d 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -60,7 +60,7 @@ static void create_pack_file(void)
close(fd[1]);
*p++ = "git-rev-list";
*p++ = "--objects";
- if (MAX_NEEDS <= nr_needs)
+ if (create_full_pack || MAX_NEEDS <= nr_needs)
*p++ = "--all";
else {
for (i = 0; i < nr_needs; i++) {
@@ -69,12 +69,13 @@ static void create_pack_file(void)
buf += 41;
}
}
- for (i = 0; i < nr_has; i++) {
- *p++ = buf;
- *buf++ = '^';
- memcpy(buf, sha1_to_hex(has_sha1[i]), 41);
- buf += 41;
- }
+ if (!create_full_pack)
+ for (i = 0; i < nr_has; i++) {
+ *p++ = buf;
+ *buf++ = '^';
+ memcpy(buf, sha1_to_hex(has_sha1[i]), 41);
+ buf += 41;
+ }
*p++ = NULL;
execvp("git-rev-list", argv);
die("git-upload-pack: unable to exec git-rev-list");
---
0.99.8.GIT
^ permalink raw reply related
* Re: git 565ebbf79f61873042c22a7126d002c104e056f4 broken on OpenBSD
From: Randal L. Schwartz @ 2005-10-26 14:24 UTC (permalink / raw)
To: git
In-Reply-To: <86y84gfjv4.fsf@blue.stonehenge.com>
>>>>> "Randal" == Randal L Schwartz <merlyn@stonehenge.com> writes:
Randal> gcc -o sha1_file.o -c -g -O2 -Wall -I/usr/local/include -L/usr/local/lib -Dstrcasestr=gitstrcasestr -DNO_STRCASESTR=1 -DSHA1_HEADER='<openssl/sha.h>' sha1_file.c
Randal> sha1_file.c: In function `move_temp_to_file':
Randal> sha1_file.c:1247: error: `ENOTSUP' undeclared (first use in this function)
Randal> sha1_file.c:1247: error: (Each undeclared identifier is reported only once
Randal> sha1_file.c:1247: error: for each function it appears in.)
Randal> gmake: *** [sha1_file.o] Error 1
got it... a bit messy, but here it is:
Subject: [PATCH] fix for openbsd
---
sha1_file.c | 6 +++++-
1 files changed, 5 insertions(+), 1 deletions(-)
applies-to: b16bae041dfd1c1081873f2e88a5f82858fb2051
28dcc3eaf13856585a81a24f1b4393032f825053
diff --git a/sha1_file.c b/sha1_file.c
index 7fdc469..1079ca5 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -1244,7 +1244,11 @@ int move_temp_to_file(const char *tmpfil
* When this succeeds, we just return 0. We have nothing
* left to unlink.
*/
- if ((ret == EXDEV || ret == ENOTSUP) && !rename(tmpfile, filename))
+ if ((ret == EXDEV
+#ifdef ENOTSUP
+ || ret == ENOTSUP
+#endif
+ ) && !rename(tmpfile, filename))
return 0;
ret = errno;
}
---
0.99.8.GIT
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply related
* Re: [PATCH] Avoid using dc in git-count-objects
From: Johannes Schindelin @ 2005-10-26 14:44 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <435F4B05.4010702@op5.se>
Hi,
On Wed, 26 Oct 2005, Andreas Ericsson wrote:
> I'd be more worried about the fact that the kilobytes count is way off
> as it is. du (at least from coreutils-5.2.1) rounds up to nearest
> kilobyte *for each file* when printing kb-count.
The rationale behind this: You want to know how much space it takes on
your hard disk. Remember, git-count-objects should give you a clue whether
to repack or not.
Actually, "du -k" in my tests rounds up to nearest block size or kilobytes
(whichever is greater): For example, "du -k" on a very small file (53
bytes) says "1" on an ext2fs yields "1", "4" on hfs, and 32 on a big
FAT32. Of course, you may get different values, since the block sizes
sometimes depend on the total size of the media.
Hth,
Dscho
^ permalink raw reply
* Re: [PATCH] Avoid using dc in git-count-objects
From: Andreas Ericsson @ 2005-10-26 14:55 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.63.0510261637070.26622@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> Hi,
>
> On Wed, 26 Oct 2005, Andreas Ericsson wrote:
>
>
>>I'd be more worried about the fact that the kilobytes count is way off
>>as it is. du (at least from coreutils-5.2.1) rounds up to nearest
>>kilobyte *for each file* when printing kb-count.
>
>
> The rationale behind this: You want to know how much space it takes on
> your hard disk. Remember, git-count-objects should give you a clue whether
> to repack or not.
>
Oh. I thought it was so I would know how much data would be sent over
the network. Diskspace is cheap, bandwidth is... well, that's cheap too
(in Sweden at least), but it's boring to wait.
> Actually, "du -k" in my tests rounds up to nearest block size or kilobytes
> (whichever is greater): For example, "du -k" on a very small file (53
> bytes) says "1" on an ext2fs yields "1", "4" on hfs, and 32 on a big
> FAT32. Of course, you may get different values, since the block sizes
> sometimes depend on the total size of the media.
>
From my du man-page:
-k like --block-size=1K
I think *most* du implementations work like this, but apparently not all
of them. I'll hack something up in C instead so it's at least consistent
regardless of what version of du is used.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: git 565ebbf79f61873042c22a7126d002c104e056f4 broken on OpenBSD
From: Johannes Schindelin @ 2005-10-26 15:09 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git
In-Reply-To: <86u0f4fjah.fsf@blue.stonehenge.com>
Hi,
On Wed, 26 Oct 2005, Randal L. Schwartz wrote:
> Randal> sha1_file.c:1247: error: `ENOTSUP' undeclared (first use in this
> function)
I thought ENOTSUP is POSIX standard?
What does your man page for link() say? If it is not supported, what value
will be in errno?
Ciao,
Dscho
^ permalink raw reply
* Re: git 565ebbf79f61873042c22a7126d002c104e056f4 broken on OpenBSD
From: Randal L. Schwartz @ 2005-10-26 15:10 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0510261708280.2803@wbgn013.biozentrum.uni-wuerzburg.de>
>>>>> "Johannes" == Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
Johannes> Hi,
Johannes> On Wed, 26 Oct 2005, Randal L. Schwartz wrote:
Randal> sha1_file.c:1247: error: `ENOTSUP' undeclared (first use in this
>> function)
Johannes> I thought ENOTSUP is POSIX standard?
Johannes> What does your man page for link() say? If it is not supported, what value
Johannes> will be in errno?
EOPNOTSUPP
Probably a BSD thing.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* Re: git-rev-list: make --dense the default (and introduce "--sparse")
From: Linus Torvalds @ 2005-10-26 15:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwtk08wnx.fsf@assigned-by-dhcp.cox.net>
On Wed, 26 Oct 2005, Junio C Hamano wrote:
>
> I have not looked closely into what exactly, but the fourth
> thing this does might be to break git-send-pack.
Ack. And I see why.
What happens is that the new logic decides that if it can't look up a
commit reference (ie "get_commit_reference()" returns NULL), the thing
must be a pathname.
Fair enough.
But wrong.
The thing is, it may be a perfectly fine ref that _isn't_ a commit. In
git, you have a tag that points to your PGP key, and in the kernel, I have
a tag that points to a tree (and a direct ref that points to that tree
too, for that matter).
So the rule is (as for all the other programs that mix revs and pathnames)
not that we only accept commit references, but _any_ valid object ref.
If the object then isn't a commit ref, git-rev-list will either ignore it,
or add it to the list of non-commit objects (if using "--objects").
The solution is to move the "get_sha1()" out of get_commit_reference(),
and into the callers. In fact, we already _have_ the SHA1 in the case of
the handle_all() loop, since for_each_ref() will have done it for us, so
this is the correct thing to do anyway.
This patch (on top of the original one) does exactly that.
Linus
----
diff --git a/rev-list.c b/rev-list.c
index ac7a47f..2b82b8a 100644
--- a/rev-list.c
+++ b/rev-list.c
@@ -613,13 +613,10 @@ static void add_pending_object(struct ob
add_object(obj, &pending_objects, name);
}
-static struct commit *get_commit_reference(const char *name, unsigned int flags)
+static struct commit *get_commit_reference(const char *name, const unsigned char *sha1, unsigned int flags)
{
- unsigned char sha1[20];
struct object *object;
- if (get_sha1(name, sha1))
- return NULL;
object = parse_object(sha1);
if (!object)
die("bad object %s", name);
@@ -697,7 +694,7 @@ static struct commit_list **global_lst;
static int include_one_commit(const char *path, const unsigned char *sha1)
{
- struct commit *com = get_commit_reference(path, 0);
+ struct commit *com = get_commit_reference(path, sha1, 0);
handle_one_commit(com, global_lst);
return 0;
}
@@ -720,6 +717,7 @@ int main(int argc, const char **argv)
const char *arg = argv[i];
char *dotdot;
struct commit *commit;
+ unsigned char sha1[20];
if (!strncmp(arg, "--max-count=", 12)) {
max_count = atoi(arg + 12);
@@ -808,15 +806,19 @@ int main(int argc, const char **argv)
flags = 0;
dotdot = strstr(arg, "..");
if (dotdot) {
+ unsigned char from_sha1[20];
char *next = dotdot + 2;
- struct commit *exclude = NULL;
- struct commit *include = NULL;
*dotdot = 0;
if (!*next)
next = "HEAD";
- exclude = get_commit_reference(arg, UNINTERESTING);
- include = get_commit_reference(next, 0);
- if (exclude && include) {
+ if (!get_sha1(arg, from_sha1) && !get_sha1(next, sha1)) {
+ struct commit *exclude;
+ struct commit *include;
+
+ exclude = get_commit_reference(arg, from_sha1, UNINTERESTING);
+ include = get_commit_reference(next, sha1, 0);
+ if (!exclude || !include)
+ die("Invalid revision range %s..%s", arg, next);
limited = 1;
handle_one_commit(exclude, &list);
handle_one_commit(include, &list);
@@ -829,9 +831,9 @@ int main(int argc, const char **argv)
arg++;
limited = 1;
}
- commit = get_commit_reference(arg, flags);
- if (!commit)
+ if (get_sha1(arg, sha1) < 0)
break;
+ commit = get_commit_reference(arg, sha1, flags);
handle_one_commit(commit, &list);
}
^ permalink raw reply related
* Re: git 565ebbf79f61873042c22a7126d002c104e056f4 broken on OpenBSD
From: Johannes Schindelin @ 2005-10-26 15:26 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git
In-Reply-To: <86mzkwfh54.fsf@blue.stonehenge.com>
Hi,
On Wed, 26 Oct 2005, Randal L. Schwartz wrote:
> >>>>> "Johannes" == Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> Johannes> What does your man page for link() say? If it is not
> Johannes> supported, what value will be in errno?
>
> EOPNOTSUPP
How about this, then:
---
Subject: [PATCH] Support EOPNOTSUPP of OpenBSD
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
Makefile | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
applies-to: 01ba9ea9d9dfba5ae94c32691ac8d9fdd859fccf
eaebda7362215aa0c7349e9971848c0535782a40
diff --git a/Makefile b/Makefile
index 4877abb..5cb7194 100644
--- a/Makefile
+++ b/Makefile
@@ -211,6 +211,7 @@ ifeq ($(uname_S),OpenBSD)
NO_STRCASESTR = YesPlease
NEEDS_LIBICONV = YesPlease
PLATFORM_DEFINES += -I/usr/local/include -L/usr/local/lib
+ PLATFORM_DEFINES += -DENOTSUP=EOPNOTSUPP
endif
ifneq (,$(findstring arm,$(uname_M)))
ARM_SHA1 = YesPlease
---
0.99.8.GIT
^ permalink raw reply related
* Re: git 565ebbf79f61873042c22a7126d002c104e056f4 broken on OpenBSD
From: Randal L. Schwartz @ 2005-10-26 15:30 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0510261725150.8507@wbgn013.biozentrum.uni-wuerzburg.de>
>>>>> "Johannes" == Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
Johannes> Hi,
Johannes> On Wed, 26 Oct 2005, Randal L. Schwartz wrote:
>> >>>>> "Johannes" == Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>>
Johannes> What does your man page for link() say? If it is not
Johannes> supported, what value will be in errno?
>>
>> EOPNOTSUPP
Interesting... google for "ENOTSUPP EOPNOTSUPP". Apparently
hits like this:
<http://sources.redhat.com/ml/bug-glibc/2002-08/msg00013.html>
shows that on some platforms, they may have both. This is not as
easy as it looks. Maybe define an extra || condition to handle either
or both?
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* Re: latest stg/git commandline completions code
From: Blaisorblade @ 2005-10-26 16:14 UTC (permalink / raw)
To: Catalin Marinas; +Cc: Ben Clifford, git
In-Reply-To: <b0943d9e0510260434y61dc5e50v@mail.gmail.com>
On Wednesday 26 October 2005 13:34, Catalin Marinas wrote:
> On 25/10/05, Blaisorblade <blaisorblade@yahoo.it> wrote:
> > They _would_ behave like cat, except that Python is slow enough. Half a
> > second on a (almost) idle system means seconds and seconds on a busy
> > system, and it's pretty frequent that when I don't wait enough for an op.
> > to complete I get a traceback from the import statements, which haven't
> > been completed.
> That's a thing I should fix in StGIT - trapping the exception
> generated by SIGTERM and exiting silently.
Yep.
> > And let's leave Gentoo's emerge alone - I'd say imports can take up to a
With imports I mean Python import statement, in the case of the Gentoo
"emerge" command (which is written in Python).
Not the import command (and checking the state of the tree can take tens of
minutes, here - with a non-idle machine, though).
> > minute.
--
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894)
http://www.user-mode-linux.org/~blaisorblade
___________________________________
Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB
http://mail.yahoo.it
^ permalink raw reply
* Re: git 565ebbf79f61873042c22a7126d002c104e056f4 broken on OpenBSD
From: Linus Torvalds @ 2005-10-26 16:11 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git
In-Reply-To: <86u0f4fjah.fsf@blue.stonehenge.com>
On Wed, 26 Oct 2005, Randal L. Schwartz wrote:
>
> got it... a bit messy, but here it is:
>
> Subject: [PATCH] fix for openbsd
I think we might as well do it for any error, and skip the test of the
actual errno entirely.
Linus
^ permalink raw reply
* Re: git 565ebbf79f61873042c22a7126d002c104e056f4 broken on OpenBSD
From: Jan Harkes @ 2005-10-26 16:15 UTC (permalink / raw)
To: git
In-Reply-To: <86irvkfg80.fsf@blue.stonehenge.com>
On Wed, Oct 26, 2005 at 08:30:39AM -0700, Randal L. Schwartz wrote:
> >> >>>>> "Johannes" == Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Johannes> What does your man page for link() say? If it is not
> Johannes> supported, what value will be in errno?
> >>
> >> EOPNOTSUPP
>
> Interesting... google for "ENOTSUPP EOPNOTSUPP". Apparently
> hits like this:
>
> <http://sources.redhat.com/ml/bug-glibc/2002-08/msg00013.html>
>
> shows that on some platforms, they may have both. This is not as
> easy as it looks. Maybe define an extra || condition to handle either
> or both?
It looks like glibc assumes that the kernel doesn't have ENOTSUP and
defines it as EOPNOTSUPP in <bits/errno.h>. So even if the kernel does
return different values, any glibc linked application probably wouldn't
be able to test for the ENOTSUP error.
Checking the SuSv2 manpage for link(2), it doesn't mention either of
these error codes. But does mention EPERM as a valid error when the
filesystem doesn't support hardlinks.
http://www.opengroup.org/onlinepubs/007908799/xsh/link.html
My local manual page for link(2) agrees with that definition,
EPERM oldpath is a directory.
EPERM The filesystem containing oldpath and newpath does not support
the creation of hard links.
I also took a look at the Linux 2.4/2.6 kernel sources, and msdos, fat
and vfat all do not set a function for 'dir->i_op->link'. In that case,
vfs_link() will return EPERM.
So I don't know where ENOTSUP/EOPNOTSUPP would be coming from. From the
few places I looked, I don't think the original patch can be right. Not
sure yet if I want to change Coda's return value to EPERM as well, the
thing is that we do support hardlinks, just not between different
directories, but I guess EXDEV isn't really accurate either.
Jan
^ permalink raw reply
* Re: git 565ebbf79f61873042c22a7126d002c104e056f4 broken on OpenBSD
From: Johannes Schindelin @ 2005-10-26 16:43 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Randal L. Schwartz, git
In-Reply-To: <Pine.LNX.4.64.0510260910290.10477@g5.osdl.org>
Hi,
On Wed, 26 Oct 2005, Linus Torvalds wrote:
> On Wed, 26 Oct 2005, Randal L. Schwartz wrote:
> >
> > got it... a bit messy, but here it is:
> >
> > Subject: [PATCH] fix for openbsd
>
> I think we might as well do it for any error, and skip the test of the
> actual errno entirely.
Hah! I beat you at your own game! (I already sent out a totally untested
patch ;-)
Ciao,
Dscho
^ permalink raw reply
* Re: git 565ebbf79f61873042c22a7126d002c104e056f4 broken on OpenBSD
From: Johannes Schindelin @ 2005-10-26 16:46 UTC (permalink / raw)
To: Jan Harkes; +Cc: git
In-Reply-To: <20051026161552.GA11483@delft.aura.cs.cmu.edu>
Hi,
On Wed, 26 Oct 2005, Jan Harkes wrote:
> Checking the SuSv2 manpage for link(2), it doesn't mention either of
> these error codes. But does mention EPERM as a valid error when the
> filesystem doesn't support hardlinks.
> http://www.opengroup.org/onlinepubs/007908799/xsh/link.html
>
> My local manual page for link(2) agrees with that definition,
>
> EPERM oldpath is a directory.
>
> EPERM The filesystem containing oldpath and newpath does not support
> the creation of hard links.
On my iBook, connecting a USB stick (FAT formatted), link() sets
errno=ENOTSUP. I checked the man page, and erroneously thought that they
got it right.
*turns his eyes helplessly to the sky*
Ciao,
Dscho
^ permalink raw reply
* Re: git 565ebbf79f61873042c22a7126d002c104e056f4 broken on OpenBSD
From: Jan Harkes @ 2005-10-26 16:55 UTC (permalink / raw)
To: git
In-Reply-To: <20051026161552.GA11483@delft.aura.cs.cmu.edu>
On Wed, Oct 26, 2005 at 12:15:52PM -0400, Jan Harkes wrote:
> Checking the SuSv2 manpage for link(2), it doesn't mention either of
> these error codes. But does mention EPERM as a valid error when the
> filesystem doesn't support hardlinks.
> http://www.opengroup.org/onlinepubs/007908799/xsh/link.html
Re-reading this, I seem to have misinterpreted the text. EPERM is
returned when the filesystem doesn't allow hard linking a directory.
I guess the closest error would actually be EMLINK, assuming that a
filesystem that doesn't support hardlinks would have LINK_MAX set to 1.
Linux returns EPERM
Coda returns EXDEV
BSDs seem to return EOPNOTSUPP.
MacOS X/Darwin doesn't mention it in their manpages.
Simply falling back on rename when there is any error, as Linus
suggested, seems like a pretty good solution right now. Rename should
give the same set of errors except when the link target already existed.
Jan
diff --git a/sha1_file.c b/sha1_file.c
index e456799..0eba58c 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -1234,15 +1234,14 @@ int move_temp_to_file(const char *tmpfil
int ret = link_temp_to_file(tmpfile, filename);
if (ret) {
/*
- * Coda hack - coda doesn't like cross-directory links,
- * so we fall back to a rename, which will mean that it
- * won't be able to check collisions, but that's not a
- * big deal.
+ * The file system may not support hardlinks, so we fall back
+ * to a rename. We won't be able to check for collisions, but
+ * that's not a big deal.
*
* When this succeeds, we just return 0. We have nothing
* left to unlink.
*/
- if (ret == EXDEV && !rename(tmpfile, filename))
+ if (ret && ret != EEXIST && !rename(tmpfile, filename))
return 0;
}
unlink(tmpfile);
^ permalink raw reply related
* Re: git 565ebbf79f61873042c22a7126d002c104e056f4 broken on OpenBSD
From: Johannes Schindelin @ 2005-10-26 17:03 UTC (permalink / raw)
To: Jan Harkes; +Cc: git
In-Reply-To: <20051026165515.GA16616@delft.aura.cs.cmu.edu>
Hi,
On Wed, 26 Oct 2005, Jan Harkes wrote:
> - if (ret == EXDEV && !rename(tmpfile, filename))
> + if (ret && ret != EEXIST && !rename(tmpfile, filename))
We don't need to test for ret, as we're already in a "if (ret)" block.
What would happen if ret==EEXIST, and we try to rename() nevertheless? It
should fail, too, right?
Ciao,
Dscho
^ permalink raw reply
* Re: git 565ebbf79f61873042c22a7126d002c104e056f4 broken on OpenBSD
From: Horst von Brand @ 2005-10-26 17:22 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git
In-Reply-To: <86u0f4fjah.fsf@blue.stonehenge.com>
Randal L. Schwartz <merlyn@stonehenge.com> wrote:
> >>>>> "Randal" == Randal L Schwartz <merlyn@stonehenge.com> writes:
>
> Randal> gcc -o sha1_file.o -c -g -O2 -Wall -I/usr/local/include -L/usr/local/lib -Dstrcasestr=gitstrcasestr -DNO_STRCASESTR=1 -DSHA1_HEADER='<openssl/sha.h>' sha1_file.c
> Randal> sha1_file.c: In function `move_temp_to_file':
> Randal> sha1_file.c:1247: error: `ENOTSUP' undeclared (first use in this function)
> Randal> sha1_file.c:1247: error: (Each undeclared identifier is reported only once
> Randal> sha1_file.c:1247: error: for each function it appears in.)
> Randal> gmake: *** [sha1_file.o] Error 1
>
> got it... a bit messy, but here it is:
>
> Subject: [PATCH] fix for openbsd
>
> ---
>
> sha1_file.c | 6 +++++-
> 1 files changed, 5 insertions(+), 1 deletions(-)
>
> applies-to: b16bae041dfd1c1081873f2e88a5f82858fb2051
> 28dcc3eaf13856585a81a24f1b4393032f825053
> diff --git a/sha1_file.c b/sha1_file.c
> index 7fdc469..1079ca5 100644
> --- a/sha1_file.c
> +++ b/sha1_file.c
> @@ -1244,7 +1244,11 @@ int move_temp_to_file(const char *tmpfil
> * When this succeeds, we just return 0. We have nothing
> * left to unlink.
> */
> - if ((ret == EXDEV || ret == ENOTSUP) && !rename(tmpfile, filename))
> + if ((ret == EXDEV
> +#ifdef ENOTSUP
> + || ret == ENOTSUP
> +#endif
> + ) && !rename(tmpfile, filename))
This is EVIL.... why not just:
#ifndef ENOTSUP
#define ENOTSUP EXDEV
#endif
someplace where it doesn't hurt the eyes? (The EXDEV makes the ENOTSUPP
fold away, I presume; not that it should really matter).
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
^ permalink raw reply
* Re: git 565ebbf79f61873042c22a7126d002c104e056f4 broken on OpenBSD
From: Linus Torvalds @ 2005-10-26 17:27 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jan Harkes, git
In-Reply-To: <Pine.LNX.4.63.0510261901140.9686@wbgn013.biozentrum.uni-wuerzburg.de>
On Wed, 26 Oct 2005, Johannes Schindelin wrote:
>
> On Wed, 26 Oct 2005, Jan Harkes wrote:
>
> > - if (ret == EXDEV && !rename(tmpfile, filename))
> > + if (ret && ret != EEXIST && !rename(tmpfile, filename))
>
> We don't need to test for ret, as we're already in a "if (ret)" block.
> What would happen if ret==EEXIST, and we try to rename() nevertheless? It
> should fail, too, right?
No, the rename will succeed and overwrite the existing file.
Which is strictly correct, but it's the wrong thing if we ever want to do
collission detection.
So I'd actually prefer something like this patch instead.
Linus
---
diff --git a/sha1_file.c b/sha1_file.c
index 7fdc469..642f00d 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -1232,19 +1232,20 @@ static int link_temp_to_file(const char
int move_temp_to_file(const char *tmpfile, char *filename)
{
int ret = link_temp_to_file(tmpfile, filename);
- if (ret) {
- /*
- * Coda hack - coda doesn't like cross-directory links,
- * so we fall back to a rename, which will mean that it
- * won't be able to check collisions, but that's not a
- * big deal.
- *
- * The same holds for FAT formatted media.
- *
- * When this succeeds, we just return 0. We have nothing
- * left to unlink.
- */
- if ((ret == EXDEV || ret == ENOTSUP) && !rename(tmpfile, filename))
+
+ /*
+ * Coda hack - coda doesn't like cross-directory links,
+ * so we fall back to a rename, which will mean that it
+ * won't be able to check collisions, but that's not a
+ * big deal.
+ *
+ * The same holds for FAT formatted media.
+ *
+ * When this succeeds, we just return 0. We have nothing
+ * left to unlink.
+ */
+ if (ret && ret != EEXIST) {
+ if (!rename(tmpfile, filename))
return 0;
ret = errno;
}
^ permalink raw reply related
* Re: 0.99.9 on Saturday next week.
From: Linus Torvalds @ 2005-10-26 17:55 UTC (permalink / raw)
To: Catalin Marinas; +Cc: Junio C Hamano, git
In-Reply-To: <b0943d9e0510260450k624268aav@mail.gmail.com>
On Wed, 26 Oct 2005, Catalin Marinas wrote:
>
> I use Python for StGIT and it has support for parsing .ini syntax, no
> need to use GIT for this (unless the syntax you chose would diverge
> too much).
The syntax differences I'm aware of:
- the git ".ini" parser is case-insensitive in the variable names. I
don't know if this is true in general. I do know a lot of people use
MixedCase things, but I don't know if it's because they care, or
because they think it's so pretty.
- the git parser accepts either ";" or "#" as comments, and anywhere on a
line (not just at the beginning). Again, others may or may not do the
same.
- the git parser wants a "=" for the assignment. I think the Python one
also accepts ":". If people care, we could make the git parser allow
either.
- duplicate entries. The git parser allows them, and will just pass them
on multiple times. In fact, I had a patch (that I threw out) that
depended on this, and allowed you to rewrite hostnames for git_connect
with something like
[host]
rewrite = "host.com:" "git://git.host.com/"
rewrite = "other.org:" "rsync://rsync.other.org/"
and the git config file parser happily just parses this as two
different entries for "host.rewrite"
- quoting. This is likely the big one. The git parser thinks only the
regular '"' character ("rabbit ears") is a quote, and passes single-
ticks through unmolested. I don't have a clue what others do, if
anything.
In the absense of quotes, most should be trivial to handle by just being
careful.
Linus
^ 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