* Re: [PATCH] Support wholesale directory renames in fast-import
From: Shawn O. Pearce @ 2007-07-10 13:55 UTC (permalink / raw)
To: Rogan Dawes; +Cc: David Frech, git
In-Reply-To: <469346D8.4080906@dawes.za.net>
Rogan Dawes <lists@dawes.za.net> wrote:
> Shawn O. Pearce wrote:
> >-Zero or more `filemodify`, `filedelete` and `filedeleteall` commands
> >+Zero or more `filemodify`, `filedelete`, `filename` and
> ^^ filerename
Ugh. Thanks. I just pushed out a corrected version.
--
Shawn.
^ permalink raw reply
* Re: git-svn and renames
From: Florian Weimer @ 2007-07-10 13:42 UTC (permalink / raw)
To: git
In-Reply-To: <46938594.2010607@dawes.za.net>
* Rogan Dawes:
> $ git svn dcommit
> RA layer request failed: PROPFIND request failed on '/svn/trunk/
> webgoat/main/project/JavaSource/org/owasp/webgoat/lessons/DefaultLessonAction.java':
> PROPFIND of '/svn/trunk/
> webgoat/main/project/JavaSource/org/owasp/webgoat/lessons/DefaultLessonAction.java':
> 400 Bad Request (https://webgoat.googlecode.com) at
> /home/rdawes/bin/git-svn line 400
Does the "lessons" directory exist before that commit?
^ permalink raw reply
* Re: git-svn problems with branches containing spaces
From: Gerrit Pape @ 2007-07-10 13:42 UTC (permalink / raw)
To: git
In-Reply-To: <3F225D5F64550C4AA5F23286244275D4298C84@srvkrsexc07.nov.com>
On Wed, Jun 27, 2007 at 08:53:06AM +0200, Ewald, Robert wrote:
> As I have reported yesterday on IRC, git-svn has problems with branches
> containing spaces.
> I get the following message, when I want to clone from the repository
> containing a branch with a space.
> Cloning until the revision the branch is created everything works fine.
>
> fatal: refs/remotes/Modbus Error Limit Fix: cannot lock the ref
> update-ref -m r1897 refs/remotes/Modbus Error Limit Fix
> ff0819c8e9c97c24e9865bc868c503fd9b64f980: command returned error: 128
>
> Thanks for your help.
Hi, the same problem has been reported some time ago through
http://bugs.debian.org/430518
There's a patch attached to the report, but from a first glance, I don't
think it's the solution.
Thanks, Gerrit.
^ permalink raw reply
* [PATCH] Teach the --cover-letter option to format-patch
From: Johannes Schindelin @ 2007-07-10 13:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Daniel Barkalow, git
In-Reply-To: <7vejjgsq3y.fsf@assigned-by-dhcp.cox.net>
You can now generate a template for the cover letter by calling
git format-patch --cover-letter <...>
It will fill in the shortlog and diffstat for you.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
On Mon, 9 Jul 2007, Junio C Hamano wrote:
> Daniel Barkalow <barkalow@iabervon.org> writes:
>
> > I'd like to be able to get format-patch to produce a
> > [PATCH 0/N] message, with a message that's actually in my
> > repository, plus various goodies generated either from diffing
> > the ends of the series or by running through the log an extra
> > time to pick up summary information.
>
> $ work work work, commit commit commit, reorder and perfect
> $ git format-patch --with-cover origin..HEAD
> ... which notices --with-cover, and perhaps does
> ... $ git-shortlog origin..HEAD
> ... $ git diff --stat --summary origin..HEAD
> ... $ echo "*** BLURB HERE ***"
> ... to create 0/N which it did not do so far in
> ... 0000-cover-letter.txt
> $ $EDITOR 0000-cover-letter.txt
> $ git-send-email 0*.txt
Voila.
BTW format-patch does not complain when there are skipped merges.
It surprised me, since you do not stand a chance to pipe that to
git-am successfully...
Documentation/git-format-patch.txt | 6 +
builtin-log.c | 202 ++++++++++++++------
log-tree.c | 2 +-
log-tree.h | 1 +
t/t4013-diff-various.sh | 1 +
...tch_--stdout_--cover-letter_-n_initial..master^ | 101 ++++++++++
6 files changed, 254 insertions(+), 59 deletions(-)
create mode 100644 t/t4013/diff.format-patch_--stdout_--cover-letter_-n_initial..master^
diff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt
index 6cbcf93..aaae083 100644
--- a/Documentation/git-format-patch.txt
+++ b/Documentation/git-format-patch.txt
@@ -16,6 +16,7 @@ SYNOPSIS
[--in-reply-to=Message-Id] [--suffix=.<sfx>]
[--ignore-if-in-upstream]
[--subject-prefix=Subject-Prefix]
+ [--cover-letter]
<since>[..<until>]
DESCRIPTION
@@ -126,6 +127,11 @@ want a filename like `0001-description-of-my-change.patch`, and
the first letter does not have to be a dot. Leaving it empty would
not add any suffix.
+--cover-letter::
+ Generate a cover letter template. You still have to fill in
+ a description, but the shortlog and the diffstat will be
+ generated for you.
+
CONFIGURATION
-------------
You can specify extra mail header lines to be added to each
diff --git a/builtin-log.c b/builtin-log.c
index 13bae31..e2b5e64 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -14,6 +14,7 @@
#include "reflog-walk.h"
#include "patch-ids.h"
#include "refs.h"
+#include "run-command.h"
static int default_show_root = 1;
static const char *fmt_patch_subject_prefix = "PATCH";
@@ -303,74 +304,77 @@ static int git_format_config(const char *var, const char *value)
}
+static const char *get_oneline_for_filename(struct commit *commit,
+ int keep_subject)
+{
+ static char filename[PATH_MAX];
+ char *sol;
+ int len = 0;
+
+ sol = strstr(commit->buffer, "\n\n");
+ if (!sol)
+ filename[0] = '\0';
+ else {
+ int j, space = 0;
+
+ sol += 2;
+ /* strip [PATCH] or [PATCH blabla] */
+ if (!keep_subject && !prefixcmp(sol, "[PATCH")) {
+ char *eos = strchr(sol + 6, ']');
+ if (eos) {
+ while (isspace(*eos))
+ eos++;
+ sol = eos;
+ }
+ }
+
+ for (j = 0; len < sizeof(filename) &&
+ sol[j] && sol[j] != '\n'; j++) {
+ if (istitlechar(sol[j])) {
+ if (space) {
+ filename[len++] = '-';
+ space = 0;
+ }
+ filename[len++] = sol[j];
+ if (sol[j] == '.')
+ while (sol[j + 1] == '.')
+ j++;
+ } else
+ space = 1;
+ }
+ while (filename[len - 1] == '.'
+ || filename[len - 1] == '-')
+ len--;
+ filename[len] = '\0';
+ }
+ return filename;
+}
+
static FILE *realstdout = NULL;
static const char *output_directory = NULL;
-static int reopen_stdout(struct commit *commit, int nr, int keep_subject,
- int numbered_files)
+static int reopen_stdout(const char *oneline, int nr, int total)
{
char filename[PATH_MAX];
- char *sol;
- int len = 0;
int suffix_len = strlen(fmt_patch_suffix) + 1;
+ int len = 0;
if (output_directory) {
- if (strlen(output_directory) >=
+ len = snprintf(filename, sizeof(filename), "%s",
+ output_directory);
+ if (len >=
sizeof(filename) - FORMAT_PATCH_NAME_MAX - suffix_len)
return error("name of output directory is too long");
- strlcpy(filename, output_directory, sizeof(filename) - suffix_len);
- len = strlen(filename);
if (filename[len - 1] != '/')
filename[len++] = '/';
}
- if (numbered_files) {
- sprintf(filename + len, "%d", nr);
- len = strlen(filename);
-
- } else {
- sprintf(filename + len, "%04d", nr);
- len = strlen(filename);
-
- sol = strstr(commit->buffer, "\n\n");
- if (sol) {
- int j, space = 1;
-
- sol += 2;
- /* strip [PATCH] or [PATCH blabla] */
- if (!keep_subject && !prefixcmp(sol, "[PATCH")) {
- char *eos = strchr(sol + 6, ']');
- if (eos) {
- while (isspace(*eos))
- eos++;
- sol = eos;
- }
- }
-
- for (j = 0;
- j < FORMAT_PATCH_NAME_MAX - suffix_len - 5 &&
- len < sizeof(filename) - suffix_len &&
- sol[j] && sol[j] != '\n';
- j++) {
- if (istitlechar(sol[j])) {
- if (space) {
- filename[len++] = '-';
- space = 0;
- }
- filename[len++] = sol[j];
- if (sol[j] == '.')
- while (sol[j + 1] == '.')
- j++;
- } else
- space = 1;
- }
- while (filename[len - 1] == '.'
- || filename[len - 1] == '-')
- len--;
- filename[len] = 0;
- }
- if (len + suffix_len >= sizeof(filename))
- return error("Patch pathname too long");
+ if (!filename)
+ len += sprintf(filename + len, "%d", nr);
+ else {
+ len += sprintf(filename + len, "%04d-", nr);
+ len += snprintf(filename + len, sizeof(filename) - len - 1
+ - suffix_len, "%s", oneline);
strcpy(filename + len, fmt_patch_suffix);
}
@@ -438,6 +442,70 @@ static void gen_message_id(char *dest, unsigned int length, char *base)
(int)(email_end - email_start - 1), email_start + 1);
}
+static void make_cover_letter(struct rev_info *rev,
+ int use_stdout, int numbered, int numbered_files,
+ struct commit *origin, struct commit *head)
+{
+ const char *committer, *sep;
+ const char *origin_sha1, *head_sha1;
+ const char *argv[7];
+
+ if (rev->commit_format != CMIT_FMT_EMAIL)
+ die("Cover letter needs email format");
+
+ if (!use_stdout && reopen_stdout(numbered_files ?
+ NULL : "cover-letter", 0, rev->total))
+ return;
+
+ origin_sha1 = sha1_to_hex(origin ? origin->object.sha1 : null_sha1);
+ head_sha1 = sha1_to_hex(head->object.sha1);
+
+ printf("From %s Mon Sep 17 00:00:00 2001\n", head_sha1);
+ if (rev->message_id)
+ printf("Message-Id: <%s>\n", rev->message_id);
+ if (rev->ref_message_id)
+ printf("In-Reply-To: <%s>\nReferences: <%s>\n",
+ rev->ref_message_id, rev->ref_message_id);
+ committer = git_committer_info(0);
+ sep = strchr(committer, '>');
+ if (sep)
+ sep++;
+ else
+ sep = committer + strlen(committer);
+ printf("From: %.*s\n", sep - committer, committer);
+ printf("Date:%s\n", sep);
+ if (rev->total)
+ printf("Subject: [%s %0*d/%d] *** SUBJECT HERE ***\n",
+ rev->subject_prefix,
+ digits_in_number(rev->total), 0, rev->total);
+ else
+ printf("Subject: *** SUBJECT HERE ***\n");
+ printf("\n\n");
+
+ printf("*** BLURB HERE ***\n\n");
+
+ argv[0] = "shortlog";
+ argv[1] = head_sha1;
+ argv[2] = "--not";
+ argv[3] = origin_sha1;
+ argv[4] = NULL;
+ fflush(stdout);
+ run_command_v_opt(argv, RUN_GIT_CMD);
+
+ argv[0] = "diff";
+ argv[1] = "--stat";
+ argv[2] = "--summary";
+ argv[3] = head_sha1;
+ argv[4] = "--not";
+ argv[5] = origin_sha1;
+ argv[6] = NULL;
+ fflush(stdout);
+ run_command_v_opt(argv, RUN_GIT_CMD);
+
+ fflush(stdout);
+ printf("\n");
+}
+
int cmd_format_patch(int argc, const char **argv, const char *prefix)
{
struct commit *commit;
@@ -452,6 +520,8 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)
int subject_prefix = 0;
int ignore_if_in_upstream = 0;
int thread = 0;
+ int cover_letter = 0;
+ struct commit *origin = NULL, *head = NULL;
const char *in_reply_to = NULL;
struct patch_ids ids;
char *add_signoff = NULL;
@@ -550,6 +620,8 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)
rev.subject_prefix = argv[i] + 17;
} else if (!prefixcmp(argv[i], "--suffix="))
fmt_patch_suffix = argv[i] + 9;
+ else if (!strcmp(argv[i], "--cover-letter"))
+ cover_letter = 1;
else
argv[j++] = argv[i];
}
@@ -594,6 +666,17 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)
* get_revision() would return only the specified count.
*/
}
+ if (cover_letter) {
+ /* remember the range */
+ int i;
+ for (i = 0; i < rev.pending.nr; i++) {
+ struct object *o = rev.pending.objects[i].item;
+ if (o->flags & UNINTERESTING)
+ origin = (struct commit *)o;
+ else
+ head = (struct commit *)o;
+ }
+ }
if (ignore_if_in_upstream)
get_patch_ids(&rev, &ids, prefix);
@@ -618,6 +701,9 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)
total = nr;
if (numbered)
rev.total = total + start_number - 1;
+ if (cover_letter)
+ make_cover_letter(&rev, use_stdout, numbered, numbered_files,
+ origin, head);
rev.add_signoff = add_signoff;
rev.ref_message_id = in_reply_to;
while (0 <= --nr) {
@@ -636,10 +722,10 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)
sha1_to_hex(commit->object.sha1));
rev.message_id = message_id;
}
- if (!use_stdout)
- if (reopen_stdout(commit, rev.nr, keep_subject,
- numbered_files))
- die("Failed to create output files");
+ if (!use_stdout && reopen_stdout(numbered_files ? NULL :
+ get_oneline_for_filename(commit, keep_subject),
+ rev.nr, rev.total))
+ die("Failed to create output files");
shown = log_tree_commit(&rev, commit);
free(commit->buffer);
commit->buffer = NULL;
diff --git a/log-tree.c b/log-tree.c
index 8624d5a..5c20c74 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -130,7 +130,7 @@ static unsigned long append_signoff(char **buf_p, unsigned long *buf_sz_p,
return at;
}
-static unsigned int digits_in_number(unsigned int number)
+unsigned int digits_in_number(unsigned int number)
{
unsigned int i = 10, result = 1;
while (i <= number) {
diff --git a/log-tree.h b/log-tree.h
index e82b56a..fbab51f 100644
--- a/log-tree.h
+++ b/log-tree.h
@@ -12,5 +12,6 @@ int log_tree_diff_flush(struct rev_info *);
int log_tree_commit(struct rev_info *, struct commit *);
int log_tree_opt_parse(struct rev_info *, const char **, int);
void show_log(struct rev_info *opt, const char *sep);
+unsigned int digits_in_number(unsigned int number);
#endif
diff --git a/t/t4013-diff-various.sh b/t/t4013-diff-various.sh
index 9eec754..6b4d1c5 100755
--- a/t/t4013-diff-various.sh
+++ b/t/t4013-diff-various.sh
@@ -245,6 +245,7 @@ format-patch --inline --stdout initial..master
format-patch --inline --stdout --subject-prefix=TESTCASE initial..master
config format.subjectprefix DIFFERENT_PREFIX
format-patch --inline --stdout initial..master^^
+format-patch --stdout --cover-letter -n initial..master^
diff --abbrev initial..side
diff -r initial..side
diff --git a/t/t4013/diff.format-patch_--stdout_--cover-letter_-n_initial..master^ b/t/t4013/diff.format-patch_--stdout_--cover-letter_-n_initial..master^
new file mode 100644
index 0000000..b66a568
--- /dev/null
+++ b/t/t4013/diff.format-patch_--stdout_--cover-letter_-n_initial..master^
@@ -0,0 +1,101 @@
+$ git format-patch --stdout --cover-letter -n initial..master^
+From 9a6d4949b6b76956d9d5e26f2791ec2ceff5fdc0 Mon Sep 17 00:00:00 2001
+From: C O Mitter <committer@example.com>
+Date: 1151280300 +0000
+Subject: [DIFFERENT_PREFIX 0/2] *** SUBJECT HERE ***
+
+
+*** BLURB HERE ***
+
+A U Thor (2):
+ Second
+ Third
+
+ dir/sub | 4 ++++
+ file0 | 3 +++
+ file1 | 3 +++
+ file2 | 3 ---
+ 4 files changed, 10 insertions(+), 3 deletions(-)
+ create mode 100644 file1
+ delete mode 100644 file2
+
+From 1bde4ae5f36c8d9abe3a0fce0c6aab3c4a12fe44 Mon Sep 17 00:00:00 2001
+From: A U Thor <author@example.com>
+Date: Mon, 26 Jun 2006 00:01:00 +0000
+Subject: [DIFFERENT_PREFIX 1/2] Second
+
+This is the second commit.
+---
+ dir/sub | 2 ++
+ file0 | 3 +++
+ file2 | 3 ---
+ 3 files changed, 5 insertions(+), 3 deletions(-)
+ delete mode 100644 file2
+
+diff --git a/dir/sub b/dir/sub
+index 35d242b..8422d40 100644
+--- a/dir/sub
++++ b/dir/sub
+@@ -1,2 +1,4 @@
+ A
+ B
++C
++D
+diff --git a/file0 b/file0
+index 01e79c3..b414108 100644
+--- a/file0
++++ b/file0
+@@ -1,3 +1,6 @@
+ 1
+ 2
+ 3
++4
++5
++6
+diff --git a/file2 b/file2
+deleted file mode 100644
+index 01e79c3..0000000
+--- a/file2
++++ /dev/null
+@@ -1,3 +0,0 @@
+-1
+-2
+-3
+--
+g-i-t--v-e-r-s-i-o-n
+
+
+From 9a6d4949b6b76956d9d5e26f2791ec2ceff5fdc0 Mon Sep 17 00:00:00 2001
+From: A U Thor <author@example.com>
+Date: Mon, 26 Jun 2006 00:02:00 +0000
+Subject: [DIFFERENT_PREFIX 2/2] Third
+
+---
+ dir/sub | 2 ++
+ file1 | 3 +++
+ 2 files changed, 5 insertions(+), 0 deletions(-)
+ create mode 100644 file1
+
+diff --git a/dir/sub b/dir/sub
+index 8422d40..cead32e 100644
+--- a/dir/sub
++++ b/dir/sub
+@@ -2,3 +2,5 @@ A
+ B
+ C
+ D
++E
++F
+diff --git a/file1 b/file1
+new file mode 100644
+index 0000000..b1e6722
+--- /dev/null
++++ b/file1
+@@ -0,0 +1,3 @@
++A
++B
++C
+--
+g-i-t--v-e-r-s-i-o-n
+
+$
--
1.5.3.rc0.2782.g192a9-dirty
^ permalink raw reply related
* Re: I used git pull instead of stg pull !
From: Karl Hasselström @ 2007-07-10 13:29 UTC (permalink / raw)
To: Jean-Christian de Rivaz; +Cc: git
In-Reply-To: <469356EF.201@eclis.ch>
On 2007-07-10 11:52:47 +0200, Jean-Christian de Rivaz wrote:
> I have made the error to use the "git pull" command instead of the
> "stg pull" command. The "git pull" have been executed successfuly,
> but now stg seem to be confused:
>
> stg pull -n
> stg pull: local changes in the tree. Use "refresh" to commit them
>
> stg new dummy -m "dummy"
> stg new: HEAD and top are not the same. You probably committed
> changes to the tree outside of StGIT. If you know what you
> are doing, use the "refresh -f" command
>
> How can I restore the archive to a normal state for stg ?
The problem is that you have committed a merge on top of the StGIT
stack, and StGIT can't deal with that. You can undo the merge
(provided that you haven't committed anything else on top of it) with
"git reset --hard HEAD^".
NOTE: "reset --hard" will erase uncommitted modifications to working
tree files, so first make sure that "git status" doesn't report any
modifications you want to keep.
If you want to get a better view of what it is you're doing, you could
fire up gitk and find the sha1 of the commit that is supposed to be at
the top of the StGIT stack, and "git reset <sha1>" to that commit.
Once the merge is undone, just "stg pull" like you wanted to do in the
first place.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Patch for Makefile - LIBMD_SHA1: -lmd on FreeBSD
From: Ed Schouten @ 2007-07-10 13:19 UTC (permalink / raw)
To: git
[-- Attachment #1.1: Type: text/plain, Size: 461 bytes --]
Hello,
Once in a while I send in some patches to the FreeBSD folks for the
devel/git port. I just wrote a patch for Git that makes it possible to
link it against the FreeBSD Message Digest library (libmd), removing the
dependency on OpenSSL.
The patch adds the switch LIBMD_SHA1. When set, it just uses sha.h and
-lmd. I've also added proper documentation to the top of the Makefile.
Yours,
--
Ed Schouten <ed@fxq.nl>
WWW: http://g-rave.nl/
[-- Attachment #1.2: git-libmd.diff --]
[-- Type: text/x-diff, Size: 835 bytes --]
--- Makefile 2007-07-10 15:16:03.000000000 +0200
+++ Makefile 2007-07-10 15:17:31.000000000 +0200
@@ -55,6 +55,9 @@
# specify your own (or DarwinPort's) include directories and
# library directories by defining CFLAGS and LDFLAGS appropriately.
#
+# Define LIBMD_SHA1 environment variable when running make to make use
+# of FreeBSD's libmd SHA1 routines.
+#
# Define PPC_SHA1 environment variable when running make to make use of
# a bundled SHA1 routine optimized for PowerPC.
#
@@ -637,6 +640,10 @@
BASIC_CFLAGS += -DOLD_ICONV
endif
+ifdef LIBMD_SHA1
+ SHA1_HEADER = "sha.h"
+ EXTLIBS += -lmd
+else
ifdef PPC_SHA1
SHA1_HEADER = "ppc/sha1.h"
LIB_OBJS += ppc/sha1.o ppc/sha1ppc.o
@@ -654,6 +661,7 @@
endif
endif
endif
+endif
ifdef NO_PERL_MAKEMAKER
export NO_PERL_MAKEMAKER
endif
[-- Attachment #2: Type: application/pgp-signature, Size: 187 bytes --]
^ permalink raw reply
* Re: [RFC] series headers
From: Theodore Tso @ 2007-07-10 13:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Daniel Barkalow, git
In-Reply-To: <7vejjgsq3y.fsf@assigned-by-dhcp.cox.net>
On Mon, Jul 09, 2007 at 11:57:21PM -0700, Junio C Hamano wrote:
> I suspect that temptation to touch rev_info.commit_format arises
> purely because you are thinking about making 0/N a (perhaps
> fake) commit. I do not see a point in that.
>
> What is the workflow?
In general a patch series goes through multiple cycles of
improvements, where people send it out for review/comment, and then it
gets fixed up, etc. etc. So you don't want to just do this:
> $ work work work, commit commit commit, reorder and perfect
> $ git format-patch --with-cover origin..HEAD
> ... which notices --with-cover, and perhaps does
> ... $ git-shortlog origin..HEAD
> ... $ git diff --stat --summary origin..HEAD
> ... $ echo "*** BLURB HERE ***"
> ... to create 0/N which it did not do so far in
> ... 0000-cover-letter.txt
> $ $EDITOR 0000-cover-letter.txt
> $ git-send-email 0*.txt
Because you'll be sending out the 0000-cover-letter.txt multiple
times, refining it (and the patches) as you go along.
Some people will use quilt for this process; others will use guilt or
stg in a seprate branch. The way I would probably solve it is by
making the Patch 0/N cover letter be a empty commit with no changes,
and simply storing the comment in the commit log. Yes, that means you
have to go back and edit the 0/N message after you've finished doing
your patch series, but the general work flow will require you to go
back and clean up patch 3/27 given some comment that Cristoph Hellwig
made, so you'll be going back and forth using some tool like guilt or
stg anyway. So going back to edit the 0/N cover-letter is not a big deal.
The one advantage of putting the 0/N cover-letter at the end is that
it makes it easier to drop it if the patch series ends up being pushed
via git, but again, given that the patch series is going to be
reworked multiple times during its life cycle, reworking it one last
time to drop the cover letter doesn't seem like a major issue --- and
if it is ends up getting applied by the maintainer via e-mail and
git-am, the cover letter will get dropped by the maintainer simply not
including it in his mailbox of patches to apply.
- Ted
^ permalink raw reply
* Re: git-svn and renames
From: David Kastrup @ 2007-07-10 13:20 UTC (permalink / raw)
To: git
In-Reply-To: <46938594.2010607@dawes.za.net>
Rogan Dawes <lists@dawes.za.net> writes:
> However, when I try to push this change to the Google repo, git-svn
> dies with the following error:
>
> $ git svn dcommit
> RA layer request failed: PROPFIND request failed on '/svn/trunk/
> webgoat/main/project/JavaSource/org/owasp/webgoat/lessons/DefaultLessonAction.java':
> PROPFIND of '/svn/trunk/
> webgoat/main/project/JavaSource/org/owasp/webgoat/lessons/DefaultLessonAction.java':
> 400 Bad Request (https://webgoat.googlecode.com) at
> /home/rdawes/bin/git-svn line 400
>
> [Yes, those paths have a space in them, however this does not seem to
> have prevented me from committing the previous 20 or so changes.]
>
> I noted the following in the git-svn documentation, with regards to
> handling renames. However, I am not renaming a directory, only a
> couple of files.
> ---- quote ----
[...]
>
> Renamed and copied directories are not detected by git and hence not
> tracked when committing to SVN. I do not plan on adding support for
> this as it's quite difficult and time-consuming to get working for all
> the possible corner cases (git doesn't do it, either). Committing
> renamed and copied files are fully supported if they're similar enough
> for git to detect them.
> Any ideas?
dcommit Commit several diffs to merge with upstream
--quiet, -q
--fetch-all, --all
--no-auth-cache
--no-rebase
--no-checkout
--rmdir
--dry-run, -n
--find-copies-harder
--follow-parent, --follow!
--authors-file, -A <arg>
--copy-similarity, -C <num>
--username <arg>
--repack-flags, --repack-args, --repack-opts <arg>
--repack <num>
--verbose, -v
--edit, -e
--log-window-size <num>
--config-dir <arg>
-l <num>
--merge, -m, -M
--strategy, -s <arg>
Try playing with the --copy-similarity and --find-copies-harder flags.
--
David Kastrup
^ permalink raw reply
* git-svn and renames
From: Rogan Dawes @ 2007-07-10 13:11 UTC (permalink / raw)
To: Git Mailing List, Eric Wong
Hi folks,
I am trying to push my local changes to an imported SVN project back to
the SVN repo. For anyone who cares, this is the WebGoat repository which
you can find at http://dawes.za.net/rogan/webgoat/webgoat.git/
I am trying to push it back to the primary GoogleCode repo. I have
successfully managed to push 20 or so commits, but I am now running up
against a problem with a renamed/moved file.
I moved a file from a directory to a subdirectory, and made minimal
changes to this file so that it remained a valid Java class. i.e. I
changed the package, and a few other minor things. As can be seen at
<http://dawes.za.net/gitweb.cgi?p=rogan/webgoat/webgoat.git;a=commitdiff;h=486416188a3e49d60e1510166ac197e5e66cc4d2>,
git detects the rename with 93% similarity.
However, when I try to push this change to the Google repo, git-svn dies
with the following error:
$ git svn dcommit
RA layer request failed: PROPFIND request failed on '/svn/trunk/
webgoat/main/project/JavaSource/org/owasp/webgoat/lessons/DefaultLessonAction.java':
PROPFIND of '/svn/trunk/
webgoat/main/project/JavaSource/org/owasp/webgoat/lessons/DefaultLessonAction.java':
400 Bad Request (https://webgoat.googlecode.com) at
/home/rdawes/bin/git-svn line 400
[Yes, those paths have a space in them, however this does not seem to
have prevented me from committing the previous 20 or so changes.]
I noted the following in the git-svn documentation, with regards to
handling renames. However, I am not renaming a directory, only a couple
of files.
---- quote ----
BUGS
----
We ignore all SVN properties except svn:executable. Any unhandled
properties are logged to $GIT_DIR/svn/<refname>/unhandled.log
Renamed and copied directories are not detected by git and hence not
tracked when committing to SVN. I do not plan on adding support for
this as it's quite difficult and time-consuming to get working for all
the possible corner cases (git doesn't do it, either). Committing
renamed and copied files are fully supported if they're similar enough
for git to detect them.
---- end quote ----
This is using the latest git as of today:
$ git --version
git version 1.5.3.rc0.81.g1ed84
Any ideas?
Thanks
Rogan
^ permalink raw reply
* Encoding problem with web version of the user manual
From: Johan Herland @ 2007-07-10 12:49 UTC (permalink / raw)
To: git
The current online version of the user manual at
http://www.kernel.org/pub/software/scm/git/docs/user-manual.html seems to
have some encoding problems. The document itself is in ISO-8859-1, and it
even states so in a meta-tag. However, the server says "Content-Type:
text/html; charset=UTF-8" (which takes precedence, according to the spec).
The end result is that the document looks like crap in most/all browsers
(I've tested with Konqueror, Opera and Firefox). Not sure if any other
documents are affected. The git manual page at
http://www.kernel.org/pub/software/scm/git/docs/git.html (and other git
manual pages) works correctly, since it's actually in UTF-8 format, and the
HTTP header is therefore correct.
Have fun!
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: Per-file, possibly even per-hunk cherry picking
From: Sam Vilain @ 2007-07-10 12:48 UTC (permalink / raw)
To: git
In-Reply-To: <469378AB.7030909@vilain.net>
Sam Vilain wrote:
> I'm interested in extending the cherry analysis to allow specification
> of the diff options used when calculating diff IDs, presenting the
> calculated diff IDs for analysis by external tools, and even calculating
> and dealing with per-hunk diff IDs.
>
On reflection I think so long as --cherry-pick works together with a
file selection, it would probably be enough.
ie, if I have these commits:
A---B
\
\
C
B changes a file foo.c, adding a line of text. C changes foo.c as well
as bar.c, but the change in foo.c was identical to change B.
I want this to show me nothing:
git-rev-list --left-right --cherry-pick B...C -- foo.c
Would it be the right approach to put this information in ids->diffopts,
or somewhere else?
Sam.
^ permalink raw reply
* Per-file, possibly even per-hunk cherry picking
From: Sam Vilain @ 2007-07-10 12:16 UTC (permalink / raw)
To: git
Hi all,
I'm interested in extending the cherry analysis to allow specification
of the diff options used when calculating diff IDs, presenting the
calculated diff IDs for analysis by external tools, and even calculating
and dealing with per-hunk diff IDs.
Has anyone done anything with this before, or got any good pointers or
advice?
Sam.
^ permalink raw reply
* I used git pull instead of stg pull !
From: Jean-Christian de Rivaz @ 2007-07-10 9:52 UTC (permalink / raw)
To: git
Hi,
I have made the error to use the "git pull" command instead of the "stg
pull" command. The "git pull" have been executed successfuly, but now
stg seem to be confused:
stg pull -n
stg pull: local changes in the tree. Use "refresh" to commit them
stg new dummy -m "dummy"
stg new: HEAD and top are not the same. You probably committed
changes to the tree outside of StGIT. If you know what you
are doing, use the "refresh -f" command
How can I restore the archive to a normal state for stg ?
Best regards,
--
Jean-Christian de Rivaz
^ permalink raw reply
* Re: "svn switch" equivalent when using git-svn -- git-filter-branch?
From: David Kastrup @ 2007-07-10 9:38 UTC (permalink / raw)
To: git
In-Reply-To: <20070710090003.GA18850@muzzle>
Eric Wong <normalperson@yhbt.net> writes:
> David Kastrup <dak@gnu.org> wrote:
>> Eric Wong <normalperson@yhbt.net> writes:
>>
>> > David Kastrup <dak@gnu.org> wrote:
>> >> Hi,
>> >>
>> >> an upstream svn repository that I access with git-svn has moved. I
>> >> seem to be too stupid to use git-filter-branch and/or .git/config
>> >> and/or git-reset to make my git mirror follow the switch.
>> >
>> > Just changing the url key in the [svn-remote] section of the .git/config
>> > file should be enough.
>> >
>> > You'll probably need to fetch at least one revision from the new URL
>> > before being able to dcommit, though.
>>
>> git-fetch works, but git-rebase -l still complains:
>>
>> git-svn rebase -l
>> Unable to determine upstream SVN information from working tree history
>>
>> And consequently I can't actually update.
>
> Does manually specifying the remote name work?
>
> Try bypassing the auto-detection of "git-svn rebase" and just using
> "git rebase <remote name>"
Well, a combination of changing the config, doing a fetch, changing
the config back again, doing the rebase, and changing the config again
seems to have done the trick for now.
I'll have to see how this works in future. Maybe I will have to
refetch everything anyhow as upstream has just decided to create a
trunk directory (and presumably tags and branches will follow). I am
not sure I am up to performing the correct steps for adapting to this.
--
David Kastrup
^ permalink raw reply
* Re: "svn switch" equivalent when using git-svn -- git-filter-branch?
From: Eric Wong @ 2007-07-10 9:00 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <86ejjgzmxl.fsf@lola.quinscape.zz>
David Kastrup <dak@gnu.org> wrote:
> Eric Wong <normalperson@yhbt.net> writes:
>
> > David Kastrup <dak@gnu.org> wrote:
> >> Hi,
> >>
> >> an upstream svn repository that I access with git-svn has moved. I
> >> seem to be too stupid to use git-filter-branch and/or .git/config
> >> and/or git-reset to make my git mirror follow the switch.
> >
> > Just changing the url key in the [svn-remote] section of the .git/config
> > file should be enough.
> >
> > You'll probably need to fetch at least one revision from the new URL
> > before being able to dcommit, though.
>
> git-fetch works, but git-rebase -l still complains:
>
> git-svn rebase -l
> Unable to determine upstream SVN information from working tree history
>
> And consequently I can't actually update.
Does manually specifying the remote name work?
Try bypassing the auto-detection of "git-svn rebase" and just using
"git rebase <remote name>"
--
Eric Wong
^ permalink raw reply
* Re: [PATCH] Support wholesale directory renames in fast-import
From: Rogan Dawes @ 2007-07-10 8:44 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: David Frech, git
In-Reply-To: <20070710031036.GA9045@spearce.org>
Shawn O. Pearce wrote:
> -Zero or more `filemodify`, `filedelete` and `filedeleteall` commands
> +Zero or more `filemodify`, `filedelete`, `filename` and
^^ filerename
Rogan
^ permalink raw reply
* Re: "svn switch" equivalent when using git-svn -- git-filter-branch?
From: David Kastrup @ 2007-07-10 8:24 UTC (permalink / raw)
To: git
In-Reply-To: <20070710054038.GA17675@muzzle>
Eric Wong <normalperson@yhbt.net> writes:
> David Kastrup <dak@gnu.org> wrote:
>> Hi,
>>
>> an upstream svn repository that I access with git-svn has moved. I
>> seem to be too stupid to use git-filter-branch and/or .git/config
>> and/or git-reset to make my git mirror follow the switch.
>
> Just changing the url key in the [svn-remote] section of the .git/config
> file should be enough.
>
> You'll probably need to fetch at least one revision from the new URL
> before being able to dcommit, though.
git-fetch works, but git-rebase -l still complains:
git-svn rebase -l
Unable to determine upstream SVN information from working tree history
And consequently I can't actually update.
--
David Kastrup
^ permalink raw reply
* Re: how to combine two clones in a collection
From: Martin Langhoff @ 2007-07-10 7:51 UTC (permalink / raw)
To: git discussion list
In-Reply-To: <20070710062104.GA22603@piper.oerlikon.madduck.net>
On 7/10/07, martin f krafft <madduck@madduck.net> wrote:
> It does mean, however, that I duplicate the upstream into my repo,
> and thus into the published repo at git.debian.org, because I cannot
> just publish a single branch ('debian') in such a way that people
> could clone it and still be able to build the package against
> upstream (which they'd have to obtain for themselves), right?
Yes. But is that a problem? In most cases, the complete history of the
project is fairly small if your repo is well packed. Often not much
bigger than a tarball of one source snapshot.
What does the following say?
git repack -a -d
du -sh .git/objects/pack
cheers,
martni
^ permalink raw reply
* Re: mirroring between svn and git
From: Sean @ 2007-07-10 7:49 UTC (permalink / raw)
To: satish madrage; +Cc: git
In-Reply-To: <6a9b0ede0707100025w2a37eecr8bb06e537523a003@mail.gmail.com>
On Tue, 10 Jul 2007 12:55:04 +0530
"satish madrage" <svmdcv@gmail.com> wrote:
> can somebody give pointers to any docs through which i can set up
> mirroring between svn and git. (i.e all svn checked in contenst shd be
> seen in git).
git-svn should do what you need and it has a pretty good man page.
You might also want to checkout the introduction here:
http://utsl.gen.nz/talks/git-svn/intro.html
Cheers,
Sean
^ permalink raw reply
* Re: how to combine two clones in a collection
From: martin f krafft @ 2007-07-10 7:40 UTC (permalink / raw)
To: git
In-Reply-To: <7v3azwsp6a.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 1472 bytes --]
also sprach Junio C Hamano <gitster@pobox.com> [2007.07.10.0917 +0200]:
> For the former kind, It is unavoidable for people to get your
> (slightly modified) upstream source from you --- there is
> nowhere else that stores what you changed.
This is pretty similar to a method developed by Manoj Srivastava adn
described here: http://arch.debian.org/arch/private/srivasta/ and
it's very promising, albeit a little complex for newcomers, in my
experience. As linked previously, I presented a similar workflow
with git[0] at DebConf7[1].
0. http://albatross.madduck.net/pipermail/vcs-pkg/2007-June/000001.html
1. https://penta.debconf.org/~joerg/events/53.en.html
I actually knew the answers to my questions, I guess, but I was way
too confused to get the picture straight. Thanks to both of you for
your time in helping me understand.
I shall spend some time experimenting and will then blog about my
experience of converting the various types of Debian source packages
to the suggested style of maintenance. I shall post the URL to this
thread too.
--
martin; (greetings from the heart of the sun.)
\____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
spamtraps: madduck.bogus@madduck.net
"for art to exist, for any sort of aesthetic activity or perception to
exist, a certain physiological precondition is indispensable:
intoxication."
-- friedrich nietzsche
[-- Attachment #2: Digital signature (GPG/PGP) --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* mirroring between svn and git
From: satish madrage @ 2007-07-10 7:25 UTC (permalink / raw)
To: git
list,
i am totally new to git, we use svn, and we are working on open source
tool which tests linux kernel.
now we are contributing to one more open source project which is under git.
we use svn, now i need to mirror between git and svn,
can somebody give pointers to any docs through which i can set up
mirroring between svn and git. (i.e all svn checked in contenst shd be
seen in git).
Thanks in advance,
Satish.
^ permalink raw reply
* Re: how to combine two clones in a collection
From: Junio C Hamano @ 2007-07-10 7:17 UTC (permalink / raw)
To: martin f krafft; +Cc: git
In-Reply-To: <20070710062104.GA22603@piper.oerlikon.madduck.net>
martin f krafft <madduck@madduck.net> writes:
> Thanks, Linus, for your time in answering my questions. I have some
> more comments and questions in reply. I hope I am coherent enough,
> this subject matter doesn't exactly flow off my tongue with ease
> yet...
>
> also sprach Linus Torvalds <torvalds@linux-foundation.org> [2007.07.10.0435 +0200]:
>> I really _think_ that what you want is to just use separate
>> branches, if I understand correctly. That makes it really easy to
>> just have both lines of development (both the "trunk" and your
>> "debian" one) in one git repository.
>
> It does mean, however, that I duplicate the upstream into my repo,
> and thus into the published repo at git.debian.org, because I cannot
> just publish a single branch ('debian') in such a way that people
> could clone it and still be able to build the package against
> upstream (which they'd have to obtain for themselves), right?
I've seen two kinds of debianized source tree. One kind has
changes already applied to the pristine source outside debian/
subdirectory, and debian/rules does the debian specific
customized build, install and packaging. The other kind does
not have _any_ change to the pristine except it has debian/
subdirectory and the first thing debian/rules does is to apply
patches to pristine from patch files kept in debian/
subdirectory. The answer largely depends on which arrangement
you have in mind for your package.
For the former kind, It is unavoidable for people to get your
(slightly modified) upstream source from you --- there is
nowhere else that stores what you changed. Extracting the
vanilla pristine and debian/ separately would not cut it. For
such an arrangement, "upstream" (or "pristine") branch would
contain everything you get from your upstream tarball (or SVN)
without any of Debianization changes (you can still have generic
"fixes and enhancements" of your own there to be fed upstream).
Your "master" (you could call it "debianization") branch will
fork off of that branch, and the first commit on that branch
would add debian/ subdirectory. All the debianization
modification to the upstream, if needed, also go to this branch.
Your users will clone and pull from your "master" and do
"fakeroot debian/rules binary" or whatever, and all is good.
For the latter, since the changes from upstream is isolated to
your additional debian/ subdirectory, you could arrange your
repository like this, even without using the subproject support:
.git/
.gitignore (perhaps untracked)
Makefile (upstream)
foo.c (upstream)
...
debian/.git
debian/rules (yours)
debian/control (yours)
...
Then, have the top-level .git/ repository control pristine
upstream sources from SVN (you may want to add .gitignore to
ignore debian/ subdirectory). In debian/, you create another
independent repository, and maintain _ONLY_ debianization. You
could even publish only that repository to your users without
publishing the upstream sources, if they know which version of
upstream source to use.
I tend to prefer the former, from the end user's point of view.
^ permalink raw reply
* Re: [RFC] series headers
From: Junio C Hamano @ 2007-07-10 6:57 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0707100126250.6977@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
> I'd like to be able to get format-patch to produce a [PATCH 0/N] message,
> with a message that's actually in my repository, plus various goodies
> generated either from diffing the ends of the series or by running through
> the log an extra time to pick up summary information.
So far, so good.
> As far as implementing this... would it be sane to make struct
> rev_info.commit_format a callback, so that the code to generate an email
> message can be somewhere that's easy to use to generate an email that
> isn't for a commit in the log? I don't *think* git's quite fast enough for
> the indirect jump to a callback instead of an if tree for an enum will
> actually hurt us.
I suspect that temptation to touch rev_info.commit_format arises
purely because you are thinking about making 0/N a (perhaps
fake) commit. I do not see a point in that.
What is the workflow?
$ work work work, commit commit commit, reorder and perfect
$ git tag end-of-series
... in $EDITOR, edit the [0/N] message
$ git format-patch origin..end-of-series
... which notices end-of-series, and perhaps internally runs
... $ git-shortlog origin..end-of-series
... $ git diff --stat --summary origin..end-of-series
... $ git cat-file tag end-of-series
... to create 0/N which it did not do so far in
... 0000-cover-letter.txt
$ git-send-email 0*.txt
Would it be so much better than this workflow which would
probably not need to touch much of the 'commit formatting" code
that is used for [1/N]..[N/N] messages?
$ work work work, commit commit commit, reorder and perfect
$ git format-patch --with-cover origin..HEAD
... which notices --with-cover, and perhaps does
... $ git-shortlog origin..HEAD
... $ git diff --stat --summary origin..HEAD
... $ echo "*** BLURB HERE ***"
... to create 0/N which it did not do so far in
... 0000-cover-letter.txt
$ $EDITOR 0000-cover-letter.txt
$ git-send-email 0*.txt
^ permalink raw reply
* Re: how to combine two clones in a collection
From: martin f krafft @ 2007-07-10 6:21 UTC (permalink / raw)
To: git discussion list
In-Reply-To: <alpine.LFD.0.999.0707091923300.3412@woody.linux-foundation.org>
[-- Attachment #1: Type: text/plain, Size: 3998 bytes --]
Thanks, Linus, for your time in answering my questions. I have some
more comments and questions in reply. I hope I am coherent enough,
this subject matter doesn't exactly flow off my tongue with ease
yet...
also sprach Linus Torvalds <torvalds@linux-foundation.org> [2007.07.10.0435 +0200]:
> I really _think_ that what you want is to just use separate
> branches, if I understand correctly. That makes it really easy to
> just have both lines of development (both the "trunk" and your
> "debian" one) in one git repository.
It does mean, however, that I duplicate the upstream into my repo,
and thus into the published repo at git.debian.org, because I cannot
just publish a single branch ('debian') in such a way that people
could clone it and still be able to build the package against
upstream (which they'd have to obtain for themselves), right?
> Of course, especially if you want to continue to work the way you
> probably worked with SVN (ie you are used to seeing those two
> branches as two separate directories), that means that while you
> can (and should) see it as a single git project, you'd normally
> end up just having two copies of that project: they'd _both_ have
> two branches, but they'd just en dup having different branches
> checked out.
The way I tend to think about a pair of branches is that one depends
on the other, or rather, one stems from the other. Thus, I'd
probably branch the 'debian' branch off 'upstream', and add the
./debian directory, and then either rebase the debian branch onto
new upstream heads, or merge upstream into the debian branch on new
versions.
This makes perfect sense and I have been experimenting with such
a workflow before:
http://albatross.madduck.net/pipermail/vcs-pkg/2007-June/000001.html
So if I made changes to the debian branch, I'd check it out first,
then return to the upstream branch when done.
Your suggestion to checkout the same repo twice with different
branches does sound a lot like the way I used to do things in SVN.
However, I guess what I am trying to prevent is having to manually
set up this hierarchy on each machine I choose to work on. Instead,
I'd rather be able to clone a repository and be ready to work.
In your scenario, would I make two branches and then import upstream
into one, the ./debian directory into the other, and never ever
merge back and forth again, thus treating them as separate
directories?
> Of course, after you get comfy enough with the setup, you might
> end up just deciding that you might as well just switch branches
> around in a single repository (which is what a lot of git users
> end up doing), but at least initially, it's probably easier from
> a conceptual standpoint to just have the two branches checked out
> in separate copies of the repos.
Okay, this is beginning to make sense. However, the debian branch
tracks changes mostly to ./debian/*. To check it out separately,
I need a directory. If usptream is checked out to ., then if I'd
check out the debian branch do ./debian, I'd end up with
./debian/debian. Do you suggest the use of a symlink then?
> > How can I do this with git? I am aware that maybe the best way
> > would be to use git-svn to track the upstream branch remotely
> > and to add ./debian in a separate git branch (and to stop using
> > SVN and switch to git for ./debian)
>
> I don't think you'd have to stop using SVN.
I think I would want to. :)
> (And no, I don't know what the standard debian package management
> setup looks like, but I would hope that your extra stuff would be
> just a few files and package descriptions, and obviously any of
> the local debian changes to the project).
Your hopes seem to be quite close to reality. :)
Thanks,
--
martin; (greetings from the heart of the sun.)
\____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
spamtraps: madduck.bogus@madduck.net
http://www.vcnet.com/bms/
[-- Attachment #2: Digital signature (GPG/PGP) --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [RFC] series headers
From: Daniel Barkalow @ 2007-07-10 6:14 UTC (permalink / raw)
To: git
I'd like to be able to get format-patch to produce a [PATCH 0/N] message,
with a message that's actually in my repository, plus various goodies
generated either from diffing the ends of the series or by running through
the log an extra time to pick up summary information.
The second best idea I have for this currently is to have a commit at the
end of the series which specifies which has the same tree as its parent
and has a message with a line "Since <sha1 of the first commit of the
series>" and has the text. This goes at the end of the series, because it
describes the state with all of the changes made, which is only a good
description of a commit at the end of the series, not a commit at the
start of the series. Making it [PATCH 0/N] is just because it belongs
first in presentation, regardless of whether the other commits are
presented with recent commits first or last.
The better idea I just had was to have format-patch notice if the "until"
side is a tag object instead of a commit, and generate a [0/N] with the
tag message.
As far as implementing this... would it be sane to make struct
rev_info.commit_format a callback, so that the code to generate an email
message can be somewhere that's easy to use to generate an email that
isn't for a commit in the log? I don't *think* git's quite fast enough for
the indirect jump to a callback instead of an if tree for an enum will
actually hurt us.
-Daniel
*This .sig left intentionally blank*
^ 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