* Re: Handle HTTP error 511 Network Authentication Required (standard secure proxy authentification/captive portal detection)
From: Jeff King @ 2012-02-20 1:06 UTC (permalink / raw)
To: Nicolas Mailhot; +Cc: git
In-Reply-To: <4b8f33ba4c870528a82ab85d6dad68bd.squirrel@arekh.dyndns.org>
On Sun, Feb 19, 2012 at 10:03:37PM +0100, Nicolas Mailhot wrote:
> The IETF finally set up to fix this problem and defined a standard HTTP error
> that lets access control equipments tell the web client authentication or
> re-authentication is needed and where the authentication form is located.
>
> http://tools.ietf.org/id/draft-nottingham-http-new-status-04.txt
>
> → <http://www.rfc-editor.org/queue2.html#draft-nottingham-http-new-status> (the
> spec is approved and in the queue for publication as RFC)
>
> Please add error 511 handling in git, so git users that try to access external
> git repositories over http can authenticate on the corporate proxy
If I'm reading this right, the process works something like this:
1. Git wants to make a request to http://example.com
2. We make our request to a proxy server which is transparently
proxying our traffic (i.e, a "captive portal").
3. The proxy returns 511 along with some URL (e.g.,
"http://login.corporatenetwork"), indicating that we need
to go to that URL to complete some authentication.
As a non-browser client, what should git do? We can't make sense of the
content at http://login.corporatenetwork, which is most likely an HTML
form asking for credentials (or even money, if the captive portal is
something like a public wireless provider). The best we can probably do
is die and say "apparently you need to go http://login.corporatenetwork
in a browser before making your request".
Reading that rfc draft, the man impetus for non-browser clients seems
not to get them to do anything useful, but rather to return them a code
that is clearly not from the actual site (if it were a redirect, for
example, then we would think that example.com is redirecting is, which
is simply not true).
-Peff
^ permalink raw reply
* [PATCH 0/5] diff --ignore-case
From: Junio C Hamano @ 2012-02-20 2:16 UTC (permalink / raw)
To: git
This teaches our "diff" machinery to optionally consider lines that are
different only in upper/lower-cases to be equivalent.
Junio C Hamano (5):
xdiff: remove XDL_PATCH_* macros
xdiff: PATIENCE/HISTOGRAM are not independent option bits
xdiff: introduce XDF_INEXACT_MATCH
xdiff: introduce XDF_IGNORE_CASE
diff: --ignore-case
Documentation/diff-options.txt | 4 +++
diff.c | 8 +++---
diff.h | 2 ++
merge-recursive.c | 4 +--
t/lib-diff-alternative.sh | 45 +++++++++++++++++++++++++++++++--
t/t4033-diff-patience.sh | 6 +++++
t/t4050-diff-histogram.sh | 2 ++
xdiff/xdiff.h | 19 ++++++++------
xdiff/xdiffi.c | 4 +--
xdiff/xhistogram.c | 2 +-
xdiff/xpatience.c | 2 +-
xdiff/xprepare.c | 21 ++++++++--------
xdiff/xutils.c | 54 ++++++++++++++++++++++++++++++++--------
13 files changed, 133 insertions(+), 40 deletions(-)
--
1.7.9.1.265.g25f75
^ permalink raw reply
* [PATCH 1/5] xdiff: remove XDL_PATCH_* macros
From: Junio C Hamano @ 2012-02-20 2:16 UTC (permalink / raw)
To: git
In-Reply-To: <1329704188-9955-1-git-send-email-gitster@pobox.com>
These are not used anywhere in our codebase, and the bit assignment
definition is merely confusing.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
xdiff/xdiff.h | 5 -----
1 file changed, 5 deletions(-)
diff --git a/xdiff/xdiff.h b/xdiff/xdiff.h
index 00d36c3..70c8b87 100644
--- a/xdiff/xdiff.h
+++ b/xdiff/xdiff.h
@@ -36,11 +36,6 @@ extern "C" {
#define XDF_HISTOGRAM_DIFF (1 << 6)
#define XDF_WHITESPACE_FLAGS (XDF_IGNORE_WHITESPACE | XDF_IGNORE_WHITESPACE_CHANGE | XDF_IGNORE_WHITESPACE_AT_EOL)
-#define XDL_PATCH_NORMAL '-'
-#define XDL_PATCH_REVERSE '+'
-#define XDL_PATCH_MODEMASK ((1 << 8) - 1)
-#define XDL_PATCH_IGNOREBSPACE (1 << 8)
-
#define XDL_EMIT_FUNCNAMES (1 << 0)
#define XDL_EMIT_COMMON (1 << 1)
#define XDL_EMIT_FUNCCONTEXT (1 << 2)
--
1.7.9.1.265.g25f75
^ permalink raw reply related
* [PATCH 2/5] xdiff: PATIENCE/HISTOGRAM are not independent option bits
From: Junio C Hamano @ 2012-02-20 2:16 UTC (permalink / raw)
To: git
In-Reply-To: <1329704188-9955-1-git-send-email-gitster@pobox.com>
Because the default Myers, patience and histogram algorithms cannot be in
effect at the same time, XDL_PATIENCE_DIFF and XDL_HISTOGRAM_DIFF are not
independent bits. Instead of wasting one bit per algorithm, define a few
macros to access the few bits they occupy and update the code that access
them.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
diff.c | 4 ++--
diff.h | 2 ++
merge-recursive.c | 4 ++--
xdiff/xdiff.h | 5 ++++-
xdiff/xdiffi.c | 4 ++--
xdiff/xhistogram.c | 2 +-
xdiff/xpatience.c | 2 +-
xdiff/xprepare.c | 21 ++++++++++-----------
8 files changed, 24 insertions(+), 20 deletions(-)
diff --git a/diff.c b/diff.c
index 374ecf3..52cda7a 100644
--- a/diff.c
+++ b/diff.c
@@ -3400,9 +3400,9 @@ int diff_opt_parse(struct diff_options *options, const char **av, int ac)
else if (!strcmp(arg, "--ignore-space-at-eol"))
DIFF_XDL_SET(options, IGNORE_WHITESPACE_AT_EOL);
else if (!strcmp(arg, "--patience"))
- DIFF_XDL_SET(options, PATIENCE_DIFF);
+ options->xdl_opts = DIFF_WITH_ALG(options, PATIENCE_DIFF);
else if (!strcmp(arg, "--histogram"))
- DIFF_XDL_SET(options, HISTOGRAM_DIFF);
+ options->xdl_opts = DIFF_WITH_ALG(options, HISTOGRAM_DIFF);
/* flags options */
else if (!strcmp(arg, "--binary")) {
diff --git a/diff.h b/diff.h
index 0c51724..e688a48 100644
--- a/diff.h
+++ b/diff.h
@@ -88,6 +88,8 @@ typedef struct strbuf *(*diff_prefix_fn_t)(struct diff_options *opt, void *data)
#define DIFF_XDL_SET(opts, flag) ((opts)->xdl_opts |= XDF_##flag)
#define DIFF_XDL_CLR(opts, flag) ((opts)->xdl_opts &= ~XDF_##flag)
+#define DIFF_WITH_ALG(opts, flag) (((opts)->xdl_opts & ~XDF_DIFF_ALGORITHM_MASK) | XDF_##flag)
+
enum diff_words_type {
DIFF_WORDS_NONE = 0,
DIFF_WORDS_PORCELAIN,
diff --git a/merge-recursive.c b/merge-recursive.c
index cc664c3..1d574fe 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -2069,9 +2069,9 @@ int parse_merge_opt(struct merge_options *o, const char *s)
else if (!prefixcmp(s, "subtree="))
o->subtree_shift = s + strlen("subtree=");
else if (!strcmp(s, "patience"))
- o->xdl_opts |= XDF_PATIENCE_DIFF;
+ o->xdl_opts = DIFF_WITH_ALG(o, PATIENCE_DIFF);
else if (!strcmp(s, "histogram"))
- o->xdl_opts |= XDF_HISTOGRAM_DIFF;
+ o->xdl_opts = DIFF_WITH_ALG(o, HISTOGRAM_DIFF);
else if (!strcmp(s, "ignore-space-change"))
o->xdl_opts |= XDF_IGNORE_WHITESPACE_CHANGE;
else if (!strcmp(s, "ignore-all-space"))
diff --git a/xdiff/xdiff.h b/xdiff/xdiff.h
index 70c8b87..09215af 100644
--- a/xdiff/xdiff.h
+++ b/xdiff/xdiff.h
@@ -32,9 +32,12 @@ extern "C" {
#define XDF_IGNORE_WHITESPACE (1 << 2)
#define XDF_IGNORE_WHITESPACE_CHANGE (1 << 3)
#define XDF_IGNORE_WHITESPACE_AT_EOL (1 << 4)
+#define XDF_WHITESPACE_FLAGS (XDF_IGNORE_WHITESPACE | XDF_IGNORE_WHITESPACE_CHANGE | XDF_IGNORE_WHITESPACE_AT_EOL)
+
#define XDF_PATIENCE_DIFF (1 << 5)
#define XDF_HISTOGRAM_DIFF (1 << 6)
-#define XDF_WHITESPACE_FLAGS (XDF_IGNORE_WHITESPACE | XDF_IGNORE_WHITESPACE_CHANGE | XDF_IGNORE_WHITESPACE_AT_EOL)
+#define XDF_DIFF_ALGORITHM_MASK (XDF_PATIENCE_DIFF | XDF_HISTOGRAM_DIFF)
+#define XDF_DIFF_ALG(x) ((x) & XDF_DIFF_ALGORITHM_MASK)
#define XDL_EMIT_FUNCNAMES (1 << 0)
#define XDL_EMIT_COMMON (1 << 1)
diff --git a/xdiff/xdiffi.c b/xdiff/xdiffi.c
index 75a3922..bc889e8 100644
--- a/xdiff/xdiffi.c
+++ b/xdiff/xdiffi.c
@@ -328,10 +328,10 @@ int xdl_do_diff(mmfile_t *mf1, mmfile_t *mf2, xpparam_t const *xpp,
xdalgoenv_t xenv;
diffdata_t dd1, dd2;
- if (xpp->flags & XDF_PATIENCE_DIFF)
+ if (XDF_DIFF_ALG(xpp->flags) == XDF_PATIENCE_DIFF)
return xdl_do_patience_diff(mf1, mf2, xpp, xe);
- if (xpp->flags & XDF_HISTOGRAM_DIFF)
+ if (XDF_DIFF_ALG(xpp->flags) == XDF_HISTOGRAM_DIFF)
return xdl_do_histogram_diff(mf1, mf2, xpp, xe);
if (xdl_prepare_env(mf1, mf2, xpp, xe) < 0) {
diff --git a/xdiff/xhistogram.c b/xdiff/xhistogram.c
index 18f6f99..bf99787 100644
--- a/xdiff/xhistogram.c
+++ b/xdiff/xhistogram.c
@@ -252,7 +252,7 @@ static int fall_back_to_classic_diff(struct histindex *index,
int line1, int count1, int line2, int count2)
{
xpparam_t xpp;
- xpp.flags = index->xpp->flags & ~XDF_HISTOGRAM_DIFF;
+ xpp.flags = index->xpp->flags & ~XDF_DIFF_ALGORITHM_MASK;
return xdl_fall_back_diff(index->env, &xpp,
line1, count1, line2, count2);
diff --git a/xdiff/xpatience.c b/xdiff/xpatience.c
index fdd7d02..04e1a1a 100644
--- a/xdiff/xpatience.c
+++ b/xdiff/xpatience.c
@@ -288,7 +288,7 @@ static int fall_back_to_classic_diff(struct hashmap *map,
int line1, int count1, int line2, int count2)
{
xpparam_t xpp;
- xpp.flags = map->xpp->flags & ~XDF_PATIENCE_DIFF;
+ xpp.flags = map->xpp->flags & ~XDF_DIFF_ALGORITHM_MASK;
return xdl_fall_back_diff(map->env, &xpp,
line1, count1, line2, count2);
diff --git a/xdiff/xprepare.c b/xdiff/xprepare.c
index e419f4f..63a22c6 100644
--- a/xdiff/xprepare.c
+++ b/xdiff/xprepare.c
@@ -181,7 +181,7 @@ static int xdl_prepare_ctx(unsigned int pass, mmfile_t *mf, long narec, xpparam_
if (!(recs = (xrecord_t **) xdl_malloc(narec * sizeof(xrecord_t *))))
goto abort;
- if (xpp->flags & XDF_HISTOGRAM_DIFF)
+ if (XDF_DIFF_ALG(xpp->flags) == XDF_HISTOGRAM_DIFF)
hbits = hsize = 0;
else {
hbits = xdl_hashbits((unsigned int) narec);
@@ -209,8 +209,8 @@ static int xdl_prepare_ctx(unsigned int pass, mmfile_t *mf, long narec, xpparam_
crec->ha = hav;
recs[nrec++] = crec;
- if (!(xpp->flags & XDF_HISTOGRAM_DIFF) &&
- xdl_classify_record(pass, cf, rhash, hbits, crec) < 0)
+ if ((XDF_DIFF_ALG(xpp->flags) != XDF_HISTOGRAM_DIFF) &&
+ xdl_classify_record(pass, cf, rhash, hbits, crec) < 0)
goto abort;
}
}
@@ -273,16 +273,15 @@ int xdl_prepare_env(mmfile_t *mf1, mmfile_t *mf2, xpparam_t const *xpp,
* (nrecs) will be updated correctly anyway by
* xdl_prepare_ctx().
*/
- sample = xpp->flags & XDF_HISTOGRAM_DIFF ? XDL_GUESS_NLINES2 : XDL_GUESS_NLINES1;
+ sample = (XDF_DIFF_ALG(xpp->flags) == XDF_HISTOGRAM_DIFF
+ ? XDL_GUESS_NLINES2 : XDL_GUESS_NLINES1);
enl1 = xdl_guess_lines(mf1, sample) + 1;
enl2 = xdl_guess_lines(mf2, sample) + 1;
- if (!(xpp->flags & XDF_HISTOGRAM_DIFF) &&
- xdl_init_classifier(&cf, enl1 + enl2 + 1, xpp->flags) < 0) {
-
+ if (XDF_DIFF_ALG(xpp->flags) != XDF_HISTOGRAM_DIFF &&
+ xdl_init_classifier(&cf, enl1 + enl2 + 1, xpp->flags) < 0)
return -1;
- }
if (xdl_prepare_ctx(1, mf1, enl1, xpp, &cf, &xe->xdf1) < 0) {
@@ -296,9 +295,9 @@ int xdl_prepare_env(mmfile_t *mf1, mmfile_t *mf2, xpparam_t const *xpp,
return -1;
}
- if (!(xpp->flags & XDF_PATIENCE_DIFF) &&
- !(xpp->flags & XDF_HISTOGRAM_DIFF) &&
- xdl_optimize_ctxs(&cf, &xe->xdf1, &xe->xdf2) < 0) {
+ if ((XDF_DIFF_ALG(xpp->flags) != XDF_PATIENCE_DIFF) &&
+ (XDF_DIFF_ALG(xpp->flags) != XDF_HISTOGRAM_DIFF) &&
+ xdl_optimize_ctxs(&cf, &xe->xdf1, &xe->xdf2) < 0) {
xdl_free_ctx(&xe->xdf2);
xdl_free_ctx(&xe->xdf1);
--
1.7.9.1.265.g25f75
^ permalink raw reply related
* [PATCH 3/5] xdiff: introduce XDF_INEXACT_MATCH
From: Junio C Hamano @ 2012-02-20 2:16 UTC (permalink / raw)
To: git
In-Reply-To: <1329704188-9955-1-git-send-email-gitster@pobox.com>
The XDF_WHITESPACE_FLAGS mask is used to decide if a simple memcmp() is
sufficient to tell if two lines are the same for the purpose of producing
diff. In the current code, only options in the ignore-whitespace family
happen to call for a matching logic that is more complex than memcmp(),
but when we add new options, e.g. ignore-case, it will become apparent
that the mask is misnamed.
Introduce XDF_INEXACT_MATCH mask to express its true meaning: when any of
these bits are set, we may need to inspect the contents of the two lines
that are not exactly the same, as we may still consider them "matching".
The XDF_WHITESPACE_FLAGS will become useful again in a later patch in the
series and its definition is kept.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
diff.c | 2 +-
xdiff/xdiff.h | 6 +++++-
xdiff/xutils.c | 4 ++--
3 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/diff.c b/diff.c
index 52cda7a..87b2ec1 100644
--- a/diff.c
+++ b/diff.c
@@ -2142,7 +2142,7 @@ static void builtin_diff(const char *name_a,
struct emit_callback ecbdata;
const struct userdiff_funcname *pe;
- if (!DIFF_XDL_TST(o, WHITESPACE_FLAGS) || must_show_header) {
+ if (!DIFF_XDL_TST(o, INEXACT_MATCH) || must_show_header) {
fprintf(o->file, "%s", header.buf);
strbuf_reset(&header);
}
diff --git a/xdiff/xdiff.h b/xdiff/xdiff.h
index 09215af..48793f9 100644
--- a/xdiff/xdiff.h
+++ b/xdiff/xdiff.h
@@ -32,7 +32,11 @@ extern "C" {
#define XDF_IGNORE_WHITESPACE (1 << 2)
#define XDF_IGNORE_WHITESPACE_CHANGE (1 << 3)
#define XDF_IGNORE_WHITESPACE_AT_EOL (1 << 4)
-#define XDF_WHITESPACE_FLAGS (XDF_IGNORE_WHITESPACE | XDF_IGNORE_WHITESPACE_CHANGE | XDF_IGNORE_WHITESPACE_AT_EOL)
+#define XDF_WHITESPACE_FLAGS \
+ (XDF_IGNORE_WHITESPACE | \
+ XDF_IGNORE_WHITESPACE_CHANGE | \
+ XDF_IGNORE_WHITESPACE_AT_EOL)
+#define XDF_INEXACT_MATCH XDF_WHITESPACE_FLAGS
#define XDF_PATIENCE_DIFF (1 << 5)
#define XDF_HISTOGRAM_DIFF (1 << 6)
diff --git a/xdiff/xutils.c b/xdiff/xutils.c
index 0de084e..aa6de74 100644
--- a/xdiff/xutils.c
+++ b/xdiff/xutils.c
@@ -176,7 +176,7 @@ int xdl_recmatch(const char *l1, long s1, const char *l2, long s2, long flags)
if (s1 == s2 && !memcmp(l1, l2, s1))
return 1;
- if (!(flags & XDF_WHITESPACE_FLAGS))
+ if (!(flags & XDF_INEXACT_MATCH))
return 0;
i1 = 0;
@@ -281,7 +281,7 @@ unsigned long xdl_hash_record(char const **data, char const *top, long flags) {
unsigned long ha = 5381;
char const *ptr = *data;
- if (flags & XDF_WHITESPACE_FLAGS)
+ if (flags & XDF_INEXACT_MATCH)
return xdl_hash_record_with_whitespace(data, top, flags);
for (; ptr < top && *ptr != '\n'; ptr++) {
--
1.7.9.1.265.g25f75
^ permalink raw reply related
* [PATCH 5/5] diff: --ignore-case
From: Junio C Hamano @ 2012-02-20 2:16 UTC (permalink / raw)
To: git
In-Reply-To: <1329704188-9955-1-git-send-email-gitster@pobox.com>
Teach the front-end to flip XDF_IGNORE_CASE bit with the options GNU diff
uses.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Documentation/diff-options.txt | 4 ++++
diff.c | 2 ++
t/lib-diff-alternative.sh | 45 ++++++++++++++++++++++++++++++++++++++--
t/t4033-diff-patience.sh | 6 ++++++
t/t4050-diff-histogram.sh | 2 ++
5 files changed, 57 insertions(+), 2 deletions(-)
diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
index 9f7cba2..791e07f 100644
--- a/Documentation/diff-options.txt
+++ b/Documentation/diff-options.txt
@@ -404,6 +404,10 @@ endif::git-format-patch[]
differences even if one line has whitespace where the other
line has none.
+--ignore-case::
+ Ignore changes in case only; only ASCII alphabet is supported for
+ now.
+
--inter-hunk-context=<lines>::
Show the context between diff hunks, up to the specified number
of lines, thereby fusing hunks that are close to each other.
diff --git a/diff.c b/diff.c
index 87b2ec1..d7604b7 100644
--- a/diff.c
+++ b/diff.c
@@ -3399,6 +3399,8 @@ int diff_opt_parse(struct diff_options *options, const char **av, int ac)
DIFF_XDL_SET(options, IGNORE_WHITESPACE_CHANGE);
else if (!strcmp(arg, "--ignore-space-at-eol"))
DIFF_XDL_SET(options, IGNORE_WHITESPACE_AT_EOL);
+ else if (!strcmp(arg, "--ignore-case"))
+ DIFF_XDL_SET(options, IGNORE_CASE);
else if (!strcmp(arg, "--patience"))
options->xdl_opts = DIFF_WITH_ALG(options, PATIENCE_DIFF);
else if (!strcmp(arg, "--histogram"))
diff --git a/t/lib-diff-alternative.sh b/t/lib-diff-alternative.sh
index 75ffd91..45c665e 100644
--- a/t/lib-diff-alternative.sh
+++ b/t/lib-diff-alternative.sh
@@ -104,8 +104,9 @@ EOF
STRATEGY=$1
+ cmd='git diff --no-index'
test_expect_success "$STRATEGY diff" '
- test_must_fail git diff --no-index "--$STRATEGY" file1 file2 > output &&
+ test_must_fail $cmd ${STRATEGY:+"--$STRATEGY"} file1 file2 >output &&
test_cmp expect output
'
@@ -157,9 +158,49 @@ EOF
STRATEGY=$1
+ cmd='git diff --no-index'
test_expect_success 'completely different files' '
- test_must_fail git diff --no-index "--$STRATEGY" uniq1 uniq2 > output &&
+
+ test_must_fail $cmd ${STRATEGY:+"--$STRATEGY"} uniq1 uniq2 >output &&
test_cmp expect output
'
}
+test_diff_ignore () {
+
+ STRATEGY=$1
+
+ echo "A quick brown fox" >test.0
+ echo "A quick brown fox" >test-b
+ echo " A quick brownfox" >test-w
+ echo "A quick brown fox " >test--ignore-space-at-eol
+ echo "A Quick Brown Fox" >test--ignore-case
+ echo "A Quick Brown Fox" >test--ignore-case-b
+ echo "A quick brown fox jumps" >test
+ cases="-b -w --ignore-space-at-eol --ignore-case"
+
+ if test -z "$STRATEGY"
+ then
+ label=baseline
+ else
+ label=$STRATEGY
+ fi
+
+ cmd="git diff --no-index ${STRATEGY:+--$STRATEGY}"
+
+ test_expect_success "$label diff" '
+ test_must_fail $cmd test.0 test
+ '
+ for case in $cases
+ do
+ test_expect_success "$label diff $case" '
+ $cmd $case test.0 test$case &&
+ test_must_fail $cmd test.0 test
+ '
+ done
+
+ test_expect_success "$label diff -b --ignore-case" '
+ $cmd -b --ignore-case test.0 test--ignore-case-b
+ '
+
+}
diff --git a/t/t4033-diff-patience.sh b/t/t4033-diff-patience.sh
index 3c9932e..c7f8c6c 100755
--- a/t/t4033-diff-patience.sh
+++ b/t/t4033-diff-patience.sh
@@ -5,8 +5,14 @@ test_description='patience diff algorithm'
. ./test-lib.sh
. "$TEST_DIRECTORY"/lib-diff-alternative.sh
+# baseline
+test_diff_unique ""
+test_diff_ignore ""
+
test_diff_frobnitz "patience"
test_diff_unique "patience"
+test_diff_ignore "patience"
+
test_done
diff --git a/t/t4050-diff-histogram.sh b/t/t4050-diff-histogram.sh
index fd3e86a..98c6686 100755
--- a/t/t4050-diff-histogram.sh
+++ b/t/t4050-diff-histogram.sh
@@ -9,4 +9,6 @@ test_diff_frobnitz "histogram"
test_diff_unique "histogram"
+test_diff_ignore "histogram"
+
test_done
--
1.7.9.1.265.g25f75
^ permalink raw reply related
* [PATCH 4/5] xdiff: introduce XDF_IGNORE_CASE
From: Junio C Hamano @ 2012-02-20 2:16 UTC (permalink / raw)
To: git
In-Reply-To: <1329704188-9955-1-git-send-email-gitster@pobox.com>
Teach the hash function and per-line comparison logic to compare lines
while ignoring the differences in case. It is not an ignore-whitespace
option but still needs to trigger the inexact match logic, and that is
why the previous step introduced XDF_INEXACT_MATCH mask.
Assign the 7th bit for this option, and move the bits to select diff
algorithms out of the way in order to leave room for a few bits to add
more variants of ignore-whitespace, such as --ignore-tab-expansion, if
somebody else is inclined to do so later.
We would still need to teach the front-end to flip this bit, for this
change to be any useful.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
xdiff/xdiff.h | 7 ++++---
xdiff/xutils.c | 50 ++++++++++++++++++++++++++++++++++++++++++--------
2 files changed, 46 insertions(+), 11 deletions(-)
diff --git a/xdiff/xdiff.h b/xdiff/xdiff.h
index 48793f9..5a01a0e 100644
--- a/xdiff/xdiff.h
+++ b/xdiff/xdiff.h
@@ -36,10 +36,11 @@ extern "C" {
(XDF_IGNORE_WHITESPACE | \
XDF_IGNORE_WHITESPACE_CHANGE | \
XDF_IGNORE_WHITESPACE_AT_EOL)
-#define XDF_INEXACT_MATCH XDF_WHITESPACE_FLAGS
+#define XDF_IGNORE_CASE (1 << 7)
+#define XDF_INEXACT_MATCH (XDF_WHITESPACE_FLAGS | XDF_IGNORE_CASE)
-#define XDF_PATIENCE_DIFF (1 << 5)
-#define XDF_HISTOGRAM_DIFF (1 << 6)
+#define XDF_PATIENCE_DIFF (1 << 8)
+#define XDF_HISTOGRAM_DIFF (1 << 9)
#define XDF_DIFF_ALGORITHM_MASK (XDF_PATIENCE_DIFF | XDF_HISTOGRAM_DIFF)
#define XDF_DIFF_ALG(x) ((x) & XDF_DIFF_ALGORITHM_MASK)
diff --git a/xdiff/xutils.c b/xdiff/xutils.c
index aa6de74..925f1d0 100644
--- a/xdiff/xutils.c
+++ b/xdiff/xutils.c
@@ -170,6 +170,19 @@ long xdl_guess_lines(mmfile_t *mf, long sample) {
return nl + 1;
}
+static inline int match_a_byte(char ch1, char ch2, long flags)
+{
+ if (ch1 == ch2)
+ return 1;
+ if (!(flags & XDF_IGNORE_CASE) || ((ch1 | ch2) & 0x80))
+ return 0;
+ if (isupper(ch1))
+ ch1 = tolower(ch1);
+ if (isupper(ch2))
+ ch2 = tolower(ch2);
+ return (ch1 == ch2);
+}
+
int xdl_recmatch(const char *l1, long s1, const char *l2, long s2, long flags)
{
int i1, i2;
@@ -192,7 +205,7 @@ int xdl_recmatch(const char *l1, long s1, const char *l2, long s2, long flags)
if (flags & XDF_IGNORE_WHITESPACE) {
goto skip_ws;
while (i1 < s1 && i2 < s2) {
- if (l1[i1++] != l2[i2++])
+ if (!match_a_byte(l1[i1++], l2[i2++], flags))
return 0;
skip_ws:
while (i1 < s1 && XDL_ISSPACE(l1[i1]))
@@ -210,15 +223,28 @@ int xdl_recmatch(const char *l1, long s1, const char *l2, long s2, long flags)
i2++;
continue;
}
- if (l1[i1++] != l2[i2++])
+ if (!match_a_byte(l1[i1++], l2[i2++], flags))
return 0;
}
- } else if (flags & XDF_IGNORE_WHITESPACE_AT_EOL) {
- while (i1 < s1 && i2 < s2 && l1[i1++] == l2[i2++])
+ } else {
+ /*
+ * Either XDF_IGNORE_WHITESPACE_AT_EOL is set, or
+ * no whitespace is ignored, but INEXACT_MATCH is
+ * in effect for other reasons.
+ */
+ while (i1 < s1 && i2 < s2 &&
+ match_a_byte(l1[i1++], l2[i2++], flags))
; /* keep going */
}
/*
+ * If we are not ignoring any whitespace, we must have consumed
+ * everything for the lines to match.
+ */
+ if (!(flags & XDF_WHITESPACE_FLAGS))
+ return i1 == s1 && i2 == s2;
+
+ /*
* After running out of one side, the remaining side must have
* nothing but whitespace for the lines to match. Note that
* ignore-whitespace-at-eol case may break out of the loop
@@ -238,6 +264,14 @@ int xdl_recmatch(const char *l1, long s1, const char *l2, long s2, long flags)
return 1;
}
+static inline unsigned long hash_a_byte(const char ch_, long flags)
+{
+ unsigned long ch = ch_ & 0xFF;
+ if ((flags & XDF_IGNORE_CASE) && !(ch & 0x80) && isupper(ch))
+ ch = tolower(ch);
+ return ch;
+}
+
static unsigned long xdl_hash_record_with_whitespace(char const **data,
char const *top, long flags) {
unsigned long ha = 5381;
@@ -256,20 +290,20 @@ static unsigned long xdl_hash_record_with_whitespace(char const **data,
else if (flags & XDF_IGNORE_WHITESPACE_CHANGE
&& !at_eol) {
ha += (ha << 5);
- ha ^= (unsigned long) ' ';
+ ha ^= hash_a_byte(' ', flags);
}
else if (flags & XDF_IGNORE_WHITESPACE_AT_EOL
&& !at_eol) {
while (ptr2 != ptr + 1) {
ha += (ha << 5);
- ha ^= (unsigned long) *ptr2;
+ ha ^= hash_a_byte(*ptr2, flags);
ptr2++;
}
}
continue;
}
ha += (ha << 5);
- ha ^= (unsigned long) *ptr;
+ ha ^= hash_a_byte(*ptr, flags);
}
*data = ptr < top ? ptr + 1: ptr;
@@ -286,7 +320,7 @@ unsigned long xdl_hash_record(char const **data, char const *top, long flags) {
for (; ptr < top && *ptr != '\n'; ptr++) {
ha += (ha << 5);
- ha ^= (unsigned long) *ptr;
+ ha ^= hash_a_byte(*ptr, flags);
}
*data = ptr < top ? ptr + 1: ptr;
--
1.7.9.1.265.g25f75
^ permalink raw reply related
* Re: git-svn won't remember pem password
From: Nikolaus Demmel @ 2012-02-20 3:08 UTC (permalink / raw)
To: Jeff King; +Cc: Jakub Narebski, Igor, git, Eric Wong
In-Reply-To: <20120220005727.GA4140@sigill.intra.peff.net>
Am 20.02.2012 um 01:57 schrieb Jeff King:
> On Sat, Feb 18, 2012 at 03:30:00AM -0800, Jakub Narebski wrote:
>
>> Igor <mrigor83@gmail.com> writes:
>>
>>> I'm running into an issue where I have to enter my pem certificate
>>> password every time I git-svn fetch or git-svn dcommit. Vanilla svn
>>> uses OS X KeyChain and remembers my password just fine. Is there a
>>> known solution for this? Other users have ran into same issue as
>>> described here:
>>>
>>> http://stackoverflow.com/questions/605519/does-git-svn-store-svn-passwords
>>
>>> However, that solution of removing .subversion folder did not work
>>> for me.
>>
>> I don't know if it is svn that has to remember password, or git that
>> has to remember password. Git 1.7.9 learned "credentials API" that
>> allows integration with platform native keychain mechanisms, and I
>> think OS X Keychain is one of examples / supported platforms (but it
>> might not made it into core git)... though I am not sure if it affects
>> git-svn, or only HTTP(S) transport.
>
> It does not affect git-svn currently.
>
> I have some thoughts on providing access to the credentials API for
> scripts like git-svn (right now, it is accessible only by C git
> programs). However, there is an important question: should password
> prompting in git-svn behave like git, or behave like svn?
>
> So far, it has been the latter, and I think that is reasonable. The
> resource that requires the credentials is an svn repo, not a git repo,
> so you are more likely to want to share credentials for it with real
> svn, and not other git commands.
>
IMHO a normal user would expect git-svn to store credentials in the same way as normal svn. I think this is the way it should be.
Best regards,
Nikolaus
^ permalink raw reply
* Re: Manually decoding a git object
From: 徐迪 @ 2012-02-20 4:45 UTC (permalink / raw)
To: Philip Oakley; +Cc: Git List
In-Reply-To: <A716A27D407F401DAAC373027D5CFF2A@PhilipOakley>
2012/2/20 Philip Oakley <philipoakley@iee.org>:
> If I have a renamed file which is a git object, such a "Git_Object", was
> 8c-something-or-other, what is the easiest way of examining / decoding /
> recreating the original file (either as its sha1, or a cat-file).
>
I don't think I fully understood what you mean, I assume you just move
an object file from $GIT_DIR/objects/ to somewhere and rename it,
let's call it "obj", so if you want to exam its content you can just
simply call "git cat-file -p obj". And you can also use "git cat-file
-t obj" to exam its object type. If it's a blob you can use "git
cat-file -p obj > original" to recreate it, else it's meaningless to
recreate it.
^ permalink raw reply
* Re: Handle HTTP error 511 Network Authentication Required (standard secure proxy authentification/captive portal detection)
From: Nicolas Mailhot @ 2012-02-20 5:38 UTC (permalink / raw)
To: Jeff King; +Cc: Nicolas Mailhot, git
In-Reply-To: <20120220010617.GB4140@sigill.intra.peff.net>
Le Lun 20 février 2012 02:06, Jeff King a écrit :
> On Sun, Feb 19, 2012 at 10:03:37PM +0100, Nicolas Mailhot wrote:
>
>> The IETF finally set up to fix this problem and defined a standard HTTP
>> error
>> that lets access control equipments tell the web client authentication or
>> re-authentication is needed and where the authentication form is located.
>>
>> http://tools.ietf.org/id/draft-nottingham-http-new-status-04.txt
>>
>> → <http://www.rfc-editor.org/queue2.html#draft-nottingham-http-new-status>
>> (the
>> spec is approved and in the queue for publication as RFC)
>>
>> Please add error 511 handling in git, so git users that try to access
>> external
>> git repositories over http can authenticate on the corporate proxy
>
> If I'm reading this right, the process works something like this:
>
> 1. Git wants to make a request to http://example.com
>
> 2. We make our request to a proxy server which is transparently
> proxying our traffic (i.e, a "captive portal").
>
> 3. The proxy returns 511 along with some URL (e.g.,
> "http://login.corporatenetwork"), indicating that we need
> to go to that URL to complete some authentication.
>
> As a non-browser client, what should git do? We can't make sense of the
> content at http://login.corporatenetwork, which is most likely an HTML
> form asking for credentials (or even money, if the captive portal is
> something like a public wireless provider). The best we can probably do
> is die and say "apparently you need to go http://login.corporatenetwork
> in a browser before making your request".
Actually, the best would be to launch something capable of interpreting html
forms on the url given by the error. But short of that, that depends on how
good git is at resuming work later. Error 511 can occur at any time, not just
on initial connection (because credentials can expire at any time). So pausing
may be better than dying.
However without going there: the portal page will usually be pretty simple, a
standard basic auth form, can't git handle this? If simple web clients such as
git have specific constrains on what can appear or not on this page, can you
not define them and send them ietf-side so they can document them in a later
rfc revision?
> Reading that rfc draft, the man impetus for non-browser clients seems
> not to get them to do anything useful, but rather to return them a code
> that is clearly not from the actual site (if it were a redirect, for
> example, then we would think that example.com is redirecting is, which
> is simply not true).
The main impetus from my point of view is that captive portal/proxy auth is a
mess, because they try to trick web clients into displaying something they are
not prepared to and don't want to do, and this spec is replacing trick with
explicit request, which is nice.
Best regards,
--
Nicolas Mailhot
^ permalink raw reply
* Re: [PATCHv2 2/8] gitweb: Option for filling only specified info in fill_project_list_info
From: Junio C Hamano @ 2012-02-20 6:58 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Junio C Hamano
In-Reply-To: <1329338332-30358-3-git-send-email-jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> Introduce project_info_needs_filling($pr, $key[, \%fill_only]), which
That's "project_info_needs_filling($pr, @key[, \%fill_only])", isn't it?
> +# entry for given @keys needs filling if at least one of interesting keys
> +# in list is not present in %$project_info; key is interesting if $fill_only
> +# is not passed, or is empty (all keys are interesting in both of those cases),
> +# or if key is in $fill_only hash
> +#
> +# USAGE:
> +# * project_info_needs_filling($project_info, 'key', ...)
> +# * project_info_needs_filling($project_info, 'key', ..., \%fill_only)
> +# where %fill_only = map { $_ => 1 } @fill_only;
The reason this spells bad to me is that it gives the readers (and anybody
who may want to touch gitweb code) that the caller has _two_ ways to say
the same thing.
If a caller is interested in finding out $key in $project_info, it can
either (1) pass $key as one of the earlier parameters to the function and
not pass any \%fill_only, or (2) pass $key and pass \%fill_only but after
making sure \%fill_only also has $key defined.
And if the caller passes \%fill_only, it has to remember that it needs to
add $key to it; otherwise the earlier request "I want $key" is ignored by
the function.
Why is it a good thing to have such a convoluted API?
Is it that "fill_project_list_info" is called by multiple callers, and
they do not necessarily need to see all the fields that can be filled by
the function (namely, age, age_string, descr, descr_long, owner, ctags and
category)? If that is the case, I must say that the approach to put the
set filtering logic inside project_info_needs_filling function smells like
a bad API design.
In other words, wouldn't a callchain that uses a more natural set of API
functions be like this?
# the top-level caller that is interested only in these two fields
fill_project_list_info($projlist, 'age', 'owner');
# in fill_project_list_info()
my $projlist = shift;
my %wanted = map { $_ => 1 } @_;
foreach my $pr (@$projlist) {
if (project_info_needs_filling($pr,
filter_set(\%wanted, 'age', 'age_string'))) {
... get @activity ...
($pr->{'age'}, $pr->{'age_string'}) = @activity;
}
...
}
That way, "needs_filling" has to do one and only one thing well: it checks
if any of the fields it was asked is missing and answers. And a generic
set filtering helper that takes a filtering hashref and an array can be
used later outside of the "needs_filling" function.
> sub project_info_needs_filling {
> + my $fill_only = ref($_[-1]) ? pop : undef;
> my ($project_info, @keys) = @_;
>
> # return List::MoreUtils::any { !exists $project_info->{$_} } @keys;
> foreach my $key (@keys) {
> - if (!exists $project_info->{$key}) {
> + if ((!$fill_only || !%$fill_only || $fill_only->{$key}) &&
> + !exists $project_info->{$key}) {
> return 1;
> }
> }
> return;
> }
>
> -
Shouldn't the previous patch updated not to add this blank line in the
first place?
> # fills project list info (age, description, owner, category, forks)
Is this enumeration up-to-date? If we cannot keep it up-to-date, it may
make sense to show only a few as examples and add ellipses.
> # for each project in the list, removing invalid projects from
> -# returned list
> +# returned list, or fill only specified info (removing invalid projects
> +# only when filling 'age').
It is unclear what the added clause wants to say; especially, the link
between the mention of 'age' and 'only when' is unclear. Is asking of
'age' what makes a request a notable exception to remove invalid projects?
Or is asking to partially fill fields what triggers the removal of invalid
projects, and you mentioned 'age' as an example?
If it is the former (I am guessing it is), it would be much clearer to
say:
Invalid projects are removed from the returned list if and only if you
ask 'age' to be filled, because of such and such reasons.
^ permalink raw reply
* Re: [PATCHv2 0/8] gitweb: Faster and improved project search
From: Junio C Hamano @ 2012-02-20 7:09 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <1329338332-30358-1-git-send-email-jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> [Cc-ing Junio because of his involvement in discussion about first
> patch in previous version of this series.]
>
> First three patches in this series are mainly about speeding up
> project search (and perhaps in the future also project pagination).
> Well, first one is unification, refactoring and future-proofing.
> The second and third patch could be squashed together; second adds
> @fill_only, but third actually uses it.
I'll queue these three separately to a topic jn/gitweb-search-optim,
and fork another topic jn/gitweb-hilite-regions from there. I haven't
looked the latter closely, though.
Thanks.
^ permalink raw reply
* [PATCH 6/5] diff -i
From: Junio C Hamano @ 2012-02-20 7:36 UTC (permalink / raw)
To: git
In-Reply-To: <1329704188-9955-1-git-send-email-gitster@pobox.com>
The previous patch to teach "--ignore-case" option to our "diff" machinery
deliberately omitted a short-and-sweet "-i" that GNU diff uses to ask for
"--ignore-case". This is because our diff machinery are often used by and
shares the command line options with the commands in the "git log" family,
where the short option already means something entirely different. Namely,
it instructs to use case-insensitive match when looking for commits that
match information that appear in the commit object itself, e.g. --author
and --grep.
Tweak the option parser so that "-i" means both, so that
$ git log --grep=frotz -i -p
first picks commits that have string "frotz" in any combination of cases,
and then shows patches that ignore case-only changes for the chosen
commits, while "--ignore-case" and "--regexp-ignore-case" can be used to
mean only one, i.e.
$ git log --grep=frotz --regexp-ignore-case -p
would pick the same set of commits, but the patches shown by it does not
ignore case-only changes while
$ git log --grep=frotz --ignore-case -p
would pick commits that has "frotz" in all lowercase, but shows patches
that ignore case-only changes for the chosen commits.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Documentation/diff-options.txt | 1 +
diff.c | 2 +-
revision.c | 6 +++++-
t/lib-diff-alternative.sh | 3 ++-
4 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
index 791e07f..9ed78c9 100644
--- a/Documentation/diff-options.txt
+++ b/Documentation/diff-options.txt
@@ -404,6 +404,7 @@ endif::git-format-patch[]
differences even if one line has whitespace where the other
line has none.
+-i::
--ignore-case::
Ignore changes in case only; only ASCII alphabet is supported for
now.
diff --git a/diff.c b/diff.c
index d7604b7..9d1584e 100644
--- a/diff.c
+++ b/diff.c
@@ -3399,7 +3399,7 @@ int diff_opt_parse(struct diff_options *options, const char **av, int ac)
DIFF_XDL_SET(options, IGNORE_WHITESPACE_CHANGE);
else if (!strcmp(arg, "--ignore-space-at-eol"))
DIFF_XDL_SET(options, IGNORE_WHITESPACE_AT_EOL);
- else if (!strcmp(arg, "--ignore-case"))
+ else if (!strcmp(arg, "--ignore-case") || !strcmp(arg, "-i"))
DIFF_XDL_SET(options, IGNORE_CASE);
else if (!strcmp(arg, "--patience"))
options->xdl_opts = DIFF_WITH_ALG(options, PATIENCE_DIFF);
diff --git a/revision.c b/revision.c
index 8764dde..f1a1354 100644
--- a/revision.c
+++ b/revision.c
@@ -13,6 +13,7 @@
#include "decorate.h"
#include "log-tree.h"
#include "string-list.h"
+#include "xdiff-interface.h"
volatile show_early_output_fn_t show_early_output;
@@ -1557,7 +1558,10 @@ static int handle_revision_opt(struct rev_info *revs, int argc, const char **arg
return argcount;
} else if (!strcmp(arg, "--extended-regexp") || !strcmp(arg, "-E")) {
revs->grep_filter.regflags |= REG_EXTENDED;
- } else if (!strcmp(arg, "--regexp-ignore-case") || !strcmp(arg, "-i")) {
+ } else if (!strcmp(arg, "-i")) {
+ DIFF_XDL_SET(&revs->diffopt, IGNORE_CASE);
+ revs->grep_filter.regflags |= REG_ICASE;
+ } else if (!strcmp(arg, "--regexp-ignore-case")) {
revs->grep_filter.regflags |= REG_ICASE;
} else if (!strcmp(arg, "--fixed-strings") || !strcmp(arg, "-F")) {
revs->grep_filter.fixed = 1;
diff --git a/t/lib-diff-alternative.sh b/t/lib-diff-alternative.sh
index 45c665e..81609f8 100644
--- a/t/lib-diff-alternative.sh
+++ b/t/lib-diff-alternative.sh
@@ -175,9 +175,10 @@ test_diff_ignore () {
echo " A quick brownfox" >test-w
echo "A quick brown fox " >test--ignore-space-at-eol
echo "A Quick Brown Fox" >test--ignore-case
+ echo "A Quick Brown FoX" >test-i
echo "A Quick Brown Fox" >test--ignore-case-b
echo "A quick brown fox jumps" >test
- cases="-b -w --ignore-space-at-eol --ignore-case"
+ cases="-b -w --ignore-space-at-eol --ignore-case -i"
if test -z "$STRATEGY"
then
^ permalink raw reply related
* Re: [PATCH] completion: remote set-* <name> and <branch>
From: Junio C Hamano @ 2012-02-20 7:58 UTC (permalink / raw)
To: Philip Jägenstedt
Cc: git, SZEDER Gábor, Felipe Contreras, Teemu Likonen
In-Reply-To: <1329571973-20796-1-git-send-email-philip@foolip.org>
Philip Jägenstedt <philip@foolip.org> writes:
> Complete <name> only for set-url. For set-branches and
> set-head, complete <name> and <branch> over the network,
> like e.g. git pull already does.
>
> Signed-off-by: Philip Jägenstedt <philip@foolip.org>
You addressed your patch to Shawn, who originally wrote this, but
"git shortlog -n -s --no-merges --since=9.months pu contrib/completion"
indicates that he no longer is involved in enhancing this script, and it
has seen actions primarily from three people I Cc'ed this message to.
> contrib/completion/git-completion.bash | 12 +++++++++---
> 1 file changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
> index 1505cff..8e7abb6 100755
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -738,6 +738,9 @@ __git_complete_remote_or_refspec ()
> {
> local cur_="$cur" cmd="${words[1]}"
> local i c=2 remote="" pfx="" lhs=1 no_complete_refspec=0
> + if [ "$cmd" = "remote" ]; then
> + c=$((++c))
> + fi
I don't know about others, but auto-incrementing a variable and assigning
the result to the same variable, while not wrong at all, hurts my brain.
c=$(($c + 1))
is far more readable and does not suggest there is any funky magic
involved. Also it is a good habit to get into not to omit $ from
variables inside arithmetic substitution, even though bash allows it and
this script is meant to be consumed only by shells that understand this
bash-ism.
I do not know offhand if zsh groks it, but the point is that you do not
have to worry about it if you write "$(($c+1))" instead of "$((c+1))".
I'll let the area experts to comment on the remainder of the patch.
Thanks.
> @@ -788,7 +791,7 @@ __git_complete_remote_or_refspec ()
> __gitcomp_nl "$(__git_refs)" "$pfx" "$cur_"
> fi
> ;;
> - pull)
> + pull|remote)
> if [ $lhs = 1 ]; then
> __gitcomp_nl "$(__git_refs "$remote")" "$pfx" "$cur_"
> else
> @@ -2289,7 +2292,7 @@ _git_config ()
>
> _git_remote ()
> {
> - local subcommands="add rename rm show prune update set-head"
> + local subcommands="add rename rm set-head set-branches set-url show prune update"
> local subcommand="$(__git_find_on_cmdline "$subcommands")"
> if [ -z "$subcommand" ]; then
> __gitcomp "$subcommands"
> @@ -2297,9 +2300,12 @@ _git_remote ()
> fi
>
> case "$subcommand" in
> - rename|rm|show|prune)
> + rename|rm|set-url|show|prune)
> __gitcomp_nl "$(__git_remotes)"
> ;;
> + set-head|set-branches)
> + __git_complete_remote_or_refspec
> + ;;
> update)
> local i c='' IFS=$'\n'
> for i in $(git --git-dir="$(__gitdir)" config --get-regexp "remotes\..*" 2>/dev/null); do
^ permalink raw reply
* Re: Manually decoding a git object
From: Philip Oakley @ 2012-02-20 8:19 UTC (permalink / raw)
To: ??; +Cc: Git List
In-Reply-To: <CAMocUqRNNXpGOJ2ZG8bWpkieKkVfoo0=Lkevjw+E3Tssw68Hwg@mail.gmail.com>
From: "??" <xudifsd@gmail.com> Sent: Monday, February 20, 2012 4:45 AM
> 2012/2/20 Philip Oakley <philipoakley@iee.org>:
>> If I have a renamed file which is a git object, such a "Git_Object", was
>> 8c-something-or-other, what is the easiest way of examining / decoding /
>> recreating the original file (either as its sha1, or a cat-file).
>>
> I don't think I fully understood what you mean, I assume you just move
> an object file from $GIT_DIR/objects/ to somewhere and rename it,
> let's call it "obj", so if you want to exam its content you can just
> simply call "git cat-file -p obj". And you can also use "git cat-file
> -t obj" to exam its object type. If it's a blob you can use "git
> cat-file -p obj > original" to recreate it, else it's meaningless to
> recreate it.
When I tried it from my home directory (not in a git directory):
$ git cat-file -p Git-Object
fatal: Not a git repository (or any of the parent directories): .git
Because its sha1 isn't yet known I can't put it into the correct
.git/objects/xx/ subdirectory of an fresh 'git init', and I have located an
unzip programme that will take the plain git object and decode it - they all
expect archives.
I've described the background use-case at
http://stackoverflow.com/questions/9341278/how-to-track-the-git-directory-in-git-in-its-own-store -
the edit links to a typical corporate scenario.
Even just locating a zlib implementation that simply confirms the file
stream is compressesd and deflates it would be a start.
Philip
^ permalink raw reply
* Re: git status: small difference between stating whole repository and small subdirectory
From: Piotr Krukowiecki @ 2012-02-20 8:25 UTC (permalink / raw)
To: Jeff King
Cc: Junio C Hamano, Thomas Rast, Git Mailing List,
Nguyen Thai Ngoc Duy
In-Reply-To: <20120217222912.GC31830@sigill.intra.peff.net>
On Fri, Feb 17, 2012 at 11:29 PM, Jeff King <peff@peff.net> wrote:
> On Fri, Feb 17, 2012 at 02:25:25PM -0800, Junio C Hamano wrote:
>
>> Jeff King <peff@peff.net> writes:
>>
>> > That being said, we do have an index extension to store the tree sha1 of
>> > whole directories (i.e., we populate it when we write a whole tree or
>> > subtree into the index from the object db, and it becomes invalidated
>> > when a file becomes modified). This optimization is used by things like
>> > "git commit" to avoid having to recreate the same sub-trees over and
>> > over when creating tree objects from the index. But we could also use it
>> > here to avoid having to even read the sub-tree objects from the object
>> > db.
>>
>> Like b65982b (Optimize "diff-index --cached" using cache-tree, 2009-05-20)
>> perhaps?
>
> That's what I get for speaking before running "git log".
>
> So yeah, we may be about as reasonably fast as we can go. Or maybe that
> optimization isn't kicking in for some reason. I think going further
> would require Piotr to do more profiling.
Is the cache set? Not sure how to check it. t0090-cache-tree.sh uses
test-dump-cache-tree and executes "read-tree HEAD" to establish the
cache, but in my case read-tree does not make the cache dumpable (but
it improves status performance).
$ test-dump-cache-tree | wc -l
0
$ git read-tree HEAD
$ test-dump-cache-tree | wc -l
0
$ echo 3 | sudo tee /proc/sys/vm/drop_caches && time git status -- .
[...]
real 0m1.085s
git version 1.7.9.188.g12766
--
Piotr Krukowiecki
^ permalink raw reply
* Re: Manually decoding a git object
From: Thomas Rast @ 2012-02-20 8:29 UTC (permalink / raw)
To: Philip Oakley; +Cc: Git List
In-Reply-To: <A716A27D407F401DAAC373027D5CFF2A@PhilipOakley>
"Philip Oakley" <philipoakley@iee.org> writes:
> If I have a renamed file which is a git object, such a "Git_Object", was
> 8c-something-or-other, what is the easiest way of examining / decoding /
> recreating the original file (either as its sha1, or a cat-file).
>
> I don't appear to be able to unzip the file in its raw format... I'm using
> Msysgit on windows XP.
The SHA1 is over the decompressed object contents. The file simply
holds a zlib-compressed stream of those contents. (It's pretty much
like gzip without the file header.)
You can use any bindings to zlib and something that does sha1, e.g. in
python:
$ cd g/.git/objects/aa/ # my git.git
$ ls
592bda986a8380b64acd8cbb3d5bdfcbc0834d 6322a757bee31919f54edcc127608a3d724c99
$ python
Python 2.7.2 (default, Aug 19 2011, 20:41:43) [GCC] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import hashlib
>>> hashlib.sha1(open('592bda986a8380b64acd8cbb3d5bdfcbc0834d').read().decode('zlib')).digest().encode('hex')
'aa592bda986a8380b64acd8cbb3d5bdfcbc0834d'
Notice that the first byte of the hash goes into the directory name.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: [PATCHv2 3/8] gitweb: Faster project search
From: Junio C Hamano @ 2012-02-20 8:33 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <1329338332-30358-4-git-send-email-jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> Before searching by some field the information we search for must be
> filled in. For this fill_project_list_info() was enhanced in previous
> commit to take additional parameters which part of projects info to
"must be filled in." is correct, but that happens without the previous
patch. The first sentence must also say:
In order to search by some field, the information we look for must
be filled in, but we do not have to fill other fields that are not
involved in the search.
to justify the previous "fill_project_list_info can be asked to return
without getting unused fields" patch. The rest of the log message then
makes good sense.
> fill. This way we can limit doing expensive calculations (like
> running git-for-each-ref to get 'age' / "Last changed" info) only to
> projects which we will show as search results.
>
> With this commit the number of git commands used to generate search
> results is 2*<matched projects> + 1, and depends on number of matched
> projects rather than number of all projects (all repositories).
>
> Note: this is 'git for-each-ref' to find last activity, and 'git config'
> for each project, and 'git --version' once.
^ permalink raw reply
* Re: [PATCH 0/1] Make libintl in libc detection more robust
From: Junio C Hamano @ 2012-02-20 8:34 UTC (permalink / raw)
To: John Szakmeister; +Cc: git
In-Reply-To: <1329593884-9999-1-git-send-email-john@szakmeister.net>
John Szakmeister <john@szakmeister.net> writes:
> This is my first time submitting a patch to git. I hope I've done
> things correctly!
Looks good, except for the subject line that would have been better to say
something like:
configure: don't use -lintl when there is no gettext support
I'll tweak the log message and queue.
Thanks.
^ permalink raw reply
* Re: [PATCH 0/5] diff --ignore-case
From: Johannes Sixt @ 2012-02-20 8:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1329704188-9955-1-git-send-email-gitster@pobox.com>
Am 20.02.2012 03:16, schrieb Junio C Hamano:
> This teaches our "diff" machinery to optionally consider lines that are
> different only in upper/lower-cases to be equivalent.
When would I want to use --ignore-case? And how useful is it that it
does not obey the current locale, as in your implementation?
-- Hannes
^ permalink raw reply
* Re: [PATCH] git-latexdiff: new command in contrib, to use latexdiff and Git
From: Matthieu Moy @ 2012-02-20 8:50 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Junio C Hamano, Tim Haga, git
In-Reply-To: <m34nups3q2.fsf@localhost.localdomain>
Jakub Narebski <jnareb@gmail.com> writes:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> Aren't there LaTeX tools archives that would be a much better home for
>> this tool?
>
> There is CTAN: Comprehensive TeX Archive Network (http://ctan.org),
> which hosts tools such like latexmk (cousin of the general make
> utility), autolatex (generates Makefile), chktex, ite (interactive TeX
> editor),... latexdiff itself is also there.
It's not really the same thing: AFAIK, ctan is a good place to
distribute things, but not to develop them (i.e. I don't see revision
control or developpers mailing-lists there, which were the two
motivations for pushing git-latexdiff in git.git).
Anyway, since no one spoke up to defend my position, I'll have to find
another place to host it.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [PATCH 0/5] diff --ignore-case
From: Junio C Hamano @ 2012-02-20 8:52 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <4F420749.9010206@kdbg.org>
Johannes Sixt <j6t@kdbg.org> writes:
> Am 20.02.2012 03:16, schrieb Junio C Hamano:
>> This teaches our "diff" machinery to optionally consider lines that are
>> different only in upper/lower-cases to be equivalent.
>
> When would I want to use --ignore-case?
I wouldn't myself; it was just I saw somebody asked if -G can be used to
do case insensitive and then I realized we do not even support such in the
diff machinery to begin with, but now this opens a way to do so by copying
the xdl options when the pickaxe-grep codepath runs a subdiff.
You can update the hash and recmatch to be locale-aware, which would be an
internal update to xdiff/ directory that is independent of the rest of the
series, and/or the change to plug the machinery to -G.
^ permalink raw reply
* Re: [PATCH] git-latexdiff: new command in contrib, to use latexdiff and Git
From: Junio C Hamano @ 2012-02-20 9:05 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Jakub Narebski, Tim Haga, git
In-Reply-To: <vpqy5rxsxb3.fsf@bauges.imag.fr>
Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> There is CTAN: Comprehensive TeX Archive Network (http://ctan.org),
>> which hosts tools such like latexmk (cousin of the general make
>> utility), autolatex (generates Makefile), chktex, ite (interactive TeX
>> editor),... latexdiff itself is also there.
>
> It's not really the same thing: AFAIK, ctan is a good place to
> distribute things, but not to develop them (i.e. I don't see revision
> control or developpers mailing-lists there, which were the two
> motivations for pushing git-latexdiff in git.git).
Oh, don't get me wrong.
It's just that I agree with Jakub that a better final destination for it
is CTAN next to latexdiff, not in git.git/contrib/, and when we last did
something similar for emacs vc mode support, the copy I carried ended up
becoming way stale than its final destination, and we had to remove our
copy in order to reduce confusion. I just do not want to make the same
mistake here.
I didn't intend to discourage discusson of your application here.
Carry on the discussion in a forum where you think the most people with
appropriate skills and interests hang out, and if that forum is this list,
that is perfectly fine. Host a development repository at GitHub, Gitorious
or somesuch, if it would help people stay in sync with the current status
to have a public repository.
I just do not think my tree is a good place to use as a "while we are
developing" staging area.
^ permalink raw reply
* Re: Manually decoding a git object
From: Philip Oakley @ 2012-02-20 10:19 UTC (permalink / raw)
To: Thomas Rast; +Cc: Git List, 徐迪
In-Reply-To: <87mx8dj4at.fsf@thomas.inf.ethz.ch>
From: "Thomas Rast" <trast@inf.ethz.ch> Sent: Monday, February 20, 2012 8:29
AM
> "Philip Oakley" <philipoakley@iee.org> writes:
>
>> If I have a renamed file which is a git object, such a "Git_Object", was
>> 8c-something-or-other, what is the easiest way of examining / decoding /
>> recreating the original file (either as its sha1, or a cat-file).
>>
>> I don't appear to be able to unzip the file in its raw format... I'm
>> using
>> Msysgit on windows XP.
Correction to reply to xu's message: and I have /NOT/ located an
unzip programme that will take the plain git object and decode it.
>
> The SHA1 is over the decompressed object contents. The file simply
> holds a zlib-compressed stream of those contents. (It's pretty much
> like gzip without the file header.)
>
> You can use any bindings to zlib and something that does sha1, e.g. in
> python:
>
> $ cd g/.git/objects/aa/ # my git.git
> $ ls
> 592bda986a8380b64acd8cbb3d5bdfcbc0834d
> 6322a757bee31919f54edcc127608a3d724c99
> $ python
> Python 2.7.2 (default, Aug 19 2011, 20:41:43) [GCC] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import hashlib
> >>>
> hashlib.sha1(open('592bda986a8380b64acd8cbb3d5bdfcbc0834d').read().decode('zlib')).digest().encode('hex')
> 'aa592bda986a8380b64acd8cbb3d5bdfcbc0834d'
>
> Notice that the first byte of the hash goes into the directory name.
>
At the moment I'm in a Catch 22 situation where I can't make the first step
of examining the deflated contents, so I can't do all those next steps to
get the sha1 etc.. Have I misunderstood your suggestions?
Philip
^ permalink raw reply
* What's cooking in git.git (Feb 2012, #07; Mon, 20)
From: Junio C Hamano @ 2012-02-20 10:24 UTC (permalink / raw)
To: git; +Cc: Luke Diamand, Pete Wyckoff
Here are the topics that have been cooking. Commits prefixed with '-' are
only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'.
The first maintenance release v1.7.9.1 ironed out usability kinks in the
new features added in v1.7.9 release. Topics that add new features and
fixes that have been cooking in 'next' start to graduate to 'master'
again.
You can find the changes described here in the integration branches of the
repositories listed at
http://git-blame.blogspot.com/p/git-public-repositories.html
--------------------------------------------------
[Graduated to "master"]
* cb/maint-rev-list-verify-object (2012-02-13) 1 commit
(merged to 'next' on 2012-02-16 at a407b9a)
+ git rev-list: fix invalid typecast
Fixes an obscure bug in "rev-list --verify" that skipped verification
depending on the phase of the moon, which dates back to 1.7.8.x series.
* cb/maint-t5541-make-server-port-portable (2012-02-13) 1 commit
(merged to 'next' on 2012-02-16 at 762eefb)
+ t5541: check error message against the real port number used
Test fix.
* cb/receive-pack-keep-errors (2012-02-13) 1 commit
(merged to 'next' on 2012-02-16 at 9ff846e)
+ do not override receive-pack errors
Sometimes error status detected by a check in an earlier phase of
receive-pack (the other end of 'git push') was lost by later checks,
resulting in false indication of success.
* cb/transfer-no-progress (2012-02-13) 1 commit
(merged to 'next' on 2012-02-16 at ff17092)
+ push/fetch/clone --no-progress suppresses progress output
The transport programs ignored --no-progress and showed progress when
sending their output to a terminal.
* jc/diff-stat-scaler (2012-02-14) 1 commit
(merged to 'next' on 2012-02-16 at 404d336)
+ diff --stat: show bars of same length for paths with same amount of changes
The output from "git diff --stat" for two paths that have the same amount
of changes showed graph bars of different length due to the way we handled
rounding errors.
* tg/tag-points-at (2012-02-13) 2 commits
(merged to 'next' on 2012-02-13 at a8f4046)
+ builtin/tag.c: Fix a sparse warning
(merged to 'next' on 2012-02-10 at 4bff88f)
+ tag: add --points-at list option
* zj/decimal-width (2012-02-14) 1 commit
(merged to 'next' on 2012-02-16 at 72805c4)
+ make lineno_width() from blame reusable for others
(this branch is used by zj/diff-stat-dyncol.)
Refactoring.
* zj/term-columns (2012-02-13) 1 commit
(merged to 'next' on 2012-02-16 at fe70c88)
+ pager: find out the terminal width before spawning the pager
(this branch is used by zj/diff-stat-dyncol.)
Fixes "git -p cmd" for any subcommand that cares about the true terminal
width.
--------------------------------------------------
[New Topics]
* fc/push-prune (2012-02-17) 2 commits
- remote: reorganize check_pattern_match()
- remote: use a local variable in match_push_refs()
The first two of the three-patch RFC series. The second one and the third
one (not queued) both need better explanation, and the third one also had
a handful of minor yuck factors all of which should be straightforward to
improve.
Expecting a reroll.
* jc/add-refresh-unmerged (2012-02-17) 1 commit
- refresh_index: do not show unmerged path that is outside pathspec
"git add --refresh <pathspec>" warned about unmerged paths outside the
given pathspec.
* jc/diff-ignore-case (2012-02-19) 6 commits
- diff -i
- diff: --ignore-case
- xdiff: introduce XDF_IGNORE_CASE
- xdiff: introduce XDF_INEXACT_MATCH
- xdiff: PATIENCE/HISTOGRAM are not independent option bits
- xdiff: remove XDL_PATCH_* macros
"git diff" learned "--ignore-case" option.
* jn/gitweb-hilite-regions (2012-02-19) 5 commits
- gitweb: Use esc_html_match_hl() in 'grep' search
- gitweb: Highlight matched part of shortened project description
- gitweb: Highlight matched part of project description when searching projects
- gitweb: Highlight matched part of project name when searching projects
- gitweb: Introduce esc_html_hl_regions
(this branch uses jn/gitweb-search-optim.)
Not reviewed and do not know what this is about yet ;-).
* jn/gitweb-search-optim (2012-02-19) 3 commits
- gitweb: Faster project search
- gitweb: Option for filling only specified info in fill_project_list_info
- gitweb: Refactor checking if part of project info need filling
(this branch is used by jn/gitweb-hilite-regions.)
The API introduced in the second step still has yucky design, but at least
it is more clear than the previous rounds what this is trying to do.
* js/configure-libintl (2012-02-20) 1 commit
- configure: don't use -lintl when there is no gettext support
Build fix for autoconf, meant for 'maint' track.
* pj/remote-set-branches-usage-fix (2012-02-19) 1 commit
- remote: fix set-branches usage and documentation
Documentation fix.
--------------------------------------------------
[Stalled]
* jl/maint-submodule-relative (2012-02-09) 2 commits
- submodules: always use a relative path from gitdir to work tree
- submodules: always use a relative path to gitdir
The second one looked iffy.
* hv/submodule-recurse-push (2012-02-13) 3 commits
- push: teach --recurse-submodules the on-demand option
- Refactor submodule push check to use string list instead of integer
- Teach revision walking machinery to walk multiple times sequencially
The bottom one was not clearly explained and needs a reroll.
* zj/diff-stat-dyncol (2012-02-15) 6 commits
. diff --stat: use less columns for change counts
- (squash to the previous -- replace the last line of the log with the following)
- diff --stat: use the full terminal width
- (squash to the previous -- replace the log message with this)
- diff --stat: tests for long filenames and big change counts
- Merge branches zj/decimal-width and zj/term-columns
I am beginning to think that the last one should wait until the dust from
the earlier part settles.
* jc/advise-push-default (2011-12-18) 1 commit
- push: hint to use push.default=upstream when appropriate
Peff had a good suggestion outlining an updated code structure so that
somebody new can try to dip his or her toes in the development. Any
takers?
* ss/git-svn-prompt-sans-terminal (2012-01-04) 3 commits
- fixup! 15eaaf4
- git-svn, perl/Git.pm: extend Git::prompt helper for querying users
- perl/Git.pm: "prompt" helper to honor GIT_ASKPASS and SSH_ASKPASS
The bottom one has been replaced with a rewrite based on comments from
Ævar. The second one needs more work, both in perl/Git.pm and prompt.c, to
give precedence to tty over SSH_ASKPASS when terminal is available.
* jc/split-blob (2012-01-24) 6 commits
- chunked-object: streaming checkout
- chunked-object: fallback checkout codepaths
- bulk-checkin: support chunked-object encoding
- bulk-checkin: allow the same data to be multiply hashed
- new representation types in the packstream
- varint-in-pack: refactor varint encoding/decoding
Not ready.
I finished the streaming checkout codepath, but as explained in 127b177
(bulk-checkin: support chunked-object encoding, 2011-11-30), these are
still early steps of a long and painful journey. At least pack-objects and
fsck need to learn the new encoding for the series to be usable locally,
and then index-pack/unpack-objects needs to learn it to be used remotely.
Given that I heard a lot of noise that people want large files, and that I
was asked by somebody at GitTogether'11 privately for an advice on how to
pay developers (not me) to help adding necessary support, I am somewhat
dissapointed that the original patch series that was sent almost two
months ago still remains here without much comments and updates from the
developer community. I even made the interface to the logic that decides
where to split chunks easily replaceable, and I deliberately made the
logic in the original patch extremely stupid to entice others, especially
the "bup" fanboys, to come up with a better logic, thinking that giving
people an easy target to shoot for, they may be encouraged to help
out. The plan is not working :-(.
* nd/columns (2012-02-08) 15 commits
. column: Fix some compiler and sparse warnings
. column: add a corner-case test to t3200
. columns: minimum coding style fixes
. tag: add --column
. column: support piping stdout to external git-column process
. status: add --column
. branch: add --column
. help: reuse print_columns() for help -a
. column: add column.ui for default column output settings
. column: support columns with different widths
. column: add columnar layout
. Stop starting pager recursively
. Add git-column and column mode parsing
. column: add API to print items in columns
. Save terminal width before setting up pager
Expecting a reroll on top of zj/term-columns topic.
--------------------------------------------------
[Cooking]
* jk/diff-highlight (2012-02-13) 5 commits
(merged to 'next' on 2012-02-20 at ba040ae)
+ diff-highlight: document some non-optimal cases
+ diff-highlight: match multi-line hunks
+ diff-highlight: refactor to prepare for multi-line hunks
+ diff-highlight: don't highlight whole lines
+ diff-highlight: make perl strict and warnings fatal
Updates diff-highlight (in contrib/).
* jn/gitweb-unborn-head (2012-02-17) 1 commit
(merged to 'next' on 2012-02-20 at 80e3ff2)
+ gitweb: Fix "heads" view when there is no current branch
"gitweb" compared non-existent value of HEAD with the names of commit
objects at tips of branches, triggering runtime warnings.
* tr/perftest (2012-02-17) 3 commits
(merged to 'next' on 2012-02-20 at 4c75ba9)
+ Add a performance test for git-grep
+ Introduce a performance testing framework
+ Move the user-facing test library to test-lib-functions.sh
* jb/required-filter (2012-02-17) 1 commit
. Add a setting to require a filter to be successful
A content filter used to be a way to make the recorded contents "more
useful", but this defines a way to optionally mark a filter "required".
A few test in t0021 use 'false' as the filter, which can exit without
reading any byte from us, before we start writing and causes us to die
with SIGPIPE, leading to intermittent test failure. I think treating this
as a failure of running the filter (the end user's filter should read what
is fed in full, produce its output and write the result back to us) is the
right thing to do, so this patch needs update the surrounding code to
handle such a situation better, probably by using sigchain_push(SIGPIPE)
or something.
* jk/config-include (2012-02-17) 10 commits
(merged to 'next' on 2012-02-20 at 7b150b7)
+ config: add include directive
+ config: eliminate config_exclusive_filename
+ config: stop using config_exclusive_filename
+ config: provide a version of git_config with more options
+ config: teach git_config_rename_section a file argument
+ config: teach git_config_set_multivar_in_file a default path
+ config: copy the return value of prefix_filename
+ t1300: add missing &&-chaining
+ docs/api-config: minor clarifications
+ docs: add a basic description of the config API
An assignment to the include.path pseudo-variable causes the named file
to be included in-place when Git looks up configuration variables.
Reverted the earlier round from 'next' and then fixed up further.
* ld/git-p4-expanded-keywords (2012-02-14) 1 commit
(merged to 'next' on 2012-02-16 at a9004c5)
+ git-p4: add initial support for RCS keywords
Teach git-p4 to unexpand $RCS$-like keywords that are embedded in
tracked contents in order to reduce unnecessary merge conflicts.
Is this ready for 'master'?
^ 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