* [PATCH/RFC] ref-filter: support sorting case-insensitively
From: Nguyễn Thái Ngọc Duy @ 2016-11-17 10:21 UTC (permalink / raw)
To: git; +Cc: karthik.188, Nguyễn Thái Ngọc Duy
Similar to version:refname sorting refs by versions, icase:refname
will sort by refnames are usually, but strcasecmp will be used instead
of strcmp. This may be helpful sometimes when people name their
branches <group>-<details> but somebody names it <group>-, some goes
with <Group>-, or even <GROUP>-
Syntax is a big problem. This patch does not support
icase:version:refname or version:icase:refname, for example. If
version sorting learns about this thing, I think I prefer
iversion:refname...
Or perhaps we can. I'm losing touch with for-each-ref "pretty"
formats, I'm not quite sure what's the guideline here.
Another option is just use a symbol, like '-' or '*' to mark
case-insensitivity. But that does not look very descriptive. I don't
see any symbol suggesting this case stuff.
What do you think?
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
Documentation/git-for-each-ref.txt | 3 ++-
ref-filter.c | 8 ++++++--
ref-filter.h | 1 +
3 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-for-each-ref.txt b/Documentation/git-for-each-ref.txt
index f57e69bc83..e41005cf0e 100644
--- a/Documentation/git-for-each-ref.txt
+++ b/Documentation/git-for-each-ref.txt
@@ -171,7 +171,8 @@ For sorting purposes, fields with numeric values sort in numeric order
All other fields are used to sort in their byte-value order.
There is also an option to sort by versions, this can be done by using
-the fieldname `version:refname` or its alias `v:refname`.
+the fieldname `version:refname` or its alias `v:refname`. Prefixing
+"icase:" (e.g. `icase:refname`) makes sorting case-insensitive.
In any case, a field name that refers to a field inapplicable to
the object referred by the ref does not cause an error. It
diff --git a/ref-filter.c b/ref-filter.c
index d4c2931f3a..fd63b9c710 100644
--- a/ref-filter.c
+++ b/ref-filter.c
@@ -1542,12 +1542,12 @@ static int cmp_ref_sorting(struct ref_sorting *s, struct ref_array_item *a, stru
if (s->version)
cmp = versioncmp(va->s, vb->s);
else if (cmp_type == FIELD_STR)
- cmp = strcmp(va->s, vb->s);
+ cmp = s->strcmp(va->s, vb->s);
else {
if (va->ul < vb->ul)
cmp = -1;
else if (va->ul == vb->ul)
- cmp = strcmp(a->refname, b->refname);
+ cmp = s->strcmp(a->refname, b->refname);
else
cmp = 1;
}
@@ -1646,6 +1646,7 @@ struct ref_sorting *ref_default_sorting(void)
sorting->next = NULL;
sorting->atom = parse_ref_filter_atom(cstr_name, cstr_name + strlen(cstr_name));
+ sorting->strcmp = strcmp;
return sorting;
}
@@ -1660,6 +1661,7 @@ int parse_opt_ref_sorting(const struct option *opt, const char *arg, int unset)
s = xcalloc(1, sizeof(*s));
s->next = *sorting_tail;
+ s->strcmp = strcmp;
*sorting_tail = s;
if (*arg == '-') {
@@ -1669,6 +1671,8 @@ int parse_opt_ref_sorting(const struct option *opt, const char *arg, int unset)
if (skip_prefix(arg, "version:", &arg) ||
skip_prefix(arg, "v:", &arg))
s->version = 1;
+ else if (skip_prefix(arg, "icase:", &arg))
+ s->strcmp = strcasecmp;
len = strlen(arg);
s->atom = parse_ref_filter_atom(arg, arg+len);
return 0;
diff --git a/ref-filter.h b/ref-filter.h
index 14d435e2cc..ea2db565f1 100644
--- a/ref-filter.h
+++ b/ref-filter.h
@@ -30,6 +30,7 @@ struct ref_sorting {
int atom; /* index into used_atom array (internal) */
unsigned reverse : 1,
version : 1;
+ int (*strcmp)(const char *, const char *);
};
struct ref_array_item {
--
2.11.0.rc0.161.g80d5b92
^ permalink raw reply related
* Re: [PATCH v15 09/27] bisect--helper: `bisect_write` shell function in C
From: Stephan Beyer @ 2016-11-17 9:40 UTC (permalink / raw)
To: Pranit Bauva, git
In-Reply-To: <01020157c38b1ad1-f3a59b1f-9cdb-4d91-b28e-2501facdcb45-000000@eu-west-1.amazonses.com>
Hi,
I've only got some minors to mention here ;)
On 10/14/2016 04:14 PM, Pranit Bauva wrote:
> diff --git a/builtin/bisect--helper.c b/builtin/bisect--helper.c
> index c542e8b..3f19b68 100644
> --- a/builtin/bisect--helper.c
> +++ b/builtin/bisect--helper.c
> @@ -19,9 +19,15 @@ static const char * const git_bisect_helper_usage[] = {
> N_("git bisect--helper --write-terms <bad_term> <good_term>"),
> N_("git bisect--helper --bisect-clean-state"),
> N_("git bisect--helper --bisect-reset [<commit>]"),
> + N_("git bisect--helper --bisect-write <state> <revision> <TERM_GOOD> <TERM_BAD> [<nolog>]"),
> NULL
> };
I wouldn't write "<TERM_GOOD <TERM_BAD>" in capital letters. I'd use
something like "<good_term> <bad_term>" as you have used for
--write-terms. Note that "git bisect --help" uses "<term-old>
<term-new>" in that context.
> @@ -149,6 +155,63 @@ static int check_expected_revs(const char **revs, int rev_nr)
> return 0;
> }
>
> +static int bisect_write(const char *state, const char *rev,
> + const struct bisect_terms *terms, int nolog)
> +{
> + struct strbuf tag = STRBUF_INIT;
> + struct strbuf commit_name = STRBUF_INIT;
> + struct object_id oid;
> + struct commit *commit;
> + struct pretty_print_context pp = {0};
> + FILE *fp = NULL;
> + int retval = 0;
> +
> + if (!strcmp(state, terms->term_bad))
> + strbuf_addf(&tag, "refs/bisect/%s", state);
> + else if (one_of(state, terms->term_good, "skip", NULL))
> + strbuf_addf(&tag, "refs/bisect/%s-%s", state, rev);
> + else {
> + error(_("Bad bisect_write argument: %s"), state);
> + retval = -1;
> + goto finish;
> + }
> +
> + if (get_oid(rev, &oid)) {
> + error(_("couldn't get the oid of the rev '%s'"), rev);
> + retval = -1;
> + goto finish;
> + }
> +
> + if (update_ref(NULL, tag.buf, oid.hash, NULL, 0,
> + UPDATE_REFS_MSG_ON_ERR)) {
> + retval = -1;
> + goto finish;
> + }
I'd like to mention that the "goto fail;" trick could apply in this
function, too.
> @@ -156,9 +219,10 @@ int cmd_bisect__helper(int argc, const char **argv, const char *prefix)
> WRITE_TERMS,
> BISECT_CLEAN_STATE,
> BISECT_RESET,
> - CHECK_EXPECTED_REVS
> + CHECK_EXPECTED_REVS,
> + BISECT_WRITE
> } cmdmode = 0;
> - int no_checkout = 0;
> + int no_checkout = 0, res = 0;
Why do you do this "direct return" -> "set res and return res" transition?
You don't need it in this patch, you do not need it in the subsequent
patches (you always set "res" exactly once after the initialization),
and you don't need cleanup code in this function.
> struct option options[] = {
> OPT_CMDMODE(0, "next-all", &cmdmode,
> N_("perform 'git bisect next'"), NEXT_ALL),
> @@ -170,10 +234,13 @@ int cmd_bisect__helper(int argc, const char **argv, const char *prefix)
> N_("reset the bisection state"), BISECT_RESET),
> OPT_CMDMODE(0, "check-expected-revs", &cmdmode,
> N_("check for expected revs"), CHECK_EXPECTED_REVS),
> + OPT_CMDMODE(0, "bisect-write", &cmdmode,
> + N_("write out the bisection state in BISECT_LOG"), BISECT_WRITE),
That info text is confusing, especially considering that there is a
"nolog" option. I think the action of bisect-write is two-fold: (1)
update the refs, (2) log.
> @@ -182,24 +249,37 @@ int cmd_bisect__helper(int argc, const char **argv, const char *prefix)
> usage_with_options(git_bisect_helper_usage, options);
>
> switch (cmdmode) {
> + int nolog;
> case NEXT_ALL:
> return bisect_next_all(prefix, no_checkout);
> case WRITE_TERMS:
> if (argc != 2)
> die(_("--write-terms requires two arguments"));
> - return write_terms(argv[0], argv[1]);
> + res = write_terms(argv[0], argv[1]);
> + break;
As indicated above, I think the direct "return ...;" is cleaner.
~Stephan
^ permalink raw reply
* Re: RFC: Enable delayed responses to Git clean/smudge filter requests
From: Lars Schneider @ 2016-11-17 9:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jakub Narębski, Eric Wong, git
In-Reply-To: <xmqq37irouni.fsf@gitster.mtv.corp.google.com>
> On 17 Nov 2016, at 00:46, Junio C Hamano <gitster@pobox.com> wrote:
>
> 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".
Correct!
^ permalink raw reply
* [ANNOUNCE] tig-2.2.1
From: Jonas Fonseca @ 2016-11-17 4:04 UTC (permalink / raw)
To: git
Hello,
A new minor version of tig is available which adds support for
diff-highlight (see instructions below) and navigation between merge
commits as well as several keybinding tweaks.
Tarballs should now be downloaded from GitHub. Either go to
https://github.com/jonas/tig/releases or use the following pattern:
https://github.com/jonas/tig/releases/download/tig-VERSION/tig-VERSION.tar.gz
MD5 checksums can be found at:
https://github.com/jonas/tig/releases/download/tig-VERSION/tig-VERSION.tar.gz.md5
Similarly, the home page is now also on GitHub at
https://jonas.github.io/tig/. A big thanks to Simon L. B. Nielsen for
generously hosting Tig on nitro.dk!
Release notes
-------------
Improvements:
- Support Git's 'diff-highlight' program when `diff-highlight` is set
to either true or the path of the script to use for post-processing.
- Add navigation between merge commits. (GH #525)
- Add 'A' as a binding to apply a stash without dropping it.
- Bind 'Ctrl-D' and 'Ctrl-U' to half-page movements by default.
- manual: Mention how to change default Up/Down behavior in diff view.
Bug fixes
- Reorganize checking of libraries for termcap functions.
- Fix `:goto <id>` error message.
Change summary
--------------
The short diffstat and log summary for changes made in this release.
118 files changed, 3765 insertions(+), 3284 deletions(-)
22 Jonas Fonseca
1 Frank Fesevur
1 Jelte Fennema
1 Jeremy Lin
1 Parker Coates
1 Philipp Gesang
1 Ramsay Jones
1 David Lin
1 lightside
--
Jonas Fonseca
^ permalink raw reply
* Re: [PATCH v15 07/27] bisect--helper: `bisect_reset` shell function in C
From: Pranit Bauva @ 2016-11-17 3:56 UTC (permalink / raw)
To: Stephan Beyer; +Cc: Git List
In-Reply-To: <1190e37e-d54a-7dbf-412d-8dff90ca677a@gmx.net>
Hey Stephan,
On Thu, Nov 17, 2016 at 4:53 AM, Stephan Beyer <s-beyer@gmx.net> wrote:
> 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.
True. Thanks!
>> + 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."?
That sounds good.
>> + return bisect_reset(argc ? argv[0] : NULL);
>> default:
>> die("BUG: unknown subcommand '%d'", cmdmode);
>> }
Regards,
Pranit Bauva
^ permalink raw reply
* Re: Rebasing cascading topic trees
From: Norbert Kiesel @ 2016-11-17 3:21 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20161117014522.lzk43sfmpl4ted3d@sigill.intra.peff.net>
More things I learned!
So there are (at least) 2 possible approaches: using history, or using
local tracking branches. The latter looks actually nicer to me, with
the exception that if asks for a `git pull`. Using `git pull
--rebase` actually also ends up with the same tree, but I like the
rebase better.
The following 2 scripts show the 2 approaches. Only difference is in
the creation of topic/b and the last rebase command.
# History
mkdir topic; cd topic
git init
date > a; git add a; git commit -m a
date > b; git add b; git commit -m b
git branch -b topic/a
git checkout -b topic1
date > c; git add c; git commit -m c
date > d; git add d; git commit -m d
git checkout -b topic2
date > e; git add e; git commit -m e
date > f; git add f; git commit -m f
git checkout master
date > g; git add g; git commit -m g
echo "before rebase"; git log --oneline --graph --all
git rebase master topic1
echo "after rebase of topic1"; git log --oneline --graph --all
git rebase --onto=topic1 topic1@{1} topic2
echo "after rebase of topic2"; git log --oneline --graph --all
# Tracking
mkdir topic; cd topic
git init
date > a; git add a; git commit -m a
date > b; git add b; git commit -m b
git branch -b topic/a
git checkout -b topic1
date > c; git add c; git commit -m c
date > d; git add d; git commit -m d
git checkout --track topic1 -b topic2
date > e; git add e; git commit -m e
date > f; git add f; git commit -m f
git checkout master
date > g; git add g; git commit -m g
echo "before rebase"; git log --oneline --graph --all
git rebase master topic1
echo "after rebase of topic1"; git log --oneline --graph --all
git rebase --onto=topic1 master topic2
echo "after rebase of topic2"; git log --oneline --graph --all
On Wed, Nov 16, 2016 at 5:45 PM, Jeff King <peff@peff.net> wrote:
> On Wed, Nov 16, 2016 at 04:12:20PM -0800, Norbert Kiesel wrote:
>
>> Yes, `git rebase --onto topic1 topic1@{1} topic2` is the answer!
>
> See also the `--fork-point` option, which (I think) should do this for
> you (and is the default if "topic1" is the configured upstream for
> topic2 and you just run "git rebase").
>
> -Peff
^ permalink raw reply
* Re: Rebasing cascading topic trees
From: Jeff King @ 2016-11-17 1:45 UTC (permalink / raw)
To: Norbert Kiesel; +Cc: Junio C Hamano, git
In-Reply-To: <CAM+g_Ns-9Sj5r0V2XXZfGQz+0XiO1O-hT03japEGibkNgh8a4A@mail.gmail.com>
On Wed, Nov 16, 2016 at 04:12:20PM -0800, Norbert Kiesel wrote:
> Yes, `git rebase --onto topic1 topic1@{1} topic2` is the answer!
See also the `--fork-point` option, which (I think) should do this for
you (and is the default if "topic1" is the configured upstream for
topic2 and you just run "git rebase").
-Peff
^ permalink raw reply
* Re: Re* Protecting old temporary objects being reused from concurrent "git gc"?
From: Jeff King @ 2016-11-17 1:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Matt McCutchen, git
In-Reply-To: <xmqqvavmopl8.fsf_-_@gitster.mtv.corp.google.com>
On Wed, Nov 16, 2016 at 05:35:47PM -0800, Junio C Hamano wrote:
> 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.
That makes sense. I was focusing on cache_tree_update() call, but we do
not even get there in the fully-valid case.
So I think this approach is nice as long as there is not a caller who
asks "are we fully valid? I do not need to write, but was just
wondering". That should be a read-only operation, but the freshen calls
may fail with EPERM, for example.
I do not see any such callers, nor do I really expect any. Just trying
to think through the possible consequences.
> 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.
Good observation, and nicely explained all around.
-Peff
^ permalink raw reply
* 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
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