* Re: tar-tree.c dereferencing pointer to incomplete type
From: 白い熊 @ 2013-01-19 14:37 UTC (permalink / raw)
To: git
In-Reply-To: <CAPy7p-7V6y4hfLrYYi_3zGkzGTw2BeF5wh3zPYzumrp+Pbqr+Q@mail.gmail.com>
On Sat, Jan 19, 2013 at 6:26 PM, 白い熊 <ShiroiKuma@shiroikuma.org> wrote:
> Thank you, this must've been it, as it was finding tar.h from glibc.
>
> Moved it and compiles fine. In fact I moved it back now, so it should
> be finding it again and it still builds fine, no trace of the prior
> error. I'm dumbfounded! But at least it compiles...
OK, figured it out. It was indeed the wrong tar.h, the one that was
making it bomb was the kernel headers tar.h from the Android source.
That explains it quite well.
All's good now. Thank you :@)
--
白い熊
^ permalink raw reply
* Re: tar-tree.c dereferencing pointer to incomplete type
From: 白い熊 @ 2013-01-19 14:26 UTC (permalink / raw)
To: git
In-Reply-To: <CACsJy8DfOYRmF6FqTLCAYgXGpECX-VhpXGK5CfcmVvKXQ+DpuA@mail.gmail.com>
On Sat, Jan 19, 2013 at 5:37 PM, Duy Nguyen <pclouds@gmail.com> wrote:
> There is another tar.h somewhere in your system? Stopping the
> compilation after proprocessing should show if it includes the correct
> tar.h.
Thank you, this must've been it, as it was finding tar.h from glibc.
Moved it and compiles fine. In fact I moved it back now, so it should
be finding it again and it still builds fine, no trace of the prior
error. I'm dumbfounded! But at least it compiles...
--
白い熊
^ permalink raw reply
* Re: [PATCH] INSTALL: git-p4 doesn't support Python 3
From: Pete Wyckoff @ 2013-01-19 14:23 UTC (permalink / raw)
To: John Keeping; +Cc: git
In-Reply-To: <20130119120158.GH31172@serenity.lan>
john@keeping.me.uk wrote on Sat, 19 Jan 2013 12:01 +0000:
> git-p4 supports Python 2.6 and later versions of Python 2. Since Pyhton
> 2.8 will never exist [1], it is most concise to just list the supported
> versions.
>
> [1] http://www.python.org/dev/peps/pep-0404/
>
> Signed-off-by: John Keeping <john@keeping.me.uk>
[..]
> - - Python version 2.6 or later is needed to use the git-p4
> + - Python version 2.6 or 2.7 is needed to use the git-p4
This is indeed more accurate.
Acked-by: Pete Wyckoff <pw@padd.com>
^ permalink raw reply
* Re: Re* t9902 fails
From: Jean-Noël AVILA @ 2013-01-19 13:43 UTC (permalink / raw)
To: Junio C Hamano
Cc: Torsten Bögershausen, Jonathan Nieder, Jeff King, git,
Nguyễn Thái Ngọc Duy, Felipe Contreras
In-Reply-To: <7vwqv9obie.fsf_-_@alter.siamese.dyndns.org>
Le samedi 19 janvier 2013 08:52:25, Junio C Hamano a écrit :
> (2) instead of being inclusive, collecting all executable in
> GIT_EXEC_PATH that happens to be named "git-", add a mode to
> "git help" that lists those that we know to be standard
> commands that the users may want to complete from the command
> line.
Am I wrong when I say that "git help -a" already provides the difference
between core git commands and other commands available through path?
If we use this, then we can instruct git-completion that we are in test mode
and that it should not provide additional completions.
---
contrib/completion/git-completion.bash | 13 +++++++++++--
t/t9902-completion.sh | 2 +-
2 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-
completion.bash
index 14dd5e7..dc0ea5b 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -23,6 +23,8 @@
# 3) Consider changing your PS1 to also show the current branch,
# see git-prompt.sh for details.
+__testing_git=$1
+
case "$COMP_WORDBREAKS" in
*:*) : great ;;
*) COMP_WORDBREAKS="$COMP_WORDBREAKS:"
@@ -533,8 +535,15 @@ __git_complete_strategy ()
__git_list_all_commands ()
{
- local i IFS=" "$'\n'
- for i in $(git help -a|egrep '^ [a-zA-Z0-9]')
+ local i cmdlist IFS=" "$'\n'
+
+ if [ "x$__testing_git" != "xTEST" ]; then
+ cmdlist=$(git help -a|egrep '^ [a-zA-Z0-9]')
+ else
+ cmdlist=$(git help -a| egrep -m 1 -B1000 PATH | egrep '^ [a-zA-Z0-9]')
+ fi
+
+ for i in $cmdlist
do
case $i in
*--*) : helper pattern;;
diff --git a/t/t9902-completion.sh b/t/t9902-completion.sh
index 3cd53f8..51463b2 100755
--- a/t/t9902-completion.sh
+++ b/t/t9902-completion.sh
@@ -13,7 +13,7 @@ complete ()
return 0
}
-. "$GIT_BUILD_DIR/contrib/completion/git-completion.bash"
+. "$GIT_BUILD_DIR/contrib/completion/git-completion.bash" TEST
# We don't need this function to actually join words or do anything special.
# Also, it's cleaner to avoid touching bash's internal completion variables.
--
1.8.1.1.271.g02f55e6
^ permalink raw reply related
* Re: tar-tree.c dereferencing pointer to incomplete type
From: Duy Nguyen @ 2013-01-19 13:37 UTC (permalink / raw)
To: 白い熊; +Cc: git
In-Reply-To: <CAPy7p-45-E-vWcjBTXSLpjoQLic54JdAoKqB3jz4RA6GzAkw8w@mail.gmail.com>
On Sat, Jan 19, 2013 at 8:31 PM, 白い熊 <ShiroiKuma@shiroikuma.org> wrote:
> Hello:
>
> I'm building v 1.8.1.1 on Android. The build chokes on the builtins
> phase on tar-tree.c with:
>
> CC builtin/tar-tree.o
> builtin/tar-tree.c: In function 'cmd_get_tar_commit_id':
> builtin/tar-tree.c:93:12: error: dereferencing pointer to incomplete type
> make: *** [builtin/tar-tree.o] Error 1
>
> The line that's causing this in tar-tree.c is:
>
> if (header->typeflag[0] != 'g')
There is another tar.h somewhere in your system? Stopping the
compilation after proprocessing should show if it includes the correct
tar.h.
--
Duy
^ permalink raw reply
* tar-tree.c dereferencing pointer to incomplete type
From: 白い熊 @ 2013-01-19 13:31 UTC (permalink / raw)
To: git
Hello:
I'm building v 1.8.1.1 on Android. The build chokes on the builtins
phase on tar-tree.c with:
CC builtin/tar-tree.o
builtin/tar-tree.c: In function 'cmd_get_tar_commit_id':
builtin/tar-tree.c:93:12: error: dereferencing pointer to incomplete type
make: *** [builtin/tar-tree.o] Error 1
The line that's causing this in tar-tree.c is:
if (header->typeflag[0] != 'g')
from
int cmd_get_tar_commit_id(int argc, const char **argv, const char *prefix)
{
char buffer[HEADERSIZE];
struct ustar_header *header = (struct ustar_header *)buffer;
char *content = buffer + RECORDSIZE;
ssize_t n;
if (argc != 1)
usage(builtin_get_tar_commit_id_usage);
n = read_in_full(0, buffer, HEADERSIZE);
if (n < HEADERSIZE)
die("git get-tar-commit-id: read error");
if (header->typeflag[0] != 'g')
return 1;
if (memcmp(content, "52 comment=", 11))
return 1;
n = write_in_full(1, content + 11, 41);
if (n < 41)
die_errno("git get-tar-commit-id: write error");
return 0;
}
But why?
What's messed up with my setup.
I can compile no probs on other machines. I'm trying to get my head
round this, but don't see the problem?
--
白い熊
^ permalink raw reply
* [PATCH] INSTALL: git-p4 doesn't support Python 3
From: John Keeping @ 2013-01-19 12:01 UTC (permalink / raw)
To: git; +Cc: Pete Wyckoff
git-p4 supports Python 2.6 and later versions of Python 2. Since Pyhton
2.8 will never exist [1], it is most concise to just list the supported
versions.
[1] http://www.python.org/dev/peps/pep-0404/
Signed-off-by: John Keeping <john@keeping.me.uk>
---
INSTALL | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/INSTALL b/INSTALL
index 28f34bd..c456d1c 100644
--- a/INSTALL
+++ b/INSTALL
@@ -131,7 +131,7 @@ Issues of note:
use English. Under autoconf the configure script will do this
automatically if it can't find libintl on the system.
- - Python version 2.6 or later is needed to use the git-p4
+ - Python version 2.6 or 2.7 is needed to use the git-p4
interface to Perforce.
- Some platform specific issues are dealt with Makefile rules,
--
1.8.1
^ permalink raw reply related
* Re: bug: git-svn seg fault during 'git svn fetch' due to perl < 5.10
From: Eric Wong @ 2013-01-19 11:51 UTC (permalink / raw)
To: Durham Goode; +Cc: git@vger.kernel.org, Jonathan Nieder
In-Reply-To: <2B10A89294DA6740AC6155F56842F9CE05234E6C@PRN-MBX01-2.TheFacebook.com>
Durham Goode <durham@fb.com> wrote:
> In git 1.8.1, when we do 'git svn fetch' on a large repo, we're seeing a
> seg fault. It's caused by git-svn trying to parse a large yaml file
> (introduced in
> https://github.com/git/git/commit/68f532f4ba888f277637a94b4a49136054df0540
> ) which encounters a perl regex stack overflow bug that was present in
> perl < 5.10 (https://bugzilla.redhat.com/show_bug.cgi?id=192400).
>
> We'll find a work around, but it'd be nice if there was a config setting
> to let us choose not to use the yaml format.
Maybe try a libyaml-based YAML module? I'm not too familiar
with YAML parsers in the Perl world. Hopefully Jonathan can help.
> Let me know if there's a better place to report this.
Yes, feel free to Cc: folks who signed-off/acked the change which
introduced the problem for you.
^ permalink raw reply
* Re: [PATCH] git-svn: do not escape certain characters in paths
From: Eric Wong @ 2013-01-19 11:34 UTC (permalink / raw)
To: Peter Wu; +Cc: git
In-Reply-To: <1472347.NT5gjdj3yd@al>
Peter Wu <lekensteyn@gmail.com> wrote:
> Signed-off-by: Peter Wu <lekensteyn@gmail.com>
Thanks, Signed-off-by: Eric Wong <normalperson@yhbt.net>
Will push.
^ permalink raw reply
* [PATCH] unpack-trees: do not abort when overwriting an existing file with the same content
From: Nguyễn Thái Ngọc Duy @ 2013-01-19 11:24 UTC (permalink / raw)
To: git; +Cc: Nguyễn Thái Ngọc Duy
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
The "git reset" as illustrated in the test case is one case people
may be hit by this. We can also do the same for "uptodate" check, but
I'm not sure how that could happen.
t/t1011-read-tree-sparse-checkout.sh | 3 ++-
t/t2021-checkout-overwrite.sh | 8 ++++++++
unpack-trees.c | 27 +++++++++++++++++++++++++++
3 files changed, 37 insertions(+), 1 deletion(-)
diff --git a/t/t1011-read-tree-sparse-checkout.sh b/t/t1011-read-tree-sparse-checkout.sh
index 5c0053a..38f9899 100755
--- a/t/t1011-read-tree-sparse-checkout.sh
+++ b/t/t1011-read-tree-sparse-checkout.sh
@@ -238,7 +238,8 @@ test_expect_success 'print errors when failed to update worktree' '
echo sub >.git/info/sparse-checkout &&
git checkout -f init &&
mkdir sub &&
- touch sub/added sub/addedtoo &&
+ echo modified >sub/added &&
+ echo modified >sub/addedtoo &&
test_must_fail git checkout top 2>actual &&
cat >expected <<\EOF &&
error: The following untracked working tree files would be overwritten by checkout:
diff --git a/t/t2021-checkout-overwrite.sh b/t/t2021-checkout-overwrite.sh
index 5da63e9..4163449 100755
--- a/t/t2021-checkout-overwrite.sh
+++ b/t/t2021-checkout-overwrite.sh
@@ -47,4 +47,12 @@ test_expect_success SYMLINKS 'checkout commit with dir must not remove untracked
test -h a/b
'
+test_expect_success 'do not abort on overwriting an existing file with the same content' '
+ echo abc >bar &&
+ git add bar &&
+ git commit -m "new file" &&
+ git reset HEAD^ &&
+ git checkout HEAD@{1}
+'
+
test_done
diff --git a/unpack-trees.c b/unpack-trees.c
index 0e1a196..16adc03 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c
@@ -1363,6 +1363,7 @@ static int check_ok_to_remove(const char *name, int len, int dtype,
struct unpack_trees_options *o)
{
struct cache_entry *result;
+ unsigned long ce_size;
/*
* It may be that the 'lstat()' succeeded even though
@@ -1405,6 +1406,32 @@ static int check_ok_to_remove(const char *name, int len, int dtype,
return 0;
}
+ /*
+ * If it has the same content that we are going to write down,
+ * there's no point in complaining. We still overwrite it in the
+ * end though. Permission is not checked so it may be lost.
+ */
+ if (ce &&
+ S_ISREG(st->st_mode) && S_ISREG(ce->ce_mode) &&
+ st->st_size < 1024 * 1024 && /* should be configurable */
+ sha1_object_info(ce->sha1, &ce_size) == OBJ_BLOB &&
+ ce_size == st->st_size) {
+ void *buffer = NULL;
+ unsigned long size;
+ enum object_type type;
+ struct strbuf sb = STRBUF_INIT;
+ int matched =
+ strbuf_read_file(&sb, ce->name, ce_size) == ce_size &&
+ (buffer = read_sha1_file(ce->sha1, &type, &size)) != NULL &&
+ type == OBJ_BLOB &&
+ size == ce_size &&
+ !memcmp(buffer, sb.buf, size);
+ free(buffer);
+ strbuf_release(&sb);
+ if (matched)
+ return 0;
+ }
+
return o->gently ? -1 :
add_rejected_path(o, error_type, name);
}
--
1.8.0.rc2.23.g1fb49df
^ permalink raw reply related
* Re: [PATCH 1/2] Change old system name 'GIT' to 'Git'
From: David Aguilar @ 2013-01-19 10:39 UTC (permalink / raw)
To: Thomas Ackermann; +Cc: git
In-Reply-To: <379071741.1327695.1358589560822.JavaMail.ngmail@webmail24.arcor-online.net>
On Sat, Jan 19, 2013 at 1:59 AM, Thomas Ackermann <th.acker@arcor.de> wrote:
> @@ -55,7 +55,7 @@ History Viewers
>
> - *gitweb* (shipped with git-core)
>
> - GITweb provides full-fledged web interface for GIT repositories.
> + GITweb provides full-fledged web interface for Git repositories.
What about GITweb?
> diff --git a/Documentation/git-update-ref.txt b/Documentation/git-update-ref.txt
> index d377a35..0df13ff 100644
> --- a/Documentation/git-update-ref.txt
> +++ b/Documentation/git-update-ref.txt
> @@ -73,7 +73,7 @@ in ref value. Log lines are formatted as:
> Where "oldsha1" is the 40 character hexadecimal value previously
> stored in <ref>, "newsha1" is the 40 character hexadecimal value of
> <newvalue> and "committer" is the committer's name, email address
> -and date in the standard GIT committer ident format.
> +and date in the standard Git committer ident format.
IMO some of these look nicer when everything is lowercase.
e.g. "standard git committer ident format".
> diff --git a/Documentation/gitweb.txt b/Documentation/gitweb.txt
> index 168e8bf..d364c3a 100644
> --- a/Documentation/gitweb.txt
> +++ b/Documentation/gitweb.txt
> @@ -504,7 +504,7 @@ repositories, you can configure Apache like this:
>
> The above configuration expects your public repositories to live under
> '/pub/git' and will serve them as `http://git.domain.org/dir-under-pub-git`,
> -both as cloneable GIT URL and as browseable gitweb interface. If you then
> +both as cloneable Git URL and as browseable gitweb interface. If you then
> start your linkgit:git-daemon[1] with `--base-path=/pub/git --export-all`
> then you can even use the `git://` URL with exactly the same path.
Git but not Gitweb? IMO it reads nicer as "cloneable git URL",
which also avoids this mismatch, but like I said that's my opinion.
$ git grep 'git repositor' | wc -l
226
These changes touch, for example, git-clone.txt to make it
say: "Make a 'bare' Git repository". Why not lowercase?
In that same file it has "git repository", in lowercase,
in a later paragraph. I'm not sure which way is preferred,
but I think they should be consistent.
Anyways, just some small notes.
cheers,
--
David
^ permalink raw reply
* Re: [PATCH 2/2] help --standard: list standard commands
From: Jean-Noël AVILA @ 2013-01-19 10:32 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Torsten Bögershausen, Jonathan Nieder, Jeff King,
Nguyễn Thái Ngọc Duy, Felipe Contreras
In-Reply-To: <7vk3r9ob22.fsf_-_@alter.siamese.dyndns.org>
Le samedi 19 janvier 2013 09:02:13, Junio C Hamano a écrit :
> If you run "make" on a branch that adds "git check-ignore", checkout
> an older branch that did not know about the command without "make clean",
> and the run t9902 test, the completion script fails to exclude the
> "check-ignore" command from candidates to complete "check".
>
> This is because the completion script asks "git help -a" to show
> every executable that begins with "git-" in the GIT_EXEC_PATH, and
> because we run tests with GIT_EXEC_PATH set to the top of the
> working tree, that has the executable we just built, in order to
> test these before installing. Leftover "git check-ignore" that we
> did not build for the current version gets in the way.
>
> One way to solve this is to restrict the completion to only the
> commands we know about.
>
> Note that this will make the completion useless in real life for
> some people, as they do want to get their custom commands on their
> $PATH to be included in the completion.
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
>
> * This is not a real patch, for the reasons stated.
>
> builtin/help.c | 17 ++++++++++++++---
> command-list.txt | 4 ++--
> contrib/completion/git-completion.bash | 14 +-------------
> generate-cmdlist.sh | 13 ++++++++++++-
> help.c | 30 ++++++++++++++++++++++++++++--
> help.h | 1 +
> 6 files changed, 58 insertions(+), 21 deletions(-)
>
> diff --git a/builtin/help.c b/builtin/help.c
> index 6067a61..32e7d64 100644
> --- a/builtin/help.c
> +++ b/builtin/help.c
> @@ -35,11 +35,16 @@ enum help_format {
>
> static const char *html_path;
>
> -static int show_all = 0;
> +#define HELP_SHOW_ALL 1
> +#define HELP_SHOW_STANDARD 2
> +static int show_what;
> static unsigned int colopts;
> static enum help_format help_format = HELP_FORMAT_NONE;
> static struct option builtin_help_options[] = {
> - OPT_BOOLEAN('a', "all", &show_all, N_("print all available commands")),
> + OPT_SET_INT('a', "all", &show_what, N_("print all available commands"),
> + HELP_SHOW_ALL),
> + OPT_SET_INT(0, "standard", &show_what, N_("print all available
> commands"), + HELP_SHOW_STANDARD),
> OPT_SET_INT('m', "man", &help_format, N_("show man page"),
> HELP_FORMAT_MAN), OPT_SET_INT('w', "web", &help_format, N_("show manual in
> web browser"), HELP_FORMAT_WEB),
> @@ -424,12 +429,18 @@ int cmd_help(int argc, const char **argv, const char
> *prefix) builtin_help_usage, 0);
> parsed_help_format = help_format;
>
> - if (show_all) {
> + if (show_what == HELP_SHOW_ALL) {
> git_config(git_help_config, NULL);
> printf(_("usage: %s%s"), _(git_usage_string), "\n\n");
> list_commands(colopts, &main_cmds, &other_cmds);
> printf("%s\n", _(git_more_info_string));
> return 0;
> + } else if (show_what == HELP_SHOW_STANDARD) {
> + int i;
> + limit_to_standard(&main_cmds);
> + for (i = 0; i < main_cmds.cnt; i++)
> + printf("%s\n", main_cmds.names[i]->name);
> + return 0;
> }
>
> if (!argv[0]) {
> diff --git a/command-list.txt b/command-list.txt
> index 7e8cfec..94ce8ec 100644
> --- a/command-list.txt
> +++ b/command-list.txt
> @@ -116,8 +116,8 @@ git-show mainporcelain
> common git-show-branch ancillaryinterrogators
> git-show-index plumbinginterrogators
> git-show-ref plumbinginterrogators
> -git-sh-i18n purehelpers
> -git-sh-setup purehelpers
> +git-sh-i18n purehelpers nocomplete
> +git-sh-setup purehelpers nocomplete
> git-stash mainporcelain
> git-status mainporcelain common
> git-stripspace purehelpers
> diff --git a/contrib/completion/git-completion.bash
> b/contrib/completion/git-completion.bash index a4c48e1..46f22af 100644
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -531,23 +531,11 @@ __git_complete_strategy ()
> return 1
> }
>
> -__git_list_all_commands ()
> -{
> - local i IFS=" "$'\n'
> - for i in $(git help -a|egrep '^ [a-zA-Z0-9]')
> - do
> - case $i in
> - *--*) : helper pattern;;
> - *) echo $i;;
> - esac
> - done
> -}
> -
> __git_all_commands=
> __git_compute_all_commands ()
> {
> test -n "$__git_all_commands" ||
> - __git_all_commands=$(__git_list_all_commands)
> + __git_all_commands=$(git help --standard)
> }
>
> __git_list_porcelain_commands ()
> diff --git a/generate-cmdlist.sh b/generate-cmdlist.sh
> index 9a4c9b9..7800af3 100755
> --- a/generate-cmdlist.sh
> +++ b/generate-cmdlist.sh
> @@ -9,7 +9,7 @@ struct cmdname_help {
> static struct cmdname_help common_cmds[] = {"
>
> sed -n -e 's/^git-\([^ ]*\)[ ].* common.*/\1/p' command-list.txt |
> -sort |
> +LC_ALL=C LANG=C sort |
> while read cmd
> do
> sed -n '
> @@ -20,4 +20,15 @@ do
> p
> }' "Documentation/git-$cmd.txt"
> done
> +echo "};
> +
> +static const char *standard_cmd[] = {"
> +
> +LC_ALL=C LANG=C sort command-list.txt |
> +sed -n -e '
> + /^git-[^ ]*[ ].* deprecated.*/d
> + /^git-[^ ]*[ ].* nocomplete.*/d
> + s/^git-\([^ ]*\)[ ].*/ "\1",/p
> +'
> +
> echo "};"
> diff --git a/help.c b/help.c
> index 1dfa0b0..2ad10db 100644
> --- a/help.c
> +++ b/help.c
> @@ -182,7 +182,7 @@ void load_command_list(const char *prefix,
> uniq(main_cmds);
> }
>
> - if (env_path) {
> + if (env_path && other_cmds) {
> char *paths, *path, *colon;
> path = paths = xstrdup(env_path);
> while (1) {
> @@ -201,7 +201,33 @@ void load_command_list(const char *prefix,
> sizeof(*other_cmds->names), cmdname_compare);
> uniq(other_cmds);
> }
> - exclude_cmds(other_cmds, main_cmds);
> +
> + if (other_cmds)
> + exclude_cmds(other_cmds, main_cmds);
> +}
> +
> +void limit_to_standard(struct cmdnames *cmds)
> +{
> + int src = 0, dst = 0, ref = 0;
> +
> + while (src < cmds->cnt && ref < ARRAY_SIZE(standard_cmd)) {
> + int cmp = strcmp(cmds->names[src]->name, standard_cmd[ref]);
> + if (cmp < 0) {
> + src++; /* not a standard command */
> + } else if (!cmp) {
> + if (dst != src) {
> + free(cmds->names[dst]);
> + cmds->names[dst] = cmds->names[src];
> + }
> + ref++;
> + dst++;
> + } else {
> + ref++; /* uninstalled standard command */
> + }
> + }
> + for (src = dst; src < cmds->cnt; src++)
> + free(cmds->names[src]);
> + cmds->cnt = dst;
> }
>
> void list_commands(unsigned int colopts,
> diff --git a/help.h b/help.h
> index 0ae5a12..ce0d2a5 100644
> --- a/help.h
> +++ b/help.h
> @@ -21,6 +21,7 @@ extern const char *help_unknown_cmd(const char *cmd);
> extern void load_command_list(const char *prefix,
> struct cmdnames *main_cmds,
> struct cmdnames *other_cmds);
> +extern void limit_to_standard(struct cmdnames *);
> extern void add_cmdname(struct cmdnames *cmds, const char *name, int len);
> /* Here we require that excludes is a sorted list. */
> extern void exclude_cmds(struct cmdnames *cmds, struct cmdnames
> *excludes);
With these two patches, the test passes.
^ permalink raw reply
* Re: t9902 fails
From: Jean-Noël AVILA @ 2013-01-19 10:23 UTC (permalink / raw)
To: Torsten Bögershausen
Cc: Junio C Hamano, Jonathan Nieder, Jeff King, git,
Nguyễn Thái Ngọc Duy, Felipe Contreras
In-Reply-To: <50FA316E.8060807@web.de>
Le samedi 19 janvier 2013 06:38:54, Torsten Bögershausen a écrit :
> On 18.01.13 23:23, Jean-Noël AVILA wrote:
> > Le vendredi 18 janvier 2013 21:15:23, Junio C Hamano a écrit :
> >> Junio C Hamano <gitster@pobox.com> writes:
> >>> How about doing something like this and set that variable in the
> >>> test instead? If STD_ONLY is not set, you will get everything, but
> >>> when STD_ONLY is set, we will stop reading from "help -a" when it
> >>> starts listing additional stuff.
> >
> > I tried both of your propositions but none made test 10 of t9902 pass.
> >
> > Am I supposed to run "make install" before running the test?
>
> No. The test suite could (and should) be run before you make install.
> So a typical sequence could be:
> Run test suite, and if that passes, install the binaries on my system.
> This could look like this on the command line:
> make test && sudo make install
>
> Jean-Noël,
> would it be possible to run
> "git status"
> and share the result with us?
>
> And did you try Jonathans patch?
>
> /Torsten
Hi all,
My workdir is clean.
jnavila@cayenne git (master)]$ make
GEN perl/PM.stamp
SUBDIR gitweb
SUBDIR ../
make[2]: « GIT-VERSION-FILE » est à jour.
GEN git-instaweb
SUBDIR git-gui
SUBDIR gitk-git
make[1]: Rien à faire pour « all ».
SUBDIR perl
SUBDIR git_remote_helpers
SUBDIR templates
[jnavila@cayenne git (master)]$ git branch -vv
attr_pattern 3cb6a4c Add directory pattern matching to attributes
fix_test_t9902 02f55e6 Merge git://bogomips.org/git-svn
maint 611fa18 Add directory pattern matching to attributes
* master 02f55e6 [origin/master] Merge git://bogomips.org/git-svn
next 82c5000 [origin/next: ahead 157, behind 550] Merge branch
'jc/doc-diff-blobs' into next
pu 25f269c [origin/pu: ahead 68, behind 137] Merge branch
'mp/diff-algo-config' into pu
todo 70e0e3e [origin/todo: behind 1] What's cooking (2013/01 #06)
[jnavila@cayenne git (master)]$ git status
# On branch master
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# gitk-git/gitk-wish
nothing added to commit but untracked files present (use "git add" to track)
[jnavila@cayenne git (master)]$ ls -l | grep git-check
-rwxr-xr-x 108 jnavila jnavila 7677476 janv. 19 10:30 git-check-attr
-rwxr-xr-x 108 jnavila jnavila 7677476 janv. 19 10:30 git-checkout
-rwxr-xr-x 108 jnavila jnavila 7677476 janv. 19 10:30 git-checkout-index
-rwxr-xr-x 108 jnavila jnavila 7677476 janv. 19 10:30 git-check-ref-format
If I move git-checkout-branches out of /usr/bin, the test passes. So somehow
GIT_EXEC_PATH is not what is expected.
^ permalink raw reply
* [PATCH 1/2] Change old system name 'GIT' to 'Git'
From: Thomas Ackermann @ 2013-01-19 9:59 UTC (permalink / raw)
To: th.acker, git
In-Reply-To: <732444561.1327663.1358589465467.JavaMail.ngmail@webmail24.arcor-online.net>
Signed-off-by: Thomas Ackermann <th.acker@arcor.de>
---
Documentation/asciidoc.conf | 2 +-
Documentation/everyday.txt | 4 ++--
Documentation/git-clone.txt | 2 +-
Documentation/git-cvsexportcommit.txt | 2 +-
Documentation/git-cvsserver.txt | 8 ++++----
Documentation/git-daemon.txt | 4 ++--
Documentation/git-mv.txt | 2 +-
Documentation/git-send-email.txt | 2 +-
Documentation/git-tools.txt | 14 +++++++-------
Documentation/git-update-ref.txt | 2 +-
Documentation/git.txt | 2 +-
Documentation/gitcore-tutorial.txt | 4 ++--
Documentation/gitglossary.txt | 2 +-
Documentation/gittutorial.txt | 2 +-
Documentation/gitweb.txt | 2 +-
Documentation/gitworkflows.txt | 2 +-
Documentation/glossary-content.txt | 2 +-
Documentation/howto-index.sh | 2 +-
Documentation/howto/rebase-from-internal-branch.txt | 6 +++---
Documentation/howto/revert-branch-rebase.txt | 4 ++--
Documentation/howto/setup-git-server-over-http.txt | 4 ++--
Documentation/technical/api-index-skel.txt | 4 ++--
Documentation/technical/index-format.txt | 6 +++---
Documentation/technical/pack-format.txt | 4 ++--
Documentation/user-manual.txt | 4 ++--
25 files changed, 46 insertions(+), 46 deletions(-)
diff --git a/Documentation/asciidoc.conf b/Documentation/asciidoc.conf
index 1273a85..2c16c53 100644
--- a/Documentation/asciidoc.conf
+++ b/Documentation/asciidoc.conf
@@ -4,7 +4,7 @@
#
# Note, {0} is the manpage section, while {target} is the command.
#
-# Show GIT link as: <command>(<section>); if section is defined, else just show
+# Show Git link as: <command>(<section>); if section is defined, else just show
# the command.
[macros]
diff --git a/Documentation/everyday.txt b/Documentation/everyday.txt
index 048337b..6acfd33 100644
--- a/Documentation/everyday.txt
+++ b/Documentation/everyday.txt
@@ -1,4 +1,4 @@
-Everyday GIT With 20 Commands Or So
+Everyday Git With 20 Commands Or So
===================================
<<Individual Developer (Standalone)>> commands are essential for
@@ -229,7 +229,7 @@ commands in addition to the ones needed by participants.
Examples
~~~~~~~~
-My typical GIT day.::
+My typical Git day.::
+
------------
$ git status <1>
diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt
index 7fefdb0..597048b 100644
--- a/Documentation/git-clone.txt
+++ b/Documentation/git-clone.txt
@@ -125,7 +125,7 @@ objects from the source repository into a pack in the cloned repository.
No checkout of HEAD is performed after the clone is complete.
--bare::
- Make a 'bare' GIT repository. That is, instead of
+ Make a 'bare' Git repository. That is, instead of
creating `<directory>` and placing the administrative
files in `<directory>/.git`, make the `<directory>`
itself the `$GIT_DIR`. This obviously implies the `-n`
diff --git a/Documentation/git-cvsexportcommit.txt b/Documentation/git-cvsexportcommit.txt
index 7f79cec..a671e22 100644
--- a/Documentation/git-cvsexportcommit.txt
+++ b/Documentation/git-cvsexportcommit.txt
@@ -15,7 +15,7 @@ SYNOPSIS
DESCRIPTION
-----------
-Exports a commit from GIT to a CVS checkout, making it easier
+Exports a commit from Git to a CVS checkout, making it easier
to merge patches from a git repository into a CVS repository.
Specify the name of a CVS checkout using the -w switch or execute it
diff --git a/Documentation/git-cvsserver.txt b/Documentation/git-cvsserver.txt
index 88d814a..36d069b 100644
--- a/Documentation/git-cvsserver.txt
+++ b/Documentation/git-cvsserver.txt
@@ -72,9 +72,9 @@ plugin. Most functionality works fine with both of these clients.
LIMITATIONS
-----------
-CVS clients cannot tag, branch or perform GIT merges.
+CVS clients cannot tag, branch or perform Git merges.
-'git-cvsserver' maps GIT branches to CVS modules. This is very different
+'git-cvsserver' maps Git branches to CVS modules. This is very different
from what most CVS users would expect since in CVS modules usually represent
one or more directories.
@@ -130,7 +130,7 @@ Then provide your password via the pserver method, for example:
------
cvs -d:pserver:someuser:somepassword <at> server/path/repo.git co <HEAD_name>
------
-No special setup is needed for SSH access, other than having GIT tools
+No special setup is needed for SSH access, other than having Git tools
in the PATH. If you have clients that do not accept the CVS_SERVER
environment variable, you can rename 'git-cvsserver' to `cvs`.
@@ -197,7 +197,7 @@ allowing access over SSH.
shell is bash, .bashrc may be a reasonable alternative.
5. Clients should now be able to check out the project. Use the CVS 'module'
- name to indicate what GIT 'head' you want to check out. This also sets the
+ name to indicate what Git 'head' you want to check out. This also sets the
name of your newly checked-out directory, unless you tell it otherwise with
`-d <dir_name>`. For example, this checks out 'master' branch to the
`project-master` directory:
diff --git a/Documentation/git-daemon.txt b/Documentation/git-daemon.txt
index 7e5098a..80de4f6 100644
--- a/Documentation/git-daemon.txt
+++ b/Documentation/git-daemon.txt
@@ -51,7 +51,7 @@ OPTIONS
--base-path=<path>::
Remap all the path requests as relative to the given path.
- This is sort of "GIT root" - if you run 'git daemon' with
+ This is sort of "Git root" - if you run 'git daemon' with
'--base-path=/srv/git' on example.com, then if you later try to pull
'git://example.com/hello.git', 'git daemon' will interpret the path
as '/srv/git/hello.git'.
@@ -73,7 +73,7 @@ OPTIONS
whitelist.
--export-all::
- Allow pulling from all directories that look like GIT repositories
+ Allow pulling from all directories that look like Git repositories
(have the 'objects' and 'refs' subdirectories), even if they
do not have the 'git-daemon-export-ok' file.
diff --git a/Documentation/git-mv.txt b/Documentation/git-mv.txt
index e3c8448..bcb79c9 100644
--- a/Documentation/git-mv.txt
+++ b/Documentation/git-mv.txt
@@ -34,7 +34,7 @@ OPTIONS
-k::
Skip move or rename actions which would lead to an error
condition. An error happens when a source is neither existing nor
- controlled by GIT, or when it would overwrite an existing
+ controlled by Git, or when it would overwrite an existing
file unless '-f' is given.
-n::
--dry-run::
diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
index eeb561c..44a1f7c 100644
--- a/Documentation/git-send-email.txt
+++ b/Documentation/git-send-email.txt
@@ -67,7 +67,7 @@ The --cc option must be repeated for each user you want on the cc list.
When '--compose' is used, git send-email will use the From, Subject, and
In-Reply-To headers specified in the message. If the body of the message
(what you type after the headers and a blank line) only contains blank
-(or GIT: prefixed) lines the summary won't be sent, but From, Subject,
+(or Git: prefixed) lines the summary won't be sent, but From, Subject,
and In-Reply-To headers will be used unless they are removed.
+
Missing From or In-Reply-To headers will be prompted for.
diff --git a/Documentation/git-tools.txt b/Documentation/git-tools.txt
index a96403c..8428827 100644
--- a/Documentation/git-tools.txt
+++ b/Documentation/git-tools.txt
@@ -19,24 +19,24 @@ Alternative/Augmentative Porcelains
Cogito is a version control system layered on top of the git tree history
storage system. It aims at seamless user interface and ease of use,
- providing generally smoother user experience than the "raw" Core GIT
+ providing generally smoother user experience than the "raw" Core Git
itself and indeed many other version control systems.
Cogito is no longer maintained as most of its functionality
- is now in core GIT.
+ is now in core Git.
- *pg* (http://www.spearce.org/category/projects/scm/pg/)
- pg is a shell script wrapper around GIT to help the user manage a set of
+ pg is a shell script wrapper around Git to help the user manage a set of
patches to files. pg is somewhat like quilt or StGIT, but it does have a
slightly different feature set.
- *StGit* (http://www.procode.org/stgit/)
- Stacked GIT provides a quilt-like patch management functionality in the
- GIT environment. You can easily manage your patches in the scope of GIT
+ Stacked Git provides a quilt-like patch management functionality in the
+ Git environment. You can easily manage your patches in the scope of Git
until they get merged upstream.
@@ -45,7 +45,7 @@ History Viewers
- *gitk* (shipped with git-core)
- gitk is a simple Tk GUI for browsing history of GIT repositories easily.
+ gitk is a simple Tk GUI for browsing history of Git repositories easily.
- *gitview* (contrib/)
@@ -55,7 +55,7 @@ History Viewers
- *gitweb* (shipped with git-core)
- GITweb provides full-fledged web interface for GIT repositories.
+ GITweb provides full-fledged web interface for Git repositories.
- *qgit* (http://digilander.libero.it/mcostalba/)
diff --git a/Documentation/git-update-ref.txt b/Documentation/git-update-ref.txt
index d377a35..0df13ff 100644
--- a/Documentation/git-update-ref.txt
+++ b/Documentation/git-update-ref.txt
@@ -73,7 +73,7 @@ in ref value. Log lines are formatted as:
Where "oldsha1" is the 40 character hexadecimal value previously
stored in <ref>, "newsha1" is the 40 character hexadecimal value of
<newvalue> and "committer" is the committer's name, email address
-and date in the standard GIT committer ident format.
+and date in the standard Git committer ident format.
Optionally with -m:
diff --git a/Documentation/git.txt b/Documentation/git.txt
index 555250d..1aac71e 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -890,7 +890,7 @@ See also the link:howto-index.html[howto] documents for some useful
examples.
The internals are documented in the
-link:technical/api-index.html[GIT API documentation].
+link:technical/api-index.html[Git API documentation].
Users migrating from CVS may also want to
read linkgit:gitcvs-migration[7].
diff --git a/Documentation/gitcore-tutorial.txt b/Documentation/gitcore-tutorial.txt
index 5325c5a..6a701dd 100644
--- a/Documentation/gitcore-tutorial.txt
+++ b/Documentation/gitcore-tutorial.txt
@@ -16,8 +16,8 @@ This tutorial explains how to use the "core" git commands to set up and
work with a git repository.
If you just need to use git as a revision control system you may prefer
-to start with "A Tutorial Introduction to GIT" (linkgit:gittutorial[7]) or
-link:user-manual.html[the GIT User Manual].
+to start with "A Tutorial Introduction to Git" (linkgit:gittutorial[7]) or
+link:user-manual.html[the Git User Manual].
However, an understanding of these low-level tools can be helpful if
you want to understand git's internals.
diff --git a/Documentation/gitglossary.txt b/Documentation/gitglossary.txt
index d77a45a..6d7b195 100644
--- a/Documentation/gitglossary.txt
+++ b/Documentation/gitglossary.txt
@@ -3,7 +3,7 @@ gitglossary(7)
NAME
----
-gitglossary - A GIT Glossary
+gitglossary - A Git Glossary
SYNOPSIS
--------
diff --git a/Documentation/gittutorial.txt b/Documentation/gittutorial.txt
index f1cb6f3..9dd45c4 100644
--- a/Documentation/gittutorial.txt
+++ b/Documentation/gittutorial.txt
@@ -656,7 +656,7 @@ digressions that may be interesting at this point are:
* linkgit:gitworkflows[7]: Gives an overview of recommended
workflows.
- * link:everyday.html[Everyday GIT with 20 Commands Or So]
+ * link:everyday.html[Everyday Git with 20 Commands Or So]
* linkgit:gitcvs-migration[7]: Git for CVS users.
diff --git a/Documentation/gitweb.txt b/Documentation/gitweb.txt
index 168e8bf..d364c3a 100644
--- a/Documentation/gitweb.txt
+++ b/Documentation/gitweb.txt
@@ -504,7 +504,7 @@ repositories, you can configure Apache like this:
The above configuration expects your public repositories to live under
'/pub/git' and will serve them as `http://git.domain.org/dir-under-pub-git`,
-both as cloneable GIT URL and as browseable gitweb interface. If you then
+both as cloneable Git URL and as browseable gitweb interface. If you then
start your linkgit:git-daemon[1] with `--base-path=/pub/git --export-all`
then you can even use the `git://` URL with exactly the same path.
diff --git a/Documentation/gitworkflows.txt b/Documentation/gitworkflows.txt
index 8b8c6ae..e2e7d65 100644
--- a/Documentation/gitworkflows.txt
+++ b/Documentation/gitworkflows.txt
@@ -242,7 +242,7 @@ tag to the tip of 'master' indicating the release version:
.Release tagging
[caption="Recipe: "]
=====================================
-`git tag -s -m "GIT X.Y.Z" vX.Y.Z master`
+`git tag -s -m "Git X.Y.Z" vX.Y.Z master`
=====================================
You need to push the new tag to a public git server (see
diff --git a/Documentation/glossary-content.txt b/Documentation/glossary-content.txt
index f928b57..7c28aef 100644
--- a/Documentation/glossary-content.txt
+++ b/Documentation/glossary-content.txt
@@ -52,7 +52,7 @@
[[def_cherry-picking]]cherry-picking::
In <<def_SCM,SCM>> jargon, "cherry pick" means to choose a subset of
changes out of a series of changes (typically commits) and record them
- as a new series of changes on top of a different codebase. In GIT, this is
+ as a new series of changes on top of a different codebase. In Git, this is
performed by the "git cherry-pick" command to extract the change introduced
by an existing <<def_commit,commit>> and to record it based on the tip
of the current <<def_branch,branch>> as a new commit.
diff --git a/Documentation/howto-index.sh b/Documentation/howto-index.sh
index 34aa30c..8e82e52 100755
--- a/Documentation/howto-index.sh
+++ b/Documentation/howto-index.sh
@@ -1,7 +1,7 @@
#!/bin/sh
cat <<\EOF
-GIT Howto Index
+Git Howto Index
===============
Here is a collection of mailing list postings made by various
diff --git a/Documentation/howto/rebase-from-internal-branch.txt b/Documentation/howto/rebase-from-internal-branch.txt
index 4627ee4..19ab604 100644
--- a/Documentation/howto/rebase-from-internal-branch.txt
+++ b/Documentation/howto/rebase-from-internal-branch.txt
@@ -4,7 +4,7 @@ Cc: Petr Baudis <pasky@suse.cz>, Linus Torvalds <torvalds@osdl.org>
Subject: Re: sending changesets from the middle of a git tree
Date: Sun, 14 Aug 2005 18:37:39 -0700
Abstract: In this article, JC talks about how he rebases the
- public "pu" branch using the core GIT tools when he updates
+ public "pu" branch using the core Git tools when he updates
the "master" branch, and how "rebase" works. Also discussed
is how this applies to individual developers who sends patches
upstream.
@@ -31,7 +31,7 @@ up. With its basing philosophical ancestry on quilt, this is
the kind of task StGIT is designed to do.
I just have done a simpler one, this time using only the core
-GIT tools.
+Git tools.
I had a handful of commits that were ahead of master in pu, and I
wanted to add some documentation bypassing my usual habit of
@@ -96,7 +96,7 @@ you ran fsck-cache, which is normal. After testing "pu", you
can run "git prune" to get rid of those original three commits.
While I am talking about "git rebase", I should talk about how
-to do cherrypicking using only the core GIT tools.
+to do cherrypicking using only the core Git tools.
Let's go back to the earlier picture, with different labels.
diff --git a/Documentation/howto/revert-branch-rebase.txt b/Documentation/howto/revert-branch-rebase.txt
index a59ced8..84dd839 100644
--- a/Documentation/howto/revert-branch-rebase.txt
+++ b/Documentation/howto/revert-branch-rebase.txt
@@ -12,10 +12,10 @@ How to revert an existing commit
================================
One of the changes I pulled into the 'master' branch turns out to
-break building GIT with GCC 2.95. While they were well intentioned
+break building Git with GCC 2.95. While they were well intentioned
portability fixes, keeping things working with gcc-2.95 was also
important. Here is what I did to revert the change in the 'master'
-branch and to adjust the 'pu' branch, using core GIT tools and
+branch and to adjust the 'pu' branch, using core Git tools and
barebone Porcelain.
First, prepare a throw-away branch in case I screw things up.
diff --git a/Documentation/howto/setup-git-server-over-http.txt b/Documentation/howto/setup-git-server-over-http.txt
index a695f01..e49d785 100644
--- a/Documentation/howto/setup-git-server-over-http.txt
+++ b/Documentation/howto/setup-git-server-over-http.txt
@@ -53,10 +53,10 @@ In effect, this means you're going to be root, or that you're using a
preconfigured WebDAV server.
-Step 1: setup a bare GIT repository
+Step 1: setup a bare Git repository
-----------------------------------
-At the time of writing, git-http-push cannot remotely create a GIT
+At the time of writing, git-http-push cannot remotely create a Git
repository. So we have to do that at the server side with git. Another
option is to generate an empty bare repository at the client and copy
it to the server with a WebDAV client (which is the only option if Git
diff --git a/Documentation/technical/api-index-skel.txt b/Documentation/technical/api-index-skel.txt
index 730cfac..eda8c19 100644
--- a/Documentation/technical/api-index-skel.txt
+++ b/Documentation/technical/api-index-skel.txt
@@ -1,7 +1,7 @@
-GIT API Documents
+Git API Documents
=================
-GIT has grown a set of internal API over time. This collection
+Git has grown a set of internal API over time. This collection
documents them.
////////////////////////////////////////////////////////////////
diff --git a/Documentation/technical/index-format.txt b/Documentation/technical/index-format.txt
index 7324154..6a05ee2 100644
--- a/Documentation/technical/index-format.txt
+++ b/Documentation/technical/index-format.txt
@@ -1,4 +1,4 @@
-GIT index format
+Git index format
================
== The git index file has the following format
@@ -21,9 +21,9 @@ GIT index format
- Extensions
Extensions are identified by signature. Optional extensions can
- be ignored if GIT does not understand them.
+ be ignored if Git does not understand them.
- GIT currently supports cached tree and resolve undo extensions.
+ Git currently supports cached tree and resolve undo extensions.
4-byte extension signature. If the first byte is 'A'..'Z' the
extension is optional and can be ignored.
diff --git a/Documentation/technical/pack-format.txt b/Documentation/technical/pack-format.txt
index a7871fb..e7d07bc 100644
--- a/Documentation/technical/pack-format.txt
+++ b/Documentation/technical/pack-format.txt
@@ -1,4 +1,4 @@
-GIT pack format
+Git pack format
===============
== pack-*.pack files have the following format:
@@ -9,7 +9,7 @@ GIT pack format
The signature is: {'P', 'A', 'C', 'K'}
4-byte version number (network byte order):
- GIT currently accepts version number 2 or 3 but
+ Git currently accepts version number 2 or 3 but
generates version 2 only.
4-byte number of objects contained in the pack (network byte order)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 1b377dc..c93e1a8 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -2299,7 +2299,7 @@ Here are some of the scripts that simplify all this even further.
-------------------------------------------------
==== update script ====
-# Update a branch in my GIT tree. If the branch to be updated
+# Update a branch in my Git tree. If the branch to be updated
# is origin, then pull from kernel.org. Otherwise merge
# origin/master branch into test|release branch
@@ -2357,7 +2357,7 @@ esac
-------------------------------------------------
==== status script ====
-# report on status of my ia64 GIT tree
+# report on status of my ia64 Git tree
gb=$(tput setab 2)
rb=$(tput setab 1)
--
1.8.0.msysgit.0
---
Thomas
^ permalink raw reply related
* [PATCH 0/2] GIT, Git, git
From: Thomas Ackermann @ 2013-01-19 9:57 UTC (permalink / raw)
To: th.acker, git
Git changed its 'official' system name from 'GIT' to 'Git' in v1.6.5.3
(as can be seen in the corresponding release note where 'GIT' was
changed to 'Git' in the header line).
Alas the documention uses 'GIT', 'Git' or even 'git' to refer to the
Git system. So change every occurrence of 'GIT" and 'git' to 'Git'
whenever Git as a system is referred to (but don't do this change
in the release notes because they constitute a history orthogonal
to the history versioned by Git).
[PATCH 1/2] Change old system name 'GIT' to 'Git'
[PATCH 2/2] Change 'git' to 'Git' whenever the whole system is referred to
Documentation/CodingGuidelines | 14 +-
Documentation/SubmittingPatches | 12 +-
Documentation/asciidoc.conf | 2 +-
Documentation/blame-options.txt | 4 +-
Documentation/config.txt | 106 +++++------
Documentation/diff-config.txt | 2 +-
Documentation/diff-options.txt | 4 +-
Documentation/everyday.txt | 10 +-
Documentation/git-apply.txt | 2 +-
Documentation/git-archimport.txt | 14 +-
Documentation/git-archive.txt | 2 +-
Documentation/git-bisect-lk2009.txt | 22 +--
Documentation/git-bisect.txt | 4 +-
Documentation/git-blame.txt | 2 +-
Documentation/git-branch.txt | 2 +-
Documentation/git-bundle.txt | 2 +-
Documentation/git-check-ref-format.txt | 4 +-
Documentation/git-checkout.txt | 4 +-
Documentation/git-clean.txt | 6 +-
Documentation/git-clone.txt | 12 +-
Documentation/git-commit-tree.txt | 2 +-
Documentation/git-commit.txt | 6 +-
Documentation/git-credential-cache.txt | 4 +-
Documentation/git-credential-store.txt | 6 +-
Documentation/git-credential.txt | 6 +-
Documentation/git-cvsexportcommit.txt | 6 +-
Documentation/git-cvsimport.txt | 10 +-
Documentation/git-cvsserver.txt | 20 +-
Documentation/git-daemon.txt | 10 +-
Documentation/git-describe.txt | 2 +-
Documentation/git-diff.txt | 2 +-
Documentation/git-difftool.txt | 2 +-
Documentation/git-fetch.txt | 2 +-
Documentation/git-filter-branch.txt | 4 +-
Documentation/git-format-patch.txt | 10 +-
Documentation/git-fsck.txt | 6 +-
Documentation/git-grep.txt | 2 +-
Documentation/git-hash-object.txt | 2 +-
Documentation/git-help.txt | 2 +-
Documentation/git-http-backend.txt | 2 +-
Documentation/git-index-pack.txt | 6 +-
Documentation/git-init.txt | 16 +-
Documentation/git-log.txt | 2 +-
Documentation/git-ls-files.txt | 2 +-
Documentation/git-merge-index.txt | 4 +-
Documentation/git-merge.txt | 4 +-
Documentation/git-mergetool--lib.txt | 2 +-
Documentation/git-mktag.txt | 4 +-
Documentation/git-mv.txt | 2 +-
Documentation/git-p4.txt | 66 +++----
Documentation/git-pack-objects.txt | 12 +-
Documentation/git-pull.txt | 8 +-
Documentation/git-push.txt | 8 +-
Documentation/git-quiltimport.txt | 4 +-
Documentation/git-rebase.txt | 2 +-
Documentation/git-reflog.txt | 2 +-
Documentation/git-remote-ext.txt | 14 +-
Documentation/git-remote-fd.txt | 10 +-
Documentation/git-remote-helpers.txt | 46 ++---
Documentation/git-replace.txt | 2 +-
Documentation/git-rev-list.txt | 2 +-
Documentation/git-rev-parse.txt | 4 +-
Documentation/git-rm.txt | 8 +-
Documentation/git-send-email.txt | 2 +-
Documentation/git-send-pack.txt | 2 +-
Documentation/git-sh-setup.txt | 4 +-
Documentation/git-show-index.txt | 2 +-
Documentation/git-status.txt | 8 +-
Documentation/git-stripspace.txt | 2 +-
Documentation/git-submodule.txt | 2 +-
Documentation/git-svn.txt | 88 ++++-----
Documentation/git-tag.txt | 2 +-
Documentation/git-tools.txt | 40 ++--
Documentation/git-update-index.txt | 16 +-
Documentation/git-update-ref.txt | 2 +-
Documentation/git-upload-archive.txt | 2 +-
Documentation/git-upload-pack.txt | 2 +-
Documentation/git-var.txt | 12 +-
Documentation/git-verify-pack.txt | 2 +-
Documentation/git-verify-tag.txt | 2 +-
Documentation/git-web--browse.txt | 4 +-
Documentation/git-whatchanged.txt | 4 +-
Documentation/git.txt | 90 ++++-----
Documentation/gitattributes.txt | 68 +++----
Documentation/gitcli.txt | 14 +-
Documentation/gitcore-tutorial.txt | 150 +++++++--------
Documentation/gitcredentials.txt | 24 +--
Documentation/gitcvs-migration.txt | 20 +-
Documentation/gitdiffcore.txt | 2 +-
Documentation/gitglossary.txt | 4 +-
Documentation/githooks.txt | 8 +-
Documentation/gitignore.txt | 22 +--
Documentation/gitk.txt | 8 +-
Documentation/gitmodules.txt | 4 +-
Documentation/gitnamespaces.txt | 2 +-
Documentation/gitrepository-layout.txt | 10 +-
Documentation/gitrevisions.txt | 2 +-
Documentation/gittutorial-2.txt | 38 ++--
Documentation/gittutorial.txt | 48 ++---
Documentation/gitweb.conf.txt | 32 ++--
Documentation/gitweb.txt | 22 +--
Documentation/gitworkflows.txt | 6 +-
Documentation/glossary-content.txt | 58 +++---
Documentation/howto-index.sh | 4 +-
Documentation/howto/maintain-git.txt | 6 +-
Documentation/howto/new-command.txt | 20 +-
.../howto/rebase-from-internal-branch.txt | 6 +-
Documentation/howto/rebuild-from-update-hook.txt | 8 +-
.../howto/recover-corrupted-blob-object.txt | 4 +-
Documentation/howto/revert-a-faulty-merge.txt | 2 +-
Documentation/howto/revert-branch-rebase.txt | 4 +-
Documentation/howto/setup-git-server-over-http.txt | 18 +-
Documentation/howto/use-git-daemon.txt | 2 +-
.../howto/using-signed-tag-in-pull-request.txt | 4 +-
Documentation/i18n.txt | 8 +-
Documentation/merge-config.txt | 8 +-
Documentation/rev-list-options.txt | 4 +-
Documentation/revisions.txt | 2 +-
Documentation/technical/api-builtin.txt | 2 +-
Documentation/technical/api-config.txt | 10 +-
Documentation/technical/api-credentials.txt | 16 +-
Documentation/technical/api-directory-listing.txt | 2 +-
Documentation/technical/api-index-skel.txt | 4 +-
Documentation/technical/api-parse-options.txt | 2 +-
Documentation/technical/api-remote.txt | 2 +-
Documentation/technical/index-format.txt | 8 +-
Documentation/technical/pack-format.txt | 4 +-
Documentation/technical/pack-heuristics.txt | 20 +-
Documentation/technical/racy-git.txt | 26 +--
Documentation/urls-remotes.txt | 2 +-
Documentation/urls.txt | 2 +-
Documentation/user-manual.txt | 212 ++++++++++-----------
132 files changed, 904 insertions(+), 904 deletions(-)
---
Thomas
^ permalink raw reply
* [PATCH 2/2] help --standard: list standard commands
From: Junio C Hamano @ 2013-01-19 8:02 UTC (permalink / raw)
To: git
Cc: Torsten Bögershausen, Jean-Noël AVILA, Jonathan Nieder,
Jeff King, Nguyễn Thái Ngọc Duy,
Felipe Contreras
In-Reply-To: <7vpq11ob4w.fsf_-_@alter.siamese.dyndns.org>
If you run "make" on a branch that adds "git check-ignore", checkout
an older branch that did not know about the command without "make clean",
and the run t9902 test, the completion script fails to exclude the
"check-ignore" command from candidates to complete "check".
This is because the completion script asks "git help -a" to show
every executable that begins with "git-" in the GIT_EXEC_PATH, and
because we run tests with GIT_EXEC_PATH set to the top of the
working tree, that has the executable we just built, in order to
test these before installing. Leftover "git check-ignore" that we
did not build for the current version gets in the way.
One way to solve this is to restrict the completion to only the
commands we know about.
Note that this will make the completion useless in real life for
some people, as they do want to get their custom commands on their
$PATH to be included in the completion.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
* This is not a real patch, for the reasons stated.
builtin/help.c | 17 ++++++++++++++---
command-list.txt | 4 ++--
contrib/completion/git-completion.bash | 14 +-------------
generate-cmdlist.sh | 13 ++++++++++++-
help.c | 30 ++++++++++++++++++++++++++++--
help.h | 1 +
6 files changed, 58 insertions(+), 21 deletions(-)
diff --git a/builtin/help.c b/builtin/help.c
index 6067a61..32e7d64 100644
--- a/builtin/help.c
+++ b/builtin/help.c
@@ -35,11 +35,16 @@ enum help_format {
static const char *html_path;
-static int show_all = 0;
+#define HELP_SHOW_ALL 1
+#define HELP_SHOW_STANDARD 2
+static int show_what;
static unsigned int colopts;
static enum help_format help_format = HELP_FORMAT_NONE;
static struct option builtin_help_options[] = {
- OPT_BOOLEAN('a', "all", &show_all, N_("print all available commands")),
+ OPT_SET_INT('a', "all", &show_what, N_("print all available commands"),
+ HELP_SHOW_ALL),
+ OPT_SET_INT(0, "standard", &show_what, N_("print all available commands"),
+ HELP_SHOW_STANDARD),
OPT_SET_INT('m', "man", &help_format, N_("show man page"), HELP_FORMAT_MAN),
OPT_SET_INT('w', "web", &help_format, N_("show manual in web browser"),
HELP_FORMAT_WEB),
@@ -424,12 +429,18 @@ int cmd_help(int argc, const char **argv, const char *prefix)
builtin_help_usage, 0);
parsed_help_format = help_format;
- if (show_all) {
+ if (show_what == HELP_SHOW_ALL) {
git_config(git_help_config, NULL);
printf(_("usage: %s%s"), _(git_usage_string), "\n\n");
list_commands(colopts, &main_cmds, &other_cmds);
printf("%s\n", _(git_more_info_string));
return 0;
+ } else if (show_what == HELP_SHOW_STANDARD) {
+ int i;
+ limit_to_standard(&main_cmds);
+ for (i = 0; i < main_cmds.cnt; i++)
+ printf("%s\n", main_cmds.names[i]->name);
+ return 0;
}
if (!argv[0]) {
diff --git a/command-list.txt b/command-list.txt
index 7e8cfec..94ce8ec 100644
--- a/command-list.txt
+++ b/command-list.txt
@@ -116,8 +116,8 @@ git-show mainporcelain common
git-show-branch ancillaryinterrogators
git-show-index plumbinginterrogators
git-show-ref plumbinginterrogators
-git-sh-i18n purehelpers
-git-sh-setup purehelpers
+git-sh-i18n purehelpers nocomplete
+git-sh-setup purehelpers nocomplete
git-stash mainporcelain
git-status mainporcelain common
git-stripspace purehelpers
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index a4c48e1..46f22af 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -531,23 +531,11 @@ __git_complete_strategy ()
return 1
}
-__git_list_all_commands ()
-{
- local i IFS=" "$'\n'
- for i in $(git help -a|egrep '^ [a-zA-Z0-9]')
- do
- case $i in
- *--*) : helper pattern;;
- *) echo $i;;
- esac
- done
-}
-
__git_all_commands=
__git_compute_all_commands ()
{
test -n "$__git_all_commands" ||
- __git_all_commands=$(__git_list_all_commands)
+ __git_all_commands=$(git help --standard)
}
__git_list_porcelain_commands ()
diff --git a/generate-cmdlist.sh b/generate-cmdlist.sh
index 9a4c9b9..7800af3 100755
--- a/generate-cmdlist.sh
+++ b/generate-cmdlist.sh
@@ -9,7 +9,7 @@ struct cmdname_help {
static struct cmdname_help common_cmds[] = {"
sed -n -e 's/^git-\([^ ]*\)[ ].* common.*/\1/p' command-list.txt |
-sort |
+LC_ALL=C LANG=C sort |
while read cmd
do
sed -n '
@@ -20,4 +20,15 @@ do
p
}' "Documentation/git-$cmd.txt"
done
+echo "};
+
+static const char *standard_cmd[] = {"
+
+LC_ALL=C LANG=C sort command-list.txt |
+sed -n -e '
+ /^git-[^ ]*[ ].* deprecated.*/d
+ /^git-[^ ]*[ ].* nocomplete.*/d
+ s/^git-\([^ ]*\)[ ].*/ "\1",/p
+'
+
echo "};"
diff --git a/help.c b/help.c
index 1dfa0b0..2ad10db 100644
--- a/help.c
+++ b/help.c
@@ -182,7 +182,7 @@ void load_command_list(const char *prefix,
uniq(main_cmds);
}
- if (env_path) {
+ if (env_path && other_cmds) {
char *paths, *path, *colon;
path = paths = xstrdup(env_path);
while (1) {
@@ -201,7 +201,33 @@ void load_command_list(const char *prefix,
sizeof(*other_cmds->names), cmdname_compare);
uniq(other_cmds);
}
- exclude_cmds(other_cmds, main_cmds);
+
+ if (other_cmds)
+ exclude_cmds(other_cmds, main_cmds);
+}
+
+void limit_to_standard(struct cmdnames *cmds)
+{
+ int src = 0, dst = 0, ref = 0;
+
+ while (src < cmds->cnt && ref < ARRAY_SIZE(standard_cmd)) {
+ int cmp = strcmp(cmds->names[src]->name, standard_cmd[ref]);
+ if (cmp < 0) {
+ src++; /* not a standard command */
+ } else if (!cmp) {
+ if (dst != src) {
+ free(cmds->names[dst]);
+ cmds->names[dst] = cmds->names[src];
+ }
+ ref++;
+ dst++;
+ } else {
+ ref++; /* uninstalled standard command */
+ }
+ }
+ for (src = dst; src < cmds->cnt; src++)
+ free(cmds->names[src]);
+ cmds->cnt = dst;
}
void list_commands(unsigned int colopts,
diff --git a/help.h b/help.h
index 0ae5a12..ce0d2a5 100644
--- a/help.h
+++ b/help.h
@@ -21,6 +21,7 @@ extern const char *help_unknown_cmd(const char *cmd);
extern void load_command_list(const char *prefix,
struct cmdnames *main_cmds,
struct cmdnames *other_cmds);
+extern void limit_to_standard(struct cmdnames *);
extern void add_cmdname(struct cmdnames *cmds, const char *name, int len);
/* Here we require that excludes is a sorted list. */
extern void exclude_cmds(struct cmdnames *cmds, struct cmdnames *excludes);
--
1.8.1.1.454.g48d39c0
^ permalink raw reply related
* [PATCH 1/2] help: include <common-cmds.h> only in one file
From: Junio C Hamano @ 2013-01-19 8:00 UTC (permalink / raw)
To: git
Cc: Torsten Bögershausen, Jean-Noël AVILA, Jonathan Nieder,
Jeff King, Nguyễn Thái Ngọc Duy,
Felipe Contreras
In-Reply-To: <7vwqv9obie.fsf_-_@alter.siamese.dyndns.org>
This header not only declares but also defines the contents of the
array that holds the list of command names and help text. Do not
include it in multiple places to waste text space.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
* This is a real "cleanup" patch.
builtin/help.c | 18 ------------------
help.c | 17 +++++++++++++++++
2 files changed, 17 insertions(+), 18 deletions(-)
diff --git a/builtin/help.c b/builtin/help.c
index bd86253..6067a61 100644
--- a/builtin/help.c
+++ b/builtin/help.c
@@ -6,7 +6,6 @@
#include "cache.h"
#include "builtin.h"
#include "exec_cmd.h"
-#include "common-cmds.h"
#include "parse-options.h"
#include "run-command.h"
#include "column.h"
@@ -287,23 +286,6 @@ static int git_help_config(const char *var, const char *value, void *cb)
static struct cmdnames main_cmds, other_cmds;
-void list_common_cmds_help(void)
-{
- int i, longest = 0;
-
- for (i = 0; i < ARRAY_SIZE(common_cmds); i++) {
- if (longest < strlen(common_cmds[i].name))
- longest = strlen(common_cmds[i].name);
- }
-
- puts(_("The most commonly used git commands are:"));
- for (i = 0; i < ARRAY_SIZE(common_cmds); i++) {
- printf(" %s ", common_cmds[i].name);
- mput_char(' ', longest - strlen(common_cmds[i].name));
- puts(_(common_cmds[i].help));
- }
-}
-
static int is_git_command(const char *s)
{
return is_in_cmdlist(&main_cmds, s) ||
diff --git a/help.c b/help.c
index 2a42ec6..1dfa0b0 100644
--- a/help.c
+++ b/help.c
@@ -223,6 +223,23 @@ void list_commands(unsigned int colopts,
}
}
+void list_common_cmds_help(void)
+{
+ int i, longest = 0;
+
+ for (i = 0; i < ARRAY_SIZE(common_cmds); i++) {
+ if (longest < strlen(common_cmds[i].name))
+ longest = strlen(common_cmds[i].name);
+ }
+
+ puts(_("The most commonly used git commands are:"));
+ for (i = 0; i < ARRAY_SIZE(common_cmds); i++) {
+ printf(" %s ", common_cmds[i].name);
+ mput_char(' ', longest - strlen(common_cmds[i].name));
+ puts(_(common_cmds[i].help));
+ }
+}
+
int is_in_cmdlist(struct cmdnames *c, const char *s)
{
int i;
--
1.8.1.1.454.g48d39c0
^ permalink raw reply related
* Re: [PATCH v2 4/8] git_remote_helpers: use 2to3 if building with Python 3
From: Sverre Rabbelier @ 2013-01-19 7:52 UTC (permalink / raw)
To: John Keeping; +Cc: Junio C Hamano, Michael Haggerty, Git List, Pete Wyckoff
In-Reply-To: <20130118103241.GM4574@serenity.lan>
Assuming you tried this out on both 2.x and 3.x:
Acked-by: Sverre Rabbelier <srabbelier@gmail.com>
On Fri, Jan 18, 2013 at 2:32 AM, John Keeping <john@keeping.me.uk> wrote:
> On Thu, Jan 17, 2013 at 09:15:08PM -0800, Sverre Rabbelier wrote:
>> On Thu, Jan 17, 2013 at 10:53 AM, John Keeping <john@keeping.me.uk> wrote:
>> > [1] http://wiki.python.org/moin/PortingPythonToPy3k
>>
>> This link seems dead.
>
> Looks like the Python wiki is down [1].
>
> I'll replace it with [2] since the content is similar and it should be
> easier to find a mirror of the Python documentation than of the wiki.
>
> [1] http://pyfound.blogspot.co.uk/2013/01/wikipythonorg-compromised.html
> [2] http://docs.python.org/3.3/howto/pyporting.html#during-installation
>
>
> John
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re* t9902 fails
From: Junio C Hamano @ 2013-01-19 7:52 UTC (permalink / raw)
To: Torsten Bögershausen
Cc: Jean-Noël AVILA, Jonathan Nieder, Jeff King, git,
Nguyễn Thái Ngọc Duy, Felipe Contreras
In-Reply-To: <50FA316E.8060807@web.de>
Torsten Bögershausen <tboegi@web.de> writes:
> would it be possible to run
> "git status"
> and share the result with us?
>
> And did you try Jonathans patch?
It may hide the immediate issue, but I am afraid Jonathan's patch
does not fix anything fundamental. If you do this:
git checkout next
make
git checkout master ;# without 'make clean'
make && cd t && sh ./t9902-*.sh
then the completion machinery will see the leftover git-check-ignore
at the top of the working tree (which is the $GIT_EXEC_PATH) and the
test that expects "check" to expand only to "checkout" will fail,
because 'master' does not have exclusion definition for check-ignore,
even though it knows check-attr, check-ref-format and checkout-index
are to be excluded as "plumbing".
So if you come up with a brilliant idea to add "git cherry-pack"
command and did this:
git checkout -b tb/cherry-pack
edit Makefile builtin/cherry-pack.c builtin.h git.c ...
git add builtin/cherry-pack.c
make test
git commit -a -m "cherry-pack: new command"
git checkout master ;# without 'make clean'
make && cd t && sh ./t9902-*.sh
the test will break exactly the same way.
If we really wanted to exclude random build artifacts that the
current checkout did not build, you have to do one of these things:
(1) at the beginning of t9902, "rm -fr" a temporary location,
install the built product with a custom DESTDIR set to that
temporary location that we now know is empty, and point
GIT_EXEC_PATH to the libexec/git-core directory in that
temporary location, so that "git help -a" run in the completion
script will find _only_ the executable we would install; or
(2) instead of being inclusive, collecting all executable in
GIT_EXEC_PATH that happens to be named "git-", add a mode to
"git help" that lists those that we know to be standard
commands that the users may want to complete from the command
line.
An outline to do (2) would look like this patch, but I didn't check
other consumers of command-list.txt, so this may be breaking them in
unplanned ways.
builtin/help.c | 35 ++++++++++---------------
command-list.txt | 4 +--
contrib/completion/git-completion.bash | 14 +---------
generate-cmdlist.sh | 13 +++++++++-
help.c | 47 ++++++++++++++++++++++++++++++++--
help.h | 1 +
6 files changed, 75 insertions(+), 39 deletions(-)
diff --git a/builtin/help.c b/builtin/help.c
index bd86253..32e7d64 100644
--- a/builtin/help.c
+++ b/builtin/help.c
@@ -6,7 +6,6 @@
#include "cache.h"
#include "builtin.h"
#include "exec_cmd.h"
-#include "common-cmds.h"
#include "parse-options.h"
#include "run-command.h"
#include "column.h"
@@ -36,11 +35,16 @@ enum help_format {
static const char *html_path;
-static int show_all = 0;
+#define HELP_SHOW_ALL 1
+#define HELP_SHOW_STANDARD 2
+static int show_what;
static unsigned int colopts;
static enum help_format help_format = HELP_FORMAT_NONE;
static struct option builtin_help_options[] = {
- OPT_BOOLEAN('a', "all", &show_all, N_("print all available commands")),
+ OPT_SET_INT('a', "all", &show_what, N_("print all available commands"),
+ HELP_SHOW_ALL),
+ OPT_SET_INT(0, "standard", &show_what, N_("print all available commands"),
+ HELP_SHOW_STANDARD),
OPT_SET_INT('m', "man", &help_format, N_("show man page"), HELP_FORMAT_MAN),
OPT_SET_INT('w', "web", &help_format, N_("show manual in web browser"),
HELP_FORMAT_WEB),
@@ -287,23 +291,6 @@ static int git_help_config(const char *var, const char *value, void *cb)
static struct cmdnames main_cmds, other_cmds;
-void list_common_cmds_help(void)
-{
- int i, longest = 0;
-
- for (i = 0; i < ARRAY_SIZE(common_cmds); i++) {
- if (longest < strlen(common_cmds[i].name))
- longest = strlen(common_cmds[i].name);
- }
-
- puts(_("The most commonly used git commands are:"));
- for (i = 0; i < ARRAY_SIZE(common_cmds); i++) {
- printf(" %s ", common_cmds[i].name);
- mput_char(' ', longest - strlen(common_cmds[i].name));
- puts(_(common_cmds[i].help));
- }
-}
-
static int is_git_command(const char *s)
{
return is_in_cmdlist(&main_cmds, s) ||
@@ -442,12 +429,18 @@ int cmd_help(int argc, const char **argv, const char *prefix)
builtin_help_usage, 0);
parsed_help_format = help_format;
- if (show_all) {
+ if (show_what == HELP_SHOW_ALL) {
git_config(git_help_config, NULL);
printf(_("usage: %s%s"), _(git_usage_string), "\n\n");
list_commands(colopts, &main_cmds, &other_cmds);
printf("%s\n", _(git_more_info_string));
return 0;
+ } else if (show_what == HELP_SHOW_STANDARD) {
+ int i;
+ limit_to_standard(&main_cmds);
+ for (i = 0; i < main_cmds.cnt; i++)
+ printf("%s\n", main_cmds.names[i]->name);
+ return 0;
}
if (!argv[0]) {
diff --git a/command-list.txt b/command-list.txt
index 7e8cfec..94ce8ec 100644
--- a/command-list.txt
+++ b/command-list.txt
@@ -116,8 +116,8 @@ git-show mainporcelain common
git-show-branch ancillaryinterrogators
git-show-index plumbinginterrogators
git-show-ref plumbinginterrogators
-git-sh-i18n purehelpers
-git-sh-setup purehelpers
+git-sh-i18n purehelpers nocomplete
+git-sh-setup purehelpers nocomplete
git-stash mainporcelain
git-status mainporcelain common
git-stripspace purehelpers
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index a4c48e1..46f22af 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -531,23 +531,11 @@ __git_complete_strategy ()
return 1
}
-__git_list_all_commands ()
-{
- local i IFS=" "$'\n'
- for i in $(git help -a|egrep '^ [a-zA-Z0-9]')
- do
- case $i in
- *--*) : helper pattern;;
- *) echo $i;;
- esac
- done
-}
-
__git_all_commands=
__git_compute_all_commands ()
{
test -n "$__git_all_commands" ||
- __git_all_commands=$(__git_list_all_commands)
+ __git_all_commands=$(git help --standard)
}
__git_list_porcelain_commands ()
diff --git a/generate-cmdlist.sh b/generate-cmdlist.sh
index 9a4c9b9..7800af3 100755
--- a/generate-cmdlist.sh
+++ b/generate-cmdlist.sh
@@ -9,7 +9,7 @@ struct cmdname_help {
static struct cmdname_help common_cmds[] = {"
sed -n -e 's/^git-\([^ ]*\)[ ].* common.*/\1/p' command-list.txt |
-sort |
+LC_ALL=C LANG=C sort |
while read cmd
do
sed -n '
@@ -20,4 +20,15 @@ do
p
}' "Documentation/git-$cmd.txt"
done
+echo "};
+
+static const char *standard_cmd[] = {"
+
+LC_ALL=C LANG=C sort command-list.txt |
+sed -n -e '
+ /^git-[^ ]*[ ].* deprecated.*/d
+ /^git-[^ ]*[ ].* nocomplete.*/d
+ s/^git-\([^ ]*\)[ ].*/ "\1",/p
+'
+
echo "};"
diff --git a/help.c b/help.c
index 2a42ec6..2ad10db 100644
--- a/help.c
+++ b/help.c
@@ -182,7 +182,7 @@ void load_command_list(const char *prefix,
uniq(main_cmds);
}
- if (env_path) {
+ if (env_path && other_cmds) {
char *paths, *path, *colon;
path = paths = xstrdup(env_path);
while (1) {
@@ -201,7 +201,33 @@ void load_command_list(const char *prefix,
sizeof(*other_cmds->names), cmdname_compare);
uniq(other_cmds);
}
- exclude_cmds(other_cmds, main_cmds);
+
+ if (other_cmds)
+ exclude_cmds(other_cmds, main_cmds);
+}
+
+void limit_to_standard(struct cmdnames *cmds)
+{
+ int src = 0, dst = 0, ref = 0;
+
+ while (src < cmds->cnt && ref < ARRAY_SIZE(standard_cmd)) {
+ int cmp = strcmp(cmds->names[src]->name, standard_cmd[ref]);
+ if (cmp < 0) {
+ src++; /* not a standard command */
+ } else if (!cmp) {
+ if (dst != src) {
+ free(cmds->names[dst]);
+ cmds->names[dst] = cmds->names[src];
+ }
+ ref++;
+ dst++;
+ } else {
+ ref++; /* uninstalled standard command */
+ }
+ }
+ for (src = dst; src < cmds->cnt; src++)
+ free(cmds->names[src]);
+ cmds->cnt = dst;
}
void list_commands(unsigned int colopts,
@@ -223,6 +249,23 @@ void list_commands(unsigned int colopts,
}
}
+void list_common_cmds_help(void)
+{
+ int i, longest = 0;
+
+ for (i = 0; i < ARRAY_SIZE(common_cmds); i++) {
+ if (longest < strlen(common_cmds[i].name))
+ longest = strlen(common_cmds[i].name);
+ }
+
+ puts(_("The most commonly used git commands are:"));
+ for (i = 0; i < ARRAY_SIZE(common_cmds); i++) {
+ printf(" %s ", common_cmds[i].name);
+ mput_char(' ', longest - strlen(common_cmds[i].name));
+ puts(_(common_cmds[i].help));
+ }
+}
+
int is_in_cmdlist(struct cmdnames *c, const char *s)
{
int i;
diff --git a/help.h b/help.h
index 0ae5a12..ce0d2a5 100644
--- a/help.h
+++ b/help.h
@@ -21,6 +21,7 @@ extern const char *help_unknown_cmd(const char *cmd);
extern void load_command_list(const char *prefix,
struct cmdnames *main_cmds,
struct cmdnames *other_cmds);
+extern void limit_to_standard(struct cmdnames *);
extern void add_cmdname(struct cmdnames *cmds, const char *name, int len);
/* Here we require that excludes is a sorted list. */
extern void exclude_cmds(struct cmdnames *cmds, struct cmdnames *excludes);
^ permalink raw reply related
* [PATCH 3/3] t0050: Use TAB for indentation
From: Torsten Bögershausen @ 2013-01-19 7:19 UTC (permalink / raw)
To: git; +Cc: tboegi
Use one TAB for indentation and remove empty lines
Signed-off-by: Torsten Bögershausen <tboegi@web.de>
---
t/t0050-filesystem.sh | 48 +++++++++++++++---------------------------------
1 file changed, 15 insertions(+), 33 deletions(-)
diff --git a/t/t0050-filesystem.sh b/t/t0050-filesystem.sh
index a6fa3c5..05d78d2 100755
--- a/t/t0050-filesystem.sh
+++ b/t/t0050-filesystem.sh
@@ -29,12 +29,10 @@ test_have_prereq SYMLINKS ||
if test_have_prereq CASE_INSENSITIVE_FS
then
test_expect_success "detection of case insensitive filesystem during repo init" '
-
test $(git config --bool core.ignorecase) = true
'
else
test_expect_success "detection of case insensitive filesystem during repo init" '
-
test_must_fail git config --bool core.ignorecase >/dev/null ||
test $(git config --bool core.ignorecase) = false
'
@@ -43,20 +41,17 @@ fi
if test_have_prereq SYMLINKS
then
test_expect_success "detection of filesystem w/o symlink support during repo init" '
-
test_must_fail git config --bool core.symlinks ||
test "$(git config --bool core.symlinks)" = true
'
else
test_expect_success "detection of filesystem w/o symlink support during repo init" '
-
v=$(git config --bool core.symlinks) &&
test "$v" = false
'
fi
test_expect_success "setup case tests" '
-
git config core.ignorecase true &&
touch camelcase &&
git add camelcase &&
@@ -67,29 +62,23 @@ test_expect_success "setup case tests" '
git mv tmp CamelCase &&
git commit -m "rename" &&
git checkout -f master
-
'
$test_case 'rename (case change)' '
-
git mv camelcase CamelCase &&
git commit -m "rename"
-
'
test_expect_success 'merge (case change)' '
-
rm -f CamelCase &&
rm -f camelcase &&
git reset --hard initial &&
git merge topic
-
'
test_expect_failure CASE_INSENSITIVE_FS 'add (with different case)' '
-
git reset --hard initial &&
rm camelcase &&
echo 1 >CamelCase &&
@@ -97,37 +86,30 @@ test_expect_failure CASE_INSENSITIVE_FS 'add (with different case)' '
camel=$(git ls-files | grep -i camelcase) &&
test $(echo "$camel" | wc -l) = 1 &&
test "z$(git cat-file blob :$camel)" = z1
-
'
test_expect_success "setup unicode normalization tests" '
-
- test_create_repo unicode &&
- cd unicode &&
- touch "$aumlcdiar" &&
- git add "$aumlcdiar" &&
- git commit -m initial &&
- git tag initial &&
- git checkout -b topic &&
- git mv $aumlcdiar tmp &&
- git mv tmp "$auml" &&
- git commit -m rename &&
- git checkout -f master
-
+ test_create_repo unicode &&
+ cd unicode &&
+ touch "$aumlcdiar" &&
+ git add "$aumlcdiar" &&
+ git commit -m initial &&
+ git tag initial &&
+ git checkout -b topic &&
+ git mv $aumlcdiar tmp &&
+ git mv tmp "$auml" &&
+ git commit -m rename &&
+ git checkout -f master
'
$test_unicode 'rename (silent unicode normalization)' '
-
- git mv "$aumlcdiar" "$auml" &&
- git commit -m rename
-
+ git mv "$aumlcdiar" "$auml" &&
+ git commit -m rename
'
$test_unicode 'merge (silent unicode normalization)' '
-
- git reset --hard initial &&
- git merge topic
-
+ git reset --hard initial &&
+ git merge topic
'
test_done
--
1.8.0.197.g5a90748
^ permalink raw reply related
* [PATCH 2/3] t0050: honor CASE_INSENSITIVE_FS in add (with different case)
From: Torsten Bögershausen @ 2013-01-19 7:19 UTC (permalink / raw)
To: git; +Cc: tboegi
The test case "add (with different case)" indicates a
known breakage when run on a case sensitive file system.
The test is invalid for case sensitive file system,
check the precondition CASE_INSENSITIVE_FS before running it.
Signed-off-by: Torsten Bögershausen <tboegi@web.de>
---
t/t0050-filesystem.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/t/t0050-filesystem.sh b/t/t0050-filesystem.sh
index ccd685d..a6fa3c5 100755
--- a/t/t0050-filesystem.sh
+++ b/t/t0050-filesystem.sh
@@ -88,7 +88,7 @@ test_expect_success 'merge (case change)' '
-test_expect_failure 'add (with different case)' '
+test_expect_failure CASE_INSENSITIVE_FS 'add (with different case)' '
git reset --hard initial &&
rm camelcase &&
--
1.8.0.197.g5a90748
^ permalink raw reply related
* [PATCH 1/3] t0050: known breakage vanished in merge (case change)
From: Torsten Bögershausen @ 2013-01-19 7:19 UTC (permalink / raw)
To: git; +Cc: tboegi
This test case has passed ever since:
commit 0047dd2fd1fc1980913901c5fa098357482c2842
Author: Steffen Prohaska <prohaska@zib.de>
Date: Thu May 15 07:19:54 2008 +0200
t0050: Fix merge test on case sensitive file systems
Demand it to pass by using test_expect_success
Signed-off-by: Torsten Bögershausen <tboegi@web.de>
---
t/t0050-filesystem.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/t/t0050-filesystem.sh b/t/t0050-filesystem.sh
index 78816d9..ccd685d 100755
--- a/t/t0050-filesystem.sh
+++ b/t/t0050-filesystem.sh
@@ -77,7 +77,7 @@ $test_case 'rename (case change)' '
'
-$test_case 'merge (case change)' '
+test_expect_success 'merge (case change)' '
rm -f CamelCase &&
rm -f camelcase &&
--
1.8.0.197.g5a90748
^ permalink raw reply related
* Re: [PATCH 0/2] Hiding some refs in ls-remote
From: Michael Haggerty @ 2013-01-19 6:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, spearce, mfick
In-Reply-To: <1358555826-11883-1-git-send-email-gitster@pobox.com>
On 01/19/2013 01:37 AM, Junio C Hamano wrote:
> This is an early preview of reducing the network cost while talking
> with a repository with tons of refs, most of which are of use by
> very narrow audiences (e.g. refs under Gerrit's refs/changes/ are
> useful only for people who are interested in the changes under
> review). As long as these narrow audiences have a way to learn the
> names of refs or objects pointed at by the refs out-of-band, it is
> not necessary to advertise these refs.
>
> On the server end, you tell upload-pack that some refs do not have
> to be advertised with the uploadPack.hiderefs multi-valued
> configuration variable:
>
> [uploadPack]
> hiderefs = refs/changes
>
> The changes necessary on the client side to allow fetching objects
> at the tip of a ref in hidden hierarchies are much more involved and
> not part of this early preview, but the end user UI is expected to
> be like these:
>
> $ git fetch $there refs/changes/72/41672/1
> $ git fetch $there 9598d59cdc098c5d9094d68024475e2430343182
>
> That is, you ask for a refname as usual even though it is not part
> of ls-remote response, or you ask for the commit object that is at
> the tip of whatever hidden ref you are interested in.
Although I can understand the pain of slow network performance, somehow
this proposal gives me the feeling of being expeditious rather than elegant.
Could the problem be solved in some other way? Maybe such references
could be stored in a second repository or in a separate namespace (in
the sense of gitnamespaces(7)) to prevent their creating overhead when
they are unneeded?
And *if* reference hiding makes sense, it seems to me that the client,
not the server, should be the one who decides which server references it
is interested in (though I understand that would require a protocol
change). Otherwise the git repository *relies* on out-of-band channels
for its functionality. If I understand correctly, a user would have *no
way* to discover, via git, what hidden references are contained in a
remote repository, or indeed even that the repo contains a hidden
namespace. For example this would make it impossible to clean up
obsolete "hidden" references on a remote repository without the
supplementary information stored elsewhere. And if anybody accidentally
creates a reference in a hidden namespace by hand, it will just sit
there undetectably, forever.
I assume (though I've never checked) that a server does not let a client
ask for a SHA1 that is not currently reachable from a server-side
reference, and I assume that that you are not proposing to change this
policy. But allowing objects to be fetched from a hidden reference
opens up some "interesting" possibilities:
* A pusher could upload arbitrary content to a public git server under a
cryptic hidden reference name. Most people would be completely unable
to see this content, unless given the SHA1 or the reference name by the
pusher. Thus this mechanism could be used as a dark channel to exchange
arbitrary data relatively secretly.
* Somebody could push a trojan version of code to a hidden reference in
a project, then pass the SHA1 to a victim. The victim might trust the
code because it comes from a known project website, even though the code
would be invisible to other project developers and thus impossible for
them to audit. And even if they learned about the trojan's SHA1 they
would be unable to remove it from their repository because they have no
way to find out the name of the hidden reference!
Obviously these hacks would only be possible for a bad guy with push
privileges to a repository that has turned on hidden references, but I
think they are sobering nevertheless.
These worries would go away if reference hiding were configured on the
client rather than on the server.
A second point: currently, the output of "git show-ref -d" and "git
ls-remote ." are almost identical. Under your proposal, I believe that
the hiderefs would only be omitted from the latter. Would it be useful
to add an option to "git show-ref" to make it omit the "hiderefs" refs?
And maybe another option to make it display *only* the hideref refs?
And in the bikeshedding department, I wonder if "hiderefs" is the best
name for the config setting. "hiderefs", implies to me that the refs
are actively hidden and not available to the client in any way. But in
fact they are just not advertised; they can be fetched normally. Maybe
another name would be more suggestive of its true effect, for example
"quietrefs" or "noadvertiserefs".
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: [PATCH 0/2] Hiding some refs in ls-remote
From: Duy Nguyen @ 2013-01-19 5:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, spearce, mfick
In-Reply-To: <1358555826-11883-1-git-send-email-gitster@pobox.com>
On Sat, Jan 19, 2013 at 7:37 AM, Junio C Hamano <gitster@pobox.com> wrote:
> This is an early preview of reducing the network cost while talking
> with a repository with tons of refs, most of which are of use by
> very narrow audiences (e.g. refs under Gerrit's refs/changes/ are
> useful only for people who are interested in the changes under
> review). As long as these narrow audiences have a way to learn the
> names of refs or objects pointed at by the refs out-of-band, it is
> not necessary to advertise these refs.
>
> On the server end, you tell upload-pack that some refs do not have
> to be advertised with the uploadPack.hiderefs multi-valued
> configuration variable:
>
> [uploadPack]
> hiderefs = refs/changes
>
> The changes necessary on the client side to allow fetching objects
> at the tip of a ref in hidden hierarchies are much more involved and
> not part of this early preview, but the end user UI is expected to
> be like these:
>
> $ git fetch $there refs/changes/72/41672/1
> $ git fetch $there 9598d59cdc098c5d9094d68024475e2430343182
>
> That is, you ask for a refname as usual even though it is not part
> of ls-remote response, or you ask for the commit object that is at
> the tip of whatever hidden ref you are interested in.
Should the client side learn how to list hidden refs too? I'm thinking
of an extreme case where upload-pack advertises nothing (or maybe just
refs/heads/master) and it's up to the client to ask for the ref
selection it's interested in. upload-pack may need more updates to do
that, I think.
--
Duy
^ permalink raw reply
* Re: [DOCBUG] git subtree synopsis needs updating
From: Techlive Zheng @ 2013-01-19 5:48 UTC (permalink / raw)
To: Herman van Rink; +Cc: Yann Dirson, git list
In-Reply-To: <5082FE13.2000003@initfour.nl>
On 12-10-20, Herman van Rink wrote:
> On 10/19/2012 03:21 PM, Yann Dirson wrote:
> > As the examples in git-subtree.txt show, the synopsis in the same file should
> > surely get a patch along the lines of:
> >
> > -'git subtree' add -P <prefix> <commit>
> > +'git subtree' add -P <prefix> <repository> <commit>
> >
> > Failure to specify the repository (by just specifying a local commit) fails with
> > the cryptic:
> >
> > warning: read-tree: emptying the index with no arguments is deprecated; use --empty
> > fatal: just how do you expect me to merge 0 trees?
> >
> >
> > Furthermore, the doc paragraph for add, aside from mentionning <repository>, also
> > mentions a <refspec> which the synopsis does not show either.
> >
> >
> > As a sidenote it someone wants to do some maintainance, using "." as repository when
> > the branch to subtree-add is already locally available does not work well either
> > (fails with "could not find ref myremote/myhead").
> >
>
> The version of subtree in contrib is rather out-dated unfortunately.
You should really submit these patches here for reviewing, David is
actively maintaining this tool here.
>
> I've collected a bunch of patches in
> https://github.com/helmo/git/tree/subtree-updates
>
> The documentation issue is also fixed in there.
>
> --
>
> Met vriendelijke groet / Regards,
>
> Herman van Rink
> Initfour websolutions
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ 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