* Re: daemon.c broken on OpenBSD
From: Randal L. Schwartz @ 2005-10-25 23:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <86r7a9jhq4.fsf@blue.stonehenge.com>
>>>>> "Randal" == Randal L Schwartz <merlyn@stonehenge.com> writes:
Randal> Actually, you probably want this instead:
And this one too, because .gitignore is missing some files:
>From nobody Mon Sep 17 00:00:00 2001
Subject: [PATCH] fix .gitignore to add new progs
From: Charlie <root@blue.stonehenge.com>
Date: 1130283408 -0700
---
.gitignore | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
applies-to: eba31d473719d9a1f2d00b40b3011460d7af864c
c0964c0160d7b08c0b5dd28d1b9462fd2b01bd50
diff --git a/.gitignore b/.gitignore
index 52cb9e2..758aaf6 100644
--- a/.gitignore
+++ b/.gitignore
@@ -54,6 +54,7 @@ git-merge-recursive
git-merge-resolve
git-merge-stupid
git-mktag
+git-mv
git-octopus
git-pack-objects
git-parse-remote
@@ -78,6 +79,7 @@ git-revert
git-send-email
git-send-pack
git-sh-setup
+git-shell
git-shortlog
git-show-branch
git-show-index
---
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
* [PATCH 2/4] create_symref: if symlink fails, fall back to writing a "symbolic ref"
From: Johannes Schindelin @ 2005-10-25 23:40 UTC (permalink / raw)
To: git, junkio
There are filesystems out there which do not understand symlinks, even if
the OS is perfectly capable of writing them. So, do not fail right away,
but try to write a symbolic ref first. If that fails, you can die().
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
refs.c | 11 ++++++-----
1 files changed, 6 insertions(+), 5 deletions(-)
applies-to: ccd3f478f6bdf8174f7d5d24d54434e66fa9068e
2e920b7169ad9661385ba02412cdbdc4e69e00a1
diff --git a/refs.c b/refs.c
index 97506a4..8b544e0 100644
--- a/refs.c
+++ b/refs.c
@@ -116,14 +116,16 @@ const char *resolve_ref(const char *path
int create_symref(const char *git_HEAD, const char *refs_heads_master)
{
-#if USE_SYMLINK_HEAD
- unlink(git_HEAD);
- return symlink(refs_heads_master, git_HEAD);
-#else
const char *lockpath;
char ref[1000];
int fd, len, written;
+#if USE_SYMLINK_HEAD
+ unlink(git_HEAD);
+ if (!symlink(refs_heads_master, git_HEAD))
+ return 0;
+#endif
+
len = snprintf(ref, sizeof(ref), "ref: %s\n", refs_heads_master);
if (sizeof(ref) <= len) {
error("refname too long: %s", refs_heads_master);
@@ -144,7 +146,6 @@ int create_symref(const char *git_HEAD,
return -3;
}
return 0;
-#endif
}
int read_ref(const char *filename, unsigned char *sha1)
---
0.99.8.GIT
^ permalink raw reply related
* [PATCH 1/4] git-init-db should error out with a message
From: Johannes Schindelin @ 2005-10-25 23:39 UTC (permalink / raw)
To: git, junkio
When the HEAD symref could not be created, it is helpful for the user to
know that.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
init-db.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
applies-to: 51f96562f1ef47cd9a09731e3f27445efaddbbe7
159c632ef3cc7371aaa495c41afd5fd41e2d3f3f
diff --git a/init-db.c b/init-db.c
index aabc09f..2c27e18 100644
--- a/init-db.c
+++ b/init-db.c
@@ -192,7 +192,7 @@ static void create_default_files(const c
strcpy(path + len, "HEAD");
if (read_ref(path, sha1) < 0) {
if (create_symref(path, "refs/heads/master") < 0)
- exit(1);
+ die("Could not create HEAD symref!");
}
path[len] = 0;
copy_templates(path, len, template_path);
---
0.99.8.GIT
^ permalink raw reply related
* [PATCH 0/4] Make git-clone work on a USB stick
From: Johannes Schindelin @ 2005-10-25 23:38 UTC (permalink / raw)
To: git, junkio
When I tried to git-clone something to a USB stick so that I could
carry the repository to a friend with a slow modem, I got stuck.
There were several issues (mostly having to do with limitations of
the FAT format), but none of them show stoppers.
This patch series solves all of these issues.
^ permalink raw reply
* Re: [PATCH] Make fetch-pack play nicer with servers which do not speak multi_ack
From: Junio C Hamano @ 2005-10-25 23:32 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0510251104470.24174@wbgn013.biozentrum.uni-wuerzburg.de>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=iso-2022-jp-2, Size: 1253 bytes --]
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Tue, 25 Oct 2005, Junio C Hamano wrote:
>
>> But you are right. If you made 20 commits on top of my "master"
>> branch head, we should send those 20 (and the commit you based
>> on your changes, which the other end has), way before sending
>> the ancient v0.99 tag. Probably, we should never be sending
>> v0.99 tag as "have" if we are going to send your "master" branch
>> head, since the commit that tag refers to is reachable by your
>> "master" branch head but there are a lot more commit between
>> them, some of which will give us better "common" selected, and
>> that v0.99 tag is what the other end said they have so is known
>> to be ACKed if sent.
>
> You^[.A^[N4re right. Complete common refs are sent even if they are ancestors of
> other complete common refs. I^[.A^[N4ll think about that.
I think you should be able to do something similar to what
git-show-branch --independent does, except that the current
show-branch implementation sucks. It wastes one-bit per ref
head, which is not too bad if we deal only with branches (who
would sanely keep more than 29 branches in a repo except Jeff
;-) but is useless for a repository with any reasonable history
and a lot of tags.
^ permalink raw reply
* Re: daemon.c broken on OpenBSD
From: Randal L. Schwartz @ 2005-10-25 23:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <86vezljhve.fsf@blue.stonehenge.com>
>>>>> "Randal" == Randal L Schwartz <merlyn@stonehenge.com> writes:
Randal> I can confirm that the following patch lets the current origin
Randal> compile on OpenBSD. If you could apply this until you sort out the
Randal> rest of the namespace issue, I would be happy. Thanks.
Actually, you probably want this instead:
Subject: [PATCH] openbsd patch
---
daemon.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
applies-to: 6234aa4f7095054a137e030030f914dc6633f809
7666c6f2cf2fcf41fce1d0665b79e5cc2f7b73b5
diff --git a/daemon.c b/daemon.c
index 0c6182f..c3f8641 100644
--- a/daemon.c
+++ b/daemon.c
@@ -1,5 +1,3 @@
-#include "cache.h"
-#include "pkt-line.h"
#include <signal.h>
#include <sys/wait.h>
#include <sys/socket.h>
@@ -9,6 +7,8 @@
#include <netinet/in.h>
#include <arpa/inet.h>
#include <syslog.h>
+#include "pkt-line.h"
+#include "cache.h"
static int log_syslog;
static int verbose;
---
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: daemon.c broken on OpenBSD
From: Randal L. Schwartz @ 2005-10-25 23:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v64rnsd83.fsf@assigned-by-dhcp.cox.net>
I can confirm that the following patch lets the current origin
compile on OpenBSD. If you could apply this until you sort out the
rest of the namespace issue, I would be happy. Thanks.
diff --git a/daemon.c b/daemon.c
index 0c6182f..c3f8641 100644
--- a/daemon.c
+++ b/daemon.c
@@ -1,5 +1,3 @@
-#include "cache.h"
-#include "pkt-line.h"
#include <signal.h>
#include <sys/wait.h>
#include <sys/socket.h>
@@ -9,6 +7,8 @@
#include <netinet/in.h>
#include <arpa/inet.h>
#include <syslog.h>
+#include "pkt-line.h"
+#include "cache.h"
static int log_syslog;
static int verbose;
--
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
* [PATCH] Avoid using dc in git-count-objects
From: Johannes Schindelin @ 2005-10-25 23:22 UTC (permalink / raw)
To: git, junkio
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.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
This is (again) something I found on a default cygwin setup:
dc is not installed. I do not even know if you can install
dc on cygwin without compiling it yourself.
FYI: I use git-count-objects in t5500-fetch-pack to find out
if the correct number of objects was fetched.
git-count-objects.sh | 14 ++++++++++----
1 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/git-count-objects.sh b/git-count-objects.sh
index 843d2fd..7f9d8e5 100755
--- a/git-count-objects.sh
+++ b/git-count-objects.sh
@@ -2,12 +2,18 @@
. git-sh-setup
+function sum () {
+ local result=0
+ while read line; do
+ result=$(expr $result + $line)
+ done
+ echo $result
+}
+
echo $(find "$GIT_DIR/objects"/?? -type f -print 2>/dev/null | wc -l) objects, \
$({
- echo 0
# "no-such" is to help Darwin folks by not using xargs -r.
find "$GIT_DIR/objects"/?? -type f -print 2>/dev/null |
xargs du -k "$GIT_DIR/objects/no-such" 2>/dev/null |
- sed -e 's/[ ].*/ +/'
- echo p
-} | dc) kilobytes
+ sed -e 's/[ ].*//'
+} | sum) kilobytes
^ permalink raw reply related
* [PATCH] Add git-name-rev
From: Johannes Schindelin @ 2005-10-25 23:05 UTC (permalink / raw)
To: git, junkio
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.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
This is a toy which may help you, too. In case it is still not
clear what it does:
$ git-name-rev 33db5f4d9027a10e477ccf054b2c1ab94f74c85a
33db5f4d9027a10e477ccf054b2c1ab94f74c85a v0.99^0~940
A thing like this is very useful for debugging git-fetch-pack: If
you see that a certain rev is common, you can now understand in
more detail where this rev is.
.gitignore | 1
Documentation/git-name-rev.txt | 47 ++++++++++++
Makefile | 2
name-rev.c | 162 ++++++++++++++++++++++++++++++++++++++++
4 files changed, 211 insertions(+), 1 deletions(-)
create mode 100644 Documentation/git-name-rev.txt
create mode 100644 name-rev.c
applies-to: 2152f0960114f638d74c4919a850dd597963ac52
bc2caae16f461e3b496d27e3f038cbb6d141706c
diff --git a/.gitignore b/.gitignore
index 52cb9e2..fe16651 100644
--- a/.gitignore
+++ b/.gitignore
@@ -54,6 +54,7 @@ git-merge-recursive
git-merge-resolve
git-merge-stupid
git-mktag
+git-name-rev
git-octopus
git-pack-objects
git-parse-remote
diff --git a/Documentation/git-name-rev.txt b/Documentation/git-name-rev.txt
new file mode 100644
index 0000000..6a7bb07
--- /dev/null
+++ b/Documentation/git-name-rev.txt
@@ -0,0 +1,47 @@
+git-name-rev(1)
+===============
+
+NAME
+----
+git-name-rev - Find symbolic names for given revs.
+
+
+SYNOPSIS
+--------
+'git-name-rev' <commitish>...
+
+DESCRIPTION
+-----------
+Finds symbolic names suitable for human digestion for revisions given in any
+format parsable by git-rev-parse.
+
+
+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.
+
+
+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
index d6fd706..4877abb 100644
--- 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..a3a095e
--- /dev/null
+++ b/name-rev.c
@@ -0,0 +1,162 @@
+#include <stdlib.h>
+#include "cache.h"
+#include "commit.h"
+#include "tag.h"
+#include "refs.h"
+
+static const char name_rev_usage[] =
+ "git-name-rev 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 name_ref(const char *path, const unsigned char *sha1)
+{
+ struct object *o = parse_object(sha1);
+ int deref = 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;
+}
+
+int main(int argc, char **argv)
+{
+ struct object_list *revs = NULL;
+ struct object_list **walker = &revs;
+ int as_is = 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;
+ }
+
+ 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);
+
+ for ( ; revs; revs = revs->next) {
+ struct rev_name *n = (struct rev_name *)revs->item->util;
+
+ printf("%s %s", revs->name, n->tip_name);
+ if (n->generation)
+ printf("~%d", n->generation);
+ printf("\n");
+ }
+
+ return 0;
+}
+
---
0.99.8.GIT
^ permalink raw reply related
* Re: git-rev-list: make --dense the default (and introduce "--sparse")
From: Linus Torvalds @ 2005-10-25 22:29 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0510251459070.10477@g5.osdl.org>
On Tue, 25 Oct 2005, Linus Torvalds wrote:
>
> This actually does three things:
>
> - make "--dense" the default for git-rev-list. Since dense is a no-op if
> no filenames are given, this doesn't actually change any historical
> behaviour, but it's logically the right default (if we want to prune on
> filenames, do it fully. The sparse "merge-only" thing may be useful,
> but it's not what you'd normally expect)
>
> - make "git-rev-parse" show the default revision control before it shows
> any pathnames.
Btw, if it wasn't obvious, this has some subtle (and very nice) side
effects.
For example, try this:
git log git-fetch.sh
and notice how "git log" automagically became able to give per-file logs.
With _zero_ changes to git-log.sh itself ;)
And same old rev-confusion-avoidance:
git log -- gitk
to make clear that you want to get the log of "gitk the file", rather than
"gitk the branch".
Magic.
Linus
^ permalink raw reply
* git-rev-list: make --dense the default (and introduce "--sparse")
From: Linus Torvalds @ 2005-10-25 22:24 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List
This actually does three things:
- make "--dense" the default for git-rev-list. Since dense is a no-op if
no filenames are given, this doesn't actually change any historical
behaviour, but it's logically the right default (if we want to prune on
filenames, do it fully. The sparse "merge-only" thing may be useful,
but it's not what you'd normally expect)
- make "git-rev-parse" show the default revision control before it shows
any pathnames.
This was a real bug, but nobody would ever have noticed, because
the default thing tends to only make sense for git-rev-list, and
git-rev-list didn't use to take pathnames.
- it changes "git-rev-list" to match the other commands that take a mix
of revisions and filenames - it no longer requires the "--" before
filenames (although you still need to do it if a filename could be
confused with a revision name, eg "gitk" in the git archive)
This all just makes for much more pleasant and obvous usage. Just doing a
gitk t/
does the obvious thing: it will show the history as it concerns the "t/"
subdirectory.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
---
NOTE! None of this will change anything that used to work before. But
things that used to make git-rev-list die with a usage message will now
possibly do things. In particular, it may do something that you don't
expect.
For example, let's say that you mis-type a revision name, and do
gitk v0.99.88
with one "8" too much. It used to cause gitk to die on you, echoing the
usage string from git-rev-list. Now it will cause gitk to start up
happily, and say "No commits selected", because there is no _file_ called
"v0.99.88" anywhere, so git-rev-list will end up with empty output.
So it does change behaviour, even if it doesn't change anything that was
_successful_ before.
For the same reasons, a
git-rev-list $(git-rev-parse --default HEAD v0.99.88)
will now give an empty list rather than an error usage string.
(But doing
git-rev-list v0.99.88
will still cause an error, since that doesn't have any revision at all!)
Comments? It really makes usage more "obvious", I think.
diff --git a/rev-list.c b/rev-list.c
index edf3b37..ac7a47f 100644
--- a/rev-list.c
+++ b/rev-list.c
@@ -28,7 +28,7 @@ static const char rev_list_usage[] =
" --merge-order [ --show-breaks ]\n"
" --topo-order";
-static int dense = 0;
+static int dense = 1;
static int unpacked = 0;
static int bisect_list = 0;
static int tag_objects = 0;
@@ -619,7 +619,7 @@ static struct commit *get_commit_referen
struct object *object;
if (get_sha1(name, sha1))
- usage(rev_list_usage);
+ return NULL;
object = parse_object(sha1);
if (!object)
die("bad object %s", name);
@@ -793,12 +793,12 @@ int main(int argc, const char **argv)
dense = 1;
continue;
}
+ if (!strcmp(arg, "--sparse")) {
+ dense = 0;
+ continue;
+ }
if (!strcmp(arg, "--")) {
- paths = get_pathspec(prefix, argv + i + 1);
- if (paths) {
- limited = 1;
- diff_tree_setup_paths(paths);
- }
+ i++;
break;
}
@@ -830,9 +830,20 @@ int main(int argc, const char **argv)
limited = 1;
}
commit = get_commit_reference(arg, flags);
+ if (!commit)
+ break;
handle_one_commit(commit, &list);
}
+ if (!list)
+ usage(rev_list_usage);
+
+ paths = get_pathspec(prefix, argv + i);
+ if (paths) {
+ limited = 1;
+ diff_tree_setup_paths(paths);
+ }
+
save_commit_buffer = verbose_header;
track_object_refs = 0;
diff --git a/rev-parse.c b/rev-parse.c
index 243f89f..adfc68c 100644
--- a/rev-parse.c
+++ b/rev-parse.c
@@ -153,6 +153,7 @@ static void show_datestring(const char *
static void show_file(const char *arg)
{
+ show_default();
if ((filter & (DO_NONFLAGS|DO_NOREV)) == (DO_NONFLAGS|DO_NOREV))
show(arg);
}
@@ -174,7 +175,6 @@ int main(int argc, char **argv)
if (*arg == '-') {
if (!strcmp(arg, "--")) {
as_is = 1;
- show_default();
/* Pass on the "--" if we show anything but files.. */
if (filter & (DO_FLAGS | DO_REVS))
show_file(arg);
^ permalink raw reply related
* Re: Convention for help in git commands?
From: Martin Langhoff @ 2005-10-25 22:07 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: git
In-Reply-To: <200510252335.47917.Josef.Weidendorfer@gmx.de>
On 10/26/05, Josef Weidendorfer <Josef.Weidendorfer@gmx.de> wrote:
> On Tuesday 25 October 2005 22:24, you wrote:
> > On 10/26/05, Junio C Hamano <junkio@cox.net> wrote:
> > > > * For commands which need at least one argument, the usage
> > > > is also printed, if the command is run without argument
> > >
> > > This is slightly debatable. I'd rather see it error out for one
> > > thing, and we might want to do a sane default given no arguments
> > > later.
> >
> > This could lead to subtle bugs when git is used by porcelains. If
> > there are going to be changes in default behaviours, let's have them
> > soon-ish ;-)
>
> What is the difference for a porcelain between error out,
> presumable with an error message, and printing the usage alone?
Sorry! My comment was aimed at the "do a sane default given no
arguments later" part of Junio's post. Error vs help messages don't
affect porcelains if you check your tty and avoid spitting out a help
message when invoked from a script ;-)
cheers,
martin
^ permalink raw reply
* [PATCH] Add some missing commands to the git.txt commands list
From: Petr Baudis @ 2005-10-25 22:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vsluph6vx.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Tue, Oct 25, 2005 at 06:57:06PM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> told me that...
> Also we need a link to this in either Ancillary (in which
> subsection I am not sure of, though) or Synching repository
> section of git.txt. I think we already lack links to a couple
> of recent commands there, so somebody needs to do another sweep
> of git.txt to make sure everything is listed.
for i in `l Documentation/*.txt | cut -d / -f 2 | cut -d . -f 1`; do
grep -q $i Documentation/git.txt || echo $i; done
But really, the more you have autogenerated, the better and more
consistent things are. In Cogito, I have all the documentation (usage
strings, synopsis, description, ...) at a _single_ place and everything
else (from command lists to various views of the docs) is autogenerated,
and it's a great help at making things complete and consistent. Also,
since it's inside of the code, people actually tend to remember to
update (and write in the first place) the documentation.
BTW, as of now, it appears that only the commands git-findtags and
git-fmt-merge-msg are undocumented.
---
[PATCH] Add some missing commands to the git.txt commands list
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
Documentation/git.txt | 18 ++++++++++++++++++
1 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/Documentation/git.txt b/Documentation/git.txt
index 769054b..054f091 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -209,6 +209,9 @@ gitlink:git-add[1]::
Add paths to the index file.
Previously this command was known as git-add-script.
+gitlink:git-am[1]::
+ Apply patches from a mailbox, but cooler.
+
gitlink:git-applymbox[1]::
Apply patches from a mailbox.
@@ -262,6 +265,9 @@ gitlink:git-ls-remote[1]::
gitlink:git-merge[1]::
Grand unified merge driver.
+gitlink:git-mv[1]::
+ Move or rename a file, a directory, or a symlink.
+
gitlink:git-octopus[1]::
Merge more than two commits.
Previously this command was known as git-octopus-script.
@@ -347,6 +353,9 @@ gitlink:git-relink[1]::
Hardlink common objects in local repositories.
Previously this command was known as git-relink-script.
+gitlink:git-svnimport[1]::
+ Import a SVN repository into git.
+
gitlink:git-sh-setup[1]::
Common git shell script setup code.
Previously this command was known as git-sh-setup-script.
@@ -355,9 +364,15 @@ gitlink:git-tag[1]::
An example script to create a tag object signed with GPG
Previously this command was known as git-tag-script.
+gitlink:git-update-ref[1]::
+ Update the object name stored in a ref safely.
+
Interrogators:
+gitlink:git-check-ref-format[1]::
+ Make sure ref name is well formed.
+
gitlink:git-cherry[1]::
Find commits not merged upstream.
@@ -395,6 +410,9 @@ gitlink:git-send-email[1]::
Send patch e-mails out of "format-patch --mbox" output.
Previously this command was known as git-send-email-script.
+gitlink:git-symbolic-refs[1]::
+ Read and modify symbolic refs.
+
gitlink:git-stripspace[1]::
Filter out empty lines.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply related
* git status and commit from subdirectory?
From: Daniel Barkalow @ 2005-10-25 21:51 UTC (permalink / raw)
To: git
It seems like everything that "git status" does can now be done from a
subdirectory (giving, of course, the status of the contents of the
subdirectory). I think the same might be true of "git commit", but I
haven't checked on everything. Is there anything that has to be done to
enable this properly other than removing the "|| die" part of the first
line?
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH] Documentation for git-shell
From: Petr Baudis @ 2005-10-25 21:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: gti
In-Reply-To: <7vsluph6vx.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Tue, Oct 25, 2005 at 06:57:06PM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> told me that...
> Thanks. I'd leave the door open for possibility of future
> command additions by saying what *kind* of things it is meant to
> allow spawning first and then listing what commands we
> *currently* allow next.
>
> Also we need a link to this in either Ancillary (in which
> subsection I am not sure of, though) or Synching repository
> section of git.txt.
Done.
---
[PATCH] Documentation for git-shell
This adds some simple documentation for git-shell.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
Documentation/git-shell.txt | 35 +++++++++++++++++++++++++++++++++++
Documentation/git.txt | 3 +++
2 files changed, 38 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-shell.txt b/Documentation/git-shell.txt
new file mode 100644
index 0000000..3f4d804
--- /dev/null
+++ b/Documentation/git-shell.txt
@@ -0,0 +1,35 @@
+git-shell(1)
+============
+
+NAME
+----
+git-shell - Restricted login shell for GIT over SSH only
+
+
+SYNOPSIS
+--------
+'git-shell -c <command> <argument>'
+
+DESCRIPTION
+-----------
+This is meant to be used as a login shell for SSH accounts you want
+to restrict to GIT pull/push access only. It permits execution only
+of server-side GIT commands implementing the pull/push functionality.
+The commands can be executed only by the '-c' option; the shell is not
+interactive.
+
+Currently, only the `git-receive-pack` and `git-upload-pack` commands
+are permitted to be called, with a single required argument.
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org>
+
+Documentation
+--------------
+Documentation by Petr Baudis and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the gitlink:git[7] suite
+
diff --git a/Documentation/git.txt b/Documentation/git.txt
index 796c4f6..769054b 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -182,6 +182,9 @@ gitlink:git-receive-pack[1]::
gitlink:git-send-pack[1]::
Pushes to a remote repository, intelligently.
+gitlink:git-shell[1]::
+ Restricted shell for GIT-only SSH access.
+
gitlink:git-ssh-fetch[1]::
Pulls from a remote repository over ssh connection
Previously this command was known as git-ssh-pull.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply related
* Re: Convention for help in git commands?
From: Josef Weidendorfer @ 2005-10-25 21:35 UTC (permalink / raw)
To: git
In-Reply-To: <46a038f90510251324s50911b88pb5eabb304644bcad@mail.gmail.com>
On Tuesday 25 October 2005 22:24, you wrote:
> On 10/26/05, Junio C Hamano <junkio@cox.net> wrote:
> > > * For commands which need at least one argument, the usage
> > > is also printed, if the command is run without argument
> >
> > This is slightly debatable. I'd rather see it error out for one
> > thing, and we might want to do a sane default given no arguments
> > later.
>
> This could lead to subtle bugs when git is used by porcelains. If
> there are going to be changes in default behaviours, let's have them
> soon-ish ;-)
What is the difference for a porcelain between error out,
presumable with an error message, and printing the usage alone?
Is there any dependency of porcelains to the fact the e.g.
"git-rev-list" currently does nothing if not called with a
commit-id? Somehow I think "git-rev-list" should give an error,
as the usage string (with lots of options on a line of its own ?!)
requires a commit-id as argument.
BTW, the error message of "mv" is:
===
mv: missing file operand
Try `mv --help' for more information.
===
What about something similar to this? Mentioning the command
which triggered the error is probably a good idea.
And I would add as another convention:
* "git-cmd -h" always should give the usage, and not error out
with "fatal: Not a git repository" before.
Josef
^ permalink raw reply
* [WIP] Implement a test for git-fetch-pack
From: Johannes Schindelin @ 2005-10-25 21:34 UTC (permalink / raw)
To: git
It does some basic things right now, but I'll add more.
---
t/t5500-fetch-pack.sh | 142 +++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 142 insertions(+), 0 deletions(-)
diff --git a/t/t5500-fetch-pack.sh b/t/t5500-fetch-pack.sh
new file mode 100755
index 0000000..a5d3a25
--- /dev/null
+++ b/t/t5500-fetch-pack.sh
@@ -0,0 +1,142 @@
+#!/bin/sh
+#
+# Copyright (c) 2005 Johannes Schindelin
+#
+
+test_description='Testing multi_ack pack fetching
+
+'
+. ./test-lib.sh
+
+# Test fetching for an empty, a partial, a full copy, and for a repository,
+# which is not empty but has no common commits (think coolest merge ever).
+
+function add () {
+ local name=$1
+ local branch=$(expr $name : '\(.\)')
+ local text="$@"
+ local parents=""
+
+ shift
+ while test $1; do
+ local sha1=$(eval echo \$$1)
+ test -z "$sha1" && sha1=$1
+ parents="$parents -p $sha1"
+ shift
+ done
+
+ echo "$text" > test.txt
+ git-update-index --add test.txt
+ tree=$(git-write-tree)
+ commit=$(echo "$text" | git-commit-tree $tree $parents 2>/dev/null)
+ export $name=$commit
+ echo $commit > .git/refs/heads/$branch
+ git-symbolic-ref HEAD refs/heads/$branch 2>/dev/null
+}
+
+function tag () {
+ local name=$1
+ local commit=$(eval echo \$$2)
+ local text="$@"
+
+ git-tag -m "$text" $name $commit
+}
+
+function count_objects () {
+ local line="$(git-count-objects)"
+ expr "$line" : '\([^ ]*\)'
+}
+
+function test_expect_object_count () {
+ local repository=$1
+ local count=$2
+
+ expect="$count objects, $count kilobytes"
+ output="$(git-count-objects)"
+ test_expect_success "$repository repository is valid" \
+ "test \"$output\" = \"$expect\""
+}
+
+function check_rep () {
+ local rep=$1
+ local count=$2
+
+ cd $rep
+ test_expect_success "fetch from upstream into $rep" \
+ 'git-fetch-pack -v .. A B C 2> log.txt'
+ git-update-ref HEAD $A46
+ test_expect_success "fsck $rep" 'git-fsck-objects --full'
+ test_expect_object_count $rep $count
+ cd ..
+}
+
+# A1 - A2 - A3 - A4 - A5 - .. - A47
+# \ \ / /
+# B1 - B2 ------ B3 - B4 - B5
+# \ / \
+# C1 - C2 - C3
+
+# the partial copy is cloned at A1-B3-C2 time.
+
+(
+ mkdir empty &&
+ cd empty &&
+ git-init-db 2>/dev/null
+)
+
+add B1
+
+pre_tag_count=$(count_objects)
+
+i=1; while [ $i -le 40 ]; do
+ tag T$i B1
+ i=$(expr $i + 1)
+done
+
+post_tag_count=$(count_objects)
+
+add A1
+add B2 B1 A1
+add B3 B2
+add C1 B2
+add C2 C1
+
+# clone
+git-clone . partial 2>/dev/null
+
+partial_count=$(count_objects)
+
+add A2 A1
+add A3 A2
+add A4 A3 C1
+add C3 C2 B3
+add A5 A4 B3
+add B4 B3
+add B5 B4
+i=5
+while [ $i -le 46 ]; do
+ next=$(expr $i + 1)
+ add A$next A$i
+ i=$next
+done
+
+total_count=$(count_objects)
+
+git-clone . full 2>/dev/null
+
+# let the testing begin
+
+test_expect_success 'precalculated counts' \
+ "test $post_tag_count:$partial_count:$total_count = 43:58:205"
+
+tag_count=$(expr $post_tag_count - $pre_tag_count)
+empty_diff=$(expr $total_count - $tag_count)
+partial_diff=$(expr $total_count - $partial_count)
+
+check_rep empty $empty_diff
+check_rep partial $partial_diff
+check_rep full 0
+
+#gitk --all
+
+test_done
^ permalink raw reply related
* Re: [PATCH 4/4] git-fetch-pack: Implement client part of the multi_ack extension
From: Johannes Schindelin @ 2005-10-25 21:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Alex Riesen, git
In-Reply-To: <7vvezlcnpi.fsf@assigned-by-dhcp.cox.net>
Hi,
On Tue, 25 Oct 2005, Junio C Hamano wrote:
> Alex Riesen <raa.lkml@gmail.com> writes:
>
> > Johannes Schindelin, Sun, Oct 23, 2005 03:40:13 +0200:
> >> This patch concludes the series, which makes
> >> git-fetch-pack/git-upload-pack negotiate a potentially better set of
> >> common revs. It should make a difference when fetching from a repository
> >> with a few branches.
> >
> > This broke git-pull for me (the local one):
>
> Is this the same problem I fixed with this commit, which sits at
> the tip on the "master" branch?
>
> commit 7efc8e43508b415e2540dbcb79521bde16c51e0c
> tree 6234aa4f7095054a137e030030f914dc6633f809
> parent 40a10462498bdd23d4e49f02867b8be50eb78704
> author Junio C Hamano <junkio@cox.net> 1130061738 -0700
> committer Junio C Hamano <junkio@cox.net> 1130192018 -0700
>
> upload-pack: fix thinko in common-commit finder code.
>
> The code to check if we have the object the other side has was bogus
> (my fault).
>
> Signed-off-by: Junio C Hamano <junkio@cox.net>
It looks to me like it is not. This looks more like upload-pack speaks
multi_ack, but fetch-pack does not, since it gets the "got ack ..
continue" too late.
I'll send out a patch implementing a first version of my "nasty"
fetch-pack tests in a few minutes. This test showed me my error.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 4/4] git-fetch-pack: Implement client part of the multi_ack extension
From: Junio C Hamano @ 2005-10-25 21:04 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <20051025204754.GA8030@steel.home>
Alex Riesen <raa.lkml@gmail.com> writes:
> Johannes Schindelin, Sun, Oct 23, 2005 03:40:13 +0200:
>> This patch concludes the series, which makes
>> git-fetch-pack/git-upload-pack negotiate a potentially better set of
>> common revs. It should make a difference when fetching from a repository
>> with a few branches.
>
> This broke git-pull for me (the local one):
Is this the same problem I fixed with this commit, which sits at
the tip on the "master" branch?
commit 7efc8e43508b415e2540dbcb79521bde16c51e0c
tree 6234aa4f7095054a137e030030f914dc6633f809
parent 40a10462498bdd23d4e49f02867b8be50eb78704
author Junio C Hamano <junkio@cox.net> 1130061738 -0700
committer Junio C Hamano <junkio@cox.net> 1130192018 -0700
upload-pack: fix thinko in common-commit finder code.
The code to check if we have the object the other side has was bogus
(my fault).
Signed-off-by: Junio C Hamano <junkio@cox.net>
^ permalink raw reply
* Re: [PATCH 4/4] git-fetch-pack: Implement client part of the multi_ack extension
From: Johannes Schindelin @ 2005-10-25 21:02 UTC (permalink / raw)
To: Alex Riesen; +Cc: git, junkio
In-Reply-To: <20051025204754.GA8030@steel.home>
Hi,
On Tue, 25 Oct 2005, Alex Riesen wrote:
> Johannes Schindelin, Sun, Oct 23, 2005 03:40:13 +0200:
> > This patch concludes the series, which makes
> > git-fetch-pack/git-upload-pack negotiate a potentially better set of
> > common revs. It should make a difference when fetching from a repository
> > with a few branches.
>
> This broke git-pull for me (the local one):
>
> /d/e/f.git$ git-pull
> fatal: bad pack file
> fatal: git-unpack-objects died with error code 128
> Fetch failure: /a/b/c/.git
>
> > applies-to: 6b4b7d9acf60aa99d961b599f37d0c824be79e27
> > 9adb6b3971e7daa79221d7dbe05b66327b266b86
> ...
> > diff --git a/fetch-pack.c b/fetch-pack.c
> > index 3a903c4..57602b9 100644
> > --- a/fetch-pack.c
> > +++ b/fetch-pack.c
>
> Reverting just fetch-pack.c part of the patch helps.
Could you please try the patch I sent with the subject "[PATCH]
fetch/upload: Fix corner case with few revs"? Your output looks exactly
like what I fixed with that patch.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] fetch/upload: Fix corner case with few revs
From: Johannes Schindelin @ 2005-10-25 20:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vll0hfqdb.fsf@assigned-by-dhcp.cox.net>
Hi,
On Tue, 25 Oct 2005, Junio C Hamano wrote:
> I've already pushed your initial set out to "master", but I
> suspect we may be better of if I recall them and let it simmer a
> bit longer in the proposed updates branch, and defer them post
> 0.99.9. What do you think?
Yes, please. Sorry for the problems.
Ciao,
Dscho
^ permalink raw reply
* Towards CVS code-exchange and gateways
From: Martin Langhoff @ 2005-10-25 20:57 UTC (permalink / raw)
To: Git Mailing List
Now that I have a few cvs2git gateways (git-cvsimport running on cron)
for the projects we work on, I am starting to need tools to "replay"
chunks of git history against external CVS repositories. So I am
thinking of writing two new scripts which expect to be executed inside
a CVS working copy:
+ "git-cvsapplypatch < patchfile" takes a patch as formatted by
git-format-patch, apply using patch (with options to be strict of
fuzzy), prepares the commit message and (optionally) autocommit if
patch returned clean.
+ "GIT_DIR=~/foo/bar/.git git-cvsreplaycommit parent:child" takes a
pair of git revisions that must be parent/child, applies the diff on
text files and changes on binary objects. Prepares the commit message
and (optionally) autocommits if the merge was clean.
Which should lead later to a git-cvsapplymbox script to automate the
process further. This part of the automation is actually a bit scary:
with git, all your scripted merges take place in your private repo,
and you review the result of the whole patchrun before pushing it out
to a public repo. With cvs, if the merge turns out to apply cleanly
but be a really bad idea... it'll be way too late. I hope to be able
to find a smart way to run it in "test" mode.
Is there anyone working on a git -> cvs gateway or similar scripts?
cheers,
martin
^ permalink raw reply
* Re: [PATCH 4/4] git-fetch-pack: Implement client part of the multi_ack extension
From: Alex Riesen @ 2005-10-25 20:47 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, junkio
In-Reply-To: <Pine.LNX.4.63.0510230339090.21239@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin, Sun, Oct 23, 2005 03:40:13 +0200:
> This patch concludes the series, which makes
> git-fetch-pack/git-upload-pack negotiate a potentially better set of
> common revs. It should make a difference when fetching from a repository
> with a few branches.
This broke git-pull for me (the local one):
/d/e/f.git$ git-pull
fatal: bad pack file
fatal: git-unpack-objects died with error code 128
Fetch failure: /a/b/c/.git
> applies-to: 6b4b7d9acf60aa99d961b599f37d0c824be79e27
> 9adb6b3971e7daa79221d7dbe05b66327b266b86
...
> diff --git a/fetch-pack.c b/fetch-pack.c
> index 3a903c4..57602b9 100644
> --- a/fetch-pack.c
> +++ b/fetch-pack.c
Reverting just fetch-pack.c part of the patch helps.
^ permalink raw reply
* Re: Convention for help in git commands?
From: Martin Langhoff @ 2005-10-25 20:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Josef Weidendorfer, git
In-Reply-To: <7vfyqpe87x.fsf@assigned-by-dhcp.cox.net>
On 10/26/05, Junio C Hamano <junkio@cox.net> wrote:
> > * For commands which need at least one argument, the usage
> > is also printed, if the command is run without argument
>
> This is slightly debatable. I'd rather see it error out for one
> thing, and we might want to do a sane default given no arguments
> later.
This could lead to subtle bugs when git is used by porcelains. If
there are going to be changes in default behaviours, let's have them
soon-ish ;-)
cheers,
martin
^ permalink raw reply
* Make "gitk" work better with dense revlists
From: Linus Torvalds @ 2005-10-25 20:01 UTC (permalink / raw)
To: Paul Mackerras, Junio C Hamano, Git Mailing List
To generate the diff for a commit, gitk used to do
git-diff-tree -p -C $p $id
(and same thing to generate filenames, except using just "-r" there) which
does actually generate the diff from the parent to the $id, exactly like
it meant to do.
However, that really sucks with --dense, where the "parent" information
has all been rewritten to point to the previous commit. The diff actually
works exactly right, but now it's the diff of the _whole_ sequence of
commits all the way to the previous commit that last changed the file(s)
that we are looking at.
And that's really not what we want 99.9% of the time, even if it may be
perfectly sensible. Not only will the diff not actually match the commit
message, but it will usually be _huge_, and all of it will be totally
uninteresting to us, since we were only interested in a particular set of
files.
It also doesn't match what we do when we write the patch to a file.
So this makes gitk just show the diff of _that_ commit.
We might even want to have some way to limit the diff to only the
filenames we're interested in, but it's often nice to see what else
changed at the same time, so that's secondary.
The merge diff handling is left alone, although I think that should also
be changed to only look at what that _particular_ merge did, not what it
did when compared to the faked-out parents.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
---
Hmm?
Also, having now tested the previous "handle root commit in the
TREECHANGED" logic a bit more, I think it's (a) stable and (b) the right
thing to do. Sign me off on that one too.
Linus
diff --git a/gitk b/gitk
index f1ea4e1..a9d37d9 100755
--- a/gitk
+++ b/gitk
@@ -2806,7 +2806,7 @@ proc gettreediffs {ids} {
set treediff {}
set id [lindex $ids 0]
set p [lindex $ids 1]
- if [catch {set gdtf [open "|git-diff-tree -r $p $id" r]}] return
+ if [catch {set gdtf [open "|git-diff-tree -r $id" r]}] return
fconfigure $gdtf -blocking 0
fileevent $gdtf readable [list gettreediffline $gdtf $ids]
}
@@ -2842,7 +2842,7 @@ proc getblobdiffs {ids} {
set id [lindex $ids 0]
set p [lindex $ids 1]
set env(GIT_DIFF_OPTS) $diffopts
- set cmd [list | git-diff-tree -r -p -C $p $id]
+ set cmd [list | git-diff-tree -r -p -C $id]
if {[catch {set bdf [open $cmd r]} err]} {
puts "error getting diffs: $err"
return
^ 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