* Re: What's cooking in git.git (Oct 2016, #01; Mon, 3)
From: Junio C Hamano @ 2016-10-04 4:01 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20161004005247.sgeqgw3accn3whgi@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
>> * lt/abbrev-auto (2016-10-03) 3 commits
>
> I kind of expected this one to cook in next for a bit while people
> decided whether the larger hashes were irritating or not. Despite
> working on the implementation, I'm on the fence myself.
>
> I'd kind of hoped people would play with core.disambiguate and the hints
> and see if they still actually wanted to bump the default abbrev (and
> how aggressively to do so; if core.disambiguate means most of the
> ambiguity is just between commits, that cuts the number of
> collision-interesting objects by an order of magnitude).
Sure. Let's keep them cooking.
>> * jk/pack-objects-optim-mru (2016-08-11) 4 commits
>> (merged to 'next' on 2016-09-21 at 97b919bdbd)
>> + pack-objects: use mru list when iterating over packs
>> + pack-objects: break delta cycles before delta-search phase
>> + sha1_file: make packed_object_info public
>> + provide an initializer for "struct object_info"
>>
>> Originally merged to 'next' on 2016-08-11
>>
>> "git pack-objects" in a repository with many packfiles used to
>> spend a lot of time looking for/at objects in them; the accesses to
>> the packfiles are now optimized by checking the most-recently-used
>> packfile first.
>>
>> Will hold to see if people scream.
>
> This has been in next for 6 weeks. Is it time to consider graduating it?
Perhaps.
^ permalink raw reply
* Re: [PATCH 3/3] abbrev: auto size the default abbreviation
From: Junio C Hamano @ 2016-10-04 1:37 UTC (permalink / raw)
To: Jeff King; +Cc: Linus Torvalds, Git Mailing List
In-Reply-To: <20161003234728.s5sadekukxoppcmw@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
>> OK, as Linus's "count at the point of use" is already in 'next',
>> could you make it incremental with a log message?
>
> Sure. I wasn't sure if you actually liked my direction or not, so I was
> mostly just showing off what the completed one would look like.
To be quite honest, I am not just unsure if I liked your direction;
rather I am not sure if I actually understood what you perceived as
a difference that matters between the two approaches. I wanted to
hear you explain the difference in terms of "Linus's does this, but
it is bad in X and Y way, so let's avoid it and do it like Z
instead". One effective way to extract that out of you was to force
you to justify the "incremental" update.
And it seems that I succeeded ;-).
I am still not sure if I 100% agree with your first paragraph, but
at least now I think I see where you are coming from.
You probably will hear from Ramsay about extern-ness of msb().
> -- >8 --
> Subject: [PATCH] find_unique_abbrev: move logic out of get_short_sha1()
>
> The get_short_sha1() is only about reading short sha1s; we
> do call it in a loop to check "is this long enough" for each
> object, but otherwise it should not need to know about
> things like our default_abbrev setting.
>
> So instead of asking it to set default_automatic_abbrev as a
> side-effect, let's just have find_unique_abbrev() pick the
> right place to start its loop. This requires a separate
> approximate_object_count() function, but that naturally
> belongs with the rest of sha1_file.c.
>
> Signed-off-by: Jeff King <peff@peff.net>
> ---
> cache.h | 7 ++++++-
> sha1_file.c | 27 +++++++++++++++++++++++++++
> sha1_name.c | 60 +++++++++++++++++++++++++++++++++++-------------------------
> 3 files changed, 68 insertions(+), 26 deletions(-)
>
> diff --git a/cache.h b/cache.h
> index 0e2a059..f22ace5 100644
> --- a/cache.h
> +++ b/cache.h
> @@ -1204,7 +1204,6 @@ struct object_context {
> #define GET_SHA1_TREEISH 020
> #define GET_SHA1_BLOB 040
> #define GET_SHA1_FOLLOW_SYMLINKS 0100
> -#define GET_SHA1_AUTOMATIC 0200
> #define GET_SHA1_ONLY_TO_DIE 04000
>
> #define GET_SHA1_DISAMBIGUATORS \
> @@ -1456,6 +1455,12 @@ extern void prepare_packed_git(void);
> extern void reprepare_packed_git(void);
> extern void install_packed_git(struct packed_git *pack);
>
> +/*
> + * Give a rough count of objects in the repository. This sacrifices accuracy
> + * for speed.
> + */
> +unsigned long approximate_object_count(void);
> +
> extern struct packed_git *find_sha1_pack(const unsigned char *sha1,
> struct packed_git *packs);
>
> diff --git a/sha1_file.c b/sha1_file.c
> index b9c1fa3..4882440 100644
> --- a/sha1_file.c
> +++ b/sha1_file.c
> @@ -1381,6 +1381,32 @@ static void prepare_packed_git_one(char *objdir, int local)
> strbuf_release(&path);
> }
>
> +static int approximate_object_count_valid;
> +
> +/*
> + * Give a fast, rough count of the number of objects in the repository. This
> + * ignores loose objects completely. If you have a lot of them, then either
> + * you should repack because your performance will be awful, or they are
> + * all unreachable objects about to be pruned, in which case they're not really
> + * interesting as a measure of repo size in the first place.
> + */
> +unsigned long approximate_object_count(void)
> +{
> + static unsigned long count;
> + if (!approximate_object_count_valid) {
> + struct packed_git *p;
> +
> + prepare_packed_git();
> + count = 0;
> + for (p = packed_git; p; p = p->next) {
> + if (open_pack_index(p))
> + continue;
> + count += p->num_objects;
> + }
> + }
> + return count;
> +}
> +
> static void *get_next_packed_git(const void *p)
> {
> return ((const struct packed_git *)p)->next;
> @@ -1455,6 +1481,7 @@ void prepare_packed_git(void)
>
> void reprepare_packed_git(void)
> {
> + approximate_object_count_valid = 0;
> prepare_packed_git_run_once = 0;
> prepare_packed_git();
> }
> diff --git a/sha1_name.c b/sha1_name.c
> index beb7ab5..76e6885 100644
> --- a/sha1_name.c
> +++ b/sha1_name.c
> @@ -15,7 +15,6 @@ typedef int (*disambiguate_hint_fn)(const unsigned char *, void *);
>
> struct disambiguate_state {
> int len; /* length of prefix in hex chars */
> - unsigned int nrobjects;
> char hex_pfx[GIT_SHA1_HEXSZ + 1];
> unsigned char bin_pfx[GIT_SHA1_RAWSZ];
>
> @@ -119,14 +118,6 @@ static void find_short_object_filename(struct disambiguate_state *ds)
>
> if (strlen(de->d_name) != 38)
> continue;
> -
> - /*
> - * We only look at the one subdirectory, and we assume
> - * each subdirectory is roughly similar, so each
> - * object we find probably has 255 other objects in
> - * the other fan-out directories.
> - */
> - ds->nrobjects += 256;
> if (memcmp(de->d_name, ds->hex_pfx + 2, ds->len - 2))
> continue;
> memcpy(hex + 2, de->d_name, 38);
> @@ -160,7 +151,6 @@ static void unique_in_pack(struct packed_git *p,
>
> open_pack_index(p);
> num = p->num_objects;
> - ds->nrobjects += num;
> last = num;
> while (first < last) {
> uint32_t mid = (first + last) / 2;
> @@ -390,9 +380,6 @@ static int show_ambiguous_object(const unsigned char *sha1, void *data)
> return 0;
> }
>
> -/* start from our historical default before the automatic abbreviation */
> -static int default_automatic_abbrev = FALLBACK_DEFAULT_ABBREV;
> -
> static int get_short_sha1(const char *name, int len, unsigned char *sha1,
> unsigned flags)
> {
> @@ -439,14 +426,6 @@ static int get_short_sha1(const char *name, int len, unsigned char *sha1,
> for_each_abbrev(ds.hex_pfx, show_ambiguous_object, &ds);
> }
>
> - if (len < 16 && !status && (flags & GET_SHA1_AUTOMATIC)) {
> - unsigned int expect_collision = 1 << (len * 2);
> - if (ds.nrobjects > expect_collision) {
> - default_automatic_abbrev = len+1;
> - return SHORT_NAME_AMBIGUOUS;
> - }
> - }
> -
> return status;
> }
>
> @@ -476,22 +455,53 @@ int for_each_abbrev(const char *prefix, each_abbrev_fn fn, void *cb_data)
> return ret;
> }
>
> +/*
> + * Return the slot of the most-significant bit set in "val". There are various
> + * ways to do this quickly with fls() or __builtin_clzl(), but speed is
> + * probably not a big deal here.
> + */
> +unsigned msb(unsigned long val)
> +{
> + unsigned r = 0;
> + while (val >>= 1)
> + r++;
> + return r;
> +}
> +
> int find_unique_abbrev_r(char *hex, const unsigned char *sha1, int len)
> {
> int status, exists;
> - int flags = GET_SHA1_QUIETLY;
>
> if (len < 0) {
> - flags |= GET_SHA1_AUTOMATIC;
> - len = default_automatic_abbrev;
> + unsigned long count = approximate_object_count();
> + /*
> + * Add one because the MSB only tells us the highest bit set,
> + * not including the value of all the _other_ bits (so "15"
> + * is only one off of 2^4, but the MSB is the 3rd bit.
> + */
> + len = msb(count) + 1;
> + /*
> + * We now know we have on the order of 2^len objects, which
> + * expects a collision at 2^(len/2). But we also care about hex
> + * chars, not bits, and there are 4 bits per hex. So all
> + * together we need to divide by 2; but we also want to round
> + * odd numbers up, hence adding one before dividing.
> + */
> + len = (len + 1) / 2;
> + /*
> + * For very small repos, we stick with our regular fallback.
> + */
> + if (len < FALLBACK_DEFAULT_ABBREV)
> + len = FALLBACK_DEFAULT_ABBREV;
> }
> +
> sha1_to_hex_r(hex, sha1);
> if (len == 40 || !len)
> return 40;
> exists = has_sha1_file(sha1);
> while (len < 40) {
> unsigned char sha1_ret[20];
> - status = get_short_sha1(hex, len, sha1_ret, flags);
> + status = get_short_sha1(hex, len, sha1_ret, GET_SHA1_QUIETLY);
> if (exists
> ? !status
> : status == SHORT_NAME_NOT_FOUND) {
^ permalink raw reply
* Re: [PATCH v2 6/6] git-gui: Update Japanese information
From: Junio C Hamano @ 2016-10-04 1:20 UTC (permalink / raw)
To: Pat Thoyts; +Cc: git
In-Reply-To: <87mvilt4jg.fsf@red.patthoyts.tk>
Pat Thoyts <patthoyts@users.sourceforge.net> writes:
> I've tried to merge in these branches as they appear in your version
> although I already had one patch on top of 0.20.0 for some time. I've
> tentatively pushed this up to http://github.com/patthoyts/git-gui as
> branch 'pu' with additional stuff on top of the patches you already
> have. If this looks ok to you I'll merge this to my master and send you
> a merge request to get it all synchronized.
Your 64c6b4c507 matches what I expected to see as the result of
merging the above four topics on top of your 'master'. I have no
opinion on the other topics that appear on top of it on the branch
you pushed out, other than that I trust the maintainer of the
subsystem and I'm fine to blindly pull them from you ;-)
I am not sure if f64a1a9311 ("git-gui: maintain backwards
compatibility for merge syntax", 2016-10-04) makes any practical
difference in the real world, though. You'd need to find somebody
who grabs the newer version of git-gui that includes b5f325cb4a
("git-gui: stop using deprecated merge syntax", 2016-09-24), without
having updated their copy of git-core for more than a year, given
that 2.5.0 is from July last year. It would not hurt, but I am not
sure if an extra invocation of "git version" is really worth it.
Thanks.
^ permalink raw reply
* Re: What's cooking in git.git (Oct 2016, #01; Mon, 3)
From: Jeff King @ 2016-10-04 0:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <xmqqtwct3w0p.fsf@gitster.mtv.corp.google.com>
On Mon, Oct 03, 2016 at 03:31:02PM -0700, Junio C Hamano wrote:
> * lt/abbrev-auto (2016-10-03) 3 commits
> (merged to 'next' on 2016-10-03 at bb188d00f7)
> + abbrev: auto size the default abbreviation
> + abbrev: prepare for new world order
> + abbrev: add FALLBACK_DEFAULT_ABBREV to prepare for auto sizing
> (this branch uses jk/ambiguous-short-object-names.)
>
> Allow the default abbreviation length, which has historically been
> 7, to scale as the repository grows. The logic suggests to use 12
> hexdigits for the Linux kernel, and 9 to 10 for Git itself.
>
> Will merge to 'master'.
I kind of expected this one to cook in next for a bit while people
decided whether the larger hashes were irritating or not. Despite
working on the implementation, I'm on the fence myself.
I'd kind of hoped people would play with core.disambiguate and the hints
and see if they still actually wanted to bump the default abbrev (and
how aggressively to do so; if core.disambiguate means most of the
ambiguity is just between commits, that cuts the number of
collision-interesting objects by an order of magnitude).
> * jk/pack-objects-optim-mru (2016-08-11) 4 commits
> (merged to 'next' on 2016-09-21 at 97b919bdbd)
> + pack-objects: use mru list when iterating over packs
> + pack-objects: break delta cycles before delta-search phase
> + sha1_file: make packed_object_info public
> + provide an initializer for "struct object_info"
>
> Originally merged to 'next' on 2016-08-11
>
> "git pack-objects" in a repository with many packfiles used to
> spend a lot of time looking for/at objects in them; the accesses to
> the packfiles are now optimized by checking the most-recently-used
> packfile first.
>
> Will hold to see if people scream.
This has been in next for 6 weeks. Is it time to consider graduating it?
-Peff
^ permalink raw reply
* Re: [RFC/PATCH 0/2] place cherry pick line below commit title
From: Jonathan Tan @ 2016-10-04 0:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Christian Couder
In-Reply-To: <xmqq8tu55bel.fsf@gitster.mtv.corp.google.com>
On 10/03/2016 03:13 PM, Junio C Hamano wrote:
> Jonathan Tan <jonathantanmy@google.com> writes:
>
>> There are other options like checking for indentation or checking for
>> balanced parentheses/brackets, but I think that these would lead to
>> surprising behavior for the user (this would mean that whitespace or
>> certain characters could turn a valid trailer into an invalid one or
>> vice versa, or change the behavior of trailer.ifexists, especially
>> "replace").
>
> Yes, that is exactly why I said that it may be necessary for the
> code to analize the lines in a block identified as "likely to be a
> trailing block" more carefully. We can afford to be loose as long
> as the only allowed operation is to append one at the end, but once
> we start removing/replacing an existing entry, etc., the definition
> of what an entry is becomes very much relevant.
I agree, and I was trying to discuss the possible alternatives for the
definition of what an entry is in my previous e-mail.
If you think that the alternatives are still too loose, I'm not sure if
we can make it any tighter. As far as I know, we're dealing with
trailers like the following:
Signed-off-by: A <author@example.com>
[This has nothing to do with the above line]
Signed-off-by: B <buthor@example.com>
and:
Link 1: a link
a continuation of the above
and:
Signed-off-by: Some body <some@body.xz> (comment
on two lines)
As I stated in the quoted paragraph, one possibility is to use
indentation and/or balanced parentheses/brackets to determine if a
trailer line continues onto the next line, and this would handle all the
above cases, but I still think that these would lead to surprising
behavior. Hence my suggestion to just simply define it as a single
physical line. But if you think that the pros (of the more complicated
approach) outweigh the cons, I'm OK with that.
One alternative is to postpone this decision by changing sequencer only
(and not trailer) to tolerate other lines in the trailer. This would
make them even more divergent (sequencer supports arbitrary lines while
trailer doesn't), but they were divergent already (sequencer supports
"(cherry picked by" but trailer doesn't).
^ permalink raw reply
* Re: [PATCH] http: http.emptyauth should allow empty (not just NULL) usernames
From: brian m. carlson @ 2016-10-04 0:07 UTC (permalink / raw)
To: David Turner; +Cc: 'Jeff King', git@vger.kernel.org
In-Reply-To: <335996ca2642478386e94d9f3dc43223@exmbdft7.ad.twosigma.com>
[-- Attachment #1: Type: text/plain, Size: 1555 bytes --]
On Mon, Oct 03, 2016 at 09:54:19PM +0000, David Turner wrote:
>
> > I dunno. The code path you are changing _only_ affects anything if the
> > http.emptyauth config is set. But I guess I just don't understand why you
> > would say "http://@gitserver" in the first place. Is that a common thing?
> >
> > -Peff
>
> I have no idea if it is common. I know that we do it.
I've never seen this. RFC 3986 does seem to allow it:
authority = [ userinfo "@" ] host [ ":" port ]
userinfo = *( unreserved / pct-encoded / sub-delims / ":" )
I normally write it like one of these:
https://bmc@git.crustytoothpaste.net/
https://:@git.crustytoothpaste.net/
Of course, the username is ignored in the first one, but it serves a
documentary purpose for me.
> The reason we have a required-to-be-blank username/password is
> apparently Kerberos (or something about our particular Kerberos
> configuration), which I treat as inscrutable black magic.
The issue with git is usually that it uses libcurl, which won't do
authentication unless it has a username or password, even if those are
empty or ignored. http.emptyAuth was designed for this case.
With Kerberos (at least in my experience), the username doesn't actually
get sent, since you send only ticket-related information over the
channel, and that has your principal name embedded.
--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | https://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: https://keybase.io/bk2204
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 3/3] abbrev: auto size the default abbreviation
From: Jeff King @ 2016-10-03 23:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, Git Mailing List
In-Reply-To: <xmqqoa313v0j.fsf@gitster.mtv.corp.google.com>
On Mon, Oct 03, 2016 at 03:52:44PM -0700, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > On Mon, Oct 03, 2016 at 03:34:03PM -0700, Linus Torvalds wrote:
> >
> >> On Mon, Oct 3, 2016 at 3:27 PM, Jeff King <peff@peff.net> wrote:
> >> >
> >> > + if (len < 0) {
> >> > + unsigned long count = approximate_object_count();
> >> > + len = (msb(count) + 1) / 2;
> >> > + if (len < 0)
> >> > + len = FALLBACK_DEFAULT_ABBREV;
> >> > + }
> >>
> >> that second "if (len < 0)" should probably be testing against
> >> FALLBACK_DEFAULT_ABBREV, not zero. Or at the very least
> >> MINIMUM_ABBREV. Because a two-character abbreviation won't even be
> >> recognized, even if the git project is very small indeed.
> >
> > Oops, yes, clearly it should be FALLBACK_DEFAULT_ABBREV. What is there
> > would not even pass the tests (it _does_ work on linux.git, of course,
> > because it is much too large for that code to be triggered).
>
> OK, as Linus's "count at the point of use" is already in 'next',
> could you make it incremental with a log message?
Sure. I wasn't sure if you actually liked my direction or not, so I was
mostly just showing off what the completed one would look like.
Here it is as an incremental on top of lt/abbrev-auto. I also tweaked
the math a bit to round-up more aggressively, and commented it more (I
could also just make the math look exactly like Linus's, counting up
until hitting an expected collision. I dunno if that is more clear).
-- >8 --
Subject: [PATCH] find_unique_abbrev: move logic out of get_short_sha1()
The get_short_sha1() is only about reading short sha1s; we
do call it in a loop to check "is this long enough" for each
object, but otherwise it should not need to know about
things like our default_abbrev setting.
So instead of asking it to set default_automatic_abbrev as a
side-effect, let's just have find_unique_abbrev() pick the
right place to start its loop. This requires a separate
approximate_object_count() function, but that naturally
belongs with the rest of sha1_file.c.
Signed-off-by: Jeff King <peff@peff.net>
---
cache.h | 7 ++++++-
sha1_file.c | 27 +++++++++++++++++++++++++++
sha1_name.c | 60 +++++++++++++++++++++++++++++++++++-------------------------
3 files changed, 68 insertions(+), 26 deletions(-)
diff --git a/cache.h b/cache.h
index 0e2a059..f22ace5 100644
--- a/cache.h
+++ b/cache.h
@@ -1204,7 +1204,6 @@ struct object_context {
#define GET_SHA1_TREEISH 020
#define GET_SHA1_BLOB 040
#define GET_SHA1_FOLLOW_SYMLINKS 0100
-#define GET_SHA1_AUTOMATIC 0200
#define GET_SHA1_ONLY_TO_DIE 04000
#define GET_SHA1_DISAMBIGUATORS \
@@ -1456,6 +1455,12 @@ extern void prepare_packed_git(void);
extern void reprepare_packed_git(void);
extern void install_packed_git(struct packed_git *pack);
+/*
+ * Give a rough count of objects in the repository. This sacrifices accuracy
+ * for speed.
+ */
+unsigned long approximate_object_count(void);
+
extern struct packed_git *find_sha1_pack(const unsigned char *sha1,
struct packed_git *packs);
diff --git a/sha1_file.c b/sha1_file.c
index b9c1fa3..4882440 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -1381,6 +1381,32 @@ static void prepare_packed_git_one(char *objdir, int local)
strbuf_release(&path);
}
+static int approximate_object_count_valid;
+
+/*
+ * Give a fast, rough count of the number of objects in the repository. This
+ * ignores loose objects completely. If you have a lot of them, then either
+ * you should repack because your performance will be awful, or they are
+ * all unreachable objects about to be pruned, in which case they're not really
+ * interesting as a measure of repo size in the first place.
+ */
+unsigned long approximate_object_count(void)
+{
+ static unsigned long count;
+ if (!approximate_object_count_valid) {
+ struct packed_git *p;
+
+ prepare_packed_git();
+ count = 0;
+ for (p = packed_git; p; p = p->next) {
+ if (open_pack_index(p))
+ continue;
+ count += p->num_objects;
+ }
+ }
+ return count;
+}
+
static void *get_next_packed_git(const void *p)
{
return ((const struct packed_git *)p)->next;
@@ -1455,6 +1481,7 @@ void prepare_packed_git(void)
void reprepare_packed_git(void)
{
+ approximate_object_count_valid = 0;
prepare_packed_git_run_once = 0;
prepare_packed_git();
}
diff --git a/sha1_name.c b/sha1_name.c
index beb7ab5..76e6885 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -15,7 +15,6 @@ typedef int (*disambiguate_hint_fn)(const unsigned char *, void *);
struct disambiguate_state {
int len; /* length of prefix in hex chars */
- unsigned int nrobjects;
char hex_pfx[GIT_SHA1_HEXSZ + 1];
unsigned char bin_pfx[GIT_SHA1_RAWSZ];
@@ -119,14 +118,6 @@ static void find_short_object_filename(struct disambiguate_state *ds)
if (strlen(de->d_name) != 38)
continue;
-
- /*
- * We only look at the one subdirectory, and we assume
- * each subdirectory is roughly similar, so each
- * object we find probably has 255 other objects in
- * the other fan-out directories.
- */
- ds->nrobjects += 256;
if (memcmp(de->d_name, ds->hex_pfx + 2, ds->len - 2))
continue;
memcpy(hex + 2, de->d_name, 38);
@@ -160,7 +151,6 @@ static void unique_in_pack(struct packed_git *p,
open_pack_index(p);
num = p->num_objects;
- ds->nrobjects += num;
last = num;
while (first < last) {
uint32_t mid = (first + last) / 2;
@@ -390,9 +380,6 @@ static int show_ambiguous_object(const unsigned char *sha1, void *data)
return 0;
}
-/* start from our historical default before the automatic abbreviation */
-static int default_automatic_abbrev = FALLBACK_DEFAULT_ABBREV;
-
static int get_short_sha1(const char *name, int len, unsigned char *sha1,
unsigned flags)
{
@@ -439,14 +426,6 @@ static int get_short_sha1(const char *name, int len, unsigned char *sha1,
for_each_abbrev(ds.hex_pfx, show_ambiguous_object, &ds);
}
- if (len < 16 && !status && (flags & GET_SHA1_AUTOMATIC)) {
- unsigned int expect_collision = 1 << (len * 2);
- if (ds.nrobjects > expect_collision) {
- default_automatic_abbrev = len+1;
- return SHORT_NAME_AMBIGUOUS;
- }
- }
-
return status;
}
@@ -476,22 +455,53 @@ int for_each_abbrev(const char *prefix, each_abbrev_fn fn, void *cb_data)
return ret;
}
+/*
+ * Return the slot of the most-significant bit set in "val". There are various
+ * ways to do this quickly with fls() or __builtin_clzl(), but speed is
+ * probably not a big deal here.
+ */
+unsigned msb(unsigned long val)
+{
+ unsigned r = 0;
+ while (val >>= 1)
+ r++;
+ return r;
+}
+
int find_unique_abbrev_r(char *hex, const unsigned char *sha1, int len)
{
int status, exists;
- int flags = GET_SHA1_QUIETLY;
if (len < 0) {
- flags |= GET_SHA1_AUTOMATIC;
- len = default_automatic_abbrev;
+ unsigned long count = approximate_object_count();
+ /*
+ * Add one because the MSB only tells us the highest bit set,
+ * not including the value of all the _other_ bits (so "15"
+ * is only one off of 2^4, but the MSB is the 3rd bit.
+ */
+ len = msb(count) + 1;
+ /*
+ * We now know we have on the order of 2^len objects, which
+ * expects a collision at 2^(len/2). But we also care about hex
+ * chars, not bits, and there are 4 bits per hex. So all
+ * together we need to divide by 2; but we also want to round
+ * odd numbers up, hence adding one before dividing.
+ */
+ len = (len + 1) / 2;
+ /*
+ * For very small repos, we stick with our regular fallback.
+ */
+ if (len < FALLBACK_DEFAULT_ABBREV)
+ len = FALLBACK_DEFAULT_ABBREV;
}
+
sha1_to_hex_r(hex, sha1);
if (len == 40 || !len)
return 40;
exists = has_sha1_file(sha1);
while (len < 40) {
unsigned char sha1_ret[20];
- status = get_short_sha1(hex, len, sha1_ret, flags);
+ status = get_short_sha1(hex, len, sha1_ret, GET_SHA1_QUIETLY);
if (exists
? !status
: status == SHORT_NAME_NOT_FOUND) {
--
2.10.0.618.g82cc264
^ permalink raw reply related
* Re: [PATCH] git-gui: stop using deprecated merge syntax
From: Pat Thoyts @ 2016-10-03 23:15 UTC (permalink / raw)
To: René Scharfe
Cc: Stefan Beller, Junio C Hamano, Johannes Sixt, Git List,
Dennis Kaarsemaker
In-Reply-To: <5283506a-9399-6ddc-d714-1dd9d2b49704@web.de>
René Scharfe <l.s.r@web.de> writes:
>Am 03.10.2016 um 10:30 schrieb Pat Thoyts:
>> The only problem I see here is that generally git-gui tries to continue
>> to work with older versions of git as well. So adding a guard using the
>> git-version procedure should maintain that backwards compatibility.
>
>Makes sense for a stand-alone tool.
>
>> I suggest:
>>
>> From c2716458f05893ca88c05ce211a295a330e74590 Mon Sep 17 00:00:00 2001
>> From: René Scharfe <l.s.r@web.de>
>> Date: Sat, 24 Sep 2016 13:30:22 +0200
>> Subject: [PATCH] git-gui: stop using deprecated merge syntax
>>
>> Starting with v2.5.0 git merge can handle FETCH_HEAD internally and
>> warns when it's called like 'git merge <message> HEAD <commit>' because
>> that syntax is deprecated. Use this feature in git-gui and get rid of
>> that warning.
>>
>> Tested-by: Johannes Sixt <j6t@kdbg.org>
>> Reviewed-by: Stefan Beller <sbeller@google.com>
>> Signed-off-by: Rene Scharfe <l.s.r@web.de>
>> Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
>
>OK, but perhaps move me from From: to Original-patch-by: as the
>version check is a big enough change in itself. Or add a separate
>commit for it. Or at least mention that you added the check in the
>commit message.
>
>Thanks,
>René
As this is one of the ones already staged to git's 'next' I'll make this
as a separate commit on top.
--
Pat Thoyts http://www.patthoyts.tk/
PGP fingerprint 2C 6E 98 07 2C 59 C8 97 10 CE 11 E6 04 E0 B9 DD
^ permalink raw reply
* Re: [PATCH v2 6/6] git-gui: Update Japanese information
From: Pat Thoyts @ 2016-10-03 23:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <xmqq7f9p6xh8.fsf@gitster.mtv.corp.google.com>
Junio C Hamano <gitster@pobox.com> writes:
>Junio C Hamano <gitster@pobox.com> writes:
>
>> Pat Thoyts <patthoyts@users.sourceforge.net> writes:
>>
>>> I'm just starting to catch up once again. hopefully I can be
>>> a bit more reactive than recently. Merging 52285c83 looks fine. I'll
>>> stick that onto the 0.20.0 head and see what else I can pick up on top.
>>> There are a few from the git for windows set among others.
>>
>> Nice to hear from you again. I think I have a few topics I merged
>> to my tree bypassing you in the meantime. Let me get back to you
>> with a list of topic tips to bring your tree in sync with what I
>> have later.
>
>I think the following lists everything that has been done bypassing
>your tree:
>
>66fe3e061a ("git-gui: l10n: add Portuguese translation", 2016-05-06)
>52285c8312 ("git-gui: update Japanese information", 2016-09-07)
>2afe6b733e ("git-gui: respect commit.gpgsign again", 2016-09-09)
>b5f325cb4a ("git-gui: stop using deprecated merge syntax", 2016-09-24)
>
>52285c8312 and 2afe6b733e are already in my 'master'; the other two
>are already cooking in 'next'.
>
>So if you fetch from me and merge the above, you'd be in sync with
>me (I won't be in sync with you, as you would have more than I have
>from other places like Git for Windows set).
>
>Thanks.
>
I've tried to merge in these branches as they appear in your version
although I already had one patch on top of 0.20.0 for some time. I've
tentatively pushed this up to http://github.com/patthoyts/git-gui as
branch 'pu' with additional stuff on top of the patches you already
have. If this looks ok to you I'll merge this to my master and send you
a merge request to get it all synchronized.
--
Pat Thoyts http://www.patthoyts.tk/
^ permalink raw reply
* Re: [PATCH] http: http.emptyauth should allow empty (not just NULL) usernames
From: Junio C Hamano @ 2016-10-03 22:54 UTC (permalink / raw)
To: David Turner
Cc: 'Jeff King', git@vger.kernel.org,
sandals@crustytoothpaste.net
In-Reply-To: <b7e31e9b13494f94b5bd6fff5fc55af0@exmbdft7.ad.twosigma.com>
David Turner <David.Turner@twosigma.com> writes:
>> > > I dunno. The code path you are changing _only_ affects anything if
>> > > the http.emptyauth config is set. But I guess I just don't
>> > > understand why you would say "http://@gitserver" in the first place.
>> Is that a common thing?
>> >
>> > I have no idea if it is common. I know that we do it.
>>
>> I guess my question is: _why_ do you do it? Or more specifically, does
>> http://gitserver.example.com" with http.emptyauth not work, and why?
>>
>> From your response, I _think_ the answer is "no, it doesn't, and I have no
>> clue why".
>
> That was true historically.
>
> I just tried our old version of git 2.8 (that is, before this patch, and before the libcurl upgrade), and http://gitserver.example.com *does* seem to work with http.emptyauth (and does not work without). However, http://@gitserver.example.com does *not* work with http.emptyauth, and *does* work without.
>
> After the libcurl upgrade, but before this patch, http://@gitserver.example.com does *not* work with http.emptyauth, while http://gitserver.example.com does.
>
> And finally, after the upgrade and with this patch, both urls work.
>
>> So I dunno. It is annoying not to know what is actually going on, but I'm
>> OK with it if we don't think there's a high chance of regressing any other
>> workflows (which I guess not, because http.emptyauth seems to be a
>> Kerberos-specific hack in the first place).
>
> Yes, I think this is all Kerberos-only.
Now, perhaps with these back-and-forth, hopefully you have enough
material to update the proposed log message to clarify so that next
Peff won't have to ask "would it be common? why would you do so?"
Thanks.
^ permalink raw reply
* Re: [PATCH 3/3] abbrev: auto size the default abbreviation
From: Junio C Hamano @ 2016-10-03 22:52 UTC (permalink / raw)
To: Jeff King; +Cc: Linus Torvalds, Git Mailing List
In-Reply-To: <20161003224028.ksvwaplxe7a3vtwv@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Mon, Oct 03, 2016 at 03:34:03PM -0700, Linus Torvalds wrote:
>
>> On Mon, Oct 3, 2016 at 3:27 PM, Jeff King <peff@peff.net> wrote:
>> >
>> > + if (len < 0) {
>> > + unsigned long count = approximate_object_count();
>> > + len = (msb(count) + 1) / 2;
>> > + if (len < 0)
>> > + len = FALLBACK_DEFAULT_ABBREV;
>> > + }
>>
>> that second "if (len < 0)" should probably be testing against
>> FALLBACK_DEFAULT_ABBREV, not zero. Or at the very least
>> MINIMUM_ABBREV. Because a two-character abbreviation won't even be
>> recognized, even if the git project is very small indeed.
>
> Oops, yes, clearly it should be FALLBACK_DEFAULT_ABBREV. What is there
> would not even pass the tests (it _does_ work on linux.git, of course,
> because it is much too large for that code to be triggered).
OK, as Linus's "count at the point of use" is already in 'next',
could you make it incremental with a log message?
Thanks.
^ permalink raw reply
* Re: [PATCH 3/3] abbrev: auto size the default abbreviation
From: Jeff King @ 2016-10-03 22:40 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <CA+55aFydV+9c3-5C03XUj7v_wGJF5NyJNaP6742zLVgZs410FA@mail.gmail.com>
On Mon, Oct 03, 2016 at 03:34:03PM -0700, Linus Torvalds wrote:
> On Mon, Oct 3, 2016 at 3:27 PM, Jeff King <peff@peff.net> wrote:
> >
> > + if (len < 0) {
> > + unsigned long count = approximate_object_count();
> > + len = (msb(count) + 1) / 2;
> > + if (len < 0)
> > + len = FALLBACK_DEFAULT_ABBREV;
> > + }
>
> that second "if (len < 0)" should probably be testing against
> FALLBACK_DEFAULT_ABBREV, not zero. Or at the very least
> MINIMUM_ABBREV. Because a two-character abbreviation won't even be
> recognized, even if the git project is very small indeed.
Oops, yes, clearly it should be FALLBACK_DEFAULT_ABBREV. What is there
would not even pass the tests (it _does_ work on linux.git, of course,
because it is much too large for that code to be triggered).
-Peff
^ permalink raw reply
* Re: [PATCH 3/3] abbrev: auto size the default abbreviation
From: Linus Torvalds @ 2016-10-03 22:34 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <20161003222701.za5njew33rqc5b6g@sigill.intra.peff.net>
On Mon, Oct 3, 2016 at 3:27 PM, Jeff King <peff@peff.net> wrote:
>
> + if (len < 0) {
> + unsigned long count = approximate_object_count();
> + len = (msb(count) + 1) / 2;
> + if (len < 0)
> + len = FALLBACK_DEFAULT_ABBREV;
> + }
that second "if (len < 0)" should probably be testing against
FALLBACK_DEFAULT_ABBREV, not zero. Or at the very least
MINIMUM_ABBREV. Because a two-character abbreviation won't even be
recognized, even if the git project is very small indeed.
Linus
^ permalink raw reply
* A note from the maintainer
From: Junio C Hamano @ 2016-10-03 22:31 UTC (permalink / raw)
To: git
Welcome to the Git development community.
This message is written by the maintainer and talks about how Git
project is managed, and how you can work with it.
* Mailing list and the community
The development is primarily done on the Git mailing list. Help
requests, feature proposals, bug reports and patches should be sent to
the list address <git@vger.kernel.org>. You don't have to be
subscribed to send messages. The convention on the list is to keep
everybody involved on Cc:, so it is unnecessary to say "Please Cc: me,
I am not subscribed".
Before sending patches, please read Documentation/SubmittingPatches
and Documentation/CodingGuidelines to familiarize yourself with the
project convention.
If you sent a patch and you did not hear any response from anybody for
several days, it could be that your patch was totally uninteresting,
but it also is possible that it was simply lost in the noise. Please
do not hesitate to send a reminder message in such a case. Messages
getting lost in the noise may be a sign that those who can evaluate
your patch don't have enough mental/time bandwidth to process them
right at the moment, and it often helps to wait until the list traffic
becomes calmer before sending such a reminder.
The list archive is available at a few public sites:
http://public-inbox.org/git/
http://marc.info/?l=git
http://www.spinics.net/lists/git/
For those who prefer to read it over NNTP:
nntp://news.public-inbox.org/inbox.comp.version-control.git
nntp://news.gmane.org/gmane.comp.version-control.git
are available.
When you point at a message in a mailing list archive, using its
message ID is often the most robust (if not very friendly) way to do
so, like this:
http://public-inbox.org/git/Pine.LNX.4.58.0504150753440.7211@ppc970.osdl.org
Often these web interfaces accept the message ID with enclosing <>
stripped (like the above example to point at one of the most important
message in the Git list).
Some members of the development community can sometimes be found on
the #git and #git-devel IRC channels on Freenode. Their logs are
available at:
http://colabti.org/irclogger/irclogger_log/git
http://colabti.org/irclogger/irclogger_log/git-devel
There is a volunteer-run newsletter to serve our community ("Git Rev
News" http://git.github.io/rev_news/rev_news.html).
Git is a member project of software freedom conservancy, a non-profit
organization (https://sfconservancy.org/). To reach a committee of
liaisons to the conservancy, contact them at <git@sfconservancy.org>.
* Reporting bugs
When you think git does not behave as you expect, please do not stop
your bug report with just "git does not work". "I used git in this
way, but it did not work" is not much better, neither is "I used git
in this way, and X happend, which is broken". It often is that git is
correct to cause X happen in such a case, and it is your expectation
that is broken. People would not know what other result Y you expected
to see instead of X, if you left it unsaid.
Please remember to always state
- what you wanted to achieve;
- what you did (the version of git and the command sequence to reproduce
the behavior);
- what you saw happen (X above);
- what you expected to see (Y above); and
- how the last two are different.
See http://www.chiark.greenend.org.uk/~sgtatham/bugs.html for further
hints.
If you think you found a security-sensitive issue and want to disclose
it to us without announcing it to wider public, please contact us at
our security mailing list <git-security@googlegroups.com>. This is
a closed list that is limited to people who need to know early about
vulnerabilities, including:
- people triaging and fixing reported vulnerabilities
- people operating major git hosting sites with many users
- people packaging and distributing git to large numbers of people
where these issues are discussed without risk of the information
leaking out before we're ready to make public announcements.
* Repositories and documentation.
My public git.git repositories are at:
git://git.kernel.org/pub/scm/git/git.git/
https://kernel.googlesource.com/pub/scm/git/git
git://repo.or.cz/alt-git.git/
https://github.com/git/git/
git://git.sourceforge.jp/gitroot/git-core/git.git/
git://git-core.git.sourceforge.net/gitroot/git-core/git-core/
A few web interfaces are found at:
http://git.kernel.org/cgit/git/git.git
https://kernel.googlesource.com/pub/scm/git/git
http://repo.or.cz/w/alt-git.git
Preformatted documentation from the tip of the "master" branch can be
found in:
git://git.kernel.org/pub/scm/git/git-{htmldocs,manpages}.git/
git://repo.or.cz/git-{htmldocs,manpages}.git/
https://github.com/gitster/git-{htmldocs,manpages}.git/
The manual pages formatted in HTML for the tip of 'master' can be
viewed online at:
https://git.github.io/htmldocs/git.html
* How various branches are used.
There are four branches in git.git repository that track the source tree
of git: "master", "maint", "next", and "pu".
The "master" branch is meant to contain what are very well tested and
ready to be used in a production setting. Every now and then, a
"feature release" is cut from the tip of this branch. They used to be
named with three dotted decimal digits (e.g. "1.8.5"), but recently we
switched the versioning scheme and "feature releases" are named with
three-dotted decimal digits that ends with ".0" (e.g. "1.9.0").
The last such release was 2.10 done on Sep 2nd, 2016. You can expect
that the tip of the "master" branch is always more stable than any of
the released versions.
Whenever a feature release is made, "maint" branch is forked off from
"master" at that point. Obvious and safe fixes after a feature
release are applied to this branch and maintenance releases are cut
from it. Usually the fixes are merged to the "master" branch first,
several days before merged to the "maint" branch, to reduce the chance
of last-minute issues. The maintenance releases used to be named with
four dotted decimal, named after the feature release they are updates
to (e.g. "1.8.5.1" was the first maintenance release for "1.8.5"
feature release). These days, maintenance releases are named by
incrementing the last digit of three-dotted decimal name (e.g. "2.9.3"
is the third maintenance release for the "2.9" series).
New features never go to the 'maint' branch. This branch is also
merged into "master" to propagate the fixes forward as needed.
A new development does not usually happen on "master". When you send a
series of patches, after review on the mailing list, a separate topic
branch is forked from the tip of "master" and your patches are queued
there, and kept out of "master" while people test it out. The quality of
topic branches are judged primarily by the mailing list discussions.
Topic branches that are in good shape are merged to the "next" branch. In
general, the "next" branch always contains the tip of "master". It might
not be quite rock-solid, but is expected to work more or less without major
breakage. The "next" branch is where new and exciting things take place. A
topic that is in "next" is expected to be polished to perfection before it
is merged to "master". Please help this process by building & using the
"next" branch for your daily work, and reporting any new bugs you find to
the mailing list, before the breakage is merged down to the "master".
The "pu" (proposed updates) branch bundles all the remaining topic
branches the maintainer happens to have seen. There is no guarantee that
the maintainer has enough bandwidth to pick up any and all topics that
are remotely promising from the list traffic, so please do not read
too much into a topic being on (or not on) the "pu" branch. This
branch is mainly to remind the maintainer that the topics in them may
turn out to be interesting when they are polished, nothing more. The
topics on this branch aren't usually complete, well tested, or well
documented and they often need further work. When a topic that was
in "pu" proves to be in a testable shape, it is merged to "next".
You can run "git log --first-parent master..pu" to see what topics are
currently in flight. Sometimes, an idea that looked promising turns out
to be not so good and the topic can be dropped from "pu" in such a case.
The output of the above "git log" talks about a "jch" branch, which is an
early part of the "pu" branch; that branch contains all topics that
are in "next" and a bit more (but not all of "pu") and is used by the
maintainer for his daily work.
The two branches "master" and "maint" are never rewound, and "next"
usually will not be either. After a feature release is made from
"master", however, "next" will be rebuilt from the tip of "master"
using the topics that didn't make the cut in the feature release.
Note that being in "next" is not a guarantee to appear in the next
release, nor even in any future release. There were cases that topics
needed reverting a few commits in them before graduating to "master",
or a topic that already was in "next" was reverted from "next" because
fatal flaws were found in it after it was merged to "next".
* Other people's trees.
Documentation/SubmittingPatches outlines to whom your proposed changes
should be sent. As described in contrib/README, I would delegate fixes
and enhancements in contrib/ area to the primary contributors of them.
Although the following are included in git.git repository, they have their
own authoritative repository and maintainers:
- git-gui/ comes from git-gui project, maintained by Pat Thoyts:
git://repo.or.cz/git-gui.git
- gitk-git/ comes from Paul Mackerras's gitk project:
git://ozlabs.org/~paulus/gitk
- po/ comes from the localization coordinator, Jiang Xin:
https://github.com/git-l10n/git-po/
When sending proposed updates and fixes to these parts of the system,
please base your patches on these trees, not git.git (the former two
even have different directory structures).
^ permalink raw reply
* What's cooking in git.git (Oct 2016, #01; Mon, 3)
From: Junio C Hamano @ 2016-10-03 22:31 UTC (permalink / raw)
To: git
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 ones marked with '.' do not appear in any of
the integration branches, but I am still holding onto them.
With fixes since 2.10 accumulated on the 'master' front, the first
maintenance release 2.10.1 has been tagged. The auto-abbreviation
by Linus and Peff is now in 'next'. The tip of 'master' has quite a
many topics merged since the last report. Pat is back and hopefully
be more active as the git-gui maintainer. Life is good ;-)
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"]
* dt/mailinfo (2016-09-26) 1 commit
(merged to 'next' on 2016-09-27 at 59e95dbc0e)
+ add David Turner's Two Sigma address
* dt/tree-fsck (2016-09-27) 2 commits
(merged to 'next' on 2016-09-28 at afdfdbbf37)
+ fsck: handle bad trees like other errors
+ tree-walk: be more specific about corrupt tree errors
The codepath in "git fsck" to detect malformed tree objects has
been updated not to die but keep going after detecting them.
* ik/gitweb-force-highlight (2016-09-25) 2 commits
(merged to 'next' on 2016-09-27 at cbb8391a76)
+ gitweb: use highlight's shebang detection
+ gitweb: remove unused guess_file_syntax() parameter
"gitweb" can spawn "highlight" to show blob contents with
(programming) language-specific syntax highlighting, but only
when the language is known. "highlight" can however be told
to make the guess itself by giving it "--force" option, which
has been enabled.
* jc/verify-loose-object-header (2016-09-26) 2 commits
(merged to 'next' on 2016-09-27 at 2947f95f14)
+ unpack_sha1_header(): detect malformed object header
+ streaming: make sure to notice corrupt object
Codepaths that read from an on-disk loose object were too loose in
validating what they are reading is a proper object file and
sometimes read past the data they read from the disk, which has
been corrected. H/t to Gustavo Grieco for reporting.
* jc/worktree-config (2016-09-27) 1 commit
(merged to 'next' on 2016-09-28 at 0c262f6)
+ worktree: honor configuration variables
"git worktree", even though it used the default_abbrev setting that
ought to be affected by core.abbrev configuration variable, ignored
the variable setting. The command has been taught to read the
default set of configuration variables to correct this.
* jk/ident-ai-canonname-could-be-null (2016-09-23) 1 commit
(merged to 'next' on 2016-09-26 at 0eefb29)
+ ident: handle NULL ai_canonname
In the codepath that comes up with the hostname to be used in an
e-mail when the user didn't tell us, we looked at ai_canonname
field in struct addrinfo without making sure it is not NULL first.
* jk/verify-packfile-gently (2016-09-22) 1 commit
(merged to 'next' on 2016-09-26 at f5abba5)
+ verify_packfile: check pack validity before accessing data
A low-level function verify_packfile() was meant to show errors
that were detected without dying itself, but under some conditions
it didn't and died instead, which has been fixed.
* jt/fetch-pack-in-vain-count-with-stateless (2016-09-23) 1 commit
(merged to 'next' on 2016-09-26 at 9645629)
+ fetch-pack: do not reset in_vain on non-novel acks
When "git fetch" tries to find where the history of the repository
it runs in has diverged from what the other side has, it has a
mechanism to avoid digging too deep into irrelevant side branches.
This however did not work well over the "smart-http" transport due
to a design bug, which has been fixed.
* jt/mailinfo-fold-in-body-headers (2016-09-21) 3 commits
(merged to 'next' on 2016-09-26 at 4235eb6)
+ mailinfo: handle in-body header continuations
+ mailinfo: make is_scissors_line take plain char *
+ mailinfo: separate in-body header processing
When "git format-patch --stdout" output is placed as an in-body
header and it uses the RFC2822 header folding, "git am" failed to
put the header line back into a single logical line. The
underlying "git mailinfo" was taught to handle this properly.
* kd/mailinfo-quoted-string (2016-09-28) 2 commits
(merged to 'next' on 2016-09-28 at 2aaeb57804)
+ mailinfo: unescape quoted-pair in header fields
+ t5100-mailinfo: replace common path prefix with variable
An author name, that spelled a backslash-quoted double quote in the
human readable part "My \"double quoted\" name", was not unquoted
correctly while applying a patch from a piece of e-mail.
* mh/diff-indent-heuristic (2016-09-27) 1 commit
(merged to 'next' on 2016-09-27 at 3d6fb6605a)
+ xdiff: rename "struct group" to "struct xdlgroup"
Clean-up for a recently graduated topic.
* nd/init-core-worktree-in-multi-worktree-world (2016-09-25) 5 commits
(merged to 'next' on 2016-09-27 at 619f7f3a3b)
+ init: kill git_link variable
+ init: do not set unnecessary core.worktree
+ init: kill set_git_dir_init()
+ init: call set_git_dir_init() from within init_db()
+ init: correct re-initialization from a linked worktree
"git init" tried to record core.worktree in the repository's
'config' file when GIT_WORK_TREE environment variable was set and
it was different from where GIT_DIR appears as ".git" at its top,
but the logic was faulty when .git is a "gitdir:" file that points
at the real place, causing trouble in working trees that are
managed by "git worktree". This has been corrected.
* pb/rev-list-reverse-with-count (2016-09-27) 1 commit
(merged to 'next' on 2016-09-28 at 2905d0adbc)
+ rev-list-options: clarify the usage of --reverse
Doc update to clarify what "log -3 --reverse" does.
* rs/copy-array (2016-09-25) 2 commits
(merged to 'next' on 2016-09-27 at c92e020669)
+ use COPY_ARRAY
+ add COPY_ARRAY
Code cleanup.
* rs/git-gui-use-modern-git-merge-syntax (2016-09-26) 2 commits
(merged to 'next' on 2016-09-27 at f55850df7d)
+ Merge branch 'rs/use-modern-git-merge-syntax' of git-gui into rs/git-gui-use-modern-git-merge-syntax
+ git-gui: stop using deprecated merge syntax
The original command line syntax for "git merge", which was "git
merge <msg> HEAD <parent>...", has been deprecated for quite some
time, and "git gui" was the last in-tree user of the syntax. This
is finally fixed, so that we can move forward with the deprecation.
* va/git-gui-i18n (2016-09-26) 3 commits
(merged to 'next' on 2016-09-27 at ab0f66ff8a)
+ Merge branch 'va/i18n' of ../git-gui into va/git-gui-i18n
+ git-gui: l10n: add Portuguese translation
+ git-gui i18n: mark strings for translation
"git gui" l10n to Portuguese.
--------------------------------------------------
[New Topics]
* rs/cocci (2016-10-03) 4 commits
(merged to 'next' on 2016-10-03 at 758cc6de9c)
+ coccicheck: make transformation for strbuf_addf(sb, "...") more precise
(merged to 'next' on 2016-09-28 at 26462645f9)
+ use strbuf_add_unique_abbrev() for adding short hashes, part 2
+ use strbuf_addstr() instead of strbuf_addf() with "%s", part 2
+ gitignore: ignore output files of coccicheck make target
Code clean-up with help from coccinelle tool continues.
Will merge to 'master'.
* nd/ita-empty-commit (2016-09-28) 3 commits
- commit: don't be fooled by ita entries when creating initial commit
- diff-lib.c: enable --shift-ita in index_differs_from()
- Resurrect "diff-lib.c: adjust position of i-t-a entries in diff"
When new paths were added by "git add -N" to the index, it was
enough to circumvent the check by "git commit" to refrain from
making an empty commit without "--allow-empty". The same logic
prevented "git status" to show such a path as "new file" in the
"Changes not staged for commit" section.
Expecting a reroll.
cf. <xmqqzimrj03j.fsf@gitster.mtv.corp.google.com>
cf. <xmqq8tubkgg5.fsf@gitster.mtv.corp.google.com>
* jc/blame-abbrev (2016-09-28) 1 commit
(merged to 'next' on 2016-10-03 at 8ec86ff1e1)
+ blame: use DEFAULT_ABBREV macro
Almost everybody uses DEFAULT_ABBREV to refer to the default
setting for the abbreviation, but "git blame" peeked into
underlying variable bypassing the macro for no good reason.
Will merge to 'master'.
* lt/abbrev-auto (2016-10-03) 3 commits
(merged to 'next' on 2016-10-03 at bb188d00f7)
+ abbrev: auto size the default abbreviation
+ abbrev: prepare for new world order
+ abbrev: add FALLBACK_DEFAULT_ABBREV to prepare for auto sizing
(this branch uses jk/ambiguous-short-object-names.)
Allow the default abbreviation length, which has historically been
7, to scale as the repository grows. The logic suggests to use 12
hexdigits for the Linux kernel, and 9 to 10 for Git itself.
Will merge to 'master'.
* dt/http-empty-auth (2016-10-03) 1 commit
- http: http.emptyauth should allow empty (not just NULL) usernames
http.emptyauth configuration is a way to allow an empty username to
pass when attempting to authenticate using mechanisms like
Kerberos. We took an unspecified (NULL) username and sent ":"
(i.e. no username, no password) to CURLOPT_USERPWD, but did not do
the same when the username is explicitly set to an empty string.
cf. <20161003210100.t5nqknwfotag3lmj@sigill.intra.peff.net>
* jc/diff-unique-abbrev-comments (2016-09-30) 1 commit
- diff_unique_abbrev(): document its assumption and limitation
* jk/graph-padding-fix (2016-09-29) 1 commit
(merged to 'next' on 2016-10-03 at 3f526e0f38)
+ graph: fix extra spaces in graph_padding_line
The "graph" API used in "git log --graph" miscounted the number of
output columns consumed so far when drawing a padding line, which
has been fixed; this did not affect any existing code as nobody
tried to write anything after the padding on such a line, though.
Will merge to 'master'.
* jk/quarantine-received-objects (2016-10-03) 5 commits
- tmp-objdir: do not migrate files starting with '.'
- tmp-objdir: put quarantine information in the environment
- receive-pack: quarantine objects until pre-receive accepts
- tmp-objdir: introduce API for temporary object directories
- check_connected: accept an env argument
(this branch uses jk/alt-odb-cleanup.)
In order for the receiving end of "git push" to inspect the
received history and decide to reject the push, the objects sent
from the sending end need to be made available to the hook and
the mechanism for the connectivity check, and this was done
traditionally by storing the objects in the receiving repository
and letting "git gc" to expire it. Instead, store the newly
received objects in a temporary area, and make them available by
reusing the alternate object store mechanism to them only while we
decide if we accept the check, and once we decide, either migrate
them to the repository or purge them immediately.
* ps/http-gssapi-cred-delegation (2016-09-29) 1 commit
(merged to 'next' on 2016-10-03 at 310fbe8f24)
+ http: control GSSAPI credential delegation
In recent versions of cURL, GSSAPI credential delegation is
disabled by default due to CVE-2011-2192; introduce a configuration
to selectively allow enabling this.
Will merge to 'master'.
* rs/c-auto-resets-attributes (2016-09-29) 1 commit
(merged to 'next' on 2016-10-03 at 6a0b946a79)
+ pretty: avoid adding reset for %C(auto) if output is empty
When "%C(auto)" appears at the very beginning of the pretty format
string, it did not need to issue the reset sequence, but it did.
Will merge to 'master'.
This is a small optimization to already graduated topic.
* rs/qsort (2016-10-03) 6 commits
- show-branch: use QSORT
- use QSORT, part 2
- coccicheck: use --all-includes by default
- remove unnecessary check before QSORT
- use QSORT
- add QSORT
We call "qsort(array, nelem, sizeof(array[0]), fn)", and most of
the time third parameter is redundant. A new QSORT() macro lets us
omit it.
Will merge to 'next'.
* sg/ref-filter-parse-optim (2016-10-03) 1 commit
(merged to 'next' on 2016-10-03 at 9af6bb63e9)
+ ref-filter: strip format option after a field name only once while parsing
The code that parses the format parameter of for-each-ref command
has seen a micro-optimization.
Will merge to 'master'.
* jk/alt-odb-cleanup (2016-10-03) 18 commits
- alternates: use fspathcmp to detect duplicates
- sha1_file: always allow relative paths to alternates
- count-objects: report alternates via verbose mode
- fill_sha1_file: write into a strbuf
- alternates: store scratch buffer as strbuf
- fill_sha1_file: write "boring" characters
- alternates: use a separate scratch space
- alternates: encapsulate alt->base munging
- alternates: provide helper for allocating alternate
- alternates: provide helper for adding to alternates list
- link_alt_odb_entry: refactor string handling
- link_alt_odb_entry: handle normalize_path errors
- t5613: clarify "too deep" recursion tests
- t5613: do not chdir in main process
- t5613: whitespace/style cleanups
- t5613: use test_must_fail
- t5613: drop test_valid_repo function
- t5613: drop reachable_via function
(this branch is used by jk/quarantine-received-objects.)
--------------------------------------------------
[Stalled]
* jc/bundle (2016-03-03) 6 commits
- index-pack: --clone-bundle option
- Merge branch 'jc/index-pack' into jc/bundle
- bundle v3: the beginning
- bundle: keep a copy of bundle file name in the in-core bundle header
- bundle: plug resource leak
- bundle doc: 'verify' is not about verifying the bundle
The beginning of "split bundle", which could be one of the
ingredients to allow "git clone" traffic off of the core server
network to CDN.
While I think it would make it easier for people to experiment and
build on if the topic is merged to 'next', I am at the same time a
bit reluctant to merge an unproven new topic that introduces a new
file format, which we may end up having to support til the end of
time. It is likely that to support a "prime clone from CDN", it
would need a lot more than just "these are the heads and the pack
data is over there", so this may not be sufficient.
Will discard.
* jc/attr (2016-05-25) 18 commits
- attr: support quoting pathname patterns in C style
- attr: expose validity check for attribute names
- attr: add counted string version of git_attr()
- attr: add counted string version of git_check_attr()
- attr: retire git_check_attrs() API
- attr: convert git_check_attrs() callers to use the new API
- attr: convert git_all_attrs() to use "struct git_attr_check"
- attr: (re)introduce git_check_attr() and struct git_attr_check
- attr: rename function and struct related to checking attributes
- attr.c: plug small leak in parse_attr_line()
- attr.c: tighten constness around "git_attr" structure
- attr.c: simplify macroexpand_one()
- attr.c: mark where #if DEBUG ends more clearly
- attr.c: complete a sentence in a comment
- attr.c: explain the lack of attr-name syntax check in parse_attr()
- attr.c: update a stale comment on "struct match_attr"
- attr.c: use strchrnul() to scan for one line
- commit.c: use strchrnul() to scan for one line
(this branch is used by jc/attr-more, sb/pathspec-label and sb/submodule-default-paths.)
The attributes API has been updated so that it can later be
optimized using the knowledge of which attributes are queried.
I wanted to polish this topic further to make the attribute
subsystem thread-ready, but because other topics depend on this
topic and they do not (yet) need it to be thread-ready.
As the authors of topics that depend on this seem not in a hurry,
let's discard this and dependent topics and restart them some other
day.
Will discard.
* jc/attr-more (2016-06-09) 8 commits
- attr.c: outline the future plans by heavily commenting
- attr.c: always pass check[] to collect_some_attrs()
- attr.c: introduce empty_attr_check_elems()
- attr.c: correct ugly hack for git_all_attrs()
- attr.c: rename a local variable check
- fixup! d5ad6c13
- attr.c: pass struct git_attr_check down the callchain
- attr.c: add push_stack() helper
(this branch uses jc/attr; is tangled with sb/pathspec-label and sb/submodule-default-paths.)
The beginning of long and tortuous journey to clean-up attribute
subsystem implementation.
Needs to be redone.
Will discard.
* sb/submodule-default-paths (2016-06-20) 5 commits
- completion: clone can recurse into submodules
- clone: add --init-submodule=<pathspec> switch
- submodule update: add `--init-default-path` switch
- Merge branch 'sb/pathspec-label' into sb/submodule-default-paths
- Merge branch 'jc/attr' into sb/submodule-default-paths
(this branch uses jc/attr and sb/pathspec-label; is tangled with jc/attr-more.)
Allow specifying the set of submodules the user is interested in on
the command line of "git clone" that clones the superproject.
Will discard.
* sb/pathspec-label (2016-06-03) 6 commits
- pathspec: disable preload-index when attribute pathspec magic is in use
- pathspec: allow escaped query values
- pathspec: allow querying for attributes
- pathspec: move prefix check out of the inner loop
- pathspec: move long magic parsing out of prefix_pathspec
- Documentation: fix a typo
(this branch is used by sb/submodule-default-paths; uses jc/attr; is tangled with jc/attr-more.)
The pathspec mechanism learned ":(attr:X)$pattern" pathspec magic
to limit paths that match $pattern further by attribute settings.
The preload-index mechanism is disabled when the new pathspec magic
is in use (at least for now), because the attribute subsystem is
not thread-ready.
Will discard.
* mh/connect (2016-06-06) 10 commits
- connect: [host:port] is legacy for ssh
- connect: move ssh command line preparation to a separate function
- connect: actively reject git:// urls with a user part
- connect: change the --diag-url output to separate user and host
- connect: make parse_connect_url() return the user part of the url as a separate value
- connect: group CONNECT_DIAG_URL handling code
- connect: make parse_connect_url() return separated host and port
- connect: re-derive a host:port string from the separate host and port variables
- connect: call get_host_and_port() earlier
- connect: document why we sometimes call get_port after get_host_and_port
Rewrite Git-URL parsing routine (hopefully) without changing any
behaviour.
It has been two months without any support. We may want to discard
this.
* pb/bisect (2016-08-23) 27 commits
. bisect--helper: remove the dequote in bisect_start()
. bisect--helper: retire `--bisect-auto-next` subcommand
. bisect--helper: retire `--bisect-autostart` subcommand
. bisect--helper: retire `--check-and-set-terms` subcommand
. bisect--helper: retire `--bisect-write` subcommand
. bisect--helper: `bisect_replay` shell function in C
. bisect--helper: `bisect_log` shell function in C
. bisect--helper: retire `--write-terms` subcommand
. bisect--helper: retire `--check-expected-revs` subcommand
. bisect--helper: `bisect_state` & `bisect_head` shell function in C
. bisect--helper: `bisect_autostart` shell function in C
. bisect--helper: retire `--next-all` subcommand
. bisect--helper: retire `--bisect-clean-state` subcommand
. bisect--helper: `bisect_next` and `bisect_auto_next` shell function in C
. bisect--helper: `bisect_start` shell function partially in C
. bisect--helper: `get_terms` & `bisect_terms` shell function in C
. bisect--helper: `bisect_next_check` & bisect_voc shell function in C
. bisect--helper: `check_and_set_terms` shell function in C
. bisect--helper: `bisect_write` shell function in C
. bisect--helper: `is_expected_rev` & `check_expected_revs` shell function in C
. bisect--helper: `bisect_reset` shell function in C
. wrapper: move is_empty_file() and rename it as is_empty_or_missing_file()
. t6030: explicitly test for bisection cleanup
. bisect--helper: `bisect_clean_state` shell function in C
. bisect--helper: `write_terms` shell function in C
. bisect: rewrite `check_term_format` shell function in C
. bisect--helper: use OPT_CMDMODE instead of OPT_BOOL
GSoC "bisect" topic.
I'd prefer to see early part solidified so that reviews can focus
on the later part that is still in flux. We are almost there but
not quite yet.
* kn/ref-filter-branch-list (2016-05-17) 17 commits
- branch: implement '--format' option
- branch: use ref-filter printing APIs
- branch, tag: use porcelain output
- ref-filter: allow porcelain to translate messages in the output
- ref-filter: add `:dir` and `:base` options for ref printing atoms
- ref-filter: make remote_ref_atom_parser() use refname_atom_parser_internal()
- ref-filter: introduce symref_atom_parser() and refname_atom_parser()
- ref-filter: introduce refname_atom_parser_internal()
- ref-filter: make "%(symref)" atom work with the ':short' modifier
- ref-filter: add support for %(upstream:track,nobracket)
- ref-filter: make %(upstream:track) prints "[gone]" for invalid upstreams
- ref-filter: introduce format_ref_array_item()
- ref-filter: move get_head_description() from branch.c
- ref-filter: modify "%(objectname:short)" to take length
- ref-filter: implement %(if:equals=<string>) and %(if:notequals=<string>)
- ref-filter: include reference to 'used_atom' within 'atom_value'
- ref-filter: implement %(if), %(then), and %(else) atoms
The code to list branches in "git branch" has been consolidated
with the more generic ref-filter API.
Rerolled.
Needs review.
* sb/bisect (2016-04-15) 22 commits
. SQUASH???
. bisect: get back halfway shortcut
. bisect: compute best bisection in compute_relevant_weights()
. bisect: use a bottom-up traversal to find relevant weights
. bisect: prepare for different algorithms based on find_all
. bisect: rename count_distance() to compute_weight()
. bisect: make total number of commits global
. bisect: introduce distance_direction()
. bisect: extract get_distance() function from code duplication
. bisect: use commit instead of commit list as arguments when appropriate
. bisect: replace clear_distance() by unique markers
. bisect: use struct node_data array instead of int array
. bisect: get rid of recursion in count_distance()
. bisect: make algorithm behavior independent of DEBUG_BISECT
. bisect: make bisect compile if DEBUG_BISECT is set
. bisect: plug the biggest memory leak
. bisect: add test for the bisect algorithm
. t6030: generalize test to not rely on current implementation
. t: use test_cmp_rev() where appropriate
. t/test-lib-functions.sh: generalize test_cmp_rev
. bisect: allow 'bisect run' if no good commit is known
. bisect: write about `bisect next` in documentation
The internal algorithm used in "git bisect" to find the next commit
to check has been optimized greatly.
Was expecting a reroll, but now pb/bisect topic starts removinging
more and more parts from git-bisect.sh, this needs to see a fresh
reroll.
Will discard.
cf. <1460294354-7031-1-git-send-email-s-beyer@gmx.net>
* sg/completion-updates (2016-02-28) 21 commits
. completion: cache the path to the repository
. completion: extract repository discovery from __gitdir()
. completion: don't guard git executions with __gitdir()
. completion: consolidate silencing errors from git commands
. completion: don't use __gitdir() for git commands
. completion: respect 'git -C <path>'
. completion: fix completion after 'git -C <path>'
. completion: don't offer commands when 'git --opt' needs an argument
. rev-parse: add '--absolute-git-dir' option
. completion: list short refs from a remote given as a URL
. completion: don't list 'HEAD' when trying refs completion outside of a repo
. completion: list refs from remote when remote's name matches a directory
. completion: respect 'git --git-dir=<path>' when listing remote refs
. completion: fix most spots not respecting 'git --git-dir=<path>'
. completion: ensure that the repository path given on the command line exists
. completion tests: add tests for the __git_refs() helper function
. completion tests: check __gitdir()'s output in the error cases
. completion tests: consolidate getting path of current working directory
. completion tests: make the $cur variable local to the test helper functions
. completion tests: don't add test cruft to the test repository
. completion: improve __git_refs()'s in-code documentation
Has been waiting for a reroll for too long.
cf. <1456754714-25237-1-git-send-email-szeder@ira.uka.de>
Will discard.
* ec/annotate-deleted (2015-11-20) 1 commit
- annotate: skip checking working tree if a revision is provided
Usability fix for annotate-specific "<file> <rev>" syntax with deleted
files.
Has been waiting for a review for too long without seeing anything.
Will discard.
* dk/gc-more-wo-pack (2016-01-13) 4 commits
- gc: clean garbage .bitmap files from pack dir
- t5304: ensure non-garbage files are not deleted
- t5304: test .bitmap garbage files
- prepare_packed_git(): find more garbage
Follow-on to dk/gc-idx-wo-pack topic, to clean up stale
.bitmap and .keep files.
Has been waiting for a reroll for too long.
cf. <xmqq60ypbeng.fsf@gitster.mtv.corp.google.com>
Will discard.
* jc/diff-b-m (2015-02-23) 5 commits
. WIPWIP
. WIP: diff-b-m
- diffcore-rename: allow easier debugging
- diffcore-rename.c: add locate_rename_src()
- diffcore-break: allow debugging
"git diff -B -M" produced incorrect patch when the postimage of a
completely rewritten file is similar to the preimage of a removed
file; such a resulting file must not be expressed as a rename from
other place.
The fix in this patch is broken, unfortunately.
Will discard.
--------------------------------------------------
[Cooking]
* jk/ambiguous-short-object-names (2016-09-27) 11 commits
(merged to 'next' on 2016-09-28 at 1b85295323)
+ get_short_sha1: make default disambiguation configurable
+ get_short_sha1: list ambiguous objects on error
+ for_each_abbrev: drop duplicate objects
+ sha1_array: let callbacks interrupt iteration
+ get_short_sha1: mark ambiguity error for translation
+ get_short_sha1: NUL-terminate hex prefix
+ get_short_sha1: refactor init of disambiguation code
+ get_short_sha1: parse tags when looking for treeish
+ get_sha1: propagate flags to child functions
+ get_sha1: avoid repeating ourselves via ONLY_TO_DIE
+ get_sha1: detect buggy calls with multiple disambiguators
(this branch is used by lt/abbrev-auto.)
When given an abbreviated object name that is not (or more
realistically, "no longer") unique, we gave a fatal error
"ambiguous argument". This error is now accompanied by hints that
lists the objects that begins with the given prefix. During the
course of development of this new feature, numerous minor bugs were
uncovered and corrected, the most notable one of which is that we
gave "short SHA1 xxxx is ambiguous." twice without good reason.
Will merge to 'master'.
* va/i18n-perl-scripts (2016-09-25) 11 commits
- i18n: difftool: mark warnings for translation
- i18n: send-email: mark string with interpolation for translation
- i18n: send-email: mark warnings and errors for translation
- i18n: send-email: mark strings for translation
- i18n: add--interactive: mark edit_hunk_manually message for translation
- i18n: add--interactive: i18n of help_patch_cmd
- i18n: add--interactive: mark message for translation
- i18n: add--interactive: mark plural strings
- i18n: add--interactive: mark strings with interpolation for translation
- i18n: add--interactive: mark simple here documents for translation
- i18n: add--interactive: mark strings for translation
Porcelain scripts written in Perl are getting internationalized.
Waiting for a reroll.
cf. <1474913721.1035.9.camel@sapo.pt>
* vn/revision-shorthand-for-side-branch-log (2016-09-27) 1 commit
(merged to 'next' on 2016-09-28 at c1237b24f6)
+ revision: new rev^-n shorthand for rev^n..rev
"git log rev^..rev" is an often-used revision range specification
to show what was done on a side branch merged at rev. This has
gained a short-hand "rev^-1". In general "rev^-$n" is the same as
"^rev^$n rev", i.e. what has happened on other branches while the
history leading to nth parent was looking the other way.
Will merge to 'master'.
* jc/latin-1 (2016-09-26) 2 commits
(merged to 'next' on 2016-09-28 at c8673e03c2)
+ utf8: accept "latin-1" as ISO-8859-1
+ utf8: refactor code to decide fallback encoding
Some platforms no longer understand "latin-1" that is still seen in
the wild in e-mail headers; replace them with "iso-8859-1" that is
more widely known when conversion fails from/to it.
Will hold to see if people scream.
* mg/gpg-richer-status (2016-09-28) 1 commit
- gpg-interface: use more status letters
The GPG verification status shown in "%G?" pretty format specifier
was not rich enough to differentiate a signature made by an expired
key, a signature made by a revoked key, etc. New output letters
have been assigned to express them.
* jc/blame-reverse (2016-06-14) 2 commits
(merged to 'next' on 2016-09-22 at d1a8e9ce99)
+ blame: dwim "blame --reverse OLD" as "blame --reverse OLD.."
+ blame: improve diagnosis for "--reverse NEW"
It is a common mistake to say "git blame --reverse OLD path",
expecting that the command line is dwimmed as if asking how lines
in path in an old revision OLD have survived up to the current
commit.
Will hold to see if it is broken.
* js/libify-require-clean-work-tree (2016-09-12) 5 commits
- wt-status: teach has_{unstaged,uncommitted}_changes() about submodules
- Export also the has_un{staged,committed}_changed() functions
- Make the require_clean_work_tree() function truly reusable
- pull: make code more similar to the shell script again
- pull: drop confusing prefix parameter of die_on_unclean_work_tree()
The require_clean_work_tree() helper was recreated in C when "git
pull" was rewritten from shell; the helper is now made available to
other callers in preparation for upcoming "rebase -i" work.
Waiting for comments.
Modulo a few minor nits, this looked almost ready.
cf. <xmqqtwdl2bhm.fsf@gitster.mtv.corp.google.com>
cf. <xmqqpoo92bdr.fsf@gitster.mtv.corp.google.com>
* bw/ls-files-recurse-submodules (2016-10-03) 4 commits
- ls-files: add pathspec matching for submodules
- ls-files: pass through safe options for --recurse-submodules
- ls-files: optionally recurse into submodules
- git: make super-prefix option
"git ls-files" learned "--recurse-submodules" option that can be
used to get a listing of tracked files across submodules (i.e. this
only works with "--cached" option, not for listing untracked or
ignored files). This would be a useful tool to sit on the upstream
side of a pipe that is read with xargs to work on all working tree
files from the top-level superproject.
Looking good. Is this ready for 'next'?
* ls/filter-process (2016-09-23) 11 commits
- convert: add filter.<driver>.process option
- convert: make apply_filter() adhere to standard Git error handling
- convert: modernize tests
- convert: quote filter names in error messages
- pkt-line: add functions to read/write flush terminated packet streams
- pkt-line: add packet_write_gently()
- pkt-line: add packet_flush_gently()
- pkt-line: add packet_write_fmt_gently()
- run-command: move check_pipe() from write_or_die to run_command
- pkt-line: extract set_packet_header()
- pkt-line: rename packet_write() to packet_write_fmt()
The smudge/clean filter API expect an external process is spawned
to filter the contents for each path that has a filter defined. A
new type of "process" filter API has been added to allow the first
request to run the filter for a path to spawn a single process, and
all filtering need is served by this single process for multiple
paths, reducing the process creation overhead.
Somehow I thought this was getting ready for 'next' but it seems
at least another round of reroll is coming?
* hv/submodule-not-yet-pushed-fix (2016-09-14) 2 commits
- serialize collection of refs that contain submodule changes
- serialize collection of changed submodules
The code in "git push" to compute if any commit being pushed in the
superproject binds a commit in a submodule that hasn't been pushed
out was overly inefficient, making it unusable even for a small
project that does not have any submodule but have a reasonable
number of refs.
The last two in the original series seem to break a few tests when
queued to 'pu', and dropped for now.
Waiting for a reroll.
* sg/fix-versioncmp-with-common-suffix (2016-09-08) 5 commits
- versioncmp: cope with common leading parts in versionsort.prereleaseSuffix
- versioncmp: pass full tagnames to swap_prereleases()
- t7004-tag: add version sort tests to show prerelease reordering issues
- t7004-tag: use test_config helper
- t7004-tag: delete unnecessary tags with test_when_finished
The prereleaseSuffix feature of version comparison that is used in
"git tag -l" did not correctly when two or more prereleases for the
same release were present (e.g. when 2.0, 2.0-beta1, and 2.0-beta2
are there and the code needs to compare 2.0-beta1 and 2.0-beta2).
Waiting for a reroll.
cf. <20160908223727.Horde.jVOOJ278ssZ3qkyjkmyqZD-@webmail.informatik.kit.edu>
* cp/completion-negative-refs (2016-08-24) 1 commit
(merged to 'next' on 2016-09-22 at abd1585aa6)
+ completion: support excluding refs
The command-line completion script (in contrib/) learned to
complete "git cmd ^mas<HT>" to complete the negative end of
reference to "git cmd ^master".
Will hold to see if it is broken.
* sb/push-make-submodule-check-the-default (2016-08-24) 1 commit
- push: change submodule default to check
Turn the default of "push.recurseSubmodules" to "check".
Will hold to wait for hv/submodule-not-yet-pushed-fix
This reveals that the "check" mode is too inefficient to use in
real projects, even in ones as small as git itself.
cf. <xmqqh9aaot49.fsf@gitster.mtv.corp.google.com>
* ak/curl-imap-send-explicit-scheme (2016-08-17) 1 commit
(merged to 'next' on 2016-09-22 at 4449584c26)
+ imap-send: Tell cURL to use imap:// or imaps://
When we started cURL to talk to imap server when a new enough
version of cURL library is available, we forgot to explicitly add
imap(s):// before the destination. To some folks, that didn't work
and the library tried to make HTTP(s) requests instead.
Will hold to see if it is broken.
* jk/pack-objects-optim-mru (2016-08-11) 4 commits
(merged to 'next' on 2016-09-21 at 97b919bdbd)
+ pack-objects: use mru list when iterating over packs
+ pack-objects: break delta cycles before delta-search phase
+ sha1_file: make packed_object_info public
+ provide an initializer for "struct object_info"
Originally merged to 'next' on 2016-08-11
"git pack-objects" in a repository with many packfiles used to
spend a lot of time looking for/at objects in them; the accesses to
the packfiles are now optimized by checking the most-recently-used
packfile first.
Will hold to see if people scream.
* dp/autoconf-curl-ssl (2016-06-28) 1 commit
(merged to 'next' on 2016-09-22 at 9c5aeeced9)
+ ./configure.ac: detect SSL in libcurl using curl-config
The ./configure script generated from configure.ac was taught how
to detect support of SSL by libcurl better.
Will hold to see if it is broken.
* jc/pull-rebase-ff (2016-07-28) 1 commit
- pull: fast-forward "pull --rebase=true"
"git pull --rebase", when there is no new commits on our side since
we forked from the upstream, should be able to fast-forward without
invoking "git rebase", but it didn't.
Needs a real log message and a few tests.
* ex/deprecate-empty-pathspec-as-match-all (2016-06-22) 1 commit
(merged to 'next' on 2016-09-21 at e19148ea63)
+ pathspec: warn on empty strings as pathspec
Originally merged to 'next' on 2016-07-13
An empty string used as a pathspec element has always meant
'everything matches', but it is too easy to write a script that
finds a path to remove in $path and run 'git rm "$paht"', which
ends up removing everything. Start warning about this use of an
empty string used for 'everything matches' and ask users to use a
more explicit '.' for that instead.
The hope is that existing users will not mind this change, and
eventually the warning can be turned into a hard error, upgrading
the deprecation into removal of this (mis)feature.
Will hold to see if people scream.
* nd/shallow-deepen (2016-06-13) 27 commits
(merged to 'next' on 2016-09-22 at f0cf3e3385)
+ fetch, upload-pack: --deepen=N extends shallow boundary by N commits
+ upload-pack: add get_reachable_list()
+ upload-pack: split check_unreachable() in two, prep for get_reachable_list()
+ t5500, t5539: tests for shallow depth excluding a ref
+ clone: define shallow clone boundary with --shallow-exclude
+ fetch: define shallow boundary with --shallow-exclude
+ upload-pack: support define shallow boundary by excluding revisions
+ refs: add expand_ref()
+ t5500, t5539: tests for shallow depth since a specific date
+ clone: define shallow clone boundary based on time with --shallow-since
+ fetch: define shallow boundary with --shallow-since
+ upload-pack: add deepen-since to cut shallow repos based on time
+ shallow.c: implement a generic shallow boundary finder based on rev-list
+ fetch-pack: use a separate flag for fetch in deepening mode
+ fetch-pack.c: mark strings for translating
+ fetch-pack: use a common function for verbose printing
+ fetch-pack: use skip_prefix() instead of starts_with()
+ upload-pack: move rev-list code out of check_non_tip()
+ upload-pack: make check_non_tip() clean things up on error
+ upload-pack: tighten number parsing at "deepen" lines
+ upload-pack: use skip_prefix() instead of starts_with()
+ upload-pack: move "unshallow" sending code out of deepen()
+ upload-pack: remove unused variable "backup"
+ upload-pack: move "shallow" sending code out of deepen()
+ upload-pack: move shallow deepen code out of receive_needs()
+ transport-helper.c: refactor set_helper_option()
+ remote-curl.c: convert fetch_git() to use argv_array
The existing "git fetch --depth=<n>" option was hard to use
correctly when making the history of an existing shallow clone
deeper. A new option, "--deepen=<n>", has been added to make this
easier to use. "git clone" also learned "--shallow-since=<date>"
and "--shallow-exclude=<tag>" options to make it easier to specify
"I am interested only in the recent N months worth of history" and
"Give me only the history since that version".
Will hold to see if it is broken.
* jc/merge-drop-old-syntax (2015-04-29) 1 commit
- merge: drop 'git merge <message> HEAD <commit>' syntax
Stop supporting "git merge <message> HEAD <commit>" syntax that has
been deprecated since October 2007, and issues a deprecation
warning message since v2.5.0.
It has been reported that git-gui still uses the deprecated syntax,
which needs to be fixed before this final step can proceed.
cf. <5671DB28.8020901@kdbg.org>
Will hold to wait for rs/git-gui-use-modern-git-merge-syntax
--------------------------------------------------
[Discarded]
* jn/fix-connect-unexpected-hangup-diag (2016-09-08) 1 commit
. connect: tighten check for unexpected early hang up
Now part of jt/accept-capability-advertisement-when-fetching-from-void
topic.
^ permalink raw reply
* [ANNOUNCE] Git v2.10.1
From: Junio C Hamano @ 2016-10-03 22:30 UTC (permalink / raw)
To: git; +Cc: Linux Kernel
The latest maintenance release Git v2.10.1 is now available at
the usual places.
The tarballs are found at:
https://www.kernel.org/pub/software/scm/git/
The following public repositories all have a copy of the 'v2.10.1'
tag and the 'maint' branch that the tag points at:
url = https://kernel.googlesource.com/pub/scm/git/git
url = git://repo.or.cz/alt-git.git
url = git://git.sourceforge.jp/gitroot/git-core/git.git
url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core
url = https://github.com/gitster/git
----------------------------------------------------------------
Git v2.10.1 Release Notes
=========================
Fixes since v2.10
-----------------
* Clarify various ways to specify the "revision ranges" in the
documentation.
* "diff-highlight" script (in contrib/) learned to work better with
"git log -p --graph" output.
* The test framework left the number of tests and success/failure
count in the t/test-results directory, keyed by the name of the
test script plus the process ID. The latter however turned out not
to serve any useful purpose. The process ID part of the filename
has been removed.
* Having a submodule whose ".git" repository is somehow corrupt
caused a few commands that recurse into submodules loop forever.
* "git symbolic-ref -d HEAD" happily removes the symbolic ref, but
the resulting repository becomes an invalid one. Teach the command
to forbid removal of HEAD.
* A test spawned a short-lived background process, which sometimes
prevented the test directory from getting removed at the end of the
script on some platforms.
* Update a few tests that used to use GIT_CURL_VERBOSE to use the
newer GIT_TRACE_CURL.
* Update Japanese translation for "git-gui".
* "git fetch http::/site/path" did not die correctly and segfaulted
instead.
* "git commit-tree" stopped reading commit.gpgsign configuration
variable that was meant for Porcelain "git commit" in Git 2.9; we
forgot to update "git gui" to look at the configuration to match
this change.
* "git log --cherry-pick" used to include merge commits as candidates
to be matched up with other commits, resulting a lot of wasted time.
The patch-id generation logic has been updated to ignore merges to
avoid the wastage.
* The http transport (with curl-multi option, which is the default
these days) failed to remove curl-easy handle from a curlm session,
which led to unnecessary API failures.
* "git diff -W" output needs to extend the context backward to
include the header line of the current function and also forward to
include the body of the entire current function up to the header
line of the next one. This process may have to merge to adjacent
hunks, but the code forgot to do so in some cases.
* Performance tests done via "t/perf" did not use the same set of
build configuration if the user relied on autoconf generated
configuration.
* "git format-patch --base=..." feature that was recently added
showed the base commit information after "-- " e-mail signature
line, which turned out to be inconvenient. The base information
has been moved above the signature line.
* Even when "git pull --rebase=preserve" (and the underlying "git
rebase --preserve") can complete without creating any new commit
(i.e. fast-forwards), it still insisted on having a usable ident
information (read: user.email is set correctly), which was less
than nice. As the underlying commands used inside "git rebase"
would fail with a more meaningful error message and advice text
when the bogus ident matters, this extra check was removed.
* "git gc --aggressive" used to limit the delta-chain length to 250,
which is way too deep for gaining additional space savings and is
detrimental for runtime performance. The limit has been reduced to
50.
* Documentation for individual configuration variables to control use
of color (like `color.grep`) said that their default value is
'false', instead of saying their default is taken from `color.ui`.
When we updated the default value for color.ui from 'false' to
'auto' quite a while ago, all of them broke. This has been
corrected.
* A shell script example in check-ref-format documentation has been
fixed.
* "git checkout <word>" does not follow the usual disambiguation
rules when the <word> can be both a rev and a path, to allow
checking out a branch 'foo' in a project that happens to have a
file 'foo' in the working tree without having to disambiguate.
This was poorly documented and the check was incorrect when the
command was run from a subdirectory.
* Some codepaths in "git diff" used regexec(3) on a buffer that was
mmap(2)ed, which may not have a terminating NUL, leading to a read
beyond the end of the mapped region. This was fixed by introducing
a regexec_buf() helper that takes a <ptr,len> pair with REG_STARTEND
extension.
* The procedure to build Git on Mac OS X for Travis CI hardcoded the
internal directory structure we assumed HomeBrew uses, which was a
no-no. The procedure has been updated to ask HomeBrew things we
need to know to fix this.
* When "git rebase -i" is given a broken instruction, it told the
user to fix it with "--edit-todo", but didn't say what the step
after that was (i.e. "--continue").
* "git add --chmod=+x" added recently lacked documentation, which has
been corrected.
* "git add --chmod=+x <pathspec>" added recently only toggled the
executable bit for paths that are either new or modified. This has
been corrected to flip the executable bit for all paths that match
the given pathspec.
* "git pack-objects --include-tag" was taught that when we know that
we are sending an object C, we want a tag B that directly points at
C but also a tag A that points at the tag B. We used to miss the
intermediate tag B in some cases.
* Documentation around tools to import from CVS was fairly outdated.
* In the codepath that comes up with the hostname to be used in an
e-mail when the user didn't tell us, we looked at ai_canonname
field in struct addrinfo without making sure it is not NULL first.
Also contains minor documentation updates and code clean-ups.
----------------------------------------------------------------
Changes since v2.10.0 are as follows:
Alex Henrie (5):
am: put spaces around pipe in usage string
cat-file: put spaces around pipes in usage string
git-rebase--interactive: fix English grammar
git-merge-octopus: do not capitalize "octopus"
unpack-trees: do not capitalize "working"
Beat Bolli (1):
SubmittingPatches: use gitk's "Copy commit summary" format
Brandon Williams (1):
pathspec: remove unnecessary function prototypes
Brian Henderson (3):
diff-highlight: add some tests
diff-highlight: add failing test for handling --graph output
diff-highlight: add support for --graph output
Elia Pinto (5):
t5541-http-push-smart.sh: use the GIT_TRACE_CURL environment var
test-lib.sh: preserve GIT_TRACE_CURL from the environment
t5550-http-fetch-dumb.sh: use the GIT_TRACE_CURL environment var
t5551-http-fetch-smart.sh: use the GIT_TRACE_CURL environment var
git-check-ref-format.txt: fixup documentation
Eric Wong (3):
http: warn on curl_multi_add_handle failures
http: consolidate #ifdefs for curl_multi_remove_handle
http: always remove curl easy from curlm session on release
Jeff King (20):
rebase-interactive: drop early check for valid ident
gc: default aggressive depth to 50
test-lib: drop PID from test-results/*.count
diff-highlight: ignore test cruft
diff-highlight: add multi-byte tests
diff-highlight: avoid highlighting combined diffs
error_errno: use constant return similar to error()
color_parse_mem: initialize "struct color" temporary
t5305: move cleanup into test block
t5305: drop "dry-run" of unpack-objects
t5305: use "git -C"
t5305: simplify packname handling
pack-objects: walk tag chains for --include-tag
remote-curl: handle URLs without protocol
patch-ids: turn off rename detection
patch-ids: refuse to compute patch-id for merge commit
docs/cvsimport: prefer cvs-fast-export to parsecvs
docs/cvs-migration: update link to cvsps homepage
docs/cvs-migration: mention cvsimport caveats
ident: handle NULL ai_canonname
Jiang Xin (1):
l10n: zh_CN: fixed some typos for git 2.10.0
Johannes Schindelin (4):
git-gui: respect commit.gpgsign again
regex: -G<pattern> feeds a non NUL-terminated string to regexec() and fails
regex: add regexec_buf() that can work on a non NUL-terminated string
regex: use regexec_buf()
Johannes Sixt (4):
t9903: fix broken && chain
t6026-merge-attr: clean up background process at end of test case
t3700-add: create subdirectory gently
t3700-add: do not check working tree file mode without POSIXPERM
Josh Triplett (1):
format-patch: show base info before email signature
Junio C Hamano (6):
submodule: avoid auto-discovery in prepare_submodule_repo_env()
symbolic-ref -d: do not allow removal of HEAD
Prepare for 2.9.4
Start preparing for 2.10.1
Prepare for 2.10.1
Git 2.10.1
Kirill Smelkov (1):
t/perf/run: copy config.mak.autogen & friends to build area
Lars Schneider (1):
travis-ci: ask homebrew for its path instead of hardcoding it
Matthieu Moy (1):
Documentation/config: default for color.* is color.ui
Mike Ralphson (1):
vcs-svn/fast_export: fix timestamp fmt specifiers
Nguyễn Thái Ngọc Duy (3):
checkout: add some spaces between code and comment
checkout.txt: document a common case that ignores ambiguation rules
checkout: fix ambiguity check in subdir
Philip Oakley (12):
doc: use 'symmetric difference' consistently
doc: revisions - name the left and right sides
doc: show the actual left, right, and boundary marks
doc: revisions: give headings for the two and three dot notations
doc: revisions: extra clarification of <rev>^! notation effects
doc: revisions: single vs multi-parent notation comparison
doc: gitrevisions - use 'reachable' in page description
doc: gitrevisions - clarify 'latter case' is revision walk
doc: revisions - define `reachable`
doc: revisions - clarify reachability examples
doc: revisions: show revision expansion in examples
doc: revisions: sort examples and fix alignment of the unchanged
Ralf Thielow (1):
rebase -i: improve advice on bad instruction lines
Ray Chen (1):
l10n: zh_CN: review for git v2.10.0 l10n
René Scharfe (6):
compat: move strdup(3) replacement to its own file
introduce hex2chr() for converting two hexadecimal digits to a character
strbuf: use valid pointer in strbuf_remove()
checkout: constify parameters of checkout_stage() and checkout_merged()
unpack-trees: pass checkout state explicitly to check_updates()
xdiff: fix merging of hunks with -W context and -u context
Satoshi Yasushima (6):
git-gui: consistently use the same word for "remote" in Japanese
git-gui: consistently use the same word for "blame" in Japanese
git-gui: apply po template to Japanese translation
git-gui: add Japanese language code
git-gui: update Japanese translation
git-gui: update Japanese information
Stefan Beller (5):
xdiff: remove unneeded declarations
transport: report missing submodule pushes consistently on stderr
diff.c: use diff_options directly
diff: omit found pointer from emit_callback
diff: remove dead code
Thomas Gummerer (4):
add: document the chmod option
update-index: add test for chmod flags
read-cache: introduce chmod_index_entry
add: modify already added files when --chmod is given
Vasco Almeida (2):
l10n: pt_PT: update Portuguese translation
l10n: pt_PT: update Portuguese repository info
^ permalink raw reply
* Re: [PATCH 3/3] abbrev: auto size the default abbreviation
From: Jeff King @ 2016-10-03 22:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Linus Torvalds
In-Reply-To: <20161001001937.10884-4-gitster@pobox.com>
On Fri, Sep 30, 2016 at 05:19:37PM -0700, Junio C Hamano wrote:
> Introduce a mechanism, where we estimate the number of objects in
> the repository upon the first request to abbreviate an object name
> with the default setting and come up with a sane default for the
> repository. Based on the expectation that we would see collision in
> a repository with 2^(2N) objects when using object names shortened
> to first N bits, use sufficient number of hexdigits to cover the
> number of objects in the repository. Each hexdigit (4-bits) we add
> to the shortened name allows us to have four times (2-bits) as many
> objects in the repository.
>
> ---
> cache.h | 1 +
> environment.c | 2 +-
> sha1_name.c | 28 +++++++++++++++++++++++++++-
> 3 files changed, 29 insertions(+), 2 deletions(-)
For reference, here's a working version that just uses a separate
counting function (no commit message, because I would just steal the one
from Linus ;) ).
---
cache.h | 6 ++++++
environment.c | 2 +-
sha1_file.c | 27 +++++++++++++++++++++++++++
sha1_name.c | 20 ++++++++++++++++++++
4 files changed, 54 insertions(+), 1 deletion(-)
diff --git a/cache.h b/cache.h
index 5a651b8..f22ace5 100644
--- a/cache.h
+++ b/cache.h
@@ -1455,6 +1455,12 @@ extern void prepare_packed_git(void);
extern void reprepare_packed_git(void);
extern void install_packed_git(struct packed_git *pack);
+/*
+ * Give a rough count of objects in the repository. This sacrifices accuracy
+ * for speed.
+ */
+unsigned long approximate_object_count(void);
+
extern struct packed_git *find_sha1_pack(const unsigned char *sha1,
struct packed_git *packs);
diff --git a/environment.c b/environment.c
index 44fb107..6f9d290 100644
--- a/environment.c
+++ b/environment.c
@@ -16,7 +16,7 @@ int trust_executable_bit = 1;
int trust_ctime = 1;
int check_stat = 1;
int has_symlinks = 1;
-int minimum_abbrev = 4, default_abbrev = FALLBACK_DEFAULT_ABBREV;
+int minimum_abbrev = 4, default_abbrev = -1;
int ignore_case;
int assume_unchanged;
int prefer_symlink_refs;
diff --git a/sha1_file.c b/sha1_file.c
index b9c1fa3..4882440 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -1381,6 +1381,32 @@ static void prepare_packed_git_one(char *objdir, int local)
strbuf_release(&path);
}
+static int approximate_object_count_valid;
+
+/*
+ * Give a fast, rough count of the number of objects in the repository. This
+ * ignores loose objects completely. If you have a lot of them, then either
+ * you should repack because your performance will be awful, or they are
+ * all unreachable objects about to be pruned, in which case they're not really
+ * interesting as a measure of repo size in the first place.
+ */
+unsigned long approximate_object_count(void)
+{
+ static unsigned long count;
+ if (!approximate_object_count_valid) {
+ struct packed_git *p;
+
+ prepare_packed_git();
+ count = 0;
+ for (p = packed_git; p; p = p->next) {
+ if (open_pack_index(p))
+ continue;
+ count += p->num_objects;
+ }
+ }
+ return count;
+}
+
static void *get_next_packed_git(const void *p)
{
return ((const struct packed_git *)p)->next;
@@ -1455,6 +1481,7 @@ void prepare_packed_git(void)
void reprepare_packed_git(void)
{
+ approximate_object_count_valid = 0;
prepare_packed_git_run_once = 0;
prepare_packed_git();
}
diff --git a/sha1_name.c b/sha1_name.c
index 3b647fd..ecc4b54 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -455,10 +455,30 @@ int for_each_abbrev(const char *prefix, each_abbrev_fn fn, void *cb_data)
return ret;
}
+/*
+ * Return the slot of the most-significant bit set in "val". There are various
+ * ways to do this quickly with fls() or __builtin_clzl(), but speed is
+ * probably not a big deal here.
+ */
+unsigned msb(unsigned long val)
+{
+ unsigned r = 0;
+ while (val >>= 1)
+ r++;
+ return r;
+}
+
int find_unique_abbrev_r(char *hex, const unsigned char *sha1, int len)
{
int status, exists;
+ if (len < 0) {
+ unsigned long count = approximate_object_count();
+ len = (msb(count) + 1) / 2;
+ if (len < 0)
+ len = FALLBACK_DEFAULT_ABBREV;
+ }
+
sha1_to_hex_r(hex, sha1);
if (len == 40 || !len)
return 40;
--
2.10.0.618.g82cc264
^ permalink raw reply related
* RE: [PATCH] http: http.emptyauth should allow empty (not just NULL) usernames
From: David Turner @ 2016-10-03 22:26 UTC (permalink / raw)
To: 'Jeff King'; +Cc: git@vger.kernel.org, sandals@crustytoothpaste.net
In-Reply-To: <20161003215840.6ihqjtplkcsporiw@sigill.intra.peff.net>
> -----Original Message-----
> From: Jeff King [mailto:peff@peff.net]
> Sent: Monday, October 03, 2016 5:59 PM
> To: David Turner
> Cc: git@vger.kernel.org; sandals@crustytoothpaste.net
> Subject: Re: [PATCH] http: http.emptyauth should allow empty (not just
> NULL) usernames
>
> On Mon, Oct 03, 2016 at 09:54:19PM +0000, David Turner wrote:
>
> > > I dunno. The code path you are changing _only_ affects anything if
> > > the http.emptyauth config is set. But I guess I just don't
> > > understand why you would say "http://@gitserver" in the first place.
> Is that a common thing?
> >
> > I have no idea if it is common. I know that we do it.
>
> I guess my question is: _why_ do you do it? Or more specifically, does
> http://gitserver.example.com" with http.emptyauth not work, and why?
>
> From your response, I _think_ the answer is "no, it doesn't, and I have no
> clue why".
That was true historically.
I just tried our old version of git 2.8 (that is, before this patch, and before the libcurl upgrade), and http://gitserver.example.com *does* seem to work with http.emptyauth (and does not work without). However, http://@gitserver.example.com does *not* work with http.emptyauth, and *does* work without.
After the libcurl upgrade, but before this patch, http://@gitserver.example.com does *not* work with http.emptyauth, while http://gitserver.example.com does.
And finally, after the upgrade and with this patch, both urls work.
> So I dunno. It is annoying not to know what is actually going on, but I'm
> OK with it if we don't think there's a high chance of regressing any other
> workflows (which I guess not, because http.emptyauth seems to be a
> Kerberos-specific hack in the first place).
Yes, I think this is all Kerberos-only.
^ permalink raw reply
* Re: What's cooking in git.git (Sep 2016, #08; Tue, 27)
From: Stefan Beller @ 2016-10-03 22:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git@vger.kernel.org
In-Reply-To: <xmqqh98t5c69.fsf@gitster.mtv.corp.google.com>
On Mon, Oct 3, 2016 at 2:56 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Stefan Beller <sbeller@google.com> writes:
>
>> // Note: git_attr_check_elem seems to be useless now, as the
>> // results are not stored in there, we only make use of the `attr` key.
>
> I do not think git_attr_check_elem would be visible to the callers,
> once we split the "inquiry" and "result" like the code illustrated
> above. I actually doubt that the type would even internally need to
> survive such a rewrite.
So how would we go about git_all_attrs then?
I think those (only builtin/check-attr.c as well as Documentation) would
need to read these names off of git_attr_check_elem.
So instead we could do a
int git_all_attrs(const char *path, char *result_keys[], char *result_values[],
int nr, int alloc)
Internally git_all_attrs would use nr/alloc to resize result_{key,value} to an
appropriate size and then fill it with keys/values.
Although I do not think check-attr needs to be fast as it is a debugging
tool rather than a daily used tool, but it would fit into the current
line of thinking?
>
> The point of "future-proofing" the callers is to hide such
> implementation details from them. We know that the current API will
> need to be updated at least once to prepare the implementation of
> the API so that it has some chance of becoming thread-safe, and I
> think we know enough how the updated API should look like to the
> callers.
I don't think we have the same idea how it should look like, as e.g.
it is unclear what we do with the `const struct git_attr` in the
git_attr_check to me.
> I was hoping the minimum future-proofing would allow us to
> update the current "attr" API users only once, without having to
> update them again when we make it ready to be used in threaded
> environment.
Ok, so let's first define how the future proofed API should look like
and then we can go towards it.
^ permalink raw reply
* Re: [RFC/PATCH 0/2] place cherry pick line below commit title
From: Junio C Hamano @ 2016-10-03 22:13 UTC (permalink / raw)
To: Jonathan Tan; +Cc: git, Christian Couder
In-Reply-To: <d3df0636-1975-1d08-2f34-384984c72e5d@google.com>
Jonathan Tan <jonathantanmy@google.com> writes:
> There are other options like checking for indentation or checking for
> balanced parentheses/brackets, but I think that these would lead to
> surprising behavior for the user (this would mean that whitespace or
> certain characters could turn a valid trailer into an invalid one or
> vice versa, or change the behavior of trailer.ifexists, especially
> "replace").
Yes, that is exactly why I said that it may be necessary for the
code to analize the lines in a block identified as "likely to be a
trailing block" more carefully. We can afford to be loose as long
as the only allowed operation is to append one at the end, but once
we start removing/replacing an existing entry, etc., the definition
of what an entry is becomes very much relevant.
^ permalink raw reply
* Re: Slow pushes on 'pu' - even when up-to-date..
From: Junio C Hamano @ 2016-10-03 22:06 UTC (permalink / raw)
To: Stefan Beller; +Cc: Linus Torvalds, Heiko Voigt, Git Mailing List
In-Reply-To: <CAGZ79kY6FpTD1VJQ=+wJ0FrXe9LjJ=NBwLsOku0R4FerAmQGJQ@mail.gmail.com>
Stefan Beller <sbeller@google.com> writes:
> On Mon, Oct 3, 2016 at 2:17 PM, Stefan Beller <sbeller@google.com> wrote:
>>
>> * sb/push-make-submodule-check-the-default (2016-08-24) 1 commit
>> - push: change submodule default to check
>>
>> Turn the default of "push.recurseSubmodules" to "check".
>>
>> Will hold to wait for hv/submodule-not-yet-pushed-fix
>>
>> This reveals that the "check" mode is too inefficient to use in
>> real projects, even in ones as small as git itself.
>> cf. <xmqqh9aaot49.fsf@gitster.mtv.corp.google.com>
>
> So maybe we should eject this series from pu as long as
> hv/submodule-not-yet-pushed-fix is ejected to enable you
> running pu happily.
I am planning to merge lt/abbrev-auto to 'next' together with Peff's
ambiguous-short-object-names series in today's pushout.
Just FYI, there is another integration branch called 'jch' that
typically has several topics more than 'next' but does not merge
things I haven't looked at (or things I have looked at and decided
not ready). That is what I use for my daily work. You can grab it
out of "git log --oneline --first-parent master..pu", or from my
broken-out repository (git://github.com/gitster/git/).
^ permalink raw reply
* Re: [PATCH 1/3] add QSORT
From: René Scharfe @ 2016-10-03 22:00 UTC (permalink / raw)
To: Kevin Bracey, GIT Mailing-list
In-Reply-To: <57F290DC.5080303@bracey.fi>
Am 03.10.2016 um 19:09 schrieb Kevin Bracey:
> As such, NULL checks can still be elided even with your change. If you
> effectively change your example to:
>
> if (nmemb > 1)
> qsort(array, nmemb, size, cmp);
> if (!array)
> printf("array is NULL\n");
>
> array may only be checked for NULL if nmemb <= 1. You can see GCC doing
> that in the compiler explorer - it effectively turns that into "else
> if".
We don't support array == NULL together with nmemb > 1, so a segfault is
to be expected in such cases, and thus NULL checks can be removed safely.
> To make that check really work, you have to do:
>
> if (array)
> qsort(array, nmemb, size, cmp);
> else
> printf("array is NULL\n");
>
> So maybe your "sane_qsort" should be checking array, not nmemb.
It would be safe, but arguably too much so, because non-empty arrays
with NULL wouldn't segfault anymore, and thus become harder to identify
as the programming errors they are.
The intention is to support NULL pointers only for empty arrays (in
addition to valid pointers). That we also support NULL pointers for
arrays with a single member might be considered to be the result of a
premature optimization, but it should be safe -- the compiler won't
remove checks unexpectedly.
Does that make sense (it's getting late here, so my logic might already
be resting..)?
René
^ permalink raw reply
* Re: [PATCH] http: http.emptyauth should allow empty (not just NULL) usernames
From: Jeff King @ 2016-10-03 21:58 UTC (permalink / raw)
To: David Turner; +Cc: git@vger.kernel.org, sandals@crustytoothpaste.net
In-Reply-To: <335996ca2642478386e94d9f3dc43223@exmbdft7.ad.twosigma.com>
On Mon, Oct 03, 2016 at 09:54:19PM +0000, David Turner wrote:
> > I dunno. The code path you are changing _only_ affects anything if the
> > http.emptyauth config is set. But I guess I just don't understand why you
> > would say "http://@gitserver" in the first place. Is that a common thing?
>
> I have no idea if it is common. I know that we do it.
I guess my question is: _why_ do you do it? Or more specifically, does
http://gitserver.example.com" with http.emptyauth not work, and why?
From your response, I _think_ the answer is "no, it doesn't, and I have
no clue why".
So I dunno. It is annoying not to know what is actually going on, but
I'm OK with it if we don't think there's a high chance of regressing any
other workflows (which I guess not, because http.emptyauth seems to be a
Kerberos-specific hack in the first place).
-Peff
^ permalink raw reply
* Re: What's cooking in git.git (Sep 2016, #08; Tue, 27)
From: Junio C Hamano @ 2016-10-03 21:56 UTC (permalink / raw)
To: Stefan Beller; +Cc: git@vger.kernel.org
In-Reply-To: <CAGZ79kYt+Z=ff1b2G+wWRAGGS=je+dpksfmMXj0fWwYVvHk8Cg@mail.gmail.com>
Stefan Beller <sbeller@google.com> writes:
> // Note: git_attr_check_elem seems to be useless now, as the
> // results are not stored in there, we only make use of the `attr` key.
I do not think git_attr_check_elem would be visible to the callers,
once we split the "inquiry" and "result" like the code illustrated
above. I actually doubt that the type would even internally need to
survive such a rewrite.
The point of "future-proofing" the callers is to hide such
implementation details from them. We know that the current API will
need to be updated at least once to prepare the implementation of
the API so that it has some chance of becoming thread-safe, and I
think we know enough how the updated API should look like to the
callers. I was hoping the minimum future-proofing would allow us to
update the current "attr" API users only once, without having to
update them again when we make it ready to be used in threaded
environment.
^ permalink raw reply
* RE: [PATCH] http: http.emptyauth should allow empty (not just NULL) usernames
From: David Turner @ 2016-10-03 21:54 UTC (permalink / raw)
To: 'Jeff King'; +Cc: git@vger.kernel.org, sandals@crustytoothpaste.net
In-Reply-To: <20161003210100.t5nqknwfotag3lmj@sigill.intra.peff.net>
> -----Original Message-----
> From: Jeff King [mailto:peff@peff.net]
> Sent: Monday, October 03, 2016 5:01 PM
> To: David Turner
> Cc: git@vger.kernel.org; sandals@crustytoothpaste.net
> Subject: Re: [PATCH] http: http.emptyauth should allow empty (not just
> NULL) usernames
>
> On Mon, Oct 03, 2016 at 01:19:28PM -0400, David Turner wrote:
>
> > When using kerberos authentication, one URL pattern which is allowed
> > is http://@gitserver.example.com. This leads to a username of
> > zero-length, rather than a NULL username. But the two cases should be
> > treated the same by http.emptyauth.
> >
> > Signed-off-by: David Turner <dturner@twosigma.com>
> > ---
> > http.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/http.c b/http.c
> > index 82ed542..bd0dba2 100644
> > --- a/http.c
> > +++ b/http.c
> > @@ -351,7 +351,7 @@ static int http_options(const char *var, const
> > char *value, void *cb)
> >
> > static void init_curl_http_auth(CURL *result) {
> > - if (!http_auth.username) {
> > + if (!http_auth.username || !*http_auth.username) {
>
> Hmm. This fixes this caller, but what about other users of the credential
> struct? I wonder if the correct fix is in credential_from_url(), which
> should avoid writing an empty field.
>
> OTOH, I can imagine that "http://user:@example.com" would be a way to say
> "I have a username and the password is blank" without getting prompted.
> Which makes me wonder if it is useful to say "my username is blank" in the
> same way.
Yes, that was my thought process.
> I dunno. The code path you are changing _only_ affects anything if the
> http.emptyauth config is set. But I guess I just don't understand why you
> would say "http://@gitserver" in the first place. Is that a common thing?
>
> -Peff
I have no idea if it is common. I know that we do it.
It used to be that git 2.8/libcurl would handle @gitserver as if the username were blank, but then we upgraded our company's libcurl and it broke (git started prompting for a password). I do not know what the previous version of libcurl was.
The reason we have a required-to-be-blank username/password is apparently Kerberos (or something about our particular Kerberos configuration), which I treat as inscrutable black magic.
^ 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