[PATCH 0/3] hash-object crash fix and new doc and tests
This patch series fixes a buffer overrun triggered by an extra-long bogus object type specified via hash-object --literally. It also adds documentation and tests which were missing from the initial series which introduced hash-object --literally. Eric Sunshine (3): git-hash-object.txt: document --literally option t1007: add hash-object --literally tests write_sha1_file_prepare: fix buffer overrun with extra-long object type Documentation/git-hash-object.txt | 10 -- sha1_file.c | 21 ++--- t/t1007-hash-object.sh| 11 +++ 3 files changed, 29 insertions(+), 13 deletions(-) -- 2.4.0.319.g7a04823 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Fixed a translation error
Signed-off-by: Alangi Derick alangider...@gmail.com
---
builtin/config.c | 34 +-
1 file changed, 17 insertions(+), 17 deletions(-)
diff --git a/builtin/config.c b/builtin/config.c
index d32c532..2b6bf0a 100644
--- a/builtin/config.c
+++ b/builtin/config.c
@@ -85,7 +85,7 @@ static struct option builtin_config_options[] = {
static void check_argc(int argc, int min, int max) {
if (argc = min argc = max)
return;
- error(wrong number of arguments);
+ error(_(wrong number of arguments));
usage_with_options(builtin_config_usage, builtin_config_options);
}
@@ -366,10 +366,10 @@ static int get_colorbool(const char *var, int print)
static void check_write(void)
{
if (given_config_source.use_stdin)
- die(writing to stdin is not supported);
+ die(_(writing to stdin is not supported));
if (given_config_source.blob)
- die(writing config blobs is not supported);
+ die(_(writing config blobs is not supported));
}
struct urlmatch_current_candidate_value {
@@ -412,7 +412,7 @@ static int get_urlmatch(const char *var, const char *url)
config.cb = values;
if (!url_normalize(url, config.url))
- die(%s, config.url.err);
+ die(_(%s), config.url.err);
config.section = xstrdup_tolower(var);
section_tail = strchr(config.section, '.');
@@ -477,7 +477,7 @@ int cmd_config(int argc, const char **argv, const char
*prefix)
if (use_global_config + use_system_config + use_local_config +
!!given_config_source.file + !!given_config_source.blob 1) {
- error(only one config file at a time.);
+ error(_(only one config file at a time.));
usage_with_options(builtin_config_usage,
builtin_config_options);
}
@@ -500,7 +500,7 @@ int cmd_config(int argc, const char **argv, const char
*prefix)
* location; error out even if XDG_CONFIG_HOME
* is set and points at a sane location.
*/
- die($HOME not set);
+ die(_($HOME not set));
if (access_or_warn(user_config, R_OK, 0)
xdg_config !access_or_warn(xdg_config, R_OK, 0))
@@ -530,17 +530,17 @@ int cmd_config(int argc, const char **argv, const char
*prefix)
}
if (HAS_MULTI_BITS(types)) {
- error(only one type at a time.);
+ error(_(only one type at a time.));
usage_with_options(builtin_config_usage,
builtin_config_options);
}
if ((actions (ACTION_GET_COLOR|ACTION_GET_COLORBOOL)) types) {
- error(--get-color and variable type are incoherent);
+ error(_(--get-color and variable type are incoherent));
usage_with_options(builtin_config_usage,
builtin_config_options);
}
if (HAS_MULTI_BITS(actions)) {
- error(only one action at a time.);
+ error(_(only one action at a time.));
usage_with_options(builtin_config_usage,
builtin_config_options);
}
if (actions == 0)
@@ -561,7 +561,7 @@ int cmd_config(int argc, const char **argv, const char
*prefix)
die_errno(unable to read config file '%s',
given_config_source.file);
else
- die(error processing config file(s));
+ die(_(error processing config file(s)));
}
}
else if (actions == ACTION_EDIT) {
@@ -569,11 +569,11 @@ int cmd_config(int argc, const char **argv, const char
*prefix)
check_argc(argc, 0, 0);
if (!given_config_source.file nongit)
- die(not in a git directory);
+ die(_(not in a git directory));
if (given_config_source.use_stdin)
- die(editing stdin is not supported);
+ die(_(editing stdin is not supported));
if (given_config_source.blob)
- die(editing blobs is not supported);
+ die(_(editing blobs is not supported));
git_config(git_default_config, NULL);
config_file = xstrdup(given_config_source.file ?
given_config_source.file :
git_path(config));
@@ -598,8 +598,8 @@ int cmd_config(int argc, const char **argv, const char
*prefix)
value = normalize_value(argv[0], argv[1]);
ret = git_config_set_in_file(given_config_source.file, argv[0],
value);
if (ret == CONFIG_NOTHING_SET)
- error(cannot overwrite multiple values with a single
value\n
- Use a regexp,
[PATCH] clean: describe --dry-run option in a more clear way in the usage string
Signed-off-by: Alexander Kuleshov kuleshovm...@gmail.com
---
builtin/clean.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/clean.c b/builtin/clean.c
index 17a1c13..01aae96 100644
--- a/builtin/clean.c
+++ b/builtin/clean.c
@@ -891,7 +891,7 @@ int cmd_clean(int argc, const char **argv, const char
*prefix)
const char *qname;
struct option options[] = {
OPT__QUIET(quiet, N_(do not print names of files removed)),
- OPT__DRY_RUN(dry_run, N_(dry run)),
+ OPT__DRY_RUN(dry_run, N_(do not remove anything, only show
what would be removed)),
OPT__FORCE(force, N_(force)),
OPT_BOOL('i', interactive, interactive, N_(interactive
cleaning)),
OPT_BOOL('d', NULL, remove_directories,
--
2.4.0.dirty
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] lock_packed_refs(): allow retries when acquiring the packed-refs lock
On Fri, May 1, 2015 at 10:19 PM, Michael Haggerty mhag...@alum.mit.edu wrote:
On 05/01/2015 08:22 PM, Jeff King wrote:
On Fri, May 01, 2015 at 10:51:47AM -0700, Stefan Beller wrote:
diff --git a/refs.c b/refs.c
index 47e4e53..3f8ac63 100644
--- a/refs.c
+++ b/refs.c
@@ -2413,9 +2413,19 @@ static int write_packed_entry_fn(struct ref_entry
*entry, void *cb_data)
/* This should return a meaningful errno on failure */
int lock_packed_refs(int flags)
{
+ static int timeout_configured = 0;
+ static int timeout_value = 1000;
I'd personally be more happier with a default value of 100 ms or less
The reason is found in the human nature, as humans tend to perceive
anything faster than 100ms as instant[1], while a 100ms is a long time
for computers.
Now a small default time may lead to to little retries, so maybe it's worth
checking at the very end of the time again (ignoring the computed backoff
times). As pushes to $server usually take a while (connecting, packing
packs,
writing objects etc), this may be overcautios bikeshedding from my side.
Keep in mind that this 1s is the maximum time to wait. The
lock_file_timeout() code from patch 1 starts off at 1ms, grows
quadratically, and quits as soon as it succeeds. So in most cases, the
user will wait a much smaller amount of time.
Yes, I forgot about that when having an opinion. I agree a one second
time out is reasonable.
The current code would poll at the following times (in ms), ignoring the
time taken for the actual polling attempt and ignoring the random component:
time backoff percent
--- ---
01 N/A
14 400%
59 180%
14 16 114%
30 25 83%
55 36 65%
91 49 54%
140 64 46%
204 81 40%
285 100 35%
385 121 31%
506 144 28%
650 169 26%
819 196 24%
1015 225 22% - Stop here with the default 1 s timeout
So a configuration of one second only has about twice the attempts
than a 100ms configuration in the worst case, which is nice for the
machine load, and as I said above, not too long for the user.
Thanks for laying out the numbers here, it's more
understandable now.
1240 256 21%
1496 289 19%
1785 324 18%
2109 361 17%
2470 400 16%
2870 441 15%
3311 484 15%
3795 529 14%
4324 576 13%
4900 625 13%
5525 676 12%
6201 729 12%
6930 784 11%
7714 841 11%
8555 900 11%
9455 961 10%
10416 1000 10%
11416 1000 9%
12416 1000 8%
From the table, the first backoff that is longer than 100 ms doesn't
start until 385 ms, and in the worst case, that 121 ms delay would
increase the *total* wait by only 31%. And the longest backoff within
the first second is only 196 ms. The backoff doesn't reach its maximum
value, 1 s, until the process has already been blocked for 10.4 seconds.
Remember, these backoffs are the *maximum* time that the user might wait
between the time that one process is finished and the time that the
second process resumes. The *average* wait time will be half of that.
And finally, remember that lock contention should be very rare in the
first place, and will mostly occur on servers (because normal users are
unlikely to have lots of parallel processes accessing a single git
repository). What are the most likely scenarios for lock contention in
the real world?
* Occasionally, by chance, under normal operations. In most cases, the
blocking process will finish up within a few milliseconds, the blocked
process will resume almost immediately, and nobody will notice a thing.
* In a pathological repository that has, say, a million packed
references, and writing the packed-refs file takes unusually long. Here,
typical lock contention delays will be long anyway, and adding (worst
case) 121 ms == 31% to the delay is not unreasonable.
* When the server is struggling with enormous load, or a
denial-of-service attack, or some other system-wide problem that is
making processes super slow. In this case it would be counterproductive
to have *additional* processes waking up every 100 ms.
* When a packed-refs.lock file fails to get cleaned up for some reason.
In this case the contention will never go away on its own, so the
polling is wasted effort. (Happily, I've almost never seen this happen
on our servers.)
It would be trivial to increase or decrease the maximum backoff. But I
think the current value is a reasonable compromise.
Michael
--
Michael Haggerty
mhag...@alum.mit.edu
--
To unsubscribe from this list: send the line unsubscribe git in
Re: Diffing submodule does not yield complete logs for merge commits
Am 04.05.2015 um 17:05 schrieb Robert Dailey: On Fri, May 1, 2015 at 12:57 PM, Heiko Voigt hvo...@hvoigt.net wrote: Hi, On Wed, Apr 29, 2015 at 03:53:11PM -0500, Robert Dailey wrote: I am attempting to diff a submodule modified in my working copy and the only difference is a merge commit. However, I do not get the full range of commits introduced by the merge commit when I diff it: $ git diff --submodule=log Core Submodule Core 8b4ec60..def2f3b: Merge remote-tracking branch 'origin/master-ah3k' However if I go inside my submodule and run `git log` by hand, I get more information about the TRUE commits introduced: $ git log --oneline 8b4ec60..def2f3b def2f3b Merge remote-tracking branch 'origin/master-ah3k' 015c961 Remove log spam in FontManager 7713ba1 Update third party submodule to latest 10aac78 Merge pull request #9 in FE/core from feature/FE-1348-selecting-continue-on-zero-balance to master-ah3k 287882f FE-1376 Nedd to remain in check detail screen when selecting donation after SBI a5a6bed Do not overwrite the current check# within loop dfb8547 Adding list of checks to CRspChecks before saving 1be280a FE-1354: Guest logged out in specific multiple check scenario de06d5a [FE-1348] Fix PATT exit while checks still open It's almost as if the `git diff --submodule=log` approach is passing in --first-parent to git log, which would exclude commits in the range that I'm seeing when I run git log manually. That is exactly the case. In prepare_submodule_summary() that option is set before doing the revision walk. Is this by design? Is there a way to enable the full log history with `git diff` on a submodule? This stems from the first implementation for showing submodule diffs in commit 752c0c24. I guess this was done deliberately to limit the amount of output you get for a submodule. At the moment this is hardcoded but I think there is nothing wrong with adding another option to include the full log. Cheers Heiko I will go ahead and work on this feature. Here is what I'd like to see: 1. `git diff --submodule` should have the ability to display full logs vs current logs (i.e. without --first-parent) I agree. Just recently I started missing that feature too at $DAYJOB. 2. `git submodule summary` should have an option to display full logs or first-parent logs. No objection against that. Maybe now is a good time to make `git submodule summary` use `git diff --submodule` internally to make them behave the same? For #1, do you recommend adding a 3rd setting for `diff.submodule` config? Something like full-log or something? Or an entirely new config? I'd go with a 3rd setting for diff.submodule (and full-log would have been my first choice too ;-). I noticed that in diff.h, the DIFF_OPT flags already consume 31 bits. If this is a 32-bit flag, there is only 1 bit left. If we go with a 3rd setting for `diff.submodule` I think this might consume the last bit. Yup. But I'm not sure we can do anything about it. We could also make `git diff --submodule` default to the full log type, and if users want only first parent logs in submodule summary, they'd have to execute `git submodule summary` instead. Please do not change defaults that people lived fine with for years lightly. But I won't object changing that on a major version if a majority of users request that. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: forcing a user@ into the URL if not present
On Thu, Apr 30, 2015 at 4:23 PM, brian m. carlson sand...@crustytoothpaste.net wrote: On Thu, Apr 30, 2015 at 04:14:12PM -0400, Dan Langille wrote: Would this question be better suited for another list? Nope, this is the place to go. On Wed, Apr 22, 2015 at 4:06 PM, Dan Langille dlangi...@sourcefire.com wrote: Hello, I'm using git 2.3.2 with Kerberos for authentication and gito-lite for authorization. This works: $ git clone https://dvl@ repo.example.org/git/testing Cloning into 'testing'... warning: You appear to have cloned an empty repository. Checking connectivity... done. My goal: have it work without supplying dvl@ as shown here: $ git clone https://repo.example.org/git/testing Cloning into 'testing'... Username for 'https://repo.example.org': I don't want to be prompted for a password. I want Kerberos to kick in. Following http://git-scm.com/docs/gitcredentials, the following seems to have nil effect. Anyone used this feature already? git config --global credential.https://repo.example.org.username dvl $ cat ~/.gitconfig [credential https://repo.example.org;] username = dvl [http] sslCAInfo = /usr/local/etc/trusted-certificates.pem With the above, I still get prompted for a password Given my use of Kerberos for authorization, is this option feasible? Not at the present time. The only time that the credential API is invoked is if it prompts for a password, and by that point you've fallen back to Basic authentication. Should I be taking a different approach? If you want it to work only with Kerberos, then any username in the URL is fine, as libcurl doesn't care. That is what I found during testing. So long as I put a username in the URL, Kerberos worked and all authentication occurred as expected. One thing you could try is to make your URL https://g...@repo.example.org and then use git config --global credential.https://g...@repo.example.org.username dvl and see if it does the right thing for both Kerberos and Basic auth. It would be sort of a hack, but it might work. It asks for a password, and for the correct user: Password for 'https://d...@repo.example.org': Thanks Brian, for this, and your other help. I appreciate it. -- Dan Langille Infrastructure Operations Talos Group Sourcefire, Inc. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] contrib/subtree: fix linefeeds trimming for cmd_split()
Danny Lin danny0...@gmail.com writes: From dc549b6b4ec36f8faf9c6f7bb1e343ef7babd14f Mon Sep 17 00:00:00 2001 From: Danny Lin danny0...@gmail.com Date: Mon, 4 May 2015 14:09:38 +0800 Subject: [PATCH] contrib/subtree: fix linefeeds trimming for cmd_split() Please do not use multipart/mixed attachments, but instead inline your patch. When doing so, please drop all these four lines above. cmd_split() prints the info message using say -n, which makes no sense and could cause the linefeed be trimmed in some cases. This patch fixes the issue. I think this was written knowing that say is merely a thin wrapper of echo (which is a bad manner but happens to be correct) and assuming that everybody's echo understands -n (which is not a good assumption) to implement progress display that shows the N out of M done output over and over on the same physical line. So,... contrary to your makes no sense claim, what it tries to do makes perfect sense to me, even though its execution seems somewhat poor. --- contrib/subtree/git-subtree.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/contrib/subtree/git-subtree.sh b/contrib/subtree/git-subtree.sh index fa1a583..28a1377 100755 --- a/contrib/subtree/git-subtree.sh +++ b/contrib/subtree/git-subtree.sh @@ -599,7 +599,7 @@ cmd_split() eval $grl | while read rev parents; do revcount=$(($revcount + 1)) - say -n $revcount/$revmax ($createcount) + say $revcount/$revmax ($createcount) debug Processing commit: $rev exists=$(cache_get $rev) if [ -n $exists ]; then -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Fixed a translation error
Jonathan Nieder jrnie...@gmail.com writes:
While we're here, start the error messages with a lowercase letter to
match the usual typography of error messages.
A quick web search and a code search at codesearch.debian.net finds no
scripts trying to parse these error messages, so this change should be
safe.
Very well thought through and nicely written.
I am tempted to pick this patch up and queue it on its own. Alengi,
if you want to add _() markings to this file, perhaps it is a good
idea to base your patch relative to (i.e. on top of) Jonathan's
patch.
Thanks.
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
builtin/config.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/builtin/config.c b/builtin/config.c
index d32c532..89f3208 100644
--- a/builtin/config.c
+++ b/builtin/config.c
@@ -193,7 +193,7 @@ static int get_value(const char *key_, const char *regex_)
key_regexp = (regex_t*)xmalloc(sizeof(regex_t));
if (regcomp(key_regexp, key, REG_EXTENDED)) {
- fprintf(stderr, Invalid key pattern: %s\n, key_);
+ error(invalid key pattern: %s, key_);
free(key_regexp);
key_regexp = NULL;
ret = CONFIG_INVALID_PATTERN;
@@ -214,7 +214,7 @@ static int get_value(const char *key_, const char *regex_)
regexp = (regex_t*)xmalloc(sizeof(regex_t));
if (regcomp(regexp, regex_, REG_EXTENDED)) {
- fprintf(stderr, Invalid pattern: %s\n, regex_);
+ error(invalid pattern: %s, regex_);
free(regexp);
regexp = NULL;
ret = CONFIG_INVALID_PATTERN;
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
