* Re: New to git, need help!
From: Pranit Bauva @ 2016-11-15 15:43 UTC (permalink / raw)
To: Mayank Gupta; +Cc: Git List
In-Reply-To: <CAJNRPQRhyrALj0zdaTxKgwo8j8r8_7ixgX21+C=ue+CGKYgaCg@mail.gmail.com>
Hey Mayank,
On Tue, Nov 15, 2016 at 6:00 PM, Mayank Gupta
<mayankgupta18198@gmail.com> wrote:
> Hi All,
>
> I'm new to open source and have recently joined this mailing list.
> Since I'm new at this, I think I can initially contribute to the
> community by fixing some small bugs or errors but as the documentation
> is too large, I don't know where to start.
> So if anybody could guide me on how to go about it, it would be really
> appreciated.
It is really nice that you want to start contributing. We have a user
documentation[1] and a developer documentation[2]. To contribute to a
feature, firstly you need to learn about that feature. So go through
the man pages of the tool which you would want to work on. The things
that you would be using are documented in the technical documentation.
Apart from this, you can start hunting small errors but I think it
would be difficult in the initial stages. So read this[3] even though
it is specific for GSoC, it is helpful for any new developer. Also you
can search the mailing list archives for "low hanging fruit" to get
things which were thought of but not done or something like that.
[1]: https://github.com/git/git/tree/master/Documentation
[2]: https://github.com/git/git/tree/master/Documentation/technical
[3]: https://git.github.io/SoC-2016-Microprojects/
Hope to see a patch from your side soon! :)
Regards,
Pranit Bauva
^ permalink raw reply
* Re: [PATCH v1 2/2] travis-ci: disable GIT_TEST_HTTPD for macOS
From: Jeff King @ 2016-11-15 15:31 UTC (permalink / raw)
To: Heiko Voigt
Cc: Lars Schneider, Junio C Hamano, Torsten Bögershausen, git,
Eric Sunshine
In-Reply-To: <20161115120718.GA7854@book.hvoigt.net>
On Tue, Nov 15, 2016 at 01:07:18PM +0100, Heiko Voigt wrote:
> On Fri, Nov 11, 2016 at 09:22:51AM +0100, Lars Schneider wrote:
> > To all macOS users on the list:
> > Does anyone execute the tests with GIT_TEST_HTTPD enabled successfully?
>
> Nope. The following tests fail for me on master: 5539, 5540, 5541, 5542,
> 5550, 5551, 5561, 5812.
Failing how? Does apache fail to start up? Do tests fails? What does
"-v" say? Is there anything interesting in httpd/error.log in the trash
directory?
-Peff
^ permalink raw reply
* Re: Git status takes too long- How to improve the performance of git
From: Heiko Voigt @ 2016-11-15 15:10 UTC (permalink / raw)
To: ravalika; +Cc: git
In-Reply-To: <1479202392275-7657456.post@n2.nabble.com>
On Tue, Nov 15, 2016 at 02:33:12AM -0700, ravalika wrote:
> Number of files - 63883
Since you also posted this to the "Git for Windows" mailinglist I assume
that you are using Windows. Reduce the number of files. For example
split the repository into two one for documentation and one for source.
Thats what I did with a converted repository that had to many files.
Windows is unfortunately very slow when it comes to handling many files
and if I recall correctly ~30000 files was in a nicely handleable range
for a Git repository on Windows, but that might have changed...
Cheers Heiko
^ permalink raw reply
* [PATCH v3 4/4] submodule_needs_pushing() NEEDSWORK when we can not answer this question
From: Heiko Voigt @ 2016-11-15 14:56 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Jeff King, Stefan Beller, Jens.Lehmann, Fredrik Gustafsson,
Leandro Lucarella
In-Reply-To: <cover.1479221071.git.hvoigt@hvoigt.net>
Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net>
---
submodule.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/submodule.c b/submodule.c
index e1196fd..29efee9 100644
--- a/submodule.c
+++ b/submodule.c
@@ -531,6 +531,14 @@ static int submodule_has_commits(const char *path, struct sha1_array *commits)
static int submodule_needs_pushing(const char *path, struct sha1_array *commits)
{
if (!submodule_has_commits(path, commits))
+ /* NEEDSWORK: The correct answer here is "We do not
+ * know" instead of "No push needed". We currently
+ * proceed pushing here as if the submodules commits are
+ * available on a remote. Since we can not check the
+ * remote availability for this submodule we should
+ * consider changing this behavior to: Stop here and
+ * tell the user how to skip this check if wanted.
+ */
return 0;
if (for_each_remote_ref_submodule(path, has_remote, NULL) > 0) {
--
2.10.1.386.gc503e45
^ permalink raw reply related
* [PATCH v3 1/4] serialize collection of changed submodules
From: Heiko Voigt @ 2016-11-15 14:56 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Jeff King, Stefan Beller, Jens.Lehmann, Fredrik Gustafsson,
Leandro Lucarella
In-Reply-To: <cover.1479221071.git.hvoigt@hvoigt.net>
To check whether a submodule needs to be pushed we need to collect all
changed submodules. Lets collect them first and then execute the
possibly expensive test whether certain revisions are already pushed
only once per submodule.
There is further potential for optimization since we can assemble one
command and only issued that instead of one call for each remote ref in
the submodule.
Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net>
---
submodule.c | 60 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++----
1 file changed, 56 insertions(+), 4 deletions(-)
diff --git a/submodule.c b/submodule.c
index 6f7d883..b91585e 100644
--- a/submodule.c
+++ b/submodule.c
@@ -532,19 +532,34 @@ static int submodule_needs_pushing(const char *path, const unsigned char sha1[20
return 0;
}
+static struct sha1_array *submodule_commits(struct string_list *submodules,
+ const char *path)
+{
+ struct string_list_item *item;
+
+ item = string_list_insert(submodules, path);
+ if (item->util)
+ return (struct sha1_array *) item->util;
+
+ /* NEEDSWORK: should we have sha1_array_init()? */
+ item->util = xcalloc(1, sizeof(struct sha1_array));
+ return (struct sha1_array *) item->util;
+}
+
static void collect_submodules_from_diff(struct diff_queue_struct *q,
struct diff_options *options,
void *data)
{
int i;
- struct string_list *needs_pushing = data;
+ struct string_list *submodules = data;
for (i = 0; i < q->nr; i++) {
struct diff_filepair *p = q->queue[i];
+ struct sha1_array *commits;
if (!S_ISGITLINK(p->two->mode))
continue;
- if (submodule_needs_pushing(p->two->path, p->two->oid.hash))
- string_list_insert(needs_pushing, p->two->path);
+ commits = submodule_commits(submodules, p->two->path);
+ sha1_array_append(commits, p->two->oid.hash);
}
}
@@ -560,6 +575,31 @@ static void find_unpushed_submodule_commits(struct commit *commit,
diff_tree_combined_merge(commit, 1, &rev);
}
+struct collect_submodule_from_sha1s_data {
+ char *submodule_path;
+ struct string_list *needs_pushing;
+};
+
+static int collect_submodules_from_sha1s(const unsigned char sha1[20],
+ void *data)
+{
+ struct collect_submodule_from_sha1s_data *me =
+ (struct collect_submodule_from_sha1s_data *) data;
+
+ if (submodule_needs_pushing(me->submodule_path, sha1))
+ string_list_insert(me->needs_pushing, me->submodule_path);
+
+ return 0;
+}
+
+static void free_submodules_sha1s(struct string_list *submodules)
+{
+ struct string_list_item *item;
+ for_each_string_list_item(item, submodules)
+ sha1_array_clear((struct sha1_array *) item->util);
+ string_list_clear(submodules, 1);
+}
+
int find_unpushed_submodules(unsigned char new_sha1[20],
const char *remotes_name, struct string_list *needs_pushing)
{
@@ -568,6 +608,8 @@ int find_unpushed_submodules(unsigned char new_sha1[20],
const char *argv[] = {NULL, NULL, "--not", "NULL", NULL};
int argc = ARRAY_SIZE(argv) - 1;
char *sha1_copy;
+ struct string_list submodules = STRING_LIST_INIT_DUP;
+ struct string_list_item *submodule;
struct strbuf remotes_arg = STRBUF_INIT;
@@ -581,12 +623,22 @@ int find_unpushed_submodules(unsigned char new_sha1[20],
die("revision walk setup failed");
while ((commit = get_revision(&rev)) != NULL)
- find_unpushed_submodule_commits(commit, needs_pushing);
+ find_unpushed_submodule_commits(commit, &submodules);
reset_revision_walk();
free(sha1_copy);
strbuf_release(&remotes_arg);
+ for_each_string_list_item(submodule, &submodules) {
+ struct collect_submodule_from_sha1s_data data;
+ data.submodule_path = submodule->string;
+ data.needs_pushing = needs_pushing;
+ sha1_array_for_each_unique((struct sha1_array *) submodule->util,
+ collect_submodules_from_sha1s,
+ &data);
+ }
+ free_submodules_sha1s(&submodules);
+
return needs_pushing->nr;
}
--
2.10.1.386.gc503e45
^ permalink raw reply related
* [PATCH v3 2/4] serialize collection of refs that contain submodule changes
From: Heiko Voigt @ 2016-11-15 14:56 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Jeff King, Stefan Beller, Jens.Lehmann, Fredrik Gustafsson,
Leandro Lucarella
In-Reply-To: <cover.1479221071.git.hvoigt@hvoigt.net>
We are iterating over each pushed ref and want to check whether it
contains changes to submodules. Instead of immediately checking each ref
lets first collect them and then do the check for all of them in one
revision walk.
Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net>
---
submodule.c | 35 ++++++++++++++++++++---------------
submodule.h | 5 +++--
transport.c | 29 +++++++++++++++++++++--------
3 files changed, 44 insertions(+), 25 deletions(-)
diff --git a/submodule.c b/submodule.c
index b91585e..769d666 100644
--- a/submodule.c
+++ b/submodule.c
@@ -500,6 +500,13 @@ static int has_remote(const char *refname, const struct object_id *oid,
return 1;
}
+static int append_sha1_to_argv(const unsigned char sha1[20], void *data)
+{
+ struct argv_array *argv = (struct argv_array *) data;
+ argv_array_push(argv, sha1_to_hex(sha1));
+ return 0;
+}
+
static int submodule_needs_pushing(const char *path, const unsigned char sha1[20])
{
if (add_submodule_odb(path) || !lookup_commit_reference(sha1))
@@ -600,25 +607,24 @@ static void free_submodules_sha1s(struct string_list *submodules)
string_list_clear(submodules, 1);
}
-int find_unpushed_submodules(unsigned char new_sha1[20],
+int find_unpushed_submodules(struct sha1_array *commits,
const char *remotes_name, struct string_list *needs_pushing)
{
struct rev_info rev;
struct commit *commit;
- const char *argv[] = {NULL, NULL, "--not", "NULL", NULL};
- int argc = ARRAY_SIZE(argv) - 1;
- char *sha1_copy;
struct string_list submodules = STRING_LIST_INIT_DUP;
struct string_list_item *submodule;
+ struct argv_array argv = ARGV_ARRAY_INIT;
- struct strbuf remotes_arg = STRBUF_INIT;
-
- strbuf_addf(&remotes_arg, "--remotes=%s", remotes_name);
init_revisions(&rev, NULL);
- sha1_copy = xstrdup(sha1_to_hex(new_sha1));
- argv[1] = sha1_copy;
- argv[3] = remotes_arg.buf;
- setup_revisions(argc, argv, &rev, NULL);
+
+ /* argv.argv[0] will be ignored by setup_revisions */
+ argv_array_push(&argv, "find_unpushed_submodules");
+ sha1_array_for_each_unique(commits, append_sha1_to_argv, &argv);
+ argv_array_push(&argv, "--not");
+ argv_array_pushf(&argv, "--remotes=%s", remotes_name);
+
+ setup_revisions(argv.argc, argv.argv, &rev, NULL);
if (prepare_revision_walk(&rev))
die("revision walk setup failed");
@@ -626,8 +632,7 @@ int find_unpushed_submodules(unsigned char new_sha1[20],
find_unpushed_submodule_commits(commit, &submodules);
reset_revision_walk();
- free(sha1_copy);
- strbuf_release(&remotes_arg);
+ argv_array_clear(&argv);
for_each_string_list_item(submodule, &submodules) {
struct collect_submodule_from_sha1s_data data;
@@ -664,12 +669,12 @@ static int push_submodule(const char *path)
return 1;
}
-int push_unpushed_submodules(unsigned char new_sha1[20], const char *remotes_name)
+int push_unpushed_submodules(struct sha1_array *commits, const char *remotes_name)
{
int i, ret = 1;
struct string_list needs_pushing = STRING_LIST_INIT_DUP;
- if (!find_unpushed_submodules(new_sha1, remotes_name, &needs_pushing))
+ if (!find_unpushed_submodules(commits, remotes_name, &needs_pushing))
return 1;
for (i = 0; i < needs_pushing.nr; i++) {
diff --git a/submodule.h b/submodule.h
index d9e197a..9454806 100644
--- a/submodule.h
+++ b/submodule.h
@@ -3,6 +3,7 @@
struct diff_options;
struct argv_array;
+struct sha1_array;
enum {
RECURSE_SUBMODULES_CHECK = -4,
@@ -62,9 +63,9 @@ int submodule_uses_gitfile(const char *path);
int ok_to_remove_submodule(const char *path);
int merge_submodule(unsigned char result[20], const char *path, const unsigned char base[20],
const unsigned char a[20], const unsigned char b[20], int search);
-int find_unpushed_submodules(unsigned char new_sha1[20], const char *remotes_name,
+int find_unpushed_submodules(struct sha1_array *commits, const char *remotes_name,
struct string_list *needs_pushing);
-int push_unpushed_submodules(unsigned char new_sha1[20], const char *remotes_name);
+int push_unpushed_submodules(struct sha1_array *commits, const char *remotes_name);
void connect_work_tree_and_git_dir(const char *work_tree, const char *git_dir);
int parallel_submodules(void);
diff --git a/transport.c b/transport.c
index d57e8de..f482869 100644
--- a/transport.c
+++ b/transport.c
@@ -949,23 +949,36 @@ int transport_push(struct transport *transport,
if ((flags & TRANSPORT_RECURSE_SUBMODULES_ON_DEMAND) && !is_bare_repository()) {
struct ref *ref = remote_refs;
+ struct sha1_array commits = SHA1_ARRAY_INIT;
+
for (; ref; ref = ref->next)
- if (!is_null_oid(&ref->new_oid) &&
- !push_unpushed_submodules(ref->new_oid.hash,
- transport->remote->name))
- die ("Failed to push all needed submodules!");
+ if (!is_null_oid(&ref->new_oid))
+ sha1_array_append(&commits, ref->new_oid.hash);
+
+ if (!push_unpushed_submodules(&commits, transport->remote->name)) {
+ sha1_array_clear(&commits);
+ die("Failed to push all needed submodules!");
+ }
+ sha1_array_clear(&commits);
}
if ((flags & (TRANSPORT_RECURSE_SUBMODULES_ON_DEMAND |
TRANSPORT_RECURSE_SUBMODULES_CHECK)) && !is_bare_repository()) {
struct ref *ref = remote_refs;
struct string_list needs_pushing = STRING_LIST_INIT_DUP;
+ struct sha1_array commits = SHA1_ARRAY_INIT;
for (; ref; ref = ref->next)
- if (!is_null_oid(&ref->new_oid) &&
- find_unpushed_submodules(ref->new_oid.hash,
- transport->remote->name, &needs_pushing))
- die_with_unpushed_submodules(&needs_pushing);
+ if (!is_null_oid(&ref->new_oid))
+ sha1_array_append(&commits, ref->new_oid.hash);
+
+ if (find_unpushed_submodules(&commits, transport->remote->name,
+ &needs_pushing)) {
+ sha1_array_clear(&commits);
+ die_with_unpushed_submodules(&needs_pushing);
+ }
+ string_list_clear(&needs_pushing, 0);
+ sha1_array_clear(&commits);
}
push_ret = transport->push_refs(transport, remote_refs, flags);
--
2.10.1.386.gc503e45
^ permalink raw reply related
* [PATCH v3 3/4] batch check whether submodule needs pushing into one call
From: Heiko Voigt @ 2016-11-15 14:56 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Jeff King, Stefan Beller, Jens.Lehmann, Fredrik Gustafsson,
Leandro Lucarella
In-Reply-To: <cover.1479221071.git.hvoigt@hvoigt.net>
We run a command for each sha1 change in a submodule. This is
unnecessary since we can simply batch all sha1's we want to check into
one command. Lets do it so we can speedup the check when many submodule
changes are in need of checking.
Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net>
---
submodule.c | 63 ++++++++++++++++++++++++++++++++-----------------------------
1 file changed, 33 insertions(+), 30 deletions(-)
diff --git a/submodule.c b/submodule.c
index 769d666..e1196fd 100644
--- a/submodule.c
+++ b/submodule.c
@@ -507,27 +507,49 @@ static int append_sha1_to_argv(const unsigned char sha1[20], void *data)
return 0;
}
-static int submodule_needs_pushing(const char *path, const unsigned char sha1[20])
+static int check_has_commit(const unsigned char sha1[20], void *data)
{
- if (add_submodule_odb(path) || !lookup_commit_reference(sha1))
+ int *has_commit = (int *) data;
+
+ if (!lookup_commit_reference(sha1))
+ *has_commit = 0;
+
+ return 0;
+}
+
+static int submodule_has_commits(const char *path, struct sha1_array *commits)
+{
+ int has_commit = 1;
+
+ if (add_submodule_odb(path))
+ return 0;
+
+ sha1_array_for_each_unique(commits, check_has_commit, &has_commit);
+ return has_commit;
+}
+
+static int submodule_needs_pushing(const char *path, struct sha1_array *commits)
+{
+ if (!submodule_has_commits(path, commits))
return 0;
if (for_each_remote_ref_submodule(path, has_remote, NULL) > 0) {
struct child_process cp = CHILD_PROCESS_INIT;
- const char *argv[] = {"rev-list", NULL, "--not", "--remotes", "-n", "1" , NULL};
struct strbuf buf = STRBUF_INIT;
int needs_pushing = 0;
- argv[1] = sha1_to_hex(sha1);
- cp.argv = argv;
+ argv_array_push(&cp.args, "rev-list");
+ sha1_array_for_each_unique(commits, append_sha1_to_argv, &cp.args);
+ argv_array_pushl(&cp.args, "--not", "--remotes", "-n", "1" , NULL);
+
prepare_submodule_repo_env(&cp.env_array);
cp.git_cmd = 1;
cp.no_stdin = 1;
cp.out = -1;
cp.dir = path;
if (start_command(&cp))
- die("Could not run 'git rev-list %s --not --remotes -n 1' command in submodule %s",
- sha1_to_hex(sha1), path);
+ die("Could not run 'git rev-list <commits> --not --remotes -n 1' command in submodule %s",
+ path);
if (strbuf_read(&buf, cp.out, 41))
needs_pushing = 1;
finish_command(&cp);
@@ -582,23 +604,6 @@ static void find_unpushed_submodule_commits(struct commit *commit,
diff_tree_combined_merge(commit, 1, &rev);
}
-struct collect_submodule_from_sha1s_data {
- char *submodule_path;
- struct string_list *needs_pushing;
-};
-
-static int collect_submodules_from_sha1s(const unsigned char sha1[20],
- void *data)
-{
- struct collect_submodule_from_sha1s_data *me =
- (struct collect_submodule_from_sha1s_data *) data;
-
- if (submodule_needs_pushing(me->submodule_path, sha1))
- string_list_insert(me->needs_pushing, me->submodule_path);
-
- return 0;
-}
-
static void free_submodules_sha1s(struct string_list *submodules)
{
struct string_list_item *item;
@@ -635,12 +640,10 @@ int find_unpushed_submodules(struct sha1_array *commits,
argv_array_clear(&argv);
for_each_string_list_item(submodule, &submodules) {
- struct collect_submodule_from_sha1s_data data;
- data.submodule_path = submodule->string;
- data.needs_pushing = needs_pushing;
- sha1_array_for_each_unique((struct sha1_array *) submodule->util,
- collect_submodules_from_sha1s,
- &data);
+ struct sha1_array *commits = (struct sha1_array *) submodule->util;
+
+ if (submodule_needs_pushing(submodule->string, commits))
+ string_list_insert(needs_pushing, submodule->string);
}
free_submodules_sha1s(&submodules);
--
2.10.1.386.gc503e45
^ permalink raw reply related
* [PATCH v3 0/4] Speedup finding of unpushed submodules
From: Heiko Voigt @ 2016-11-15 14:56 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Jeff King, Stefan Beller, Jens.Lehmann, Fredrik Gustafsson,
Leandro Lucarella
You can find the second iteration of this series here:
http://public-inbox.org/git/cover.1475851621.git.hvoigt@hvoigt.net/
All mentioned issues should be fixed. I put the NEEDSWORK comment in a
seperate patch since it seemed to me as if we did not fully agree on
that. So in case we decide against it we can just drop that patch.
Cheers Heiko
Heiko Voigt (4):
serialize collection of changed submodules
serialize collection of refs that contain submodule changes
batch check whether submodule needs pushing into one call
submodule_needs_pushing() NEEDSWORK when we can not answer this
question
submodule.c | 120 +++++++++++++++++++++++++++++++++++++++++++++++-------------
submodule.h | 5 ++-
transport.c | 29 +++++++++++----
3 files changed, 118 insertions(+), 36 deletions(-)
--
2.10.1.386.gc503e45
^ permalink raw reply
* Re: RFC: Enable delayed responses to Git clean/smudge filter requests
From: Lars Schneider @ 2016-11-15 14:29 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <20161115010356.GA29602@starla>
> On 15 Nov 2016, at 02:03, Eric Wong <e@80x24.org> wrote:
>
> Lars Schneider <larsxschneider@gmail.com> wrote:
>> Hi,
>>
>> Git always performs a clean/smudge filter on files in sequential order.
>> Sometimes a filter operation can take a noticeable amount of time.
>> This blocks the entire Git process.
>
> I have the same problem in many places which aren't git :>
>
>> I would like to give a filter process the possibility to answer Git with
>> "I got your request, I am processing it, ask me for the result later!".
>>
>> I see the following way to realize this:
>>
>> In unpack-trees.c:check_updates() [1] we loop through the cache
>> entries and "ask me later" could be an acceptable return value of the
>> checkout_entry() call. The loop could run until all entries returned
>> success or error.
>>
>> The filter machinery is triggered in various other places in Git and
>> all places that want to support "ask me later" would need to be patched
>> accordingly.
>
> That all sounds reasonable.
>
> The filter itself would need to be aware of parallelism
> if it lives for multiple objects, right?
Correct. This way Git doesn't need to deal with threading...
>> Do you think this could be a viable approach?
>
> It'd probably require a bit of work, but yes, I think it's viable.
>
> We already do this with curl_multi requests for parallel
> fetching from dumb HTTP servers, but that's driven by curl
> internals operating with a select/poll loop.
>
> Perhaps the curl API could be a good example for doing this.
Thanks for the pointer!
>> Do you see a better way?
>
> Nope, I prefer non-blocking state machines to threads for
> debuggability and determinism.
Agreed!
> Anyways, I'll plan on doing something similar (in Perl) with the
> synchronous parts of public-inbox which relies on "cat-file --batch"
> at some point... (my rotational disks are sloooooooow :<)
That sounds interesting! What changes to you have in mind for
"cat-file --batch"? We are thinking about performance improvements
in that area, too. I would be happy to help reviewing your patches!
Thanks a lot for your RFC feedback,
Lars
^ permalink raw reply
* Re: [PATCH v1 2/2] travis-ci: disable GIT_TEST_HTTPD for macOS
From: Lars Schneider @ 2016-11-15 14:18 UTC (permalink / raw)
To: Heiko Voigt
Cc: Jeff King, Junio C Hamano, Torsten Bögershausen, git,
Eric Sunshine
In-Reply-To: <20161115120718.GA7854@book.hvoigt.net>
> On 15 Nov 2016, at 13:07, Heiko Voigt <hvoigt@hvoigt.net> wrote:
>
> On Fri, Nov 11, 2016 at 09:22:51AM +0100, Lars Schneider wrote:
>> To all macOS users on the list:
>> Does anyone execute the tests with GIT_TEST_HTTPD enabled successfully?
>
> Nope. The following tests fail for me on master: 5539, 5540, 5541, 5542,
> 5550, 5551, 5561, 5812.
That's what I see, too. Apache needs to be configured in some special way
to make them work and I was wondering if anyone has figured that out
already for macOS...
However, I much prefer Peff's idea to test against real world servers:
http://public-inbox.org/git/20161111092824.qqgrmhtkuw3wpbwa@sigill.intra.peff.net/
- Lars
^ permalink raw reply
* Protecting old temporary objects being reused from concurrent "git gc"?
From: Matt McCutchen @ 2016-11-15 14:13 UTC (permalink / raw)
To: git
The Braid subproject management tool stores the subproject content in
the main tree and is able to switch to a different upstream revision of
a subproject by doing the equivalent of "git read-tree -m" on the
superproject tree and the two upstream trees. The tricky part is
preparing temporary trees with the upstream content moved to the path
configured for the superproject. The usual method is "git read-tree
--prefix", but using what index file? Braid currently uses the user's
actual worktree, which can leave a mess if it gets interrupted:
https://github.com/cristibalan/braid/blob/7d81da6e86e24de62a74f3ab8d880666cb343b04/lib/braid/commands/update.rb#L98
I want to change this to something that won't leave an inconsistent
state if interrupted. I've written code for this kind of thing before
that sets GIT_INDEX_FILE and uses a temporary index file and "git
write-tree". But I realized that if "git gc" runs concurrently, the
generated tree could be deleted before it is used and the tool would
fail. If I had a need to run "git commit-tree", it seems like I might
even end up with a commit object with a broken reference to a tree.
"git gc" normally doesn't delete objects that were created in the last
2 weeks, but if an identical tree was added to the object database more
than 2 weeks ago by another operation and is unreferenced, it could be
reused without updating its mtime and it could still get deleted.
Is there a recommended way to avoid this kind of problem in add-on
tools? (I searched the Git documentation and the web for information
about races with "git gc" and didn't find anything useful.) If not, it
seems to be a significant design flaw in "git gc", even if the problem
is extremely rare in practice. I wonder if some of the built-in
commands may have the same problem, though I haven't tried to test
them. If this is confirmed to be a known problem affecting built-in
commands, then at least I won't feel bad about introducing the
same problem into add-on tools. :/
Thanks,
Matt
^ permalink raw reply
* Re: git shortlog vs. stdin
From: Christian Neukirchen @ 2016-11-15 13:39 UTC (permalink / raw)
To: git
In-Reply-To: <20161115130418.GA28847@inner.h.apk.li>
Andreas Krey <a.krey@gmx.de> writes:
> Bug or feature?
Documented feature, but you're holding it wrong ;)
If no revisions are passed on the command line and either standard
input is not a terminal or there is no current branch, git shortlog
will output a summary of the log read from standard input, without
reference to the current repository.
(Note that you can use shortlog ala "git log --pretty=short | git shortlog")
--
Christian Neukirchen <chneukirchen@gmail.com> http://chneukirchen.org
^ permalink raw reply
* git shortlog vs. stdin
From: Andreas Krey @ 2016-11-15 13:04 UTC (permalink / raw)
To: git
Hi all,
I observed a strange an unexpected behaviour in 'git shortlog'.
When in git.git:
$ git shortlog -sn | wc
1441 4493 31477
but with input redirected:
$ git shortlog -sn </dev/null | wc
0 0 0
--no-pager expectedly doesn't help.
Observed with 2.6.2 and 2.10.0-rc1.
I originally stumbled over this while trying something like
$ ls z* | while read name rest; do
echo "$name" ====; git --no-pager shortlog | tail -4; done
where it also essentially terminates the while loop,
presumably by eating the stdin to the loop.
Bug or feature?
- Andreas
--
"Totally trivial. Famous last words."
From: Linus Torvalds <torvalds@*.org>
Date: Fri, 22 Jan 2010 07:29:21 -0800
^ permalink raw reply
* New to git, need help!
From: Mayank Gupta @ 2016-11-15 12:30 UTC (permalink / raw)
To: git
Hi All,
I'm new to open source and have recently joined this mailing list.
Since I'm new at this, I think I can initially contribute to the
community by fixing some small bugs or errors but as the documentation
is too large, I don't know where to start.
So if anybody could guide me on how to go about it, it would be really
appreciated.
Thanks,
Mayank
^ permalink raw reply
* Re: [PATCH v1 2/2] travis-ci: disable GIT_TEST_HTTPD for macOS
From: Heiko Voigt @ 2016-11-15 12:07 UTC (permalink / raw)
To: Lars Schneider
Cc: Jeff King, Junio C Hamano, Torsten Bögershausen, git,
Eric Sunshine
In-Reply-To: <2088B631-4FE8-4232-9F3C-699122E6A7B0@gmail.com>
On Fri, Nov 11, 2016 at 09:22:51AM +0100, Lars Schneider wrote:
> To all macOS users on the list:
> Does anyone execute the tests with GIT_TEST_HTTPD enabled successfully?
Nope. The following tests fail for me on master: 5539, 5540, 5541, 5542,
5550, 5551, 5561, 5812.
Cheers Heiko
^ permalink raw reply
* Re: Git status takes too long- How to improve the performance of git
From: Christian Couder @ 2016-11-15 11:44 UTC (permalink / raw)
To: ravalika; +Cc: git, Fredrik Gustafsson
In-Reply-To: <20161115102400.GC28860@paksenarrion.iveqy.com>
On Tue, Nov 15, 2016 at 11:24 AM, Fredrik Gustafsson <iveqy@iveqy.com> wrote:
> On Tue, Nov 15, 2016 at 02:33:12AM -0700, ravalika wrote:
[...]
>> And I have experimented the following ways
>> - - Setting core.ignorestat to true
>> - - Git gc &git clean
>> - - Shallow clone – Reducing number of commits
>> - - Clone only one branch
>> - Git repacking - git repack -ad && git prune
>> - - Cold/warm cache
>>
>> Could you please let me know, what are the ways to improve the git
>> performance ?
>> I have gone through the mailing lists.
>
> You could always check the --assume-unchanged bit, see the manual page
> for git update-index. However this is quite extreme and demanding for
> the user.
If you install a recent version version, you may be able to use the
untracked cache feature.
(See "core.untrackedCache" in the git config documentation and
--untracked-cache in the git update-index documentation.)
^ permalink raw reply
* Re: Git status takes too long- How to improve the performance of git
From: Fredrik Gustafsson @ 2016-11-15 10:24 UTC (permalink / raw)
To: ravalika; +Cc: git
In-Reply-To: <1479202392275-7657456.post@n2.nabble.com>
Hi,
On Tue, Nov 15, 2016 at 02:33:12AM -0700, ravalika wrote:
> We are using git-1.8.2 version for version control.
That's a three (almost four) year old version of git. Your first test
should be to see if an upgrade to a recent version will improve things.
> It is an centralized server and git status takes too long
A centralized server? How? git is designed to be runned locally. If
you're running git on a network file system, the performance will
suffer. Could you elaborate on how your environment is setup?
>
> How to improve the performance of git status
>
> Git repo details:
>
> Size of the .git folder is 8.9MB
> Number of commits approx 53838 (git rev-list HEAD --count)
> Number of branches - 330
> Number of files - 63883
> Working tree clone size is 4.3GB
.git folder of 8.9 MEGABYTE and working tree of 4.3 GIGABYTE? Is this a
typo?
>
> time git status shows
> real 0m23.673s
> user 0m9.432s
> sys 0m3.793s
>
> then after 5 mins
> real 0m4.864s
> user 0m1.417s
> sys 0m4.710s
A slow disc and empty caches are slow. Two ways of improving this is to
have faster discs or make sure your cache is up to date. When I'd a
really slow disc, I'd my shell to run a git status in the background to
load the cache everytime I started working on a project. This is however
an ugly hack that wasn't approved to be a part of git.
>
> And I have experimented the following ways
> - - Setting core.ignorestat to true
> - - Git gc &git clean
> - - Shallow clone – Reducing number of commits
> - - Clone only one branch
> - Git repacking - git repack -ad && git prune
> - - Cold/warm cache
>
> Could you please let me know, what are the ways to improve the git
> performance ?
> I have gone through the mailing lists.
You could always check the --assume-unchanged bit, see the manual page
for git update-index. However this is quite extreme and demanding for
the user.
--
Fredrik Gustafsson
phone: +46 733-608274
e-mail: iveqy@iveqy.com
website: http://www.iveqy.com
^ permalink raw reply
* Git status takes too long- How to improve the performance of git
From: ravalika @ 2016-11-15 9:33 UTC (permalink / raw)
To: git
Hi All,
We are using git-1.8.2 version for version control.
It is an centralized server and git status takes too long
How to improve the performance of git status
Git repo details:
Size of the .git folder is 8.9MB
Number of commits approx 53838 (git rev-list HEAD --count)
Number of branches - 330
Number of files - 63883
Working tree clone size is 4.3GB
time git status shows
real 0m23.673s
user 0m9.432s
sys 0m3.793s
then after 5 mins
real 0m4.864s
user 0m1.417s
sys 0m4.710s
And I have experimented the following ways
- - Setting core.ignorestat to true
- - Git gc &git clean
- - Shallow clone – Reducing number of commits
- - Clone only one branch
- Git repacking - git repack -ad && git prune
- - Cold/warm cache
Could you please let me know, what are the ways to improve the git
performance ?
I have gone through the mailing lists.
Thank you,
Renuka
--
View this message in context: http://git.661346.n2.nabble.com/Git-status-takes-too-long-How-to-improve-the-performance-of-git-tp7657456.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH v7 13/17] ref-filter: add `:dir` and `:base` options for ref printing atoms
From: Jacob Keller @ 2016-11-15 7:56 UTC (permalink / raw)
To: Karthik Nayak; +Cc: Junio C Hamano, Git mailing list
In-Reply-To: <CA+P7+xo6OqcpLZ7v_m1EPm85eK2xCPD_LCw1Ly2RSPeSC0Ei7g@mail.gmail.com>
On Mon, Nov 14, 2016 at 11:55 PM, Jacob Keller <jacob.keller@gmail.com> wrote:
> On Mon, Nov 14, 2016 at 10:48 PM, Karthik Nayak <karthik.188@gmail.com> wrote:
>> On Tue, Nov 15, 2016 at 1:21 AM, Junio C Hamano <gitster@pobox.com> wrote:
>>> Karthik Nayak <karthik.188@gmail.com> writes:
>>>
>>>>> - More importantly, what do these do? I do not think of a good
>>>>> description that generalizes "base of refs/foo/bar/boz is foo" to
>>>>> explain your :base.
>>>>
>>>> $ ./git for-each-ref --format "%(refname)%(end) %(refname:dir)"
>>>> refs/heads/master refs/heads
>>>> refs/heads/ref-filter refs/heads
>>>> refs/remotes/junio/va/i18n refs/remotes/junio/va
>>>>
>>>> $ ./git for-each-ref refs/heads --format
>>>> "%(align:left,30)%(refname)%(end) %(refname:base)"
>>>> refs/heads/master heads
>>>> refs/heads/ref-filter heads
>>>> refs/remotes/junio/va/i18n remotes
>>>>
>>>> I guess this should clear it up.
>>>
>>> Hmph.
>>>
>>> I would guess from these examples that :dir is an equivalent to
>>> dirname(). But it is unclear how :base is defined. Is it the path
>>> component that comes immediately after "refs/" that appears at the
>>> beginning?
>>
>> ':dir' is equivalent to dirname(). Yup, base is the folder right after 'refs/'.
>> For local branches it is 'heads' for remotes it is 'remotes'. This is useful
>> when we want to make decisions based on the type of branch we're dealing
>> with (using along with %(if)...%(end)).
>>
>> --
>> Regards,
>> Karthik Nayak
>
>
> dirname makes sense. What about implementing a reverse variant of
> strip, which you could perform stripping of right-most components and
> instead of stripping by a number, strip "to" a number, ie: keep the
> left N most components, and then you could use something like
>
> "keep=2" to keep "refs/heads"
>
> ?
>
> I think that would be more general purpose than basename, and less confusing?
>
> Thanks,
> Jake
You could even make it compatible with strip so that:
"keep=2,strip=1" would return the equivalent of base?
Thanks,
Jake
^ permalink raw reply
* Re: [PATCH v7 13/17] ref-filter: add `:dir` and `:base` options for ref printing atoms
From: Jacob Keller @ 2016-11-15 7:55 UTC (permalink / raw)
To: Karthik Nayak; +Cc: Junio C Hamano, Git mailing list
In-Reply-To: <CAOLa=ZQepW9GiUrKEWXojpy10B86K-jb84G_dJeL=mqtjZ4AWg@mail.gmail.com>
On Mon, Nov 14, 2016 at 10:48 PM, Karthik Nayak <karthik.188@gmail.com> wrote:
> On Tue, Nov 15, 2016 at 1:21 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> Karthik Nayak <karthik.188@gmail.com> writes:
>>
>>>> - More importantly, what do these do? I do not think of a good
>>>> description that generalizes "base of refs/foo/bar/boz is foo" to
>>>> explain your :base.
>>>
>>> $ ./git for-each-ref --format "%(refname)%(end) %(refname:dir)"
>>> refs/heads/master refs/heads
>>> refs/heads/ref-filter refs/heads
>>> refs/remotes/junio/va/i18n refs/remotes/junio/va
>>>
>>> $ ./git for-each-ref refs/heads --format
>>> "%(align:left,30)%(refname)%(end) %(refname:base)"
>>> refs/heads/master heads
>>> refs/heads/ref-filter heads
>>> refs/remotes/junio/va/i18n remotes
>>>
>>> I guess this should clear it up.
>>
>> Hmph.
>>
>> I would guess from these examples that :dir is an equivalent to
>> dirname(). But it is unclear how :base is defined. Is it the path
>> component that comes immediately after "refs/" that appears at the
>> beginning?
>
> ':dir' is equivalent to dirname(). Yup, base is the folder right after 'refs/'.
> For local branches it is 'heads' for remotes it is 'remotes'. This is useful
> when we want to make decisions based on the type of branch we're dealing
> with (using along with %(if)...%(end)).
>
> --
> Regards,
> Karthik Nayak
dirname makes sense. What about implementing a reverse variant of
strip, which you could perform stripping of right-most components and
instead of stripping by a number, strip "to" a number, ie: keep the
left N most components, and then you could use something like
"keep=2" to keep "refs/heads"
?
I think that would be more general purpose than basename, and less confusing?
Thanks,
Jake
^ permalink raw reply
* Re: [PATCH 1/2] push: --dry-run updates submodules when --recurse-submodules=on-demand
From: Johannes Sixt @ 2016-11-15 7:03 UTC (permalink / raw)
To: Brandon Williams, git
In-Reply-To: <1479172735-698-2-git-send-email-bmwill@google.com>
Am 15.11.2016 um 02:18 schrieb Brandon Williams:
> diff --git a/t/t5531-deep-submodule-push.sh b/t/t5531-deep-submodule-push.sh
> index 198ce84..e6ccc30 100755
> --- a/t/t5531-deep-submodule-push.sh
> +++ b/t/t5531-deep-submodule-push.sh
> @@ -427,7 +427,31 @@ test_expect_success 'push unpushable submodule recursively fails' '
> cd submodule.git &&
> git rev-parse master >../actual
> ) &&
> - test_cmp expected actual
> + test_cmp expected actual &&
> + git -C work reset --hard master^
This line looks like a clean-up to be done after the test case. You
should wrap it in test_when_finished, but outside of a sub-shell, which
looks like it's just one line earlier, before the test_cmp.
> +'
> +
> +test_expect_failure 'push --dry-run does not recursively update submodules' '
> + (
> + cd work &&
> + (
> + cd gar/bage &&
> + git checkout master &&
> + git rev-parse master >../../../expected_submodule &&
> + > junk9 &&
> + git add junk9 &&
> + git commit -m "Ninth junk"
> + ) &&
Could you please avoid this nested sub-shell? It is fine to cd around
when you are in a sub-shell.
> + git checkout master &&
> + git rev-parse master >../expected_pub
Broken && chain.
> + git add gar/bage &&
> + git commit -m "Ninth commit for gar/bage" &&
> + git push --dry-run --recurse-submodules=on-demand ../pub.git master
> + ) &&
> + git -C submodule.git rev-parse master >actual_submodule &&
> + git -C pub.git rev-parse master >actual_pub &&
All of the commands above are 'git something' that could become 'git -C
work something' and then the sub-shell would be unnecessary. I'm not
sure I would appreciate the verbosity of the result, though. (Perhaps
aligning the git subcommands after -C foo would help.)
> + test_cmp expected_pub actual_pub &&
> + test_cmp expected_submodule actual_submodule
> '
>
> test_done
>
^ permalink raw reply
* Re: [PATCH v7 13/17] ref-filter: add `:dir` and `:base` options for ref printing atoms
From: Karthik Nayak @ 2016-11-15 6:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jacob Keller, Git mailing list
In-Reply-To: <xmqqy40lx2k8.fsf@gitster.mtv.corp.google.com>
On Tue, Nov 15, 2016 at 1:21 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Karthik Nayak <karthik.188@gmail.com> writes:
>
>>> - More importantly, what do these do? I do not think of a good
>>> description that generalizes "base of refs/foo/bar/boz is foo" to
>>> explain your :base.
>>
>> $ ./git for-each-ref --format "%(refname)%(end) %(refname:dir)"
>> refs/heads/master refs/heads
>> refs/heads/ref-filter refs/heads
>> refs/remotes/junio/va/i18n refs/remotes/junio/va
>>
>> $ ./git for-each-ref refs/heads --format
>> "%(align:left,30)%(refname)%(end) %(refname:base)"
>> refs/heads/master heads
>> refs/heads/ref-filter heads
>> refs/remotes/junio/va/i18n remotes
>>
>> I guess this should clear it up.
>
> Hmph.
>
> I would guess from these examples that :dir is an equivalent to
> dirname(). But it is unclear how :base is defined. Is it the path
> component that comes immediately after "refs/" that appears at the
> beginning?
':dir' is equivalent to dirname(). Yup, base is the folder right after 'refs/'.
For local branches it is 'heads' for remotes it is 'remotes'. This is useful
when we want to make decisions based on the type of branch we're dealing
with (using along with %(if)...%(end)).
--
Regards,
Karthik Nayak
^ permalink raw reply
* Re: [PATCH v15 02/27] bisect: rewrite `check_term_format` shell function in C
From: Pranit Bauva @ 2016-11-15 5:16 UTC (permalink / raw)
To: Stephan Beyer; +Cc: Git List
In-Reply-To: <61aacd44-cb6a-2bbb-7fb4-933e2505040d@gmx.net>
Hey Stephan,
On Tue, Nov 15, 2016 at 3:50 AM, Stephan Beyer <s-beyer@gmx.net> wrote:
> Hi,
>
> I saw in the recent "What's cooking" mail that this is still waiting
> for review, so I thought I could interfere and help reviewing it from a
> non-git-developer point of view.
> But only two commits for today. The first one seems fine. The second
> one makes me write this mail ;-)
Thanks a lot!
> On 10/14/2016 04:14 PM, Pranit Bauva wrote:
>> +static int check_term_format(const char *term, const char *orig_term)
>> +{
> [...]
>> + if (one_of(term, "help", "start", "skip", "next", "reset",
>> + "visualize", "replay", "log", "run", NULL))
> [... vs ...]
>> -check_term_format () {
>> - term=$1
>> - git check-ref-format refs/bisect/"$term" ||
>> - die "$(eval_gettext "'\$term' is not a valid term")"
>> - case "$term" in
>> - help|start|terms|skip|next|reset|visualize|replay|log|run)
>
> Is there a reasons why "terms" has been dropped from the list?
It is a mistake. I will rectify.. Thanks!
Regards,
Pranit Bauva
^ permalink raw reply
* Re: [PATCH] remote-curl: don't hang when a server dies before any output
From: Jeff King @ 2016-11-15 3:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: David Turner, git, spearce
In-Reply-To: <xmqqa8d1v9lo.fsf@gitster.mtv.corp.google.com>
On Mon, Nov 14, 2016 at 05:02:27PM -0800, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > Actually, I take it back. I think it works for a single round of ref
> > negotiation, but not for multiple. Enabling GIT_TEST_LONG=1 causes it to
> > fail t5551.
> >
> > I think I've probably made a mis-assumption on exactly when in the HTTP
> > protocol we will see a flush packet (and perhaps that is a sign that
> > this protocol-snooping approach is not a good one).
>
> Hmph. I think I tried David's original under GIT_TEST_LONG and saw
> it got stuck; could be the same issue, I guess.
It works OK here. I think it is just that the test is really slow (by
design).
-Peff
^ permalink raw reply
* Re: [PATCH] remote-curl: don't hang when a server dies before any output
From: Jeff King @ 2016-11-15 2:40 UTC (permalink / raw)
To: David Turner; +Cc: git, spearce
In-Reply-To: <20161115004426.unheihlmftlw6ex7@sigill.intra.peff.net>
On Mon, Nov 14, 2016 at 07:44:26PM -0500, Jeff King wrote:
> > But it does seem to work. At least it doesn't seem to break anything in
> > the test suite, and it fixes the new tests you added. I'd worry that
> > there's some obscure case where the response isn't packetized in the
> > same way.
>
> Actually, I take it back. I think it works for a single round of ref
> negotiation, but not for multiple. Enabling GIT_TEST_LONG=1 causes it to
> fail t5551.
>
> I think I've probably made a mis-assumption on exactly when in the HTTP
> protocol we will see a flush packet (and perhaps that is a sign that
> this protocol-snooping approach is not a good one).
Yep, that is it. The server may end with an ACK or a NAK, not a flush
packet. So going this route really does mean teaching remote-curl a lot
more about the protocol, which is pretty nasty. I think trying to
somehow signal the end-of-response to fetch-pack would be a more
maintainable approach.
-Peff
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox