* Re* Protecting old temporary objects being reused from concurrent "git gc"?
From: Junio C Hamano @ 2016-11-17 1:35 UTC (permalink / raw)
To: Jeff King; +Cc: Matt McCutchen, git
In-Reply-To: <20161117010449.6k3cwo3njvrid4jy@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> I think the case that is helped here is somebody who runs "git
> write-tree" and expects that the timestamp on those trees is fresh. So
> even more a briefly used index, like:
>
> export GIT_INDEX_FILE=/tmp/foo
> git read-tree ...
> git write-tree
> rm -f $GIT_INDEX_FILE
>
> we'd expect that a "git gc" which runs immediately after would see those
> trees as recent and avoid pruning them (and transitively, any blobs that
> are reachable from the trees). But I don't think that write-tree
> actually freshens them (it sees "oh, we already have these; there is
> nothing to write").
OK, here is what I have queued.
-- >8 --
Subject: cache-tree: make sure to "touch" tree objects the cache-tree records
The cache_tree_fully_valid() function is called by callers that want
to know if they need to call cache_tree_update(), i.e. as an attempt
to optimize. They all want to have a fully valid cache-tree in the
end so that they can write a tree object out.
We used to check if the cached tree object is up-to-date (i.e. the
index entires covered by the cache-tree entry hasn't been changed
since the roll-up hash was computed for the cache-tree entry) and
made sure the tree object is already in the object store. Since the
top-level tree we would soon be asked to write out (and would find
in the object store) may not be anchored to any refs or commits
immediately, freshen the tree object when it happens.
Similarly, when we actually compute the cache-tree entries in
cache_tree_update(), we refrained from writing a tree object out
when it already exists in the object store. We would want to
freshen the tree object in that case to protect it from premature
pruning.
Strictly speaking, freshing these tree objects at each and every
level is probably unnecessary, given that anything reachable from a
young object inherits the youth from the referring object to be
protected from pruning. It should be sufficient to freshen only the
very top-level tree instead. Benchmarking and optimization is left
as an exercise for later days.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
cache-tree.c | 6 +++---
cache.h | 1 +
sha1_file.c | 9 +++++++--
3 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/cache-tree.c b/cache-tree.c
index 3ebf9c3aa4..c8c74a1e07 100644
--- a/cache-tree.c
+++ b/cache-tree.c
@@ -225,7 +225,7 @@ int cache_tree_fully_valid(struct cache_tree *it)
int i;
if (!it)
return 0;
- if (it->entry_count < 0 || !has_sha1_file(it->sha1))
+ if (it->entry_count < 0 || !freshen_object(it->sha1))
return 0;
for (i = 0; i < it->subtree_nr; i++) {
if (!cache_tree_fully_valid(it->down[i]->cache_tree))
@@ -253,7 +253,7 @@ static int update_one(struct cache_tree *it,
*skip_count = 0;
- if (0 <= it->entry_count && has_sha1_file(it->sha1))
+ if (0 <= it->entry_count && freshen_object(it->sha1))
return it->entry_count;
/*
@@ -393,7 +393,7 @@ static int update_one(struct cache_tree *it,
if (repair) {
unsigned char sha1[20];
hash_sha1_file(buffer.buf, buffer.len, tree_type, sha1);
- if (has_sha1_file(sha1))
+ if (freshen_object(sha1))
hashcpy(it->sha1, sha1);
else
to_invalidate = 1;
diff --git a/cache.h b/cache.h
index 4ff196c259..72c0b321ac 100644
--- a/cache.h
+++ b/cache.h
@@ -1077,6 +1077,7 @@ extern int sha1_object_info(const unsigned char *, unsigned long *);
extern int hash_sha1_file(const void *buf, unsigned long len, const char *type, unsigned char *sha1);
extern int write_sha1_file(const void *buf, unsigned long len, const char *type, unsigned char *return_sha1);
extern int hash_sha1_file_literally(const void *buf, unsigned long len, const char *type, unsigned char *sha1, unsigned flags);
+extern int freshen_object(const unsigned char *);
extern int pretend_sha1_file(void *, unsigned long, enum object_type, unsigned char *);
extern int force_object_loose(const unsigned char *sha1, time_t mtime);
extern int git_open_noatime(const char *name);
diff --git a/sha1_file.c b/sha1_file.c
index d0f2aa029b..9acce3d3b8 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -3151,6 +3151,11 @@ static int freshen_packed_object(const unsigned char *sha1)
return 1;
}
+int freshen_object(const unsigned char *sha1)
+{
+ return freshen_packed_object(sha1) || freshen_loose_object(sha1);
+}
+
int write_sha1_file(const void *buf, unsigned long len, const char *type, unsigned char *sha1)
{
char hdr[32];
@@ -3160,7 +3165,7 @@ int write_sha1_file(const void *buf, unsigned long len, const char *type, unsign
* it out into .git/objects/??/?{38} file.
*/
write_sha1_file_prepare(buf, len, type, sha1, hdr, &hdrlen);
- if (freshen_packed_object(sha1) || freshen_loose_object(sha1))
+ if (freshen_object(sha1))
return 0;
return write_loose_object(sha1, hdr, hdrlen, buf, len, 0);
}
@@ -3178,7 +3183,7 @@ int hash_sha1_file_literally(const void *buf, unsigned long len, const char *typ
if (!(flags & HASH_WRITE_OBJECT))
goto cleanup;
- if (freshen_packed_object(sha1) || freshen_loose_object(sha1))
+ if (freshen_object(sha1))
goto cleanup;
status = write_loose_object(sha1, header, hdrlen, buf, len, 0);
--
2.11.0-rc1-156-g07127df5c1
^ permalink raw reply related
* Re: Protecting old temporary objects being reused from concurrent "git gc"?
From: Jeff King @ 2016-11-17 1:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Matt McCutchen, git
In-Reply-To: <xmqq1sybqmjt.fsf@gitster.mtv.corp.google.com>
On Wed, Nov 16, 2016 at 10:58:30AM -0800, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > I suspect the issue is that read-tree populates the cache-tree index
> > extension, and then write-tree omits the object write before it even
> > gets to write_sha1_file().
>
> Wait a minute. The entries in the index and trees in the cache-tree
> are root of "still in use" traversal for the purpose of pruning,
> which makes the "something like this" patch unnecessary for the real
> index file.
>
> And for temporary index files that is kept for 6 months, touching
> tree objects that cache-tree references is irrelevant---the blobs
> recorded in the "list of objects" part of the index will go stale,
> which is a lot more problematic.
I think the case that is helped here is somebody who runs "git
write-tree" and expects that the timestamp on those trees is fresh. So
even more a briefly used index, like:
export GIT_INDEX_FILE=/tmp/foo
git read-tree ...
git write-tree
rm -f $GIT_INDEX_FILE
we'd expect that a "git gc" which runs immediately after would see those
trees as recent and avoid pruning them (and transitively, any blobs that
are reachable from the trees). But I don't think that write-tree
actually freshens them (it sees "oh, we already have these; there is
nothing to write").
I could actually see an argument that the read-tree operation should
freshen the blobs themselves (because we know those blobs are now in
active use, and probably shouldn't be pruned), but I am not sure I agree
there. If only because it is weird that an operation which is otherwise
read-only with respect to the repository would modify the object
database.
-Peff
^ permalink raw reply
* Re: Rebasing cascading topic trees
From: Norbert Kiesel @ 2016-11-17 0:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <xmqq7f83ouqs.fsf@gitster.mtv.corp.google.com>
Yes, `git rebase --onto topic1 topic1@{1} topic2` is the answer!
Thanks so much, learned something new today.
On Wed, Nov 16, 2016 at 3:44 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Norbert Kiesel <nkiesel@gmail.com> writes:
>
>> I currently have a situation with cascading topic branches that I need to rebase
>> regularly. In the picture below, I want to rebase the tree starting with `E` to
>> be rebased onto master (my actually cascade is 4 branches deep).
>>
>> A--B--C--D (master)
>> \
>> E--F (topic1)
>> \
>> G--H (topic2)
>>
>> After running `git rebase --onto master master topic1`, I end up with
>>
>> A--B--C--D (master)
>> | \
>> \ E'--F' (topic1)
>> E--F
>> \
>> G--H (topic2)
>>
>> I then need to also run `git rebase --onto topic1 F topic2` to arrive at the
>> desired
>>
>> A--B--C--D (master)
>> | \
>> \ E'--F' (topic1)
>> E--F \
>> | G'--H' (topic2)
>> \
>> G--H
>>
>> Problem here is that I don't have a nice symbolic name for `F` anymore after the
>> first rebase. Rebasing `topic2` first is not really possible, because I do not
>> have a new graft-point yet. I currently write down `F` ahead of time (or use
>> `reflog` if I forgot) `F`, but I wonder if there is a better solution.
>
> Doesn't topic1@{1} point at "F" after the rebase of the topic1
> finishes?
>
^ permalink raw reply
* Re: [PATCH v15 08/27] bisect--helper: `is_expected_rev` & `check_expected_revs` shell function in C
From: Stephan Beyer @ 2016-11-16 23:47 UTC (permalink / raw)
To: Pranit Bauva, git
In-Reply-To: <01020157c38b1ab6-bda8420e-9a63-47d7-9b99-47465b6333d9-000000@eu-west-1.amazonses.com>
Hi,
On 10/14/2016 04:14 PM, Pranit Bauva wrote:
> diff --git a/builtin/bisect--helper.c b/builtin/bisect--helper.c
> index d84ba86..c542e8b 100644
> --- a/builtin/bisect--helper.c
> +++ b/builtin/bisect--helper.c
> @@ -123,13 +123,40 @@ static int bisect_reset(const char *commit)
> return bisect_clean_state();
> }
>
> +static int is_expected_rev(const char *expected_hex)
> +{
> + struct strbuf actual_hex = STRBUF_INIT;
> + int res = 0;
> + if (strbuf_read_file(&actual_hex, git_path_bisect_expected_rev(), 0) >= 40) {
> + strbuf_trim(&actual_hex);
> + res = !strcmp(actual_hex.buf, expected_hex);
> + }
> + strbuf_release(&actual_hex);
> + return res;
> +}
I am not sure it does what it should.
I would expect the following behavior from this function:
- file does not exist (or is "broken") => return 0
- actual_hex != expected_hex => return 0
- otherwise return 1
If I am not wrong, the code does the following instead:
- file does not exist (or is "broken") => return 0
- actual_hex != expected_hex => return 1
- otherwise => return 0
> +static int check_expected_revs(const char **revs, int rev_nr)
> +{
> + int i;
> +
> + for (i = 0; i < rev_nr; i++) {
> + if (!is_expected_rev(revs[i])) {
> + unlink_or_warn(git_path_bisect_ancestors_ok());
> + unlink_or_warn(git_path_bisect_expected_rev());
> + return 0;
> + }
> + }
> + return 0;
> +}
Here I am not sure what the function *should* do. However, I see that it
basically mimics the behavior of the shell function (assuming
is_expected_rev() is implemented correctly).
I don't understand why the return value is int and not void. To avoid a
"return 0;" line when calling this function?
> @@ -167,6 +196,8 @@ int cmd_bisect__helper(int argc, const char **argv, const char *prefix)
> if (argc > 1)
> die(_("--bisect-reset requires either zero or one arguments"));
> return bisect_reset(argc ? argv[0] : NULL);
> + case CHECK_EXPECTED_REVS:
> + return check_expected_revs(argv, argc);
I note that you check the correct number of arguments for some
subcommands and you do not check it for some other subcommands like this
one. (I don't care, I just want to mention it.)
> default:
> die("BUG: unknown subcommand '%d'", cmdmode);
> }
~Stephan
^ permalink raw reply
* Re: RFC: Enable delayed responses to Git clean/smudge filter requests
From: Junio C Hamano @ 2016-11-16 23:46 UTC (permalink / raw)
To: Jakub Narębski; +Cc: Lars Schneider, Eric Wong, git
In-Reply-To: <5eb682e8-13cb-67f2-a8a9-ec1fa1d139c6@gmail.com>
Jakub Narębski <jnareb@gmail.com> writes:
>> I intend to implement this feature only for the new long running filter
>> process protocol. OK with you?
>
> If I remember and understand it correctly, current version of long
> running process protocol processes files sequentially, one by one:
> git sends file to filter wholly, and receives response wholly.
>
> In the single-file filter case, git calls filter process as async
> task, in a separate thread, so that one thread feeds the filter,
> and main thread (I think?) reads from it, to avoid deadlocks.
>
> Couldn't something like this be done for long running filter process,
> via protocol extension?
My reading of the message you are responding to is that Lars means
doing so by "implement this feature". Instead of returning the
filtered bytes, a new protocol lets his filter to say "No result yet
for you to process, ask me later".
^ permalink raw reply
* Re: Rebasing cascading topic trees
From: Junio C Hamano @ 2016-11-16 23:44 UTC (permalink / raw)
To: Norbert Kiesel; +Cc: git
In-Reply-To: <CAM+g_Nsiu_qqapB+FvwJCBfwEYLTPdHg4DueQWHq4XDNXMCgpQ@mail.gmail.com>
Norbert Kiesel <nkiesel@gmail.com> writes:
> I currently have a situation with cascading topic branches that I need to rebase
> regularly. In the picture below, I want to rebase the tree starting with `E` to
> be rebased onto master (my actually cascade is 4 branches deep).
>
> A--B--C--D (master)
> \
> E--F (topic1)
> \
> G--H (topic2)
>
> After running `git rebase --onto master master topic1`, I end up with
>
> A--B--C--D (master)
> | \
> \ E'--F' (topic1)
> E--F
> \
> G--H (topic2)
>
> I then need to also run `git rebase --onto topic1 F topic2` to arrive at the
> desired
>
> A--B--C--D (master)
> | \
> \ E'--F' (topic1)
> E--F \
> | G'--H' (topic2)
> \
> G--H
>
> Problem here is that I don't have a nice symbolic name for `F` anymore after the
> first rebase. Rebasing `topic2` first is not really possible, because I do not
> have a new graft-point yet. I currently write down `F` ahead of time (or use
> `reflog` if I forgot) `F`, but I wonder if there is a better solution.
Doesn't topic1@{1} point at "F" after the rebase of the topic1
finishes?
^ permalink raw reply
* Rebasing cascading topic trees
From: Norbert Kiesel @ 2016-11-16 23:39 UTC (permalink / raw)
To: git
I currently have a situation with cascading topic branches that I need to rebase
regularly. In the picture below, I want to rebase the tree starting with `E` to
be rebased onto master (my actually cascade is 4 branches deep).
A--B--C--D (master)
\
E--F (topic1)
\
G--H (topic2)
After running `git rebase --onto master master topic1`, I end up with
A--B--C--D (master)
| \
\ E'--F' (topic1)
E--F
\
G--H (topic2)
I then need to also run `git rebase --onto topic1 F topic2` to arrive at the
desired
A--B--C--D (master)
| \
\ E'--F' (topic1)
E--F \
| G'--H' (topic2)
\
G--H
Problem here is that I don't have a nice symbolic name for `F` anymore after the
first rebase. Rebasing `topic2` first is not really possible, because I do not
have a new graft-point yet. I currently write down `F` ahead of time (or use
`reflog` if I forgot) `F`, but I wonder if there is a better solution.
^ permalink raw reply
* [Bug?] git notes are not copied during rebase
From: Norbert Kiesel @ 2016-11-16 23:38 UTC (permalink / raw)
To: git
Hi,
I am currently a heavy user of rebasing and noticed that my notes
don't get correctly applied, even if notes.rewrite.rebase is set
explicitly to true (though manual says that is the default).
Below is a use case that shows that a commit on a branch got rebased,
but the note was not copied to the new commit.
% mkdir notes
% cd notes
% git init
Initialized empty Git repository in /tmp/notes/.git/
% date
% git add a
% git commit -m c1
[master (root-commit) 2e24a91] c1
1 file changed, 1 insertion(+)
create mode 100644 a
% git checkout -b mybranch
Switched to a new branch 'mybranch'
% date
% git add b
% git commit -m c2
[mybranch 5ef9954] c2
1 file changed, 1 insertion(+)
create mode 100644 b
% git notes add -m note1
% git log
commit 5ef9954 (HEAD -> mybranch)
Author: Norbert Kiesel <nkiesel@metricstream.com>
Date: Mon Nov 14 15:48:00 2016 -0800
c2
Notes:
note1
commit 2e24a91 (master)
Author: Norbert Kiesel <nkiesel@metricstream.com>
Date: Mon Nov 14 15:48:00 2016 -0800
c1
% git notes
c39895a0948c17df2028f07c3ec0993a532edabf
5ef9954dbadddfccefe95277be5e7a995335124b
% git checkout master
Switched to branch 'master'
% date
% git commit -a -m c3
[master 1368832] c3
1 file changed, 1 insertion(+)
% git rebase master mybranch
First, rewinding head to replay your work on top of it...
Applying: c2
% git log
commit 8921cb7 (HEAD -> mybranch)
Author: Norbert Kiesel <nkiesel@metricstream.com>
Date: Mon Nov 14 15:48:00 2016 -0800
c2
commit 1368832 (master)
Author: Norbert Kiesel <nkiesel@metricstream.com>
Date: Mon Nov 14 15:48:00 2016 -0800
c3
commit 2e24a91
Author: Norbert Kiesel <nkiesel@metricstream.com>
Date: Mon Nov 14 15:48:00 2016 -0800
c1
% git notes
c39895a0948c17df2028f07c3ec0993a532edabf
5ef9954dbadddfccefe95277be5e7a995335124b
^ permalink raw reply
* Re: [PATCH v15 07/27] bisect--helper: `bisect_reset` shell function in C
From: Stephan Beyer @ 2016-11-16 23:23 UTC (permalink / raw)
To: Pranit Bauva, git
In-Reply-To: <01020157c38b1aa0-0c1fed14-e058-4621-9958-973113d7e45f-000000@eu-west-1.amazonses.com>
Hi,
On 10/14/2016 04:14 PM, Pranit Bauva wrote:
> diff --git a/builtin/bisect--helper.c b/builtin/bisect--helper.c
> index 4254d61..d84ba86 100644
> --- a/builtin/bisect--helper.c
> +++ b/builtin/bisect--helper.c
> @@ -84,12 +89,47 @@ static int write_terms(const char *bad, const char *good)
> return (res < 0) ? -1 : 0;
> }
>
> +static int bisect_reset(const char *commit)
> +{
> + struct strbuf branch = STRBUF_INIT;
> +
> + if (!commit) {
> + if (strbuf_read_file(&branch, git_path_bisect_start(), 0) < 1) {
> + printf("We are not bisecting.\n");
I think this string should be marked for translation.
> + return 0;
> + }
> + strbuf_rtrim(&branch);
[...]
> @@ -121,6 +163,10 @@ int cmd_bisect__helper(int argc, const char **argv, const char *prefix)
> if (argc != 0)
> die(_("--bisect-clean-state requires no arguments"));
> return bisect_clean_state();
> + case BISECT_RESET:
> + if (argc > 1)
> + die(_("--bisect-reset requires either zero or one arguments"));
This error message is imho a little unspecific (but this might not be an
issue because bisect--helper commands are not really exposed to the
user). Maybe "--bisect-reset requires either no argument or a commit."?
> + return bisect_reset(argc ? argv[0] : NULL);
> default:
> die("BUG: unknown subcommand '%d'", cmdmode);
> }
~Stephan
^ permalink raw reply
* Re: RFC: Enable delayed responses to Git clean/smudge filter requests
From: Jakub Narębski @ 2016-11-16 22:41 UTC (permalink / raw)
To: Lars Schneider, Junio C Hamano; +Cc: Eric Wong, git
In-Reply-To: <17709AFF-3C2D-4EC0-97DC-BD750F514D0B@gmail.com>
W dniu 16.11.2016 o 10:53, Lars Schneider pisze:
> On 15 Nov 2016, at 19:03, Junio C Hamano <gitster@pobox.com> wrote:
>> Lars Schneider <larsxschneider@gmail.com> writes:
>>
>>>> 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...
[...]
>> * You'd need to rein in the maximum parallelism somehow, as you do
>> not want to see hundreds of competing filter processes starting
>> only to tell the main loop over an index with hundreds of entries
>> that they are delayed checkouts.
>
> I intend to implement this feature only for the new long running filter
> process protocol. OK with you?
If I remember and understand it correctly, current version of long
running process protocol processes files sequentially, one by one:
git sends file to filter wholly, and receives response wholly.
In the single-file filter case, git calls filter process as async
task, in a separate thread, so that one thread feeds the filter,
and main thread (I think?) reads from it, to avoid deadlocks.
Couldn't something like this be done for long running filter process,
via protocol extension? Namely, Git would send in an async task
content to be filtered, and filter process would stream the response
back, in any order. If it would be not enough, we could borrow
idea of channels, and be sending few files back concurrently in
parallel, as separate channels... though that would probably
require quite a bit of change in caller.
Best,
--
Jakub Narębski
^ permalink raw reply
* What's cooking in git.git (Nov 2016, #03; Wed, 16)
From: Junio C Hamano @ 2016-11-16 22:08 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.
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]
* dt/empty-submodule-in-merge (2016-11-12) 1 commit
- submodules: allow empty working-tree dirs in merge/cherry-pick
An empty directory in a working tree that can simply be nuked used
to interfere while merging or cherry-picking a change to create a
submodule directory there, which has been fixed..
* bw/grep-recurse-submodules (2016-11-14) 6 commits
- grep: search history of moved submodules
- grep: enable recurse-submodules to work on <tree> objects
- grep: optionally recurse into submodules
- grep: add submodules as a grep source type
- submodules: load gitmodules file from commit sha1
- submodules: add helper functions to determine presence of submodules
"git grep" learns to optionally recurse into submodules
* dt/smart-http-detect-server-going-away (2016-11-14) 2 commits
- upload-pack: optionally allow fetching any sha1
- remote-curl: don't hang when a server dies before any output
When the http server gives an incomplete response to a smart-http
rpc call, it could lead to client waiting for a full response that
will never come. Teach the client side to notice this condition
and abort the transfer.
An improvement counterproposal exists.
cf. <20161114194049.mktpsvgdhex2f4zv@sigill.intra.peff.net>
* mm/push-social-engineering-attack-doc (2016-11-14) 1 commit
(merged to 'next' on 2016-11-16 at b7c1b27563)
+ doc: mention transfer data leaks in more places
Doc update on fetching and pushing.
Will cook in 'next'.
* nd/worktree-lock (2016-11-13) 1 commit
(merged to 'next' on 2016-11-16 at 67b731de07)
+ git-worktree.txt: fix typo "to"/"two", and add comma
Typofix.
Will merge to 'master'.
* nd/worktree-move (2016-11-12) 11 commits
. 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()
. copy.c: convert copy_file() to copy_dir_recursively()
. copy.c: style fix
. copy.c: convert bb_(p)error_msg to error(_errno)
. copy.c: delete unused code in copy_file()
. copy.c: import copy_file() from busybox
"git worktree" learned move and remove subcommands.
Seems to break a test or two.
* tk/diffcore-delta-remove-unused (2016-11-14) 1 commit
(merged to 'next' on 2016-11-16 at 51e66c2fa7)
+ diffcore-delta: remove unused parameter to diffcore_count_changes()
Code cleanup.
Will merge to 'master'.
* jc/compression-config (2016-11-15) 1 commit
- compression: unify pack.compression configuration parsing
Compression setting for producing packfiles were spread across
three codepaths, one of which did not honor any configuration.
Unify these so that all of them honor core.compression and
pack.compression variables the same way.
Needs tests for pack-objects and fast-import.
* mm/gc-safety-doc (2016-11-16) 1 commit
- git-gc.txt: expand discussion of races with other processes
Doc update.
Will merge to 'next'.
--------------------------------------------------
[Stalled]
* sb/push-make-submodule-check-the-default (2016-10-10) 2 commits
- push: change submodule default to check when submodules exist
- submodule add: extend force flag to add existing repos
Turn the default of "push.recurseSubmodules" to "check" when
submodules seem to be in use.
Will hold to wait for hv/submodule-not-yet-pushed-fix
* 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.
While I think it would make it easier for people to experiment and
build on if the topic is merged to 'next', I am at the same time a
bit reluctant to merge an unproven new topic that introduces a new
file format, which we may end up having to support til the end of
time. It is likely that to support a "prime clone from CDN", it
would need a lot more than just "these are the heads and the pack
data is over there", so this may not be sufficient.
Will discard.
* mh/connect (2016-06-06) 10 commits
- connect: [host:port] is legacy for ssh
- connect: move ssh command line preparation to a separate function
- connect: actively reject git:// urls with a user part
- connect: change the --diag-url output to separate user and host
- connect: make parse_connect_url() return the user part of the url as a separate value
- connect: group CONNECT_DIAG_URL handling code
- connect: make parse_connect_url() return separated host and port
- connect: re-derive a host:port string from the separate host and port variables
- connect: call get_host_and_port() earlier
- connect: document why we sometimes call get_port after get_host_and_port
Rewrite Git-URL parsing routine (hopefully) without changing any
behaviour.
It has been two months without any support. We may want to discard
this.
* ec/annotate-deleted (2015-11-20) 1 commit
- annotate: skip checking working tree if a revision is provided
Usability fix for annotate-specific "<file> <rev>" syntax with deleted
files.
Has been waiting for a review for too long without seeing anything.
Will discard.
* dk/gc-more-wo-pack (2016-01-13) 4 commits
- gc: clean garbage .bitmap files from pack dir
- t5304: ensure non-garbage files are not deleted
- t5304: test .bitmap garbage files
- prepare_packed_git(): find more garbage
Follow-on to dk/gc-idx-wo-pack topic, to clean up stale
.bitmap and .keep files.
Has been waiting for a reroll for too long.
cf. <xmqq60ypbeng.fsf@gitster.mtv.corp.google.com>
Will discard.
* 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]
* hv/submodule-not-yet-pushed-fix (2016-11-16) 4 commits
- submodule_needs_pushing(): explain the behaviour when we cannot answer
- batch check whether submodule needs pushing into one call
- serialize collection of refs that contain submodule changes
- serialize collection of changed submodules
The code in "git push" to compute if any commit being pushed in the
superproject binds a commit in a submodule that hasn't been pushed
out was overly inefficient, making it unusable even for a small
project that does not have any submodule but have a reasonable
number of refs.
Looking good.
* kn/ref-filter-branch-list (2016-11-15) 18 commits
- for-each-ref: do not segv with %(HEAD) on an unborn branch
- branch: implement '--format' option
- branch: use ref-filter printing APIs
- branch, tag: use porcelain output
- ref-filter: allow porcelain to translate messages in the output
- ref-filter: add `:dir` and `:base` options for ref printing atoms
- ref-filter: make remote_ref_atom_parser() use refname_atom_parser_internal()
- ref-filter: introduce symref_atom_parser() and refname_atom_parser()
- ref-filter: introduce refname_atom_parser_internal()
- ref-filter: make "%(symref)" atom work with the ':short' modifier
- ref-filter: add support for %(upstream:track,nobracket)
- ref-filter: make %(upstream:track) prints "[gone]" for invalid upstreams
- ref-filter: introduce format_ref_array_item()
- ref-filter: move get_head_description() from branch.c
- ref-filter: modify "%(objectname:short)" to take length
- ref-filter: implement %(if:equals=<string>) and %(if:notequals=<string>)
- ref-filter: include reference to 'used_atom' within 'atom_value'
- ref-filter: implement %(if), %(then), and %(else) atoms
The code to list branches in "git branch" has been consolidated
with the more generic ref-filter API.
Rerolled, reviewed, looking good.
Expecting a reroll.
cf. <20161108201211.25213-1-Karthik.188@gmail.com>
cf. <CAOLa=ZQqe3vEj_428d41vd_4kfjzsm87Wam6Zm2dhXWkPdJ8Rw@mail.gmail.com>
cf. <xmqq7f84tqa7.fsf_-_@gitster.mtv.corp.google.com>
* bw/transport-protocol-policy (2016-11-09) 2 commits
(merged to 'next' on 2016-11-16 at 1391d3eeed)
+ transport: add protocol policy config option
+ lib-proto-disable: variable name fix
Finer-grained control of what protocols are allowed for transports
during clone/fetch/push have been enabled via a new configuration
mechanism.
Will cook in 'next'.
* jk/create-branch-remove-unused-param (2016-11-09) 1 commit
(merged to 'next' on 2016-11-16 at 621254c832)
+ create_branch: drop unused "head" parameter
Code clean-up.
Will merge to 'master'.
* jt/fetch-no-redundant-tag-fetch-map (2016-11-11) 1 commit
(merged to 'next' on 2016-11-16 at 5846c27cc5)
+ fetch: do not redundantly calculate tag refmap
Code cleanup to avoid using redundant refspecs while fetching with
the --tags option.
Will cook in 'next'.
* jc/retire-compaction-heuristics (2016-11-02) 3 commits
- SQUASH???
- SQUASH???
- diff: retire the original experimental "compaction" heuristics
* jc/abbrev-autoscale-config (2016-11-01) 1 commit
- config.abbrev: document the new default that auto-scales
* jk/nofollow-attr-ignore (2016-11-02) 5 commits
- exclude: do not respect symlinks for in-tree .gitignore
- attr: do not respect symlinks for in-tree .gitattributes
- exclude: convert "check_index" into a flags field
- attr: convert "macro_ok" into a flags field
- add open_nofollow() helper
* sb/submodule-config-cleanup (2016-11-02) 3 commits
- submodule-config: clarify parsing of null_sha1 element
- submodule-config: rename commit_sha1 to commit_or_tree
- submodule config: inline config_from_{name, path}
* jc/push-default-explicit (2016-10-31) 2 commits
(merged to 'next' on 2016-11-01 at 8dc3a6cf25)
+ push: test pushing ambiguously named branches
+ push: do not use potentially ambiguous default refspec
A lazy "git push" without refspec did not internally use a fully
specified refspec to perform 'current', 'simple', or 'upstream'
push, causing unnecessary "ambiguous ref" errors.
Will cook in 'next'.
* jt/use-trailer-api-in-commands (2016-11-02) 6 commits
- sequencer: use trailer's trailer layout
- trailer: have function to describe trailer layout
- trailer: avoid unnecessary splitting on lines
- commit: make ignore_non_trailer take buf/len
- SQUASH???
- trailer: be stricter in parsing separators
Commands that operate on a log message and add lines to the trailer
blocks, such as "format-patch -s", "cherry-pick (-x|-s)", and
"commit -s", have been taught to use the logic of and share the
code with "git interpret-trailer".
* nd/rebase-forget (2016-10-28) 1 commit
- rebase: add --forget to cleanup rebase, leave HEAD untouched
"git rebase" learned "--forget" option, which allows a user to
remove the metadata left by an earlier "git rebase" that was
manually aborted without using "git rebase --abort".
Waiting for a reroll.
* jc/git-open-cloexec (2016-11-02) 3 commits
- sha1_file: stop opening files with O_NOATIME
- git_open_cloexec(): use fcntl(2) w/ FD_CLOEXEC fallback
- git_open(): untangle possible NOATIME and CLOEXEC interactions
The codeflow of setting NOATIME and CLOEXEC on file descriptors Git
opens has been simplified.
We may want to drop the tip one.
* jk/no-looking-at-dotgit-outside-repo-final (2016-10-26) 1 commit
(merged to 'next' on 2016-10-26 at 220e160451)
+ 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/reset-unmerge (2016-10-24) 1 commit
- reset: --unmerge
After "git add" is run prematurely during a conflict resolution,
"git diff" can no longer be used as a way to sanity check by
looking at the combined diff. "git reset" learned a new
"--unmerge" option to recover from this situation.
* jc/merge-base-fp-only (2016-10-19) 8 commits
. merge-base: fp experiment
- merge: allow to use only the fp-only merge bases
- merge-base: limit the output to bases that are on first-parent chain
- merge-base: mark bases that are on first-parent chain
- merge-base: expose get_merge_bases_many_0() a bit more
- merge-base: stop moving commits around in remove_redundant()
- sha1_name: remove ONELINE_SEEN bit
- commit: simplify fastpath of merge-base
An experiment of merge-base that ignores common ancestors that are
not on the first parent chain.
* tb/convert-stream-check (2016-10-27) 2 commits
- convert.c: stream and fast search for binary
- read-cache: factor out get_sha1_from_index() helper
End-of-line conversion sometimes needs to see if the current blob
in the index has NULs and CRs to base its decision. We used to
always get a full statistics over the blob, but in many cases we
can return early when we have seen "enough" (e.g. if we see a
single NUL, the blob will be handled as binary). The codepaths
have been optimized by using streaming interface.
Waiting for review.
The tip seems to do too much in a single commit and may be better split.
cf. <20161012134724.28287-1-tboegi@web.de>
cf. <xmqqd1il5w4e.fsf@gitster.mtv.corp.google.com>
* pb/bisect (2016-10-18) 27 commits
- 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.
Waiting for review.
* st/verify-tag (2016-10-10) 7 commits
- t/t7004-tag: Add --format specifier tests
- t/t7030-verify-tag: Add --format specifier tests
- builtin/tag: add --format argument for tag -v
- builtin/verify-tag: add --format to verify-tag
- tag: add format specifier to gpg_verify_tag
- ref-filter: add function to print single ref_array_item
- gpg-interface, tag: add GPG_VERIFY_QUIET flag
"git tag" and "git verify-tag" learned to put GPG verification
status in their "--format=<placeholders>" output format.
Waiting for a reroll.
cf. <20161007210721.20437-1-santiago@nyu.edu>
* sb/attr (2016-11-11) 35 commits
- completion: clone can initialize specific submodules
- clone: add --init-submodule=<pathspec> switch
- submodule update: add `--init-default-path` switch
- pathspec: allow escaped query values
- pathspec: allow querying for attributes
- pathspec: move prefix check out of the inner loop
- pathspec: move long magic parsing out of prefix_pathspec
- Documentation: fix a typo
- attr: keep attr stack for each check
- attr: convert to new threadsafe API
- attr: make git_check_attr_counted static
- attr.c: outline the future plans by heavily commenting
- attr.c: always pass check[] to collect_some_attrs()
- attr.c: introduce empty_attr_check_elems()
- attr.c: correct ugly hack for git_all_attrs()
- attr.c: rename a local variable check
- attr.c: pass struct git_attr_check down the callchain
- attr.c: add push_stack() helper
- attr: support quoting pathname patterns in C style
- attr: expose validity check for attribute names
- attr: add counted string version of git_check_attr()
- attr: retire git_check_attrs() API
- attr: convert git_check_attrs() callers to use the new API
- attr: convert git_all_attrs() to use "struct git_attr_check"
- attr: (re)introduce git_check_attr() and struct git_attr_check
- attr: rename function and struct related to checking attributes
- attr.c: plug small leak in parse_attr_line()
- attr.c: tighten constness around "git_attr" structure
- attr.c: simplify macroexpand_one()
- attr.c: mark where #if DEBUG ends more clearly
- attr.c: complete a sentence in a comment
- attr.c: explain the lack of attr-name syntax check in parse_attr()
- attr.c: update a stale comment on "struct match_attr"
- attr.c: use strchrnul() to scan for one line
- commit.c: use strchrnul() to scan for one line
The attributes API has been updated so that it can later be
optimized using the knowledge of which attributes are queried.
Building on top of the updated API, the pathspec machinery learned
to select only paths with given attributes set.
Waiting for review.
* va/i18n-perl-scripts (2016-11-11) 16 commits
- i18n: difftool: mark warnings for translation
- i18n: send-email: mark composing message for translation
- i18n: send-email: mark string with interpolation for translation
- i18n: send-email: mark warnings and errors for translation
- i18n: send-email: mark strings for translation
- i18n: add--interactive: mark status words for translation
- i18n: add--interactive: remove %patch_modes entries
- i18n: add--interactive: mark edit_hunk_manually message for translation
- i18n: add--interactive: i18n of help_patch_cmd
- i18n: add--interactive: mark patch prompt for translation
- i18n: add--interactive: mark plural strings
- i18n: clean.c: match string with git-add--interactive.perl
- i18n: add--interactive: mark strings with interpolation for translation
- i18n: add--interactive: mark simple here-documents for translation
- i18n: add--interactive: mark strings for translation
- Git.pm: add subroutines for commenting lines
Porcelain scripts written in Perl are getting internationalized.
Waiting for review.
* jc/latin-1 (2016-09-26) 2 commits
(merged to 'next' on 2016-09-28 at c8673e03c2)
+ utf8: accept "latin-1" as ISO-8859-1
+ utf8: refactor code to decide fallback encoding
Some platforms no longer understand "latin-1" that is still seen in
the wild in e-mail headers; replace them with "iso-8859-1" that is
more widely known when conversion fails from/to it.
Will hold to see if people scream.
* sg/fix-versioncmp-with-common-suffix (2016-09-08) 5 commits
- versioncmp: cope with common leading parts in versionsort.prereleaseSuffix
- versioncmp: pass full tagnames to swap_prereleases()
- t7004-tag: add version sort tests to show prerelease reordering issues
- t7004-tag: use test_config helper
- t7004-tag: delete unnecessary tags with test_when_finished
The prereleaseSuffix feature of version comparison that is used in
"git tag -l" did not correctly when two or more prereleases for the
same release were present (e.g. when 2.0, 2.0-beta1, and 2.0-beta2
are there and the code needs to compare 2.0-beta1 and 2.0-beta2).
Waiting for a reroll.
cf. <20160908223727.Horde.jVOOJ278ssZ3qkyjkmyqZD-@webmail.informatik.kit.edu>
* jc/pull-rebase-ff (2016-07-28) 1 commit
- pull: fast-forward "pull --rebase=true"
"git pull --rebase", when there is no new commits on our side since
we forked from the upstream, should be able to fast-forward without
invoking "git rebase", but it didn't.
Needs a real log message and a few tests.
* jc/merge-drop-old-syntax (2015-04-29) 1 commit
(merged to 'next' on 2016-10-11 at 8928c8b9b3)
+ 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.
It has been reported that git-gui still uses the deprecated syntax,
which needs to be fixed before this final step can proceed.
cf. <5671DB28.8020901@kdbg.org>
Will cook in 'next'.
^ permalink raw reply
* [PATCH] git-gui: Sort entries in optimized tclIndex
From: Anders Kaseorg @ 2016-11-16 21:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Pat Thoyts, Olaf Hering, git
auto_mkindex expands wildcards in directory order, which depends on
the underlying filesystem. To improve build reproducibility, sort the
list of *.tcl files in the Makefile.
The unoptimized loading case (7 lines below) was previously fixed in
v2.11.0-rc0~31^2^2~14 “git-gui: sort entries in tclIndex”.
Signed-off-by: Anders Kaseorg <andersk@mit.edu>
---
git-gui/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/git-gui/Makefile b/git-gui/Makefile
index fe30be38d..f94b3e13d 100644
--- a/git-gui/Makefile
+++ b/git-gui/Makefile
@@ -252,7 +252,7 @@ $(ALL_MSGFILES): %.msg : %.po
lib/tclIndex: $(ALL_LIBFILES) GIT-GUI-VARS
$(QUIET_INDEX)if echo \
$(foreach p,$(PRELOAD_FILES),source $p\;) \
- auto_mkindex lib '*.tcl' \
+ auto_mkindex lib $(patsubst lib/%,%,$(sort $(ALL_LIBFILES))) \
| $(TCL_PATH) $(QUIET_2DEVNULL); then : ok; \
else \
echo >&2 " * $(TCL_PATH) failed; using unoptimized loading"; \
--
2.11.0.rc0
^ permalink raw reply related
* Re: [PATCH] t0021, t5615: use $PWD instead of $(pwd) in PATH-like shell variables
From: Junio C Hamano @ 2016-11-16 21:51 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy
Cc: Johannes Schindelin, Lars Schneider, Johannes Sixt, git,
Jeff King
In-Reply-To: <alpine.DEB.2.20.1611161041040.3746@virtualbox>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> This is the offending part from last night's build:
>
> -- snipsnap --
> 2016-11-16T00:31:57.5321220Z copy.c: In function 'copy_dir_1':
> 2016-11-16T00:31:57.5321220Z copy.c:369:8: error: implicit declaration of function 'lchown' [-Werror=implicit-function-declaration]
> 2016-11-16T00:31:57.5321220Z if (lchown(dest, source_stat.st_uid, source_stat.st_gid) < 0)
> 2016-11-16T00:31:57.5321220Z ^~~~~~
> 2016-11-16T00:31:57.5321220Z copy.c:391:7: error: implicit declaration of function 'mknod' [-Werror=implicit-function-declaration]
> 2016-11-16T00:31:57.5321220Z if (mknod(dest, source_stat.st_mode, source_stat.st_rdev) < 0)
> 2016-11-16T00:31:57.5321220Z ^~~~~
> 2016-11-16T00:31:57.5321220Z copy.c:405:7: error: implicit declaration of function 'utimes' [-Werror=implicit-function-declaration]
> 2016-11-16T00:31:57.5321220Z if (utimes(dest, times) < 0)
> 2016-11-16T00:31:57.5321220Z ^~~~~~
> 2016-11-16T00:31:57.5321220Z copy.c:407:7: error: implicit declaration of function 'chown' [-Werror=implicit-function-declaration]
> 2016-11-16T00:31:57.5321220Z if (chown(dest, source_stat.st_uid, source_stat.st_gid) < 0) {
> 2016-11-16T00:31:57.5321220Z ^~~~~
> 2016-11-16T00:31:57.7982432Z CC ctype.o
> 2016-11-16T00:31:58.1418929Z cc1.exe: all warnings being treated as errors
> 2016-11-16T00:31:58.6368128Z make: *** [Makefile:1988: copy.o] Error 1
That looks like a part of the new 'instead of run_command("cp -R"),
let's borrow code from somewhere and do that ourselves' in the
nd/worktree-move topic.
The offending part is this:
+ if (S_ISBLK(source_stat.st_mode) ||
+ S_ISCHR(source_stat.st_mode) ||
+ S_ISSOCK(source_stat.st_mode) ||
+ S_ISFIFO(source_stat.st_mode)) {
+ if (mknod(dest, source_stat.st_mode, source_stat.st_rdev) < 0)
+ return error_errno(_("can't create '%s'"), dest);
+ } else
+ return error(_("unrecognized file '%s' with mode %x"),
+ source, source_stat.st_mode);
I think all of this is meant to be used to copy what is in the
working tree, and what is in the working tree is meant to be tracked
by Git, none of the four types that triggers mknod() would be
relevant for our purpose. The simplest and cleanest would be to
make the above to return error("unsupported filetype").
I do not mind run_command("cp -R") and get rid of this code
altogether; that might be a more portable and sensible approach.
^ permalink raw reply
* Re: [PATCH v4 4/4] submodule_needs_pushing() NEEDSWORK when we can not answer this question
From: Heiko Voigt @ 2016-11-16 21:31 UTC (permalink / raw)
To: Junio C Hamano
Cc: Brandon Williams, git, Jeff King, Stefan Beller, Jens.Lehmann,
Fredrik Gustafsson, Leandro Lucarella
In-Reply-To: <xmqqoa1fp72o.fsf@gitster.mtv.corp.google.com>
On Wed, Nov 16, 2016 at 11:18:07AM -0800, Junio C Hamano wrote:
> Heiko Voigt <hvoigt@hvoigt.net> writes:
>
> > Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net>
> > ---
>
> Needs retitle ;-) Here is what I tentatively queued.
Thanks ;-) Missed that one.
> submodule_needs_pushing(): explain the behaviour when we cannot answer
>
> When we do not have commits that are involved in the update of the
> superproject in our copy of submodule, we cannot tell if the remote
> end needs to acquire these commits to be able to check out the
> superproject tree. Explain why we answer "no there is no need/point
> in pushing from our submodule repository" in this case.
>
> Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Sound fine to me.
Cheers Heiko
^ permalink raw reply
* git stash can recursively delete a directory with no warning
From: Russell Yanofsky @ 2016-11-16 20:19 UTC (permalink / raw)
To: git
Using git 2.10.1, I recently lost the contents of an entire directory
by running a "git stash" command. I don't know if this known behavior,
but it seems pretty dangerous. To trigger the bug, all you have to do
is check out a repository containing a symlink, delete the symlink,
and then create a directory with files at the path where the deleted
symlink was. After this, running "git stash" will recursively delete
the directory, leaving no way to recover the data.
Here are minimal steps to reproduce:
mkdir test-repo
cd test-repo
git init
ln -s location symlink
git add symlink
git commit -m'add symlink'
rm symlink
mkdir symlink
echo important-data > symlink/important-data
git stash # recursively deletes entire contents of "symlink" directory
^ permalink raw reply
* Re: [PATCH v1 2/2] travis-ci: disable GIT_TEST_HTTPD for macOS
From: Torsten Bögershausen @ 2016-11-16 20:01 UTC (permalink / raw)
To: Heiko Voigt, Jeff King; +Cc: Lars Schneider, Junio C Hamano, git, Eric Sunshine
In-Reply-To: <20161116143925.GA32631@book.hvoigt.net>
On 16.11.16 15:39, Heiko Voigt wrote:
> On Tue, Nov 15, 2016 at 10:31:59AM -0500, Jeff King wrote:
>> 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?
>
> This is what I see for 5539:
>
> $ GIT_TEST_HTTPD=1 ./t5539-fetch-http-shallow.sh -v
> Initialized empty Git repository in /Users/hvoigt/Repository/git4/t/trash directory.t5539-fetch-http-shallow/.git/
> checking prerequisite: NOT_ROOT
>
> mkdir -p "$TRASH_DIRECTORY/prereq-test-dir" &&
> (
> cd "$TRASH_DIRECTORY/prereq-test-dir" &&
> uid=$(id -u) &&
> test "$uid" != 0
>
> )
> prerequisite NOT_ROOT ok
> httpd: Syntax error on line 65 of /Users/hvoigt/Repository/git4/t/lib-httpd/apache.conf: Cannot load modules/mod_mpm_prefork.so into server: dlopen(/Users/hvoigt/Repository/git4/t/trash directory.t5539-fetch-http-shallow/httpd/modules/mod_mpm_prefork.so, 10): image not found
> error: web server setup failed
>
Yes, same here.
If we take that out:
diff --git a/t/lib-httpd/apache.conf b/t/lib-httpd/apache.conf
index c3e6313..1925fdb 100644
--- a/t/lib-httpd/apache.conf
+++ b/t/lib-httpd/apache.conf
@@ -61,9 +61,6 @@ LockFile accept.lock
<IfModule !mod_access_compat.c>
LoadModule access_compat_module modules/mod_access_compat.so
</IfModule>
-<IfModule !mod_mpm_prefork.c>
- LoadModule mpm_prefork_module modules/mod_mpm_prefork.so
-</IfModule>
<IfModule !mod_unixd.c>
LoadModule unixd_module modules/mod_unixd.so
</IfModule>
I run into other issues:
[core:emerg] [pid 2502] (2)No such file or directory: AH00023: Couldn't create the rewrite-map mutex (file /private/var/run/rewrite-map.2502)
AH00016: Configuration Failed
(apache2 comes via MacPorts)
^ permalink raw reply related
* Can I squash the merge created by "git subtree add"?
From: Kannan Goundan @ 2016-11-16 19:37 UTC (permalink / raw)
To: git
When I do a "git subtree add", I get two commits.
df7e8f5 Merge commit '6de34775ea846c90e3f28e9e7fdfe690385c068b' as
'go/src/gopkg.in/ns1/ns1-go.v1'
6de3477 Squashed 'go/src/gopkg.in/ns1/ns1-go.v1/' content from
commit 1d343da
Unfortunately, in the environment I'm currently working in, merge
commits aren't allowed.
Is it safe to squash these two commits into a single commit? Will
future "subtree" commands still work correctly?
^ permalink raw reply
* Re: RFC: Enable delayed responses to Git clean/smudge filter requests
From: Junio C Hamano @ 2016-11-16 19:19 UTC (permalink / raw)
To: Lars Schneider; +Cc: Eric Wong, git
In-Reply-To: <2F93C9B4-157C-4F5C-9BD5-A67AA519757A@gmail.com>
Lars Schneider <larsxschneider@gmail.com> writes:
>> On 16 Nov 2016, at 19:15, Junio C Hamano <gitster@pobox.com> wrote:
>>
>> Lars Schneider <larsxschneider@gmail.com> writes:
>>
>>>> * You'd need to rein in the maximum parallelism somehow, as you do
>>>> not want to see hundreds of competing filter processes starting
>>>> only to tell the main loop over an index with hundreds of entries
>>>> that they are delayed checkouts.
>>>
>>> I intend to implement this feature only for the new long running filter
>>> process protocol. OK with you?
>>
>> Do you mean that a long-running filter process interacting with
>> convert_to_worktree() called from checkout_entry() will be the only
>> codepath that will spawn multiple processes or threads?
>>
>> That is fine, but it does not change the fact that you still need to
>> limit the maximum parallelism there.
>
> Filters using the long running protocol are spawned only once by Git.
> The filter process would get all the smudge requests via the pipe
> protocol and is supposed to manage the parallelism on its own.
Yes, I think we are on the same page. You need to be careful not to
let the filter process go berserk spawning too many threads or
processes.
^ permalink raw reply
* Re: [PATCH v4 4/4] submodule_needs_pushing() NEEDSWORK when we can not answer this question
From: Junio C Hamano @ 2016-11-16 19:18 UTC (permalink / raw)
To: Heiko Voigt
Cc: Brandon Williams, git, Jeff King, Stefan Beller, Jens.Lehmann,
Fredrik Gustafsson, Leandro Lucarella
In-Reply-To: <9c95594f73625e06374f323fa5dc7d6487aa0356.1479308877.git.hvoigt@hvoigt.net>
Heiko Voigt <hvoigt@hvoigt.net> writes:
> Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net>
> ---
Needs retitle ;-) Here is what I tentatively queued.
submodule_needs_pushing(): explain the behaviour when we cannot answer
When we do not have commits that are involved in the update of the
superproject in our copy of submodule, we cannot tell if the remote
end needs to acquire these commits to be able to check out the
superproject tree. Explain why we answer "no there is no need/point
in pushing from our submodule repository" in this case.
Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
> submodule.c | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/submodule.c b/submodule.c
> index 11391fa..00dd655 100644
> --- a/submodule.c
> +++ b/submodule.c
> @@ -531,6 +531,17 @@ 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))
> + /*
> + * NOTE: We do consider it safe to return "no" here. The
> + * correct answer would be "We do not know" instead of
> + * "No push needed", but it is quite hard to change
> + * the submodule pointer without having the submodule
> + * around. If a user did however change the submodules
> + * without having the submodule around, this indicates
> + * an expert who knows what they are doing or a
> + * maintainer integrating work from other people. In
> + * both cases it should be safe to skip this check.
> + */
> return 0;
>
> if (for_each_remote_ref_submodule(path, has_remote, NULL) > 0) {
^ permalink raw reply
* Re: [PATCH 01/16] submodule.h: add extern keyword to functions, break line before 80
From: Junio C Hamano @ 2016-11-16 19:08 UTC (permalink / raw)
To: Stefan Beller
In-Reply-To: <20161115230651.23953-2-sbeller@google.com>
Stefan Beller <sbeller@google.com> writes:
> submodule.h: add extern keyword to functions, break line before 80
The former is probably a good change for consistency. As the latter
change breaks a workflow around quickly checking the output from
"git grep funcname \*.h", I am not sure if it is a good idea.
Especially things like this look like a usability regression:
-void handle_ignore_submodules_arg(struct diff_options *diffopt, const char *);
+extern void handle_ignore_submodules_arg(struct diff_options *diffopt,
+ const char *);
Perhaps the name "diffopt" can be dropped from there if we want it
to be shorter. Names in prototypes are valuable for parameters of
more generic types like "char *", especially when there are more
than one parameters of the same type, but in this case the typename
is specific enough for readers to tell what it is.
^ permalink raw reply
* Re: [PATCH 02/16] submodule: modernize ok_to_remove_submodule to use argv_array
From: Junio C Hamano @ 2016-11-16 19:03 UTC (permalink / raw)
To: David Turner
Cc: 'Stefan Beller', git@vger.kernel.org, bmwill@google.com,
jrnieder@gmail.com, mogulguy10@gmail.com
In-Reply-To: <e19fbbca91d5446e8fe308e847f53ae3@exmbdft7.ad.twosigma.com>
David Turner <David.Turner@twosigma.com> writes:
>> - "-u",
> ...
>> + argv_array_pushl(&cp.args, "status", "--porcelain", "-uall",
>
> This also changes -u to -uall, which is not mentioned in the
> commit message. That should probably be called out.
Or not making that change at all. Isn't "-u" the same as "-uall"?
^ permalink raw reply
* Re: Protecting old temporary objects being reused from concurrent "git gc"?
From: Junio C Hamano @ 2016-11-16 18:58 UTC (permalink / raw)
To: Jeff King; +Cc: Matt McCutchen, git
In-Reply-To: <20161115174028.zvohfcw4jse3jrmm@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> I suspect the issue is that read-tree populates the cache-tree index
> extension, and then write-tree omits the object write before it even
> gets to write_sha1_file().
Wait a minute. The entries in the index and trees in the cache-tree
are root of "still in use" traversal for the purpose of pruning,
which makes the "something like this" patch unnecessary for the real
index file.
And for temporary index files that is kept for 6 months, touching
tree objects that cache-tree references is irrelevant---the blobs
recorded in the "list of objects" part of the index will go stale,
which is a lot more problematic.
^ permalink raw reply
* Re: RFC: Enable delayed responses to Git clean/smudge filter requests
From: Lars Schneider @ 2016-11-16 18:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Eric Wong, git
In-Reply-To: <xmqqpolvqoka.fsf@gitster.mtv.corp.google.com>
> On 16 Nov 2016, at 19:15, Junio C Hamano <gitster@pobox.com> wrote:
>
> Lars Schneider <larsxschneider@gmail.com> writes:
>
>>> * You'd need to rein in the maximum parallelism somehow, as you do
>>> not want to see hundreds of competing filter processes starting
>>> only to tell the main loop over an index with hundreds of entries
>>> that they are delayed checkouts.
>>
>> I intend to implement this feature only for the new long running filter
>> process protocol. OK with you?
>
> Do you mean that a long-running filter process interacting with
> convert_to_worktree() called from checkout_entry() will be the only
> codepath that will spawn multiple processes or threads?
>
> That is fine, but it does not change the fact that you still need to
> limit the maximum parallelism there.
Filters using the long running protocol are spawned only once by Git.
The filter process would get all the smudge requests via the pipe
protocol and is supposed to manage the parallelism on its own.
- Lars
^ permalink raw reply
* Re: [PATCH 00/11] git worktree (re)move
From: Junio C Hamano @ 2016-11-16 18:39 UTC (permalink / raw)
To: Duy Nguyen; +Cc: git
In-Reply-To: <xmqqy40jqoqm.fsf@gitster.mtv.corp.google.com>
Junio C Hamano <gitster@pobox.com> writes:
> Duy Nguyen <pclouds@gmail.com> writes:
>
>> The following patch should fix it if that's the same thing you saw. I
>> could pile it on worktree-move series, or you can make it a separate
>> one-patch series. What's your preference?
>
> Giving a stable output to the users is probably a good preparatory
> fix to what is already in the released versions, so it would make
> the most sense to make it a separate patch to be applied to maint
> then build the remainder on top.
>
> I do not think "always show the primary first" is necessarily a good
> idea (I would have expected an output more like "git branch --list").
Yikes, "worktree list" is documented like so:
List details of each worktree. The main worktree is listed
first, followed by each of the linked worktrees.
If the primary workree is somehow missing, it still should be listed
first as missing---otherwise the readers of --porcelain readers will
have hard time telling what is going on.
^ permalink raw reply
* Re: [RFC/PATCH 0/2] git diff <(command1) <(command2)
From: Junio C Hamano @ 2016-11-16 18:37 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Michael J Gruber, Jacob Keller, Dennis Kaarsemaker,
Git mailing list
In-Reply-To: <xmqqh977qnvk.fsf@gitster.mtv.corp.google.com>
Junio C Hamano <gitster@pobox.com> writes:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
>> On Mon, 14 Nov 2016, Junio C Hamano wrote:
>>
>>> I _think_ the no-index mode was primarily for those who want to use
>>> our diff as a replacement for GNU and other diffs, and from that
>>> point of view, I'd favour not doing the "comparing symbolic link?
>>> We'll show the difference between the link contents, not target"
>>> under no-index mode myself.
>>
>> If I read this correctly,...
>
> Now I re-read it and I can see it can be read either way.
>
> By "link contents" in "comparing symbolic link? We'll show the
> difference between the link contents, not target", I meant the
> result you get from readlink(2), which will result in
>
> diff --git a/RelNotes b/RelNotes
> index c02235fe8c..b54330f7cd 120000
> --- a/RelNotes
> +++ b/RelNotes
> @@ -1 +1 @@
> -Documentation/RelNotes/2.10.2.txt
> \ No newline at end of file
> +Documentation/RelNotes/2.11.0.txt
> \ No newline at end of file
>
> not the comparison between the files that are link targets,
> i.e. hypothetical
>
> diff --git a/RelNotes b/RelNotes
> index c4d4397023..7a1fce7720 100644
> --- a/Documentation/RelNotes/2.10.2.txt
> +++ b/Documentation/RelNotes/2.11.0.txt
> @@ -1,41 +1,402 @@
> -Git v2.10.2 Release Notes
> -=========================
> +Git 2.11 Release Notes
> ...
>
> And I'd favour *NOT* doing that if we are using our diff as a
Again, this can be read both ways. By "that" on the above line I
meant "the former".
> replacement for GNU and other diffs in "no-index" mode. Which leads
> to ...
>
>>> That is a lot closer to the diff other people implemented, not ours.
>>> Hence the knee-jerk reaction I gave in
>>>
>>> http://public-inbox.org/git/xmqqinrt1zcx.fsf@gitster.mtv.corp.google.com
>
> ... this conclusion, which is consistent with ...
>
>>
>> Let me quote the knee-jerk reaction:
>>
>>> My knee-jerk reaction is:
>>>
>>> * The --no-index mode should default to your --follow-symlinks
>>> behaviour, without any option to turn it on or off.
>
> ... this one.
>
> But notice "I _think_" in the first sentence you quoted. That is a
> basic assumption that leads to the conclusion, and that assumption
> is not a fact. Maybe users do *not* want the "no-index" mode as a
> replacement for GNU and other diffs, in which case comparing the
> result of readlink(2) even in no-index mode might have merit. I
> just didn't think it was the case.
And "I just didn't think it was the case", when fully spelt out, is
"I just didn't think that the assumption was incorrect."
^ 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