* [PATCH 04/18] lib-submodule-update.sh: replace sha1 by hash
From: Stefan Beller @ 2017-03-02 0:47 UTC (permalink / raw)
To: sbeller; +Cc: git, bmwill, novalis, sandals, hvoigt, gitster, jrnieder, ramsay
In-Reply-To: <20170302004759.27852-1-sbeller@google.com>
Cleaning up code by generalising it.
Currently the mailing list discusses yet again how
to migrate away from sha1.
Signed-off-by: Stefan Beller <sbeller@google.com>
---
t/lib-submodule-update.sh | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/t/lib-submodule-update.sh b/t/lib-submodule-update.sh
index a906c92cfb..83202c54fc 100755
--- a/t/lib-submodule-update.sh
+++ b/t/lib-submodule-update.sh
@@ -171,9 +171,9 @@ reset_work_tree_to () {
git checkout -f "$1" &&
git status -u -s >actual &&
test_must_be_empty actual &&
- sha1=$(git rev-parse --revs-only HEAD:sub1) &&
- if test -n "$sha1" &&
- test $(cd "../submodule_update_sub1" && git rev-parse --verify "$sha1^{commit}")
+ hash=$(git rev-parse --revs-only HEAD:sub1) &&
+ if test -n "$hash" &&
+ test $(cd "../submodule_update_sub1" && git rev-parse --verify "$hash^{commit}")
then
git submodule update --init --recursive "sub1"
fi
--
2.12.0.rc1.52.ge239d7e709.dirty
^ permalink raw reply related
* [PATCH 08/18] update submodules: add submodule config parsing
From: Stefan Beller @ 2017-03-02 0:47 UTC (permalink / raw)
To: sbeller; +Cc: git, bmwill, novalis, sandals, hvoigt, gitster, jrnieder, ramsay
In-Reply-To: <20170302004759.27852-1-sbeller@google.com>
Similar to b33a15b08 (push: add recurseSubmodules config option,
2015-11-17) and 027771fcb1 (submodule: allow erroneous values for the
fetchRecurseSubmodules option, 2015-08-17), we add submodule-config code
that is later used to parse whether we are interested in updating
submodules.
We need the `die_on_error` parameter to be able to call this parsing
function for the config file as well, which if incorrect lets Git die.
As we're just touching the header file, also mark all functions extern.
Signed-off-by: Stefan Beller <sbeller@google.com>
---
submodule-config.c | 20 ++++++++++++++++++++
submodule-config.h | 17 +++++++++--------
2 files changed, 29 insertions(+), 8 deletions(-)
diff --git a/submodule-config.c b/submodule-config.c
index 93453909cf..3e8e380d98 100644
--- a/submodule-config.c
+++ b/submodule-config.c
@@ -234,6 +234,26 @@ int parse_fetch_recurse_submodules_arg(const char *opt, const char *arg)
return parse_fetch_recurse(opt, arg, 1);
}
+static int parse_update_recurse(const char *opt, const char *arg,
+ int die_on_error)
+{
+ switch (git_config_maybe_bool(opt, arg)) {
+ case 1:
+ return RECURSE_SUBMODULES_ON;
+ case 0:
+ return RECURSE_SUBMODULES_OFF;
+ default:
+ if (die_on_error)
+ die("bad %s argument: %s", opt, arg);
+ return RECURSE_SUBMODULES_ERROR;
+ }
+}
+
+int parse_update_recurse_submodules_arg(const char *opt, const char *arg)
+{
+ return parse_update_recurse(opt, arg, 1);
+}
+
static int parse_push_recurse(const char *opt, const char *arg,
int die_on_error)
{
diff --git a/submodule-config.h b/submodule-config.h
index 70f19363fd..d434ecdb45 100644
--- a/submodule-config.h
+++ b/submodule-config.h
@@ -22,16 +22,17 @@ struct submodule {
int recommend_shallow;
};
-int parse_fetch_recurse_submodules_arg(const char *opt, const char *arg);
-int parse_push_recurse_submodules_arg(const char *opt, const char *arg);
-int parse_submodule_config_option(const char *var, const char *value);
-const struct submodule *submodule_from_name(const unsigned char *commit_or_tree,
- const char *name);
-const struct submodule *submodule_from_path(const unsigned char *commit_or_tree,
- const char *path);
+extern int parse_fetch_recurse_submodules_arg(const char *opt, const char *arg);
+extern int parse_update_recurse_submodules_arg(const char *opt, const char *arg);
+extern int parse_push_recurse_submodules_arg(const char *opt, const char *arg);
+extern int parse_submodule_config_option(const char *var, const char *value);
+extern const struct submodule *submodule_from_name(
+ const unsigned char *commit_or_tree, const char *name);
+extern const struct submodule *submodule_from_path(
+ const unsigned char *commit_or_tree, const char *path);
extern int gitmodule_sha1_from_commit(const unsigned char *commit_sha1,
unsigned char *gitmodules_sha1,
struct strbuf *rev);
-void submodule_free(void);
+extern void submodule_free(void);
#endif /* SUBMODULE_CONFIG_H */
--
2.12.0.rc1.52.ge239d7e709.dirty
^ permalink raw reply related
* [PATCH 12/18] update submodules: add submodule_move_head
From: Stefan Beller @ 2017-03-02 0:47 UTC (permalink / raw)
To: sbeller; +Cc: git, bmwill, novalis, sandals, hvoigt, gitster, jrnieder, ramsay
In-Reply-To: <20170302004759.27852-1-sbeller@google.com>
In later patches we introduce the options and flag for commands
that modify the working directory, e.g. git-checkout.
This piece of code will be used universally for
all these working tree modifications as it
* supports dry run to answer the question:
"Is it safe to change the submodule to this new state?"
e.g. is it overwriting untracked files or are there local
changes that would be overwritten?
* supports a force flag that can be used for resetting
the tree.
Signed-off-by: Stefan Beller <sbeller@google.com>
---
submodule.c | 135 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
submodule.h | 7 ++++
2 files changed, 142 insertions(+)
diff --git a/submodule.c b/submodule.c
index 0b2596e88a..bc5fecf8c5 100644
--- a/submodule.c
+++ b/submodule.c
@@ -1239,6 +1239,141 @@ int bad_to_remove_submodule(const char *path, unsigned flags)
return ret;
}
+static int submodule_has_dirty_index(const struct submodule *sub)
+{
+ struct child_process cp = CHILD_PROCESS_INIT;
+
+ prepare_submodule_repo_env_no_git_dir(&cp.env_array);
+
+ cp.git_cmd = 1;
+ argv_array_pushl(&cp.args, "diff-index", "--quiet", \
+ "--cached", "HEAD", NULL);
+ cp.no_stdin = 1;
+ cp.no_stdout = 1;
+ cp.dir = sub->path;
+ if (start_command(&cp))
+ die("could not recurse into submodule '%s'", sub->path);
+
+ return finish_command(&cp);
+}
+
+static void submodule_reset_index(const char *path)
+{
+ struct child_process cp = CHILD_PROCESS_INIT;
+ prepare_submodule_repo_env_no_git_dir(&cp.env_array);
+
+ cp.git_cmd = 1;
+ cp.no_stdin = 1;
+ cp.dir = path;
+
+ argv_array_pushf(&cp.args, "--super-prefix=%s/", path);
+ argv_array_pushl(&cp.args, "read-tree", "-u", "--reset", NULL);
+
+ argv_array_push(&cp.args, EMPTY_TREE_SHA1_HEX);
+
+ if (run_command(&cp))
+ die("could not reset submodule index");
+}
+
+/**
+ * Moves a submodule at a given path from a given head to another new head.
+ * For edge cases (a submodule coming into existence or removing a submodule)
+ * pass NULL for old or new respectively.
+ */
+int submodule_move_head(const char *path,
+ const char *old,
+ const char *new,
+ unsigned flags)
+{
+ int ret = 0;
+ struct child_process cp = CHILD_PROCESS_INIT;
+ const struct submodule *sub;
+
+ sub = submodule_from_path(null_sha1, path);
+
+ if (!sub)
+ die("BUG: could not get submodule information for '%s'", path);
+
+ if (old && !(flags & SUBMODULE_MOVE_HEAD_FORCE)) {
+ /* Check if the submodule has a dirty index. */
+ if (submodule_has_dirty_index(sub))
+ return error(_("submodule '%s' has dirty index"), path);
+ }
+
+ if (!(flags & SUBMODULE_MOVE_HEAD_DRY_RUN)) {
+ if (old) {
+ if (!submodule_uses_gitfile(path))
+ absorb_git_dir_into_superproject("", path,
+ ABSORB_GITDIR_RECURSE_SUBMODULES);
+ } else {
+ struct strbuf sb = STRBUF_INIT;
+ strbuf_addf(&sb, "%s/modules/%s",
+ get_git_common_dir(), sub->name);
+ connect_work_tree_and_git_dir(path, sb.buf);
+ strbuf_release(&sb);
+
+ /* make sure the index is clean as well */
+ submodule_reset_index(path);
+ }
+ }
+
+ prepare_submodule_repo_env_no_git_dir(&cp.env_array);
+
+ cp.git_cmd = 1;
+ cp.no_stdin = 1;
+ cp.dir = path;
+
+ argv_array_pushf(&cp.args, "--super-prefix=%s/", path);
+ argv_array_pushl(&cp.args, "read-tree", NULL);
+
+ if (flags & SUBMODULE_MOVE_HEAD_DRY_RUN)
+ argv_array_push(&cp.args, "-n");
+ else
+ argv_array_push(&cp.args, "-u");
+
+ if (flags & SUBMODULE_MOVE_HEAD_FORCE)
+ argv_array_push(&cp.args, "--reset");
+ else
+ argv_array_push(&cp.args, "-m");
+
+ argv_array_push(&cp.args, old ? old : EMPTY_TREE_SHA1_HEX);
+ argv_array_push(&cp.args, new ? new : EMPTY_TREE_SHA1_HEX);
+
+ if (run_command(&cp)) {
+ ret = -1;
+ goto out;
+ }
+
+ if (!(flags & SUBMODULE_MOVE_HEAD_DRY_RUN)) {
+ if (new) {
+ struct child_process cp1 = CHILD_PROCESS_INIT;
+ /* also set the HEAD accordingly */
+ cp1.git_cmd = 1;
+ cp1.no_stdin = 1;
+ cp1.dir = path;
+
+ argv_array_pushl(&cp1.args, "update-ref", "HEAD",
+ new ? new : EMPTY_TREE_SHA1_HEX, NULL);
+
+ if (run_command(&cp1)) {
+ ret = -1;
+ goto out;
+ }
+ } else {
+ struct strbuf sb = STRBUF_INIT;
+
+ strbuf_addf(&sb, "%s/.git", path);
+ unlink_or_warn(sb.buf);
+ strbuf_release(&sb);
+
+ if (is_empty_dir(path))
+ rmdir_or_warn(path);
+ }
+ }
+out:
+ return ret;
+}
+
static int find_first_merges(struct object_array *result, const char *path,
struct commit *a, struct commit *b)
{
diff --git a/submodule.h b/submodule.h
index 6f3fe85c7c..4cdf6445f7 100644
--- a/submodule.h
+++ b/submodule.h
@@ -96,6 +96,13 @@ extern int push_unpushed_submodules(struct sha1_array *commits,
extern void connect_work_tree_and_git_dir(const char *work_tree, const char *git_dir);
extern int parallel_submodules(void);
+#define SUBMODULE_MOVE_HEAD_DRY_RUN (1<<0)
+#define SUBMODULE_MOVE_HEAD_FORCE (1<<1)
+extern int submodule_move_head(const char *path,
+ const char *old,
+ const char *new,
+ unsigned flags);
+
/*
* Prepare the "env_array" parameter of a "struct child_process" for executing
* a submodule by clearing any repo-specific envirionment variables, but
--
2.12.0.rc1.52.ge239d7e709.dirty
^ permalink raw reply related
* [PATCH 10/18] submodules: introduce check to see whether to touch a submodule
From: Stefan Beller @ 2017-03-02 0:47 UTC (permalink / raw)
To: sbeller; +Cc: git, bmwill, novalis, sandals, hvoigt, gitster, jrnieder, ramsay
In-Reply-To: <20170302004759.27852-1-sbeller@google.com>
In later patches we introduce the --recurse-submodule flag for commands
that modify the working directory, e.g. git-checkout.
It is potentially expensive to check if a submodule needs an update,
because a common theme to interact with submodules is to spawn a child
process for each interaction.
So let's introduce a function that checks if a submodule needs
to be checked for an update before attempting the update.
Signed-off-by: Stefan Beller <sbeller@google.com>
---
submodule.c | 16 ++++++++++++++++
submodule.h | 7 +++++++
2 files changed, 23 insertions(+)
diff --git a/submodule.c b/submodule.c
index 591f4a694e..8b2c0212be 100644
--- a/submodule.c
+++ b/submodule.c
@@ -548,6 +548,22 @@ void set_config_update_recurse_submodules(int value)
config_update_recurse_submodules = value;
}
+int should_update_submodules(void)
+{
+ return config_update_recurse_submodules == RECURSE_SUBMODULES_ON;
+}
+
+const struct submodule *submodule_from_ce(const struct cache_entry *ce)
+{
+ if (!S_ISGITLINK(ce->ce_mode))
+ return NULL;
+
+ if (!should_update_submodules())
+ return NULL;
+
+ return submodule_from_path(null_sha1, ce->name);
+}
+
static int has_remote(const char *refname, const struct object_id *oid,
int flags, void *cb_data)
{
diff --git a/submodule.h b/submodule.h
index b4e60c08d2..6f3fe85c7c 100644
--- a/submodule.h
+++ b/submodule.h
@@ -65,6 +65,13 @@ extern void show_submodule_inline_diff(FILE *f, const char *path,
const struct diff_options *opt);
extern void set_config_fetch_recurse_submodules(int value);
extern void set_config_update_recurse_submodules(int value);
+/* Check if we want to update any submodule.*/
+extern int should_update_submodules(void);
+/*
+ * Returns the submodule struct if the given ce entry is a submodule
+ * and it should be updated. Returns NULL otherwise.
+ */
+extern const struct submodule *submodule_from_ce(const struct cache_entry *ce);
extern void check_for_new_submodule_commits(unsigned char new_sha1[20]);
extern int fetch_populated_submodules(const struct argv_array *options,
const char *prefix, int command_line_option,
--
2.12.0.rc1.52.ge239d7e709.dirty
^ permalink raw reply related
* [PATCH 02/18] lib-submodule-update.sh: do not use ./. as submodule remote
From: Stefan Beller @ 2017-03-02 0:47 UTC (permalink / raw)
To: sbeller; +Cc: git, bmwill, novalis, sandals, hvoigt, gitster, jrnieder, ramsay
In-Reply-To: <20170302004759.27852-1-sbeller@google.com>
Adding the repository itself as a submodule does not make sense in the
real world. In our test suite we used to do that out of convenience in
some tests as the current repository has easiest access for setting up
'just a submodule'.
However this doesn't quite test the real world, so let's do not follow
this pattern any further and actually create an independent repository
that we can use as a submodule.
When using './.' as the remote the superproject and submodule share the
same objects, such that testing if a given sha1 is a valid commit works
in either repository. As running commands in an unpopulated submodule
fall back to the superproject, this happens in `reset_work_tree_to`
to determine if we need to populate the submodule. Fix this bug by
checking in the actual remote now.
Signed-off-by: Stefan Beller <sbeller@google.com>
---
t/lib-submodule-update.sh | 15 +++++++++++++--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/t/lib-submodule-update.sh b/t/lib-submodule-update.sh
index 5df528ea81..c0d6325133 100755
--- a/t/lib-submodule-update.sh
+++ b/t/lib-submodule-update.sh
@@ -37,6 +37,17 @@
#
create_lib_submodule_repo () {
+ git init submodule_update_sub1 &&
+ (
+ cd submodule_update_sub1 &&
+ echo "expect" >>.gitignore &&
+ echo "actual" >>.gitignore &&
+ echo "x" >file1 &&
+ echo "y" >file2 &&
+ git add .gitignore file1 file2 &&
+ git commit -m "Base inside first submodule" &&
+ git branch "no_submodule"
+ ) &&
git init submodule_update_repo &&
(
cd submodule_update_repo &&
@@ -49,7 +60,7 @@ create_lib_submodule_repo () {
git branch "no_submodule" &&
git checkout -b "add_sub1" &&
- git submodule add ./. sub1 &&
+ git submodule add ../submodule_update_sub1 sub1 &&
git config -f .gitmodules submodule.sub1.ignore all &&
git config submodule.sub1.ignore all &&
git add .gitmodules &&
@@ -162,7 +173,7 @@ reset_work_tree_to () {
test_must_be_empty actual &&
sha1=$(git rev-parse --revs-only HEAD:sub1) &&
if test -n "$sha1" &&
- test $(cd "sub1" && git rev-parse --verify "$sha1^{commit}")
+ test $(cd "../submodule_update_sub1" && git rev-parse --verify "$sha1^{commit}")
then
git submodule update --init --recursive "sub1"
fi
--
2.12.0.rc1.52.ge239d7e709.dirty
^ permalink raw reply related
* [PATCH 09/18] update submodules: add a config option to determine if submodules are updated
From: Stefan Beller @ 2017-03-02 0:47 UTC (permalink / raw)
To: sbeller; +Cc: git, bmwill, novalis, sandals, hvoigt, gitster, jrnieder, ramsay
In-Reply-To: <20170302004759.27852-1-sbeller@google.com>
In later patches we introduce the options and flag for commands
that modify the working directory, e.g. git-checkout.
Have a central place to store such settings whether we want to update
a submodule.
Signed-off-by: Stefan Beller <sbeller@google.com>
---
submodule.c | 6 ++++++
submodule.h | 1 +
2 files changed, 7 insertions(+)
diff --git a/submodule.c b/submodule.c
index 04d185738f..591f4a694e 100644
--- a/submodule.c
+++ b/submodule.c
@@ -17,6 +17,7 @@
#include "worktree.h"
static int config_fetch_recurse_submodules = RECURSE_SUBMODULES_ON_DEMAND;
+static int config_update_recurse_submodules = RECURSE_SUBMODULES_DEFAULT;
static int parallel_jobs = 1;
static struct string_list changed_submodule_paths = STRING_LIST_INIT_NODUP;
static int initialized_fetch_ref_tips;
@@ -542,6 +543,11 @@ void set_config_fetch_recurse_submodules(int value)
config_fetch_recurse_submodules = value;
}
+void set_config_update_recurse_submodules(int value)
+{
+ config_update_recurse_submodules = value;
+}
+
static int has_remote(const char *refname, const struct object_id *oid,
int flags, void *cb_data)
{
diff --git a/submodule.h b/submodule.h
index 0b915bd3ac..b4e60c08d2 100644
--- a/submodule.h
+++ b/submodule.h
@@ -64,6 +64,7 @@ extern void show_submodule_inline_diff(FILE *f, const char *path,
const char *del, const char *add, const char *reset,
const struct diff_options *opt);
extern void set_config_fetch_recurse_submodules(int value);
+extern void set_config_update_recurse_submodules(int value);
extern void check_for_new_submodule_commits(unsigned char new_sha1[20]);
extern int fetch_populated_submodules(const struct argv_array *options,
const char *prefix, int command_line_option,
--
2.12.0.rc1.52.ge239d7e709.dirty
^ permalink raw reply related
* Re: Delta compression not so effective
From: Marius Storm-Olsen @ 2017-03-02 0:12 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <CA+55aFx7QFqrHw4e72vOdM5z0rw1CCkL2-UX8ej5CLSBWjLNLA@mail.gmail.com>
On 3/1/2017 12:30, Linus Torvalds wrote:
> On Wed, Mar 1, 2017 at 9:57 AM, Marius Storm-Olsen <mstormo@gmail.com> wrote:
>>
>> Indeed, I did do a
>> -c pack.threads=20 --window-memory=6g
>> to 'git repack', since the machine is a 20-core (40 threads) machine with
>> 126GB of RAM.
>>
>> So I guess with these sized objects, even at 6GB per thread, it's not enough
>> to get a big enough Window for proper delta-packing?
>
> Hmm. The 6GB window should be plenty good enough, unless your blobs
> are in the gigabyte range too.
No, the list of git verify-objects in the previous post was from the
bottom of the sorted list, so those are the largest blobs, ~249MB..
>> This repo took >14hr to repack on 20 threads though ("compression" step was
>> very fast, but stuck 95% of the time in "writing objects"), so I can only
>> imagine how long a pack.threads=1 will take :)
>
> Actually, it's usually the compression phase that should be slow - but
> if something is limiting finding deltas (so that we abort early), then
> that would certainly tend to speed up compression.
>
> The "writing objects" phase should be mainly about the actual IO.
> Which should be much faster *if* you actually find deltas.
So, this repo must be knocking several parts of Git's insides. I was
curious about why it was so slow on the writing objects part, since the
whole repo is on a 4x RAID 5, 7k spindels. Now, they are not SSDs sure,
but the thing has ~400MB/s continuous throughput available.
iostat -m 5 showed trickle read/write to the process, and 80-100% CPU
single thread (since the "write objects" stage is single threaded,
obviously).
The failing delta must be triggering other negative behavior.
> For example, the sorting code thinks that objects with the same name
> across the history are good sources of deltas. But it may be that for
> your case, the binary blobs that you have don't tend to actually
> change in the history, so that heuristic doesn't end up doing
> anything.
These are generally just DLLs (debug & release), which content is
updated due to upstream project updates. So, filenames/paths tend to
stay identical, while content changes throughout history.
> The sorting does use the size and the type too, but the "filename
> hash" (which isn't really a hash, it's something nasty to give
> reasonable results for the case where files get renamed) is the main
> sort key.
>
> So you might well want to look at the sorting code too. If filenames
> (particularly the end of filenames) for the blobs aren't good hints
> for the sorting code, that sort might end up spreading all the blobs
> out rather than sort them by size.
Filenames are fairly static, and the bulk of the 6000 biggest
non-delta'ed blobs are the same DLLs (multiple of them)
> And again, if that happens, the "can I delta these two objects" code
> will notice that the size of the objects are wildly different and
> won't even bother trying. Which speeds up the "compressing" phase, of
> course, but then because you don't get any good deltas, the "writing
> out" phase sucks donkey balls because it does zlib compression on big
> objects and writes them out to disk.
Right, now on this machine, I really didn't notice much difference
between standard zlib level and doing -9. The 203GB version was actually
with zlib=9.
> So there are certainly multiple possible reasons for the deltification
> to not work well for you.
>
> Hos sensitive is your material? Could you make a smaller repo with
> some of the blobs that still show the symptoms? I don't think I want
> to download 206GB of data even if my internet access is good.
Pretty sensitive, and not sure how I can reproduce this reasonable well.
However, I can easily recompile git with any recommended
instrumentation/printfs, if you have any suggestions of good places to
start? If anyone have good file/line numbers, I'll give that a go, and
report back?
Thanks!
--
.marius
^ permalink raw reply
* Re: [PATCH 2/2] pretty: use fmt_output_email_subject()
From: René Scharfe @ 2017-03-01 15:41 UTC (permalink / raw)
To: Jeff King, Adrian Dudau; +Cc: git@vger.kernel.org
In-Reply-To: <58e05599-5dc4-9881-d8c0-89ad1f2e3838@web.de>
Am 01.03.2017 um 12:37 schrieb René Scharfe:
> Add the email-style subject prefix (e.g. "Subject: [PATCH] ") directly
> when it's needed instead of letting log_write_email_headers() prepare
> it in a static buffer in advance. This simplifies storage ownership and
> code flow.
>
> Signed-off-by: Rene Scharfe <l.s.r@web.de>
> ---
> This slows down the last three tests in p4000 by ca. 3% for some reason,
> so we may want to only do the first part for now, which is performance
> neutral on my machine.
Update below.
> diff --git a/commit.h b/commit.h
> index 9c12abb911..459daef94a 100644
> --- a/commit.h
> +++ b/commit.h
> @@ -142,21 +142,24 @@ static inline int cmit_fmt_is_mail(enum cmit_fmt fmt)
> return (fmt == CMIT_FMT_EMAIL || fmt == CMIT_FMT_MBOXRD);
> }
>
> +struct rev_info; /* in revision.h, it circularly uses enum cmit_fmt */
> +
> struct pretty_print_context {
> /*
> * Callers should tweak these to change the behavior of pp_* functions.
> */
> enum cmit_fmt fmt;
> int abbrev;
> - const char *subject;
> const char *after_subject;
> int preserve_subject;
> struct date_mode date_mode;
> unsigned date_mode_explicit:1;
> + unsigned print_email_subject:1;
Turning this into an int restores performance according to p4000.
Didn't know that bitfields can be *that* expensive.
René
^ permalink raw reply
* Re: Delta compression not so effective
From: Marius Storm-Olsen @ 2017-03-01 23:59 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Git Mailing List
In-Reply-To: <CACPiFC+=ZpHT=xh7Y8f68BcXxNYx8EFJfzqqG2ub4NL=uREu7g@mail.gmail.com>
On 3/1/2017 14:19, Martin Langhoff wrote:
> On Wed, Mar 1, 2017 at 8:51 AM, Marius Storm-Olsen <mstormo@gmail.com> wrote:
>> BUT, even still, I would expect Git's delta compression to be quite effective, compared to the compression present in SVN.
>
> jar files are zipfiles. They don't delta in any useful form, and in
> fact they differ even if they contain identical binary files inside.
If you look through the initial post, you'll see that the jar in
question is in fact a tool (BFG) by Roberto Tyley, which is basically
git filter-branch on steroids. I used it to quickly filter out the
extern/ folder, just to prove most of the original size stems from that
particular folder. That's all.
The repo does not contain zip or jar files. A few images and other
compressed formats (except a few 100MBs of proprietary files, which
never change), but nothing unusual.
>> Commits: 32988
>> DB (server) size: 139GB
>
> Are you certain of the on-disk storage at the SVN server? Ideally,
> you've taken the size with a low-level tool like `du -sh
> /path/to/SVNRoot`.
139GB is from 'du -sh' on the SVN server. I imported (via SubGit)
directly from the (hotcopied) SVN folder on the server. So true SVN size.
> Even with no delta compression (as per Junio and Linus' discussion),
> based on past experience importing jar/wars/binaries from SVN into
> git... I'd expect git's worst case to be on-par with SVN, perhaps ~5%
> larger due to compression headers on uncompressible data.
Yes, I was expecting a Git repo <139GB, but like Linus mentioned,
something must be knocking the delta search off its feet, so it bails
out. Loose object -> 'hard' repack didn't show that much difference.
Thanks!
--
.marius
^ permalink raw reply
* Re: [PATCH] Put sha1dc on a diet
From: Linus Torvalds @ 2017-03-01 23:38 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Git Mailing List, Dan Shumow, Marc Stevens
In-Reply-To: <20170301203427.e5xa5ej3czli7c3o@sigill.intra.peff.net>
On Wed, Mar 1, 2017 at 12:34 PM, Jeff King <peff@peff.net> wrote:
>
> I don't think that helps. The sha1 over the pack-file takes about 1.3s
> with openssl, and 5s with sha1dc. So we already know the increase there
> is only a few seconds, not a few minutes.
Yeah, I did a few statistics by adding just logging of "SHA1_Init()"
calls. For that network clone situation, the call distribution is
1 SHA1: Init at builtin/index-pack.c:326
841228 SHA1: Init at builtin/index-pack.c:450
2 SHA1: Init at csum-file.c:152
4415756 SHA1: Init at sha1_file.c:3218
(the line numbers are a bit off from 'pu', because I obviously have
the logging code).
The big number (one for every object) is from
write_sha1_file_prepare(), which we'd want to be the strong collision
checking version because those are things we're about to create git
objects out of. It's called from
- hash_sha1_file() - doesn't actually write the object, but is used
to calculate the sha for incoming data after applying the delta, for
example.
- write_sha1_file() - many uses, actually writes the object
- hash_sha1_file_literally() - git hash-object
and that index-pack.c:450 is from unpack_entry_data() for the base
non-delta objects (which should also be the strong kind).
So all of them should check against collision attacks, so none of them
seem to be things you'd want to optimize away..
So I was wrong in thinking that there were a lot of unnecessary SHA1
calculations in that load. They all look like they should be done with
the slower checking code.
Oh well.
Linus
^ permalink raw reply
* Re: [PATCH v1 1/1] git diff --quiet exits with 1 on clean tree with CRLF conversions
From: Junio C Hamano @ 2017-03-01 23:29 UTC (permalink / raw)
To: Mike Crowe; +Cc: tboegi, git
In-Reply-To: <20170301212535.GA6878@mcrowe.com>
Mike Crowe <mac@mcrowe.com> writes:
> With the above patch, both "git diff" and "git diff --quiet" report that
> there are no changes. Previously Git would report the extra newline
> correctly.
I sent an updated one that (I think) fixes the real issue, which the
extra would_convert_to_git() calls added in the older iteration to
diff_filespec_check_stat_unmatch() were merely papering over.
It would be nice to see if it fixes the issue for you.
Thanks.
^ permalink raw reply
* Re: [PATCH 6/6 v5] revert.c: delegate handling of "-" shorthand to setup_revisions
From: Junio C Hamano @ 2017-03-01 23:18 UTC (permalink / raw)
To: Siddharth Kannan; +Cc: git, Matthieu.Moy, pranit.bauva, peff, pclouds, sandals
In-Reply-To: <1488007487-12965-7-git-send-email-kannan.siddharth12@gmail.com>
Siddharth Kannan <kannan.siddharth12@gmail.com> writes:
> revert.c:run_sequencer calls setup_revisions right after replacing "-" with
> "@{-1}" for this shorthand. A previous patch taught setup_revisions to handle
> this shorthand by doing the required replacement inside revision.c:get_sha1_1.
>
> Hence, the code here is redundant and has been removed.
>
> This patch also adds a test to check that revert recognizes the "-" shorthand.
Unlike "merge" [*1*], I think this one is OK because "git revert
$commit" does not try to say _how_ the commit was given, and most
importantly, it does not say what branch the reverted thing was.
Thanks.
[Footnote]
*1* Probably "checkout" would exhibit the same issue as we saw in
5/6 for "git merge" if you remove the "- to @{-1}" conversion
from it.
^ permalink raw reply
* Re: [PATCH] Put sha1dc on a diet
From: Jeff King @ 2017-03-01 23:19 UTC (permalink / raw)
To: Linus Torvalds
Cc: Johannes Schindelin, Junio C Hamano, Marc Stevens, Dan Shumow,
Git Mailing List
In-Reply-To: <CA+55aFy9=jBJT36FC2HiAeabJBssY=jE=zLxwrXWzhpiFkMUXg@mail.gmail.com>
On Wed, Mar 01, 2017 at 03:05:25PM -0800, Linus Torvalds wrote:
> On Wed, Mar 1, 2017 at 2:51 PM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> >
> > But I think bigger than just developers on Windows OS. There are many
> > developers out there working on large repositories (yes, much larger than
> > Linux). Also using Macs and Linux. I am not at all sure that we want to
> > give them an updated Git they cannot fail to notice to be much slower than
> > before.
>
> Johannes, have you *tried* the patches?
>
> I really don't think you have. It is completely unnoticeable in any
> normal situation. The two cases that it's noticeable is:
>
> - a full fsck is noticeable slower
>
> - a full non-local clone is slower (but not really noticeably so
> since the network traffic dominates).
>
> In other words, I think you're making shit up. I don't think you
> understand how little the SHA1 performance actually matters. It's
> noticeable in benchmarks. It's not noticeable in any normal operation.
>
> .. and yes, I've actually been running the patches locally since I
> posted my first version (which apparently didn't go out to the list
> because of list size limits) and now running the version in 'pu'.
You have to remember that some of the Git for Windows users are doing
horrific things like using repositories with 450MB .git/index files, and
the speed to compute the sha1 during an update is noticeable there.
IMHO that is a good sign that the right approach is to switch to an
index format that doesn't require rewriting all 450MB to update one
entry. But obviously that is a much harder problem than just using an
optimized sha1 implementation.
I do think that could argue for turning on the collision detection only
during object-write operations, which is where it matters. It would be
really trivial to flip the "check collisions" bit on sha1dc. But I
suspect you could go faster still by compiling against two separate
implementations: the fast-as-possible one (which could be openssl or
blk-sha1), and the slower-but-careful sha1dc.
-Peff
^ permalink raw reply
* [PATCH] README: create HTTP/HTTPS links from URLs in Markdown
From: Eric Wong @ 2017-03-01 22:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Markdown supports automatic links by surrounding URLs with
angle brackets, as documented in
<https://daringfireball.net/projects/markdown/syntax#autolink>
While we're at it, update URLs to avoid redirecting clients for
git-scm.com (by using HTTPS) and public-inbox.org (by adding a
trailing slash).
Signed-off-by: Eric Wong <e@80x24.org>
---
I was going to cite some style manuals (MLA, APA, etc),
but it seems current versions do not favor angle brackets.
However, this remains consistent with the recommendations in
RFC 2369 <https://ietf.org/rfc/rfc2369.txt> for mail headers.
README.md | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/README.md b/README.md
index c0cd5580e..f17af66a9 100644
--- a/README.md
+++ b/README.md
@@ -12,7 +12,7 @@ Torvalds with help of a group of hackers around the net.
Please read the file [INSTALL][] for installation instructions.
-Many Git online resources are accessible from http://git-scm.com/
+Many Git online resources are accessible from <https://git-scm.com/>
including full documentation and Git related tools.
See [Documentation/gittutorial.txt][] to get started, then see
@@ -33,8 +33,8 @@ requests, comments and patches to git@vger.kernel.org (read
[Documentation/SubmittingPatches][] for instructions on patch submission).
To subscribe to the list, send an email with just "subscribe git" in
the body to majordomo@vger.kernel.org. The mailing list archives are
-available at https://public-inbox.org/git,
-http://marc.info/?l=git and other archival sites.
+available at <https://public-inbox.org/git/>,
+<http://marc.info/?l=git> and other archival sites.
The maintainer frequently sends the "What's cooking" reports that
list the current status of various development topics to the mailing
--
EW
^ permalink raw reply related
* Re: [PATCH] Put sha1dc on a diet
From: Jeff King @ 2017-03-01 23:13 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Dan Shumow, Git Mailing List, Junio C Hamano, Marc Stevens
In-Reply-To: <CA+55aFwr1jncrk-cekn0Y8rs_S+zs7RrgQ-Jb-ZbgCvmVrHT_A@mail.gmail.com>
On Wed, Mar 01, 2017 at 12:58:39PM -0800, Linus Torvalds wrote:
>> I don't think that helps. The sha1 over the pack-file takes about 1.3s
>> with openssl, and 5s with sha1dc. So we already know the increase there
>> is only a few seconds, not a few minutes.
>
> OK. I guess what w could easily do is to just add an argument to
> git_SHA1_Init() to say whether we want checking or not, and only use the
> checking functions when receiving objects (which would include creating new
> objects from files, and obviously deck).
>
> You'd still eat the cost on the receiving side of a clone, but that's when
> you really want the checking anyway. At least it wouldn't be so visible on
> the sending side, which is all the hosting etc, where there might be server
> utilization issues.
>
> Would that make deployment happier? It should be an easy little flag to
> add, I think.
I don't think it makes all that big a difference. The sending side
wastes the extra 2-3 seconds of CPU to checksum the whole packfile, but
it's not inflating all the object contents in the first place (between
reachability bitmaps to get the list of objects in the first place, and
then verbatim reuse of pack contents).
Which isn't to say it's not reasonable to limit the checking to a few
spots (basically anything that's _writing_ objects). But I don't think
it makes a big difference to the server side of a fetch or clone.
-Peff
^ permalink raw reply
* Re: What's cooking in git.git (Mar 2017, #01; Wed, 1)
From: Junio C Hamano @ 2017-03-01 23:08 UTC (permalink / raw)
To: René Scharfe; +Cc: git
In-Reply-To: <52f043cc-7b39-5ab7-bcdc-894aeb402c12@web.de>
René Scharfe <l.s.r@web.de> writes:
> Am 01.03.2017 um 23:35 schrieb Junio C Hamano:
>> * rs/log-email-subject (2017-03-01) 2 commits
>> - pretty: use fmt_output_email_subject()
>> - log-tree: factor out fmt_output_email_subject()
>>
>> Code clean-up.
>>
>> Will merge to 'next'.
>
> Could you please squash this in? We only use a single context (as
> opposed to an array), so it doesn't have to be especially compact,
> and using a bitfield slows down half of the tests in p4000 by 3%
> for me.
I thought I saw the keyword "bitfield" to the solution for that 3%
somewhere in the thread and forgot when I updated the "What's
cooking" report.
Will do. Thanks for being careful.
>
> ---
> commit.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/commit.h b/commit.h
> index 459daef94a..528272ac9b 100644
> --- a/commit.h
> +++ b/commit.h
> @@ -154,7 +154,7 @@ struct pretty_print_context {
> int preserve_subject;
> struct date_mode date_mode;
> unsigned date_mode_explicit:1;
> - unsigned print_email_subject:1;
> + int print_email_subject;
> int expand_tabs_in_log;
> int need_8bit_cte;
> char *notes_message;
^ permalink raw reply
* Re: [PATCH] Put sha1dc on a diet
From: Linus Torvalds @ 2017-03-01 23:05 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Junio C Hamano, Jeff King, Marc Stevens, Dan Shumow,
Git Mailing List
In-Reply-To: <alpine.DEB.2.20.1703012334400.3767@virtualbox>
On Wed, Mar 1, 2017 at 2:51 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
>
> But I think bigger than just developers on Windows OS. There are many
> developers out there working on large repositories (yes, much larger than
> Linux). Also using Macs and Linux. I am not at all sure that we want to
> give them an updated Git they cannot fail to notice to be much slower than
> before.
Johannes, have you *tried* the patches?
I really don't think you have. It is completely unnoticeable in any
normal situation. The two cases that it's noticeable is:
- a full fsck is noticeable slower
- a full non-local clone is slower (but not really noticeably so
since the network traffic dominates).
In other words, I think you're making shit up. I don't think you
understand how little the SHA1 performance actually matters. It's
noticeable in benchmarks. It's not noticeable in any normal operation.
.. and yes, I've actually been running the patches locally since I
posted my first version (which apparently didn't go out to the list
because of list size limits) and now running the version in 'pu'.
Linus
^ permalink raw reply
* [PATCH v2 0/2] Minor changes to skip gitweb tests without Time::HiRes
From: Ævar Arnfjörð Bjarmason @ 2017-03-01 21:15 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Jakub Narębski,
Ævar Arnfjörð Bjarmason
In-Reply-To: <4b34e3a0-3da7-d821-2a7f-9a420ac1d3f6@gmail.com>
This was originally just one small patch, but Jakub Narębski pointed
out that calling the module "unusable" when we failed to load it was
confusing, so now the start of this series is just a rephrasing of an
existing error message I copied.
Ævar Arnfjörð Bjarmason (2):
gitweb tests: Change confusing "skip_all" phrasing
gitweb tests: Skip tests when we don't have Time::HiRes
t/gitweb-lib.sh | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
--
2.11.0
^ permalink raw reply
* Re: [PATCH 5/6 v5] merge.c: delegate handling of "-" shorthand to revision.c:get_sha1
From: Junio C Hamano @ 2017-03-01 23:05 UTC (permalink / raw)
To: Siddharth Kannan; +Cc: git, Matthieu.Moy, pranit.bauva, peff, pclouds, sandals
In-Reply-To: <xmqqpoi0eho8.fsf@gitster.mtv.corp.google.com>
Junio C Hamano <gitster@pobox.com> writes:
> Siddharth Kannan <kannan.siddharth12@gmail.com> writes:
>
>> The callchain for handling each argument contains the function
>> revision.c:get_sha1 where the shorthand for "-" ~ "@{-1}" has already been
>> implemented in a previous patch; the complete callchain leading to that
>> function is:
>>
>> 1. merge.c:collect_parents
>> 2. commit.c:get_merge_parent : this function calls revision.c:get_sha1
>>
>> This patch also adds a test for checking that the shorthand works properly
>
> This breaks "git merge".
>
>> +test_expect_success 'merge - should work' '
>> + git checkout testing-2 &&
>> + git merge - &&
>> + git rev-parse HEAD HEAD^^ | sort >actual &&
>> + git rev-parse master testing-1 | sort >expect &&
>> + test_cmp expect actual
>
> This test is not sufficient to catch a regression I seem to be
> seeing.
>
> $ git checkout side
> $ git checkout pu
> $ git merge -
>
> used to say "Merge branch 'side' into pu". With this series merged,
> I seem to be getting "Merge commit '-' into pu".
You stopped at get_sha1_1() in your 3817cebabc ("sha1_name.c: teach
get_sha1_1 "-" shorthand for "@{-1}"", 2017-02-25), instead of going
down to get_sha1_basic() and teaching it that "-" means the same
thing as "@{-1}", which would in turn require you to teach
dwim_ref() that "-" is the same thing as "@{-1}". As dwim_ref()
does not know about "-" and does not expand it to the refname like
it expands "@{-1}", it would break and that is why 3817cebabc punts
at a bit higher in the callchain.
The breakage by this patch to "git merge" happens for the same
reason. cmd_merge() calls collect_parents() which annotates the
commits that are merged with their textual name, which used to be
"@{-1}" without this patch but now "-" is passed as-is. This
annotation will be given to merge_name(), and the first thing it
does is dwim_ref(). The function knows what to do with "@{-1}",
but it does not know what to do with "-", and that is why you end up
producing "Merge commit '-' into ...".
Dropping this patch from the series would make things consistent
with what was done in 3817cebabc and I think that is a sensible
place to stop. After the dust settles, We _can_ later dig further
by teaching dwim_ref() and friends what "-" means, and when it is
done, this patch would become useful.
Thanks.
^ permalink raw reply
* Re: What's cooking in git.git (Mar 2017, #01; Wed, 1)
From: René Scharfe @ 2017-03-01 22:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <xmqq60jsfww5.fsf@gitster.mtv.corp.google.com>
Am 01.03.2017 um 23:35 schrieb Junio C Hamano:
> * rs/log-email-subject (2017-03-01) 2 commits
> - pretty: use fmt_output_email_subject()
> - log-tree: factor out fmt_output_email_subject()
>
> Code clean-up.
>
> Will merge to 'next'.
Could you please squash this in? We only use a single context (as
opposed to an array), so it doesn't have to be especially compact,
and using a bitfield slows down half of the tests in p4000 by 3%
for me.
---
commit.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/commit.h b/commit.h
index 459daef94a..528272ac9b 100644
--- a/commit.h
+++ b/commit.h
@@ -154,7 +154,7 @@ struct pretty_print_context {
int preserve_subject;
struct date_mode date_mode;
unsigned date_mode_explicit:1;
- unsigned print_email_subject:1;
+ int print_email_subject;
int expand_tabs_in_log;
int need_8bit_cte;
char *notes_message;
--
2.12.0
^ permalink raw reply related
* Re: [PATCH] Put sha1dc on a diet
From: Johannes Schindelin @ 2017-03-01 22:51 UTC (permalink / raw)
To: Linus Torvalds
Cc: Junio C Hamano, Jeff King, Marc Stevens, Dan Shumow,
Git Mailing List
In-Reply-To: <CA+55aFys5oQ0RySQ+Xv0ZDussr-xZNh4_b3+Upx_d9VPWmpM8Q@mail.gmail.com>
Hi,
On Wed, 1 Mar 2017, Linus Torvalds wrote:
> On Wed, Mar 1, 2017 at 1:56 PM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> > Footnote *1*: I know, it is easy to forget that some developers cannot
> > choose their tools, or even their hardware. In the past, we seemed to take
> > appropriate care, though.
>
> I don't think you need to worry about the Windows side.
I am not. I build G?t for Windows using GCC.
My concern is about that unexpected turn "oh, let's just switch to C99
because, well, because my compiler canehandle it, and everybody else
should just switch tn a modern compiler". That really sounded careless.
> That can continue to do something else.
>
> When I advocated perhaps using USE_SHA1DC by default, I definitely did
> not mean it in a "everywhere, regardless of issues" manner.
>
> For example, the conmfig.mak.uname script already explicitly asks for
> "BLK_SHA1 = YesPlease" for Windows. Don't bother changing that, it's an
> explicit choice.
That setting is only in git.git's version, not in gxt-for-windows/git.git.
We switched to OpenSSL because of speed improvements, in particular with
recent Intel processors.
> But the Linux rules don't actually specify which SHA1 version to use,
> so the main Makefile currently defaults to just using openssl.
>
> So that's the "default" choice I think we might want to change. Not
> the "we're windows, and explicitly want BLK_SHA1 because of
> environment and build infrastructure".
Since we switched away from BLOCK_SHA1, any such change would affect Git
for Windews.
But I think bigger than just developers on Windows OS. There are many
developers out there working on large repositories (yes, much larger than
Linux). Also using Macs and Linux. I am not at all sure that we want to
give them an updated Git they cannot fail to notice to be much slower than
before.
Don't get me wrong: I *hope* that you'll manage to get sha1dc
competitively fast. If you don't, well, then we simply cannot use it by
default for *all* of our calls (you already pointed out that the pack
index' checksum does not need collision detection, and in fact, *any*
operation that works on implicitly trusted data falls into the same court,
e.g. `git add`).
Ciao,
Johannes
^ permalink raw reply
* Re: [PATCH v8 4/6] stash: teach 'push' (and 'create_stash') to honor pathspec
From: Thomas Gummerer @ 2017-03-01 21:57 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Jeff King, Johannes Schindelin, sunny, Jakub Narębski,
Matthieu Moy
In-Reply-To: <xmqqo9xmhshd.fsf@gitster.mtv.corp.google.com>
On 02/28, Junio C Hamano wrote:
> Thomas Gummerer <t.gummerer@gmail.com> writes:
>
> > + git reset ${GIT_QUIET:+-q} -- "$@"
> > + git ls-files -z --modified -- "$@" |
> > + git checkout-index -z --force --stdin
> > + git checkout ${GIT_QUIET:+-q} HEAD -- $(git ls-files -z --modified "$@")
>
> I think you forgot to remove this line, whose correction was added
> as two lines immediately before it. I'll remove it while queuing.
Yes, sorry. What you queued looks good to me, thanks!
> > + git clean --force ${GIT_QUIET:+-q} -d -- "$@"
>
> Thanks.
^ permalink raw reply
* What's cooking in git.git (Mar 2017, #01; Wed, 1)
From: Junio C Hamano @ 2017-03-01 22:35 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'. The ones marked with '.' do not appear in any of
the integration branches, but I am still holding onto them.
Note: some may have sent updates to topics that are marked as "will
merge to 'next'" that cross with this message. I'll try to pick them
up before merging the topics to 'next', but mistakes happen X-< and
it appears at least at my end that the latency of messages sent to
vger reaching recipients has got longer in the past few weeks?
You can find the changes described here in the integration branches
of the repositories listed at
http://git-blame.blogspot.com/p/git-public-repositories.html
--------------------------------------------------
[New Topics]
* jk/interpret-branch-name (2017-02-28) 8 commits
- checkout: restrict @-expansions when finding branch
- strbuf_check_ref_format(): expand only local branches
- branch: restrict @-expansions when deleting
- t3204: test git-branch @-expansion corner cases
- interpret_branch_name: allow callers to restrict expansions
- strbuf_branchname: add docstring
- strbuf_branchname: drop return value
- interpret_branch_name: move docstring to header file
"git branch @" created refs/heads/@ as a branch, and in general the
code that handled @{-1} and @{upstream} was a bit too loose in
disambiguating.
Expecting a reroll.
cf. <20170228123331.wubqplp5zjwzz6is@sigill.intra.peff.net>
* jk/sha1dc (2017-03-01) 7 commits
- Put sha1dc on a diet
- sha1dc: avoid 'for' loop initial decl
- sha1dc: resurrect LICENSE file
- sha1dc: avoid c99 declaration-after-statement
- Makefile: add USE_SHA1DC knob
- sha1dc: adjust header includes for git
- add collision-detecting sha1 implementation
Borrow "detect attempt to create collisions" variant of SHA-1
implementation by Marc Stevens (CWI) and Dan Shumow (Microsoft).
Expecting a cleaned-up reroll after discussion settles.
cf. <CA+55aFxTWqsTTiDKo4DBZT-8Z9t80bGMD3uijzKONa_bYEZABQ@mail.gmail.com>
* js/travis-32bit-linux (2017-02-28) 1 commit
- Travis: also test on 32-bit Linux
Add 32-bit Linux variant to the set of platforms to be tested with
Travis CI.
Will merge to 'next'.
* jt/http-base-url-update-upon-redirect (2017-02-28) 1 commit
- http: attempt updating base URL only if no error
When a redirected http transport gets an error during the
redirected request, we ignored the error we got from the server,
and ended up giving a not-so-useful error message.
Will merge to 'next'.
* jt/mark-tree-uninteresting-for-uninteresting-commit (2017-02-28) 3 commits
- upload-pack: compute blob reachability correctly
- revision: exclude trees/blobs given commit
- revision: unify {tree,blob}_objects in rev_info
The revision/object traversal machinery did not mark all tree and
blob objects that are contained in an uninteresting commit as
uninteresting, because that is quite costly. Instead, it only
marked those that are contained in an uninteresting boundary commit
as uninteresting.
* ps/docs-diffcore (2017-02-28) 2 commits
- docs/diffcore: unquote "Complete Rewrites" in headers
- docs/diffcore: fix grammar in diffcore-rename header
Doc update.
Will merge to 'next'.
* rj/remove-unused-mktemp (2017-02-28) 2 commits
- wrapper.c: remove unused gitmkstemps() function
- wrapper.c: remove unused git_mkstemp() function
Code cleanup.
Will merge to 'next'.
* sb/submodule-init-url-selection (2017-02-28) 1 commit
- submodule init: warn about falling back to a local path
Give a warning when "git submodule init" decides that the submodule
in the working tree is its upstream, as it is not a very common
setup.
Will merge to 'next'.
* jc/diff-populate-filespec-size-only-fix (2017-03-01) 1 commit
- diff: do not short-cut CHECK_SIZE_ONLY check in diff_populate_filespec()
"git diff --quiet" relies on the size field in diff_filespec to be
correctly populated, but diff_populate_filespec() helper function
made an incorrect short-cut when asked only to populate the size
field for paths that need to go through convert_to_git() (e.g. CRLF
conversion).
Will merge to 'next'.
* nd/conditional-config-include (2017-03-01) 4 commits
- SQUASH???
- config: add conditional include
- config.txt: reflow the second include.path paragraph
- config.txt: clarify multiple key values in include.path
The configuration file learned a new "includeIf.<condition>.path"
that includes the contents of the given path only when the
condition holds. This allows you to say "include this work-related
bit only in the repositories under my ~/work/ directory".
I think this is almost ready for 'next'.
* rs/log-email-subject (2017-03-01) 2 commits
- pretty: use fmt_output_email_subject()
- log-tree: factor out fmt_output_email_subject()
Code clean-up.
Will merge to 'next'.
--------------------------------------------------
[Stalled]
* nd/worktree-move (2017-01-27) 7 commits
. fixup! worktree move: new command
. worktree remove: new command
. worktree move: refuse to move worktrees with submodules
. worktree move: accept destination as directory
. worktree move: new command
. worktree.c: add update_worktree_location()
. worktree.c: add validate_worktree()
"git worktree" learned move and remove subcommands.
Tentatively ejected as it seems to break 'pu' when merged.
* pb/bisect (2017-02-18) 28 commits
- fixup! bisect--helper: `bisect_next_check` & bisect_voc shell function in C
- bisect--helper: remove the dequote in bisect_start()
- bisect--helper: retire `--bisect-auto-next` subcommand
- bisect--helper: retire `--bisect-autostart` subcommand
- bisect--helper: retire `--bisect-write` subcommand
- bisect--helper: `bisect_replay` shell function in C
- bisect--helper: `bisect_log` shell function in C
- bisect--helper: retire `--write-terms` subcommand
- bisect--helper: retire `--check-expected-revs` subcommand
- bisect--helper: `bisect_state` & `bisect_head` shell function in C
- bisect--helper: `bisect_autostart` shell function in C
- bisect--helper: retire `--next-all` subcommand
- bisect--helper: retire `--bisect-clean-state` subcommand
- bisect--helper: `bisect_next` and `bisect_auto_next` shell function in C
- t6030: no cleanup with bad merge base
- bisect--helper: `bisect_start` shell function partially in C
- bisect--helper: `get_terms` & `bisect_terms` shell function in C
- bisect--helper: `bisect_next_check` & bisect_voc shell function in C
- bisect--helper: `check_and_set_terms` shell function in C
- bisect--helper: `bisect_write` shell function in C
- bisect--helper: `is_expected_rev` & `check_expected_revs` shell function in C
- bisect--helper: `bisect_reset` shell function in C
- wrapper: move is_empty_file() and rename it as is_empty_or_missing_file()
- t6030: explicitly test for bisection cleanup
- bisect--helper: `bisect_clean_state` shell function in C
- bisect--helper: `write_terms` shell function in C
- bisect: rewrite `check_term_format` shell function in C
- bisect--helper: use OPT_CMDMODE instead of OPT_BOOL
Move more parts of "git bisect" to C.
Expecting a reroll.
cf. <CAFZEwPPXPPHi8KiEGS9ggzNHDCGhuqMgH9Z8-Pf9GLshg8+LPA@mail.gmail.com>
cf. <CAFZEwPM9RSTGN54dzaw9gO9iZmsYjJ_d1SjUD4EzSDDbmh-XuA@mail.gmail.com>
cf. <CAFZEwPNUXcNY9Qdz=_B7q2kQuaecPzJtTMGdv8YMUPEz2vnp8A@mail.gmail.com>
* ls/filter-process-delayed (2017-01-08) 1 commit
. convert: add "status=delayed" to filter process protocol
Ejected, as does not build when merged to 'pu'.
* sh/grep-tree-obj-tweak-output (2017-01-20) 2 commits
- grep: use '/' delimiter for paths
- grep: only add delimiter if there isn't one already
"git grep", when fed a tree-ish as an input, shows each hit
prefixed with "<tree-ish>:<path>:<lineno>:". As <tree-ish> is
almost always either a commit or a tag that points at a commit, the
early part of the output "<tree-ish>:<path>" can be used as the
name of the blob and given to "git show". When <tree-ish> is a
tree given in the extended SHA-1 syntax (e.g. "<commit>:", or
"<commit>:<dir>"), however, this results in a string that does not
name a blob (e.g. "<commit>::<path>" or "<commit>:<dir>:<path>").
"git grep" has been taught to be a bit more intelligent about these
cases and omit a colon (in the former case) or use slash (in the
latter case) to produce "<commit>:<path>" and
"<commit>:<dir>/<path>" that can be used as the name of a blob.
Expecting a reroll? Is this good enough with known limitations?
* jc/diff-b-m (2015-02-23) 5 commits
. WIPWIP
. WIP: diff-b-m
- diffcore-rename: allow easier debugging
- diffcore-rename.c: add locate_rename_src()
- diffcore-break: allow debugging
"git diff -B -M" produced incorrect patch when the postimage of a
completely rewritten file is similar to the preimage of a removed
file; such a resulting file must not be expressed as a rename from
other place.
The fix in this patch is broken, unfortunately.
Will discard.
--------------------------------------------------
[Cooking]
* cc/split-index-config (2017-03-01) 22 commits
- Documentation/git-update-index: explain splitIndex.*
- Documentation/config: add splitIndex.sharedIndexExpire
- read-cache: use freshen_shared_index() in read_index_from()
- read-cache: refactor read_index_from()
- t1700: test shared index file expiration
- read-cache: unlink old sharedindex files
- config: add git_config_get_expiry() from gc.c
- read-cache: touch shared index files when used
- sha1_file: make check_and_freshen_file() non static
- Documentation/config: add splitIndex.maxPercentChange
- t1700: add tests for splitIndex.maxPercentChange
- read-cache: regenerate shared index if necessary
- config: add git_config_get_max_percent_split_change()
- Documentation/git-update-index: talk about core.splitIndex config var
- Documentation/config: add information for core.splitIndex
- t1700: add tests for core.splitIndex
- update-index: warn in case of split-index incoherency
- read-cache: add and then use tweak_split_index()
- split-index: add {add,remove}_split_index() functions
- config: add git_config_get_split_index()
- t1700: change here document style
- config: mark an error message up for translation
The experimental "split index" feature has gained a few
configuration variables to make it easier to use.
I think this is almost ready for 'next'.
* dp/filter-branch-prune-empty (2017-02-23) 4 commits
- p7000: add test for filter-branch with --prune-empty
- filter-branch: fix --prune-empty on parentless commits
- t7003: ensure --prune-empty removes entire branch when applicable
- t7003: ensure --prune-empty can prune root commit
"git filter-branch --prune-empty" drops a single-parent commit that
becomes a no-op, but did not drop a root commit whose tree is empty.
Needs review.
* jc/config-case-cmdline-take-2 (2017-02-23) 2 commits
(merged to 'next' on 2017-03-01 at 2e9920eeeb)
+ config: use git_config_parse_key() in git_config_parse_parameter()
+ config: move a few helper functions up
The code to parse "git -c VAR=VAL cmd" and set configuration
variable for the duration of cmd had two small bugs, which have
been fixed.
Will merge to 'master'.
This supersedes jc/config-case-cmdline topic that has been discarded.
* ab/cond-skip-tests (2017-02-27) 2 commits
- gitweb tests: skip tests when we don't have Time::HiRes
- cvs tests: skip tests that call "cvs commit" when running as root
A few tests were run conditionally under (rare) conditions where
they cannot be run (like running cvs tests under 'root' account).
Will merge to 'next'.
* jk/auto-namelen-in-interpret-branch-name (2017-02-27) 1 commit
- interpret_branch_name(): handle auto-namelen for @{-1}
A small bug in the code that parses @{...} has been fixed.
Will merge to 'next'.
* jk/interop-test (2017-02-27) 2 commits
- t/interop: add test of old clients against modern git-daemon
- t: add an interoperability test harness
Picking two versions of Git and running tests to make sure the
older one and the newer one interoperate happily has now become
possible.
Needs review.
* jk/parse-config-key-cleanup (2017-02-24) 3 commits
(merged to 'next' on 2017-03-01 at e531d8d3a9)
+ parse_hide_refs_config: tell parse_config_key we don't want a subsection
+ parse_config_key: allow matching single-level config
+ parse_config_key: use skip_prefix instead of starts_with
(this branch uses sb/parse-hide-refs-config-cleanup.)
The "parse_config_key()" API function has been cleaned up.
Will merge to 'master'.
* jk/t6300-cleanup (2017-02-27) 1 commit
- t6300: avoid creating refs/heads/HEAD
A test that creats a confusing branch whose name is HEAD when any
branch name would have sufficed has been corrected.
Will merge to 'next'.
* rs/commit-parsing-optim (2017-02-27) 2 commits
- commit: don't check for space twice when looking for header
- commit: be more precise when searching for headers
The code that parses header fields in the commit object has been
updated for (micro)performance and code hygiene.
Will merge to 'next'.
* rs/sha1-file-plug-fallback-base-leak (2017-02-27) 1 commit
- sha1_file: release fallback base's memory in unpack_entry()
A leak in a codepath to read from a packed object in (rare) cases
has been plugged.
Will merge to 'next'.
* rs/strbuf-add-real-path (2017-02-27) 2 commits
- strbuf: add strbuf_add_real_path()
- cocci: use ALLOC_ARRAY
An helper function to make it easier to append the result from
real_path() to a strbuf has been added.
Will merge to 'next'.
* sb/parse-hide-refs-config-cleanup (2017-02-24) 1 commit
(merged to 'next' on 2017-03-01 at fd722ba039)
+ refs: parse_hide_refs_config to use parse_config_key
(this branch is used by jk/parse-config-key-cleanup.)
Code clean-up.
Will merge to 'master'.
* sg/clone-refspec-from-command-line-config (2017-02-27) 1 commit
- clone: respect configured fetch respecs during initial fetch
Needs review.
cf. <20170227211217.73gydlxb2qu2sp3m@sigill.intra.peff.net>
* sk/dash-is-previous (2017-02-27) 6 commits
- revert.c: delegate handling of "-" shorthand to setup_revisions
- merge.c: delegate handling of "-" shorthand to revision.c:get_sha1
- sha1_name.c: teach get_sha1_1 "-" shorthand for "@{-1}"
- revision.c: args starting with "-" might be a revision
- revision.c: swap if/else blocks
- revision.c: do not update argv with unknown option
A dash "-" can be written to mean "the branch that was previously
checked out" in more places.
Needs review.
cf. <1488007487-12965-1-git-send-email-kannan.siddharth12@gmail.com>
* jh/send-email-one-cc (2017-02-27) 1 commit
- send-email: only allow one address per body tag
"Cc:" on the trailer part does not have to conform to RFC strictly,
unlike in the e-mail header. "git send-email" has been updated to
ignore anything after '>' when picking addresses, to allow non-address
cruft like " # stable 4.4" after the address.
Will merge to 'next'.
* jk/http-auth (2017-02-27) 2 commits
- http: add an "auto" mode for http.emptyauth
- http: restrict auth methods to what the server advertises
Reduce authentication round-trip over HTTP when the server supports
just a single authentication method.
Will merge to 'next'.
* jk/ident-empty (2017-02-23) 4 commits
(merged to 'next' on 2017-03-01 at ff80031ce6)
+ ident: do not ignore empty config name/email
+ ident: reject all-crud ident name
+ ident: handle NULL email when complaining of empty name
+ ident: mark error messages for translation
user.email that consists of only cruft chars should have
consistently errored out, but didn't.
Will merge to 'master'.
* jt/upload-pack-error-report (2017-02-23) 1 commit
(merged to 'next' on 2017-03-01 at aea583dbe5)
+ upload-pack: report "not our ref" to client
"git upload-pack", which is a counter-part of "git fetch", did not
report a request for a ref that was not advertised as invalid.
This is generally not a problem (because "git fetch" will stop
before making such a request), but is the right thing to do.
Will merge to 'master'.
* ah/doc-ls-files-quotepath (2017-02-28) 3 commits
- SQUASH???
- Documentation: Link descriptions of -z to core.quotePath
- Documentation: Improve description for core.quotePath
Documentation for "git ls-files" did not refer to core.quotePath
* jh/memihash-opt (2017-02-17) 5 commits
- name-hash: remember previous dir_entry during lazy_init_name_hash
- name-hash: specify initial size for istate.dir_hash table
- name-hash: precompute hash values during preload-index
- hashmap: allow memihash computation to be continued
- name-hash: eliminate duplicate memihash call
Expecting an update for perf?
* nd/prune-in-worktree (2017-02-19) 15 commits
. rev-list: expose and document --single-worktree
. revision.c: --reflog add HEAD reflog from all worktrees
. files-backend: make reflog iterator go through per-worktree reflog
. refs: add refs_for_each_reflog[_ent]()
. revision.c: --all adds HEAD from all worktrees
. refs: remove dead for_each_*_submodule()
. revision.c: use refs_for_each*() instead of for_each_*_submodule()
. refs: add a refs_for_each_in() and friends
. refs: add refs_for_each_ref()
. refs: add refs_head_ref()
. refs: add refs_read_ref[_full]()
. refs: move submodule slash stripping code to get_submodule_ref_store
. revision.c: --indexed-objects add objects from all worktrees
. revision.c: refactor add_index_objects_to_pending()
. revision.h: new flag in struct rev_info wrt. worktree-related refs
(this branch uses nd/worktree-kill-parse-ref; is tangled with nd/files-backend-git-dir.)
"git gc" and friends when multiple worktrees are used off of a
single repository did not consider the index and per-worktree refs
of other worktrees as the root for reachability traversal, making
objects that are in use only in other worktrees to be subject to
garbage collection.
* mm/fetch-show-error-message-on-unadvertised-object (2017-02-22) 4 commits
- fetch-pack: add specific error for fetching an unadvertised object
- fetch_refs_via_pack: call report_unmatched_refs
- squash??? remove unfinished sentence
- fetch-pack: move code to report unmatched refs to a function
"git fetch" that requests a commit by object name, when the other
side does not allow such an request, failed without much
explanation.
Will squash the change in before merging to 'next'.
* nd/worktree-kill-parse-ref (2017-02-19) 22 commits
. refs: kill set_worktree_head_symref()
. refs: add refs_create_symref()
. worktree.c: kill parse_ref() in favor of refs_resolve_ref_unsafe()
. refs.c: add refs_resolve_ref_unsafe()
. refs: introduce get_worktree_ref_store()
. refs: rename get_ref_store() to get_submodule_ref_store() and make it public
. files-backend: remove submodule_allowed from files_downcast()
. refs: move submodule code out of files-backend.c
. path.c: move some code out of strbuf_git_path_submodule()
. refs.c: make get_main_ref_store() public and use it
. refs.c: kill register_ref_store(), add register_submodule_ref_store()
. refs.c: flatten get_ref_store() a bit
. refs: rename lookup_ref_store() to lookup_submodule_ref_store()
. refs.c: introduce get_main_ref_store()
. files-backend: remove the use of git_path()
. refs.c: share is_per_worktree_ref() to files-backend.c
. files-backend: replace *git_path*() with files_path()
. files-backend: add files_path()
. files-backend: convert git_path() to strbuf_git_path()
. refs-internal.c: make files_log_ref_write() static
. Merge branch 'mh/ref-remove-empty-directory' into nd/files-backend-git-dir
. Merge branch 'mh/submodule-hash' into nd/files-backend-git-dir
(this branch is used by nd/prune-in-worktree; is tangled with nd/files-backend-git-dir.)
(hopefully) a beginning of safer "git worktree" that is resistant
to "gc".
Waiting for nd/files-backend-git-dir to settle.
* nd/files-backend-git-dir (2017-02-22) 26 commits
. t1406: new tests for submodule ref store
. t1405: some basic tests on main ref store
. t/helper: add test-ref-store to test ref-store functions
. refs: delete pack_refs() in favor of refs_pack_refs()
. files-backend: avoid ref api targetting main ref store
. refs: new transaction related ref-store api
. refs: add new ref-store api
. refs: rename get_ref_store() to get_submodule_ref_store() and make it public
. files-backend: replace submodule_allowed check in files_downcast()
. refs: move submodule code out of files-backend.c
. path.c: move some code out of strbuf_git_path_submodule()
. refs.c: make get_main_ref_store() public and use it
. refs.c: kill register_ref_store(), add register_submodule_ref_store()
. refs.c: flatten get_ref_store() a bit
. refs: rename lookup_ref_store() to lookup_submodule_ref_store()
. refs.c: introduce get_main_ref_store()
. files-backend: remove the use of git_path()
. files-backend: add and use files_refname_path()
. files-backend: add and use files_reflog_path()
. files-backend: move "logs/" out of TMP_RENAMED_LOG
. files-backend: convert git_path() to strbuf_git_path()
. files-backend: add and use files_packed_refs_path()
. files-backend: make files_log_ref_write() static
. refs.h: add forward declaration for structs used in this file
. Merge branch 'mh/ref-remove-empty-directory' into nd/files-backend-git-dir
. Merge branch 'mh/submodule-hash' into nd/files-backend-git-dir
(this branch is tangled with nd/prune-in-worktree and nd/worktree-kill-parse-ref.)
The "submodule" specific field in the ref_store structure is
replaced with a more generic "gitdir" that can later be used also
when dealing with ref_store that represents the set of refs visible
from the other worktrees.
Needs review.
* sb/checkout-recurse-submodules (2017-02-23) 15 commits
- builtin/checkout: add --recurse-submodules switch
- entry.c: update submodules when interesting
- read-cache, remove_marked_cache_entries: wipe selected submodules.
- unpack-trees: check if we can perform the operation for submodules
- unpack-trees: pass old oid to verify_clean_submodule
- update submodules: add submodule_move_head
- update submodules: move up prepare_submodule_repo_env
- submodules: introduce check to see whether to touch a submodule
- update submodules: add a config option to determine if submodules are updated
- update submodules: add submodule config parsing
- connect_work_tree_and_git_dir: safely create leading directories
- make is_submodule_populated gently
- lib-submodule-update.sh: define tests for recursing into submodules
- lib-submodule-update.sh: do not use ./. as submodule remote
- lib-submodule-update.sh: reorder create_lib_submodule_repo
"git checkout" is taught --recurse-submodules option.
Needs review.
* tg/stash-push (2017-02-28) 6 commits
- stash: allow pathspecs in the no verb form
- stash: use stash_push for no verb form
- stash: teach 'push' (and 'create_stash') to honor pathspec
- stash: refactor stash_create
- stash: add test for the create command line arguments
- stash: introduce push verb
Allow "git stash" to take pathspec so that the local changes can be
stashed away only partially.
Will merge to 'next'.
* bc/object-id (2017-02-22) 19 commits
- wt-status: convert to struct object_id
- builtin/merge-base: convert to struct object_id
- Convert object iteration callbacks to struct object_id
- sha1_file: introduce an nth_packed_object_oid function
- refs: simplify parsing of reflog entries
- refs: convert each_reflog_ent_fn to struct object_id
- reflog-walk: convert struct reflog_info to struct object_id
- builtin/replace: convert to struct object_id
- Convert remaining callers of resolve_refdup to object_id
- builtin/merge: convert to struct object_id
- builtin/clone: convert to struct object_id
- builtin/branch: convert to struct object_id
- builtin/grep: convert to struct object_id
- builtin/fmt-merge-message: convert to struct object_id
- builtin/fast-export: convert to struct object_id
- builtin/describe: convert to struct object_id
- builtin/diff-tree: convert to struct object_id
- builtin/commit: convert to struct object_id
- hex: introduce parse_oid_hex
"uchar [40]" to "struct object_id" conversion continues.
Now at v5.
cf. <20170221234737.894681-1-sandals@crustytoothpaste.net>
* jh/mingw-openssl-sha1 (2017-02-09) 1 commit
- mingw: use OpenSSL's SHA-1 routines
Windows port wants to use OpenSSL's implementation of SHA-1
routines, so let them.
Kicked back to 'pu'
cf. <9913e513-553e-eba6-e81a-9c21030dd767@kdbg.org>
* sg/completion-refs-speedup (2017-02-13) 13 commits
- squash! completion: fill COMPREPLY directly when completing refs
- completion: fill COMPREPLY directly when completing refs
- completion: list only matching symbolic and pseudorefs when completing refs
- completion: let 'for-each-ref' sort remote branches for 'checkout' DWIMery
- completion: let 'for-each-ref' filter remote branches for 'checkout' DWIMery
- completion: let 'for-each-ref' strip the remote name from remote branches
- completion: let 'for-each-ref' and 'ls-remote' filter matching refs
- completion: don't disambiguate short refs
- completion: don't disambiguate tags and branches
- completion: support excluding full refs
- completion: support completing full refs after '--option=refs/<TAB>'
- completion: wrap __git_refs() for better option parsing
- completion: remove redundant __gitcomp_nl() options from _git_commit()
The refs completion for large number of refs has been sped up,
partly by giving up disambiguating ambiguous refs and partly by
eliminating most of the shell processing between 'git for-each-ref'
and 'ls-remote' and Bash's completion facility.
What's the donness of this topic?
* jk/no-looking-at-dotgit-outside-repo-final (2016-10-26) 1 commit
(merged to 'next' on 2017-02-27 at 7373a1b73d)
+ setup_git_env: avoid blind fall-back to ".git"
This is the endgame of the topic to avoid blindly falling back to
".git" when the setup sequence said we are _not_ in Git repository.
A corner case that happens to work right now may be broken by a
call to die("BUG").
Will cook in 'next'.
* jc/merge-drop-old-syntax (2015-04-29) 1 commit
(merged to 'next' on 2017-02-27 at 2c0f5f73d8)
+ merge: drop 'git merge <message> HEAD <commit>' syntax
Stop supporting "git merge <message> HEAD <commit>" syntax that has
been deprecated since October 2007, and issues a deprecation
warning message since v2.5.0.
Will cook in 'next'.
* jc/bundle (2016-03-03) 6 commits
- index-pack: --clone-bundle option
- Merge branch 'jc/index-pack' into jc/bundle
- bundle v3: the beginning
- bundle: keep a copy of bundle file name in the in-core bundle header
- bundle: plug resource leak
- bundle doc: 'verify' is not about verifying the bundle
The beginning of "split bundle", which could be one of the
ingredients to allow "git clone" traffic off of the core server
network to CDN.
--------------------------------------------------
[Discarded]
* sb/push-make-submodule-check-the-default (2017-01-26) 2 commits
. Revert "push: change submodule default to check when submodules exist"
. push: change submodule default to check when submodules exist
Turn the default of "push.recurseSubmodules" to "check" when
submodules seem to be in use.
Retracted.
* ls/submodule-config-ucase (2017-02-15) 2 commits
. submodule config does not apply to upper case submodules?
. t7400: cleanup "submodule add clone shallow submodule" test
Demonstrate a breakage in handling submodule.UPPERCASENAME.update
configuration variables.
Superseded by jc/config-case-cmdline.
* js/curl-empty-auth-set-by-default (2017-02-22) 1 commit
. http(s): automatically try NTLM authentication first
Flip "http.emptyAuth" on by default to help OOB experience for
users of HTTP Negotiate authentication scheme.
Superseded by jk/http-auth topic.
* jc/config-case-cmdline (2017-02-21) 3 commits
. config: squelch stupid compiler
. config: reject invalid VAR in 'git -c VAR=VAL command'
. config: preserve <subsection> case for one-shot config on the command line
The code to parse "git -c VAR=VAL cmd" and set configuration
variable for the duration of cmd had two small bugs, which have
been fixed.
Superseded by jc/config-case-cmdline-take-2
* lt/oneline-decoration-at-end (2017-02-21) 2 commits
. log: fix regression to "--source" when "--decorate" was updated
. show decorations at the end of the line
The output from "git log --oneline --decorate" has been updated to
show the extra information at the end of the line, not near the
front.
Retracted.
cf. <CA+55aFwT2HUBzZO8Gpt9tHoJtdRxv9oe3TDoSH5jcEOixRNBXg@mail.gmail.com>
* sk/parse-remote-cleanup (2017-02-21) 2 commits
. Revert "parse-remote: remove reference to unused op_prep"
. parse-remote: remove reference to unused op_prep
Code clean-up.
Will discard.
There may be third-party scripts that are dot-sourcing this one.
^ permalink raw reply
* Re: [PATCH v2 0/2] Minor changes to skip gitweb tests without Time::HiRes
From: Junio C Hamano @ 2017-03-01 22:42 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason; +Cc: git, Jakub Narębski
In-Reply-To: <20170301211540.4382-1-avarab@gmail.com>
Thanks, will replace what has been on 'pu'.
Note that I'd dropped a double-SP from the latter one while queuing.
^ permalink raw reply
* [PATCH v2 1/2] gitweb tests: Change confusing "skip_all" phrasing
From: Ævar Arnfjörð Bjarmason @ 2017-03-01 21:15 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Jakub Narębski,
Ævar Arnfjörð Bjarmason
In-Reply-To: <4b34e3a0-3da7-d821-2a7f-9a420ac1d3f6@gmail.com>
Change the phrasing so that instead of saying that the CGI module is
unusable, we say that it's not available.
This came up on the git mailing list in
<4b34e3a0-3da7-d821-2a7f-9a420ac1d3f6@gmail.com> from Jakub Narębski.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
---
t/gitweb-lib.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/t/gitweb-lib.sh b/t/gitweb-lib.sh
index d5dab5a94f..59ef15efbd 100644
--- a/t/gitweb-lib.sh
+++ b/t/gitweb-lib.sh
@@ -110,7 +110,7 @@ perl -MEncode -e '$e="";decode_utf8($e, Encode::FB_CROAK)' >/dev/null 2>&1 || {
}
perl -MCGI -MCGI::Util -MCGI::Carp -e 0 >/dev/null 2>&1 || {
- skip_all='skipping gitweb tests, CGI module unusable'
+ skip_all='skipping gitweb tests, CGI & CGI::Util & CGI::Carp modules not available'
test_done
}
--
2.11.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox