Re: bash completion with 2.18.0/maint: unknown options
Hello Jeff, thanks for your answer. You are right: I have forgotten to run 'make install'. After doing so the completion works again. type git reports /usr/local/bin/git Regards Дилян On Sat, 2018-07-14 at 17:24 -0400, Jeff King wrote: > On Sat, Jul 14, 2018 at 02:46:17PM +0000, Дилян Палаузов wrote: > > > After upgrading to 2.18 the completion does not work: > > > > typing "git de" prints > > my@host:~$ git deUnknown option: --list-cmds=list- > > mainporcelain,others,nohelpers,alias,list-complete,config > > usage: git [--version] [--help] [-C ] [-c name=value] > > [...] > > In v2.18, the completions are generated programatically using new > options added to the git binary. The completion and the git binary > you're using have to be upgraded in lockstep (this has always been the > case, though I think this is probably the case where not doing so would > have the biggest effect). > > Are you sure the git binary you're running matches the completion? > > You mentioned that you're sourcing the completion from a clone in > /git/git. What does `type git` report? > > -Peff
bash completion with 2.18.0/maint: unknown options
Hello,
in /git/git I have v2.18.0 and in ~/.bashrc :
export
PS1='${debian_chroot:+($debian_chroot)}\[\e[01;32m\]\u@\h\[\e[00m\]:\[\
e[
01;34m\]\w\[\e[36m\]$(__git_ps1 " %s")\$ \[\e[0m\]'
source /git/git/contrib/completion/git-completion.bash
source /git/git/contrib/completion/git-prompt.sh
After upgrading to 2.18 the completion does not work:
typing "git de" prints
my@host:~$ git deUnknown option: --list-cmds=list-
mainporcelain,others,nohelpers,alias,list-complete,config
usage: git [--version] [--help] [-C ] [-c name=value]
[--exec-path[=]] [--html-path] [--man-path] [--info-
path]
[-p | --paginate | --no-pager] [--no-replace-objects] [
--bare]
[--git-dir=] [--work-tree=] [--namespace=]
[]
l.txt
with l.txt being part of a file called "del.txt"
or typing "git reb" I expect to have rebase, but I see
my@myhost:~$ git rebUnknown option: --list-cmds=list-
mainporcelain,others,nohelpers,alias,list-complete,config
usage: git [--version] [--help] [-C ] [-c name=value]
[--exec-path[=]] [--html-path] [--man-path] [--info-
path]
[-p | --paginate | --no-pager] [--no-replace-objects] [
--bare]
[--git-dir=] [--work-tree=] [--namespace=]
[]
Ideas?
Doing in git/git/ "git checkout v2.17." followed by 'source
/git/git/contrib/completion/git-comletion.bash" does help (makes the
completion functioning).
In the likely case this is fixed by now on master, please backport the
fix soon to the maint branch.
Greetings
Дилят
Re: Worktree silently deleted on git fetch/gc/log
Hello Duy, thanks for your answer. Your assumption is correct: when renaming the directory apparently I have not adjusted /git/A/.git/worktrees/B/gitdir to the new location. I fixed the situation by renaming /git/B to /git/B.bak, creating a new worktree pointing to /git/B (with branch g), then deleting /git/B and moving /git/B.bak to /git/B . Consider adjusting the documentation as suggested below, possibly using a different wording. Regards Дилян On 03/02/18 00:56, Duy Nguyen wrote: On Fri, Mar 2, 2018 at 3:14 AM, Eric Sunshine <sunsh...@sunshineco.com> wrote: As far as I know, there isn't any code in Git which would automatically remove the .git/worktrees/B directory, so it's not clear how that happened. "git worktree prune" does, which is called by "git gc" and that was actually executed from the command output in the original mail. Дилян Палаузов did you move /git/B away manually? For example, you originally created "B" with git worktree add /somewhere/B g then you do this at some point mv /somewhere/B /git/B Signed-off-by Дилян Палаузов <git-...@aegee.org> --- diff --git a/Documentation/git-gc.txt b/Documentation/git-gc.txt index 571b5a7..33655c4 100644 --- a/Documentation/git-gc.txt +++ b/Documentation/git-gc.txt @@ -15,8 +15,8 @@ DESCRIPTION --- Runs a number of housekeeping tasks within the current repository, such as compressing file revisions (to reduce disk space and increase -performance) and removing unreachable objects which may have been -created from prior invocations of 'git add'. +performance), removing unreachable objects, which may have been +created from prior invocations of 'git add', and calling 'git worktree prune'. Users are encouraged to run this task on a regular basis within each repository to maintain good disk space utilization and good diff --git a/Documentation/git-worktree.txt b/Documentation/git-worktree.txt index 5ac3f68..4b0d32f 100644 --- a/Documentation/git-worktree.txt +++ b/Documentation/git-worktree.txt @@ -82,7 +82,7 @@ with `--reason`. prune:: -Prune working tree information in $GIT_DIR/worktrees. +Prune working tree information in $GIT_DIR/worktrees. Called implicitly by 'git gc'. unlock:: -- 2.10.0.298.gc59cecb
Re: Worktree silently deleted on git fetch/gc/log
Hello, /git/A/.git/worktrees/b/ is missing - that is the point. /git/B/,git wasn't modified since the worktree was created, cat: gitdir: /git/A/.git/worktrees/b Regards Дилян On 03/01/18 19:09, Eric Sunshine wrote: On Wed, Feb 28, 2018 at 7:44 AM, Дилян Палаузов <dilyan.palau...@aegee.org> wrote: A (branch master) and B (branch g) which is a worktree of the first. /git/B g>$ git fetch [...] From https://... 13e4c55a0..02655d5fb g -> origin/g c37a3ca25..bc7888511 master -> origin/master Auto packing the repository in background for optimum performance. See "git help gc" for manual housekeeping. /git/B g<>$ git log -p origin/g fatal: Not a git repository: /git/A/.git/worktrees/B /git/B$ Please note that on the second last prompt there is <>, so that git-prompt has found the neccessary information and this was later deleted - by 'gc' or 'log'. What would be the procedure to restore the /git/A/.git/worktrees/B structure? Can you show us (via 'cat') the content of the following files? /git/B/.git /git/A/.git/worktrees/b/HEAD /git/A/.git/worktrees/b/commondir /git/A/.git/worktrees/b/gitdir
Worktree silently deleted on git fetch/gc/log
Hello, with git 2.16.2 I have two repositories: A (branch master) and B (branch g) which is a worktree of the first. This has always forked fine until yesterday, when I did: /git/B g>$ git fetch remote: Counting objects: 29, done. remote: Compressing objects: 100% (6/6), done. remote: Total 29 (delta 19), reused 25 (delta 19), pack-reused 4 Unpacking objects: 100% (29/29), done. From https://... 13e4c55a0..02655d5fb g -> origin/g c37a3ca25..bc7888511 master -> origin/master Auto packing the repository in background for optimum performance. See "git help gc" for manual housekeeping. /git/B g<>$ git log -p origin/g fatal: Not a git repository: /git/A/.git/worktrees/B /git/B$ Please note that on the second last prompt there is <>, so that git-prompt has found the neccessary information and this was this was later deleted - by 'gc' or 'log'. I guess somebody who knows the code in detail can easily fix this. What would be the procedure to restore the /git/A/.git/worktrees/B structure? Kind regards Dilyan
Re: git grep -P fatal: pcre_exec failed with error code -8
Hello, thanks for your answer. I understand that the PCRE's stack can get exhausted for some files, but in such cases, git grep shall proceed with the other files, and print at the end/stderr for which files the pattern was not applied. Such behaviour would be more usefull than the current one. Regards Dilian On 11/05/2017 03:16 AM, Jeff King wrote: On Sun, Nov 05, 2017 at 01:06:21AM +0100, Дилян Палаузов wrote: with git 2.14.3 linked with libpcre.so.1.2.9 when I do: git clone https://github.com/django/django cd django git grep -P "if.*([^\s])+\s+and\s+\1" django/contrib/admin/static/admin/js/vendor/select2/select2.full.min.js the output is: fatal: pcre_exec failed with error code -8 Code -8 is PCRE_ERROR_MATCHLIMIT. And "man pcreapi" has this to say: The match_limit field provides a means of preventing PCRE from using up a vast amount of resources when running patterns that are not going to match, but which have a very large number of possibilities in their search trees. The classic example is a pattern that uses nested unlimited repeats. Internally, pcre_exec() uses a function called match(), which it calls repeatedly (sometimes recursively). The limit set by match_limit is imposed on the number of times this function is called during a match, which has the effect of limiting the amount of backtracking that can take place. For patterns that are not anchored, the count restarts from zero for each posi‐ tion in the subject string. When pcre_exec() is called with a pattern that was successfully studied with a JIT option, the way that the matching is exe‐ cuted is entirely different. However, there is still the pos‐ sibility of runaway matching that goes on for a very long time, and so the match_limit value is also used in this case (but in a different way) to limit how long the matching can continue. The default value for the limit can be set when PCRE is built; the default default is 10 million, which handles all but the most extreme cases. You can override the default by suppling pcre_exec() with a pcre_extra block in which match_limit is set, and PCRE_EXTRA_MATCH_LIMIT is set in the flags field. If the limit is exceeded, pcre_exec() returns PCRE_ERROR_MATCH‐ LIMIT. So your pattern is just really expensive and is running afoul of pcre's backtracking limits (and it's not helped by the fact that the file is basically one giant line). There's no way to ask Git to specify a larger match_limit to pcre, but you might be able to construct your pattern in a way that involves less backtracking. It looks like you're trying to find things like "if foo and foo"? Should the captured term actually be "([^\s]+)" (with the "+" on the _inside_ of the capture? Or maybe I'm just misunderstanding your goal. -Peff
git grep -P fatal: pcre_exec failed with error code -8
Hello, with git 2.14.3 linked with libpcre.so.1.2.9 when I do: git clone https://github.com/django/django cd django git grep -P "if.*([^\s])+\s+and\s+\1" django/contrib/admin/static/admin/js/vendor/select2/select2.full.min.js the output is: fatal: pcre_exec failed with error code -8 (But not with git clone https://github.com/select2/select2 cd select2 git grep -P "if.*([^\s])+\s+and\s+\1" dist/js/select2.full.min.js as the two select2.full.min.js files differ slightly in their size) Any ideas? Regards Dilian
[PATCH] Remove useless assignments
Signed-off-by: Дилян Палаузов <git-...@aegee.org>
diff --git a/archive.c b/archive.c
index 60b889198..e2534d186 100644
--- a/archive.c
+++ b/archive.c
@@ -503,7 +503,7 @@ int write_archive(int argc, const char **argv, const char
*prefix,
init_tar_archiver();
init_zip_archiver();
- argc = parse_archive_args(argc, argv, , , name_hint, remote);
+ parse_archive_args(argc, argv, , , name_hint, remote);
if (!startup_info->have_repository) {
/*
* We know this will die() with an error, so we could just
diff --git a/builtin/add.c b/builtin/add.c
index 9f53f020d..fc1481273 100644
--- a/builtin/add.c
+++ b/builtin/add.c
@@ -211,7 +211,7 @@ static int edit_patch(int argc, const char **argv, const
char *prefix)
init_revisions(, prefix);
rev.diffopt.context = 7;
- argc = setup_revisions(argc, argv, , NULL);
+ setup_revisions(argc, argv, , NULL);
rev.diffopt.output_format = DIFF_FORMAT_PATCH;
rev.diffopt.use_color = 0;
DIFF_OPT_SET(, IGNORE_DIRTY_SUBMODULES);
diff --git a/builtin/help.c b/builtin/help.c
index 49f7a07f8..3d24b084e 100644
--- a/builtin/help.c
+++ b/builtin/help.c
@@ -453,7 +453,7 @@ int cmd_help(int argc, const char **argv, const char
*prefix)
int nongit;
enum help_format parsed_help_format;
- argc = parse_options(argc, argv, prefix, builtin_help_options,
+ parse_options(argc, argv, prefix, builtin_help_options,
builtin_help_usage, 0);
parsed_help_format = help_format;
diff --git a/builtin/merge.c b/builtin/merge.c
index 703827f00..337efef6f 100644
--- a/builtin/merge.c
+++ b/builtin/merge.c
@@ -795,7 +795,7 @@ static int merge_trivial(struct commit *head, struct
commit_list *remoteheads)
write_tree_trivial(_tree);
printf(_("Wonderful.\n"));
pptr = commit_list_append(head, pptr);
- pptr = commit_list_append(remoteheads->item, pptr);
+ commit_list_append(remoteheads->item, pptr);
prepare_to_commit(remoteheads);
if (commit_tree(merge_msg.buf, merge_msg.len, result_tree.hash, parents,
result_commit.hash, NULL, sign_commit))
diff --git a/builtin/notes.c b/builtin/notes.c
index 7b891471c..6ec753383 100644
--- a/builtin/notes.c
+++ b/builtin/notes.c
@@ -1015,7 +1015,7 @@ int cmd_notes(int argc, const char **argv, const char
*prefix)
else if (!strcmp(argv[0], "get-ref"))
result = get_ref(argc, argv, prefix);
else {
- result = error(_("unknown subcommand: %s"), argv[0]);
+ error(_("unknown subcommand: %s"), argv[0]);
usage_with_options(git_notes_usage, options);
}
diff --git a/builtin/prune-packed.c b/builtin/prune-packed.c
index c026299e7..73f424d9f 100644
--- a/builtin/prune-packed.c
+++ b/builtin/prune-packed.c
@@ -59,7 +59,7 @@ int cmd_prune_packed(int argc, const char **argv, const char
*prefix)
OPT_END()
};
- argc = parse_options(argc, argv, prefix, prune_packed_options,
+ parse_options(argc, argv, prefix, prune_packed_options,
prune_packed_usage, 0);
prune_packed_objects(opts);
diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c
index 0bb36d584..0fa779103 100644
--- a/builtin/receive-pack.c
+++ b/builtin/receive-pack.c
@@ -498,7 +498,7 @@ static const char *check_nonce(const char *buf, size_t len)
char *nonce = find_header(buf, len, "nonce");
timestamp_t stamp, ostamp;
char *bohmac, *expect = NULL;
- const char *retval = NONCE_BAD;
+ const char *retval;
if (!nonce) {
retval = NONCE_MISSING;
diff --git a/builtin/reset.c b/builtin/reset.c
index fc3b906c4..f547efd8d 100644
--- a/builtin/reset.c
+++ b/builtin/reset.c
@@ -291,7 +291,7 @@ int cmd_reset(int argc, const char **argv, const char
*prefix)
git_config(git_default_config, NULL);
- argc = parse_options(argc, argv, prefix, options, git_reset_usage,
+ parse_options(argc, argv, prefix, options, git_reset_usage,
PARSE_OPT_KEEP_DASHDASH);
parse_args(, argv, prefix, patch_mode, );
diff --git a/diffcore-rename.c b/diffcore-rename.c
index f7444c86b..632e19089 100644
--- a/diffcore-rename.c
+++ b/diffcore-rename.c
@@ -580,7 +580,7 @@ void diffcore_rename(struct diff_options *options)
rename_count += find_renames(mx, dst_cnt, minimum_score, 0);
if (detect_rename == DIFF_DETECT_COPY)
- rename_count += find_renames(mx, dst_cnt, minimum_score, 1);
+ find_renames(mx, dst_cnt, minimum_score, 1);
free(mx);
cleanup:
diff --git a/fast-import.c b/fast-import.c
index cf58f875b..0369363b2 100644
--- a/fast-import.c
+++ b/fast-import.c
@@ -2054,7 +2054,7 @@ static int validate_
Re: git and the Clang Static Analyzer
Hello Johannes, I compiled git/master ... which advances from time to time, so you definitely want to include a more informative data point here, e.g. 4fa66c85f11 (Git 2.13-rc2, 2017-05-04) ... The 4fa66c85f11 you mentioned is part of the URL I sent. Please note, that the information is only about what gets actually compiled, code disabled by #if .. #endif is not considered (e.g. when determining whether a variable assignment is useless). So you already know that the report is specific to your setup. It may make a lot of sense to actually state what your setup is, i.e. Operating System, installed libraries (and their respective versions), CPU, etc. I don't think this is of much relevance. The hints provided encourage one to look at the code and to evaluate mentally the lines. By tweaking the preprocessor directives, you could get less warnings (a previously unused variable now appears within an asser()), or more warnings (as more code gets compiled). Getting more warnings makes sense, after the current ones are processed. Getting less warnings means (again) compiling more code. I use already pcre and openssl, what else can I enable? There are probably false-positives. Probably. So why don't you give it a try and look through the report? Then summarize your findings here. That would definitely find a warm welcome, I would expect. However in case of e.g. builtin/notes.c:1018, builtin/reset.c:294 or fast-import.c:2057 I consider the hints as justified. Okay. And those hint are...? Click on https://mail.aegee.org/dpa/scan-build-git-4fa66c85f11/ and then on "fast-import.c: line 2057 -> View Report" and you will see pointless assignment. I cannot organize the report much better, as filtering out the false positives requires usually too deep understanding of the code organization of git, which I do not have. This is the analysis done on the pu-branch: https://mail.aegee.org/dpa/scan-build-git-7dd243c75 Both reports do not list files in the same order, as I did parallel builds, but I do not see on the spot any difference. Learning Travis is not on my priority list, I sent the commands I called to get the report. I also compiled clang by myself. For those who mistrust sites, there are no-javascipt, no-css browsers like lynx. Greetings Dilyan
git clone -b
Hello, why do these work: git clone --bare -b 3.5 https://github.com/python/cpython A git clone -b 3.6 A B git clone -b 3.5 https://github.com/python/cpython C but these not: git clone -b 3.6 C D git clone --no-local -b 3.6 C D with git version 2.12.2.89.g49800c940? Regards Дилян
git and the Clang Static Analyzer
Hello, I compiled git/master using the clang 4.0 static analyzer with scan-build ./configure --with-libpcre --with-openssl scan-build make and here are the results: https://mail.aegee.org/dpa/scan-build-git-4fa66c85f11/ Please note, that the information is only about what gets actually compiled, code disabled by #if .. #endif is not considered (e.g. when determining whether a variable assignment is useless). There are probably false-positives. However in case of e.g. builtin/notes.c:1018, builtin/reset.c:294 or fast-import.c:2057 I consider the hints as justified. This is for your information, I wouldn't have a problem if you ignore the analysis. When you are worried about javascript, use lynx. Regards Дилян
git log --ignore-space-change -L start,end:file does not ignore indentation changes
Hello,
$ git version
git version 2.12.2.89.g49800c940
$ git init
Initialized empty Git repository in .git/
$ cat a.c
int main() {
int result;
}
$git add a.c
$git commit -m I
[master (root-commit) ef9ab63] I
1 file changed, 3 insertions(+)
create mode 100644 a.c
$cat a.c # now the indentation of result changed
cat a.c
int main() {
int result;
return 0;
}
$git commit -am J
[master 1bed130] J
1 file changed, 2 insertions(+), 1 deletion(-)
$git -oneline -b -L:main:a.c
1bed130 J
diff --git a/a.c b/a.c
--- a/a.c
+++ b/a.c
@@ -1,3 +1,4 @@
int main() {
- int result;
+ int result;
+ return 0;
}
ef9ab63 I
diff --git a/a.c b/a.c
--- /dev/null
+++ b/a.c
@@ -0,0 +1,3 @@
+int main() {
+ int result;
+}
I expect that the result-line is not displayed as changed, when git log
is called with -b.
Likewise:
git log --oneline -b -L2,2:a.c
1bed130 J
diff --git a/a.c b/a.c
--- a/a.c
+++ b/a.c
@@ -2,1 +2,1 @@
- int result;
+ int result;
ef9ab63 I
diff --git a/a.c b/a.c
--- /dev/null
+++ b/a.c
@@ -0,0 +2,1 @@
+ int result;
Regards
Дилян
[PATCH] ./configure.ac: Detect SSL in libcurl using curl-config
The API of libcurl does not mention Curl_ssl_init() and when curl is built
with -flto, the Curl_ssl_init symbol is not exported.
https://curl.haxx.se/libcurl/using/ suggests calling
curl-config --feature | grep SSL
to see, if the installed curl has SSL support. Another approach would
be calling curl_version_info and checking the returned struct.
This patch removes the check for the Curl_ssl_init exported symbol from
libcurl and uses curl-config to detect SSL support in libcurl.
Signed-Off-By: Дилян Палаузов <git-...@aegee.org>
---
configure.ac | 21 +++--
1 file changed, 11 insertions(+), 10 deletions(-)
diff --git a/configure.ac b/configure.ac
index c279025..5e9ba59 100644
--- a/configure.ac
+++ b/configure.ac
@@ -528,16 +528,6 @@ AC_CHECK_LIB([curl], [curl_global_init],
[NO_CURL=],
[NO_CURL=YesPlease])
-if test -z "${NO_CURL}" && test -z "${NO_OPENSSL}"; then
-
-AC_CHECK_LIB([curl], [Curl_ssl_init],
-[NEEDS_SSL_WITH_CURL=YesPlease],
-[NEEDS_SSL_WITH_CURL=])
-
-GIT_CONF_SUBST([NEEDS_SSL_WITH_CURL])
-
-fi
-
GIT_UNSTASH_FLAGS($CURLDIR)
GIT_CONF_SUBST([NO_CURL])
@@ -550,6 +540,17 @@ AC_CHECK_PROG([CURL_CONFIG], [curl-config],
if test $CURL_CONFIG != no; then
GIT_CONF_SUBST([CURL_CONFIG])
+if test -z "${NO_OPENSSL}"; then
+ AC_MSG_CHECKING([if Curl supports SSL])
+ if test $(curl-config --features|grep SSL) = SSL; then
+ NEEDS_SSL_WITH_CURL=YesPlease
+ AC_MSG_RESULT([yes])
+ else
+ NEEDS_SSL_WITH_CURL=
+ AC_MSG_RESULT([no])
+ fi
+ GIT_CONF_SUBST([NEEDS_SSL_WITH_CURL])
+fi
fi
fi
--
2.9.0
--
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
git-completion.bash emitting error messages
Hello, I use ./bash 4.3.42 with bundled libreadline and git/contrib/completion/git-completion.bash , as modified by commit 8716bdca268 from 22 Feb 2016. I cd to git.git (non-bare, with working tree) and type git b62c.. ori to force TAB-completion. And then on the shell comes the output (on the same line) "error: key does not contain variable name: alias.b62c.." Pressing again TAB repeats the message. Even if TAB is pressed once, the printed text cannot be deleted with the backspace, so the only way to do something useful is to press ENTER. While the command is indeed nonsense, in my understanding tab-completion shall do nothing, if completion is not possible. In particular it shall not print error messages and even the user types stupid things, he shall not be required to force ENTER to come back to a clear state, where a command can by types. Greetings Dilian -- 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
diff --minimal versus --diff-algorithm=minimal
Hello, after I put in ~/.config/git "[diff] algorithm=histogram", and called "git diff --minimal" I expect from git to use algorithm=minimal. But it uses histogram, unless I call "--diff-algorithm=minimal". According to the documentation, however, --minimal and --diff-algorithm=minimal shall be equivalent. By the way, histogram produces more compact output than minimal (in terms of number of lines and in terms of @@ ... @@ snippets), but the documentation suggests, that minimal produces the most compact form that can be achieved. I use git version 2.6.3.385.g1bc8fea. Greetings Дилян -- 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
git pull git gc
Hello, I have a local folder with the git-repository (so that its .git/config contains ([remote origin]\n url = git://github.com/git/git.git\nfetch = +refs/heads/*:refs/remotes/origin/* ) I do there git pull. Usually the output is Already up to date but since today it prints Auto packing the repository in background for optimum performance. See git help gc for manual housekeeping. Already up-to-date. and starts in the background a git gc --auto process. This is all fine, however, when the git gc process finishes, and I do again git pull I get the same message, as above (git gc is again started). My understanding is, that git gc has to be occasionally run and then the garbage collection is done for a while. In the concrete case, if git pull starts git gc in the background and prints a message on this, it is all fine, but running git pull after a while, when the garbage collection was recently done, where shall be neither message nor an action about git gc. My system-wide gitconfig contains [pack] threads = 1. I have tar xJf'ed my local git repository and have put it under http://mail.aegee.org/dpa/v/git-repository.tar.xz The question is: Why does git pull every time when it is invoked today print information about git gc? I have git 2.3.3 adjusted with ./configure --with-openssl --with-libpcre --with-curl --with-expat. Thanks in advance for your answer Dilian -- 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: git pull git gc
Hello, # git gc --auto Auto packing the repository in background for optimum performance. See git help gc for manual housekeeping. and calls in the background: 25618 1 0 32451 884 1 14:20 ?00:00:00 git gc --auto 25639 25618 51 49076 49428 0 14:20 ?00:00:07 git prune --expire 2.weeks.ago # git count-objects -v count: 6039 size: 65464 in-pack: 185432 packs: 1 size-pack: 46687 prune-packable: 0 garbage: 0 size-garbage: 0 Regards Dilian On 18.03.2015 15:16, Duy Nguyen wrote: On Wed, Mar 18, 2015 at 8:53 PM, Дилян Палаузов dilyan.palau...@aegee.org wrote: Hello, I have a local folder with the git-repository (so that its .git/config contains ([remote origin]\nurl = git://github.com/git/git.git\nfetch = +refs/heads/*:refs/remotes/origin/* ) I do there git pull. Usually the output is Already up to date but since today it prints Auto packing the repository in background for optimum performance. See git help gc for manual housekeeping. Already up-to-date. and starts in the background a git gc --auto process. This is all fine, however, when the git gc process finishes, and I do again git pull I get the same message, as above (git gc is again started). So if you do git gc --auto now, does it exit immediately or go through the garbage collection process again (it'll print something)? What does git count-objects -v show? -- 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: git pull git gc
Hello Duy, #ls .git/objects/17/* | wc -l 30 30 * 256 = 7 680 6 700 And now? Do I have to run git gc --aggressive ? Kind regards Dilian On 18.03.2015 15:33, Duy Nguyen wrote: On Wed, Mar 18, 2015 at 9:23 PM, Дилян Палаузов dilyan.palau...@aegee.org wrote: Hello, # git gc --auto Auto packing the repository in background for optimum performance. See git help gc for manual housekeeping. and calls in the background: 25618 1 0 32451 884 1 14:20 ?00:00:00 git gc --auto 25639 25618 51 49076 49428 0 14:20 ?00:00:07 git prune --expire 2.weeks.ago # git count-objects -v count: 6039 loose number threshold is 6700, unless you tweaked something. But there's a tweak, we'll come back to this. size: 65464 in-pack: 185432 packs: 1 Pack threshold is 50, You only have one pack, good OK back to the count 6039 above. You have that many loose objects. But 'git gc' is lazier than 'git count-objects'. It assume a flat distribution, and only counts the number of objects in .git/objects/17 directory only, then extrapolate for the total number. So can you see how many files you have in this directory .git/objects/17? That number, multiplied by 256, should be greater than 6700. If that's the case git gc laziness is the problem. If not, I made some mistake in analyzing this and we'll start again. -- 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] Remove duplicate #include
deheader (git://gitorious.org/deheader/deheader.git) found out that some .c files #include twice one and the same header file. This patch removes such occurrences and hence speeds up the compilation. Signed-off-by: Дилян Палаузов git-...@aegee.org --- builtin/fetch.c| 1 - trailer.c | 1 - transport-helper.c | 1 - userdiff.c | 1 - 4 files changed, 4 deletions(-) diff --git a/builtin/fetch.c b/builtin/fetch.c index 7b84d35..75a55e5 100644 --- a/builtin/fetch.c +++ b/builtin/fetch.c @@ -11,7 +11,6 @@ #include run-command.h #include parse-options.h #include sigchain.h -#include transport.h #include submodule.h #include connected.h #include argv-array.h diff --git a/trailer.c b/trailer.c index 623adeb..05b3859 100644 --- a/trailer.c +++ b/trailer.c @@ -1,7 +1,6 @@ #include cache.h #include string-list.h #include run-command.h -#include string-list.h #include commit.h #include trailer.h /* diff --git a/transport-helper.c b/transport-helper.c index 0224687..3652b16 100644 --- a/transport-helper.c +++ b/transport-helper.c @@ -5,7 +5,6 @@ #include commit.h #include diff.h #include revision.h -#include quote.h #include remote.h #include string-list.h #include thread-utils.h diff --git a/userdiff.c b/userdiff.c index fad52d6..2ccbee5 100644 --- a/userdiff.c +++ b/userdiff.c @@ -1,6 +1,5 @@ #include cache.h #include userdiff.h -#include cache.h #include attr.h static struct userdiff_driver *drivers; -- 2.3.0.1.g24c2b87 -- 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
git log --graph --color inconsistency
Hello, I use git version 1.9.1 . With git clone git://github.com/pocoproject/poco.git cd poco git log --graph --color=always and scrolling a bit, I see http://mail.aegee.org/dpa/git-log-graph-color/git-log-graph-color.png . My expectation is, that one branch keeps its color consistent in log --graph, but here it changes from red to green without any obvious reason. Any ideas? Greetings Dilyan -- 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] configure.ac: link with -liconv for locale_charset()
Hello, this changes effectively the meaning of CHARSET_LIB to always/unconditionally contain the library with the charset_locale () function. The snippet at the end of the email updates the description in /Makefile . However, I checked now how gnulib deals with locale_charset (). Contary to my expectation, where gnulib builds only functions if they are not found in libraries on the target system, gnulib module localcharset builds unconditionally from source the function locale_charset (). I guess they do this in a portable way, but still. My preference is to agree on universal approach for finding this function, something like: OK, if found in libiconv, else OK, if found in libcharset, else OK, here are the sources, build the function from them, and don't look for it in (shared) libaries I asked at bug-gnulib@ why they build locale_charset() before checking for it in libiconv / libcharset. My posting shall appear at http://lists.gnu.org/archive/html/bug-gnulib/2014-03/index.html . Let's see what the answer will be. I don't know if in the git codebase generally is refused to use gnulib code, but if you agree on the above procedure with 3xOK, then locale_charset() will be available even on systems, that don't have this function in libcharset or libiconv Maybe /compat/poll/poll.[ch] in git-core from gnulib had similar history. Kind regards Дилян On 11.03.2014 21:35, Junio C Hamano wrote: Dmitry Marakasov amd...@amdmi3.ru writes: On e.g. FreeBSD 10.x, the following situation is common: - there's iconv implementation in libc, which has no locale_charset() function - there's GNU libiconv installed from Ports Collection Git build process - detects that iconv is in libc and thus -liconv is not needed for it - detects locale_charset in -liconv, but for some reason doesn't add it to CHARSET_LIB (as it would do with -lcharset if locale_charset() was found there instead of -liconv) - git doesn't build due to unresolved external locale_charset() Fix this by adding -liconv to CHARSET_LIB if locale_charset() is detected in this library. Signed-off-by: Dmitry Marakasov amd...@amdmi3.ru --- Looks sensible; Dilyan, any comments? configure.ac | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git configure.ac configure.ac index 2f43393..3f5c644 100644 --- configure.ac +++ configure.ac @@ -890,7 +890,7 @@ GIT_CONF_SUBST([HAVE_STRINGS_H]) # and libcharset does CHARSET_LIB= AC_CHECK_LIB([iconv], [locale_charset], - [], + [CHARSET_LIB=-liconv], [AC_CHECK_LIB([charset], [locale_charset], [CHARSET_LIB=-lcharset])]) GIT_CONF_SUBST([CHARSET_LIB]) -- diff --git a/Makefile b/Makefile index dddaf4f..dce4694 100644 --- a/Makefile +++ b/Makefile @@ -59,9 +59,9 @@ all:: # FreeBSD can use either, but MinGW and some others need to use # libcharset.h's locale_charset() instead. # -# Define CHARSET_LIB to you need to link with library other than -liconv to +# Define CHARSET_LIB to the library you need to link with in order to # use locale_charset() function. On some platforms this needs to set to -# -lcharset +# -lcharset, on others to -liconv . # # Define LIBC_CONTAINS_LIBINTL if your gettext implementation doesn't # need -lintl when linking. -- 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
typo in Documentation/git-rebase.txt
Hello, please change in Documentation/git-rebase.txt, as of v1.8.2-470-g21ccebe, for --ignore-whitespace and --whitespace, line 326 from These flag are passed to the 'git apply' program to (add an 's') These flags are passed to the 'git apply' program and in the same file, under --autosqash, --no-autosquash, last paragraph If the '--autosquash' option is enabled by default using the configuration variable `rebase.autosquash`, this option can be used to override and disable this setting. please delete by default. With by default comes the question, what is the default value, if rebase.autosquash is not set. I suggest as replacement text If the '--autosquash' option is enabled using the configuration variable 'rebase.autosquash', '--no-autosqash' can be used to override and disable this setting. Even and disable is redundant and can be skipped. Със здраве Дилян -- 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
