* [PATCH v2] rev-list-options: clarify the usage of --reverse
From: Pranit Bauva @ 2016-09-27 20:44 UTC (permalink / raw)
To: git
In-Reply-To: <010201576bfb6c7d-0b68228f-9503-4dd1-9721-713477fa2596-000000@eu-west-1.amazonses.com>
Specify even more clearly that --reverse works only with the commits
which are chosen to be shown so as to eliminate the confusion as to
whether the first n or the last n commits with be shown when used
with `-n --reverse`.
Reported-by: Ruediger Meier <sweet_f_a@gmx.de>
Signed-off-by: Pranit Bauva <pranit.bauva@gmail.com>
---
Documentation/rev-list-options.txt | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/Documentation/rev-list-options.txt b/Documentation/rev-list-options.txt
index 7e462d3..5da7cf5 100644
--- a/Documentation/rev-list-options.txt
+++ b/Documentation/rev-list-options.txt
@@ -657,8 +657,9 @@ avoid showing the commits from two parallel development track mixed
together.
--reverse::
- Output the commits in reverse order.
- Cannot be combined with `--walk-reflogs`.
+ Output the commits chosen to be shown (see Commit Limiting
+ section above) in reverse order. Cannot be combined with
+ `--walk-reflogs`.
Object Traversal
~~~~~~~~~~~~~~~~
--
https://github.com/git/git/pull/296
^ permalink raw reply related
* Re: [PATCH 3/4 v4] ls-files: pass through safe options for --recurse-submodules
From: Brandon Williams @ 2016-09-27 20:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <xmqqd1jpnpyh.fsf@gitster.mtv.corp.google.com>
On 09/27, Junio C Hamano wrote:
> Brandon Williams <bmwill@google.com> writes:
>
> > if (recurse_submodules &&
> > - (show_stage || show_deleted || show_others || show_unmerged ||
> > + (show_deleted || show_others || show_unmerged ||
> > show_killed || show_modified || show_resolve_undo ||
> > - show_valid_bit || show_tag || show_eol || with_tree ||
> > - (line_terminator == '\0')))
> > + with_tree))
> > die("ls-files --recurse-submodules unsupported mode");
>
> Ahh, one more thing, and this comment probably applies to 2/4 not
> this one, but if the intention is to shrink this "not supported yet"
> check as the series progresses, in the earlier step the check would
> need to make sure no pathspec is given, which is first supported in
> 4/4, I think. It is not a big deal to require rerolling by itself,
> bit if you are rerolling 2/4 for other reasons, then...
Oh there is a separate if gaurd for pathspecs which is introduced in 2/4
and then removed once pathspec support has been added in 4/4.
--
Brandon Williams
^ permalink raw reply
* Re: [PATCH 3/4 v4] ls-files: pass through safe options for --recurse-submodules
From: Brandon Williams @ 2016-09-27 20:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <xmqqh991nq34.fsf@gitster.mtv.corp.google.com>
On 09/27, Junio C Hamano wrote:
> Brandon Williams <bmwill@google.com> writes:
> > @@ -170,6 +171,27 @@ static void show_killed_files(struct dir_struct *dir)
> > }
> > }
> >
> > +/*
> > + * Compile an argv_array with all of the options supported by --recurse_submodules
> > + */
> > +static void compile_submodule_options(int show_tag)
> > +{
> > + if (show_cached)
> > + argv_array_push(&recurse_submodules_opts, "--cached");
> > + if (show_stage)
> > + argv_array_push(&recurse_submodules_opts, "--stage");
> > + if (show_valid_bit)
> > + argv_array_push(&recurse_submodules_opts, "-v");
> > + if (show_tag)
> > + argv_array_push(&recurse_submodules_opts, "-t");
> > + if (line_terminator == '\0')
> > + argv_array_push(&recurse_submodules_opts, "-z");
> > + if (debug_mode)
> > + argv_array_push(&recurse_submodules_opts, "--debug");
> > + if (show_eol)
> > + argv_array_push(&recurse_submodules_opts, "--eol");
> > +}
>
> OK. These are only the safe ones to pass through? "compile" or
> "assemble" is much less important thing to say than how these are
> chosen. "pass_supported_options()" or something? I dunno.
Alternatively we can change this to compile all potential options (not
just the ones that are supported now) and then just error the caller
out, as you've suggested, if an unsupported option used. 'pass' may not
be the most descriptive word for this function as it isn't actually
doing the passing but rather generating an argv of options that will be
passed in the event a submodule is found and we need to kick off a child
process for it.
--
Brandon Williams
^ permalink raw reply
* Re: [PATCH 3/4 v4] ls-files: pass through safe options for --recurse-submodules
From: Brandon Williams @ 2016-09-27 20:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <xmqqwphxm7av.fsf@gitster.mtv.corp.google.com>
On 09/27, Junio C Hamano wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
> > In nul_to_q and q_to_nul implementations (t/test-lib-functions.sh)
> > we seem to avoid using "tr", even though q_to_cr and others do use
> > it. I wonder if we had some portability issues with passing NUL
> > through tr or something?
> >
> > ... digs and finds e85fe4d8 ("more tr portability test script
> > fixes", 2008-03-12)
> >
> > So use something like
> >
> > perl -pe 'y/\012/\000/' <<\-EOF
> > ...
> > EOF
> >
> > instead, perhaps?
>
> I actually think it would make more sense to add
>
> lf_to_nul () {
> perl -pe 'y/\012/\000/'
> }
>
> to t/test-lib-functions.sh somewhere near q_to_nul if we were to go
> this route.
my mind is drawing a blank, what does the 'lf' in 'lf_to_nul' stand for?
line feed?
--
Brandon Williams
^ permalink raw reply
* RE: git-upload-pack hangs
From: Jason Pyeron @ 2016-09-27 20:56 UTC (permalink / raw)
To: git; +Cc: 'Junio C Hamano'
In-Reply-To: <xmqqlgydqqk0.fsf@gitster.mtv.corp.google.com>
> -----Original Message-----
> From: Junio C Hamano
> Sent: Tuesday, September 27, 2016 12:02
>
> Jason Pyeron writes:
>
> > This is a very, very first draft.
> >
> > It is allowing IIS to work right now.
> >
> > I still need to address chunked issues, where there is no
> content length (see
> http://www.gossamer-threads.com/lists/apache/users/373042)
> >
> > Any comments, sugestions?
>
> Does this have any relation to another thread earlier this year,
> which seems to have ended here:
>
> https://public-inbox.org/git/20160401235532.GA27941@sigill.intra.peff.net/
Looks like the same. Did not (don't know why I was unsubscribed a few months ago?!) see that one and gmane is killing me on my
searches...
I will read the full thread, digest and fold what I can glean in to my (in production right now) patch.
-Jason
^ permalink raw reply
* Re: [PATCH 3/4 v4] ls-files: pass through safe options for --recurse-submodules
From: Junio C Hamano @ 2016-09-27 20:58 UTC (permalink / raw)
To: Brandon Williams; +Cc: git
In-Reply-To: <20160927205202.GG32565@google.com>
Brandon Williams <bmwill@google.com> writes:
> my mind is drawing a blank, what does the 'lf' in 'lf_to_nul' stand for?
> line feed?
Yup. "man 7 ascii" ;-)
^ permalink raw reply
* Re: [PATCH 3/4 v4] ls-files: pass through safe options for --recurse-submodules
From: Stefan Beller @ 2016-09-27 20:59 UTC (permalink / raw)
To: Brandon Williams; +Cc: Junio C Hamano, git@vger.kernel.org
In-Reply-To: <20160927205202.GG32565@google.com>
On Tue, Sep 27, 2016 at 1:52 PM, Brandon Williams <bmwill@google.com> wrote:
> On 09/27, Junio C Hamano wrote:
>> Junio C Hamano <gitster@pobox.com> writes:
>>
>> > In nul_to_q and q_to_nul implementations (t/test-lib-functions.sh)
>> > we seem to avoid using "tr", even though q_to_cr and others do use
>> > it. I wonder if we had some portability issues with passing NUL
>> > through tr or something?
>> >
>> > ... digs and finds e85fe4d8 ("more tr portability test script
>> > fixes", 2008-03-12)
>> >
>> > So use something like
>> >
>> > perl -pe 'y/\012/\000/' <<\-EOF
>> > ...
>> > EOF
>> >
>> > instead, perhaps?
>>
>> I actually think it would make more sense to add
>>
>> lf_to_nul () {
>> perl -pe 'y/\012/\000/'
>> }
>>
>> to t/test-lib-functions.sh somewhere near q_to_nul if we were to go
>> this route.
>
> my mind is drawing a blank, what does the 'lf' in 'lf_to_nul' stand for?
> line feed?
>
Yes, line feed. (Note that Git has to deal with this cross platform new lines
e.g. CRLF is common on Windows, CR was common on MAC, and LF is
Windows, so naming the new line as they are, makes sense here.)
^ permalink raw reply
* Re: [PATCH 2/2] use strbuf_add_unique_abbrev() for adding short hashes, part 2
From: René Scharfe @ 2016-09-27 20:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git List
In-Reply-To: <xmqqshslm6jo.fsf@gitster.mtv.corp.google.com>
Am 27.09.2016 um 22:28 schrieb Junio C Hamano:
> René Scharfe <l.s.r@web.de> writes:
>> diff --git a/submodule.c b/submodule.c
>> index dcc5ce3..8cf40ea 100644
>> --- a/submodule.c
>> +++ b/submodule.c
>> @@ -396,7 +396,7 @@ static void show_submodule_header(FILE *f, const char *path,
>> find_unique_abbrev(one->hash, DEFAULT_ABBREV));
>> if (!fast_backward && !fast_forward)
>> strbuf_addch(&sb, '.');
>> - strbuf_addstr(&sb, find_unique_abbrev(two->hash, DEFAULT_ABBREV));
>> + strbuf_add_unique_abbrev(&sb->hash, two, DEFAULT_ABBREV);
>
> I wonder how could this change come out of this definition:
>
> @@
> expression E1, E2, E3;
> @@
> - strbuf_addstr(E1, find_unique_abbrev(E2, E3));
> + strbuf_add_unique_abbrev(E1, E2, E3);
Impossible. I added "->hash" manually during a rebase (merging
a0d12c44, wrongly). Good catch, thanks!
Seeing proof of skipping compile-testing I wonder what else I do
forget in my daily life. :-| I'll better go to sleep now..
Fixup patch, generated by reverting the diff, re-adding the
semantic patch and using coccicheck; compiles and survives make
test:
---
submodule.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/submodule.c b/submodule.c
index 8cf40ea..bb06b60 100644
--- a/submodule.c
+++ b/submodule.c
@@ -396,7 +396,7 @@ static void show_submodule_header(FILE *f, const char *path,
find_unique_abbrev(one->hash, DEFAULT_ABBREV));
if (!fast_backward && !fast_forward)
strbuf_addch(&sb, '.');
- strbuf_add_unique_abbrev(&sb->hash, two, DEFAULT_ABBREV);
+ strbuf_add_unique_abbrev(&sb, two->hash, DEFAULT_ABBREV);
if (message)
strbuf_addf(&sb, " %s%s\n", message, reset);
else
--
2.10.0
^ permalink raw reply related
* [PATCH v4 2/2] fsck: handle bad trees like other errors
From: David Turner @ 2016-09-27 20:59 UTC (permalink / raw)
To: git, peff; +Cc: David Turner
In-Reply-To: <1475009991-16368-1-git-send-email-dturner@twosigma.com>
Instead of dying when fsck hits a malformed tree object, log the error
like any other and continue. Now fsck can tell the user which tree is
bad, too.
Signed-off-by: David Turner <dturner@twosigma.com>
---
fsck.c | 18 ++++++++-----
t/t1450-fsck.sh | 16 +++++++++--
tree-walk.c | 83 +++++++++++++++++++++++++++++++++++++++++++++++++--------
tree-walk.h | 8 ++++++
4 files changed, 106 insertions(+), 19 deletions(-)
diff --git a/fsck.c b/fsck.c
index c9cf3de..4a3069e 100644
--- a/fsck.c
+++ b/fsck.c
@@ -347,8 +347,9 @@ static int fsck_walk_tree(struct tree *tree, void *data, struct fsck_options *op
return -1;
name = get_object_name(options, &tree->object);
- init_tree_desc(&desc, tree->buffer, tree->size);
- while (tree_entry(&desc, &entry)) {
+ if (init_tree_desc_gently(&desc, tree->buffer, tree->size))
+ return -1;
+ while (tree_entry_gently(&desc, &entry)) {
struct object *obj;
int result;
@@ -520,7 +521,7 @@ static int verify_ordered(unsigned mode1, const char *name1, unsigned mode2, con
static int fsck_tree(struct tree *item, struct fsck_options *options)
{
- int retval;
+ int retval = 0;
int has_null_sha1 = 0;
int has_full_path = 0;
int has_empty_name = 0;
@@ -535,7 +536,10 @@ static int fsck_tree(struct tree *item, struct fsck_options *options)
unsigned o_mode;
const char *o_name;
- init_tree_desc(&desc, item->buffer, item->size);
+ if (init_tree_desc_gently(&desc, item->buffer, item->size)) {
+ retval += report(options, &item->object, FSCK_MSG_BAD_TREE, "cannot be parsed as a tree");
+ return retval;
+ }
o_mode = 0;
o_name = NULL;
@@ -556,7 +560,10 @@ static int fsck_tree(struct tree *item, struct fsck_options *options)
is_hfs_dotgit(name) ||
is_ntfs_dotgit(name));
has_zero_pad |= *(char *)desc.buffer == '0';
- update_tree_entry(&desc);
+ if (update_tree_entry_gently(&desc)) {
+ retval += report(options, &item->object, FSCK_MSG_BAD_TREE, "cannot be parsed as a tree");
+ break;
+ }
switch (mode) {
/*
@@ -597,7 +604,6 @@ static int fsck_tree(struct tree *item, struct fsck_options *options)
o_name = name;
}
- retval = 0;
if (has_null_sha1)
retval += report(options, &item->object, FSCK_MSG_NULL_SHA1, "contains entries pointing to null sha1");
if (has_full_path)
diff --git a/t/t1450-fsck.sh b/t/t1450-fsck.sh
index 8f52da2..ee7d473 100755
--- a/t/t1450-fsck.sh
+++ b/t/t1450-fsck.sh
@@ -188,8 +188,7 @@ test_expect_success 'commit with NUL in header' '
grep "error in commit $new.*unterminated header: NUL at offset" out
'
-test_expect_success 'malformatted tree object' '
- test_when_finished "git update-ref -d refs/tags/wrong" &&
+test_expect_success 'tree object with duplicate entries' '
test_when_finished "remove_object \$T" &&
T=$(
GIT_INDEX_FILE=test-index &&
@@ -208,6 +207,19 @@ test_expect_success 'malformatted tree object' '
grep "error in tree .*contains duplicate file entries" out
'
+test_expect_success 'unparseable tree object' '
+ test_when_finished "git update-ref -d refs/heads/wrong" &&
+ test_when_finished "remove_object \$tree_sha1" &&
+ test_when_finished "remove_object \$commit_sha1" &&
+ tree_sha1=$(printf "100644 \0twenty-bytes-of-junk" | git hash-object -t tree --stdin -w --literally) &&
+ commit_sha1=$(git commit-tree $tree_sha1) &&
+ git update-ref refs/heads/wrong $commit_sha1 &&
+ test_must_fail git fsck 2>out &&
+ test_i18ngrep "error: empty filename in tree entry" out &&
+ test_i18ngrep "$tree_sha1" out &&
+ test_i18ngrep ! "fatal: empty filename in tree entry" out
+'
+
test_expect_success 'tag pointing to nonexistent' '
cat >invalid-tag <<-\EOF &&
object ffffffffffffffffffffffffffffffffffffffff
diff --git a/tree-walk.c b/tree-walk.c
index 24f9a0f..828f435 100644
--- a/tree-walk.c
+++ b/tree-walk.c
@@ -22,33 +22,60 @@ static const char *get_mode(const char *str, unsigned int *modep)
return str;
}
-static void decode_tree_entry(struct tree_desc *desc, const char *buf, unsigned long size)
+static int decode_tree_entry(struct tree_desc *desc, const char *buf, unsigned long size, struct strbuf *err)
{
const char *path;
unsigned int mode, len;
- if (size < 23 || buf[size - 21])
- die(_("too-short tree object"));
+ if (size < 23 || buf[size - 21]) {
+ strbuf_addstr(err, _("too-short tree object"));
+ return -1;
+ }
path = get_mode(buf, &mode);
- if (!path)
- die(_("malformed mode in tree entry for tree"));
- if (!*path)
- die(_("empty filename in tree entry for tree"));
+ if (!path) {
+ strbuf_addstr(err, _("malformed mode in tree entry"));
+ return -1;
+ }
+ if (!*path) {
+ strbuf_addstr(err, _("empty filename in tree entry"));
+ return -1;
+ }
len = strlen(path) + 1;
/* Initialize the descriptor entry */
desc->entry.path = path;
desc->entry.mode = canon_mode(mode);
desc->entry.oid = (const struct object_id *)(path + len);
+
+ return 0;
}
-void init_tree_desc(struct tree_desc *desc, const void *buffer, unsigned long size)
+static int init_tree_desc_internal(struct tree_desc *desc, const void *buffer, unsigned long size, struct strbuf *err)
{
desc->buffer = buffer;
desc->size = size;
if (size)
- decode_tree_entry(desc, buffer, size);
+ return decode_tree_entry(desc, buffer, size, err);
+ return 0;
+}
+
+void init_tree_desc(struct tree_desc *desc, const void *buffer, unsigned long size)
+{
+ struct strbuf err = STRBUF_INIT;
+ if (init_tree_desc_internal(desc, buffer, size, &err))
+ die("%s", err.buf);
+ strbuf_release(&err);
+}
+
+int init_tree_desc_gently(struct tree_desc *desc, const void *buffer, unsigned long size)
+{
+ struct strbuf err = STRBUF_INIT;
+ int result = init_tree_desc_internal(desc, buffer, size, &err);
+ if (result)
+ error("%s", err.buf);
+ strbuf_release(&err);
+ return result;
}
void *fill_tree_descriptor(struct tree_desc *desc, const unsigned char *sha1)
@@ -75,7 +102,7 @@ static void entry_extract(struct tree_desc *t, struct name_entry *a)
*a = t->entry;
}
-void update_tree_entry(struct tree_desc *desc)
+static int update_tree_entry_internal(struct tree_desc *desc, struct strbuf *err)
{
const void *buf = desc->buffer;
const unsigned char *end = desc->entry.oid->hash + 20;
@@ -89,7 +116,30 @@ void update_tree_entry(struct tree_desc *desc)
desc->buffer = buf;
desc->size = size;
if (size)
- decode_tree_entry(desc, buf, size);
+ return decode_tree_entry(desc, buf, size, err);
+ return 0;
+}
+
+void update_tree_entry(struct tree_desc *desc)
+{
+ struct strbuf err = STRBUF_INIT;
+ if (update_tree_entry_internal(desc, &err))
+ die("%s", err.buf);
+ strbuf_release(&err);
+}
+
+int update_tree_entry_gently(struct tree_desc *desc)
+{
+ struct strbuf err = STRBUF_INIT;
+ if (update_tree_entry_internal(desc, &err)) {
+ error("%s", err.buf);
+ strbuf_release(&err);
+ /* Stop processing this tree after error */
+ desc->size = 0;
+ return -1;
+ }
+ strbuf_release(&err);
+ return 0;
}
int tree_entry(struct tree_desc *desc, struct name_entry *entry)
@@ -102,6 +152,17 @@ int tree_entry(struct tree_desc *desc, struct name_entry *entry)
return 1;
}
+int tree_entry_gently(struct tree_desc *desc, struct name_entry *entry)
+{
+ if (!desc->size)
+ return 0;
+
+ *entry = desc->entry;
+ if (update_tree_entry_gently(desc))
+ return 0;
+ return 1;
+}
+
void setup_traverse_info(struct traverse_info *info, const char *base)
{
int pathlen = strlen(base);
diff --git a/tree-walk.h b/tree-walk.h
index 97a7d69..68bb78b 100644
--- a/tree-walk.h
+++ b/tree-walk.h
@@ -25,14 +25,22 @@ static inline int tree_entry_len(const struct name_entry *ne)
return (const char *)ne->oid - ne->path - 1;
}
+/*
+ * The _gently versions of these functions warn and return false on a
+ * corrupt tree entry rather than dying,
+ */
+
void update_tree_entry(struct tree_desc *);
+int update_tree_entry_gently(struct tree_desc *);
void init_tree_desc(struct tree_desc *desc, const void *buf, unsigned long size);
+int init_tree_desc_gently(struct tree_desc *desc, const void *buf, unsigned long size);
/*
* Helper function that does both tree_entry_extract() and update_tree_entry()
* and returns true for success
*/
int tree_entry(struct tree_desc *, struct name_entry *);
+int tree_entry_gently(struct tree_desc *, struct name_entry *);
void *fill_tree_descriptor(struct tree_desc *desc, const unsigned char *sha1);
--
2.8.0.rc4.22.g8ae061a
^ permalink raw reply related
* [PATCH v4 1/2] tree-walk: be more specific about corrupt tree errors
From: David Turner @ 2016-09-27 20:59 UTC (permalink / raw)
To: git, peff; +Cc: David Turner
From: Jeff King <peff@peff.net>
When the tree-walker runs into an error, it just calls
die(), and the message is always "corrupt tree file".
However, we are actually covering several cases here; let's
give the user a hint about what happened.
Let's also avoid using the word "corrupt", which makes it
seem like the data bit-rotted on disk. Our sha1 check would
already have found that. These errors are ones of data that
is malformed in the first place.
Signed-off-by: David Turner <dturner@twosigma.com>
Signed-off-by: Jeff King <peff@peff.net>
---
t/t1007-hash-object.sh | 25 +++++++++++++++++++++++--
tree-walk.c | 12 +++++++-----
2 files changed, 30 insertions(+), 7 deletions(-)
diff --git a/t/t1007-hash-object.sh b/t/t1007-hash-object.sh
index acca9ac..c5245c5 100755
--- a/t/t1007-hash-object.sh
+++ b/t/t1007-hash-object.sh
@@ -183,9 +183,30 @@ for args in "-w --stdin-paths" "--stdin-paths -w"; do
pop_repo
done
-test_expect_success 'corrupt tree' '
+test_expect_success 'too-short tree' '
echo abc >malformed-tree &&
- test_must_fail git hash-object -t tree malformed-tree
+ test_must_fail git hash-object -t tree malformed-tree 2>err &&
+ test_i18ngrep "too-short tree object" err
+'
+
+hex2oct() {
+ perl -ne 'printf "\\%03o", hex for /../g'
+}
+
+test_expect_success 'malformed mode in tree' '
+ hex_sha1=$(echo foo | git hash-object --stdin -w) &&
+ bin_sha1=$(echo $hex_sha1 | hex2oct) &&
+ printf "9100644 \0$bin_sha1" >tree-with-malformed-mode &&
+ test_must_fail git hash-object -t tree tree-with-malformed-mode 2>err &&
+ test_i18ngrep "malformed mode in tree entry" err
+'
+
+test_expect_success 'empty filename in tree' '
+ hex_sha1=$(echo foo | git hash-object --stdin -w) &&
+ bin_sha1=$(echo $hex_sha1 | hex2oct) &&
+ printf "100644 \0$bin_sha1" >tree-with-empty-filename &&
+ test_must_fail git hash-object -t tree tree-with-empty-filename 2>err &&
+ test_i18ngrep "empty filename in tree entry" err
'
test_expect_success 'corrupt commit' '
diff --git a/tree-walk.c b/tree-walk.c
index ce27842..24f9a0f 100644
--- a/tree-walk.c
+++ b/tree-walk.c
@@ -27,12 +27,14 @@ static void decode_tree_entry(struct tree_desc *desc, const char *buf, unsigned
const char *path;
unsigned int mode, len;
- if (size < 24 || buf[size - 21])
- die("corrupt tree file");
+ if (size < 23 || buf[size - 21])
+ die(_("too-short tree object"));
path = get_mode(buf, &mode);
- if (!path || !*path)
- die("corrupt tree file");
+ if (!path)
+ die(_("malformed mode in tree entry for tree"));
+ if (!*path)
+ die(_("empty filename in tree entry for tree"));
len = strlen(path) + 1;
/* Initialize the descriptor entry */
@@ -81,7 +83,7 @@ void update_tree_entry(struct tree_desc *desc)
unsigned long len = end - (const unsigned char *)buf;
if (size < len)
- die("corrupt tree file");
+ die(_("too-short tree file"));
buf = end;
size -= len;
desc->buffer = buf;
--
2.8.0.rc4.22.g8ae061a
^ permalink raw reply related
* Re: [PATCH 3/4 v4] ls-files: pass through safe options for --recurse-submodules
From: Junio C Hamano @ 2016-09-27 20:59 UTC (permalink / raw)
To: Brandon Williams; +Cc: git
In-Reply-To: <20160927204440.GE32565@google.com>
Brandon Williams <bmwill@google.com> writes:
> Oh there is a separate if gaurd for pathspecs which is introduced in 2/4
> and then removed once pathspec support has been added in 4/4.
Thanks; I missed to spot that when I wrote the message you are
responding to, but it indeed is there ;-)
^ permalink raw reply
* Re: [PATCH 1/2] ls-files: adding support for submodules
From: Junio C Hamano @ 2016-09-27 21:38 UTC (permalink / raw)
To: Brandon Williams; +Cc: Jeff King, git
In-Reply-To: <xmqq7fa36bwm.fsf@gitster.mtv.corp.google.com>
As this is relevant to what to call the prefix thing that is passed
down to an internal re-invocation of ls-files and how to explain it
to end-users...
Junio C Hamano <gitster@pobox.com> writes:
> I agree that this is not specific to submodules; this is closely
> related to what we internally call "prefix", but is different.
>
> In any case, I would strongly recommend against exposing this (or
> anything for that matter) "--prefix" to the end-user,...
I have a slight suspicion that this was what made you say earlier
that I was against exposing this at all to end users, but what I
meant was a plain boring "prefix" is a bad name and nothing more
than that.
> What we internally call "prefix" and "--submodule-prefix" is closely
> related in that they both interact with pathspecs. "prefix" gets
> prepended to elements of an end-user supplied pathspec before a
> full-path-in-the-repository (i.e. a path in the index and a path
> relative from the top of the working tree) is matched against them.
In a sense, this new thing is a superset of the existing GIT_PREFIX,
which gives the current working directory from the end user's point
of view relative to the actual current working directory. The "git"
wrapper, when running a "git thing" from a subdirectory of a working
tree, chdir(2)s up to the top-level before spawning the "thing"
subcommand that is not built-in or a third-party "git-thing" binary
on user's $PATH; so "git-thing" binary will be told via $GIT_PREFIX
relative to what directory path-like things the end user supplied to
the command (e.g. "-o outfile" argument and pathspecs) need to be
interpreted. The new thing can override the $GIT_PREFIX to allow
path-like things to be interpreted relative to somewhere _above_ the
top-level of the working tree.
I am tempted to suggest GIT_SUPER_PREFIX, 50% because I cannot think
of any better word, 40% because I think it actually makes sense (in
the sense that this comes _above_ it, hence "super", and also in the
sense that this is something your "super" project would give you),
and 10% because I hope that being ridiculous would nudge people to
come up with a better alternative ;-)
And from that point of view ...
> * It is unclear how this should interact with commands that are run
> in a subdirectory of the working tree. E.g. what should the
> prefix and the pathspec look like if the command in the above
> example is started in w/git.git/Documentation subdirectory, i.e.
>
> $ cd ~
> $ git -C w/git.git/Documentation ls-files \
> --submodule-prefix=??????? -- '???????' |
> xargs ls -1 -l
>
> Should we error out if we are not at the top of the working tree
> when --submodule-prefix is given?
... the answer to this question becomes clear. It is not possible
to _be_ in a subdirectory "Documentation" of this working tree and
in a directory "~" above this working tree at the same time, so we
simply should forbid running the command from anywhere other than
the top of the working tree (i.e. the internal "prefix" and
GIT_PREFIX must be empty) when the super-prefix is set by erroring
it out. When we realize that "prefix" adds to the paths that are
supplied by the user (e.g. when the user says Makefile while in t/
subdirectory, i.e. GIT_PREFIX=t/, s/he means t/Makefile), but this
new thing subtracts from the paths given by the user (e.g. when the
user gives a pathspec 'w/git.git/D*' while setting the super thing
as w/git.git, because s/he is at ~/, the pathspec matcher
conceptually subtracts w/git.git/ from the pathspec before matching
them against the paths it finds in the index), it becomes clear that
giving both at the same time is awkward and not very useful.
^ permalink raw reply
* Re: [PATCH v4 1/2] tree-walk: be more specific about corrupt tree errors
From: Junio C Hamano @ 2016-09-27 21:45 UTC (permalink / raw)
To: David Turner; +Cc: git, peff
In-Reply-To: <1475009991-16368-1-git-send-email-dturner@twosigma.com>
Thanks, will queue both.
^ permalink raw reply
* Re: [PATCH 1/2] ls-files: adding support for submodules
From: Brandon Williams @ 2016-09-27 21:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git
In-Reply-To: <xmqq60phm39w.fsf@gitster.mtv.corp.google.com>
On 09/27, Junio C Hamano wrote:
> > What we internally call "prefix" and "--submodule-prefix" is closely
> > related in that they both interact with pathspecs. "prefix" gets
> > prepended to elements of an end-user supplied pathspec before a
> > full-path-in-the-repository (i.e. a path in the index and a path
> > relative from the top of the working tree) is matched against them.
>
> In a sense, this new thing is a superset of the existing GIT_PREFIX,
> which gives the current working directory from the end user's point
> of view relative to the actual current working directory. The "git"
> wrapper, when running a "git thing" from a subdirectory of a working
> tree, chdir(2)s up to the top-level before spawning the "thing"
> subcommand that is not built-in or a third-party "git-thing" binary
> on user's $PATH; so "git-thing" binary will be told via $GIT_PREFIX
> relative to what directory path-like things the end user supplied to
> the command (e.g. "-o outfile" argument and pathspecs) need to be
> interpreted. The new thing can override the $GIT_PREFIX to allow
> path-like things to be interpreted relative to somewhere _above_ the
> top-level of the working tree.
>
> I am tempted to suggest GIT_SUPER_PREFIX, 50% because I cannot think
> of any better word, 40% because I think it actually makes sense (in
> the sense that this comes _above_ it, hence "super", and also in the
> sense that this is something your "super" project would give you),
> and 10% because I hope that being ridiculous would nudge people to
> come up with a better alternative ;-)
haha, yeah it seems difficult to come up with a name that is going to
mean the same thing in 5 years from now. At least GIT_SUPER_PREFIX
makes senese in that it is a path from the superproject down to the
submodule.
> > * It is unclear how this should interact with commands that are run
> > in a subdirectory of the working tree. E.g. what should the
> > prefix and the pathspec look like if the command in the above
> > example is started in w/git.git/Documentation subdirectory, i.e.
> >
> > $ cd ~
> > $ git -C w/git.git/Documentation ls-files \
> > --submodule-prefix=??????? -- '???????' |
> > xargs ls -1 -l
> >
> > Should we error out if we are not at the top of the working tree
> > when --submodule-prefix is given?
>
> ... the answer to this question becomes clear. It is not possible
> to _be_ in a subdirectory "Documentation" of this working tree and
> in a directory "~" above this working tree at the same time, so we
> simply should forbid running the command from anywhere other than
> the top of the working tree (i.e. the internal "prefix" and
> GIT_PREFIX must be empty) when the super-prefix is set by erroring
> it out. When we realize that "prefix" adds to the paths that are
> supplied by the user (e.g. when the user says Makefile while in t/
> subdirectory, i.e. GIT_PREFIX=t/, s/he means t/Makefile), but this
> new thing subtracts from the paths given by the user (e.g. when the
> user gives a pathspec 'w/git.git/D*' while setting the super thing
> as w/git.git, because s/he is at ~/, the pathspec matcher
> conceptually subtracts w/git.git/ from the pathspec before matching
> them against the paths it finds in the index), it becomes clear that
> giving both at the same time is awkward and not very useful.
Well maybe...I don't really know much about how the prefix interacts in
every scenario but would what you describe still work if we are in a sub
dir of the superproject (which contains other directorys and perhaps a
submodule) and execute a --recurse-submodules command in the
subdirectory? I suspect we don't want to force users to be in the root
directory of the project in order to use --recurse-submodules.
--
Brandon Williams
^ permalink raw reply
* Re: [PATCH v2] rev-list-options: clarify the usage of --reverse
From: Philip Oakley @ 2016-09-27 21:51 UTC (permalink / raw)
To: Pranit Bauva, git
In-Reply-To: <010201576d63f422-abe45938-0da1-4fc0-b0e7-3e552b59d10a-000000@eu-west-1.amazonses.com>
From: "Pranit Bauva" <pranit.bauva@gmail.com>
> Specify even more clearly that --reverse works only with the commits
> which are chosen to be shown so as to eliminate the confusion as to
> whether the first n or the last n commits with be shown when used
hi Pranit,
micro-nit: 'first' and 'last' can be tricky to distinguish for lists (e.g.
of commits) that can be considered from both ends with equal ease (people
are so easily confused ;-). In such cases its always worth stating the sort
order mechanism (within the appropriate sentence). However, in this case the
clarification is to clearly point elsewhere, so I'm OK with the patch.
> with `-n --reverse`.
>
> Reported-by: Ruediger Meier <sweet_f_a@gmx.de>
> Signed-off-by: Pranit Bauva <pranit.bauva@gmail.com>
> ---
> Documentation/rev-list-options.txt | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/rev-list-options.txt
> b/Documentation/rev-list-options.txt
> index 7e462d3..5da7cf5 100644
> --- a/Documentation/rev-list-options.txt
> +++ b/Documentation/rev-list-options.txt
> @@ -657,8 +657,9 @@ avoid showing the commits from two parallel
> development track mixed
> together.
>
> --reverse::
> - Output the commits in reverse order.
> - Cannot be combined with `--walk-reflogs`.
> + Output the commits chosen to be shown (see Commit Limiting
> + section above) in reverse order. Cannot be combined with
> + `--walk-reflogs`.
>
> Object Traversal
> ~~~~~~~~~~~~~~~~
>
> --
> https://github.com/git/git/pull/296
>
--
Philip
^ permalink raw reply
* Re: [PATCH 00/11] Resumable clone
From: Eric Wong @ 2016-09-27 21:51 UTC (permalink / raw)
To: Kevin Wern; +Cc: git
In-Reply-To: <1473984742-12516-1-git-send-email-kevin.m.wern@gmail.com>
Kevin Wern <kevin.m.wern@gmail.com> wrote:
> Hey, all,
>
> It's been a while (sent a very short patch in May), but I've
> still been working on the resumable clone feature and checking up on
> the mailing list for any updates. After submitting the prime-clone
> service alone, I figured implementing the whole thing would be the best
> way to understand the full scope of the problem (this is my first real
> contribution here, and learning while working on such an involved
> feature has not been easy).
Thank you for working on this. I'm hugely interested in this
feature as both a cheapskate sysadmin and as a client with
unreliable connectivity (and I've barely been connected this month).
> This is a functional implementation handling a direct http/ftp URI to a
> single, fully connected packfile (i.e. the link is a direct path to the
> file, not a prefix or guess). My hope is that this acts as a bare
> minimum cross-section spanning the full requirments that can expand in
> width as more cases are added (.info file, split bundle, daemon
> download service). This is certainly not perfect, but I think it at
> least prototypes each component involved in the workflow.
>
> This patch series is based on jc/bundle, because the logic to find the
> tips of a pack's history already exists there (I call index-pack
> --clone-bundle on the downloaded file, and read the file to write the
> references to a temporary directory). If I need to re-implement this
> logic or base it on another branch, let me know. For ease of pulling
> and testing, I included the branch here:
>
> https://github.com/kevinwern/git/tree/feature/prime-clone
Am I correct this imposes no additional storage burden for servers?
(unlike the current .bundle dance used by kernel.org:
https://www.kernel.org/cloning-linux-from-a-bundle.html )
That would be great!
> Although there are a few changes internally from the last patch,
> the "alternate resource" url to download is configured on the
> server side in exactly the same way:
>
> [primeclone]
> url = http://location/pack-$NAME.pack
> filetype = pack
If unconfigured, I wonder if a primeclone pack can be inferred by
the existence of a pack bitmap (or merely being the biggest+oldest
pack for dumb HTTP).
> The prime-clone service simply outputs the components as:
>
> ####url filetype
> 0000
>
> On the client side, the transport_prime_clone and
> transport_download_primer APIs are built to be more robust (i.e. read
> messages without dying due to protocol errors), so that git clone can
> always try them without being dependent on the capability output of
> git-upload-pack. transport_download_primer is dependent on the success
> of transport_prime_clone, but transport_prime_clone is always run on an
> initial clone. Part of achieving this robustness involves adding
> *_gentle functions to pkt_line, so that prime_clone can fail silently
> without dying.
>
> The transport_download_primer function uses a resumable download,
> which is applicable to both automatic and manual resuming. Automatic
> is programmatically reconnecting to the resource after being
> interrupted (up to a set number of times). Manual is using a newly
> taught --resume option on the command line:
>
> git clone --resume <resumable_work_or_git_dir>
I think calling "git fetch" should resume, actually.
It would reduce the learning curve and seems natural to me:
"fetch" is jabout grabbing whatever else appeared since the
last clone/fetch happened.
> Right now, a manually resumable directory is left behind only if the
> *client* is interrupted while a new junk mode, JUNK_LEAVE_RESUMABLE,
> is set (right before the download). For an initial clone, if the
> connection fails after automatic resuming, the client erases the
> partial resources and falls through to a normal clone. However, once a
> resumable directory is left behind by the program, it is NEVER
> deleted/abandoned after it is continued with --resume.
I'm not sure if erasing partial resources should ever be done
automatically. Perhaps a note to the user explaining the
situation and potential ways to correct/resume it.
> I think determining when a resource is "unsalvageable" should be more
> nuanced. Especially in a case where a connection is perpetually poor
> and the user wishes to resume over a long period of time. The timeout
> logic itself *definitely* needs more nuance than "repeat 5 times", such
> as expanding wait times and using earlier successes when deciding to
> try again. Right now, I think the most important part of this patch is
> that these two paths (falling through after a failed download, exiting
> to be manually resumed later) exist.
>
> Off the top of my head, outstanding issues/TODOs inlcude:
> - The above issue of determining when to fall through, when to
> reattempt, and when to write the resumable info and exit
> in git clone.
My current (initial) reaction is: you're overthinking this.
I think it's less surprising to a user to always write resumable
info and let them know how to resume (or abort); rather than
trying to second-guess their intent.
Going by the zero-one-infinity rule, I'd probably attempt an
auto-retry once on socket errors before saving state and bailing
with instructions on how to resume.
If they hit Ctrl-C manually, then just tell them they can
either resume or "rm -r" the directory.
> - Creating git-daemon service to download a resumable resource.
> Pretty straightforward, I think, especially if
> http.getanyfile already exists. This falls more under
> "haven't gotten to yet" than dilemma.
I think this could be handled natively by git-daemon for
trickling data to slow clients in the existing event loop (and
expanded to use epoll/kqueue). Similar to how X-Sendfile works
with (Apache|lighttpd) or X-Accel in nginx.
This would be cheaper than wasting a process (or thread) to
trickle to low-bandwidth clients. But this may be an
optimization we defer until we've ironed out other parts.
> - Logic for git clone to determine when a full clone would
> be superior, such as when a clone is local or a reference is
> given.
> - Configuring prime-clone for multiple resources, in two
> dimensions: (a) resources to choose from (e.g. fall back to
> a second resource if the first one doesn't work) and (b)
> resources to be downloaded together or in sequence (e.g.
> download http://host/this, then http://host/that). Maybe
> prime-clone could also handle client preferences in terms of
> filetype or protocol. For this, I just have to re-read a few
> discussions about the filetypes we use to see if there are
> any outliers that aren't representable in this way. I think
> this is another "haven't gotten to yet".
Perhaps using the existing http-alternates (and automatic
primeclone pack inference I wrote about above) can be done.
<snip>
> - Creating the logic to guess a packfile, and append that to a
> prefix specified by the admin. Additionally, allowing the
> admin to use a custom script to use their own logic to
> output the URL.
Yes :) Though I'm not sure if the custom script is necessary.
^ permalink raw reply
* Re: [PATCH 1/2] ls-files: adding support for submodules
From: Junio C Hamano @ 2016-09-27 22:01 UTC (permalink / raw)
To: Brandon Williams; +Cc: Jeff King, git
In-Reply-To: <20160927214854.GA180705@google.com>
Brandon Williams <bmwill@google.com> writes:
> Well maybe...I don't really know much about how the prefix interacts in
> every scenario but would what you describe still work if we are in a sub
> dir of the superproject (which contains other directorys and perhaps a
> submodule) and execute a --recurse-submodules command in the
> subdirectory? I suspect we don't want to force users to be in the root
> directory of the project in order to use --recurse-submodules.
You need to remember "must be at the top" is relevant only to the
command that is invoked with --super-prefix, not the recursive one
that drives such a process.
Suppose your superproject is organized like so:
- file-at-top
a/file-in-A
a/b (submodule)
a/b/file-at-top-of-B
c/ (submodule)
c/file-at-top-of-C
If you are in a subdirectory of your superproject, say, a/,
cd a && git ls-files --recurse-submodules -- "b*"
I would expect we would recurse into the submodule at "a/b" and find
"b/file-at-top-of-B". What does the internal invocation to do so
would look like? I would think "git -C b --super=b ls-files" that
is run from "a".
Your code would is already prepared to find "file-at-top-of-B" in
the index of the submodule, prepend "b/" to it and report the result
as "b/file-at-top-of-B" when such a call is made, I think.
Now, can you refer to c/ and c/file-at-top-of-C while sitting at a/?
cd a && git ls-files --recurse-submodules -- "../c*"
would be the top-level invocation. This would iterate over the
index of the superproject, trying to find what matches "c*" (or,
"../c*" relative to "a" i.e. where you are), find that 'c' that is a
submodule, and invoke "git -C ../c --super=../c ls-files"
internally, I would imagine. I think your code is prepared to
accept this case as well.
In any case, the "must be at the top" does not come into the picture
at all for the end-user interaction, i.e. invocation of the command
that is told to recurse into submodules, so we'd be OK.
^ permalink raw reply
* Re: [PATCH 00/11] Resumable clone
From: Junio C Hamano @ 2016-09-27 22:07 UTC (permalink / raw)
To: Eric Wong; +Cc: Kevin Wern, git
In-Reply-To: <20160927215143.GA32622@starla>
Eric Wong <e@80x24.org> writes:
>> [primeclone]
>> url = http://location/pack-$NAME.pack
>> filetype = pack
>
> If unconfigured, I wonder if a primeclone pack can be inferred by
> the existence of a pack bitmap (or merely being the biggest+oldest
> pack for dumb HTTP).
That would probably be a nice heuristics but it is unclear who
should find that out at runtime. The downloading side would not
have a visiblity into directory listing.
>> git clone --resume <resumable_work_or_git_dir>
>
> I think calling "git fetch" should resume, actually.
> It would reduce the learning curve and seems natural to me:
> "fetch" is jabout grabbing whatever else appeared since the
> last clone/fetch happened.
I hate say this but it sounds to me like a terrible idea. At that
point when you need to resume, there is not even ref for "fetch" to
base its incremental work off of. It is better to keep the knowledge
of this "priming" dance inside "clone". Hopefully the original "clone"
whose connection was disconnected in the middle would automatically
attempt resuming and "clone --resume" would not be as often as needed.
^ permalink raw reply
* Re: [PATCH 1/2] ls-files: adding support for submodules
From: Brandon Williams @ 2016-09-27 22:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git
In-Reply-To: <xmqqwphxknoj.fsf@gitster.mtv.corp.google.com>
On 09/27, Junio C Hamano wrote:
> Brandon Williams <bmwill@google.com> writes:
>
> > Well maybe...I don't really know much about how the prefix interacts in
> > every scenario but would what you describe still work if we are in a sub
> > dir of the superproject (which contains other directorys and perhaps a
> > submodule) and execute a --recurse-submodules command in the
> > subdirectory? I suspect we don't want to force users to be in the root
> > directory of the project in order to use --recurse-submodules.
>
> You need to remember "must be at the top" is relevant only to the
> command that is invoked with --super-prefix, not the recursive one
> that drives such a process.
>
> Suppose your superproject is organized like so:
>
> - file-at-top
> a/file-in-A
> a/b (submodule)
> a/b/file-at-top-of-B
> c/ (submodule)
> c/file-at-top-of-C
>
> If you are in a subdirectory of your superproject, say, a/,
>
> cd a && git ls-files --recurse-submodules -- "b*"
>
> I would expect we would recurse into the submodule at "a/b" and find
> "b/file-at-top-of-B". What does the internal invocation to do so
> would look like? I would think "git -C b --super=b ls-files" that
> is run from "a".
>
> Your code would is already prepared to find "file-at-top-of-B" in
> the index of the submodule, prepend "b/" to it and report the result
> as "b/file-at-top-of-B" when such a call is made, I think.
>
> Now, can you refer to c/ and c/file-at-top-of-C while sitting at a/?
>
> cd a && git ls-files --recurse-submodules -- "../c*"
>
> would be the top-level invocation. This would iterate over the
> index of the superproject, trying to find what matches "c*" (or,
> "../c*" relative to "a" i.e. where you are), find that 'c' that is a
> submodule, and invoke "git -C ../c --super=../c ls-files"
> internally, I would imagine. I think your code is prepared to
> accept this case as well.
>
> In any case, the "must be at the top" does not come into the picture
> at all for the end-user interaction, i.e. invocation of the command
> that is told to recurse into submodules, so we'd be OK.
Thanks for the clear explination that makes sense.
Also, --super-prefix as a name is growing on me :)
--
Brandon Williams
^ permalink raw reply
* Re: [PATCH v2] rev-list-options: clarify the usage of --reverse
From: Junio C Hamano @ 2016-09-27 22:12 UTC (permalink / raw)
To: Philip Oakley; +Cc: Pranit Bauva, git
In-Reply-To: <A9427F4400044104B47378E024C7C2A4@PhilipOakley>
"Philip Oakley" <philipoakley@iee.org> writes:
> micro-nit: 'first' and 'last' can be tricky to distinguish for lists...
Let's do this then.
-- >8 --
From: Pranit Bauva <pranit.bauva@gmail.com>
Date: Tue, 27 Sep 2016 20:44:09 +0000
Subject: [PATCH] rev-list-options: clarify the usage of --reverse
Users often wonder if the oldest or the newest n commits are shown
by `log -n --reverse`. Clarify that --reverse kicks in only after
deciding which commits are to be shown to unconfuse them.
Reported-by: Ruediger Meier <sweet_f_a@gmx.de>
Signed-off-by: Pranit Bauva <pranit.bauva@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Documentation/rev-list-options.txt | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/Documentation/rev-list-options.txt b/Documentation/rev-list-options.txt
index 4f009d4..f8946d4 100644
--- a/Documentation/rev-list-options.txt
+++ b/Documentation/rev-list-options.txt
@@ -638,8 +638,9 @@ avoid showing the commits from two parallel development track mixed
together.
--reverse::
- Output the commits in reverse order.
- Cannot be combined with `--walk-reflogs`.
+ Output the commits chosen to be shown (see Commit Limiting
+ section above) in reverse order. Cannot be combined with
+ `--walk-reflogs`.
Object Traversal
~~~~~~~~~~~~~~~~
--
2.10.0-561-g98a6b79
^ permalink raw reply related
* Re: [PATCH v2] rev-list-options: clarify the usage of --reverse
From: Philip Oakley @ 2016-09-27 22:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Pranit Bauva, git
In-Reply-To: <xmqqoa39kn57.fsf@gitster.mtv.corp.google.com>
From: "Junio C Hamano" <gitster@pobox.com>
> "Philip Oakley" <philipoakley@iee.org> writes:
>
>> micro-nit: 'first' and 'last' can be tricky to distinguish for lists...
>
> Let's do this then.
Looks good to me. Thanks. -- Philip
>
> -- >8 --
> From: Pranit Bauva <pranit.bauva@gmail.com>
> Date: Tue, 27 Sep 2016 20:44:09 +0000
> Subject: [PATCH] rev-list-options: clarify the usage of --reverse
>
> Users often wonder if the oldest or the newest n commits are shown
> by `log -n --reverse`. Clarify that --reverse kicks in only after
> deciding which commits are to be shown to unconfuse them.
>
> Reported-by: Ruediger Meier <sweet_f_a@gmx.de>
> Signed-off-by: Pranit Bauva <pranit.bauva@gmail.com>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
> Documentation/rev-list-options.txt | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/rev-list-options.txt
> b/Documentation/rev-list-options.txt
> index 4f009d4..f8946d4 100644
> --- a/Documentation/rev-list-options.txt
> +++ b/Documentation/rev-list-options.txt
> @@ -638,8 +638,9 @@ avoid showing the commits from two parallel
> development track mixed
> together.
>
> --reverse::
> - Output the commits in reverse order.
> - Cannot be combined with `--walk-reflogs`.
> + Output the commits chosen to be shown (see Commit Limiting
> + section above) in reverse order. Cannot be combined with
> + `--walk-reflogs`.
>
> Object Traversal
> ~~~~~~~~~~~~~~~~
> --
> 2.10.0-561-g98a6b79
>
>
^ permalink raw reply
* Re: [PATCH 1/2] ls-files: adding support for submodules
From: Junio C Hamano @ 2016-09-27 22:23 UTC (permalink / raw)
To: Brandon Williams; +Cc: Jeff King, git
In-Reply-To: <20160927220955.GA38615@google.com>
Brandon Williams <bmwill@google.com> writes:
>> If you are in a subdirectory of your superproject, say, a/,
>>
>> cd a && git ls-files --recurse-submodules -- "b*"
>>
>> I would expect we would recurse into the submodule at "a/b" and find
>> "b/file-at-top-of-B". What does the internal invocation to do so
>> would look like? I would think "git -C b --super=b ls-files" that
>> is run from "a".
Actually, the internal invocation may have to be
$ git --super=a/b ls-files -- "a/b*"
if the desired overall output needs to be in the "--full-name" mode.
That is, the top-level recursive one may be
cd a && git ls-files --recurse-submodules --full-name -- "b*"
This top-level "ls-files" will have "prefix" set to "a/". Because
it is run in the "--full-name" mode, after finding that the
submodule at "a/b" matches the given pathspec and deciding to
recurse into it, it needs to arrange that paths stored in the index
of the submodule are prefixed with "a/b/", not with "b/", when
shown.
^ permalink raw reply
* Re: thoughts on error passing, was Re: [PATCH 2/2] fsck: handle bad trees like other errors
From: David Turner @ 2016-09-27 22:57 UTC (permalink / raw)
To: Jeff King; +Cc: git, mhagger, David Turner
In-Reply-To: <20160927191955.mympqgylrxhkp24n@sigill.intra.peff.net>
On Tue, 2016-09-27 at 15:19 -0400, Jeff King wrote:
> On Tue, Sep 27, 2016 at 11:19:34AM -0400, David Turner wrote:
>
> > > typedef void (*err_fn)(const char *, ...);
> > >
> > > static int decode_tree_entry(struct tree_desc *desc,
> > > const char *buf, unsigned long size,
> > > err_fn err)
> > > {
> > > ...
> > > if (size < 23 || buf[size - 21]) {
> > > err("too-short tree object");
> > > return -1;
> > > }
> > > }
> > >
> > > I dunno. Maybe that is overengineering. I guess we only hit the strbufs
> > > in the error path (which used to die!), so nobody really cares that much
> > > about the extra allocation.
> >
> > I don't really like err_fn because:
> > (a) without a baton, it's somewhat less general (or less thread-safe)
> > than the strbuf approach and
> > (b) with a baton, it's two arguments instead of one.
>
> I'm going to ramble for a minute, and I don't think it's worth exploring
> for this patch series in particular, so feel free to ignore me.
>
> I think this error concept could be extended fairly elegantly with
> something like:
>
> typedef void (*err_fn)(void *, const char *fmt, va_list ap)
> struct error_context {
> err_fn fn;
> void *data;
> };
>
> int report_error(struct error_context *err, const char *fmt, ...)
> {
> if (err->fn) {
> va_list ap;
> va_start(ap, fmt);
> err->fn(err->data, fmt, ap);
> va_end(ap);
> }
> return -1;
> }
>
> Then low-level functions just take a context and do:
>
> return report_error(&err, "some error: %s", foo);
>
> And then the callers would pick one of a few generic error contexts:
>
> - passing NULL silences the errors
Overall, +1.
I guess I would rather have a sentinel value for silencing errors,
because I'm worried that someone might read NULL as "don't handle the
errors, just die". Of course, code review would hopefully catch this,
but even so, it would be easier to read foo(x, y, silence_errors) than
foo(x, y, null).
^ permalink raw reply
* Re: What's cooking in git.git (Sep 2016, #07; Fri, 23)
From: Junio C Hamano @ 2016-09-27 23:11 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.2.20.1609242101100.129229@virtualbox>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> In your previous kitchen status ("What's cooking") you hinted at a
> possible v2.10.1 soon. I have a couple of bugfixes lined up for Git for
> Windows and would like to avoid unnecessarily frequent release
> engineering... Any more concrete ideas on a date for this version?
I scanned RelNotes for 2.11 and identified these topics that we'd
want to have in 'maint'.
bw/pathspec-remove-unused-extern-decl # 1 (6 days ago)
rs/checkout-some-states-are-const # 1 (6 days ago)
rs/strbuf-remove-fix # 1 (6 days ago)
rs/unpack-trees-reduce-file-scope-global # 1 (6 days ago)
mr/vcs-svn-printf-ulong # 1 (6 days ago)
sy/git-gui-i18n-ja # 7 (12 days ago)
jk/fix-remote-curl-url-wo-proto # 1 (12 days ago)
js/git-gui-commit-gpgsign # 2 (12 days ago)
jk/patch-ids-no-merges # 2 (6 days ago)
ew/http-do-not-forget-to-call-curl-multi-remove-handle # 3 (6 days ago)
rs/xdiff-merge-overlapping-hunks-for-W-context # 1 (6 days ago)
ks/perf-build-with-autoconf # 1 (6 days ago)
jt/format-patch-base-info-above-sig # 1 (6 days ago)
jk/rebase-i-drop-ident-check # 1 (6 days ago)
jk/reduce-gc-aggressive-depth # 1 (6 days ago)
et/add-chmod-x # 1 (6 days ago)
tg/add-chmod+x-fix # 7 (24 hours ago)
Most are internal clean-ups that I do not mind leaving out, but I
think we want to have that "add --chmod=+x" fix in. As it hasn't
been enough time passed since the topic was merged to 'master', I'd
say either
(1) 2.10.1 with everything other than the last two in a few days
and 2.10.2 late next week with "add --chmod=+x" fix, or
(2) just a single 2.10.1 with everything late next week.
I can go either way and welcome suggestions. I'd start merging
older topics in the above list to 'maint' soonish, but not today.
Thanks.
^ permalink raw reply
* What's cooking in git.git (Sep 2016, #08; Tue, 27)
From: Junio C Hamano @ 2016-09-27 23:23 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
--------------------------------------------------
[Graduated to "master"]
* mh/diff-indent-heuristic (2016-09-19) 8 commits
(merged to 'next' on 2016-09-22 at e71d742)
+ blame: honor the diff heuristic options and config
+ parse-options: add parse_opt_unknown_cb()
+ diff: improve positioning of add/delete blocks in diffs
+ xdl_change_compact(): introduce the concept of a change group
+ recs_match(): take two xrecord_t pointers as arguments
+ is_blank_line(): take a single xrecord_t as argument
+ xdl_change_compact(): only use heuristic if group can't be matched
+ xdl_change_compact(): fix compaction heuristic to adjust ixo
Output from "git diff" can be made easier to read by selecting
which lines are common and which lines are added/deleted
intelligently when the lines before and after the changed section
are the same. A command line option is added to help with the
experiment to find a good heuristics.
* mh/diff-indent-heuristic (2016-09-27) 1 commit
- xdiff: rename "struct group" to "struct xdlgroup"
Clean-up for a recently graduated topic.
* rs/cocci (2016-09-15) 3 commits
(merged to 'next' on 2016-09-22 at aa54fa4)
+ use strbuf_addstr() for adding constant strings to a strbuf, part 2
+ add coccicheck make target
+ contrib/coccinelle: fix semantic patch for oid_to_hex_r()
Code cleanup.
* ep/doc-check-ref-format-example (2016-09-21) 1 commit
(merged to 'next' on 2016-09-22 at 6d0d79e)
+ git-check-ref-format.txt: fixup documentation
A shell script example in check-ref-format documentation has been
fixed.
* jk/clone-recursive-progress (2016-09-22) 1 commit
(merged to 'next' on 2016-09-22 at 8310c42)
+ clone: pass --progress decision to recursive submodules
"git clone --recurse-submodules" lost the progress eye-candy in
recent update, which has been corrected.
* jk/doc-cvs-update (2016-09-22) 3 commits
(merged to 'next' on 2016-09-22 at c0f949f)
+ docs/cvs-migration: mention cvsimport caveats
+ docs/cvs-migration: update link to cvsps homepage
+ docs/cvsimport: prefer cvs-fast-export to parsecvs
Documentation around tools to import from CVS was fairly outdated.
* js/regexec-buf (2016-09-21) 3 commits
(merged to 'next' on 2016-09-22 at 2ee2477)
+ regex: use regexec_buf()
+ regex: add regexec_buf() that can work on a non NUL-terminated string
+ regex: -G<pattern> feeds a non NUL-terminated string to regexec() and fails
Some codepaths in "git diff" used regexec(3) on a buffer that was
mmap(2)ed, which may not have a terminating NUL, leading to a read
beyond the end of the mapped region. This was fixed by introducing
a regexec_buf() helper that takes a <ptr,len> pair with REG_STARTEND
extension.
* jt/format-patch-rfc (2016-09-21) 1 commit
(merged to 'next' on 2016-09-22 at 3b39442)
+ format-patch: add "--rfc" for the common case of [RFC PATCH]
In some projects, it is common to use "[RFC PATCH]" as the subject
prefix for a patch meant for discussion rather than application. A
new option "--rfc" was a short-hand for "--subject-prefix=RFC PATCH"
to help the participants of such projects.
* ls/travis-homebrew-path-fix (2016-09-22) 1 commit
(merged to 'next' on 2016-09-22 at 310e620)
+ travis-ci: ask homebrew for its path instead of hardcoding it
The procedure to build Git on Mac OS X for Travis CI hardcoded the
internal directory structure we assumed HomeBrew uses, which was a
no-no. The procedure has been updated to ask HomeBrew things we
need to know to fix this.
* mm/config-color-ui-default-to-auto (2016-09-16) 1 commit
(merged to 'next' on 2016-09-22 at 4eac0cb)
+ Documentation/config: default for color.* is color.ui
Documentation for individual configuration variables to control use
of color (like `color.grep`) said that their default value is
'false', instead of saying their default is taken from `color.ui`.
When we updated the default value for color.ui from 'false' to
'auto' quite a while ago, all of them broke. This has been
corrected.
* nd/checkout-disambiguation (2016-09-21) 3 commits
(merged to 'next' on 2016-09-22 at ebfa365)
+ checkout: fix ambiguity check in subdir
+ checkout.txt: document a common case that ignores ambiguation rules
+ checkout: add some spaces between code and comment
"git checkout <word>" does not follow the usual disambiguation
rules when the <word> can be both a rev and a path, to allow
checking out a branch 'foo' in a project that happens to have a
file 'foo' in the working tree without having to disambiguate.
This was poorly documented and the check was incorrect when the
command was run from a subdirectory.
* rs/c-auto-resets-attributes (2016-09-19) 1 commit
(merged to 'next' on 2016-09-22 at 68f2e4a)
+ pretty: let %C(auto) reset all attributes
The pretty-format specifier "%C(auto)" used by the "log" family of
commands to enable coloring of the output is taught to also issue a
color-reset sequence to the output.
* rs/checkout-init-macro (2016-09-22) 1 commit
(merged to 'next' on 2016-09-22 at 6513755)
+ introduce CHECKOUT_INIT
Code cleanup.
* rt/rebase-i-broken-insn-advise (2016-09-07) 1 commit
(merged to 'next' on 2016-09-23 at 0d12484)
+ rebase -i: improve advice on bad instruction lines
When "git rebase -i" is given a broken instruction, it told the
user to fix it with "--edit-todo", but didn't say what the step
after that was (i.e. "--continue").
* tg/add-chmod+x-fix (2016-09-21) 6 commits
(merged to 'next' on 2016-09-22 at 6afdd21)
+ t3700-add: do not check working tree file mode without POSIXPERM
+ t3700-add: create subdirectory gently
+ add: modify already added files when --chmod is given
+ read-cache: introduce chmod_index_entry
+ update-index: add test for chmod flags
+ Merge branch 'ib/t3700-add-chmod-x-updates' into tg/add-chmod+x-fix
"git add --chmod=+x <pathspec>" added recently only toggled the
executable bit for paths that are either new or modified. This has
been corrected to flip the executable bit for all paths that match
the given pathspec.
* va/i18n-more (2016-09-21) 6 commits
(merged to 'next' on 2016-09-22 at bea26e8)
+ i18n: stash: mark messages for translation
+ i18n: notes-merge: mark die messages for translation
+ i18n: ident: mark hint for translation
+ i18n: i18n: diff: mark die messages for translation
+ i18n: connect: mark die messages for translation
+ i18n: commit: mark message for translation
Even more i18n.
--------------------------------------------------
[New Topics]
* mh/diff-indent-heuristic (2016-09-27) 1 commit
(merged to 'next' on 2016-09-27 at 3d6fb66)
+ xdiff: rename "struct group" to "struct xdlgroup"
Clean-up for a recently graduated topic.
Will merge to 'master'.
* rs/cocci (2016-09-27) 3 commits
- use strbuf_add_unique_abbrev() for adding short hashes, part 2
- use strbuf_addstr() instead of strbuf_addf() with "%s", part 2
- gitignore: ignore output files of coccicheck make target
Code clean-up with help from coccinelle tool continues.
Will merge to 'next'.
* jc/verify-loose-object-header (2016-09-26) 2 commits
(merged to 'next' on 2016-09-27 at 2947f95)
+ unpack_sha1_header(): detect malformed object header
+ streaming: make sure to notice corrupt object
Codepaths that read from an on-disk loose object were too loose in
validating what they are reading is a proper object file and
sometimes read past the data they read from the disk, which has
been corrected. H/t to Gustavo Grieco for reporting.
Will merge to 'master'.
* jk/ambiguous-short-object-names (2016-09-27) 11 commits
- get_short_sha1: make default disambiguation configurable
- get_short_sha1: list ambiguous objects on error
- for_each_abbrev: drop duplicate objects
- sha1_array: let callbacks interrupt iteration
- get_short_sha1: mark ambiguity error for translation
- get_short_sha1: NUL-terminate hex prefix
- get_short_sha1: refactor init of disambiguation code
- get_short_sha1: parse tags when looking for treeish
- get_sha1: propagate flags to child functions
- get_sha1: avoid repeating ourselves via ONLY_TO_DIE
- get_sha1: detect buggy calls with multiple disambiguators
When given an abbreviated object name that is not (or more
realistically, "no longer") unique, we gave a fatal error
"ambiguous argument". This error is now accompanied by hints that
lists the objects that begins with the given prefix. During the
course of development of this new feature, numerous minor bugs were
uncovered and corrected, the most notable one of which is that we
gave "short SHA1 xxxx is ambiguous." twice without good reason.
Will merge to 'next'.
* rs/copy-array (2016-09-25) 2 commits
(merged to 'next' on 2016-09-27 at c92e020)
+ use COPY_ARRAY
+ add COPY_ARRAY
Code cleanup.
Will merge to 'master'.
* rs/git-gui-use-modern-git-merge-syntax (2016-09-26) 2 commits
(merged to 'next' on 2016-09-27 at f55850d)
+ Merge branch 'rs/use-modern-git-merge-syntax' of git-gui into rs/git-gui-use-modern-git-merge-syntax
+ git-gui: stop using deprecated merge syntax
The original command line syntax for "git merge", which was "git
merge <msg> HEAD <parent>...", has been deprecated for quite some
time, and "git gui" was the last in-tree user of the syntax. This
is finally fixed, so that we can move forward with the deprecation.
Will merge to 'master'.
* va/git-gui-i18n (2016-09-26) 3 commits
(merged to 'next' on 2016-09-27 at ab0f66f)
+ Merge branch 'va/i18n' of ../git-gui into va/git-gui-i18n
+ git-gui: l10n: add Portuguese translation
+ git-gui i18n: mark strings for translation
"git gui" l10n to Portuguese.
Will merge to 'master'.
* va/i18n-perl-scripts (2016-09-25) 11 commits
- i18n: difftool: mark warnings 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 edit_hunk_manually message for translation
- i18n: add--interactive: i18n of help_patch_cmd
- i18n: add--interactive: mark message for translation
- i18n: add--interactive: mark plural strings
- 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
Porcelain scripts written in Perl are getting internationalized.
Waiting for a reroll.
cf. <1474913721.1035.9.camel@sapo.pt>
* vn/revision-shorthand-for-side-branch-log (2016-09-27) 1 commit
- revision: new rev^-n shorthand for rev^n..rev
"git log rev^..rev" is an often-used revision range specification
to show what was done on a side branch merged at rev, which has
gained a short-hand "rev^-1". In general "rev^-$n" is the same as
"^rev^$n rev", i.e. what was done while the history leading to nth
parent was looking the other way.
Will merge to 'next'.
* dt/mailinfo (2016-09-26) 1 commit
(merged to 'next' on 2016-09-27 at 59e95db)
+ add David Turner's Two Sigma address
Will merge to 'master'.
* dt/tree-fsck (2016-09-27) 2 commits
- fsck: handle bad trees like other errors
- tree-walk: be more specific about corrupt tree errors
The codepath in "git fsck" to detect malformed tree objects has
been updated not to die but keep going after detecting them.
Will merge to 'next'.
* jc/latin-1 (2016-09-26) 2 commits
- 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 merge to 'next'.
* jc/worktree-config (2016-09-27) 1 commit
- worktree: honor configuration variables
"git worktree", even though it used the default_abbrev setting that
ought to be affected by core.abbrev configuration variable, ignored
the variable setting. The command has been taught to read the
default set of configuration variables to correct this.
Will merge to 'next'.
* mg/gpg-richer-status (2016-09-27) 1 commit
- gpg-interface: use more status letters
The GPG verification status shown in "%G?" pretty format specifier
was not rich enough to differentiate a signature made by an expired
key, a signature made by a revoked key, etc. New output letters
have been assigned to express them.
Will merge to 'next'.
* pb/rev-list-reverse-with-count (2016-09-27) 1 commit
- rev-list-options: clarify the usage of --reverse
Doc update.
Will merge to 'next'.
--------------------------------------------------
[Stalled]
* 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.
* jc/attr (2016-05-25) 18 commits
- attr: support quoting pathname patterns in C style
- attr: expose validity check for attribute names
- attr: add counted string version of git_attr()
- 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
(this branch is used by jc/attr-more, sb/pathspec-label and sb/submodule-default-paths.)
The attributes API has been updated so that it can later be
optimized using the knowledge of which attributes are queried.
I wanted to polish this topic further to make the attribute
subsystem thread-ready, but because other topics depend on this
topic and they do not (yet) need it to be thread-ready.
As the authors of topics that depend on this seem not in a hurry,
let's discard this and dependent topics and restart them some other
day.
Will discard.
* jc/attr-more (2016-06-09) 8 commits
- 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
- fixup! d5ad6c13
- attr.c: pass struct git_attr_check down the callchain
- attr.c: add push_stack() helper
(this branch uses jc/attr; is tangled with sb/pathspec-label and sb/submodule-default-paths.)
The beginning of long and tortuous journey to clean-up attribute
subsystem implementation.
Needs to be redone.
Will discard.
* sb/submodule-default-paths (2016-06-20) 5 commits
- completion: clone can recurse into submodules
- clone: add --init-submodule=<pathspec> switch
- submodule update: add `--init-default-path` switch
- Merge branch 'sb/pathspec-label' into sb/submodule-default-paths
- Merge branch 'jc/attr' into sb/submodule-default-paths
(this branch uses jc/attr and sb/pathspec-label; is tangled with jc/attr-more.)
Allow specifying the set of submodules the user is interested in on
the command line of "git clone" that clones the superproject.
Will discard.
* sb/pathspec-label (2016-06-03) 6 commits
- pathspec: disable preload-index when attribute pathspec magic is in use
- 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
(this branch is used by sb/submodule-default-paths; uses jc/attr; is tangled with jc/attr-more.)
The pathspec mechanism learned ":(attr:X)$pattern" pathspec magic
to limit paths that match $pattern further by attribute settings.
The preload-index mechanism is disabled when the new pathspec magic
is in use (at least for now), because the attribute subsystem is
not thread-ready.
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.
* pb/bisect (2016-08-23) 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 `--check-and-set-terms` 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
. 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
GSoC "bisect" topic.
I'd prefer to see early part solidified so that reviews can focus
on the later part that is still in flux. We are almost there but
not quite yet.
* kn/ref-filter-branch-list (2016-05-17) 17 commits
- 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.
Needs review.
* sb/bisect (2016-04-15) 22 commits
. SQUASH???
. bisect: get back halfway shortcut
. bisect: compute best bisection in compute_relevant_weights()
. bisect: use a bottom-up traversal to find relevant weights
. bisect: prepare for different algorithms based on find_all
. bisect: rename count_distance() to compute_weight()
. bisect: make total number of commits global
. bisect: introduce distance_direction()
. bisect: extract get_distance() function from code duplication
. bisect: use commit instead of commit list as arguments when appropriate
. bisect: replace clear_distance() by unique markers
. bisect: use struct node_data array instead of int array
. bisect: get rid of recursion in count_distance()
. bisect: make algorithm behavior independent of DEBUG_BISECT
. bisect: make bisect compile if DEBUG_BISECT is set
. bisect: plug the biggest memory leak
. bisect: add test for the bisect algorithm
. t6030: generalize test to not rely on current implementation
. t: use test_cmp_rev() where appropriate
. t/test-lib-functions.sh: generalize test_cmp_rev
. bisect: allow 'bisect run' if no good commit is known
. bisect: write about `bisect next` in documentation
The internal algorithm used in "git bisect" to find the next commit
to check has been optimized greatly.
Was expecting a reroll, but now pb/bisect topic starts removinging
more and more parts from git-bisect.sh, this needs to see a fresh
reroll.
Will discard.
cf. <1460294354-7031-1-git-send-email-s-beyer@gmx.net>
* sg/completion-updates (2016-02-28) 21 commits
. completion: cache the path to the repository
. completion: extract repository discovery from __gitdir()
. completion: don't guard git executions with __gitdir()
. completion: consolidate silencing errors from git commands
. completion: don't use __gitdir() for git commands
. completion: respect 'git -C <path>'
. completion: fix completion after 'git -C <path>'
. completion: don't offer commands when 'git --opt' needs an argument
. rev-parse: add '--absolute-git-dir' option
. completion: list short refs from a remote given as a URL
. completion: don't list 'HEAD' when trying refs completion outside of a repo
. completion: list refs from remote when remote's name matches a directory
. completion: respect 'git --git-dir=<path>' when listing remote refs
. completion: fix most spots not respecting 'git --git-dir=<path>'
. completion: ensure that the repository path given on the command line exists
. completion tests: add tests for the __git_refs() helper function
. completion tests: check __gitdir()'s output in the error cases
. completion tests: consolidate getting path of current working directory
. completion tests: make the $cur variable local to the test helper functions
. completion tests: don't add test cruft to the test repository
. completion: improve __git_refs()'s in-code documentation
Has been waiting for a reroll for too long.
cf. <1456754714-25237-1-git-send-email-szeder@ira.uka.de>
Will discard.
* 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]
* jk/verify-packfile-gently (2016-09-22) 1 commit
(merged to 'next' on 2016-09-26 at f5abba5)
+ verify_packfile: check pack validity before accessing data
A low-level function verify_packfile() was meant to show errors
that were detected without dying itself, but under some conditions
it didn't and died instead, which has been fixed.
Will merge to 'master'.
* jt/fetch-pack-in-vain-count-with-stateless (2016-09-23) 1 commit
(merged to 'next' on 2016-09-26 at 9645629)
+ fetch-pack: do not reset in_vain on non-novel acks
When "git fetch" tries to find where the history of the repository
it runs inhas diverged from what the other side has, it has a
mechanism to avoid digging too deep into irrelevant side branches.
This however did not work well over the "smart-http" transport due
to a design bug, which has been fixed.
Will merge to 'master'.
* ik/gitweb-force-highlight (2016-09-25) 2 commits
(merged to 'next' on 2016-09-27 at cbb8391)
+ gitweb: use highlight's shebang detection
+ gitweb: remove unused guess_file_syntax() parameter
"gitweb" can spawn "highlight" to show blob contents with
(programming) language-specific syntax highlighting, but only
when the language is known. "highlight" can however be told
to make the guess itself by giving it "--force" option, which
has been enabled.
Will merge to 'master'.
* jk/ident-ai-canonname-could-be-null (2016-09-23) 1 commit
(merged to 'next' on 2016-09-26 at 0eefb29)
+ ident: handle NULL ai_canonname
In the codepath that comes up with the hostname to be used in an
e-mail when the user didn't tell us, we looked at ai_canonname
field in struct addrinfo without making sure it is not NULL first.
Will merge to 'master'.
* jc/blame-reverse (2016-06-14) 2 commits
(merged to 'next' on 2016-09-22 at d1a8e9c)
+ blame: dwim "blame --reverse OLD" as "blame --reverse OLD.."
+ blame: improve diagnosis for "--reverse NEW"
It is a common mistake to say "git blame --reverse OLD path",
expecting that the command line is dwimmed as if asking how lines
in path in an old revision OLD have survived up to the current
commit.
Will hold to see if it is broken.
* nd/init-core-worktree-in-multi-worktree-world (2016-09-25) 5 commits
(merged to 'next' on 2016-09-27 at 619f7f3)
+ init: kill git_link variable
+ init: do not set unnecessary core.worktree
+ init: kill set_git_dir_init()
+ init: call set_git_dir_init() from within init_db()
+ init: correct re-initialization from a linked worktree
"git init" tried to record core.worktree in the repository's
'config' file when GIT_WORK_TREE environment variable was set and
it was different from where GIT_DIR appears as ".git" at its top,
but the logic was faulty when .git is a "gitdir:" file that points
at the real place, causing trouble in working trees that are
managed by "git worktree". This has been corrected.
Will merge to 'master'.
* jt/mailinfo-fold-in-body-headers (2016-09-21) 3 commits
(merged to 'next' on 2016-09-26 at 4235eb6)
+ mailinfo: handle in-body header continuations
+ mailinfo: make is_scissors_line take plain char *
+ mailinfo: separate in-body header processing
When "git format-patch --stdout" output is placed as an in-body
header and it uses the RFC2822 header folding, "git am" failed to
put the header line back into a single logical line. The
underlying "git mailinfo" was taught to handle this properly.
Will merge to 'master'.
* kd/mailinfo-quoted-string (2016-09-26) 3 commits
- mailinfo: unescape quoted-pair in header fields
- SQUASH???
- t5100-mailinfo: replace common path prefix with variable
An e-mail author named that spelled a backslash-quoted double quote
in the human readable part "My \"double quoted\" name" was not
unquoted correctly.
Waiting for a reroll.
cf. <20160926194455.GB19089@ikke.info>
* js/libify-require-clean-work-tree (2016-09-12) 5 commits
- wt-status: teach has_{unstaged,uncommitted}_changes() about submodules
- Export also the has_un{staged,committed}_changed() functions
- Make the require_clean_work_tree() function truly reusable
- pull: make code more similar to the shell script again
- pull: drop confusing prefix parameter of die_on_unclean_work_tree()
The require_clean_work_tree() helper was recreated in C when "git
pull" was rewritten from shell; the helper is now made available to
other callers in preparation for upcoming "rebase -i" work.
Waiting for comments.
Modulo a few minor nits, this looked almost ready.
cf. <xmqqtwdl2bhm.fsf@gitster.mtv.corp.google.com>
cf. <xmqqpoo92bdr.fsf@gitster.mtv.corp.google.com>
* bw/ls-files-recurse-submodules (2016-09-21) 2 commits
- ls-files: add pathspec matching for submodules
- ls-files: optionally recurse into submodules
"git ls-files" learned "--recurse-submodules" option that can be
used to get a listing of tracked files across submodules (i.e. this
only works with "--cached" option, not for listing untracked or
ignored files). This would be a useful tool to sit on the upstream
side of a pipe that is read with xargs to work on all working tree
files from the top-level superproject.
Waiting for the discussion to conclude.
* ls/filter-process (2016-09-23) 11 commits
- convert: add filter.<driver>.process option
- convert: make apply_filter() adhere to standard Git error handling
- convert: modernize tests
- convert: quote filter names in error messages
- pkt-line: add functions to read/write flush terminated packet streams
- pkt-line: add packet_write_gently()
- pkt-line: add packet_flush_gently()
- pkt-line: add packet_write_fmt_gently()
- run-command: move check_pipe() from write_or_die to run_command
- pkt-line: extract set_packet_header()
- pkt-line: rename packet_write() to packet_write_fmt()
The smudge/clean filter API expect an external process is spawned
to filter the contents for each path that has a filter defined. A
new type of "process" filter API has been added to allow the first
request to run the filter for a path to spawn a single process, and
all filtering need is served by this single process for multiple
paths, reducing the process creation overhead.
* hv/submodule-not-yet-pushed-fix (2016-09-14) 2 commits
- 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.
The last two in the original series seem to break a few tests when
queued to 'pu', and dropped for now.
Waiting for a reroll.
* 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>
* cp/completion-negative-refs (2016-08-24) 1 commit
(merged to 'next' on 2016-09-22 at abd1585)
+ completion: support excluding refs
The command-line completion script (in contrib/) learned to
complete "git cmd ^mas<HT>" to complete the negative end of
reference to "git cmd ^master".
Will hold to see if it is broken.
* sb/push-make-submodule-check-the-default (2016-08-24) 1 commit
- push: change submodule default to check
Turn the default of "push.recurseSubmodules" to "check".
Will hold to wait for hv/submodule-not-yet-pushed-fix
This reveals that the "check" mode is too inefficient to use in
real projects, even in ones as small as git itself.
cf. <xmqqh9aaot49.fsf@gitster.mtv.corp.google.com>
* ak/curl-imap-send-explicit-scheme (2016-08-17) 1 commit
(merged to 'next' on 2016-09-22 at 4449584)
+ imap-send: Tell cURL to use imap:// or imaps://
When we started cURL to talk to imap server when a new enough
version of cURL library is available, we forgot to explicitly add
imap(s):// before the destination. To some folks, that didn't work
and the library tried to make HTTP(s) requests instead.
Will hold to see if it is broken.
* jk/pack-objects-optim-mru (2016-08-11) 4 commits
(merged to 'next' on 2016-09-21 at 97b919b)
+ pack-objects: use mru list when iterating over packs
+ pack-objects: break delta cycles before delta-search phase
+ sha1_file: make packed_object_info public
+ provide an initializer for "struct object_info"
Originally merged to 'next' on 2016-08-11
"git pack-objects" in a repository with many packfiles used to
spend a lot of time looking for/at objects in them; the accesses to
the packfiles are now optimized by checking the most-recently-used
packfile first.
Will hold to see if people scream.
* dp/autoconf-curl-ssl (2016-06-28) 1 commit
(merged to 'next' on 2016-09-22 at 9c5aeec)
+ ./configure.ac: detect SSL in libcurl using curl-config
The ./configure script generated from configure.ac was taught how
to detect support of SSL by libcurl better.
Will hold to see if it is broken.
* 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.
* ex/deprecate-empty-pathspec-as-match-all (2016-06-22) 1 commit
(merged to 'next' on 2016-09-21 at e19148e)
+ pathspec: warn on empty strings as pathspec
Originally merged to 'next' on 2016-07-13
An empty string used as a pathspec element has always meant
'everything matches', but it is too easy to write a script that
finds a path to remove in $path and run 'git rm "$paht"', which
ends up removing everything. Start warning about this use of an
empty string used for 'everything matches' and ask users to use a
more explicit '.' for that instead.
The hope is that existing users will not mind this change, and
eventually the warning can be turned into a hard error, upgrading
the deprecation into removal of this (mis)feature.
Will hold to see if people scream.
* nd/shallow-deepen (2016-06-13) 27 commits
(merged to 'next' on 2016-09-22 at f0cf3e3)
+ fetch, upload-pack: --deepen=N extends shallow boundary by N commits
+ upload-pack: add get_reachable_list()
+ upload-pack: split check_unreachable() in two, prep for get_reachable_list()
+ t5500, t5539: tests for shallow depth excluding a ref
+ clone: define shallow clone boundary with --shallow-exclude
+ fetch: define shallow boundary with --shallow-exclude
+ upload-pack: support define shallow boundary by excluding revisions
+ refs: add expand_ref()
+ t5500, t5539: tests for shallow depth since a specific date
+ clone: define shallow clone boundary based on time with --shallow-since
+ fetch: define shallow boundary with --shallow-since
+ upload-pack: add deepen-since to cut shallow repos based on time
+ shallow.c: implement a generic shallow boundary finder based on rev-list
+ fetch-pack: use a separate flag for fetch in deepening mode
+ fetch-pack.c: mark strings for translating
+ fetch-pack: use a common function for verbose printing
+ fetch-pack: use skip_prefix() instead of starts_with()
+ upload-pack: move rev-list code out of check_non_tip()
+ upload-pack: make check_non_tip() clean things up on error
+ upload-pack: tighten number parsing at "deepen" lines
+ upload-pack: use skip_prefix() instead of starts_with()
+ upload-pack: move "unshallow" sending code out of deepen()
+ upload-pack: remove unused variable "backup"
+ upload-pack: move "shallow" sending code out of deepen()
+ upload-pack: move shallow deepen code out of receive_needs()
+ transport-helper.c: refactor set_helper_option()
+ remote-curl.c: convert fetch_git() to use argv_array
The existing "git fetch --depth=<n>" option was hard to use
correctly when making the history of an existing shallow clone
deeper. A new option, "--deepen=<n>", has been added to make this
easier to use. "git clone" also learned "--shallow-since=<date>"
and "--shallow-exclude=<tag>" options to make it easier to specify
"I am interested only in the recent N months worth of history" and
"Give me only the history since that version".
Will hold to see if it is broken.
* jc/merge-drop-old-syntax (2015-04-29) 1 commit
- 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 hold to wait for rs/git-gui-use-modern-git-merge-syntax
--------------------------------------------------
[Discarded]
* jn/fix-connect-unexpected-hangup-diag (2016-09-08) 1 commit
. connect: tighten check for unexpected early hang up
Now part of jt/accept-capability-advertisement-when-fetching-from-void
topic.
^ 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