Re: [PATCH 12/16] refs: always handle non-normal refs in files backend
On 12/03/2015 01:35 AM, David Turner wrote:
> Always handle non-normal (per-worktree or pseudo) refs in the files
> backend instead of alternate backends.
>
> Sometimes a ref transaction will update both a per-worktree ref and a
> normal ref. For instance, an ordinary commit might update
> refs/heads/master and HEAD (or at least HEAD's reflog).
>
> We handle three cases here:
>
> 1. updates to normal refs continue to go through the chosen backend
>
> 2. updates to non-normal refs with REF_NODEREF or to non-symbolic refs
> are moved to a separate files backend transaction.
>
> 3. updates to symbolic refs are dereferenced to their base ref. The
> update to the base ref then goes through the ordinary backend, while
> the files backend is directly called to update the symref's reflog.
>
> Signed-off-by: David Turner
> ---
> refs.c | 141
> -
> 1 file changed, 139 insertions(+), 2 deletions(-)
>
> diff --git a/refs.c b/refs.c
> index 808053f..e48e43a 100644
> --- a/refs.c
> +++ b/refs.c
> @@ -9,6 +9,11 @@
> #include "object.h"
> #include "tag.h"
>
> +const char split_transaction_fail_warning[] =
> + "A ref transaction was split across two refs backends. Part of the "
> + "transaction succeeded, but then the update to the per-worktree refs "
> + "failed. Your repository may be in an inconsistent state.";
> +
> /*
> * We always have a files backend and it is the default.
> */
> @@ -784,6 +789,13 @@ void ref_transaction_free(struct ref_transaction
> *transaction)
> free(transaction);
> }
>
> +static void add_update_obj(struct ref_transaction *transaction,
> +struct ref_update *update)
> +{
> + ALLOC_GROW(transaction->updates, transaction->nr + 1,
> transaction->alloc);
> + transaction->updates[transaction->nr++] = update;
> +}
> +
> static struct ref_update *add_update(struct ref_transaction *transaction,
>const char *refname)
> {
> @@ -791,8 +803,7 @@ static struct ref_update *add_update(struct
> ref_transaction *transaction,
> struct ref_update *update = xcalloc(1, sizeof(*update) + len);
>
> memcpy((char *)update->refname, refname, len); /* includes NUL */
> - ALLOC_GROW(transaction->updates, transaction->nr + 1,
> transaction->alloc);
> - transaction->updates[transaction->nr++] = update;
> + add_update_obj(transaction, update);
> return update;
> }
>
> @@ -1130,11 +1141,87 @@ int refs_init_db(struct strbuf *err, int shared)
> return the_refs_backend->init_db(err, shared);
> }
>
> +/*
> + * Special case for non-normal refs. For symbolic-refs when
> + * REF_NODEREF is not turned on, we dereference them here and replace
> + * updates to the symbolic refs with updates to the underlying ref.
> + * Then we do our own reflogging for the symbolic ref.
> + *
> + * We move other non-normal ref updates with into a specially-created
> + * files-backend transaction
> + */
Extra word? s/with//?
> +static int move_abnormal_ref_updates(struct ref_transaction *transaction,
> + struct ref_transaction *files_transaction,
> + struct string_list *symrefs)
> +{
> + int i;
> +
> + for (i = 0; i < transaction->nr; i++) {
> + struct ref_update *update = transaction->updates[i];
> + const char *resolved;
> + int flags = 0;
> + unsigned char sha1[20];
> +
> + if (ref_type(update->refname) == REF_TYPE_NORMAL)
> + continue;
> +
> + resolved = resolve_ref_unsafe(update->refname, 0, sha1, &flags);
> +
> + if (update->flags & REF_NODEREF || !(flags & REF_ISSYMREF)) {
> + int last;
> +
> + add_update_obj(files_transaction, update);
> + /*
> + * Replace this transaction with the
> + * last transaction, removing it from
> + * the list of backend transactions
> + */
> + last = --transaction->nr;
> + transaction->updates[i] = transaction->updates[last];
The "last" temporary variable could be trivially inlined.
> + continue;
> + }
> +
> + if (resolved) {
> + struct ref_update *new_update;
> + struct string_list_item *item;
> +
> + if (ref_type(resolved) != REF_TYPE_NORMAL)
> + die("Non-normal symbolic ref `%s` points to
> non-normal ref `%s`", update->refname, resolved);
We don't usually use backticks in error messages. Please use "'" instead.
Also, please store this error message into a "strbuf *err" and report it
via the usual mechanism.
> + new_update = xmalloc(sizeof(*new_update) +
> +
Re: Combining APPLE_COMMON_CRYPTO=1 and NO_OPENSSL=1 produces unexpected result
On Wed, Nov 25, 2015 at 10:10 AM, Jack Nagel wrote: > When compiling git on OS X (where APPLE_COMMON_CRYPTO=1 is the > default) and specifying NO_OPENSSL=1, the resulting git uses the > BLK_SHA1 implementation rather than the functions available in > CommonCrypto. > > $ make NO_OPENSSL=1 > [...] > $ nm git | grep _SHA1_ > 000100173f00 t _blk_SHA1_Block > 000100174e80 T _blk_SHA1_Final > 00010018fbb0 s _blk_SHA1_Final.pad > 000100173de0 T _blk_SHA1_Init > 000100173e10 T _blk_SHA1_Update NO_OPENSSL disables all SSL-related functionality in Git, not just SHA1 computation, however, Git still needs to compute SHA1 hashes for other reasons, so it uses its own BLK_SHA1 versions when OpenSSL is unavailable. > However, with OpenSSL available, it does use the CommonCrypto functions: > > $ make > [...] > $ nm git | grep _SHA1_ > U _CC_SHA1_Final > U _CC_SHA1_Init > U _CC_SHA1_Update > > I would not expect the presence of NO_OPENSSL=1 to change the behavior > here, since neither case actually makes use of the OpenSSL SHA1 > functions. Apple's CommonCrypto headers present OpenSSL-compatible API. When CommonCrypto is enabled in the Git makefile, aside from pulling in the CommonCrypto header and linking against the CommonCrypto framework, from Git's perspective, it still thinks it's using OpenSSL, and all SSL-related functionality is enabled (including the SHA1 functions). So, it might be easier to think of NO_OPENSSL as really meaning NO_SSL (that is, "disable all SSL-related functionality"). Since the only SSL implementation Git knows how to use is OpenSSL, perhaps one can consider the name NO_OPENSSL a historic anomaly. -- 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 v2 0/3] nd/clear-gitenv-upon-use-of-alias
On Tue, Dec 22, 2015 at 10:13:03AM -0800, Junio C Hamano wrote:
> > Another by the way, this "forcing aliases as external commands" now
> > shows something like "error: git-log died of signal 13" when the pager
> > exits early, for an alias like "l1 = log --oneline".
>
> ... and we do not show that when we directly call "git log" is...?
>
> We do signal this with non-zero exit status like so:
>
> $ GIT_PAGER=true git log --oneline ; echo $?
> 141
>
> and it is not surprising that the one that is catching the exit
> status of what was spawned and reporting "signal 13".
This sounded very familiar. Apparently I've been running with the patch
below for almost 3 years and never got around to re-examining it.
The original discussion is in:
http://thread.gmane.org/gmane.comp.version-control.git/212630
Having skimmed through the arguments there, and given that we applied
the patch from the middle of the thread, I think this is a good change.
-- >8 --
Date: Fri, 4 Jan 2013 07:19:35 -0500
Subject: [PATCH] avoid SIGPIPE warnings for aliases
When git executes an alias that specifies an external
command, it will complain if the alias dies due to a signal.
This is usually a good thing, as signal deaths are
unexpected. However, SIGPIPE is not unexpected for many
commands which produce a lot of output; it is intended that
the user closing the pager would kill them them via SIGPIPE.
As a result, the user might see annoying messages in a
scenario like this:
$ cat ~/.gitconfig
[alias]
lgbase = log --some-options
lg = !git lgbase --more-options
lg2 = !git lgbase --other-options
$ git lg -p
[user hits 'q' to exit pager]
error: git lgbase --more-options died of signal 13
fatal: While expanding alias 'lg': 'git lgbase --more-options': Success
Many users won't see this, because we execute the external
command with the shell, and a POSIX shell will silently
rewrite the signal-death exit code into 128+signal, and we
will treat it like a normal exit code. However, this does
not always happen:
1. If the sub-command does not have shell metacharacters,
we will skip the shell and exec it directly, getting
the signal code.
2. Some shells do not do this rewriting; for example,
setting SHELL_PATH set to zsh will reveal this problem.
This patch squelches the message, and lets git exit silently
(with the same exit code that a shell would use in case of a
signal).
The first line of the message comes from run-command's
wait_or_whine. To silence that message, we remain quiet
anytime we see SIGPIPE.
The second line comes from handle_alias itself. It calls
die_errno whenever run_command returns a negative value.
However, only -1 indicates a syscall error where errno has
something useful (note that it says the useless "success"
above). Instead, we treat negative returns from run_command
(except for -1) as a normal code to be passed to exit.
Signed-off-by: Jeff King
---
git.c | 2 +-
run-command.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/git.c b/git.c
index 6ed824c..34a18a3 100644
--- a/git.c
+++ b/git.c
@@ -252,7 +252,7 @@ static int handle_alias(int *argcp, const char ***argv)
alias_argv[argc] = NULL;
ret = run_command_v_opt(alias_argv, RUN_USING_SHELL);
- if (ret >= 0) /* normal exit */
+ if (ret != -1) /* normal exit */
exit(ret);
die_errno("While expanding alias '%s': '%s'",
diff --git a/run-command.c b/run-command.c
index 13fa452..694a6ff 100644
--- a/run-command.c
+++ b/run-command.c
@@ -245,7 +245,7 @@ static int wait_or_whine(pid_t pid, const char *argv0, int
in_signal)
error("waitpid is confused (%s)", argv0);
} else if (WIFSIGNALED(status)) {
code = WTERMSIG(status);
- if (code != SIGINT && code != SIGQUIT)
+ if (code != SIGINT && code != SIGQUIT && code != SIGPIPE)
error("%s died of signal %d", argv0, code);
/*
* This return value is chosen so that code & 0xff
--
2.7.0.rc2.368.g1cbb535
--
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 13/16] init: allow alternate backends to be set for new repos
On 12/05/2015 08:44 AM, Jeff King wrote: > [...] > I think the config option needs to be extensions.refsBackendType, too, > per the logic in 00a09d5 (introduce "extensions" form of > core.repositoryformatversion, 2015-06-23). And I guess it needs to bump > core.repositoryformatversion to "1". I think also, strictly speaking, the extensions.refsBackendType option should be ignored if core.repositoryFormatVersion is not "1". In practice, it probably makes more sense for the code to error out in that case because it is likely the result of a bug. Note that if the user explicitly chooses the "files" backend, it would be preferable to leave "core.repositoryFormatVersion" at "0" (assuming that no other extension is being used) and leave "extensions.refsBackendType" unset. This approach creates a repository that is compatible with older clients that don't know about refsBackendTypes. Michael -- Michael Haggerty mhag...@alum.mit.edu -- 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: Building Git with HTTPS support: avoiding libcurl?
On Tue, 22 Dec 2015, Paul Smith wrote: I grok that Git doesn't want to re-invent the wheel and that libcurl is convenient. I just wonder if anyone knows of another wheel, that doesn't come attached to an entire tractor-trailer, that could be used instead :). But if you would consider another lib, then you could just rebuild your own libcurl instead from source, entirely without any dependencies on other libs! That would be similar to finding another lib with less dependencies. (As already mentioned, you'd still need crypto and TLS support no doubt.) That huge dependency collection is there much because your distro decided that having a libcurl with all that support is preferable. libcurl itself offers lots of customizability at build-time so you can strip out most of that if you wanted to. But why do the distros build and provide a libcurl that can do all this? I think you can look at this from a slightly higher altitude. By re-using a very widely used, well developed and properly documented library (yeah, I claim it is but you don't need to take my word for it) that is available everywhere - git benefits. By having many projects use the same lib, even if no two projects use the exact same feature set, we get more reliable software in the entire ecosystem - with less work. I would guess that switching out libcurl in git would be a not insignificant amount of work, as no libcurl alternative I'm aware of is even close to this API. -- / daniel.haxx.se -- 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 v2 0/3] nd/clear-gitenv-upon-use-of-alias
On Wed, Dec 23, 2015 at 4:37 PM, Jeff King wrote:
> On Tue, Dec 22, 2015 at 10:13:03AM -0800, Junio C Hamano wrote:
>
>> > Another by the way, this "forcing aliases as external commands" now
>> > shows something like "error: git-log died of signal 13" when the pager
>> > exits early, for an alias like "l1 = log --oneline".
>>
>> ... and we do not show that when we directly call "git log" is...?
>>
>> We do signal this with non-zero exit status like so:
>>
>> $ GIT_PAGER=true git log --oneline ; echo $?
>> 141
>>
>> and it is not surprising that the one that is catching the exit
>> status of what was spawned and reporting "signal 13".
>
> This sounded very familiar. Apparently I've been running with the patch
> below for almost 3 years and never got around to re-examining it.
>
> The original discussion is in:
>
> http://thread.gmane.org/gmane.comp.version-control.git/212630
>
> Having skimmed through the arguments there, and given that we applied
> the patch from the middle of the thread, I think this is a good change.
Yep. The new thing here is the "died of" message now also comes from
execv_dashed_external() for non-external aliases, so it can show up a
lot more often. I wasn't sure if excluding SIGPIPE in wait_and_whine
was safe. But I _guess_ it is, based on your having no problem with
the patch for a long time and the past discussion.
>
> -- >8 --
> Date: Fri, 4 Jan 2013 07:19:35 -0500
> Subject: [PATCH] avoid SIGPIPE warnings for aliases
>
> When git executes an alias that specifies an external
> command, it will complain if the alias dies due to a signal.
> This is usually a good thing, as signal deaths are
> unexpected. However, SIGPIPE is not unexpected for many
> commands which produce a lot of output; it is intended that
> the user closing the pager would kill them them via SIGPIPE.
>
> As a result, the user might see annoying messages in a
> scenario like this:
>
> $ cat ~/.gitconfig
> [alias]
> lgbase = log --some-options
> lg = !git lgbase --more-options
> lg2 = !git lgbase --other-options
>
> $ git lg -p
> [user hits 'q' to exit pager]
> error: git lgbase --more-options died of signal 13
> fatal: While expanding alias 'lg': 'git lgbase --more-options': Success
>
> Many users won't see this, because we execute the external
> command with the shell, and a POSIX shell will silently
> rewrite the signal-death exit code into 128+signal, and we
> will treat it like a normal exit code. However, this does
> not always happen:
>
> 1. If the sub-command does not have shell metacharacters,
> we will skip the shell and exec it directly, getting
> the signal code.
>
> 2. Some shells do not do this rewriting; for example,
> setting SHELL_PATH set to zsh will reveal this problem.
>
> This patch squelches the message, and lets git exit silently
> (with the same exit code that a shell would use in case of a
> signal).
>
> The first line of the message comes from run-command's
> wait_or_whine. To silence that message, we remain quiet
> anytime we see SIGPIPE.
>
> The second line comes from handle_alias itself. It calls
> die_errno whenever run_command returns a negative value.
> However, only -1 indicates a syscall error where errno has
> something useful (note that it says the useless "success"
> above). Instead, we treat negative returns from run_command
> (except for -1) as a normal code to be passed to exit.
>
> Signed-off-by: Jeff King
> ---
> git.c | 2 +-
> run-command.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/git.c b/git.c
> index 6ed824c..34a18a3 100644
> --- a/git.c
> +++ b/git.c
> @@ -252,7 +252,7 @@ static int handle_alias(int *argcp, const char ***argv)
> alias_argv[argc] = NULL;
>
> ret = run_command_v_opt(alias_argv, RUN_USING_SHELL);
> - if (ret >= 0) /* normal exit */
> + if (ret != -1) /* normal exit */
> exit(ret);
>
> die_errno("While expanding alias '%s': '%s'",
> diff --git a/run-command.c b/run-command.c
> index 13fa452..694a6ff 100644
> --- a/run-command.c
> +++ b/run-command.c
> @@ -245,7 +245,7 @@ static int wait_or_whine(pid_t pid, const char *argv0,
> int in_signal)
> error("waitpid is confused (%s)", argv0);
> } else if (WIFSIGNALED(status)) {
> code = WTERMSIG(status);
> - if (code != SIGINT && code != SIGQUIT)
> + if (code != SIGINT && code != SIGQUIT && code != SIGPIPE)
> error("%s died of signal %d", argv0, code);
> /*
> * This return value is chosen so that code & 0xff
> --
> 2.7.0.rc2.368.g1cbb535
>
--
Duy
--
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] clone: use child_process for recursive checkouts
Signed-off-by: Michael Haggerty
---
David, I think if you insert this patch before your
13/16 refs: allow ref backend to be set for clone
, then the hunk in builtin/clone.c:checkout() of your patch becomes
trivial:
if (refs_backend_type)
argv_array_pushf(&cmd.args, "--refs-backend-type=%s",
refs_backend_type);
builtin/clone.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/builtin/clone.c b/builtin/clone.c
index caae43e..53c2834 100644
--- a/builtin/clone.c
+++ b/builtin/clone.c
@@ -95,10 +95,6 @@ static struct option builtin_clone_options[] = {
OPT_END()
};
-static const char *argv_submodule[] = {
- "submodule", "update", "--init", "--recursive", NULL
-};
-
static const char *get_repo_path_1(struct strbuf *path, int *is_bundle)
{
static char *suffix[] = { "/.git", "", ".git/.git", ".git" };
@@ -724,8 +720,14 @@ static int checkout(void)
err |= run_hook_le(NULL, "post-checkout", sha1_to_hex(null_sha1),
sha1_to_hex(sha1), "1", NULL);
- if (!err && option_recursive)
- err = run_command_v_opt(argv_submodule, RUN_GIT_CMD);
+ if (!err && option_recursive) {
+ struct child_process cmd = CHILD_PROCESS_INIT;
+
+ cmd.git_cmd = 1;
+ argv_array_pushl(&cmd.args, "submodule", "update",
+"--init", "--recursive", NULL);
+ err = run_command(&cmd);
+ }
return err;
}
--
2.6.4
--
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 13/16] init: allow alternate backends to be set for new repos
On 12/03/2015 01:35 AM, David Turner wrote:
> git init learns a new argument --refs-backend-type. Presently, only
> "files" is supported, but later we will add other backends.
>
> When this argument is used, the repository's core.refsBackendType
> configuration value is set, and the refs backend's initdb function is
> used to set up the ref database.
>
> Signed-off-by: David Turner
> ---
> Documentation/git-init-db.txt | 2 +-
> Documentation/git-init.txt| 6 +-
> builtin/init-db.c | 10 ++
> cache.h | 2 ++
> config.c | 20
> environment.c | 1 +
> path.c| 32 ++--
> refs.c| 8
> refs.h| 12
> setup.c | 10 ++
> 10 files changed, 99 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/git-init-db.txt b/Documentation/git-init-db.txt
> index 648a6cd..72fbd71 100644
> --- a/Documentation/git-init-db.txt
> +++ b/Documentation/git-init-db.txt
> @@ -9,7 +9,7 @@ git-init-db - Creates an empty Git repository
> SYNOPSIS
>
> [verse]
> -'git init-db' [-q | --quiet] [--bare] [--template=]
> [--separate-git-dir ] [--shared[=]]
> +'git init-db' [-q | --quiet] [--bare] [--template=]
> [--separate-git-dir ] [--shared[=]]
> [--refs-backend-type=]
>
>
> DESCRIPTION
> diff --git a/Documentation/git-init.txt b/Documentation/git-init.txt
> index 8174d27..9ea6753 100644
> --- a/Documentation/git-init.txt
> +++ b/Documentation/git-init.txt
> @@ -12,7 +12,7 @@ SYNOPSIS
> 'git init' [-q | --quiet] [--bare] [--template=]
> [--separate-git-dir ]
> [--shared[=]] [directory]
> -
> + [--refs-backend-type=]
ISTM that "backend" (used here in this option name, and in the manpage)
is not such a meaningful term to users. Could we pick a less obscure
term? E.g., maybe "--ref-storage="?
> DESCRIPTION
> ---
> @@ -113,6 +113,10 @@ does not exist, it will be created.
>
> --
>
> +--refs-backend-type=::
> +Type of refs backend. Default is to use the original "files" backend,
> +which stores ref data in files in .git/refs and .git/packed-refs.
> +
> TEMPLATE DIRECTORY
> --
>
> diff --git a/builtin/init-db.c b/builtin/init-db.c
> index 4771e7e..44db591 100644
> --- a/builtin/init-db.c
> +++ b/builtin/init-db.c
> @@ -204,6 +204,14 @@ static int create_default_files(const char
> *template_path)
> adjust_shared_perm(get_git_dir());
> }
>
> + if (refs_backend_type) {
> + struct refdb_config_data config_data = {NULL};
> + git_config_set("core.refsBackendType", refs_backend_type);
> + config_data.refs_backend_type = refs_backend_type;
> + config_data.refs_base = get_git_dir();
> + set_refs_backend(refs_backend_type, &config_data);
> + }
> +
Here is the source of the "void *data" argument that puzzled me in patch
08/16. I'm still puzzled. This code, which is later also used for the
LMDB backend, *always* passes that function a "struct refdb_config_data
*". So why is the argument declared to be "void *"?
If, on the other hand, you want to preserve a backend's freedom to
require different extra data in this parameter, then this code in
init-db.c, and code like it elsewhere, would have to know about the
reference backends so that it knows what data to pass to each one. In
that case, there would be no reason to make this function virtual; this
code could just as well call a different function (with a different
signature) depending on the backend that is in use.
Either way, something seems strange here.
(Remember that another alternative is to let the refs backend read
whatever specialized information it needs from the config by itself.)
> if (refs_init_db(&err, shared_repository))
> die("failed to set up refs db: %s", err.buf);
>
> @@ -469,6 +477,8 @@ int cmd_init_db(int argc, const char **argv, const char
> *prefix)
> OPT_BIT('q', "quiet", &flags, N_("be quiet"), INIT_DB_QUIET),
> OPT_STRING(0, "separate-git-dir", &real_git_dir, N_("gitdir"),
> N_("separate git dir from working tree")),
> + OPT_STRING(0, "refs-backend-type", &refs_backend_type,
> +N_("name"), N_("name of backend type to use")),
> OPT_END()
> };
>
> diff --git a/cache.h b/cache.h
> index 707455a..d1534db 100644
> --- a/cache.h
> +++ b/cache.h
> @@ -696,6 +696,8 @@ extern enum object_creation_mode object_creation_mode;
>
> extern char *notes_ref_name;
>
> +extern const char *refs_backend_type;
> +
> extern int grafts_replace_parents;
>
> /*
> diff --git a/config.c b/config.c
> index 248a21a..210aa08 100644
> --- a/config.c
> +++ b/config.c
> @@ -10,6 +10,7 @@
> #include "exec_cmd.h"
> #include "strbuf.h"
[PATCH 00/10] use the $( ... ) construct for command substitution
This patch series continues the changes introduced with the merge 6753d8a85d543253d95184ec2faad6dc197f248: Merge branch 'ep/shell-command-substitution' Adjust shell scripts to use $(cmd) instead of `cmd`. This is the fourth serie, the other will be sent separately. Elia Pinto (10): t/t5303-pack-corruption-resilience.sh: use the $( ... ) construct for command substitution t/t5304-prune.sh: use the $( ... ) construct for command substitution t/t5305-include-tag.sh: use the $( ... ) construct for command substitution t/t5500-fetch-pack.sh: use the $( ... ) construct for command substitution t/t5505-remote.sh: use the $( ... ) construct for command substitution t/t5506-remote-groups.sh: use the $( ... ) construct for command substitution t/t5510-fetch.sh: use the $( ... ) construct for command substitution t/t5515-fetch-merge-logic.sh: use the $( ... ) construct for command substitution t/t5516-fetch-push.sh: use the $( ... ) construct for command substitution t/t5517-push-mirror.sh: use the $( ... ) construct for command substitution t/t5303-pack-corruption-resilience.sh | 16 t/t5304-prune.sh | 2 +- t/t5305-include-tag.sh| 8 t/t5500-fetch-pack.sh | 20 ++-- t/t5505-remote.sh | 2 +- t/t5506-remote-groups.sh | 2 +- t/t5510-fetch.sh | 10 +- t/t5515-fetch-merge-logic.sh | 4 ++-- t/t5516-fetch-push.sh | 4 ++-- t/t5517-push-mirror.sh| 2 +- 10 files changed, 35 insertions(+), 35 deletions(-) -- 2.3.3.GIT -- 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 02/10] t/t5304-prune.sh: use the $( ... ) construct for command substitution
The Git CodingGuidelines prefer the $(...) construct for command
substitution instead of using the backquotes `...`.
The backquoted form is the traditional method for command
substitution, and is supported by POSIX. However, all but the
simplest uses become complicated quickly. In particular, embedded
command substitutions and/or the use of double quotes require
careful escaping with the backslash character.
The patch was generated by:
for _f in $(find . -name "*.sh")
do
perl -i -pe 'BEGIN{undef $/;} s/`(.+?)`/\$(\1)/smg' "${_f}"
done
and then carefully proof-read.
Signed-off-by: Elia Pinto
---
t/t5304-prune.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/t/t5304-prune.sh b/t/t5304-prune.sh
index def203c..133b584 100755
--- a/t/t5304-prune.sh
+++ b/t/t5304-prune.sh
@@ -266,7 +266,7 @@ EOF
'
test_expect_success 'prune .git/shallow' '
- SHA1=`echo hi|git commit-tree HEAD^{tree}` &&
+ SHA1=$(echo hi|git commit-tree HEAD^{tree}) &&
echo $SHA1 >.git/shallow &&
git prune --dry-run >out &&
grep $SHA1 .git/shallow &&
--
2.3.3.GIT
--
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 10/10] t/t5517-push-mirror.sh: use the $( ... ) construct for command substitution
The Git CodingGuidelines prefer the $(...) construct for command
substitution instead of using the backquotes `...`.
The backquoted form is the traditional method for command
substitution, and is supported by POSIX. However, all but the
simplest uses become complicated quickly. In particular, embedded
command substitutions and/or the use of double quotes require
careful escaping with the backslash character.
The patch was generated by:
for _f in $(find . -name "*.sh")
do
perl -i -pe 'BEGIN{undef $/;} s/`(.+?)`/\$(\1)/smg' "${_f}"
done
and then carefully proof-read.
Signed-off-by: Elia Pinto
---
t/t5517-push-mirror.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/t/t5517-push-mirror.sh b/t/t5517-push-mirror.sh
index 12a5dfb..02f160a 100755
--- a/t/t5517-push-mirror.sh
+++ b/t/t5517-push-mirror.sh
@@ -4,7 +4,7 @@ test_description='pushing to a mirror repository'
. ./test-lib.sh
-D=`pwd`
+D=$(pwd)
invert () {
if "$@"; then
--
2.3.3.GIT
--
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 01/10] t/t5303-pack-corruption-resilience.sh: use the $( ... ) construct for command substitution
The Git CodingGuidelines prefer the $(...) construct for command
substitution instead of using the backquotes `...`.
The backquoted form is the traditional method for command
substitution, and is supported by POSIX. However, all but the
simplest uses become complicated quickly. In particular, embedded
command substitutions and/or the use of double quotes require
careful escaping with the backslash character.
The patch was generated by:
for _f in $(find . -name "*.sh")
do
perl -i -pe 'BEGIN{undef $/;} s/`(.+?)`/\$(\1)/smg' "${_f}"
done
and then carefully proof-read.
Signed-off-by: Elia Pinto
---
t/t5303-pack-corruption-resilience.sh | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/t/t5303-pack-corruption-resilience.sh
b/t/t5303-pack-corruption-resilience.sh
index 663b02b..5940ce2 100755
--- a/t/t5303-pack-corruption-resilience.sh
+++ b/t/t5303-pack-corruption-resilience.sh
@@ -32,23 +32,23 @@ create_test_files() {
create_new_pack() {
rm -rf .git &&
git init &&
-blob_1=`git hash-object -t blob -w file_1` &&
-blob_2=`git hash-object -t blob -w file_2` &&
-blob_3=`git hash-object -t blob -w file_3` &&
-pack=`printf "$blob_1\n$blob_2\n$blob_3\n" |
- git pack-objects $@ .git/objects/pack/pack` &&
+blob_1=$(git hash-object -t blob -w file_1) &&
+blob_2=$(git hash-object -t blob -w file_2) &&
+blob_3=$(git hash-object -t blob -w file_3) &&
+pack=$(printf "$blob_1\n$blob_2\n$blob_3\n" |
+ git pack-objects $@ .git/objects/pack/pack) &&
pack=".git/objects/pack/pack-${pack}" &&
git verify-pack -v ${pack}.pack
}
do_repack() {
-pack=`printf "$blob_1\n$blob_2\n$blob_3\n" |
- git pack-objects $@ .git/objects/pack/pack` &&
+pack=$(printf "$blob_1\n$blob_2\n$blob_3\n" |
+ git pack-objects $@ .git/objects/pack/pack) &&
pack=".git/objects/pack/pack-${pack}"
}
do_corrupt_object() {
-ofs=`git show-index < ${pack}.idx | grep $1 | cut -f1 -d" "` &&
+ofs=$(git show-index < ${pack}.idx | grep $1 | cut -f1 -d" ") &&
ofs=$(($ofs + $2)) &&
chmod +w ${pack}.pack &&
dd of=${pack}.pack bs=1 conv=notrunc seek=$ofs &&
--
2.3.3.GIT
--
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 03/10] t/t5305-include-tag.sh: use the $( ... ) construct for command substitution
The Git CodingGuidelines prefer the $(...) construct for command
substitution instead of using the backquotes `...`.
The backquoted form is the traditional method for command
substitution, and is supported by POSIX. However, all but the
simplest uses become complicated quickly. In particular, embedded
command substitutions and/or the use of double quotes require
careful escaping with the backslash character.
The patch was generated by:
for _f in $(find . -name "*.sh")
do
perl -i -pe 'BEGIN{undef $/;} s/`(.+?)`/\$(\1)/smg' "${_f}"
done
and then carefully proof-read.
Signed-off-by: Elia Pinto
---
t/t5305-include-tag.sh | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/t/t5305-include-tag.sh b/t/t5305-include-tag.sh
index 21517c7..f314ad5 100755
--- a/t/t5305-include-tag.sh
+++ b/t/t5305-include-tag.sh
@@ -3,20 +3,20 @@
test_description='git pack-object --include-tag'
. ./test-lib.sh
-TRASH=`pwd`
+TRASH=$(pwd)
test_expect_success setup '
echo c >d &&
git update-index --add d &&
- tree=`git write-tree` &&
- commit=`git commit-tree $tree sig &&
echo "type commit" >>sig &&
echo "tag mytag" >>sig &&
echo "tagger $(git var GIT_COMMITTER_IDENT)" >>sig &&
echo >>sig &&
echo "our test tag" >>sig &&
- tag=`git mktag http://vger.kernel.org/majordomo-info.html
[PATCH 04/10] t/t5500-fetch-pack.sh: use the $( ... ) construct for command substitution
The Git CodingGuidelines prefer the $(...) construct for command
substitution instead of using the backquotes `...`.
The backquoted form is the traditional method for command
substitution, and is supported by POSIX. However, all but the
simplest uses become complicated quickly. In particular, embedded
command substitutions and/or the use of double quotes require
careful escaping with the backslash character.
The patch was generated by:
for _f in $(find . -name "*.sh")
do
perl -i -pe 'BEGIN{undef $/;} s/`(.+?)`/\$(\1)/smg' "${_f}"
done
and then carefully proof-read.
Signed-off-by: Elia Pinto
---
t/t5500-fetch-pack.sh | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/t/t5500-fetch-pack.sh b/t/t5500-fetch-pack.sh
index 3a9b775..e5f83bf 100755
--- a/t/t5500-fetch-pack.sh
+++ b/t/t5500-fetch-pack.sh
@@ -14,7 +14,7 @@ test_description='Testing multi_ack pack fetching'
add () {
name=$1 &&
text="$@" &&
- branch=`echo $name | sed -e 's/^\(.\).*$/\1/'` &&
+ branch=$(echo $name | sed -e 's/^\(.\).*$/\1/') &&
parents="" &&
shift &&
@@ -50,18 +50,18 @@ pull_to_client () {
case "$heads" in *B*)
echo $BTIP > .git/refs/heads/B;;
esac &&
- git symbolic-ref HEAD refs/heads/`echo $heads \
- | sed -e "s/^\(.\).*$/\1/"` &&
+ git symbolic-ref HEAD refs/heads/$(echo $heads \
+ | sed -e "s/^\(.\).*$/\1/") &&
git fsck --full &&
mv .git/objects/pack/pack-* . &&
- p=`ls -1 pack-*.pack` &&
+ p=$(ls -1 pack-*.pack) &&
git unpack-objects <$p &&
git fsck --full &&
- idx=`echo pack-*.idx` &&
- pack_count=`git show-index <$idx | wc -l` &&
+ idx=$(echo pack-*.idx) &&
+ pack_count=$(git show-index <$idx | wc -l) &&
test $pack_count = $count &&
rm -f pack-*
)
@@ -132,13 +132,13 @@ test_expect_success 'single given branch clone' '
test_expect_success 'clone shallow depth 1' '
git clone --no-single-branch --depth 1 "file://$(pwd)/." shallow0 &&
- test "`git --git-dir=shallow0/.git rev-list --count HEAD`" = 1
+ test "$(git --git-dir=shallow0/.git rev-list --count HEAD)" = 1
'
test_expect_success 'clone shallow depth 1 with fsck' '
git config --global fetch.fsckobjects true &&
git clone --no-single-branch --depth 1 "file://$(pwd)/." shallow0fsck &&
- test "`git --git-dir=shallow0fsck/.git rev-list --count HEAD`" = 1 &&
+ test "$(git --git-dir=shallow0fsck/.git rev-list --count HEAD)" = 1 &&
git config --global --unset fetch.fsckobjects
'
@@ -147,7 +147,7 @@ test_expect_success 'clone shallow' '
'
test_expect_success 'clone shallow depth count' '
- test "`git --git-dir=shallow/.git rev-list --count HEAD`" = 2
+ test "$(git --git-dir=shallow/.git rev-list --count HEAD)" = 2
'
test_expect_success 'clone shallow object count' '
@@ -273,7 +273,7 @@ test_expect_success 'additional simple shallow deepenings' '
'
test_expect_success 'clone shallow depth count' '
- test "`git --git-dir=shallow/.git rev-list --count HEAD`" = 11
+ test "$(git --git-dir=shallow/.git rev-list --count HEAD)" = 11
'
test_expect_success 'clone shallow object count' '
--
2.3.3.GIT
--
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 09/10] t/t5516-fetch-push.sh: use the $( ... ) construct for command substitution
The Git CodingGuidelines prefer the $(...) construct for command
substitution instead of using the backquotes `...`.
The backquoted form is the traditional method for command
substitution, and is supported by POSIX. However, all but the
simplest uses become complicated quickly. In particular, embedded
command substitutions and/or the use of double quotes require
careful escaping with the backslash character.
The patch was generated by:
for _f in $(find . -name "*.sh")
do
perl -i -pe 'BEGIN{undef $/;} s/`(.+?)`/\$(\1)/smg' "${_f}"
done
and then carefully proof-read.
Signed-off-by: Elia Pinto
---
t/t5516-fetch-push.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/t/t5516-fetch-push.sh b/t/t5516-fetch-push.sh
index 0a87e19..26b2caf 100755
--- a/t/t5516-fetch-push.sh
+++ b/t/t5516-fetch-push.sh
@@ -16,7 +16,7 @@ This test checks the following functionality:
. ./test-lib.sh
-D=`pwd`
+D=$(pwd)
mk_empty () {
repo_name="$1"
@@ -422,7 +422,7 @@ test_expect_success 'push tag with non-existent, incomplete
dest' '
test_expect_success 'push sha1 with non-existent, incomplete dest' '
mk_test testrepo &&
- test_must_fail git push testrepo `git rev-parse master`:foo
+ test_must_fail git push testrepo $(git rev-parse master):foo
'
--
2.3.3.GIT
--
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 08/10] t/t5515-fetch-merge-logic.sh: use the $( ... ) construct for command substitution
The Git CodingGuidelines prefer the $(...) construct for command
substitution instead of using the backquotes `...`.
The backquoted form is the traditional method for command
substitution, and is supported by POSIX. However, all but the
simplest uses become complicated quickly. In particular, embedded
command substitutions and/or the use of double quotes require
careful escaping with the backslash character.
The patch was generated by:
for _f in $(find . -name "*.sh")
do
perl -i -pe 'BEGIN{undef $/;} s/`(.+?)`/\$(\1)/smg' "${_f}"
done
and then carefully proof-read.
Signed-off-by: Elia Pinto
---
t/t5515-fetch-merge-logic.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/t/t5515-fetch-merge-logic.sh b/t/t5515-fetch-merge-logic.sh
index dbb927d..36b0dbc 100755
--- a/t/t5515-fetch-merge-logic.sh
+++ b/t/t5515-fetch-merge-logic.sh
@@ -128,8 +128,8 @@ do
case "$cmd" in
'' | '#'*) continue ;;
esac
- test=`echo "$cmd" | sed -e 's|[/ ][/ ]*|_|g'`
- pfx=`printf "%04d" $test_count`
+ test=$(echo "$cmd" | sed -e 's|[/ ][/ ]*|_|g')
+ pfx=$(printf "%04d" $test_count)
expect_f="$TEST_DIRECTORY/t5515/fetch.$test"
actual_f="$pfx-fetch.$test"
expect_r="$TEST_DIRECTORY/t5515/refs.$test"
--
2.3.3.GIT
--
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 06/10] t/t5506-remote-groups.sh: use the $( ... ) construct for command substitution
The Git CodingGuidelines prefer the $(...) construct for command
substitution instead of using the backquotes `...`.
The backquoted form is the traditional method for command
substitution, and is supported by POSIX. However, all but the
simplest uses become complicated quickly. In particular, embedded
command substitutions and/or the use of double quotes require
careful escaping with the backslash character.
The patch was generated by:
for _f in $(find . -name "*.sh")
do
perl -i -pe 'BEGIN{undef $/;} s/`(.+?)`/\$(\1)/smg' "${_f}"
done
and then carefully proof-read.
Signed-off-by: Elia Pinto
---
t/t5506-remote-groups.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/t/t5506-remote-groups.sh b/t/t5506-remote-groups.sh
index 530b016..83d5558 100755
--- a/t/t5506-remote-groups.sh
+++ b/t/t5506-remote-groups.sh
@@ -20,7 +20,7 @@ update_repos() {
}
repo_fetched() {
- if test "`git log -1 --pretty=format:%s $1 --`" = "`cat mark`"; then
+ if test "$(git log -1 --pretty=format:%s $1 --)" = "$(cat mark)"; then
echo >&2 "repo was fetched: $1"
return 0
fi
--
2.3.3.GIT
--
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 05/10] t/t5505-remote.sh: use the $( ... ) construct for command substitution
The Git CodingGuidelines prefer the $(...) construct for command
substitution instead of using the backquotes `...`.
The backquoted form is the traditional method for command
substitution, and is supported by POSIX. However, all but the
simplest uses become complicated quickly. In particular, embedded
command substitutions and/or the use of double quotes require
careful escaping with the backslash character.
The patch was generated by:
for _f in $(find . -name "*.sh")
do
perl -i -pe 'BEGIN{undef $/;} s/`(.+?)`/\$(\1)/smg' "${_f}"
done
and then carefully proof-read.
Signed-off-by: Elia Pinto
---
t/t5505-remote.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/t/t5505-remote.sh b/t/t5505-remote.sh
index dfaf9d9..1a8e3b8 100755
--- a/t/t5505-remote.sh
+++ b/t/t5505-remote.sh
@@ -85,7 +85,7 @@ test_expect_success C_LOCALE_OUTPUT 'check remote-tracking' '
test_expect_success 'remote forces tracking branches' '
(
cd test &&
- case `git config remote.second.fetch` in
+ case $(git config remote.second.fetch) in
+*) true ;;
*) false ;;
esac
--
2.3.3.GIT
--
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 07/10] t/t5510-fetch.sh: use the $( ... ) construct for command substitution
The Git CodingGuidelines prefer the $(...) construct for command
substitution instead of using the backquotes `...`.
The backquoted form is the traditional method for command
substitution, and is supported by POSIX. However, all but the
simplest uses become complicated quickly. In particular, embedded
command substitutions and/or the use of double quotes require
careful escaping with the backslash character.
The patch was generated by:
for _f in $(find . -name "*.sh")
do
perl -i -pe 'BEGIN{undef $/;} s/`(.+?)`/\$(\1)/smg' "${_f}"
done
and then carefully proof-read.
Signed-off-by: Elia Pinto
---
t/t5510-fetch.sh | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/t/t5510-fetch.sh b/t/t5510-fetch.sh
index 0ba9db0..47e68a5 100755
--- a/t/t5510-fetch.sh
+++ b/t/t5510-fetch.sh
@@ -7,7 +7,7 @@ test_description='Per branch config variables affects "git
fetch".
. ./test-lib.sh
-D=`pwd`
+D=$(pwd)
test_bundle_object_count () {
git verify-pack -v "$1" >verify.out &&
@@ -64,8 +64,8 @@ test_expect_success "fetch test" '
cd two &&
git fetch &&
test -f .git/refs/heads/one &&
- mine=`git rev-parse refs/heads/one` &&
- his=`cd ../one && git rev-parse refs/heads/master` &&
+ mine=$(git rev-parse refs/heads/one) &&
+ his=$(cd ../one && git rev-parse refs/heads/master) &&
test "z$mine" = "z$his"
'
@@ -75,8 +75,8 @@ test_expect_success "fetch test for-merge" '
git fetch &&
test -f .git/refs/heads/two &&
test -f .git/refs/heads/one &&
- master_in_two=`cd ../two && git rev-parse master` &&
- one_in_two=`cd ../two && git rev-parse one` &&
+ master_in_two=$(cd ../two && git rev-parse master) &&
+ one_in_two=$(cd ../two && git rev-parse one) &&
{
echo "$one_in_two "
echo "$master_in_twonot-for-merge"
--
2.3.3.GIT
--
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 14/16] refs: allow ref backend to be set for clone
On 12/03/2015 01:35 AM, David Turner wrote:
> Add a new option, --refs-backend-type, to allow the ref backend type to
> be set on new clones.
>
> Submodules must use the same ref backend as the parent repository, so
^^^ is this verified anywhere? Hint: if not, it probably should be. For
example, imagine a future where an existing repository can be migrated
in place from files -> lmdb. If somebody runs that command in a
submodule, this invariant would be broken and *this* version of git
would have to at least detect the problem and refuse to corrupt things.
I added CC to a couple submodules experts in case they have any
feedback. Are there any other code paths that can lead to submodules
being newly cloned, where this option would also have to be passed?
> we also pass the --refs-backend-type option option when cloning
> submodules.
>
> Signed-off-by: David Turner
> ---
> Documentation/git-clone.txt | 4
> builtin/clone.c | 27 +--
> builtin/submodule--helper.c | 5 -
> cache.h | 1 +
> 4 files changed, 34 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt
> index 6bf000d..431575b 100644
> --- a/Documentation/git-clone.txt
> +++ b/Documentation/git-clone.txt
> @@ -14,6 +14,7 @@ SYNOPSIS
> [-o ] [-b ] [-u ] [--reference ]
> [--dissociate] [--separate-git-dir ]
> [--depth ] [--[no-]single-branch]
> + [--refs-backend-type=]
> [--recursive | --recurse-submodules] [--]
> []
>
> @@ -221,6 +222,9 @@ objects from the source repository into a pack in the
> cloned repository.
> The result is Git repository can be separated from working
> tree.
>
> +--refs-backend-type=::
> + Type of refs backend. Default is to use the original files based
> + backend.
>
> ::
> The (possibly remote) repository to clone from. See the
> diff --git a/builtin/clone.c b/builtin/clone.c
> index caae43e..a53f341 100644
> --- a/builtin/clone.c
> +++ b/builtin/clone.c
> @@ -92,11 +92,13 @@ static struct option builtin_clone_options[] = {
> N_("separate git dir from working tree")),
> OPT_STRING_LIST('c', "config", &option_config, N_("key=value"),
> N_("set config inside the new repository")),
> + OPT_STRING(0, "refs-backend-type", &refs_backend_type,
> +N_("name"), N_("name of backend type to use")),
> OPT_END()
> };
>
> static const char *argv_submodule[] = {
> - "submodule", "update", "--init", "--recursive", NULL
> + "submodule", "update", "--init", "--recursive", NULL, NULL
> };
>
> static const char *get_repo_path_1(struct strbuf *path, int *is_bundle)
> @@ -724,8 +726,24 @@ static int checkout(void)
> err |= run_hook_le(NULL, "post-checkout", sha1_to_hex(null_sha1),
> sha1_to_hex(sha1), "1", NULL);
>
> - if (!err && option_recursive)
> + if (!err && option_recursive) {
> + const char **backend_arg = argv_submodule;
> + char *new_backend_arg = NULL;
> + if (refs_backend_type) {
> + while (*backend_arg)
> + ++backend_arg;
> +
> + new_backend_arg = xmalloc(21 +
> strlen(refs_backend_type));
> + sprintf(new_backend_arg, "--refs-backend-type=%s",
> + refs_backend_type);
> + *backend_arg = new_backend_arg;
> + }
> err = run_command_v_opt(argv_submodule, RUN_GIT_CMD);
> + if (refs_backend_type) {
> + free(new_backend_arg);
> + *backend_arg = NULL;
> + }
> + }
I sent a separate email about this hunk:
http://mid.gmane.org/c21eb4a5d3a3a4886c45da0abe307fe1772e932e.1450869637.git.mhag...@alum.mit.edu
>
> return err;
> }
> @@ -744,6 +762,11 @@ static void write_config(struct string_list *config)
> write_one_config, NULL) < 0)
> die("unable to write parameters to config file");
> }
> +
> + if (refs_backend_type &&
> + write_one_config("core.refsBackendType",
> + refs_backend_type, NULL) < 0)
> + die("unable to write backend parameter to config file");
> }
>
> static void write_refspec_config(const char *src_ref_prefix,
> diff --git a/builtin/submodule--helper.c b/builtin/submodule--helper.c
> index f4c3eff..5c9ca4e 100644
> --- a/builtin/submodule--helper.c
> +++ b/builtin/submodule--helper.c
> @@ -140,7 +140,10 @@ static int clone_submodule(const char *path, const char
> *gitdir, const char *url
> argv_array_pushl(&cp.args, "--reference", reference, NULL);
> if (gitdir && *gitdir)
> argv_array_pushl(&cp.args, "--separate-git-dir", gitdir, NULL);
> -
> + if (refs_backend_type && *r
Announcing release for Git 1.9 on CentOS Linux 6 and 7 x86_64 SCL
I am pleased to announce the immediate availability of Git 1.9 on CentOS Linux 6 and 7 x86_64, delivered via a Software Collection (SCL) built by the SCLo Special Interest Group (https://wiki.centos.org/SpecialInterestGroup/SCLo). QuickStart -- You can get started in three easy steps: $ sudo yum install centos-release-scl $ sudo yum install git19 $ scl enable git19 bash At this point you should be able to use git just as a normal application. Examples of commands run might be: $ git clone https://github.com/openshift/mysql.git $ git commit -m "Initial commit" In order to view the individual components included in this collection, including additional conversion tools, you can run: $ sudo yum list git19\* About Software Collections -- Software Collections give you the power to build, install, and use multiple versions of software on the same system, without affecting system-wide installed packages. Each collection is delivered as a group of RPMs, with the grouping being done using the name of the collection as a prefix of all packages that are part of the software collection. The collection git19 delivers version 1.9 of the git, fast, scalable and distributed revision control system, plus additional conversion tools and plugins also available as RPMs. For more on the Git, see https://git-scm.com. The SCLo SIG in CentOS -- The Software Collections SIG group is an open community group co-ordinating the development of the SCL technology, and helping curate a reference set of collections. In addition to the Git collection being released here, we also build and deliver databases, web servers, and language stacks including multiple versions of PostgreSQL, MariaDB, Apache HTTP Server, NodeJS, Ruby, Python and others. Software Collections SIG release was announced at https://lists.centos.org/pipermail/centos-announce/2015-October/021446.html You can learn more about Software Collections concepts at: http://softwarecollections.org You can find information on the SIG at https://wiki.centos.org/SpecialInterestGroup/SCLo ; this includes howto get involved and help with the effort. We meet every second Wednesday at 16:00 UTC in #centos-devel (ref: https://www.centos.org/community/calendar), for an informal open forum open to anyone who might have comments, concerns or wants to get started with SCL's in CentOS. Enjoy! Honza SCLo SIG member -- 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 15/16] refs: add LMDB refs backend
On 12/03/2015 01:35 AM, David Turner wrote: > Add a database backend for refs using LMDB. This backend runs git > for-each-ref about 30% faster than the files backend with fully-packed > refs on a repo with ~120k refs. It's also about 4x faster than using > fully-unpacked refs. In addition, and perhaps more importantly, it > avoids case-conflict issues on OS X. > > LMDB has a few features that make it suitable for usage in git: > > 1. It is relatively lightweight; it requires only one header file, and > the library code takes under 64k at runtime. > > 2. It is well-tested: it's been used in OpenLDAP for years. > > 3. It's very fast. LMDB's benchmarks show that it is among > the fastest key-value stores. > > 4. It has a relatively simple concurrency story; readers don't > block writers and writers don't block readers. > > Ronnie Sahlberg's original version of this patchset used tdb. The > major disadvantage of tdb is that tdb is hard to build on OS X. It's > also not in homebrew. So lmdb seemed simpler. > > To test this backend's correctness, I hacked test-lib.sh and > test-lib-functions.sh to run all tests under the refs backend. Dozens > of tests use manual ref/reflog reading/writing, or create submodules > without passing --refs-backend-type to git init. If those tests are > changed to use the update-ref machinery or test-refs-lmdb-backend (or, > in the case of packed-refs, corrupt refs, and dumb fetch tests, are > skipped), the only remaining failing tests are the git-new-workdir > tests and the gitweb tests. > > Signed-off-by: David Turner > --- > .gitignore |1 + > Documentation/config.txt |7 + > Documentation/git-clone.txt|2 +- > Documentation/git-init.txt |3 +- > Documentation/technical/refs-lmdb-backend.txt | 50 + > Documentation/technical/repository-version.txt |5 + > Makefile | 12 + > builtin/init-db.c | 10 +- > config.c | 20 +- > configure.ac | 33 + > contrib/workdir/git-new-workdir|3 + > refs.h |1 + > refs/lmdb-backend.c| 2054 > > setup.c| 22 +- > test-refs-lmdb-backend.c | 68 + > 15 files changed, 2279 insertions(+), 12 deletions(-) > create mode 100644 Documentation/technical/refs-lmdb-backend.txt > create mode 100644 refs/lmdb-backend.c > create mode 100644 test-refs-lmdb-backend.c > > diff --git a/.gitignore b/.gitignore > index 1c2f832..87d45a2 100644 > --- a/.gitignore > +++ b/.gitignore > @@ -199,6 +199,7 @@ > /test-path-utils > /test-prio-queue > /test-read-cache > +/test-refs-lmdb-backend > /test-regex > /test-revision-walking > /test-run-command > diff --git a/Documentation/config.txt b/Documentation/config.txt > index f617886..5fb25ed 100644 > --- a/Documentation/config.txt > +++ b/Documentation/config.txt > @@ -496,6 +496,13 @@ core.repositoryFormatVersion:: > Internal variable identifying the repository format and layout > version. > > +core.refsBackendType:: > + Type of refs backend. Default is to use the original files > + based backend. Set to 'lmdb' to activate the lmdb database > + backend. If you use the lmdb backend, > + core.repositoryFormatVersion must be set to 1, and > + extensions.refBackend must be set to 'lmdb'. This phrasing makes it sound like I can go into an existing repository, change this repository setting, and *presto* I will have a LMDB-backed repository. I suggest rewording it more along the lines of "this setting reflects the refs backend that is currently in use". Also please see my earlier question about whether users should see the term "backend" or whether other terms would be easier to understand. > + > core.sharedRepository:: > When 'group' (or 'true'), the repository is made shareable between > several users in a group (making sure all the files and objects are > diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt > index 431575b..739c116 100644 > --- a/Documentation/git-clone.txt > +++ b/Documentation/git-clone.txt > @@ -224,7 +224,7 @@ objects from the source repository into a pack in the > cloned repository. > > --refs-backend-type=:: > Type of refs backend. Default is to use the original files based > - backend. > + backend. Set to "lmdb" to activate the lmdb database backend. > > :: > The (possibly remote) repository to clone from. See the > diff --git a/Documentation/git-init.txt b/Documentation/git-init.txt > index 9ea6753..bbe253f 100644 > --- a/Documentation/git-init.txt > +++ b/Documentation/git-init.txt > @@ -115,7 +115,8 @@ does not exist, it will be created
Re: [PATCH v2 0/3] nd/clear-gitenv-upon-use-of-alias
On Wed, Dec 23, 2015 at 4:37 AM, Jeff King wrote: > Subject: [PATCH] avoid SIGPIPE warnings for aliases > > When git executes an alias that specifies an external > command, it will complain if the alias dies due to a signal. > This is usually a good thing, as signal deaths are > unexpected. However, SIGPIPE is not unexpected for many > commands which produce a lot of output; it is intended that > the user closing the pager would kill them them via SIGPIPE. s/them them/them/ > As a result, the user might see annoying messages in a > scenario like this: > > $ cat ~/.gitconfig > [alias] > lgbase = log --some-options > lg = !git lgbase --more-options > lg2 = !git lgbase --other-options > > $ git lg -p > [user hits 'q' to exit pager] > error: git lgbase --more-options died of signal 13 > fatal: While expanding alias 'lg': 'git lgbase --more-options': Success > > Many users won't see this, because we execute the external > command with the shell, and a POSIX shell will silently > rewrite the signal-death exit code into 128+signal, and we > will treat it like a normal exit code. However, this does > not always happen: > > 1. If the sub-command does not have shell metacharacters, > we will skip the shell and exec it directly, getting > the signal code. > > 2. Some shells do not do this rewriting; for example, > setting SHELL_PATH set to zsh will reveal this problem. > > This patch squelches the message, and lets git exit silently > (with the same exit code that a shell would use in case of a > signal). > > The first line of the message comes from run-command's > wait_or_whine. To silence that message, we remain quiet > anytime we see SIGPIPE. > > The second line comes from handle_alias itself. It calls > die_errno whenever run_command returns a negative value. > However, only -1 indicates a syscall error where errno has > something useful (note that it says the useless "success" > above). Instead, we treat negative returns from run_command > (except for -1) as a normal code to be passed to exit. > > Signed-off-by: Jeff King -- 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: Building Git with HTTPS support: avoiding libcurl?
Hi Daniel, On Wed, 23 Dec 2015, Daniel Stenberg wrote: > By re-using a very widely used, well developed and properly documented > library [libcurl] (yeah, I claim it is but you don't need to take my > word for it) that is available everywhere - git benefits. For what it's worth, I fully agree. My perspective: By using a pretty much fully-configured cURL, Git for Windows has supported the largest number of use cases with minimal requirements from myself. It has been a boon. If every library was as easy to use and as high quality, anybody could maintain Git for Windows ;-) Ciao, a very grateful Dscho -- 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 13/16] init: allow alternate backends to be set for new repos
On Wed, Dec 23, 2015 at 10:52:41AM +0100, Michael Haggerty wrote: > On 12/05/2015 08:44 AM, Jeff King wrote: > > [...] > > I think the config option needs to be extensions.refsBackendType, too, > > per the logic in 00a09d5 (introduce "extensions" form of > > core.repositoryformatversion, 2015-06-23). And I guess it needs to bump > > core.repositoryformatversion to "1". > > I think also, strictly speaking, the extensions.refsBackendType option > should be ignored if core.repositoryFormatVersion is not "1". In > practice, it probably makes more sense for the code to error out in that > case because it is likely the result of a bug. Yeah, I agree. It's not wrong, but it may be a good indication the user is confused. Perhaps issuing a warning would be appropriate. > Note that if the user explicitly chooses the "files" backend, it would > be preferable to leave "core.repositoryFormatVersion" at "0" (assuming > that no other extension is being used) and leave > "extensions.refsBackendType" unset. This approach creates a repository > that is compatible with older clients that don't know about > refsBackendTypes. Also agreed. This is going to be the case for basically every "extension" option. If the extension config key isn't present, there will be some default backwards-compatible behavior, and for compatibility, you are always better off turning off the extension than setting turning it "on" with that default value. This is the case for the "preciousObjects" extension: there is no point in setting it to "false" as opposed to removing it. So I think the rules for setting an extension value should be: 1. If you're setting it to the default value, then remove it completely. 2. If you're removing it, and there are no other extensions, set repositoryFormatVersion back to 0. Of course there's currently no code that sets extension values. And doing step 1 is going to be specific to each extension. So this a general philosophy to follow, not something we would write in a function. -Peff -- 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 14/16] refs: allow ref backend to be set for clone
On Wed, Dec 23, 2015 at 8:51 AM, Michael Haggerty wrote:
> On 12/03/2015 01:35 AM, David Turner wrote:
>> + if (refs_backend_type && *refs_backend_type) {
>> + argv_array_push(&cp.args, "--refs-backend-type");
>> + argv_array_push(&cp.args, refs_backend_type);
>> + }
>
> This could be shortened to
>
> argv_array_pushf(&cp.args, "--refs-backend-type=%s", refs_backend_type);
Or, without interpolation:
argv_array_pushl(&cp.args, "--refs-backend-type", refs_backend_type, NULL);
--
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 V4 2/2] user-manual: add section documenting shallow clones
Rather than merely pointing readers at the 1.5 release notes to learn about shallow clones, document them formally. Signed-off-by: Stephen P. Smith --- I replaced the paragraphs that I wrote with Eric Shunshine's since it was cleaner. I like the idea of linking to the preceeding effort, but gmane.org is currently undergoing maintance and therefore giving me errors when I attempt to access it. Documentation/user-manual.txt | 17 ++--- 1 file changed, 14 insertions(+), 3 deletions(-) diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt index 1c790ac..5c13683 100644 --- a/Documentation/user-manual.txt +++ b/Documentation/user-manual.txt @@ -2128,6 +2128,20 @@ The gitweb cgi script provides users an easy way to browse your project's files and history without having to install Git; see the file gitweb/INSTALL in the Git source tree for instructions on setting it up. +[[how-to-get-a-git-repository-with-minimal-history]] +How to get a Git repository with minimal history + + +A <>, with its truncated +history, is useful when one is interested only in recent history +of a project and getting full history from the upstream is +expensive. + +A <> is created by specifying +the linkgit:git-clone[1] `--depth` switch. The depth can later be +changed with the linkgit:git-fetch[1] `--depth` switch, or full +history restored with `--unshallow`. + [[sharing-development-examples]] Examples @@ -4645,9 +4659,6 @@ standard end-of-chapter section? Include cross-references to the glossary, where appropriate. -Document shallow clones? See draft 1.5.0 release notes for some -documentation. - Add a section on working with other version control systems, including CVS, Subversion, and just imports of series of release tarballs. -- 2.6.3.368.gf34be46 -- 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 v2 0/3] nd/clear-gitenv-upon-use-of-alias
Am 23.12.2015 um 10:37 schrieb Jeff King:
The second line comes from handle_alias itself. It calls
die_errno whenever run_command returns a negative value.
However, only -1 indicates a syscall error where errno has
something useful (note that it says the useless "success"
above). Instead, we treat negative returns from run_command
(except for -1) as a normal code to be passed to exit.
Signed-off-by: Jeff King
---
git.c | 2 +-
run-command.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/git.c b/git.c
index 6ed824c..34a18a3 100644
--- a/git.c
+++ b/git.c
@@ -252,7 +252,7 @@ static int handle_alias(int *argcp, const char ***argv)
alias_argv[argc] = NULL;
ret = run_command_v_opt(alias_argv, RUN_USING_SHELL);
- if (ret >= 0) /* normal exit */
+ if (ret != -1) /* normal exit */
Why does this make a difference? We only ever return -1, zero, or a
positive value from run_command/finish_command/wait_or_whine, as far as
I can see.
exit(ret);
die_errno("While expanding alias '%s': '%s'",
-- Hannes
--
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 v3 00/11] Untracked cache improvements
Here is a new version of a patch series to improve the untracked cache feature. This v3 still implements core.untrackedCache as a simple bool config variable. When it's true, Git should always try to use the untracked cache, and when false, Git should never use it. Patch 1/11 is a small bugfix that has been moved to the start of the series so it might get applied independently. Patch 2/11 to 4/11 add some small features that are missing. They haven't been changed since the previous series. Patchs 5/11 to 8/11 are some refactoring to prepare for the following patchs. Among them 7/11 is new, the others haven't changed. Patch 9/11 replaces patch 10/10 in the previous series. It deals with the "ident" field in "struct untracked_cache". As suggested by Junio, we keep paying attention to the location of the work tree that is stored in this field, but otherwise things are simplified a lot. Patch 10/11 which adds core.untrackedCache, contains a few simplifications compared to v2. Patch 11/11 has not been changed. So the changes compared to v2 are mostly small updates, and patchs 7/11 and 9/11. The patch series is also available there: https://github.com/chriscool/git/tree/uc-notifs34 Thanks to the reviewers and helpers. Christian Couder (11): dir: free untracked cache when removing it update-index: use enum for untracked cache options update-index: add --test-untracked-cache update-index: add untracked cache notifications update-index: move 'uc' var declaration dir: add add_untracked_cache() dir: add new_untracked_cache() dir: add remove_untracked_cache() dir: simplify untracked cache "ident" field config: add core.untrackedCache t7063: add tests for core.untrackedCache Documentation/config.txt | 7 Documentation/git-update-index.txt | 61 - builtin/update-index.c | 54 ++ cache.h| 1 + config.c | 4 ++ contrib/completion/git-completion.bash | 1 + dir.c | 70 -- dir.h | 2 + environment.c | 1 + t/t7063-status-untracked-cache.sh | 52 ++--- wt-status.c| 5 +++ 11 files changed, 207 insertions(+), 51 deletions(-) -- 2.7.0.rc2.11.g68ccdd4 -- 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 v3 01/11] dir: free untracked cache when removing it
Signed-off-by: Christian Couder
---
builtin/update-index.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/builtin/update-index.c b/builtin/update-index.c
index 7431938..a6fff87 100644
--- a/builtin/update-index.c
+++ b/builtin/update-index.c
@@ -1123,6 +1123,7 @@ int cmd_update_index(int argc, const char **argv, const
char *prefix)
add_untracked_ident(the_index.untracked);
the_index.cache_changed |= UNTRACKED_CHANGED;
} else if (!untracked_cache && the_index.untracked) {
+ free_untracked_cache(the_index.untracked);
the_index.untracked = NULL;
the_index.cache_changed |= UNTRACKED_CHANGED;
}
--
2.7.0.rc2.11.g68ccdd4
--
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 v3 02/11] update-index: use enum for untracked cache options
Signed-off-by: Christian Couder
---
builtin/update-index.c | 18 +-
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/builtin/update-index.c b/builtin/update-index.c
index a6fff87..1e546a3 100644
--- a/builtin/update-index.c
+++ b/builtin/update-index.c
@@ -35,6 +35,14 @@ static int mark_skip_worktree_only;
#define UNMARK_FLAG 2
static struct strbuf mtime_dir = STRBUF_INIT;
+/* Untracked cache mode */
+enum uc_mode {
+ UC_UNSPECIFIED = -1,
+ UC_DISABLE = 0,
+ UC_ENABLE,
+ UC_FORCE
+};
+
__attribute__((format (printf, 1, 2)))
static void report(const char *fmt, ...)
{
@@ -902,7 +910,7 @@ static int reupdate_callback(struct parse_opt_ctx_t *ctx,
int cmd_update_index(int argc, const char **argv, const char *prefix)
{
int newfd, entries, has_errors = 0, line_termination = '\n';
- int untracked_cache = -1;
+ enum uc_mode untracked_cache = UC_UNSPECIFIED;
int read_from_stdin = 0;
int prefix_length = prefix ? strlen(prefix) : 0;
int preferred_index_format = 0;
@@ -997,7 +1005,7 @@ int cmd_update_index(int argc, const char **argv, const
char *prefix)
OPT_BOOL(0, "untracked-cache", &untracked_cache,
N_("enable/disable untracked cache")),
OPT_SET_INT(0, "force-untracked-cache", &untracked_cache,
- N_("enable untracked cache without testing the
filesystem"), 2),
+ N_("enable untracked cache without testing the
filesystem"), UC_FORCE),
OPT_END()
};
@@ -1104,10 +1112,10 @@ int cmd_update_index(int argc, const char **argv, const
char *prefix)
the_index.split_index = NULL;
the_index.cache_changed |= SOMETHING_CHANGED;
}
- if (untracked_cache > 0) {
+ if (untracked_cache > UC_DISABLE) {
struct untracked_cache *uc;
- if (untracked_cache < 2) {
+ if (untracked_cache < UC_FORCE) {
setup_work_tree();
if (!test_if_untracked_cache_is_supported())
return 1;
@@ -1122,7 +1130,7 @@ int cmd_update_index(int argc, const char **argv, const
char *prefix)
}
add_untracked_ident(the_index.untracked);
the_index.cache_changed |= UNTRACKED_CHANGED;
- } else if (!untracked_cache && the_index.untracked) {
+ } else if (untracked_cache == UC_DISABLE && the_index.untracked) {
free_untracked_cache(the_index.untracked);
the_index.untracked = NULL;
the_index.cache_changed |= UNTRACKED_CHANGED;
--
2.7.0.rc2.11.g68ccdd4
--
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 v3 03/11] update-index: add --test-untracked-cache
It is nice to just be able to test if untracked cache is
supported without enabling it.
Signed-off-by: Christian Couder
---
Documentation/git-update-index.txt | 9 -
builtin/update-index.c | 5 +
2 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/Documentation/git-update-index.txt
b/Documentation/git-update-index.txt
index f4e5a85..a0ee0c9 100644
--- a/Documentation/git-update-index.txt
+++ b/Documentation/git-update-index.txt
@@ -18,7 +18,7 @@ SYNOPSIS
[--[no-]skip-worktree]
[--ignore-submodules]
[--[no-]split-index]
-[--[no-|force-]untracked-cache]
+[--[no-|test-|force-]untracked-cache]
[--really-refresh] [--unresolve] [--again | -g]
[--info-only] [--index-info]
[-z] [--stdin] [--index-version ]
@@ -180,6 +180,13 @@ may not support it yet.
system must change `st_mtime` field of a directory if files
are added or deleted in that directory.
+--test-untracked-cache::
+ Only perform tests on the working directory to make sure
+ untracked cache can be used. You have to manually enable
+ untracked cache using `--force-untracked-cache` (or
+ `--untracked-cache` but this will run the tests again)
+ afterwards if you really want to use it.
+
--force-untracked-cache::
For safety, `--untracked-cache` performs tests on the working
directory to make sure untracked cache can be used. These
diff --git a/builtin/update-index.c b/builtin/update-index.c
index 1e546a3..6dd 100644
--- a/builtin/update-index.c
+++ b/builtin/update-index.c
@@ -40,6 +40,7 @@ enum uc_mode {
UC_UNSPECIFIED = -1,
UC_DISABLE = 0,
UC_ENABLE,
+ UC_TEST,
UC_FORCE
};
@@ -1004,6 +1005,8 @@ int cmd_update_index(int argc, const char **argv, const
char *prefix)
N_("enable or disable split index")),
OPT_BOOL(0, "untracked-cache", &untracked_cache,
N_("enable/disable untracked cache")),
+ OPT_SET_INT(0, "test-untracked-cache", &untracked_cache,
+ N_("test if the filesystem supports untracked
cache"), UC_TEST),
OPT_SET_INT(0, "force-untracked-cache", &untracked_cache,
N_("enable untracked cache without testing the
filesystem"), UC_FORCE),
OPT_END()
@@ -1119,6 +1122,8 @@ int cmd_update_index(int argc, const char **argv, const
char *prefix)
setup_work_tree();
if (!test_if_untracked_cache_is_supported())
return 1;
+ if (untracked_cache == UC_TEST)
+ return 0;
}
if (!the_index.untracked) {
uc = xcalloc(1, sizeof(*uc));
--
2.7.0.rc2.11.g68ccdd4
--
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 v3 05/11] update-index: move 'uc' var declaration
Signed-off-by: Christian Couder
---
builtin/update-index.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/builtin/update-index.c b/builtin/update-index.c
index c91e695..f667125 100644
--- a/builtin/update-index.c
+++ b/builtin/update-index.c
@@ -1116,8 +1116,6 @@ int cmd_update_index(int argc, const char **argv, const
char *prefix)
the_index.cache_changed |= SOMETHING_CHANGED;
}
if (untracked_cache > UC_DISABLE) {
- struct untracked_cache *uc;
-
if (untracked_cache < UC_FORCE) {
setup_work_tree();
if (!test_if_untracked_cache_is_supported())
@@ -1126,7 +1124,7 @@ int cmd_update_index(int argc, const char **argv, const
char *prefix)
return 0;
}
if (!the_index.untracked) {
- uc = xcalloc(1, sizeof(*uc));
+ struct untracked_cache *uc = xcalloc(1, sizeof(*uc));
strbuf_init(&uc->ident, 100);
uc->exclude_per_dir = ".gitignore";
/* should be the same flags used by git-status */
--
2.7.0.rc2.11.g68ccdd4
--
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 v3 04/11] update-index: add untracked cache notifications
Attempting to flip the untracked-cache feature on for a random index
file with
cd /random/unrelated/place
git --git-dir=/somewhere/else/.git update-index --untracked-cache
would not work as you might expect. Because flipping the feature on
in the index also records the location of the corresponding working
tree (/random/unrelated/place in the above example), when the index
is subsequently used to keep track of files in the working tree in
/somewhere/else, the feature is disabled.
With this patch "git update-index --[test-]untracked-cache" tells the
user in which directory tests are performed. This makes it easy to
spot any problem.
Also in verbose mode, let's tell the user when the cache is enabled
or disabled.
Signed-off-by: Christian Couder
---
builtin/update-index.c | 16 +++-
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/builtin/update-index.c b/builtin/update-index.c
index 6dd..c91e695 100644
--- a/builtin/update-index.c
+++ b/builtin/update-index.c
@@ -130,7 +130,7 @@ static int test_if_untracked_cache_is_supported(void)
if (!mkdtemp(mtime_dir.buf))
die_errno("Could not make temporary directory");
- fprintf(stderr, _("Testing "));
+ fprintf(stderr, _("Testing mtime in '%s' "), xgetcwd());
atexit(remove_test_directory);
xstat_mtime_dir(&st);
fill_stat_data(&base, &st);
@@ -1135,10 +1135,16 @@ int cmd_update_index(int argc, const char **argv, const
char *prefix)
}
add_untracked_ident(the_index.untracked);
the_index.cache_changed |= UNTRACKED_CHANGED;
- } else if (untracked_cache == UC_DISABLE && the_index.untracked) {
- free_untracked_cache(the_index.untracked);
- the_index.untracked = NULL;
- the_index.cache_changed |= UNTRACKED_CHANGED;
+ if (verbose)
+ printf(_("Untracked cache enabled for '%s'\n"),
get_git_work_tree());
+ } else if (untracked_cache == UC_DISABLE) {
+ if (the_index.untracked) {
+ free_untracked_cache(the_index.untracked);
+ the_index.untracked = NULL;
+ the_index.cache_changed |= UNTRACKED_CHANGED;
+ }
+ if (verbose)
+ printf(_("Untracked cache disabled\n"));
}
if (active_cache_changed) {
--
2.7.0.rc2.11.g68ccdd4
--
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 v3 06/11] dir: add add_untracked_cache()
Factor out code into add_untracked_cache(), which will be used
in a later commit.
Signed-off-by: Christian Couder
---
builtin/update-index.c | 11 +--
dir.c | 14 ++
dir.h | 1 +
3 files changed, 16 insertions(+), 10 deletions(-)
diff --git a/builtin/update-index.c b/builtin/update-index.c
index f667125..093725a 100644
--- a/builtin/update-index.c
+++ b/builtin/update-index.c
@@ -1123,16 +1123,7 @@ int cmd_update_index(int argc, const char **argv, const
char *prefix)
if (untracked_cache == UC_TEST)
return 0;
}
- if (!the_index.untracked) {
- struct untracked_cache *uc = xcalloc(1, sizeof(*uc));
- strbuf_init(&uc->ident, 100);
- uc->exclude_per_dir = ".gitignore";
- /* should be the same flags used by git-status */
- uc->dir_flags = DIR_SHOW_OTHER_DIRECTORIES |
DIR_HIDE_EMPTY_DIRECTORIES;
- the_index.untracked = uc;
- }
- add_untracked_ident(the_index.untracked);
- the_index.cache_changed |= UNTRACKED_CHANGED;
+ add_untracked_cache();
if (verbose)
printf(_("Untracked cache enabled for '%s'\n"),
get_git_work_tree());
} else if (untracked_cache == UC_DISABLE) {
diff --git a/dir.c b/dir.c
index d2a8f06..0f7e293 100644
--- a/dir.c
+++ b/dir.c
@@ -1938,6 +1938,20 @@ void add_untracked_ident(struct untracked_cache *uc)
strbuf_addch(&uc->ident, 0);
}
+void add_untracked_cache(void)
+{
+ if (!the_index.untracked) {
+ struct untracked_cache *uc = xcalloc(1, sizeof(*uc));
+ strbuf_init(&uc->ident, 100);
+ uc->exclude_per_dir = ".gitignore";
+ /* should be the same flags used by git-status */
+ uc->dir_flags = DIR_SHOW_OTHER_DIRECTORIES |
DIR_HIDE_EMPTY_DIRECTORIES;
+ the_index.untracked = uc;
+ }
+ add_untracked_ident(the_index.untracked);
+ the_index.cache_changed |= UNTRACKED_CHANGED;
+}
+
static struct untracked_cache_dir *validate_untracked_cache(struct dir_struct
*dir,
int base_len,
const struct pathspec
*pathspec)
diff --git a/dir.h b/dir.h
index 7b5855d..ee94c76 100644
--- a/dir.h
+++ b/dir.h
@@ -308,4 +308,5 @@ void free_untracked_cache(struct untracked_cache *);
struct untracked_cache *read_untracked_extension(const void *data, unsigned
long sz);
void write_untracked_extension(struct strbuf *out, struct untracked_cache
*untracked);
void add_untracked_ident(struct untracked_cache *);
+void add_untracked_cache(void);
#endif
--
2.7.0.rc2.11.g68ccdd4
--
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 v3 07/11] dir: add new_untracked_cache()
Factor out code into new_untracked_cache(), which will be used
multiple times in a later commit.
Signed-off-by: Christian Couder
---
dir.c | 20
1 file changed, 12 insertions(+), 8 deletions(-)
diff --git a/dir.c b/dir.c
index 0f7e293..4227ba6 100644
--- a/dir.c
+++ b/dir.c
@@ -1938,16 +1938,20 @@ void add_untracked_ident(struct untracked_cache *uc)
strbuf_addch(&uc->ident, 0);
}
+static void new_untracked_cache(void)
+{
+ struct untracked_cache *uc = xcalloc(1, sizeof(*uc));
+ strbuf_init(&uc->ident, 100);
+ uc->exclude_per_dir = ".gitignore";
+ /* should be the same flags used by git-status */
+ uc->dir_flags = DIR_SHOW_OTHER_DIRECTORIES | DIR_HIDE_EMPTY_DIRECTORIES;
+ the_index.untracked = uc;
+}
+
void add_untracked_cache(void)
{
- if (!the_index.untracked) {
- struct untracked_cache *uc = xcalloc(1, sizeof(*uc));
- strbuf_init(&uc->ident, 100);
- uc->exclude_per_dir = ".gitignore";
- /* should be the same flags used by git-status */
- uc->dir_flags = DIR_SHOW_OTHER_DIRECTORIES |
DIR_HIDE_EMPTY_DIRECTORIES;
- the_index.untracked = uc;
- }
+ if (!the_index.untracked)
+ new_untracked_cache();
add_untracked_ident(the_index.untracked);
the_index.cache_changed |= UNTRACKED_CHANGED;
}
--
2.7.0.rc2.11.g68ccdd4
--
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 v3 08/11] dir: add remove_untracked_cache()
Factor out code into remove_untracked_cache(), which will be used
in a later commit.
Signed-off-by: Christian Couder
---
builtin/update-index.c | 6 +-
dir.c | 9 +
dir.h | 1 +
3 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/builtin/update-index.c b/builtin/update-index.c
index 093725a..3e5b4a6 100644
--- a/builtin/update-index.c
+++ b/builtin/update-index.c
@@ -1127,11 +1127,7 @@ int cmd_update_index(int argc, const char **argv, const
char *prefix)
if (verbose)
printf(_("Untracked cache enabled for '%s'\n"),
get_git_work_tree());
} else if (untracked_cache == UC_DISABLE) {
- if (the_index.untracked) {
- free_untracked_cache(the_index.untracked);
- the_index.untracked = NULL;
- the_index.cache_changed |= UNTRACKED_CHANGED;
- }
+ remove_untracked_cache();
if (verbose)
printf(_("Untracked cache disabled\n"));
}
diff --git a/dir.c b/dir.c
index 4227ba6..dba1ad0 100644
--- a/dir.c
+++ b/dir.c
@@ -1956,6 +1956,15 @@ void add_untracked_cache(void)
the_index.cache_changed |= UNTRACKED_CHANGED;
}
+void remove_untracked_cache(void)
+{
+ if (the_index.untracked) {
+ free_untracked_cache(the_index.untracked);
+ the_index.untracked = NULL;
+ the_index.cache_changed |= UNTRACKED_CHANGED;
+ }
+}
+
static struct untracked_cache_dir *validate_untracked_cache(struct dir_struct
*dir,
int base_len,
const struct pathspec
*pathspec)
diff --git a/dir.h b/dir.h
index ee94c76..3e5114d 100644
--- a/dir.h
+++ b/dir.h
@@ -309,4 +309,5 @@ struct untracked_cache *read_untracked_extension(const void
*data, unsigned long
void write_untracked_extension(struct strbuf *out, struct untracked_cache
*untracked);
void add_untracked_ident(struct untracked_cache *);
void add_untracked_cache(void);
+void remove_untracked_cache(void);
#endif
--
2.7.0.rc2.11.g68ccdd4
--
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 v3 11/11] t7063: add tests for core.untrackedCache
Signed-off-by: Christian Couder --- t/t7063-status-untracked-cache.sh | 48 +-- 1 file changed, 46 insertions(+), 2 deletions(-) diff --git a/t/t7063-status-untracked-cache.sh b/t/t7063-status-untracked-cache.sh index 253160a..f0af41c 100755 --- a/t/t7063-status-untracked-cache.sh +++ b/t/t7063-status-untracked-cache.sh @@ -18,6 +18,10 @@ if ! test_have_prereq UNTRACKED_CACHE; then test_done fi +test_expect_success 'core.untrackedCache is unset' ' + test_must_fail git config --get core.untrackedCache +' + test_expect_success 'setup' ' git init worktree && cd worktree && @@ -28,6 +32,11 @@ test_expect_success 'setup' ' git update-index --untracked-cache ' +test_expect_success 'core.untrackedCache is true' ' + UC=$(git config core.untrackedCache) && + test "$UC" = "true" +' + test_expect_success 'untracked cache is empty' ' test-dump-untracked-cache >../actual && cat >../expect <../actual && - cat >../expect <../expect-from-test-dump <../actual && + echo "no untracked cache" >../expect && + test_cmp ../expect ../actual +' + +test_expect_success 'git status does not change anything' ' + git status && + test-dump-untracked-cache >../actual && + test_cmp ../expect ../actual && + UC=$(git config core.untrackedCache) && + test "$UC" = "false" +' + +test_expect_success 'setting core.untrackedCache and using git status creates the cache' ' + git config core.untrackedCache true && + test-dump-untracked-cache >../actual && + test_cmp ../expect ../actual && + git status && + test-dump-untracked-cache >../actual && + test_cmp ../expect-from-test-dump ../actual +' + +test_expect_success 'unsetting core.untrackedCache and using git status removes the cache' ' + git config --unset core.untrackedCache && + test-dump-untracked-cache >../actual && + test_cmp ../expect-from-test-dump ../actual && + git status && + test-dump-untracked-cache >../actual && + test_cmp ../expect ../actual +' + test_done -- 2.7.0.rc2.11.g68ccdd4 -- 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 v3 10/11] config: add core.untrackedCache
When we know that mtime is fully supported by the environment, we might want the untracked cache to be always used by default without any mtime test or kernel version check being performed. Also when we know that mtime is not supported by the environment, for example because the repo is shared over a network file system, then we might want 'git update-index --untracked-cache' to fail immediately instead of performing tests (because it might work on some systems using the repo over the network file system but not others). The normal way to achieve the above in Git is to use a config variable. That's why this patch introduces "core.untrackedCache". To keep things simple, this variable is a bool which default to false. When "git status" is run, it now adds or removes the untracked cache in the index to respect the value of this variable. The job of `git update-index --[no-|force-]untracked-cache` was to add or remove the untracked cache from the index. This was a kind of configuration because this was persistant across git commands. To make this kind of configuration compatible with the new config variable, the simple thing to do, and what this patch does, is to make `git update-index --[no-|force-]untracked-cache` set or unset this config option. This new behavior is a backward incompatible change, but that is deliberate. The untracked cache feature has been experimental and is very unlikely used by beginners. When people will upgrade, this will remove any untracked cache they used unless they set "core.untrackedCache" before upgrading. This should be stated in the release notes. Also `--untracked-cache` used to check that the underlying operating system and file system change `st_mtime` field of a directory if files are added or deleted in that directory. But those tests take a long time and there is now `--test-untracked-cache` to perform them. That's why, to be more consistent with other git commands, this patch prevents `--untracked-cache` to perform tests, so that after this patch there is no difference any more between `--untracked-cache` and `--force-untracked-cache`. All the changes to `--[no-|force-]untracked-cache` make it possible to deprecate those options in the future. Signed-off-by: Christian Couder Signed-off-by: Ævar Arnfjörð Bjarmason --- Documentation/config.txt | 7 Documentation/git-update-index.txt | 58 +++--- builtin/update-index.c | 15 + cache.h| 1 + config.c | 4 +++ contrib/completion/git-completion.bash | 1 + environment.c | 1 + t/t7063-status-untracked-cache.sh | 4 +-- wt-status.c| 5 +++ 9 files changed, 74 insertions(+), 22 deletions(-) diff --git a/Documentation/config.txt b/Documentation/config.txt index f617886..08f0510 100644 --- a/Documentation/config.txt +++ b/Documentation/config.txt @@ -308,6 +308,13 @@ core.trustctime:: crawlers and some backup systems). See linkgit:git-update-index[1]. True by default. +core.untrackedCache:: + Determines if untracked cache will be enabled. Using + 'git update-index --[no-|force-]untracked-cache' will set + this variable. Before setting it to true, you should check + that mtime is working properly on your system. + See linkgit:git-update-index[1]. False by default. + core.checkStat:: Determines which stat fields to match between the index and work tree. The user can set this to 'default' or diff --git a/Documentation/git-update-index.txt b/Documentation/git-update-index.txt index a0ee0c9..bab6394 100644 --- a/Documentation/git-update-index.txt +++ b/Documentation/git-update-index.txt @@ -174,24 +174,29 @@ may not support it yet. --untracked-cache:: --no-untracked-cache:: - Enable or disable untracked cache extension. This could speed - up for commands that involve determining untracked files such - as `git status`. The underlying operating system and file - system must change `st_mtime` field of a directory if files - are added or deleted in that directory. + Enable or disable untracked cache extension. Please use + `--test-untracked-cache` before enabling it. ++ +These options are mostly aliases for setting the `core.untrackedCache` +configuration variable to 'true' or 'false' in the local config file +(see linkgit:git-config[1]). You can equivalently just set those +configuration values directly. These options are just provided for +backwards compatibility with the older versions of Git where this was +the only way to enable or disable the untracked cache extension. --test-untracked-cache:: Only perform tests on the working directory to make sure untracked cache can be used. You have to manually enable - untracked cache using `--force-untracked-cache` (or - `--untracked-cache
[PATCH v3 09/11] dir: simplify untracked cache "ident" field
It is not a good idea to compare kernel versions and disable
the untracked cache if it changes as people may upgrade and
still want the untracked cache to work. So let's just
compare work tree locations to decide if we should disable
it.
Also it's not useful to store many locations in the ident
field and compare to any of them. It can even be dangerous
if GIT_WORK_TREE is used with different values. So let's
just store one location, the location of the current work
tree.
If this location changed and we still want an untracked
cache, let's delete the cache and recreate it.
Signed-off-by: Christian Couder
---
dir.c | 49 ++---
1 file changed, 34 insertions(+), 15 deletions(-)
diff --git a/dir.c b/dir.c
index dba1ad0..7596a3f 100644
--- a/dir.c
+++ b/dir.c
@@ -1918,23 +1918,36 @@ static const char *get_ident_string(void)
return sb.buf;
}
-static int ident_in_untracked(const struct untracked_cache *uc)
+static int ident_current_location_in_untracked(const struct untracked_cache
*uc)
{
- const char *end = uc->ident.buf + uc->ident.len;
- const char *p = uc->ident.buf;
+ struct strbuf cur_loc = STRBUF_INIT;
+ int res = 0;
- for (p = uc->ident.buf; p < end; p += strlen(p) + 1)
- if (!strcmp(p, get_ident_string()))
- return 1;
- return 0;
+ /*
+* Previous git versions may have saved many strings in the
+* "ident" field, but it is insane to manage many locations,
+* so just take care of the first one.
+*/
+
+ strbuf_addf(&cur_loc, "Location %s, system ", get_git_work_tree());
+
+ if (starts_with(uc->ident.buf, cur_loc.buf))
+ res = 1;
+
+ strbuf_release(&cur_loc);
+
+ return res;
}
-void add_untracked_ident(struct untracked_cache *uc)
+static void set_untracked_ident(struct untracked_cache *uc)
{
- if (ident_in_untracked(uc))
- return;
+ strbuf_reset(&uc->ident);
strbuf_addstr(&uc->ident, get_ident_string());
- /* this strbuf contains a list of strings, save NUL too */
+
+ /*
+* This strbuf used to contain a list of NUL separated
+* strings, so save NUL too for backward compatibility.
+*/
strbuf_addch(&uc->ident, 0);
}
@@ -1945,15 +1958,21 @@ static void new_untracked_cache(void)
uc->exclude_per_dir = ".gitignore";
/* should be the same flags used by git-status */
uc->dir_flags = DIR_SHOW_OTHER_DIRECTORIES | DIR_HIDE_EMPTY_DIRECTORIES;
+ set_untracked_ident(the_index.untracked);
the_index.untracked = uc;
+ the_index.cache_changed |= UNTRACKED_CHANGED;
}
void add_untracked_cache(void)
{
- if (!the_index.untracked)
+ if (!the_index.untracked) {
new_untracked_cache();
- add_untracked_ident(the_index.untracked);
- the_index.cache_changed |= UNTRACKED_CHANGED;
+ } else {
+ if (!ident_current_location_in_untracked(the_index.untracked)) {
+ free_untracked_cache(the_index.untracked);
+ new_untracked_cache();
+ }
+ }
}
void remove_untracked_cache(void)
@@ -2021,7 +2040,7 @@ static struct untracked_cache_dir
*validate_untracked_cache(struct dir_struct *d
if (dir->exclude_list_group[EXC_CMDL].nr)
return NULL;
- if (!ident_in_untracked(dir->untracked)) {
+ if (!ident_current_location_in_untracked(dir->untracked)) {
warning(_("Untracked cache is disabled on this system."));
return NULL;
}
--
2.7.0.rc2.11.g68ccdd4
--
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 v2 0/3] nd/clear-gitenv-upon-use-of-alias
On Wed, Dec 23, 2015 at 09:37:04PM +0100, Johannes Sixt wrote: > >--- a/git.c > >+++ b/git.c > >@@ -252,7 +252,7 @@ static int handle_alias(int *argcp, const char ***argv) > > alias_argv[argc] = NULL; > > > > ret = run_command_v_opt(alias_argv, RUN_USING_SHELL); > >-if (ret >= 0) /* normal exit */ > >+if (ret != -1) /* normal exit */ > > Why does this make a difference? We only ever return -1, zero, or a positive > value from run_command/finish_command/wait_or_whine, as far as I can see. Yeah, you're right. This bit predates 709ca73 (run-command: encode signal death as a positive integer, 2013-01-05), which came out of the same discussion. So I'd agree this hunk can simply be dropped. That leaves the ignoring of SIGPIPE in wait_or_whine. I started to rewrite the commit message to drop the first hunk, but I found I couldn't replicate the problem in the second either! Doing: GIT_PAGER=false git -c alias.foo='!git log -p' foo doesn't trigger it. We run the alias through a shell, so we see only the munged "141" value from the shell's exit code. Something like: GIT_PAGER=false git -p -c alias.foo='!yes' foo does generate the error message. But we've redirected stderr into the pager at that point, so by definition it can never be shown. So I think we would need a case where: - the outer git doesn't run the pager that dies; instead the pager is run inside the alias. But... - inside the alias cannot be a shell pipeline, since "foo | less" will report the exit code of "less", not "foo" (we make special arrangements in git to propagate the exit code of "foo"). So it pretty much has to be a git invocation inside the alias. But... - The git invocation will convert signal death in the sub-process into 141, like a shell would. So I'm not sure if this is triggerable at all with an alias. I did manage to trigger it with an external command, like: $ cat $(which git-yes) #!/bin/sh # This _has_ to be exec, otherwise the shell converts SIGPIPE death # into 141. exec yes and then if you run your _own_ pager, like this: $ git yes | false error: git-yes died of signal 13 you see it. But if git starts the pager, you don't: $ GIT_PAGER=false git -p yes Because the stderr of the outer git process is going to the same dead pipe. So my takeaways are: 1. Complaining about signal death in general is going to be flaky, because it's so easy for shells or git to rewrite the exit code and not trigger WIFSIGNALED() in the first place. 2. I doubt anybody is actually seeing this in practice anymore. But maybe I am misunderstanding something in Duy's series that changes this. -Peff -- 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 v3 07/11] dir: add new_untracked_cache()
On Wed, Dec 23, 2015 at 4:03 PM, Christian Couder
wrote:
> Factor out code into new_untracked_cache(), which will be used
> multiple times in a later commit.
Odd indentation: s/^\s+//
> Signed-off-by: Christian Couder
> ---
> diff --git a/dir.c b/dir.c
> @@ -1938,16 +1938,20 @@ void add_untracked_ident(struct untracked_cache *uc)
> strbuf_addch(&uc->ident, 0);
> }
>
> +static void new_untracked_cache(void)
> +{
> + struct untracked_cache *uc = xcalloc(1, sizeof(*uc));
> + strbuf_init(&uc->ident, 100);
> + uc->exclude_per_dir = ".gitignore";
> + /* should be the same flags used by git-status */
> + uc->dir_flags = DIR_SHOW_OTHER_DIRECTORIES |
> DIR_HIDE_EMPTY_DIRECTORIES;
> + the_index.untracked = uc;
> +}
This and the previous patch both move the same code around. As a
reviewer, I could easily see the two patches combined, and would not
find the unified patch onerous to review.
> void add_untracked_cache(void)
> {
> - if (!the_index.untracked) {
> - struct untracked_cache *uc = xcalloc(1, sizeof(*uc));
> - strbuf_init(&uc->ident, 100);
> - uc->exclude_per_dir = ".gitignore";
> - /* should be the same flags used by git-status */
> - uc->dir_flags = DIR_SHOW_OTHER_DIRECTORIES |
> DIR_HIDE_EMPTY_DIRECTORIES;
> - the_index.untracked = uc;
> - }
> + if (!the_index.untracked)
> + new_untracked_cache();
> add_untracked_ident(the_index.untracked);
> the_index.cache_changed |= UNTRACKED_CHANGED;
> }
> --
> 2.7.0.rc2.11.g68ccdd4
--
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] user-manual: remove temporary branch entry from todo list
Remove the suggestion for using a detached HEAD instead of a temporary branch. Signed-off-by: Stephen P. Smith --- Notes: A search of the user manual found only one location which refers to temporary branches. This has to do with how Tony Luck uses them. Even then there is a clarifying parenthetical noting that the temporary branches are topic branches. A git blame showed that the last time that the entry was updated was in 2007. Documentation/user-manual.txt | 3 --- 1 file changed, 3 deletions(-) diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt index 1c790ac..18e2f1e 100644 --- a/Documentation/user-manual.txt +++ b/Documentation/user-manual.txt @@ -4636,9 +4636,6 @@ Scan email archives for other stuff left out Scan man pages to see if any assume more background than this manual provides. -Simplify beginning by suggesting disconnected head instead of -temporary branch creation? - Add more good examples. Entire sections of just cookbook examples might be a good idea; maybe make an "advanced examples" section a standard end-of-chapter section? -- 2.7.0-rc2 -- 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: RefTree: Alternate ref backend
Michael Haggerty writes: > You are answering "What is 'refs/' good for in the pathnames of files > that store loose references?" I was asking "What is 'refs/' good for in > the logical names of references?" > > It would have been totally possible to make the full name of a branch > be, for example, "heads/master" and nevertheless store its loose > reference in "$GIT_DIR/refs/heads/master". The obvious place to store > HEAD in such a scheme would have been "$GIT_DIR/refs/HEAD" while still > calling it "HEAD". This could have avoided the problem that we now have > with pseudo-references like FETCH_HEAD being stored directly in $GIT_DIR. I see; OK. -- 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 7/8] config: add core.untrackedCache
Junio C Hamano writes: > Duy Nguyen writes: > >> In that case we can just check config once in read_index_from and >> destroy UNTR extension. Or the middle ground, we check config once in >> that place, make a note in struct index_state, and make invalidate_* >> check that note instead of config file. The middle ground has an >> advantage over destroying UNTR: (probably) many operations will touch >> index but do not add or remove entries. > > Or we can even teach read_index_from() to skip reading the extension > without even parsing when the configuration tells it that the > feature is force-disabled. It can also add an empty one when the > configuration tells it that the feature is force-enabled and there > is no UNTR extension yet. Thinking about this a bit more, I am starting to feel that the config that can be used to optionally override the presence of in-index UNTR extension does not have to be too bad a thing, provided if it is done with a few tweaks to the design I read in Christian & Ævar's messages. One tweak is to address the following from Ævar's message: >> Once this series is applied and git is shipped with it existing >> users that have set "git update-index --untracked-cache" will have >> their UC feature disabled. This is because we fall back to "oh no >> config here? Must have been disabled, rm it from the index" clause >> which keeps our UC from going stale in the face of config >> flip-flopping. The above would happen only if the configuration is a boolean that defaults to false. I'd think we can have this a tristate instead. That is, config.untrackedCache can be explicitly set to 'true', 'false', or 'keep'. And make a missing config.untrackedCache default to 'keep'. When read_index_from() reads an existing index: When the configuration is set to 'true': an existing UNTR is kept, otherwise a new UNTR gets added. When the configuration is set to 'false: an existing UNTR is dropped. When the configuration is set to 'keep': an existing UNTR is kept, otherwise nothing happens. When write_index() writes out an index that wasn't initialized from the filesystem, a new UNTR gets added only when the configuration is set to 'true' and there is no in-core UNTR already. That way, those who use /etc/gitconfig to force the feature over their users would be able to set it to 'true', those who have been using the feature in some but not all of their repositories won't see any different behaviour until they muck with the configuration (and if they are paranoid and want to opt out of their administrator's setting, they can set it to 'keep' in their $HOME/.gitconfig to make sure their repositories are not affected). Orthogonal to the "config overrides the existing users' practice" issue, I still think that [PATCH v2 10/10] goes too far to remove the safety based on the working tree location. Checking kernel version and other thing may be too much, but the check based on the working tree location is a cheap way to make sure that those who do unusual things (namely, use $GIT_DIR/$GIT_WORK_TREE or their equivalents to tell Git that the working tree for this invocation is at a place different from what UNTR data was prepared for) are not harmed by incorrectly reusing the cached data for an unrelated location. So another tweak I'd feel better to see is to resurrect that safety. I wouldn't have as much issue with such a scheme as I had with the earlier description of the design in the Christian's series. Thanks. -- 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 v3 07/11] dir: add new_untracked_cache()
On Wed, Dec 23, 2015 at 11:53 PM, Eric Sunshine wrote:
> On Wed, Dec 23, 2015 at 4:03 PM, Christian Couder
> wrote:
>> Factor out code into new_untracked_cache(), which will be used
>> multiple times in a later commit.
>
> Odd indentation: s/^\s+//
Yeah, will fix.
>> Signed-off-by: Christian Couder
>> ---
>> diff --git a/dir.c b/dir.c
>> @@ -1938,16 +1938,20 @@ void add_untracked_ident(struct untracked_cache *uc)
>> strbuf_addch(&uc->ident, 0);
>> }
>>
>> +static void new_untracked_cache(void)
>> +{
>> + struct untracked_cache *uc = xcalloc(1, sizeof(*uc));
>> + strbuf_init(&uc->ident, 100);
>> + uc->exclude_per_dir = ".gitignore";
>> + /* should be the same flags used by git-status */
>> + uc->dir_flags = DIR_SHOW_OTHER_DIRECTORIES |
>> DIR_HIDE_EMPTY_DIRECTORIES;
>> + the_index.untracked = uc;
>> +}
>
> This and the previous patch both move the same code around. As a
> reviewer, I could easily see the two patches combined, and would not
> find the unified patch onerous to review.
Ok, I will squash them.
By the way it looks like I have overlooked some reviews by David and
Tosten from the previous round.
Sorry about that. I will take them into account in the next version.
--
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 v2 09/11] ref-filter: introduce remote_ref_atom_parser()
On Thu, Dec 17, 2015 at 2:52 PM, Eric Sunshine wrote:
> On Wed, Dec 16, 2015 at 10:30 AM, Karthik Nayak wrote:
>> Introduce remote_ref_atom_parser() which will parse the '%(upstream)'
>> and '%(push)' atoms and store information into the 'used_atom'
>> structure based on the modifiers used along with the corresponding
>> atom.
>>
>> Helped-by: Ramsay Jones
>> Signed-off-by: Karthik Nayak
>> ---
>> diff --git a/ref-filter.c b/ref-filter.c
>> @@ -37,6 +37,8 @@ static struct used_atom {
>> union {
>> const char *color;
>> struct align align;
>> + enum { RR_SHORTEN, RR_TRACK, RR_TRACKSHORT, RR_NORMAL }
>
> Nit: I'd have expected to see the normal/plain case first rather than
> last (but not itself worth a re-roll).
>
Will add it in. That'll put it in an alphabetical order too.
>> + remote_ref;
>> } u;
>> } *used_atom;
>> static int used_atom_cnt, need_tagged, need_symref;
>> @@ -69,6 +71,25 @@ static void color_atom_parser(struct used_atom *atom)
>> +static void remote_ref_atom_parser(struct used_atom *atom)
>> +{
>> + const char *buf;
>> +
>> + buf = strchr(atom->str, ':');
>> + atom->u.remote_ref = RR_NORMAL;
>> + if (!buf)
>> + return;
>
> This code is not as clear as it could be due to the way the 'buf'
> assignment and check for NULL are split apart. It can be made clearer
> either by doing this:
>
> atom->u.remote_ref = RR_NORMAL;
> buf = strchr(...);
> if (!buf)
> return;
>
> or (even better) this:
>
> buf = strchr(...);
> if (!buf) {
> atom->u.remote_ref = RR_NORMAL;
> return;
> }
>
Will do the latter, thanks.
>> + buf++;
>> + if (!strcmp(buf, "short"))
>> + atom->u.remote_ref = RR_SHORTEN;
>> + else if (!strcmp(buf, "track"))
>> + atom->u.remote_ref = RR_TRACK;
>> + else if (!strcmp(buf, "trackshort"))
>> + atom->u.remote_ref = RR_TRACKSHORT;
>> + else
>> + die(_("unrecognized format: %%(%s)"), atom->str);
>> +}
>> +
>> @@ -835,6 +856,42 @@ static inline char *copy_advance(char *dst, const char
>> *src)
>> +static void fill_remote_ref_details(struct used_atom *atom, const char
>> *refname,
>> + struct branch *branch, const char **s)
>> +{
>> + int num_ours, num_theirs;
>> + if (atom->u.remote_ref == RR_SHORTEN)
>> + *s = shorten_unambiguous_ref(refname, warn_ambiguous_refs);
>> + else if (atom->u.remote_ref == RR_TRACK) {
>> + if (stat_tracking_info(branch, &num_ours,
>> + &num_theirs, NULL))
>> + return;
>
> The RR_TRACKSHORT branch below has a blank line following the
> 'return', but this branch lacks it, which is inconsistent.
>
will add.
>> + if (!num_ours && !num_theirs)
>> + *s = "";
>> + else if (!num_ours)
>> + *s = xstrfmt("[behind %d]", num_theirs);
>> + else if (!num_theirs)
>> + *s = xstrfmt("[ahead %d]", num_ours);
>> + else
>> + *s = xstrfmt("[ahead %d, behind %d]",
>> +num_ours, num_theirs);
>> + } else if (atom->u.remote_ref == RR_TRACKSHORT) {
>> + if (stat_tracking_info(branch, &num_ours,
>> + &num_theirs, NULL))
>
> What happened to the assert(branch) which was in the original code
> from which this was derived (below)? Is it no longer needed?
>
stat_tracking_info() takes care of that, instead of aborting, we gracefully
continue while leaving that value empty.
--
Regards,
Karthik Nayak
--
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
