* [PATCH 02/12] Do not complain about "no common commits" in an empty repo
From: Steffen Prohaska @ 2008-07-02 8:32 UTC (permalink / raw)
To: Johannes Sixt
Cc: git, msysgit, Junio C Hamano, Johannes Schindelin,
Steffen Prohaska
In-Reply-To: <1214987532-23640-1-git-send-email-prohaska@zib.de>
From: Johannes Schindelin <johannes.schindelin@gmx.de>
If the repo is empty, we know that already, thank you very much.
So shut fetch-pack up about that case.
Fixes issue 3, too.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
builtin-fetch-pack.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/builtin-fetch-pack.c b/builtin-fetch-pack.c
index f4dbcf0..2175c6d 100644
--- a/builtin-fetch-pack.c
+++ b/builtin-fetch-pack.c
@@ -309,7 +309,8 @@ done:
}
flushes--;
}
- return retval;
+ /* it is no error to fetch into a completely empty repo */
+ return count ? retval : 0;
}
static struct commit_list *complete;
--
1.5.6.1.255.g32571
^ permalink raw reply related
* [PATCH 03/12] MinGW: Convert CR/LF to LF in tag signatures
From: Steffen Prohaska @ 2008-07-02 8:32 UTC (permalink / raw)
To: Johannes Sixt
Cc: git, msysgit, Junio C Hamano, Johannes Schindelin,
Steffen Prohaska
In-Reply-To: <1214987532-23640-2-git-send-email-prohaska@zib.de>
From: Johannes Schindelin <johannes.schindelin@gmx.de>
On Windows, gpg outputs CR/LF signatures. But since the tag
messages are already stripped of the CR by stripspace(), it is
arguably nicer to do the same for the tag signature. Actually,
this patch does not look for CR/LF, but strips all CRs
from the signature.
[ spr: ported code to use strbuf ]
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
builtin-tag.c | 14 ++++++++++++++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/builtin-tag.c b/builtin-tag.c
index e675206..77977ba 100644
--- a/builtin-tag.c
+++ b/builtin-tag.c
@@ -241,6 +241,20 @@ static int do_sign(struct strbuf *buffer)
if (finish_command(&gpg) || !len || len < 0)
return error("gpg failed to sign the tag");
+#ifdef __MINGW32__
+ /* strip CR from the line endings */
+ {
+ int i, j;
+ for (i = j = 0; i < buffer->len; i++)
+ if (buffer->buf[i] != '\r') {
+ if (i != j)
+ buffer->buf[j] = buffer->buf[i];
+ j++;
+ }
+ strbuf_setlen(buffer, j);
+ }
+#endif
+
return 0;
}
--
1.5.6.1.255.g32571
^ permalink raw reply related
* Re: [PATCH] git-add--interactive: manual hunk editing mode
From: Jeff King @ 2008-07-02 8:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Thomas Rast, git
In-Reply-To: <7vd4lwemja.fsf@gitster.siamese.dyndns.org>
On Wed, Jul 02, 2008 at 01:08:09AM -0700, Junio C Hamano wrote:
> > So if the problem is "old perl", I don't think it is an issue. Are there
> > modern perl installations in the wild that don't have File::Temp?
>
> The thing is, I think I heard quite similar explanation why Test::More is
> safe to use when the patch to add t/t9700 was submit. Then what happened?
ISTR the Test::More problem was reported by Linus, who is a Fedora user?
I tried searching for any reasonable information on which of the core
perl modules are installed by default on Fedora systems, but didn't come
up with anything useful.
I really have no clue as to what is out there, and I suspect we must
either play it totally safe, or push the limits and wait for people to
complain about breakage.
-Peff
^ permalink raw reply
* Re: How to reduce remaining differences to 4msysgit? (was What's cooking in git.git (topics))
From: Steffen Prohaska @ 2008-07-02 8:31 UTC (permalink / raw)
To: Johannes Sixt; +Cc: msysGit, Junio C Hamano, Git Mailing List
In-Reply-To: <200806302047.56935.johannes.sixt@telecom.at>
On Jun 30, 2008, at 8:47 PM, Johannes Sixt wrote:
> Then there are the extra patches in 4msysgit. From my POV, they are
> not
> _required_ because I can appearently work with git on Windows
> without them. I
> think some of them are not necessary. Can we go through them again?
I'll send a patch series in reply to this mail that contains the
following patches:
[PATCH 01/12] Fake reencoding success under NO_ICONV instead of
returning NULL.
[PATCH 02/12] Do not complain about "no common commits" in an empty
repo
[PATCH 03/12] MinGW: Convert CR/LF to LF in tag signatures
[PATCH 04/12] Avoid calling signal(SIGPIPE, ..) for MinGW builds.
[PATCH 05/12] Windows(msysgit): Per default, display help as HTML in
default browser
[PATCH 06/12] connect: Fix custom ports with plink (Putty's ssh)
[PATCH 07/12] Fixed text file auto-detection: treat EOF character
032 at the end of file as printable
[PATCH 08/12] fast-import: MinGW does not have getppid(). So do not
print it.
[PATCH 09/12] We need to check for msys as well as Windows in add--
interactive.
[PATCH 10/12] Add ANSI control code emulation for the Windows console
[PATCH 11/12] verify_path(): do not allow absolute paths
[PATCH 12/12] [TODO] setup: bring changes from 4msysgit/next to next
This series would bring *.{c,h,sh,perl} on Junio's next to 4msysgit/
next,
except for some minor differences (whitespace, comments, a workaround in
git-parse-remote.sh).
Steffen
^ permalink raw reply
* Re: [PATCH 3/3] git-branch -v: show the remote tracking statistics
From: Johannes Sixt @ 2008-07-02 8:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ingo Molnar, Bruce Stephens, git
In-Reply-To: <7vhcb8en92.fsf@gitster.siamese.dyndns.org>
Junio C Hamano schrieb:
> This teaches "git branch -v" to insert the remote tracking statistics in
> the form of [ours/theirs] just before the one-liner commit log message
> for the branch.
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
> ... which means that you would see something like this.
>
> * jc/report-tracking 41666f7 [3/117] git-branch -v: show the remo...
>
> I did not think we want to spend extra columns to show the name of
> remote branch each of them tracks, so I am showing only counts.
What makes the "tracking statistics" so useful, is that it explains the
situation in clear words. But here you throw in a few numbers without
explanation. It's practically undiscoverable what the numbers mean.
Therefore, I personally would prefer not to have them here and to save the
space for the commit summary.
What do you think about showing the tracking information only if --track
is supplied? But then even write more information:
* jc/report-tracking 41666f7 diverged 3 vs. 117
foo 1234567 behind 22
bar fedcba9 ahead 6
and filter the output to show only tracking branches.
-- Hannes
^ permalink raw reply
* Re: [PATCH] git-add--interactive: manual hunk editing mode
From: Junio C Hamano @ 2008-07-02 8:08 UTC (permalink / raw)
To: Jeff King; +Cc: Thomas Rast, git
In-Reply-To: <20080702080200.GA21367@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> According to Module::CoreList, File::Temp has shipped as part of core
> perl since 5.006001. "add -i" doesn't work with perl < 5.6 already due to
> things like 3-argument open.
>
> So if the problem is "old perl", I don't think it is an issue. Are there
> modern perl installations in the wild that don't have File::Temp?
The thing is, I think I heard quite similar explanation why Test::More is
safe to use when the patch to add t/t9700 was submit. Then what happened?
^ permalink raw reply
* Re: [PATCH] git-add--interactive: manual hunk editing mode
From: Jeff King @ 2008-07-02 8:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Thomas Rast, git
In-Reply-To: <7v7ic4hmj5.fsf@gitster.siamese.dyndns.org>
On Tue, Jul 01, 2008 at 10:39:58PM -0700, Junio C Hamano wrote:
> > +use File::Temp;
>
> People with minimum Perl installation should still be able to use "add -i"
> as long as they do not use 'e' subcommand, shouldn't they? Shouldn't we
> do something like:
>
> my $can_use_temp = eval {
> require File::Temp;
> 1;
> };
>
> and disable 'e' subcommand unless $can_use_temp?
According to Module::CoreList, File::Temp has shipped as part of core
perl since 5.006001. "add -i" doesn't work with perl < 5.6 already due to
things like 3-argument open.
So if the problem is "old perl", I don't think it is an issue. Are there
modern perl installations in the wild that don't have File::Temp?
-Peff
^ permalink raw reply
* [PATCH 3/3] git-branch -v: show the remote tracking statistics
From: Junio C Hamano @ 2008-07-02 7:52 UTC (permalink / raw)
To: Ingo Molnar; +Cc: Bruce Stephens, git
In-Reply-To: <7vlk0lmn32.fsf@gitster.siamese.dyndns.org>
This teaches "git branch -v" to insert the remote tracking statistics in
the form of [ours/theirs] just before the one-liner commit log message
for the branch.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
... which means that you would see something like this.
* jc/report-tracking 41666f7 [3/117] git-branch -v: show the remo...
I did not think we want to spend extra columns to show the name of
remote branch each of them tracks, so I am showing only counts.
builtin-branch.c | 14 ++++++++++++--
1 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/builtin-branch.c b/builtin-branch.c
index d279702..0e2bb52 100644
--- a/builtin-branch.c
+++ b/builtin-branch.c
@@ -310,6 +310,7 @@ static void print_ref_item(struct ref_item *item, int maxwidth, int verbose,
if (verbose) {
struct strbuf subject;
const char *sub = " **** invalid ref ****";
+ char stat[128];
strbuf_init(&subject, 0);
@@ -319,10 +320,19 @@ static void print_ref_item(struct ref_item *item, int maxwidth, int verbose,
&subject, 0, NULL, NULL, 0, 0);
sub = subject.buf;
}
- printf("%c %s%-*s%s %s %s\n", c, branch_get_color(color),
+
+ stat[0] = '\0';
+ if (item->kind == REF_LOCAL_BRANCH) {
+ int ours, theirs;
+ struct branch *branch = branch_get(item->name);
+ if (stat_tracking_info(branch, &ours, &theirs))
+ sprintf(stat, "[%d/%d] ", ours, theirs);
+ }
+ printf("%c %s%-*s%s %s %s%s\n", c, branch_get_color(color),
maxwidth, item->name,
branch_get_color(COLOR_BRANCH_RESET),
- find_unique_abbrev(item->sha1, abbrev), sub);
+ find_unique_abbrev(item->sha1, abbrev),
+ stat, sub);
strbuf_release(&subject);
} else {
printf("%c %s%s%s\n", c, branch_get_color(color), item->name,
--
1.5.6.1.156.ge903b
^ permalink raw reply related
* [PATCH 2/3] git-status: show the remote tracking statistics
From: Junio C Hamano @ 2008-07-02 7:52 UTC (permalink / raw)
To: Ingo Molnar; +Cc: Bruce Stephens, git
In-Reply-To: <7vlk0lmn32.fsf@gitster.siamese.dyndns.org>
This teaches "git status" to show the same remote tracking statistics
"git checkout" gives at the beginning of the output.
Now the necessary low-level machinery is properly factored out, we can do
this quite cleanly.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
wt-status.c | 22 ++++++++++++++++++++++
1 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/wt-status.c b/wt-status.c
index 28c9e63..eeb106e 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -9,6 +9,7 @@
#include "diffcore.h"
#include "quote.h"
#include "run-command.h"
+#include "remote.h"
int wt_status_relative_paths = 1;
int wt_status_use_color = -1;
@@ -315,6 +316,25 @@ static void wt_status_print_verbose(struct wt_status *s)
run_diff_index(&rev, 1);
}
+static void wt_status_print_tracking(struct wt_status *s)
+{
+ struct strbuf sb = STRBUF_INIT;
+ const char *cp, *ep;
+ struct branch *branch;
+
+ assert(s->branch && !s->is_initial);
+ if (prefixcmp(s->branch, "refs/heads/"))
+ return;
+ branch = branch_get(s->branch + 11);
+ if (!format_tracking_info(branch, &sb))
+ return;
+
+ for (cp = sb.buf; (ep = strchr(cp, '\n')) != NULL; cp = ep + 1)
+ color_fprintf_ln(s->fp, color(WT_STATUS_HEADER),
+ "# %.*s", (int)(ep - cp), cp);
+ color_fprintf_ln(s->fp, color(WT_STATUS_HEADER), "#");
+}
+
void wt_status_print(struct wt_status *s)
{
unsigned char sha1[20];
@@ -333,6 +353,8 @@ void wt_status_print(struct wt_status *s)
}
color_fprintf(s->fp, color(WT_STATUS_HEADER), "# ");
color_fprintf_ln(s->fp, branch_color, "%s%s", on_what, branch_name);
+ if (!s->is_initial)
+ wt_status_print_tracking(s);
}
if (s->is_initial) {
--
1.5.6.1.156.ge903b
^ permalink raw reply related
* [PATCH 1/3] Refactor "tracking statistics" code used by "git checkout"
From: Junio C Hamano @ 2008-07-02 7:51 UTC (permalink / raw)
To: Ingo Molnar; +Cc: Bruce Stephens, git
In-Reply-To: <7vlk0lmn32.fsf@gitster.siamese.dyndns.org>
People seem to like "Your branch is ahead by N commit" report made by
"git checkout", but the interface into the statistics function was a bit
clunky. This splits the function into three parts:
* The core "commit counting" function that takes "struct branch" and
returns number of commits to show if we are ahead, behind or forked;
* Convenience "stat formating" function that takes "struct branch" and
formats the report into a given strbuf, using the above function;
* "checkout" specific function that takes "branch_info" (type that is
internal to checkout implementation), calls the above function and
print the formatted result.
in the hope that the former two can be more easily reusable.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin-checkout.c | 94 +++----------------------------------------
remote.c | 113 ++++++++++++++++++++++++++++++++++++++++++++++++++++
remote.h | 4 ++
3 files changed, 123 insertions(+), 88 deletions(-)
diff --git a/builtin-checkout.c b/builtin-checkout.c
index 93ea69b..d6641c2 100644
--- a/builtin-checkout.c
+++ b/builtin-checkout.c
@@ -305,97 +305,15 @@ static int merge_working_tree(struct checkout_opts *opts,
return 0;
}
-static void report_tracking(struct branch_info *new, struct checkout_opts *opts)
+static void report_tracking(struct branch_info *new)
{
- /*
- * We have switched to a new branch; is it building on
- * top of another branch, and if so does that other branch
- * have changes we do not have yet?
- */
- char *base;
- unsigned char sha1[20];
- struct commit *ours, *theirs;
- char symmetric[84];
- struct rev_info revs;
- const char *rev_argv[10];
- int rev_argc;
- int num_ours, num_theirs;
- const char *remote_msg;
+ struct strbuf sb = STRBUF_INIT;
struct branch *branch = branch_get(new->name);
- /*
- * Nothing to report unless we are marked to build on top of
- * somebody else.
- */
- if (!branch || !branch->merge || !branch->merge[0] || !branch->merge[0]->dst)
- return;
-
- /*
- * If what we used to build on no longer exists, there is
- * nothing to report.
- */
- base = branch->merge[0]->dst;
- if (!resolve_ref(base, sha1, 1, NULL))
+ if (!format_tracking_info(branch, &sb))
return;
-
- theirs = lookup_commit(sha1);
- ours = new->commit;
- if (!hashcmp(sha1, ours->object.sha1))
- return; /* we are the same */
-
- /* Run "rev-list --left-right ours...theirs" internally... */
- rev_argc = 0;
- rev_argv[rev_argc++] = NULL;
- rev_argv[rev_argc++] = "--left-right";
- rev_argv[rev_argc++] = symmetric;
- rev_argv[rev_argc++] = "--";
- rev_argv[rev_argc] = NULL;
-
- strcpy(symmetric, sha1_to_hex(ours->object.sha1));
- strcpy(symmetric + 40, "...");
- strcpy(symmetric + 43, sha1_to_hex(theirs->object.sha1));
-
- init_revisions(&revs, NULL);
- setup_revisions(rev_argc, rev_argv, &revs, NULL);
- prepare_revision_walk(&revs);
-
- /* ... and count the commits on each side. */
- num_ours = 0;
- num_theirs = 0;
- while (1) {
- struct commit *c = get_revision(&revs);
- if (!c)
- break;
- if (c->object.flags & SYMMETRIC_LEFT)
- num_ours++;
- else
- num_theirs++;
- }
-
- if (!prefixcmp(base, "refs/remotes/")) {
- remote_msg = " remote";
- base += strlen("refs/remotes/");
- } else {
- remote_msg = "";
- }
-
- if (!num_theirs)
- printf("Your branch is ahead of the tracked%s branch '%s' "
- "by %d commit%s.\n",
- remote_msg, base,
- num_ours, (num_ours == 1) ? "" : "s");
- else if (!num_ours)
- printf("Your branch is behind the tracked%s branch '%s' "
- "by %d commit%s,\n"
- "and can be fast-forwarded.\n",
- remote_msg, base,
- num_theirs, (num_theirs == 1) ? "" : "s");
- else
- printf("Your branch and the tracked%s branch '%s' "
- "have diverged,\nand respectively "
- "have %d and %d different commit(s) each.\n",
- remote_msg, base,
- num_ours, num_theirs);
+ fputs(sb.buf, stdout);
+ strbuf_release(&sb);
}
static void update_refs_for_switch(struct checkout_opts *opts,
@@ -441,7 +359,7 @@ static void update_refs_for_switch(struct checkout_opts *opts,
remove_branch_state();
strbuf_release(&msg);
if (!opts->quiet && (new->path || !strcmp(new->name, "HEAD")))
- report_tracking(new, opts);
+ report_tracking(new);
}
static int switch_branches(struct checkout_opts *opts, struct branch_info *new)
diff --git a/remote.c b/remote.c
index ff2c802..bd5c3be 100644
--- a/remote.c
+++ b/remote.c
@@ -1,6 +1,9 @@
#include "cache.h"
#include "remote.h"
#include "refs.h"
+#include "commit.h"
+#include "diff.h"
+#include "revision.h"
static struct refspec s_tag_refspec = {
0,
@@ -1222,3 +1225,113 @@ int resolve_remote_symref(struct ref *ref, struct ref *list)
}
return 1;
}
+
+/*
+ * Return true if there is anything to report, otherwise false.
+ */
+int stat_tracking_info(struct branch *branch, int *num_ours, int *num_theirs)
+{
+ unsigned char sha1[20];
+ struct commit *ours, *theirs;
+ char symmetric[84];
+ struct rev_info revs;
+ const char *rev_argv[10], *base;
+ int rev_argc;
+
+ /*
+ * Nothing to report unless we are marked to build on top of
+ * somebody else.
+ */
+ if (!branch ||
+ !branch->merge || !branch->merge[0] || !branch->merge[0]->dst)
+ return 0;
+
+ /*
+ * If what we used to build on no longer exists, there is
+ * nothing to report.
+ */
+ base = branch->merge[0]->dst;
+ if (!resolve_ref(base, sha1, 1, NULL))
+ return 0;
+ theirs = lookup_commit(sha1);
+ if (!theirs)
+ return 0;
+
+ if (!resolve_ref(branch->refname, sha1, 1, NULL))
+ return 0;
+ ours = lookup_commit(sha1);
+ if (!ours)
+ return 0;
+
+ /* are we the same? */
+ if (theirs == ours)
+ return 0;
+
+ /* Run "rev-list --left-right ours...theirs" internally... */
+ rev_argc = 0;
+ rev_argv[rev_argc++] = NULL;
+ rev_argv[rev_argc++] = "--left-right";
+ rev_argv[rev_argc++] = symmetric;
+ rev_argv[rev_argc++] = "--";
+ rev_argv[rev_argc] = NULL;
+
+ strcpy(symmetric, sha1_to_hex(ours->object.sha1));
+ strcpy(symmetric + 40, "...");
+ strcpy(symmetric + 43, sha1_to_hex(theirs->object.sha1));
+
+ init_revisions(&revs, NULL);
+ setup_revisions(rev_argc, rev_argv, &revs, NULL);
+ prepare_revision_walk(&revs);
+
+ /* ... and count the commits on each side. */
+ *num_ours = 0;
+ *num_theirs = 0;
+ while (1) {
+ struct commit *c = get_revision(&revs);
+ if (!c)
+ break;
+ if (c->object.flags & SYMMETRIC_LEFT)
+ (*num_ours)++;
+ else
+ (*num_theirs)++;
+ }
+ return 1;
+}
+
+/*
+ * Return true when there is anything to report, otherwise false.
+ */
+int format_tracking_info(struct branch *branch, struct strbuf *sb)
+{
+ int num_ours, num_theirs;
+ const char *base, *remote_msg;
+
+ if (!stat_tracking_info(branch, &num_ours, &num_theirs))
+ return 0;
+
+ base = branch->merge[0]->dst;
+ if (!prefixcmp(base, "refs/remotes/")) {
+ remote_msg = " remote";
+ base += strlen("refs/remotes/");
+ } else {
+ remote_msg = "";
+ }
+ if (!num_theirs)
+ strbuf_addf(sb, "Your branch is ahead of the tracked%s branch '%s' "
+ "by %d commit%s.\n",
+ remote_msg, base,
+ num_ours, (num_ours == 1) ? "" : "s");
+ else if (!num_ours)
+ strbuf_addf(sb, "Your branch is behind the tracked%s branch '%s' "
+ "by %d commit%s,\n"
+ "and can be fast-forwarded.\n",
+ remote_msg, base,
+ num_theirs, (num_theirs == 1) ? "" : "s");
+ else
+ strbuf_addf(sb, "Your branch and the tracked%s branch '%s' "
+ "have diverged,\nand respectively "
+ "have %d and %d different commit(s) each.\n",
+ remote_msg, base,
+ num_ours, num_theirs);
+ return 1;
+}
diff --git a/remote.h b/remote.h
index 8eed87b..091b1d0 100644
--- a/remote.h
+++ b/remote.h
@@ -129,4 +129,8 @@ enum match_refs_flags {
MATCH_REFS_MIRROR = (1 << 1),
};
+/* Reporting of tracking info */
+int stat_tracking_info(struct branch *branch, int *num_ours, int *num_theirs);
+int format_tracking_info(struct branch *branch, struct strbuf *sb);
+
#endif
--
1.5.6.1.156.ge903b
^ permalink raw reply related
* [PATCH 0/3] Making remote tracking statistics available to other tools
From: Junio C Hamano @ 2008-07-02 7:50 UTC (permalink / raw)
To: Ingo Molnar; +Cc: Bruce Stephens, git
In-Reply-To: <7vlk0lmn32.fsf@gitster.siamese.dyndns.org>
The one I sent out was a bit hacky as the existing implementation inside
git-checkout was not designed to be cleanly reusable.
Here is a cleaned up series that could be applied.
[PATCH 1/3] Refactor "tracking statistics" code used by "git checkout"
[PATCH 2/3] git-status: show the remote tracking statistics
[PATCH 3/3] git-branch -v: show the remote tracking statistics
^ permalink raw reply
* Re: [PATCH 14/14] Build in merge
From: Miklos Vajna @ 2008-07-02 7:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Schindelin, Olivier Marin
In-Reply-To: <7v63rpkvme.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 366 bytes --]
On Tue, Jul 01, 2008 at 04:55:21PM -0700, Junio C Hamano <gitster@pobox.com> wrote:
> Have you looked at the series I fixed up before pushing out in 'pu' last
> night, specifically 5948e2a and 01a7dae? If you actually built and tested
> 5948e2a, you'd notice that the test in that commit *must* expect failure.
Aah. Now I see the point, thanks for explaining! :-)
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Can I remove stg sync --undo ?
From: Karl Hasselström @ 2008-07-02 7:25 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
I'm preparing a patch that removes all the old --undo flags, and
discovered that stg sync has an --undo flag backed by
stack.undo_refresh().
Is it OK if I remove it? "stg undo" will allow you to undo the whole
command, or, in case of conflicts, either the whole command or just
the last conflicting push. But it does not allow for undoing the last
refresh (whether it succeeded or not). I don't know how refresh is
used, so I can't really tell if "stg undo" is currently insufficient.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [PATCH] git-add--interactive: manual hunk editing mode
From: Thomas Rast @ 2008-07-02 7:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jeff King
In-Reply-To: <7v7ic4hmj5.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 2904 bytes --]
Junio C Hamano wrote:
>
> People with minimum Perl installation should still be able to use "add -i"
> as long as they do not use 'e' subcommand, shouldn't they? Shouldn't we
> do something like:
[...]
> and disable 'e' subcommand unless $can_use_temp?
I can just call the temporary editing file something constant, like
the commit message already is. I don't care much about that point,
and honestly assumed File::Temp came with every Perl (it's in
perl-base here).
> > +# To remove '-' lines, make them ' ' lines (context).
> > +# To remove '+' lines, delete them.
> > +# Lines starting with # will be removed.
>
> Don't you want to say "Do not touch lines that begin with ' '"?
Why? You can make them '-' instead if you really want to :-)
> > + # Reinsert the first hunk header if the user accidentally deleted it
>
> Hmm, perhaps not even giving the "@@ ... @@" lines to the editor would be
> a more robust solution?
I originally left it there because Emacs automatically recounts the
header, and it also reminds the user of the function the hunk applies
to.
> > + open $fh, '| git apply --recount --cached --check';
>
> Have to wonder where the potential error message would go, and if it would
> confuse the end users...
To the terminal. If we eat that error message, the user gets
absolutely no indication as to _what_ might be wrong with the edited
patch, so I kind of deliberately left it there.
Then again the message from git-apply is not exactly transparent
either.
> I recall that the original "add--interactive" carefully counted numbers in
> hunks it reassembles (as it can let you split and then you can choose to
> use both parts, which requires it to merge overlapping hunks back), but if
> you are going to use --recount anyway, perhaps we can discard that logic?
We briefly talked about that[1], but Jeff thought it should be a
separate patch, and I agree. Can't sneakily rip out two dozen lines
of otherwise unrelated code in my feature patch, can I?
> It may make the patch application less robust, though. I dunno.
I've become convinced it can't, apart from making it less likely to
trip over bugs in the script itself of course.
> An alternative, and probably more robust, approach would be to recount
> what we have in @{$mode->{TEXT}}, after letting the user edit some of
> them, so that "add--interactive" still knows what it is doing after
> applying your patch without having to rely on "apply --recount".
You lost me here. Why recount the mode part?
If you mean the _hunk_ headers, that's what the first three versions
of this patch did, at the expense of a lot of code complication (and
now that git-apply implements --recount, actually _duplication_).
- Thomas
[1] http://article.gmane.org/gmane.comp.version-control.git/84698
--
Thomas Rast
trast@student.ethz.ch
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* What's in git.git (stable)
From: Junio C Hamano @ 2008-07-02 6:28 UTC (permalink / raw)
To: git
In-Reply-To: <7vabh93lk6.fsf@gitster.siamese.dyndns.org>
There are a few fixes on 'maint', in addition to futureproofing of "git
shell" so that eventually we can update the ssh clients to ask for server
side programs using "git upload-pack" syntax without a dash between "git"
and the subcommand name.
Many of the medimu size items for 1.6.0 have been merged to 'master'. The
port to MinGW series will also be merged shortly.
----------------------------------------------------------------
GIT v1.6.0 Release Notes (draft)
================================
User visible changes
--------------------
With the default Makefile settings, most of the programs are now
installed outside your $PATH, except for "git", "gitk", "git-gui" and
some server side programs that need to be accessible for technical
reasons. Invoking a git subcommand as "git-xyzzy" from the command
line has been deprecated since early 2006 (and officially announced in
1.5.4 release notes); use of them from your scripts after adding
output from "git --exec-path" to the $PATH is still supported in this
release, but users are again strongly encouraged to adjust their
scripts to use "git xyzzy" form, as we will stop installing
"git-xyzzy" hardlinks for built-in commands in later releases.
Source changes needed for porting to MinGW environment are now all in the
main git.git codebase.
By default, packfiles created with this version uses delta-base-offset
encoding introduced in v1.4.4. Pack idx files are using version 2 that
allows larger packs and added robustness thanks to its CRC checking,
introduced in v1.5.2.
Updates since v1.5.6
--------------------
(subsystems)
* git-p4 in contrib learned "allowSubmit" configuration to control on
which branch to allow "submit" subcommand.
(portability)
* Sample hook scripts shipped in templates/ are now suffixed with
*.sample. We used to prevent them from triggering by default by
relying on the fact that we install them as unexecutable, but on
some filesystems this approach does not work. Instead of running
"chmod +x" on them, the users who want to activate these samples
as-is can now rename them dropping *.sample suffix.
* perl's in-place edit (-i) does not work well without backup files on Windows;
some tests are rewritten to cope with this.
(documentation)
* Updated howto/update-hook-example
* Got rid of usage of "git-foo" from the tutorial.
* Disambiguating "--" between revs and paths is finally documented.
(performance, robustness, sanity etc.)
* even more documentation pages are now accessible via "man" and "git help".
* reduced excessive inlining to shrink size of the "git" binary.
* verify-pack checks the object CRC when using version 2 idx files.
* When an object is corrupt in a pack, the object became unusable even
when the same object is available in a loose form, We now try harder to
fall back to these redundant objects when able. In particular, "git
repack -a -f" can be used to fix such a corruption as long as necessary
objects are available.
* git-clone does not create refs in loose form anymore (it behaves as
if you immediately ran git-pack-refs after cloning). This will help
repositories with insanely large number of refs.
* core.fsyncobjectfiles configuration can be used to ensure that the loose
objects created will be fsync'ed (this is only useful on filesystems
that does not order data writes properly).
* "git commit-tree" plumbing can make Octopus with more than 16 parents.
"git commit" has been capable of this for quite some time.
(usability, bells and whistles)
* git-apply can handle a patch that touches the same path more than once
much better than before.
* git-apply can be told not to trust the line counts recorded in the input
patch but recount, with the new --recount option.
* git-archive can be told to omit certain paths from its output using
export-ignore attributes.
* git-clone can clone from a remote whose URL would be rewritten by
configuration stored in $HOME/.gitconfig now.
* git-diff --check now checks leftover merge conflict markers.
* When remote side used to have branch 'foo' and git-fetch finds that now
it has branch 'foo/bar', it refuses to lose the existing remote tracking
branch and its reflog. The error message has been improved to suggest
pruning the remote if the user wants to proceed and get the latest set
of branches from the remote, including such 'foo/bar'.
* fast-export learned to export and import marks file; this can be used to
interface with fast-import incrementally.
* Original SHA-1 value for "update-ref -d" is optional now.
* git-send-mail can talk not just over SSL but over TLS now.
* You can tell "git status -u" to even more aggressively omit checking
untracked files with --untracked-files=no.
* Error codes from gitweb are made more descriptive where possible, rather
than "403 forbidden" as we used to issue everywhere.
(internal)
Fixes since v1.5.6
------------------
All of the fixes in v1.5.6 maintenance series are included in
this release, unless otherwise noted.
* diff -c/--cc showed unnecessary "deletion" lines at the context
boundary (needs backmerge to maint).
* "git-clone <src> <dst>" did not create leading directories for <dst>
like the scripted version used to do (needs backport to maint).
----------------------------------------------------------------
* The 'maint' branch has these fixes since v1.5.6.1.
Avery Pennarun (1):
git-svn: avoid filling up the disk with temp files.
Björn Steinbrink (1):
git cat-file: Fix memory leak in batch mode
Eric Wong (1):
git-svn: don't sanitize remote names in config
Jeff King (1):
doc/rev-parse: clarify reflog vs --until for specifying revisions
Jochen Voss (1):
avoid off-by-one error in run_upload_archive
Joey Hess (1):
fix git config example syntax
Junio C Hamano (5):
diff --check: do not discard error status upon seeing a good line
git-shell: accept "git foo" form
GIT 1.5.4.6
GIT 1.5.5.5
Start draft release notes for 1.5.6.2
Thomas Rast (1):
Fix 'git show' on signed tag of signed tag of commit
* The 'master' branch has these since the last announcement
in addition to the above.
Alex Riesen (1):
Fix use of "perl -i" on Windows
Brian Gernhardt (2):
Fix t4017-diff-retval for white-space from wc
Add test results directory to t/.gitignore
Christian Couder (1):
help: check early if we have a command, if not try a documentation topic
Dmitry Potapov (2):
update-hook-example: optionally allow non-fast-forward
shrink git-shell by avoiding redundant dependencies
Don Zickus (1):
git-apply: handle a patch that touches the same path more than once
better
Jeff King (3):
improve for-each-ref test script
fetch: report local storage errors in status table
fetch: give a hint to the user when local refs fail to update
Jing Xue (1):
Add 'git-p4.allowSubmit' to git-p4
Johan Herland (4):
Incorporate fetched packs in future object traversal
Move pack_refs() and friends into libgit
Prepare testsuite for a "git clone" that packs refs
Teach "git clone" to pack refs
Johannes Schindelin (4):
clone: respect url.insteadOf setting in global configs
commit-tree: lift completely arbitrary limit of 16 parents
Allow git-apply to recount the lines in a hunk (AKA recountdiff)
clone: respect the settings in $HOME/.gitconfig and /etc/gitconfig
Jonathan Nieder (7):
Documentation: fix links to tutorials and other new manual pages
whitespace fix in Documentation/git-repack.txt
Documentation: complicate example of "man git-command"
git-daemon(1): don't assume git-daemon is in /usr/bin
Documentation: prepare to be consistent about "git-" versus "git "
Documentation: be consistent about "git-" versus "git "
Documentation formatting and cleanup
Junio C Hamano (15):
git-shell: accept "git foo" form
Prepare execv_git_cmd() for removal of builtins from the filesystem
Keep some git-* programs in $(bindir)
Allow "git-reset path" when unambiguous
Start draft release notes for 1.6.0
diff --check: explain why we do not care whether old side is binary
check_and_emit_line(): rename and refactor
checkdiff: pass diff_options to the callback
Teach "diff --check" about new blank lines at end
diff --check: detect leftover conflict markers
Update sample pre-commit hook to use "diff --check"
Document the double-dash "rev -- path" disambiguator
t9700: skip when Test::More is not available
Update draft release notes for 1.6.0
Update draft release notes for 1.6.0
Kevin Ballard (1):
git-send-email: Accept fifos as well as files
Lea Wiemann (5):
t/test-lib.sh: add test_external and test_external_without_stderr
Git.pm: add test suite
gitweb: standarize HTTP status codes
test-lib.sh: show git init output when in verbose mode
GIT-VERSION-GEN: do not fail if a 'HEAD' file exists in the working copy
Linus Torvalds (4):
Split up default "core" config parsing into helper routine
Split up default "user" config parsing into helper routine
Split up default "i18n" and "branch" config parsing into helper routines
Add config option to enable 'fsync()' of object files
Miklos Vajna (1):
A simple script to parse the results from the testcases
Nanako Shiraishi (1):
gitcli: Document meaning of --cached and --index
Nguyễn Thái Ngọc Duy (1):
Move all dashed-form commands to libexecdir
Nicolas Pitre (2):
repack.usedeltabaseoffset config option now defaults to "true"
pack.indexversion config option now defaults to 2
Olivier Marin (2):
Documentation: remove {show,whatchanged}.difftree config options
show_stats(): fix stats width calculation
Patrick Higgins (1):
Remove the use of '--' in merge program invocation
Stephan Beyer (2):
api-builtin.txt: update and fix typo
t3404: stricter tests for git-rebase--interactive
Sverre Rabbelier (2):
Modify test-lib.sh to output stats to t/test-results/*
Hook up the result aggregation in the test makefile.
Ted Percival (1):
Don't use dash commands (git-foo) in tutorial-2
Thomas Rast (2):
git-send-email: add support for TLS via Net::SMTP::SSL
git-send-email: prevent undefined variable warnings if no encryption is
set
jrnieder@uchicago.edu (1):
Documentation: don't assume git-sh-setup and git-parse-remote are in PATH
^ permalink raw reply
* [StGit PATCH 2/2] Reuse the same temp index in a transaction
From: Karl Hasselström @ 2008-07-02 6:13 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <20080702060113.11361.39006.stgit@yoghurt>
Instead of making a new temp index every time we need one, just keep
reusing the same one. And keep track of which tree is currently stored
in it -- if we do several consecutive successful pushes, it's always
going to be the "right" tree so that we don't have to call read-tree
before each patch application.
The motivation behind this change is of course that it makes things
faster.
(The same simple test as in the previous patch -- pushing 250 patches
in a 32k-file repository, with one file-level merge necessary per push
-- went from 0.36 to 0.19 seconds per patch with this patch applied.)
Signed-off-by: Karl Hasselström <kha@treskal.com>
---
stgit/lib/git.py | 43 +++++++++++++++++++++++++++++--------------
stgit/lib/transaction.py | 12 +++++++++++-
2 files changed, 40 insertions(+), 15 deletions(-)
diff --git a/stgit/lib/git.py b/stgit/lib/git.py
index a38eaa5..c98e919 100644
--- a/stgit/lib/git.py
+++ b/stgit/lib/git.py
@@ -459,31 +459,46 @@ class Repository(RunWithEnv):
def set_head_ref(self, ref, msg):
self.run(['git', 'symbolic-ref', '-m', msg, 'HEAD', ref]).no_output()
def simple_merge(self, base, ours, theirs):
+ index = self.temp_index()
+ try:
+ result, index_tree = self.index_merge(base, ours, theirs,
+ index, None)
+ finally:
+ index.delete()
+ return result
+ def index_merge(self, base, ours, theirs, index, current):
"""Given three L{Tree}s, tries to do an in-index merge with a
- temporary index. Returns the result L{Tree}, or None if the
- merge failed (due to conflicts)."""
+ temporary index. Returns a pair: the result L{Tree}, or None
+ if the merge failed (due to conflicts); and the L{Tree} now
+ stored in the index.
+
+ C{index} is the L{Index} object to use for the merge.
+ C{current} is the L{Tree} object currently stored in the given
+ index. If this is the same as C{ours}, some work is saved.
+ (C{current} may be C{None}, in which case this optimization is
+ disabled.)"""
assert isinstance(base, Tree)
assert isinstance(ours, Tree)
assert isinstance(theirs, Tree)
+ assert isinstance(index, Index)
+ assert current == None or isinstance(current, Tree)
# Take care of the really trivial cases.
if base == ours:
- return theirs
+ return (theirs, current)
if base == theirs:
- return ours
+ return (ours, current)
if ours == theirs:
- return ours
+ return (ours, current)
- index = self.temp_index()
- index.read_tree(ours)
+ if current != ours:
+ index.read_tree(ours)
try:
- try:
- index.apply_treediff(base, theirs)
- return index.write_tree()
- except MergeException:
- return None
- finally:
- index.delete()
+ index.apply_treediff(base, theirs)
+ result = index.write_tree()
+ return result, result
+ except MergeException:
+ return None, ours
def apply(self, tree, patch_text):
"""Given a L{Tree} and a patch, will either return the new L{Tree}
that results when the patch is applied, or None if the patch
diff --git a/stgit/lib/transaction.py b/stgit/lib/transaction.py
index e47997e..b4d4b75 100644
--- a/stgit/lib/transaction.py
+++ b/stgit/lib/transaction.py
@@ -1,6 +1,8 @@
"""The L{StackTransaction} class makes it possible to make complex
updates to an StGit stack in a safe and convenient way."""
+import atexit
+
from stgit import exception, utils
from stgit.utils import any, all
from stgit.out import *
@@ -84,6 +86,7 @@ class StackTransaction(object):
self.__allow_conflicts = lambda trans: allow_conflicts
else:
self.__allow_conflicts = allow_conflicts
+ self.__temp_index = self.temp_index_tree = None
stack = property(lambda self: self.__stack)
patches = property(lambda self: self.__patches)
def __set_applied(self, val):
@@ -97,6 +100,12 @@ class StackTransaction(object):
or self.patches[self.applied[0]].data.parent == val)
self.__base = val
base = property(lambda self: self.__base, __set_base)
+ @property
+ def temp_index(self):
+ if not self.__temp_index:
+ self.__temp_index = self.__stack.repository.temp_index()
+ atexit.register(self.__temp_index.delete)
+ return self.__temp_index
def __checkout(self, tree, iw):
if not self.__stack.head_top_equal():
out.error(
@@ -238,7 +247,8 @@ class StackTransaction(object):
base = oldparent.data.tree
ours = cd.parent.data.tree
theirs = cd.tree
- tree = self.__stack.repository.simple_merge(base, ours, theirs)
+ tree, self.temp_index_tree = self.__stack.repository.index_merge(
+ base, ours, theirs, self.temp_index, self.temp_index_tree)
merge_conflict = False
if not tree:
if iw == None:
^ permalink raw reply related
* [StGit PATCH 1/2] Do simple in-index merge with diff+apply instead of read-tree
From: Karl Hasselström @ 2008-07-02 6:12 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <20080702060113.11361.39006.stgit@yoghurt>
The advantage is that patch application will resolve some file content
conflicts for us, so that we'll fall back to merge-recursive less
often. This is a significant speedup, especially since merge-recursive
needs to touch the worktree, which means we have to check out the
index first.
(A simple test, pushing 250 patches in a 32k-file repository, with one
file-level merge necessary per push, went from 1.07 to 0.36 seconds
per patch with this patch applied.)
Signed-off-by: Karl Hasselström <kha@treskal.com>
---
stgit/lib/git.py | 13 ++++++++-----
1 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/stgit/lib/git.py b/stgit/lib/git.py
index 6ccdfa7..a38eaa5 100644
--- a/stgit/lib/git.py
+++ b/stgit/lib/git.py
@@ -475,9 +475,10 @@ class Repository(RunWithEnv):
return ours
index = self.temp_index()
+ index.read_tree(ours)
try:
- index.merge(base, ours, theirs)
try:
+ index.apply_treediff(base, theirs)
return index.write_tree()
except MergeException:
return None
@@ -548,10 +549,6 @@ class Index(RunWithEnv):
return False
else:
return True
- def merge(self, base, ours, theirs):
- """In-index merge, no worktree involved."""
- self.run(['git', 'read-tree', '-m', '-i', '--aggressive',
- base.sha1, ours.sha1, theirs.sha1]).no_output()
def apply(self, patch_text):
"""In-index patch application, no worktree involved."""
try:
@@ -559,6 +556,12 @@ class Index(RunWithEnv):
).raw_input(patch_text).no_output()
except run.RunException:
raise MergeException('Patch does not apply cleanly')
+ def apply_treediff(self, tree1, tree2):
+ """Apply the diff from C{tree1} to C{tree2} to the index."""
+ # Passing --full-index here is necessary to support binary
+ # files. It is also sufficient, since the repository already
+ # contains all involved objects.
+ self.apply(self.__repository.diff_tree(tree1, tree2, ['--full-index']))
def delete(self):
if os.path.isfile(self.__filename):
os.remove(self.__filename)
^ permalink raw reply related
* [StGit PATCH 0/2] push optimizations
From: Karl Hasselström @ 2008-07-02 6:12 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
Here's the git-apply call you asked for. You were right: it was a huge
speed-up. I set up a benchmark to test it:
* 32 directories, each containing 32 subdirectories, each containing
32 small (and different) files.
* A series of 250 patches that each add a line to one of the files.
* An "upstream" that adds a line first in every file.
* I set all this up with a python script feeding fast-import. A huge
time-saver!
* Pop patches, git-reset to upstream, then goto top patch. This
makes sure that we use the new infrastructure to push, and that we
get one file-level conflict in each patch.
Before the first patch, the "goto" command took 4:27 minutes,
wall-clock time. After the first patch, it took 1:31. After the
second, 0:48; one second or so slower than the stable branch (which
does not have a patch stack log).
Available in kha/experimental.
---
Karl Hasselström (2):
Reuse the same temp index in a transaction
Do simple in-index merge with diff+apply instead of read-tree
stgit/lib/git.py | 52 +++++++++++++++++++++++++++++++---------------
stgit/lib/transaction.py | 12 ++++++++++-
2 files changed, 46 insertions(+), 18 deletions(-)
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [PATCH] git-add--interactive: manual hunk editing mode
From: Junio C Hamano @ 2008-07-02 5:39 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, Jeff King
In-Reply-To: <1214912674-9443-1-git-send-email-trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
> diff --git a/git-add--interactive.perl b/git-add--interactive.perl
> index 903953e..6bb117a 100755
> --- a/git-add--interactive.perl
> +++ b/git-add--interactive.perl
> @@ -2,6 +2,7 @@
>
> use strict;
> use Git;
> +use File::Temp;
People with minimum Perl installation should still be able to use "add -i"
as long as they do not use 'e' subcommand, shouldn't they? Shouldn't we
do something like:
my $can_use_temp = eval {
require File::Temp;
1;
};
and disable 'e' subcommand unless $can_use_temp?
> +sub edit_hunk_manually {
> + my ($oldtext) = @_;
> +
> + my $t = File::Temp->new(
> + TEMPLATE => $repo->repo_path . "/git-hunk-edit.XXXXXX",
> + SUFFIX => '.diff'
> + );
> + print $t "# Manual hunk edit mode -- see bottom for a quick guide\n";
> + print $t @$oldtext;
> + print $t <<EOF;
> +# ---
> +# To remove '-' lines, make them ' ' lines (context).
> +# To remove '+' lines, delete them.
> +# Lines starting with # will be removed.
Don't you want to say "Do not touch lines that begin with ' '"?
> + # Reinsert the first hunk header if the user accidentally deleted it
> + if ($newtext[0] !~ /^@/) {
> + unshift @newtext, $oldtext->[0];
> + }
Hmm, perhaps not even giving the "@@ ... @@" lines to the editor would be
a more robust solution?
> +sub diff_applies {
> + my $fh;
> + open $fh, '| git apply --recount --cached --check';
> + for my $h (@_) {
> + print $fh @{$h->{TEXT}};
> + }
> + return close $fh;
Have to wonder where the potential error message would go, and if it would
confuse the end users...
> @@ -1002,7 +1123,8 @@ sub patch_update_file {
> if (@result) {
> my $fh;
>
> - open $fh, '| git apply --cached';
> + open $fh, '| git apply --cached'
> + . ($need_recount ? ' --recount' : '');
> for (@{$head->{TEXT}}, @result) {
> print $fh $_;
> }
I recall that the original "add--interactive" carefully counted numbers in
hunks it reassembles (as it can let you split and then you can choose to
use both parts, which requires it to merge overlapping hunks back), but if
you are going to use --recount anyway, perhaps we can discard that logic?
It may make the patch application less robust, though. I dunno.
An alternative, and probably more robust, approach would be to recount
what we have in @{$mode->{TEXT}}, after letting the user edit some of
them, so that "add--interactive" still knows what it is doing after
applying your patch without having to rely on "apply --recount".
^ permalink raw reply
* Re: [PATCH] git-gui: Implement "Stage/Unstage Line"
From: Shawn O. Pearce @ 2008-07-02 5:23 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Git Mailing List
In-Reply-To: <48649519.1010307@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> wrote:
> From: Johannes Sixt <johannes.sixt@telecom.at>
>
> This adds a context menu entry below "Stage/Unstage Hunk" that stages or
> unstages just the line under the mouse pointer.
Thanks! After some brief testing this is in now my tree on repo.or.cz.
> Disclaimer: I'm Tcl/Tk illiterate. Feel free to munge the patch
> to your taste.
I wouldn't say illiterate, given this contribution. :)
> The 'do_rescan' is probably a bit heavy-weight. But editing the
> diff window like we do in "Stage Hunk" would be a bit complex, and
> just redisplaying the diff is easier.
Yea, I see why you are doing a do_rescan at the end. I was going
to suggest just calling reshow_diff but that doesn't get the lists
updated properly when a file is being initially staged as a result
of the current line being added.
Editing the Tk widget is possible, but it can be a pain.
> Furthermore, I don't know why I have to do the loop until
> "end - 1 chars". If it goes until "end", then the hunk contains
> an extra line, so that the patch in general does not apply.
> Is there an extra newline in the diff view that is not in the
> git diff output?
Yup. Tk text widgets have an extra "\n" at the end of the content
that was inserted into it. Thus an empty text widget has a single
LF as its content. Weird, I know.
--
Shawn.
^ permalink raw reply
* Re: git-gui fails to start
From: Shawn O. Pearce @ 2008-07-02 4:53 UTC (permalink / raw)
To: Michael P. Soulier; +Cc: git
In-Reply-To: <20080627002307.GE2620@tigger.digitaltorque.ca>
"Michael P. Soulier" <msoulier@digitaltorque.ca> wrote:
>
> I'm on a CentOS Linux box, tracking 4.6 with Git 1.5.5.4 built
> from source.
>
> When I run gitk on a repository it works fine, but nothing happens when I run
> git-gui. No error messages, nothing.
...
> and then it just sits there.
>
> I have Tcl/Tk 8.4.9.
I think this was fixed in gitgui-0.10.2, which did not ship with
Git proper until 1.5.6-rc0. Now that 1.5.6.1 has been released I
would encourage you to upgrade to the latest stable release of Git.
The issue was aspell earlier than 0.60 caused git-gui to deadlock
because it didn't understand "$$cr master", which git-gui sends
on startup when it launches the background spell checker.
You can also work around the issue by disabling the spell checker:
git config --global gui.spellingdictionary none
--
Shawn.
^ permalink raw reply
* What's cooking in git.git (topics)
From: Junio C Hamano @ 2008-07-02 4:41 UTC (permalink / raw)
To: git
In-Reply-To: <7v3amv1e8n.fsf@gitster.siamese.dyndns.org>
Here are the topics that have been cooking. Commits prefixed
with '-' are only in 'pu' while commits prefixed with '+' are
in 'next'.
The topics list the commits in reverse chronological order. The topics
meant to be applied to the maintenance series have "maint-" in their
names.
It already is beginning to become clear what 1.6.0 will look like. What's
already in 'next' all are well intentioned (I do not guarantee they are
already bug-free --- that is what cooking them in 'next' is for) and are
good set of feature enhancements. Bigger changes will be:
* MinGW will be in.
* With the default Makefile settings, most of the programs will be
installed outside your $PATH, except for "git", "gitk", "git-gui" and
some server side programs that need to be accessible for technical
reasons. Invoking a git subcommand as "git-xyzzy" from the command
line has been deprecated since early 2006 (and officially announced in
1.5.4 release notes); use of them from your scripts after adding
output from "git --exec-path" to the $PATH will still be supported in
1.6.0, but users are again strongly encouraged to adjust their
scripts to use "git xyzzy" form, as we will stop installing
"git-xyzzy" hardlinks for built-in commands in later releases.
* git-merge will be rewritten in C.
* default pack and idx versions will be updated as scheduled for some
time ago.
* GIT_CONFIG, which was only documented as affecting "git config", but
actually affected all git commands, now only affects "git config".
GIT_LOCAL_CONFIG, also only documented as affecting "git config" and
not different from GIT_CONFIG in a useful way, is removed.
----------------------------------------------------------------
[New Topics]
* js/import-zip (Mon Jun 30 19:50:44 2008 +0100) 1 commit
+ Add another fast-import example, this time for .zip files
* js/apply-root (Tue Jul 1 00:44:47 2008 +0100) 1 commit
+ Teach "git apply" to prepend a prefix with "--root=<root>"
* db/no-git-config (Mon Jun 30 03:37:47 2008 -0400) 1 commit
+ Only use GIT_CONFIG in "git config", not other programs
----------------------------------------------------------------
[Will merge to master soon]
* j6t/mingw (Sat Nov 17 20:48:14 2007 +0100) 38 commits
+ compat/pread.c: Add a forward declaration to fix a warning
+ Windows: Fix ntohl() related warnings about printf formatting
+ Windows: TMP and TEMP environment variables specify a temporary
directory.
+ Windows: Make 'git help -a' work.
+ Windows: Work around an oddity when a pipe with no reader is
written to.
+ Windows: Make the pager work.
+ When installing, be prepared that template_dir may be relative.
+ Windows: Use a relative default template_dir and ETC_GITCONFIG
+ Windows: Compute the fallback for exec_path from the program
invocation.
+ Turn builtin_exec_path into a function.
+ Windows: Use a customized struct stat that also has the st_blocks
member.
+ Windows: Add a custom implementation for utime().
+ Windows: Add a new lstat and fstat implementation based on Win32
API.
+ Windows: Implement a custom spawnve().
+ Windows: Implement wrappers for gethostbyname(), socket(), and
connect().
+ Windows: Work around incompatible sort and find.
+ Windows: Implement asynchronous functions as threads.
+ Windows: Disambiguate DOS style paths from SSH URLs.
+ Windows: A rudimentary poll() emulation.
+ Windows: Implement start_command().
+ Windows: A pipe() replacement whose ends are not inherited to
children.
+ Windows: Wrap execve so that shell scripts can be invoked.
+ Windows: Implement setitimer() and sigaction().
+ Windows: Fix PRIuMAX definition.
+ Windows: Implement gettimeofday().
+ Make my_mktime() public and rename it to tm_to_time_t()
+ Windows: Work around misbehaved rename().
+ Windows: always chmod(, 0666) before unlink().
+ Windows: A minimal implemention of getpwuid().
+ Windows: Implement a wrapper of the open() function.
+ Windows: Strip ".exe" from the program name.
+ Windows: Handle absolute paths in
safe_create_leading_directories().
+ Windows: Treat Windows style path names.
+ setup.c: Prepare for Windows directory separators.
+ Windows: Use the Windows style PATH separator ';'.
+ Add target architecture MinGW.
+ Compile some programs only conditionally.
+ Add compat/regex.[ch] and compat/fnmatch.[ch].
No explanation necessary ;-)
----------------------------------------------------------------
[Actively Cooking]
* jc/reflog-expire (Sat Jun 28 22:24:49 2008 -0700) 2 commits
- Make default expiration period of reflog used for stash infinite
- Per-ref reflog expiry configuration
As 1.6.0 will be a good time to make backward incompatible changes, the
tip commit makes the default expiry period of stash 'never', unless you
configure them to expire explicitly using gc.refs/stash.* variables.
Needs consensus, but I am guessing that enough people would want stash
that does not expire.
We may want to change the commit topology used to represent a stash, as
proposed in $gmane/85055 by Nana earlier.
* jc/merge-theirs (Mon Jun 30 22:18:57 2008 -0700) 4 commits
- Make "subtree" part more orthogonal to the rest of merge-
recursive.
+ Teach git-merge to pass -X<option> to the backend strategy module
+ git-merge-recursive-{ours,theirs}
+ git-merge-file --ours, --theirs
Punting a merge by discarding your own work in conflicting parts but still
salvaging the parts that are cleanly automerged. It is likely that this
will result in nonsense mishmash, but somehow often people want this, so
here they are. The interface to the backends is updated so that you can
say "git merge -Xours -Xsubtree=foo/bar/baz -s recursive other" now.
* mv/merge-in-c (Tue Jul 1 04:37:50 2008 +0200) 14 commits
- Build in merge
- git-commit-tree: make it usable from other builtins
- Add new test case to ensure git-merge prepends the custom merge
message
- Add new test case to ensure git-merge reduces octopus parents when
possible
- Introduce reduce_heads()
- Introduce get_merge_bases_many()
- Add new test to ensure git-merge handles more than 25 refs.
- Introduce get_octopus_merge_bases() in commit.c
- git-fmt-merge-msg: make it usable from other builtins
- Move read_cache_unmerged() to read-cache.c
- Add new test to ensure git-merge handles pull.twohead and
pull.octopus
- Move parse-options's skip_prefix() to git-compat-util.h
- Move commit_list_count() to commit.c
- Move split_cmdline() to alias.c
I think this is getting there. Will be in 'next' soon.
* dr/ceiling (Mon May 19 23:49:34 2008 -0700) 4 commits
+ Eliminate an unnecessary chdir("..")
+ Add support for GIT_CEILING_DIRECTORIES
+ Fold test-absolute-path into test-path-utils
+ Implement normalize_absolute_path
* jc/rerere (Sun Jun 22 02:04:31 2008 -0700) 5 commits
+ rerere.autoupdate
+ t4200: fix rerere test
+ rerere: remove dubious "tail_optimization"
+ git-rerere: detect unparsable conflicts
+ rerere: rerere_created_at() and has_resolution() abstraction
A new configuration will allow paths that have been resolved cleanly by
rerere to be updated in the index automatically.
* ph/parseopt-step-blame (Tue Jun 24 11:12:12 2008 +0200) 7 commits
- Migrate git-blame to parse-option partially.
- parse-opt: add PARSE_OPT_KEEP_ARGV0 parser option.
- parse-opt: fake short strings for callers to believe in.
- parse-opt: do not print errors on unknown options, return -2
intead.
- parse-opt: create parse_options_step.
- parse-opt: Export a non NORETURN usage dumper.
- parse-opt: have parse_options_{start,end}.
I recall Pierre said something about cleaning up the last one when he
finds time, but other than that vague recollection, I lost track of this
series. I am tempted to fork a few topics off of the penúltimo one to
convert a few more commands as examples and merge the result to 'next'.
----------------------------------------------------------------
[Graduated to "master"]
* ph/mergetool (Mon Jun 16 17:33:41 2008 -0600) 1 commit
+ Remove the use of '--' in merge program invocation
I got tired of waiting for success reports from people who use various
backends. We will hear breakages if this breaks things anyway, and if it
does, it is a fairly simple single patch to revert.
* nd/dashless (Tue Jun 24 19:58:11 2008 -0700) 2 commits
+ Keep some git-* programs in $(bindir)
+ Move all dashed-form commands to libexecdir
We'll leave server-side programs in $(bindir) so that ssh clients can ask
for "git-program" and find them on the $PATH. Next major release after
1.6.0 would most likely remove the hardlinks to built-in commands, but not
yet.
* jc/dashless (Thu Jun 26 16:43:34 2008 -0700) 2 commits
+ Prepare execv_git_cmd() for removal of builtins from the
filesystem
+ git-shell: accept "git foo" form
The botched "client asks 'git foo'" is not included. It will be long
after everybody runs 1.6.0.
* jk/maint-fetch-ref-hier (Fri Jun 27 00:01:41 2008 -0400) 2 commits
+ fetch: give a hint to the user when local refs fail to update
+ fetch: report local storage errors in status table
When the remote used to have "foo" branch but now has "foo/bar", fetch
refuses to delete the existing remote tracking branch "foo" to create a
new remote tracking branch "foo/bar", but the error message was
confusing.
Need to backmerge to 'maint' after a while.
* jc/maint-reset (Wed Jun 25 18:16:36 2008 -0700) 1 commit
+ Allow "git-reset path" when unambiguous
We used to require "git-reset -- path" even when there is no ambiguity
(i.e. path cannot be mistaken as a valid tree-ish and it is a filename in
the work tree).
Need to backmerge to 'maint' after a while.
* js/maint-clone-insteadof (Fri Jun 27 13:55:23 2008 +0100) 2 commits
+ clone: respect the settings in $HOME/.gitconfig and /etc/gitconfig
+ clone: respect url.insteadOf setting in global configs
"git clone" did not honor "url.InsteadOf" in $HOME/.gitconfig. I think
Daniel's "Let's get rid of internal use of GIT_CONFIG" makes sense (even
though it feels very scary), and it would make the solution much simpler,
but these two are independently good fix for now. I'll queue GIT_CONFIG
one in 'next' and when it graduates the unsetenv() solution in these will
become no-op.
* tr/send-email-ssl (Thu Jun 26 23:03:21 2008 +0200) 2 commits
+ git-send-email: prevent undefined variable warnings if no
encryption is set
+ git-send-email: add support for TLS via Net::SMTP::SSL
* kb/send-email-fifo (Wed Jun 25 15:44:40 2008 -0700) 1 commit
+ git-send-email: Accept fifos as well as files
Two minor send-email feature enhancements.
* jc/checkdiff (Sun Jun 29 16:49:06 2008 -0400) 7 commits
+ Fix t4017-diff-retval for white-space from wc
+ Update sample pre-commit hook to use "diff --check"
+ diff --check: detect leftover conflict markers
+ Teach "diff --check" about new blank lines at end
+ checkdiff: pass diff_options to the callback
+ check_and_emit_line(): rename and refactor
+ diff --check: explain why we do not care whether old side is
binary
Allows us to replace the sample pre-commit hook that was not aware of the
line termination convention per path nor newer whitespace breakage rules.
* np/pack-default (Wed Jun 25 00:25:53 2008 -0400) 2 commits
+ pack.indexversion config option now defaults to 2
+ repack.usedeltabaseoffset config option now defaults to "true"
Updates the default value for pack.indexversion to 2 and use delta-base
offset encoding of the packfiles by default.
* js/apply-recount (Fri Jun 27 18:43:09 2008 +0100) 1 commit
+ Allow git-apply to recount the lines in a hunk (AKA recountdiff)
A good ingredient for implementing "apply --edit".
* dz/apply-again (Fri Jun 27 14:39:12 2008 -0400) 1 commit
+ git-apply: handle a patch that touches the same path more than
once better
Allows us to feed a patch that touches the same path more than once.
----------------------------------------------------------------
[On Hold]
* sg/merge-options (Sun Apr 6 03:23:47 2008 +0200) 1 commit
+ merge: remove deprecated summary and diffstat options and config
variables
This was previously in "will be in master soon" category, but it turns out
that the synonyms to the ones this one deletes are fairly new invention
that happend in 1.5.6 timeframe, and we cannot do this just yet.
* jc/dashless (Thu Jun 26 16:43:34 2008 -0700) 2 commits
+ Revert "Make clients ask for "git program" over ssh and local
transport"
+ Make clients ask for "git program" over ssh and local transport
This is the "botched" one. Will be resurrected during 1.7.0 or 1.8.0
timeframe.
* jk/renamelimit (Sat May 3 13:58:42 2008 -0700) 1 commit
- diff: enable "too large a rename" warning when -M/-C is explicitly
asked for
This would be the right thing to do for command line use, but gitk will be
hit due to tcl/tk's limitation, so I am holding this back for now.
----------------------------------------------------------------
[Stalled/Needs more work]
* jc/blame (Wed Jun 4 22:58:40 2008 -0700) 7 commits
- blame: show "previous" information in --porcelain/--incremental
format
- git-blame: refactor code to emit "porcelain format" output
+ git-blame --reverse
+ builtin-blame.c: allow more than 16 parents
+ builtin-blame.c: move prepare_final() into a separate function.
+ rev-list --children
+ revision traversal: --children option
The blame that finds where each line in the original lines moved to. This
may help a GSoC project that wants to gather statistical overview of the
history. The final presentation may need tweaking (see the log message of
the commit ""git-blame --reverse" on the series).
The tip two commits are for peeling to see what's behind the blamed
commit, which we should be able to separate out into an independent topic
from the rest.
----------------------------------------------------------------
[Dropped for now]
* sj/merge (Sat May 3 16:55:47 2008 -0700) 6 commits
. Introduce fast forward option only
. Head reduction before selecting merge strategy
. Restructure git-merge.sh
. Introduce -ff=<fast forward option>
. New merge tests
. Documentation for joining more than two histories
This will interfere with Miklos's rewrite of merge to C.
* js/rebase-i-sequencer (Sun Apr 27 02:55:50 2008 -0400) 17 commits
. Use perl instead of tac
. Fix t3404 assumption that `wc -l` does not use whitespace.
. rebase -i: Use : in expr command instead of match.
. rebase -i: update the implementation of 'mark' command
. Add option --preserve-tags
. Teach rebase interactive the tag command
. Add option --first-parent
. Do rebase with preserve merges with advanced TODO list
. Select all lines with fake-editor
. Unify the length of $SHORT* and the commits in the TODO list
. Teach rebase interactive the merge command
. Move redo merge code in a function
. Teach rebase interactive the reset command
. Teach rebase interactive the mark command
. Move cleanup code into it's own function
. Don't append default merge message to -m message
. fake-editor: output TODO list if unchanged
* jc/cherry-pick (Wed Feb 20 23:17:06 2008 -0800) 3 commits
. WIP: rethink replay merge
. Start using replay-tree merge in cherry-pick
. revert/cherry-pick: start refactoring call to merge_recursive
This is meant to improve cherry-pick's behaviour when renames are
involved, by not using merge-recursive (whose d/f conflict resolution is
quite broken), but unfortunately has stalled for some time now.
* jc/stripspace (Sun Mar 9 00:30:35 2008 -0800) 6 commits
. git-am --forge: add Signed-off-by: line for the author
. git-am: clean-up Signed-off-by: lines
. stripspace: add --log-clean option to clean up signed-off-by:
lines
. stripspace: use parse_options()
. Add "git am -s" test
. git-am: refactor code to add signed-off-by line for the committer
Just my toy at this moment.
* jc/send-pack-tell-me-more (Thu Mar 20 00:44:11 2008 -0700) 1 commit
. "git push": tellme-more protocol extension
^ permalink raw reply
* Re: [PATCH/v2] git-basis, a script to manage bases for git-bundle
From: Jeff King @ 2008-07-02 3:21 UTC (permalink / raw)
To: Adam Brewster; +Cc: git, Jakub Narebski
In-Reply-To: <c376da900807011836i76363d74n7f1b87d66ba34cd6@mail.gmail.com>
On Tue, Jul 01, 2008 at 09:36:20PM -0400, Adam Brewster wrote:
> Makes sense, I thought it was small enough for one commit, but I'll
> split it up when I resubmit.
I think in this instance it is not too big a deal either way. I am just
trying to help encourage good habits. :)
> > Style: we usually spell NUL as '\0'.
>
> Okay. I can also include a third patch for the code I cut-and-pasted.
Heh. I said "usually", but I guess even Junio makes mistakes (unless I
am dreaming such a style directive, but ISTR it being mentioned before
on the list). I wouldn't bother with the style cleanup in rev-list
(usually for such small things, we just wait until touching that part of
the code).
> > Why make a hash when the only thing we ever do with it is "keys %new"?
> > Shouldn't an array suffice?
>
> It's probably a non-issue, but using a hash will prevent duplicates.
Ah, true. And there will be duplicates here, if you have multiple refs
at the same spot in your bundle list. So it should remain as you have
it.
> If all goes well then you're right, but I thought old objects should
> be kept around in case the user has some reason to manually delete
> them. As it is, you can go into the basis file and delete everything
> past a given date line and be back where you were. If I delete the
> redundant objects, then that's not always possible.
Hmm, and that might be useful. Probably the best thing would be to leave
it as-is for now, then, with a note. Then we can decide the best pruning
strategy if and when it becomes an issue.
> Maybe I'm a idiot, but I can't find any built-in date to string
> functions that do nice things like print the date the way the user
> says he likes to look at dates.
>
> I updated the comment line to be "# <git-date> // `date`" where
> git-date is as per git-fast-import (seconds since 1969 +/-TZ). If
> automatic pruning ever happens, the git-date will be used, so `date`
> is just for humans.
That sounds reasonable.
> > Notably absent: any tests.
> Working on those. I'll also include tests for git-bundle.
Great. Glancing over Junio's comments, though, it might make sense to
integrate this more tightly with git-bundle, in which case the perl
stuff would go away. So I'll let you work out with him which is the best
route.
-Peff
^ permalink raw reply
* Re: [RFC/PATCH 2/4] Add git-sequencer prototype documentation
From: Stephan Beyer @ 2008-07-02 3:01 UTC (permalink / raw)
To: Jakub Narebski, Junio C Hamano; +Cc: git, Johannes Schindelin
In-Reply-To: <200807020239.41613.jnareb@gmail.com>
On Wed, Jul 02, 2008 at 02:39:40AM +0200, Jakub Narebski wrote:
> On Tue, 1 July 2008, Stephan Beyer wrote:
> > On Tue, Jul 01, 2008 at 08:04:10PM +0200, Jakub Narebski wrote:
[...]
> > No. It is "git-update-ref <ref> HEAD".
>
> So what do you envision would this be used for?
I think if I had not started on top js/rebase-i-sequencer, I would have
not necessarily added "ref" (or "tag", as it was before).
But js/rebase-i-sequencer introduced a nice feature to
git-rebase-i:
-t,--preserve-tags ... "update tags to the new commit object"
I think this is worth the feature ;-)
On Tue, Jul 01, 2008 at 06:20:15PM -0700, Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
> >> No. It is "git-update-ref <ref> HEAD".
> >
> > So what do you envision would this be used for?
>
> A simple answer and a more elaborate one.
>
> * It is the final step of "git rebase" which detaches HEAD while it
> operates these days.
Ha ;)
That's a quite obvious truth that I have not implemented.
Btw: sequencer does the detaching/attaching when using "--onto <base>"
and <base> is a branch.
IIRC there was a reason that I also kept the detaching/attaching of
git-rebase-i itself but I can't remember. (I think I have to look
over the rebase-i code more carefully later...)
> * You can drive sequencer backend from a front-end that rewrite history
> while rewriting tags, like filter-branch does.
Yes.
> >>> What is important is: does it update reflog (correctly)?
>
> That is not very important question, as reflog updates would happen as
> long as you use update-ref automatically.
>
> Much more important question you did not ask is how it would interact with
> "sequencer --abort". Ideally it should rewind the ref update (and without
> relying on the user having reflog on that ref).
Yes, you asked the question in the RFC thread about the spec.
"Rewind the ref update" means:
- delete new generated refs
- update overwritten refs to their old commits
So if I keep a list containing <ref> [<oldcommit>], that behavior
is easily reached. But this is not suited for the shell prototype ;)
Btw, also the --skip case can be arguable:
pick fa1afe1
pick cedefe1 # conflict, will be "--skip"ped
ref refs/tags/v1.6.2
Here the question can be, if the "ref" should be skipped, too.
But I think the just-don't-care-strategy is a good one, so
that fa1afe1' will be tagged.
> I however personally feel that this "ref" thing is being a bit too
> ambitious.
I agree that it is no must-have feature but a nice-to-have feature ;)
Especially for the --preserve-tags feature.
Jakub wrote:
> >>>>> +squash [options] --from <mark>::
> > [...]
> >>> Here an example why it is useful for user-editing:
> >>>
> >>> (on commit f00babe)
> >>> mark :1
> >>> pick badcebab
> >>> patch foo
> >>> pick dadadada
> >>> squash -m "Foo the cebab" --signoff --from :1
> >>>
> >>> This squashes all between the mark and the squash into one commit,
> >>> on top of f00babe.
> >>
> >> Ah, so squash --from <mark> picks up everything since "mark <mark>",
> >> but does not include marked commit! Clever! In this case allowing
> >> only <mark> is a good idea, IMVHO.
> >
> > Good, thanks :)
>
> Although I guess having example would make it clear from the go...
Yes, I see that the EXAMPLES section is really important and the
squash --from is important therein.
Regards,
Stephan
--
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F
^ permalink raw reply
* Re: [PATCH/v2] git-basis, a script to manage bases for git-bundle
From: Jay Soffian @ 2008-07-02 2:21 UTC (permalink / raw)
To: Adam Brewster; +Cc: Jeff King, git, Jakub Narebski
In-Reply-To: <c376da900807011916j5a3032een4587619535061b72@mail.gmail.com>
On Tue, Jul 1, 2008 at 10:16 PM, Adam Brewster <adambrewster@gmail.com> wrote:
> But of course one function returns two very different things depending
> on what's on the left side of the equals sign. That makes perfect
> sense.
Context should be the very first thing taught in any Perl tutorial,
lest ye end up in jail:
http://yro.slashdot.org/article.pl?sid=01/03/13/208259
:-)
j.
^ 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