* Re: [PATCH] Documentation/bisect: improve on (bad|new) and (good|bad)
From: Christian Couder @ 2017-01-15 14:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Manuel Ullmann, Matthieu Moy, Christian Couder
In-Reply-To: <xmqqinpihiwz.fsf@gitster.mtv.corp.google.com>
On Fri, Jan 13, 2017 at 8:14 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Christian Couder <christian.couder@gmail.com> writes:
>
>> The following part of the description:
>>
>> git bisect (bad|new) [<rev>]
>> git bisect (good|old) [<rev>...]
>>
>> may be a bit confusing, as a reader may wonder if instead it should be:
>>
>> git bisect (bad|good) [<rev>]
>> git bisect (old|new) [<rev>...]
>>
>> Of course the difference between "[<rev>]" and "[<rev>...]" should hint
>> that there is a good reason for the way it is.
>>
>> But we can further clarify and complete the description by adding
>> "<term-new>" and "<term-old>" to the "bad|new" and "good|old"
>> alternatives.
>>
>> Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
>> ---
>> Documentation/git-bisect.txt | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> Thanks. The patch looks good.
>
> A related tangent.
>
> Last night, I was trying to think if there is a fundamental reason
> why "bad/new/term-new" cannot take more than one <rev>s on the newer
> side of the bisection, and couldn't quite think of any before
> falling asleep.
>
> Currently we keep track of a single bisect/bad, while marking all the
> revs given as good previously as bisect/good-<SHA-1>.
>
> Because the next "bad" is typically chosen from the region of the
> commit DAG that is bounded by bad and good commits, i.e. "rev-list
> bisect/bad --not bisect/good-*", the current bisect/bad will always
> be an ancestor of all bad commits that used to be bisect/bad, and
> keeping previous bisect/bad as bisect/bad-<SHA-1> won't change the
> region of the commit DAG yet to be explored.
>
> As a reason why we need to use only a single bisect/bad, the above
> description is understandable. But as a reason why we cannot have
> more than one, it is tautological. It merely says "if we start from
> only one and dig history to find older culprit, we need only one
> bad".
>
> I fell asleep last night without thinking further than that.
>
> I think the answer to the question "why do we think we need a single
> bisect/bad?" is "because bisection is about assuming that there is
> only one commit that flips the tree state from 'old' to 'new' and
> finding that single commit". That would mean that even if we had
> bisect/bad-A and bisect/bad-B, e.g.
>
> o---o---o---bad-A
> /
> -----Good---o---o---o
> \
> o---o---o---bad-B
>
>
> where 'o' are all commits whose goodness is not yet known, because
> bisection is valid only when we are hunting for a single commit that
> flips the state from good to bad, that commit MUST be at or before
> the merge base of bad-A and bad-B. So even if we allowed
>
> $ git bisect bad bad-A bad-B
>
> on the command line, we won't have to set bisect/bad-A and
> bisect/bad-B. We only need a single bisect/bad that points at the
> merge base of these two.
>
> But what if bad-A and bad-B have more than one merge bases? We
> won't know which side the badness came from.
>
> o---o---o---bad-A
> / \ /
> -----Good---o---o---o /
> \ / \
> o---o---o---bad-B
>
> Being able to bisect the region of DAG bound by "^Good bad-A bad-B"
> may have value in such a case. I dunno.
I agree that there could be improvements in this area. Though from my
experience with special cases, like when a good commit is not an
ancestor of the bad commit (where there are probably bugs still
lurking), I think it could be tricky to implement correctly in all
cases, and it could make it even more difficult, than it sometimes
already is, to explain the resulting behavior to users.
^ permalink raw reply
* Re: [PATCH 2/3] xdiff: -W: include immediately preceding non-empty lines in context
From: René Scharfe @ 2017-01-15 16:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Vegard Nossum, git
In-Reply-To: <xmqqy3ydcaia.fsf@gitster.mtv.corp.google.com>
Am 15.01.2017 um 03:39 schrieb Junio C Hamano:
> René Scharfe <l.s.r@web.de> writes:
>
>>> I am also more focused on keeping the codebase maintainable in good
>>> health by making sure that we made an effort to find a solution that
>>> is general-enough before solving a single specific problem you have
>>> today. We may end up deciding that a blank-line heuristics gives us
>>> good enough tradeoff, but I do not want us to make a decision before
>>> thinking.
>>
>> How about extending the context upward only up to and excluding a line
>> that is either empty *or* a function line? That would limit the extra
>> context to a single function in the worst case.
>>
>> Reducing context at the bottom with the aim to remove comments for the
>> next section is more tricky as it could remove part of the function
>> that we'd like to show if we get the boundary wrong. How bad would it
>> be to keep the southern border unchanged?
>
> I personally do not think there is any robust heuristic other than
> Vegard's "a blank line may be a signal enough that lines before that
> are not part of the beginning of the function", and I think your
> "hence we look for a blank line but if there is a line that matches
> the function header, stop there as we know we came too far back"
> will be a good-enough safety measure.
>
> I also agree with you that we probably do not want to futz with the
> southern border.
A replacement patch for 2/3 with these changes would look like this:
diff --git a/xdiff/xemit.c b/xdiff/xemit.c
index 8c88dbde38..9ed54cd318 100644
--- a/xdiff/xemit.c
+++ b/xdiff/xemit.c
@@ -174,11 +174,11 @@ int xdl_emit_diff(xdfenv_t *xe, xdchange_t *xscr, xdemitcb_t *ecb,
s2 = XDL_MAX(xch->i2 - xecfg->ctxlen, 0);
if (xecfg->flags & XDL_EMIT_FUNCCONTEXT) {
+ char dummy[1];
long fs1, i1 = xch->i1;
/* Appended chunk? */
if (i1 >= xe->xdf1.nrec) {
- char dummy[1];
long i2 = xch->i2;
/*
@@ -200,6 +200,10 @@ int xdl_emit_diff(xdfenv_t *xe, xdchange_t *xscr, xdemitcb_t *ecb,
}
fs1 = get_func_line(xe, xecfg, NULL, i1, -1);
+ while (fs1 > 0 && !is_empty_rec(&xe->xdf1, fs1 - 1) &&
+ match_func_rec(&xe->xdf1, xecfg, fs1 - 1,
+ dummy, sizeof(dummy)) < 0)
+ fs1--;
if (fs1 < 0)
fs1 = 0;
if (fs1 < s1) {
^ permalink raw reply related
* Re: [PATCH 2/3] xdiff: -W: include immediately preceding non-empty lines in context
From: René Scharfe @ 2017-01-15 16:57 UTC (permalink / raw)
To: Vegard Nossum, Junio C Hamano; +Cc: git
In-Reply-To: <0c761135-2696-4b3d-0a4f-3d90edf5da2e@oracle.com>
Am 15.01.2017 um 11:06 schrieb Vegard Nossum:
> On 15/01/2017 03:39, Junio C Hamano wrote:
>> René Scharfe <l.s.r@web.de> writes:
>>> How about extending the context upward only up to and excluding a line
>>> that is either empty *or* a function line? That would limit the extra
>>> context to a single function in the worst case.
>>>
>>> Reducing context at the bottom with the aim to remove comments for the
>>> next section is more tricky as it could remove part of the function
>>> that we'd like to show if we get the boundary wrong. How bad would it
>>> be to keep the southern border unchanged?
>>
>> I personally do not think there is any robust heuristic other than
>> Vegard's "a blank line may be a signal enough that lines before that
>> are not part of the beginning of the function", and I think your
>> "hence we look for a blank line but if there is a line that matches
>> the function header, stop there as we know we came too far back"
>> will be a good-enough safety measure.
>>
>> I also agree with you that we probably do not want to futz with the
>> southern border.
>
> You are right, trying to change the southern border in this way is not
> quite reliable if there are no empty lines whatsoever and can
> erroneously cause the function context to not include the bottom of the
> function being changed.
>
> I'm splitting the function boundary detection logic into separate
> functions and trying to solve the above case without breaking the tests
> (and adding a new test for the above case too).
>
> I'll see if I can additionally provide some toggles (flags or config
> variables) to control the new behaviour, what I had in mind was:
>
> -W[=preamble,=no-preamble]
> --function-context[=preamble,=no-preamble]
> diff.functionContextPreamble = <bool>
>
> (where the new logic is controlled by the new config variable and
> overridden by the presence of =preamble or =no-preamble).
Adding comments before a function is useful, removing comments after a
function sounds to me as only nice to have (under the assumption that
they belong to the next function[*]). How bad would it be to only
implement the first part (as in the patch I just sent) without adding
new config settings or parameters?
Thanks,
René
[*] Silly counter-example (the #endif line):
#ifdef SOMETHING
int f(...) {
// implementation for SOMETHING
}
#else
inf f(...) {
// implementation without SOMETHING
}
#endif /* SOMETHING */
^ permalink raw reply
* [PATCH] request-pull: drop old USAGE stuff
From: Wolfram Sang @ 2017-01-15 17:46 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Wolfram Sang
request-pull uses OPTIONS_SPEC, so no need for (meanwhile incomplete)
USAGE and LONG_USAGE anymore.
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
---
git-request-pull.sh | 3 ---
1 file changed, 3 deletions(-)
Index: git-2.11.0/git-request-pull.sh
===================================================================
--- git-2.11.0.orig/git-request-pull.sh
+++ git-2.11.0/git-request-pull.sh
@@ -4,9 +4,6 @@
# This file is licensed under the GPL v2, or a later version
# at the discretion of Linus Torvalds.
-USAGE='<start> <url> [<end>]'
-LONG_USAGE='Summarizes the changes between two commits to the standard output,
-and includes the given URL in the generated summary.'
SUBDIRECTORY_OK='Yes'
OPTIONS_KEEPDASHDASH=
OPTIONS_STUCKLONG=
^ permalink raw reply
* [RFC for GIT] pull-request: add praise to people doing QA
From: Wolfram Sang @ 2017-01-15 18:30 UTC (permalink / raw)
To: git, linux-kernel; +Cc: Wolfram Sang
Asking for opinions on lkml and git...
Getting enough quality assurance is likely one of the bigger upcoming tasks in
the near future. To improve the situation, praise the people already doing that
by adding their names to pull requests in the same manner that patch authors
are credited. Here is an example, I sent out today [1]:
=== old stuff
The following changes since commit a121103c922847ba5010819a3f250f1f7fc84ab8:
...
Vlad Tsyrklevich (1):
i2c: fix kernel memory disclosure in dev interface
=== new stuff starts here
with much appreciated quality assurance from
----------------------------------------------------------------
Andy Shevchenko (1):
(Rev.) i2c: piix4: Avoid race conditions with IMC
Benjamin Tissoires (1):
(Test) i2c: do not enable fall back to Host Notify by default
Vladimir Zapolskiy (1):
(Rev.) i2c: print correct device invalid address
=== diffstat, ...
This patch is a very early RFC to collect opinions. I am not very familiar with
the git codebase, but I guess using a filter needs to be reworked, the
dependency on GNU awk may be frowned upon (though 'asorti' is really useful
here), the reg-ex are not super-solid, and it should be a command-line option,
of course. That all being said, it was a fast way to produce what I would like
to add to my pull requests for the i2c subsystem and to see if other kernel/git
maintainers are interested in something like this.
Disclaimer: while this patch applies to the git codebase, I have to admit that
I simply patched around in /usr/lib/git-core of my Debian machine :)
So much for now, let me know what you think,
Wolfram
[1] http://lkml.org/lkml/2017/1/15/55
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
---
git-praise-qa.awk | 33 +++++++++++++++++++++++++++++++++
git-request-pull.sh | 1 +
2 files changed, 34 insertions(+)
Index: git-2.11.0/git-request-pull.sh
===================================================================
--- git-2.11.0.orig/git-request-pull.sh
+++ git-2.11.0/git-request-pull.sh
@@ -155,6 +155,7 @@ then
fi &&
git shortlog ^$baserev $headrev &&
+git log --no-merges ^$baserev $headrev | git-praise-qa.awk &&
git diff -M --stat --summary $patch $merge_base..$headrev || status=1
exit $status
Index: git-2.11.0/git-praise-qa.awk
===================================================================
--- /dev/null
+++ git-2.11.0/git-praise-qa.awk
@@ -0,0 +1,33 @@
+#! /usr/bin/gawk -f
+
+# New commit found, empty subject variable
+/^commit / { subject = "" }
+
+# Grab the subject line
+!subject && /^ / { subject = substr($0, 5); }
+
+# Scan for tags and get the type
+/^ Reviewed-by:/ { type = "Rev." }
+/^ Tested-by:/ { type = "Test" }
+
+type && subject {
+ # Extract the name
+ sub(/^.*: /, ""); sub(/ <.*/, ""); name = $0;
+ # Collect tags given by 'name'
+ tags[name] = tags[name] " (" type ") " subject "\n";
+ count[name]++;
+ # Done, clear flag
+ type = "";
+}
+
+END {
+ print "\nwith much appreciated quality assurance from"
+ print "----------------------------------------------------------------"
+ # Sort by names
+ asorti(tags, sorted_names);
+ # printout in git style
+ for (i in sorted_names) {
+ name = sorted_names[i];
+ print name " (" count[name] "):" "\n" tags[name];
+ }
+}
^ permalink raw reply
* [PATCH v5 0/7] Add --format to tag verification
From: santiago @ 2017-01-15 18:46 UTC (permalink / raw)
To: git; +Cc: gitster, peff, sunshine, walters, Santiago Torres
From: Santiago Torres <santiago@nyu.edu>
This is the fifth iteration of [1][2][3][4], and as a result of the
discussion in [5]. The main goal of this patch series is to bring
--format to git tag verification so that upper-layer tools can inspect
the content of a tag and make decisions based on it.
In this re-woll we:
* Squashed Peff's first patch[6] with the second patch of the series. The commit
message may need work.
* Applied the relevant segment's of Peff's second patch[7] on the rest of the
series
* Rebased so these patches apply to the tip of the master branch.
Thanks,
-Santiago
[1] http://public-inbox.org/git/20161007210721.20437-1-santiago@nyu.edu/
[2] http://public-inbox.org/git/20160930221806.3398-1-santiago@nyu.edu/
[3] http://public-inbox.org/git/20160922185317.349-1-santiago@nyu.edu/
[4] http://public-inbox.org/git/20160926224233.32702-1-santiago@nyu.edu/
[5] http://public-inbox.org/git/20160607195608.16643-1-santiago@nyu.edu/
[6] http://public-inbox.org/git/20161019203546.dfqmi2czcxopgj6w@sigill.intra.peff.net/
[7] http://public-inbox.org/git/20161019203943.epjxnfci7vcqg4xv@sigill.intra.peff.net/
Lukas Puehringer (4):
gpg-interface, tag: add GPG_VERIFY_QUIET flag
ref-filter: add function to print single ref_array_item
tag: add format specifier to gpg_verify_tag
builtin/tag: add --format argument for tag -v
Santiago Torres (3):
builtin/verify-tag: add --format to verify-tag
t/t7030-verify-tag: Add --format specifier tests
t/t7004-tag: Add --format specifier tests
Documentation/git-tag.txt | 2 +-
Documentation/git-verify-tag.txt | 2 +-
builtin/tag.c | 32 ++++++++++++++++++++++----------
builtin/verify-tag.c | 13 +++++++++++--
gpg-interface.h | 1 +
ref-filter.c | 27 +++++++++++++++++++++------
ref-filter.h | 7 +++++++
t/t7004-tag.sh | 16 ++++++++++++++++
t/t7030-verify-tag.sh | 16 ++++++++++++++++
tag.c | 22 +++++++++++++++-------
tag.h | 4 ++--
11 files changed, 113 insertions(+), 29 deletions(-)
--
2.11.0
^ permalink raw reply
* [PATCH v5 1/7] gpg-interface, tag: add GPG_VERIFY_QUIET flag
From: santiago @ 2017-01-15 18:46 UTC (permalink / raw)
To: git; +Cc: gitster, peff, sunshine, walters, Lukas Puehringer
In-Reply-To: <20170115184705.10376-1-santiago@nyu.edu>
From: Lukas Puehringer <luk.puehringer@gmail.com>
Functions that print git object information may require that the
gpg-interface functions be silent. Add GPG_VERIFY_QUIET flag and prevent
print_signature_buffer from being called if flag is set.
Signed-off-by: Lukas Puehringer <luk.puehringer@gmail.com>
---
gpg-interface.h | 1 +
tag.c | 5 ++++-
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/gpg-interface.h b/gpg-interface.h
index ea68885ad..85dc9820d 100644
--- a/gpg-interface.h
+++ b/gpg-interface.h
@@ -3,6 +3,7 @@
#define GPG_VERIFY_VERBOSE 1
#define GPG_VERIFY_RAW 2
+#define GPG_VERIFY_QUIET 4
struct signature_check {
char *payload;
diff --git a/tag.c b/tag.c
index d1dcd18cd..291073f6e 100644
--- a/tag.c
+++ b/tag.c
@@ -3,6 +3,7 @@
#include "commit.h"
#include "tree.h"
#include "blob.h"
+#include "gpg-interface.h"
const char *tag_type = "tag";
@@ -24,7 +25,9 @@ static int run_gpg_verify(const char *buf, unsigned long size, unsigned flags)
ret = check_signature(buf, payload_size, buf + payload_size,
size - payload_size, &sigc);
- print_signature_buffer(&sigc, flags);
+
+ if (!(flags & GPG_VERIFY_QUIET))
+ print_signature_buffer(&sigc, flags);
signature_check_clear(&sigc);
return ret;
--
2.11.0
^ permalink raw reply related
* [PATCH v5 2/7] ref-filter: add function to print single ref_array_item
From: santiago @ 2017-01-15 18:47 UTC (permalink / raw)
To: git; +Cc: gitster, peff, sunshine, walters, Lukas Puehringer
In-Reply-To: <20170115184705.10376-1-santiago@nyu.edu>
From: Lukas Puehringer <luk.puehringer@gmail.com>
ref-filter functions are useful for printing git object information
using a format specifier. However, some other modules may not want to use
this functionality on a ref-array but only print a single item.
Expose a pretty_print_ref function to create, pretty print and free
individual ref-items.
Signed-off-by: Lukas Puehringer <luk.puehringer@gmail.com>
---
ref-filter.c | 27 +++++++++++++++++++++------
ref-filter.h | 7 +++++++
2 files changed, 28 insertions(+), 6 deletions(-)
diff --git a/ref-filter.c b/ref-filter.c
index 1a978405e..5f4b08792 100644
--- a/ref-filter.c
+++ b/ref-filter.c
@@ -1361,7 +1361,7 @@ static struct ref_array_item *new_ref_array_item(const char *refname,
return ref;
}
-static int filter_ref_kind(struct ref_filter *filter, const char *refname)
+static int ref_kind_from_refname(const char *refname)
{
unsigned int i;
@@ -1374,11 +1374,7 @@ static int filter_ref_kind(struct ref_filter *filter, const char *refname)
{ "refs/tags/", FILTER_REFS_TAGS}
};
- if (filter->kind == FILTER_REFS_BRANCHES ||
- filter->kind == FILTER_REFS_REMOTES ||
- filter->kind == FILTER_REFS_TAGS)
- return filter->kind;
- else if (!strcmp(refname, "HEAD"))
+ if (!strcmp(refname, "HEAD"))
return FILTER_REFS_DETACHED_HEAD;
for (i = 0; i < ARRAY_SIZE(ref_kind); i++) {
@@ -1389,6 +1385,15 @@ static int filter_ref_kind(struct ref_filter *filter, const char *refname)
return FILTER_REFS_OTHERS;
}
+static int filter_ref_kind(struct ref_filter *filter, const char *refname)
+{
+ if (filter->kind == FILTER_REFS_BRANCHES ||
+ filter->kind == FILTER_REFS_REMOTES ||
+ filter->kind == FILTER_REFS_TAGS)
+ return filter->kind;
+ return ref_kind_from_refname(refname);
+}
+
/*
* A call-back given to for_each_ref(). Filter refs and keep them for
* later object processing.
@@ -1671,6 +1676,16 @@ void show_ref_array_item(struct ref_array_item *info, const char *format, int qu
putchar('\n');
}
+void pretty_print_ref(const char *name, const unsigned char *sha1,
+ const char *format)
+{
+ struct ref_array_item *ref_item;
+ ref_item = new_ref_array_item(name, sha1, 0);
+ ref_item->kind = ref_kind_from_refname(name);
+ show_ref_array_item(ref_item, format, 0);
+ free_array_item(ref_item);
+}
+
/* If no sorting option is given, use refname to sort as default */
struct ref_sorting *ref_default_sorting(void)
{
diff --git a/ref-filter.h b/ref-filter.h
index fc55fa357..7b05592ba 100644
--- a/ref-filter.h
+++ b/ref-filter.h
@@ -109,4 +109,11 @@ struct ref_sorting *ref_default_sorting(void);
/* Function to parse --merged and --no-merged options */
int parse_opt_merge_filter(const struct option *opt, const char *arg, int unset);
+/*
+ * Print a single ref, outside of any ref-filter. Note that the
+ * name must be a fully qualified refname.
+ */
+void pretty_print_ref(const char *name, const unsigned char *sha1,
+ const char *format);
+
#endif /* REF_FILTER_H */
--
2.11.0
^ permalink raw reply related
* [PATCH v5 7/7] t/t7004-tag: Add --format specifier tests
From: santiago @ 2017-01-15 18:47 UTC (permalink / raw)
To: git; +Cc: gitster, peff, sunshine, walters, Santiago Torres
In-Reply-To: <20170115184705.10376-1-santiago@nyu.edu>
From: Santiago Torres <santiago@nyu.edu>
tag -v now supports --format specifiers to inspect the contents of a tag
upon verification. Add two tests to ensure this behavior is respected in
future changes.
Signed-off-by: Santiago Torres <santiago@nyu.edu>
---
t/t7004-tag.sh | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/t/t7004-tag.sh b/t/t7004-tag.sh
index 07869b0c0..b2b81f203 100755
--- a/t/t7004-tag.sh
+++ b/t/t7004-tag.sh
@@ -874,6 +874,22 @@ test_expect_success GPG 'verifying a forged tag should fail' '
test_must_fail git tag -v forged-tag
'
+test_expect_success 'verifying a proper tag with --format pass and format accordingly' '
+ cat >expect <<-\EOF
+ tagname : signed-tag
+ EOF &&
+ git tag -v --format="tagname : %(tag)" "signed-tag" >actual &&
+ test_cmp expect actual
+'
+
+test_expect_success 'verifying a forged tag with --format fail and format accordingly' '
+ cat >expect <<-\EOF
+ tagname : forged-tag
+ EOF &&
+ test_must_fail git tag -v --format="tagname : %(tag)" "forged-tag" >actual &&
+ test_cmp expect actual
+'
+
# blank and empty messages for signed tags:
get_tag_header empty-signed-tag $commit commit $time >expect
--
2.11.0
^ permalink raw reply related
* [PATCH v5 6/7] t/t7030-verify-tag: Add --format specifier tests
From: santiago @ 2017-01-15 18:47 UTC (permalink / raw)
To: git; +Cc: gitster, peff, sunshine, walters, Santiago Torres
In-Reply-To: <20170115184705.10376-1-santiago@nyu.edu>
From: Santiago Torres <santiago@nyu.edu>
Verify-tag now provides --format specifiers to inspect and ensure the
contents of the tag are proper. We add two tests to ensure this
functionality works as expected: the return value should indicate if
verification passed, and the format specifiers must be respected.
Signed-off-by: Santiago Torres <santiago@nyu.edu>
---
t/t7030-verify-tag.sh | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/t/t7030-verify-tag.sh b/t/t7030-verify-tag.sh
index 07079a41c..d62ccbb98 100755
--- a/t/t7030-verify-tag.sh
+++ b/t/t7030-verify-tag.sh
@@ -125,4 +125,20 @@ test_expect_success GPG 'verify multiple tags' '
test_cmp expect.stderr actual.stderr
'
+test_expect_success 'verifying tag with --format' '
+ cat >expect <<-\EOF
+ tagname : fourth-signed
+ EOF &&
+ git verify-tag --format="tagname : %(tag)" "fourth-signed" >actual &&
+ test_cmp expect actual
+'
+
+test_expect_success 'verifying a forged tag with --format fail and format accordingly' '
+ cat >expect <<-\EOF
+ tagname : 7th forged-signed
+ EOF &&
+ test_must_fail git verify-tag --format="tagname : %(tag)" $(cat forged1.tag) >actual-forged &&
+ test_cmp expect actual-forged
+'
+
test_done
--
2.11.0
^ permalink raw reply related
* [PATCH v5 5/7] builtin/tag: add --format argument for tag -v
From: santiago @ 2017-01-15 18:47 UTC (permalink / raw)
To: git; +Cc: gitster, peff, sunshine, walters, Lukas Puehringer
In-Reply-To: <20170115184705.10376-1-santiago@nyu.edu>
From: Lukas Puehringer <luk.puehringer@gmail.com>
Adding --format to git tag -v mutes the default output of the GPG
verification and instead prints the formatted tag object.
This allows callers to cross-check the tagname from refs/tags with
the tagname from the tag object header upon GPG verification.
The callback function for for_each_tag_name() didn't allow callers to
pass custom data to their callback functions. Add a new opaque pointer
to each_tag_name_fn's parameter to allow this.
Signed-off-by: Lukas Puehringer <luk.puehringer@gmail.com>
---
Documentation/git-tag.txt | 2 +-
builtin/tag.c | 32 ++++++++++++++++++++++----------
2 files changed, 23 insertions(+), 11 deletions(-)
diff --git a/Documentation/git-tag.txt b/Documentation/git-tag.txt
index 76cfe40d9..586aaa315 100644
--- a/Documentation/git-tag.txt
+++ b/Documentation/git-tag.txt
@@ -15,7 +15,7 @@ SYNOPSIS
'git tag' [-n[<num>]] -l [--contains <commit>] [--points-at <object>]
[--column[=<options>] | --no-column] [--create-reflog] [--sort=<key>]
[--format=<format>] [--[no-]merged [<commit>]] [<pattern>...]
-'git tag' -v <tagname>...
+'git tag' -v [--format=<format>] <tagname>...
DESCRIPTION
-----------
diff --git a/builtin/tag.c b/builtin/tag.c
index 880677df5..9da11e0c2 100644
--- a/builtin/tag.c
+++ b/builtin/tag.c
@@ -24,7 +24,7 @@ static const char * const git_tag_usage[] = {
N_("git tag -d <tagname>..."),
N_("git tag -l [-n[<num>]] [--contains <commit>] [--points-at <object>]"
"\n\t\t[--format=<format>] [--[no-]merged [<commit>]] [<pattern>...]"),
- N_("git tag -v <tagname>..."),
+ N_("git tag -v [--format=<format>] <tagname>..."),
NULL
};
@@ -66,15 +66,17 @@ static int list_tags(struct ref_filter *filter, struct ref_sorting *sorting, con
}
typedef int (*each_tag_name_fn)(const char *name, const char *ref,
- const unsigned char *sha1);
+ const unsigned char *sha1, void *cb_data);
-static int for_each_tag_name(const char **argv, each_tag_name_fn fn)
+static int for_each_tag_name(const char **argv, each_tag_name_fn fn,
+ void *cb_data)
{
const char **p;
char ref[PATH_MAX];
int had_error = 0;
unsigned char sha1[20];
+
for (p = argv; *p; p++) {
if (snprintf(ref, sizeof(ref), "refs/tags/%s", *p)
>= sizeof(ref)) {
@@ -87,14 +89,14 @@ static int for_each_tag_name(const char **argv, each_tag_name_fn fn)
had_error = 1;
continue;
}
- if (fn(*p, ref, sha1))
+ if (fn(*p, ref, sha1, cb_data))
had_error = 1;
}
return had_error;
}
static int delete_tag(const char *name, const char *ref,
- const unsigned char *sha1)
+ const unsigned char *sha1, void *cb_data)
{
if (delete_ref(ref, sha1, 0))
return 1;
@@ -103,9 +105,16 @@ static int delete_tag(const char *name, const char *ref,
}
static int verify_tag(const char *name, const char *ref,
- const unsigned char *sha1)
+ const unsigned char *sha1, void *cb_data)
{
- return verify_and_format_tag(sha1, name, NULL, GPG_VERIFY_VERBOSE);
+ int flags;
+ char *fmt_pretty = cb_data;
+ flags = GPG_VERIFY_VERBOSE;
+
+ if (fmt_pretty)
+ flags = GPG_VERIFY_QUIET;
+
+ return verify_and_format_tag(sha1, ref, fmt_pretty, flags);
}
static int do_sign(struct strbuf *buffer)
@@ -428,9 +437,12 @@ int cmd_tag(int argc, const char **argv, const char *prefix)
if (filter.merge_commit)
die(_("--merged and --no-merged option are only allowed with -l"));
if (cmdmode == 'd')
- return for_each_tag_name(argv, delete_tag);
- if (cmdmode == 'v')
- return for_each_tag_name(argv, verify_tag);
+ return for_each_tag_name(argv, delete_tag, NULL);
+ if (cmdmode == 'v') {
+ if (format)
+ verify_ref_format(format);
+ return for_each_tag_name(argv, verify_tag, format);
+ }
if (msg.given || msgfile) {
if (msg.given && msgfile)
--
2.11.0
^ permalink raw reply related
* [PATCH v5 3/7] tag: add format specifier to gpg_verify_tag
From: santiago @ 2017-01-15 18:47 UTC (permalink / raw)
To: git; +Cc: gitster, peff, sunshine, walters, Lukas Puehringer
In-Reply-To: <20170115184705.10376-1-santiago@nyu.edu>
From: Lukas Puehringer <luk.puehringer@gmail.com>
Calling functions for gpg_verify_tag() may desire to print relevant
information about the header for further verification. Add an optional
format argument to print any desired information after GPG verification.
Signed-off-by: Lukas Puehringer <luk.puehringer@gmail.com>
---
builtin/tag.c | 2 +-
builtin/verify-tag.c | 2 +-
tag.c | 17 +++++++++++------
tag.h | 4 ++--
4 files changed, 15 insertions(+), 10 deletions(-)
diff --git a/builtin/tag.c b/builtin/tag.c
index 73df72811..880677df5 100644
--- a/builtin/tag.c
+++ b/builtin/tag.c
@@ -105,7 +105,7 @@ static int delete_tag(const char *name, const char *ref,
static int verify_tag(const char *name, const char *ref,
const unsigned char *sha1)
{
- return gpg_verify_tag(sha1, name, GPG_VERIFY_VERBOSE);
+ return verify_and_format_tag(sha1, name, NULL, GPG_VERIFY_VERBOSE);
}
static int do_sign(struct strbuf *buffer)
diff --git a/builtin/verify-tag.c b/builtin/verify-tag.c
index 99f8148cf..de10198c4 100644
--- a/builtin/verify-tag.c
+++ b/builtin/verify-tag.c
@@ -51,7 +51,7 @@ int cmd_verify_tag(int argc, const char **argv, const char *prefix)
const char *name = argv[i++];
if (get_sha1(name, sha1))
had_error = !!error("tag '%s' not found.", name);
- else if (gpg_verify_tag(sha1, name, flags))
+ else if (verify_and_format_tag(sha1, name, NULL, flags))
had_error = 1;
}
return had_error;
diff --git a/tag.c b/tag.c
index 291073f6e..d5a7cfb20 100644
--- a/tag.c
+++ b/tag.c
@@ -4,6 +4,7 @@
#include "tree.h"
#include "blob.h"
#include "gpg-interface.h"
+#include "ref-filter.h"
const char *tag_type = "tag";
@@ -33,8 +34,8 @@ static int run_gpg_verify(const char *buf, unsigned long size, unsigned flags)
return ret;
}
-int gpg_verify_tag(const unsigned char *sha1, const char *name_to_report,
- unsigned flags)
+int verify_and_format_tag(const unsigned char *sha1, const char *name,
+ const char *fmt_pretty, unsigned flags)
{
enum object_type type;
char *buf;
@@ -44,21 +45,25 @@ int gpg_verify_tag(const unsigned char *sha1, const char *name_to_report,
type = sha1_object_info(sha1, NULL);
if (type != OBJ_TAG)
return error("%s: cannot verify a non-tag object of type %s.",
- name_to_report ?
- name_to_report :
+ name ?
+ name :
find_unique_abbrev(sha1, DEFAULT_ABBREV),
typename(type));
buf = read_sha1_file(sha1, &type, &size);
if (!buf)
return error("%s: unable to read file.",
- name_to_report ?
- name_to_report :
+ name ?
+ name :
find_unique_abbrev(sha1, DEFAULT_ABBREV));
ret = run_gpg_verify(buf, size, flags);
free(buf);
+
+ if (fmt_pretty)
+ pretty_print_ref(name, sha1, fmt_pretty);
+
return ret;
}
diff --git a/tag.h b/tag.h
index a5721b673..896b9c2dc 100644
--- a/tag.h
+++ b/tag.h
@@ -17,7 +17,7 @@ extern int parse_tag_buffer(struct tag *item, const void *data, unsigned long si
extern int parse_tag(struct tag *item);
extern struct object *deref_tag(struct object *, const char *, int);
extern struct object *deref_tag_noverify(struct object *);
-extern int gpg_verify_tag(const unsigned char *sha1,
- const char *name_to_report, unsigned flags);
+extern int verify_and_format_tag(const unsigned char *sha1, const char *name,
+ const char *fmt_pretty, unsigned flags);
#endif /* TAG_H */
--
2.11.0
^ permalink raw reply related
* [PATCH v5 4/7] builtin/verify-tag: add --format to verify-tag
From: santiago @ 2017-01-15 18:47 UTC (permalink / raw)
To: git; +Cc: gitster, peff, sunshine, walters, Santiago Torres
In-Reply-To: <20170115184705.10376-1-santiago@nyu.edu>
From: Santiago Torres <santiago@nyu.edu>
Callers of verify-tag may want to cross-check the tagname from refs/tags
with the tagname from the tag object header upon GPG verification. This
is to avoid tag refs that point to an incorrect object.
Add a --format parameter to git verify-tag to print the formatted tag
object header in addition to or instead of the --verbose or --raw GPG
verification output.
Signed-off-by: Santiago Torres <santiago@nyu.edu>
---
Documentation/git-verify-tag.txt | 2 +-
builtin/verify-tag.c | 13 +++++++++++--
2 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-verify-tag.txt b/Documentation/git-verify-tag.txt
index d590edceb..0b8075dad 100644
--- a/Documentation/git-verify-tag.txt
+++ b/Documentation/git-verify-tag.txt
@@ -8,7 +8,7 @@ git-verify-tag - Check the GPG signature of tags
SYNOPSIS
--------
[verse]
-'git verify-tag' <tag>...
+'git verify-tag' [--format=<format>] <tag>...
DESCRIPTION
-----------
diff --git a/builtin/verify-tag.c b/builtin/verify-tag.c
index de10198c4..212449f47 100644
--- a/builtin/verify-tag.c
+++ b/builtin/verify-tag.c
@@ -12,12 +12,14 @@
#include <signal.h>
#include "parse-options.h"
#include "gpg-interface.h"
+#include "ref-filter.h"
static const char * const verify_tag_usage[] = {
- N_("git verify-tag [-v | --verbose] <tag>..."),
+ N_("git verify-tag [-v | --verbose] [--format=<format>] <tag>..."),
NULL
};
+
static int git_verify_tag_config(const char *var, const char *value, void *cb)
{
int status = git_gpg_config(var, value, cb);
@@ -30,9 +32,11 @@ int cmd_verify_tag(int argc, const char **argv, const char *prefix)
{
int i = 1, verbose = 0, had_error = 0;
unsigned flags = 0;
+ char *fmt_pretty = NULL;
const struct option verify_tag_options[] = {
OPT__VERBOSE(&verbose, N_("print tag contents")),
OPT_BIT(0, "raw", &flags, N_("print raw gpg status output"), GPG_VERIFY_RAW),
+ OPT_STRING( 0 , "format", &fmt_pretty, N_("format"), N_("format to use for the output")),
OPT_END()
};
@@ -46,12 +50,17 @@ int cmd_verify_tag(int argc, const char **argv, const char *prefix)
if (verbose)
flags |= GPG_VERIFY_VERBOSE;
+ if (fmt_pretty) {
+ verify_ref_format(fmt_pretty);
+ flags |= GPG_VERIFY_QUIET;
+ }
+
while (i < argc) {
unsigned char sha1[20];
const char *name = argv[i++];
if (get_sha1(name, sha1))
had_error = !!error("tag '%s' not found.", name);
- else if (verify_and_format_tag(sha1, name, NULL, flags))
+ else if (verify_and_format_tag(sha1, name, fmt_pretty, flags))
had_error = 1;
}
return had_error;
--
2.11.0
^ permalink raw reply related
* Re: submodule network operations [WAS: Re: [RFC/PATCH 0/4] working tree operations: support superprefix]
From: Brian J. Davis @ 2017-01-15 21:02 UTC (permalink / raw)
To: Stefan Beller; +Cc: Brandon Williams, git@vger.kernel.org, David Turner
In-Reply-To: <CAGZ79kZRV7x9B6SHRcHjJweHrjURxWKmN-=Wz_aNw2TPwYh_xw@mail.gmail.com>
On 1/13/2017 12:30 PM, Stefan Beller wrote:
> This question is about networking; the patch you originally replied to
> was strictly about local operations in the filesystem, which is quite
> a difference, so let's discuss it separately.
Yep ok look like you reclassified this and opened new topic which I hope
I am responding to correctly now.
> On Fri, Jan 13, 2017 at 9:56 AM, Brian J. Davis <bitminer@gmail.com> wrote:
>> In response to a post at:
>>
>> https://groups.google.com/forum/#!topic/git-users/BVLcKHhSUKo
>>
>> I was asked to post here to explain a potential problem with current modules
>> implementation. Apologies if I am posting in the wrong place... so good bad
>> or otherwise here goes:
>>
>> +-------------------------------
>> With:
>>
>> git push origin branchname
>>
>> or
>>
>> git push server2 branchname
>>
>> I can push or pull from multiple servers so no problem as git supports this.
>>
>> Now the problem with use of submodules
>>
>> submodules are listed:
>>
>> submodule.directory_to_
>> checkout/proj1_dir.url=https://git.someserver1/git/proj1_dir
>> <https://git.someserver1/git/proj1_dir>
> Technically it is submodule.<name>.url instead of
> submodule.<path>.url. The name is usually the path initially, and once
> you move the submodule, only the path changes, the name is supposed to
> be constant and stay the same.
I am not certain what is meant by this. All I know is I can use my
"directory_to_checkout" above to place in tree relative from root the
project any where in the tree not already tracked by git. You state
name instead of path, but it allows path correct? Either that or I have
gone off reservation with my use of git for years now. Maybe this is a
deviation from how it is documented/should work and how it actually
works? It works great how I use it.
>>
>> but if say I want to pull from some server 2 and do a
>>
>> git submodule update --init --recursive
> That is why the "git submodule init" exists at all.
>
> git submodule init
> $EDIT .git/config # change submodule.<name>.url to server2
> git submodule update # that uses the adapted url and
> # creates the submodule repository.
>
> # From now on the submodule is on its own.
> cd <submodule> && git config --list
> # prints an "origin" remote and a lot more
>
> For a better explanation, I started a documentation series, see
> https://github.com/gitster/git/commit/e2b51b9df618ceeff7c4ec044e20f5ce9a87241e
>
> (It is not finished, but that is supposed to explain this exact pain
> point in the
> STATES section, feel free to point out missing things or what is hard
> to understand)
I am not sure I got much out of the STATES section regarding my problem.
>> what I would get is from someserver1 not someserver2 as there is no "origin"
>> support for submodules. Is this correct? If so can origin support be added
>> to submodules?
> Can you explain more in detail what you mean by origin support?
Yes so when we do a:
git push origin master
origin is of course the Remote (Remotes
https://git-scm.com/book/en/v2/Git-Basics-Working-with-Remotes)
So I best use terminology "Remotes" support. Git push supports remotes,
but git submodules does not. The basic idea is this:
If Git allowed multiple submodule
(https://git-scm.com/book/en/v2/Git-Tools-Submodules) Remotes to be
specified say as an example:
git submodule add [remote] [url]
git submodule add origin https://github.com/chaconinc/DbConnector
git submodule add indhouse https://indhouse .corp/chaconinc/DbConnector
Where:
[submodule "DbConnector"]
path = DbConnector
url = https://github.com/chaconinc/DbConnector
Could then change to:
[submodule "DbConnector"]
path = DbConnector
remote.origin.url = https://github.com/chaconinc/DbConnector
remote.origin.url = https://indhouse .corp/chaconinc/DbConnector
Then it should be possible to get:
git submodules update --init --recursive
To support
git submodules update [remote] --init --recursive
And thus allow
git submodules update origin --init --recursive
git submodules update indhouse --init --recursive
>
>> +-------------------------------
>>
>> So above was post from google group. Maybe above is enough to explain the
>> problem that can result, but if not here is a discussion as to why this can
>> be confusing resulting to pushing or pulling from the incorrect server.
>>
>> Lets say projects starts at origin on https://server0.org. Project is then
>> brought in house to server https://indhouse.corp by developer A.
>>
>> Developer A then changes the submodule projects to point to indhouse and
>> changes submodules in super project to point to indhouse so everything is
>> great.
>>
>> Then Developer B clones from indhouse makes changes to submodule1 and
>> submodule1 and pushes them to indhouse. Dev A tells Dev B hey thoes changes
>> are great why don't you push to public server0 so every one can get thoes
>> changes. Dev B then git push origin branch_name on submodule1 and push
>> origin on submodule 2 and superproject. And everything is great ... right?
>>
>> Yes by now those who know git know what dev B forgot or more to the point
>> what git does not support in a "clean" way. For those who don't enter the
>> life of dev C
>>
>> So dev C clones from server0 and performs a git submodule update --init
>> --recursive. Now Dev C is on the www and can't see indhouse.corp and ...
>> kerpow... Dev B and Dev C just experienced one of the many SW mines on the
>> battlefield.
>>
>> I ask that git devs first see if I am correct with this assessment as I
>> could be wrong... maybe there is a way of doing this... and if not add a
>> feature to git to handle submodules and multiple origins cleanly.... and yes
>> beating dev B with rubber chicken might be a solution though I am looking
>> for a slightly better option.
> Yes this is a big point that we want to solve eventually.
>
> When devA brought it inhouse, what they meant to do was this:
> "This superproject is actually from server0, but we want to work on it, which
> may have submodules diverge from server0 eventually. So if a submodule changed
> you need to get it from the inhouse server, otherwise fall back to the server0".
>
> That way developerB can just make changes to some submodules and when
> devC clones
> they get the "correct" submodule.
>
> A weak attempt to do this is to use *relative* submodule urls. When
> using relative urls, and then mirroring the supeproject inhouse, then
> Git will look for the submodules as well inhouse, but there
> is no such "or if not found look at the original superprojects
> origin", which means, you have to mirror all submodules.
Yes I don't see how *relative* urls are a good solution.
> And then about upstreaming changes. If you have a single repo (no
> submodules), you have to teach people to run "git remote add remote
> server0.org && git push upstream ...", but that you can do for each
> submodule. (This is tedious:/ but maybe ok; some submodules are free
> to sent things upstream whereas others are supersecret that you do not
> want to push upstream ever.)
So right yes there are ways and means this can fail and not be
ultimately what the developer wants after all we all need to be aware of
the repercussion of the commands typed at the terminal. My goal here is
I notice a process that Git does not seem to handle well for a
distributed revision control system and thought it could use some
improvements. To your point on "supersecret" .... when pushing to
origin git could always be allowed to notify the developer of multi
remotes before pushing with a "freak-out" flag set by Dev A where git
would then ask:
git: are you sure [y/(n)] y
git: are you sure your sure [y/(n)] Y
git :you seem certain, but you might not be aware of the true
consequences of your actions... are you sure you are sure that your are
sure [Y/(N)] Y
git: ..... Ok committing... it's your fault if this goes pear shaped
sideways.
> So yeah maybe we want to have more power in the superprojects push operation
>
> (in the superproject) $ git push --recurse-submodules \
> --only-these-submodules=subA,subB \
> --submodule-to=upstream-as-configered-in-super-project
Sure ... Yes... plus "Remotes" support.
git push --recurse-submodules \
--only-these-submodules=subA,subB \
--submodule-to=upstream-as-configered-in-super-project
Allow:
git push [remote] --recurse-submodules \
--only-these-submodules=subA,subB \
--submodule-to=upstream-as-configered-in-super-project
git push indhouse --recurse-submodules \
--only-these-submodules=subA,subB \
--submodule-to=upstream-as-configered-in-super-project
and
git push origin --recurse-submodules \
--only-these-submodules=subA,subB \
--submodule-to=upstream-as-configered-in-super-project
> This is a lot of words but for explaining that is ok?
>
> Thanks,
> Stefan
Yep got it thanks.
^ permalink raw reply
* [PATCH v3 0/2] diff orderfile documentation improvements
From: Richard Hansen @ 2017-01-15 22:16 UTC (permalink / raw)
To: git; +Cc: gitster
In-Reply-To: <20170111015720.111223-1-hansenr@google.com>
Changes from v2:
* The orderfile feature doesn't set the WM_PATHNAME flag when it
calls wildmatch(), so document the pattern format accordingly.
Richard Hansen (2):
diff: document behavior of relative diff.orderFile
diff: document the format of the -O (diff.orderFile) file
Documentation/diff-config.txt | 7 ++++---
Documentation/diff-options.txt | 34 ++++++++++++++++++++++++++++++++--
2 files changed, 36 insertions(+), 5 deletions(-)
--
2.11.0.483.g087da7b7c-goog
^ permalink raw reply
* [PATCH v3 1/2] diff: document behavior of relative diff.orderFile
From: Richard Hansen @ 2017-01-15 22:16 UTC (permalink / raw)
To: git; +Cc: gitster
In-Reply-To: <20170115221631.78838-1-hansenr@google.com>
Document that a relative pathname for diff.orderFile is interpreted as
relative to the top-level work directory.
Signed-off-by: Richard Hansen <hansenr@google.com>
---
Documentation/diff-config.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/diff-config.txt b/Documentation/diff-config.txt
index 58f4bd6af..875212045 100644
--- a/Documentation/diff-config.txt
+++ b/Documentation/diff-config.txt
@@ -101,6 +101,8 @@ diff.noprefix::
diff.orderFile::
File indicating how to order files within a diff, using
one shell glob pattern per line.
+ If `diff.orderFile` is a relative pathname, it is treated as
+ relative to the top of the work tree.
Can be overridden by the '-O' option to linkgit:git-diff[1].
diff.renameLimit::
--
2.11.0.483.g087da7b7c-goog
^ permalink raw reply related
* [PATCH v3 2/2] diff: document the format of the -O (diff.orderFile) file
From: Richard Hansen @ 2017-01-15 22:16 UTC (permalink / raw)
To: git; +Cc: gitster
In-Reply-To: <20170115221631.78838-1-hansenr@google.com>
Signed-off-by: Richard Hansen <hansenr@google.com>
---
Documentation/diff-config.txt | 5 ++---
Documentation/diff-options.txt | 34 ++++++++++++++++++++++++++++++++--
2 files changed, 34 insertions(+), 5 deletions(-)
diff --git a/Documentation/diff-config.txt b/Documentation/diff-config.txt
index 875212045..9e4111320 100644
--- a/Documentation/diff-config.txt
+++ b/Documentation/diff-config.txt
@@ -99,11 +99,10 @@ diff.noprefix::
If set, 'git diff' does not show any source or destination prefix.
diff.orderFile::
- File indicating how to order files within a diff, using
- one shell glob pattern per line.
+ File indicating how to order files within a diff.
+ See the '-O' option to linkgit:git-diff[1] for details.
If `diff.orderFile` is a relative pathname, it is treated as
relative to the top of the work tree.
- Can be overridden by the '-O' option to linkgit:git-diff[1].
diff.renameLimit::
The number of files to consider when performing the copy/rename
diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
index e6215c372..d4fb70704 100644
--- a/Documentation/diff-options.txt
+++ b/Documentation/diff-options.txt
@@ -466,11 +466,41 @@ information.
endif::git-format-patch[]
-O<orderfile>::
- Output the patch in the order specified in the
- <orderfile>, which has one shell glob pattern per line.
+ Control the order in which files appear in the output.
This overrides the `diff.orderFile` configuration variable
(see linkgit:git-config[1]). To cancel `diff.orderFile`,
use `-O/dev/null`.
++
+The output order is determined by the order of glob patterns in
+<orderfile>.
+All files with pathnames that match the first pattern are output
+first, all files with pathnames that match the second pattern (but not
+the first) are output next, and so on.
+All files with pathnames that do not match any pattern are output
+last, as if there was an implicit match-all pattern at the end of the
+file.
+If multiple pathnames have the same rank (they match the same pattern
+but no earlier patterns), their output order relative to each other is
+the normal order.
++
+<orderfile> is parsed as follows:
++
+--
+ - Blank lines are ignored, so they can be used as separators for
+ readability.
+
+ - Lines starting with a hash ("`#`") are ignored, so they can be used
+ for comments. Add a backslash ("`\`") to the beginning of the
+ pattern if it starts with a hash.
+
+ - Each other line contains a single pattern.
+--
++
+Patterns have the same syntax and semantics as patterns used for
+fnmantch(3) without the FNM_PATHNAME flag, except a pathname also
+matches a pattern if removing any number of the final pathname
+components matches the pattern. For example, the pattern "`foo*bar`"
+matches "`fooasdfbar`" and "`foo/bar/baz/asdf`" but not "`foobarx`".
ifndef::git-format-patch[]
-R::
--
2.11.0.483.g087da7b7c-goog
^ permalink raw reply related
* Re: [PATCH 2/3] xdiff: -W: include immediately preceding non-empty lines in context
From: Junio C Hamano @ 2017-01-15 23:28 UTC (permalink / raw)
To: René Scharfe; +Cc: Vegard Nossum, git
In-Reply-To: <2668771d-249b-659d-3a2c-a788d7d5ebd6@web.de>
René Scharfe <l.s.r@web.de> writes:
> ... How bad would it be to only
> implement the first part (as in the patch I just sent) without adding
> new config settings or parameters?
That probably is a good place to stop ;-)
^ permalink raw reply
* Re: [PATCH 00/27] Revamp the attribute system; another round
From: Junio C Hamano @ 2017-01-15 23:47 UTC (permalink / raw)
To: Brandon Williams, Jeff King; +Cc: git, pclouds, sbeller
In-Reply-To: <20170112235354.153403-1-bmwill@google.com>
This one unfortunately clashes with jk/nofollow-attr-ignore where
Peff adds sanity to refuse following symbolic links when reading
.gitignore and .gitattributes; I'll eject jk/nofollow-attr-ignore
topic for now and see how well this topic fits together with the
remainder of the topics in flight.
Thanks.
^ permalink raw reply
* [RFC] stash --continue
From: Stephan Beyer @ 2017-01-15 23:56 UTC (permalink / raw)
To: git
Hi,
a git-newbie-ish co-worker uses git-stash sometimes. Last time he used
"git stash pop", he got into a merge conflict. After he resolved the
conflict, he did not know what to do to get the repository into the
wanted state. In his case, it was only "git add <resolved files>"
followed by a "git reset" and a "git stash drop", but there may be more
involved cases when your index is not clean before "git stash pop" and
you want to have your index as before.
This led to the idea to have something like "git stash --continue"[1]
that would expect the user to "git add" the resolved files (as "git
status" suggests) but then leads to the expected result, i.e. the index
being the same as before the conflict, the stash being dropped (if "pop"
was used instead of "apply"), etc.
Likewise, some "git stash --abort"[2] might be useful in case you did
"git stash pop" with the wrong stash in mind.
What do you think about that?
Although I think this would be a nice-to-have feature, I am not totally
sure how to achieve backwards-compatibility, i.e., such that using
--continue is still optional... (I think that "git stash apply" would
surely generate auxiliary data in case of a conflict and --continue or
--abort would remove it...)
Best
Stephan
Footnotes
1. Perhaps with a better name, because it does not really continue.
Maybe a "git stash conflict [--resolved]" subcommand?
2. Along the lines of [1], one could use "git stash conflict --abort"?
^ permalink raw reply
* Re: [RFC] stash: support filename argument
From: Junio C Hamano @ 2017-01-16 0:21 UTC (permalink / raw)
To: Thomas Gummerer; +Cc: git, kes-kes
In-Reply-To: <20170115142542.11999-1-t.gummerer@gmail.com>
Thomas Gummerer <t.gummerer@gmail.com> writes:
> While working on a repository, it's often helpful to stash the changes
> of a single or multiple files, and leave others alone. Unfortunately
> git currently offers no such option. git stash -p can be used to work
> around this, but it's often impractical when there are a lot of changes
> over multiple files.
>
> Add a --file option to git stash save, which allows for stashing a
> single file. Specifying the --file argument multiple times allows
> stashing more than one file at a time.
>
> Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
> ---
>
> Marked as RFC and without documentation updates to first get a feeling
> for the user interface, and whether people are interested in this
> change.
>
> Ideally I wanted the the user interface to look like something like:
> git stash save -- [<filename1,...>], but unfortunately that's already
> taken up by the stash message. So to preserve backward compatibility
> I used the new --file argument.
I haven't spent enough time to think if it even makes sense to
"stash" partially, leaving the working tree still dirty. My initial
reaction was "then stashing away the dirty WIP state to get a spiffy
clean working environment becomes impossible", and I still need time
to recover from that ;-) So as to the desirablity of this "feature",
I have no strong opinion for or against yet.
But if we were to do this, then we should bite the bullet and
declare that "stash save <message>" was a mistake. It should have
been "stash save -m <message>" and we should transition to that (one
easy way out would be to find another verb that is not 'save').
Then we can do "git stash save [-m <msg>] [--] [pathspec...]" which
follows the usual command line convention.
^ permalink raw reply
* Re: [PATCH] request-pull: drop old USAGE stuff
From: Junio C Hamano @ 2017-01-16 0:23 UTC (permalink / raw)
To: Wolfram Sang; +Cc: git
In-Reply-To: <20170115174635.2422-1-wsa@the-dreams.de>
Wolfram Sang <wsa@the-dreams.de> writes:
> request-pull uses OPTIONS_SPEC, so no need for (meanwhile incomplete)
> USAGE and LONG_USAGE anymore.
>
> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
> ---
Makes sense. These are not used anywhere after we switched to use
parse-options.
Thanks.
>
> git-request-pull.sh | 3 ---
> 1 file changed, 3 deletions(-)
>
> Index: git-2.11.0/git-request-pull.sh
> ===================================================================
> --- git-2.11.0.orig/git-request-pull.sh
> +++ git-2.11.0/git-request-pull.sh
> @@ -4,9 +4,6 @@
> # This file is licensed under the GPL v2, or a later version
> # at the discretion of Linus Torvalds.
>
> -USAGE='<start> <url> [<end>]'
> -LONG_USAGE='Summarizes the changes between two commits to the standard output,
> -and includes the given URL in the generated summary.'
> SUBDIRECTORY_OK='Yes'
> OPTIONS_KEEPDASHDASH=
> OPTIONS_STUCKLONG=
^ permalink raw reply
* Re: [RFC for GIT] pull-request: add praise to people doing QA
From: Junio C Hamano @ 2017-01-16 0:35 UTC (permalink / raw)
To: Wolfram Sang; +Cc: git, linux-kernel
In-Reply-To: <20170115183051.3565-1-wsa@the-dreams.de>
Wolfram Sang <wsa@the-dreams.de> writes:
> === new stuff starts here
>
> with much appreciated quality assurance from
> ----------------------------------------------------------------
> Andy Shevchenko (1):
> (Rev.) i2c: piix4: Avoid race conditions with IMC
>
> Benjamin Tissoires (1):
> (Test) i2c: do not enable fall back to Host Notify by default
>
> Vladimir Zapolskiy (1):
> (Rev.) i2c: print correct device invalid address
>
> === diffstat, ...
>
> This patch is a very early RFC to collect opinions. I am not very familiar with
> the git codebase, but I guess using a filter needs to be reworked, the
> dependency on GNU awk may be frowned upon (though 'asorti' is really useful
> here), the reg-ex are not super-solid, and it should be a command-line option,
> of course. That all being said, it was a fast way to produce what I would like
> to add to my pull requests for the i2c subsystem and to see if other kernel/git
> maintainers are interested in something like this.
>
> Disclaimer: while this patch applies to the git codebase, I have to admit that
> I simply patched around in /usr/lib/git-core of my Debian machine :)
>
> So much for now, let me know what you think,
So the idea is to have list of those whose names appear on
Reviewed-by: and Tested-by: collected and listed after the list of
commit titles and author names. I personally do not see much
downsides in doing so, but I do not consume that many PRs myself, so
let's hear from those who actually do process many of them.
As to the implementation, I am wondering if we can make this somehow
work well with the "trailers" code we already have, instead of
inventing yet another parser of trailers.
In its current shape, "interpret-trailers" focuses on "editing" an
existing commit log message to tweak the trailer lines. That mode
of operation would help amending and rebasing, and to do that it
needs to parse the commit log message, identify trailer blocks,
parse out each trailer lines, etc.
There is no fundamental reason why its output must be an edited
original commit log message---it should be usable as a filter that
picks trailer lines of the selected trailer type, like "Tested-By",
etc.
^ permalink raw reply
* Re: [RFC] stash: support filename argument
From: Stephan Beyer @ 2017-01-16 0:41 UTC (permalink / raw)
To: Junio C Hamano, Thomas Gummerer; +Cc: git, kes-kes
In-Reply-To: <xmqqvatfc0rt.fsf@gitster.mtv.corp.google.com>
Hi,
On 01/16/2017 01:21 AM, Junio C Hamano wrote:
> I haven't spent enough time to think if it even makes sense to
> "stash" partially, leaving the working tree still dirty. My initial
> reaction was "then stashing away the dirty WIP state to get a spiffy
> clean working environment becomes impossible", and I still need time
> to recover from that ;-) So as to the desirablity of this "feature",
> I have no strong opinion for or against yet.
I do remember that I simulated that feature a few times (either by
adding the to-be-keep stuff (hunks, not only files) to the index and use
--keep-index, and sometimes by making a temporary commit (to make sure
to not lose anything) and then stash). So I think there is a valid
desire of the feature.
However, going further, the next feature to be requested could be "git
stash --patch" ;D This leads me to think that the mentioned simulation
of partial stashes might be something everyone might come up with who
has basic understanding of git features and "git stash", and might be
the more flexible and probably better solution to the problem.
Best
Stephan
^ permalink raw reply
* What's cooking in git.git (Jan 2017, #02; Sun, 15)
From: Junio C Hamano @ 2017-01-16 1:51 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'. The ones marked with '.' do not appear in any of
the integration branches, but I am still holding onto them.
You can find the changes described here in the integration branches
of the repositories listed at
http://git-blame.blogspot.com/p/git-public-repositories.html
--------------------------------------------------
[New Topics]
* bw/read-blob-data-does-not-modify-index-state (2017-01-11) 1 commit
- index: improve constness for reading blob data
Code clean-up.
Will merge to 'next'.
* ep/commit-static-buf-cleanup (2017-01-13) 2 commits
- builtin/commit.c: switch to xstrfmt(), instead of snprintf()
- builtin/commit.c: remove the PATH_MAX limitation via dynamic allocation
Code clean-up.
Expecting a reroll.
The tip one would instead be done with strbuf.
cf. <CA+EOSB=4-TKpi6mr-yVbwRsFrVzE=vo4Y9Qm3VMm7pn=UB1_hQ@mail.gmail.com>
* jk/grep-e-could-be-extended-beyond-posix (2017-01-11) 1 commit
- t7810: avoid assumption about invalid regex syntax
Tighten a test to avoid mistaking an extended ERE regexp engine as
a PRE regexp engine.
Will merge to 'next'.
* jk/vreport-sanitize (2017-01-11) 2 commits
- vreport: sanitize ASCII control chars
- Revert "vreportf: avoid intermediate buffer"
An error message with an ASCII control character like '\r' in it
can alter the message to hide its early part, which is problematic
when a remote side gives such an error message that the local side
will relay with a "remote: " prefix.
Will merge to 'next'.
* sb/unpack-trees-super-prefix (2017-01-12) 5 commits
- SQUASH
- unpack-trees: support super-prefix option
- t1001: modernize style
- t1000: modernize style
- read-tree: use OPT_BOOL instead of OPT_SET_INT
"git read-tree" and its underlying unpack_trees() machinery learned
to report problematic paths prefixed with the --super-prefix option.
Expecting a reroll.
The first three are in good shape. The last one needs a better
explanation and possibly an update to its test.
cf. <CAGZ79kaHDnVLQr8WLoaD5KKs7EqeW=KbkptF=iHpU5t054Xcdw@mail.gmail.com>
* bw/grep-recurse-submodules (2016-12-22) 12 commits
(merged to 'next' on 2016-12-22 at 1ede815b8d)
+ grep: search history of moved submodules
+ grep: enable recurse-submodules to work on <tree> objects
+ grep: optionally recurse into submodules
+ grep: add submodules as a grep source type
+ submodules: load gitmodules file from commit sha1
+ submodules: add helper to determine if a submodule is initialized
+ submodules: add helper to determine if a submodule is populated
(merged to 'next' on 2016-12-22 at fea8fa870f)
+ real_path: canonicalize directory separators in root parts
+ real_path: have callers use real_pathdup and strbuf_realpath
+ real_path: create real_pathdup
+ real_path: convert real_path_internal to strbuf_realpath
+ real_path: resolve symlinks by hand
(this branch is tangled with bw/realpath-wo-chdir.)
"git grep" has been taught to optionally recurse into submodules.
Will merge to 'master'.
* sb/submodule-config-tests (2017-01-12) 2 commits
- t7411: test lookup of uninitialized submodules
- t7411: quote URLs
Will merge to 'next'.
* sb/submodule-doc (2017-01-12) 3 commits
- submodules: add a background story
- submodule update documentation: don't repeat ourselves
- submodule documentation: add options to the subcommand
Needs review.
* sb/submodule-embed-gitdir (2017-01-12) 1 commit
- submodule absorbgitdirs: mention in docstring help
Help-text fix.
Will merge to 'next'.
* sb/submodule-init (2017-01-12) 1 commit
- submodule update --init: display correct path from submodule
Error message fix.
Will merge to 'next'.
* vn/diff-ihc-config (2017-01-12) 1 commit
- diff: add interhunk context config option
"git diff" learned diff.interHunkContext configuration variable
that gives the default value for its --inter-hunk-context option.
Will merge to 'next'.
* ad/bisect-terms (2017-01-13) 1 commit
- Documentation/bisect: improve on (bad|new) and (good|bad)
Documentation fix.
Will merge to 'next'.
* bw/attr (2017-01-15) 27 commits
- attr: reformat git_attr_set_direction() function
- attr: push the bare repo check into read_attr()
- attr: store attribute stacks in hashmap
- attr: tighten const correctness with git_attr and match_attr
- attr: remove maybe-real, maybe-macro from git_attr
- attr: eliminate global check_all_attr array
- attr: use hashmap for attribute dictionary
- attr: change validity check for attribute names to use positive logic
- attr: pass struct attr_check to collect_some_attrs
- 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 attr_check"
- attr: (re)introduce git_check_attr() and struct attr_check
- attr: rename function and struct related to checking attributes
- attr.c: outline the future plans by heavily commenting
- Documentation/gitattributes.txt: fix a typo
- attr.c: add push_stack() helper
- attr: support quoting pathname patterns in C style
- attr.c: plug small leak in parse_attr_line()
- attr.c: tighten constness around "git_attr" structure
- attr.c: simplify macroexpand_one()
- attr.c: mark where #if DEBUG ends more clearly
- attr.c: complete a sentence in a comment
- attr.c: explain the lack of attr-name syntax check in parse_attr()
- attr.c: update a stale comment on "struct match_attr"
- attr.c: use strchrnul() to scan for one line
- commit.c: use strchrnul() to scan for one line
The gitattributes machinery is being taught to work better in a
multi-threaded environment.
Needs review.
* jk/loose-object-fsck (2017-01-15) 6 commits
- fsck: detect trailing garbage in all object types
- fsck: parse loose object paths directly
- sha1_file: add read_loose_object() function
- t1450: test fsck of packed objects
- sha1_file: fix error message for alternate objects
- t1450: refactor loose-object removal
"git fsck" inspects loose objects more carefully now.
Needs review.
* rh/diff-orderfile-doc (2017-01-15) 2 commits
- diff: document the format of the -O (diff.orderFile) file
- diff: document behavior of relative diff.orderFile
Documentation fix.
Will merge to 'next'.
* sb/cd-then-git-can-be-written-as-git-c (2017-01-13) 1 commit
- lib-submodule-update.sh: reduce use of subshell by using "git -C"
Test clean-up.
Will merge to 'next'.
* vn/xdiff-func-context (2017-01-15) 1 commit
- xdiff -W: relax end-of-file function detection
"git diff -W" has been taught to handle the case where a new
function is added at the end of the file better.
Will hold.
An follow-up change to go back from the line that matches the
funcline to show comments before the function definition is still
being discussed.
* ws/request-pull-code-cleanup (2017-01-15) 1 commit
- request-pull: drop old USAGE stuff
Code clean-up.
Will merge to 'next'.
--------------------------------------------------
[Stalled]
* jk/nofollow-attr-ignore (2016-11-02) 5 commits
. exclude: do not respect symlinks for in-tree .gitignore
. attr: do not respect symlinks for in-tree .gitattributes
. exclude: convert "check_index" into a flags field
. attr: convert "macro_ok" into a flags field
. add open_nofollow() helper
As we do not follow symbolic links when reading control files like
.gitignore and .gitattributes from the index, match the behaviour
and not follow symbolic links when reading them from the working
tree. This also tightens security a bit by not leaking contents of
an unrelated file in the error messages when it is pointed at by
one of these files that is a symbolic link.
Perhaps we want to cover .gitmodules too with the same mechanism?
Ejected for now.
* 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/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]
* ls/p4-retry-thrice (2016-12-29) 1 commit
(merged to 'next' on 2017-01-10 at c733e27410)
+ git-p4: do not pass '-r 0' to p4 commands
A recent updates to "git p4" was not usable for older p4 but it
could be made to work with minimum changes. Do so.
Will merge to 'master'.
* mh/ref-remove-empty-directory (2017-01-07) 23 commits
- files_transaction_commit(): clean up empty directories
- try_remove_empty_parents(): teach to remove parents of reflogs, too
- try_remove_empty_parents(): don't trash argument contents
- try_remove_empty_parents(): rename parameter "name" -> "refname"
- delete_ref_loose(): inline function
- delete_ref_loose(): derive loose reference path from lock
- log_ref_write_1(): inline function
- log_ref_setup(): manage the name of the reflog file internally
- log_ref_write_1(): don't depend on logfile argument
- log_ref_setup(): pass the open file descriptor back to the caller
- log_ref_setup(): improve robustness against races
- log_ref_setup(): separate code for create vs non-create
- log_ref_write(): inline function
- rename_tmp_log(): improve error reporting
- rename_tmp_log(): use raceproof_create_file()
- lock_ref_sha1_basic(): use raceproof_create_file()
- lock_ref_sha1_basic(): inline constant
- raceproof_create_file(): new function
- safe_create_leading_directories(): set errno on SCLD_EXISTS
- safe_create_leading_directories_const(): preserve errno
- t5505: use "for-each-ref" to test for the non-existence of references
- refname_is_safe(): correct docstring
- files_rename_ref(): tidy up whitespace
Deletion of a branch "foo/bar" could remove .git/refs/heads/foo
once there no longer is any other branch whose name begins with
"foo/", but we didn't do so so far. Now we do.
Expecting a reroll.
cf. <5051c78e-51f9-becd-e1a6-9c0b781d6912@alum.mit.edu>
* pb/test-must-fail-is-for-git (2017-01-09) 2 commits
(merged to 'next' on 2017-01-10 at 5f24a98779)
+ t9813: avoid using pipes
+ don't use test_must_fail with grep
Test cleanup.
Will merge to 'master'.
* jk/archive-zip-userdiff-config (2017-01-07) 1 commit
(merged to 'next' on 2017-01-10 at ac42e4958c)
+ archive-zip: load userdiff config
"git archive" did not read the standard configuration files, and
failed to notice a file that is marked as binary via the userdiff
driver configuration.
Will merge to 'master'.
* jk/blame-fixes (2017-01-07) 3 commits
(merged to 'next' on 2017-01-10 at 18f909da61)
+ blame: output porcelain "previous" header for each file
+ blame: handle --no-abbrev
+ blame: fix alignment with --abbrev=40
"git blame --porcelain" misidentified the "previous" <commit, path>
pair (aka "source") when contents came from two or more files.
Will merge to 'master'.
* jk/rebase-i-squash-count-fix (2017-01-07) 1 commit
(merged to 'next' on 2017-01-10 at d6cfc6ace2)
+ rebase--interactive: count squash commits above 10 correctly
"git rebase -i" with a recent update started showing an incorrect
count when squashing more than 10 commits.
Will merge to 'master'.
* js/asciidoctor-tweaks (2017-01-13) 2 commits
(merged to 'next' on 2017-01-15 at 8553c6e513)
+ asciidoctor: fix user-manual to be built by `asciidoctor`
(merged to 'next' on 2017-01-10 at 087da7b7c1)
+ giteveryday: unbreak rendering with AsciiDoctor
Adjust documentation to help AsciiDoctor render better while not
breaking the rendering done by AsciiDoc.
Will merge to 'master'.
* km/branch-get-push-while-detached (2017-01-07) 1 commit
(merged to 'next' on 2017-01-10 at a7f8af8c55)
+ branch_get_push: do not segfault when HEAD is detached
"git <cmd> @{push}" on a detached HEAD used to segfault; it has
been corrected to error out with a message.
Will merge to 'master'.
* sb/remove-gitview (2017-01-13) 4 commits
(merged to 'next' on 2017-01-15 at 7c9eae479e)
+ doc: git-gui browser does not default to HEAD
+ doc: gitk: add the upstream repo location
+ doc: gitk: remove gitview reference
(merged to 'next' on 2017-01-10 at dcb3abd146)
+ contrib: remove gitview
Will merge to 'master'.
* sb/submodule-cleanup-export-git-dir-env (2017-01-07) 1 commit
(merged to 'next' on 2017-01-10 at 2d5db6821e)
+ submodule.c: use GIT_DIR_ENVIRONMENT consistently
Code cleanup.
Will merge to 'master'.
* sb/pathspec-errors (2017-01-09) 1 commit
(merged to 'next' on 2017-01-10 at 432375cb62)
+ pathspec: give better message for submodule related pathspec error
(this branch uses bw/pathspec-cleanup.)
Running "git add a/b" when "a" is a submodule correctly errored
out, but without a meaningful error message.
Will merge to 'master'.
* ls/filter-process-delayed (2017-01-08) 1 commit
. convert: add "status=delayed" to filter process protocol
Ejected, as does not build when merged to 'pu'.
* sp/cygwin-build-fixes (2017-01-09) 2 commits
(merged to 'next' on 2017-01-10 at 2010fb6c03)
+ Makefile: put LIBS after LDFLAGS for imap-send
+ Makefile: POSIX windres
Build updates for Cygwin.
Will merge to 'master'.
* jk/execv-dashed-external (2017-01-09) 3 commits
(merged to 'next' on 2017-01-10 at 117b506cb0)
+ execv_dashed_external: wait for child on signal death
+ execv_dashed_external: stop exiting with negative code
+ execv_dashed_external: use child_process struct
Typing ^C to pager, which usually does not kill it, killed Git and
took the pager down as a collateral damage in certain process-tree
structure. This has been fixed.
Will merge to 'master'.
* rh/mergetool-regression-fix (2017-01-10) 14 commits
(merged to 'next' on 2017-01-10 at e8e00c798b)
+ mergetool: fix running in subdir when rerere enabled
+ mergetool: take the "-O" out of $orderfile
+ t7610: add test case for rerere+mergetool+subdir bug
+ t7610: spell 'git reset --hard' consistently
+ t7610: don't assume the checked-out commit
+ t7610: always work on a test-specific branch
+ t7610: delete some now-unnecessary 'git reset --hard' lines
+ t7610: run 'git reset --hard' after each test to clean up
+ t7610: don't rely on state from previous test
+ t7610: use test_when_finished for cleanup tasks
+ t7610: move setup code to the 'setup' test case
+ t7610: update branch names to match test number
+ rev-parse doc: pass "--" to rev-parse in the --prefix example
+ .mailmap: record canonical email for Richard Hansen
"git mergetool" without any pathspec on the command line that is
run from a subdirectory became no-op in Git v2.11 by mistake, which
has been fixed.
Will merge to 'master'.
* sb/unpack-trees-cleanup (2017-01-10) 3 commits
(merged to 'next' on 2017-01-10 at 95a5f3127c)
+ unpack-trees: factor progress setup out of check_updates
+ unpack-trees: remove unneeded continue
+ unpack-trees: move checkout state into check_updates
Code cleanup.
Will merge to 'master'.
* nd/worktree-move (2017-01-09) 6 commits
- worktree remove: new command
- worktree move: refuse to move worktrees with submodules
- worktree move: accept destination as directory
- worktree move: new command
- worktree.c: add update_worktree_location()
- worktree.c: add validate_worktree()
"git worktree" learned move and remove subcommands.
* dt/disable-bitmap-in-auto-gc (2016-12-29) 2 commits
(merged to 'next' on 2017-01-10 at 9f4e89e15d)
+ repack: die on incremental + write-bitmap-index
+ auto gc: don't write bitmaps for incremental repacks
It is natural that "git gc --auto" may not attempt to pack
everything into a single pack, and there is no point in warning
when the user has configured the system to use the pack bitmap,
leading to disabling further "gc".
Will merge to 'master'.
* js/mingw-test-push-unc-path (2017-01-07) 1 commit
(merged to 'next' on 2017-01-10 at 249d9f26f3)
+ mingw: add a regression test for pushing to UNC paths
"git push \\server\share\dir" has recently regressed and then
fixed. A test has retroactively been added for this breakage.
Will merge to 'master'.
* nd/log-graph-configurable-colors (2017-01-08) 1 commit
- log --graph: customize the graph lines with config log.graphColors
Some people feel the default set of colors used by "git log --graph"
rather limiting. A mechanism to customize the set of colors has
been introduced.
Waiting for review comments to be addressed.
cf. <20170109103258.25341-1-pclouds@gmail.com>
* sb/submodule-rm-absorb (2016-12-27) 4 commits
(merged to 'next' on 2017-01-10 at 1fc2000a92)
+ rm: absorb a submodules git dir before deletion
+ submodule: rename and add flags to ok_to_remove_submodule
+ submodule: modernize ok_to_remove_submodule to use argv_array
+ submodule.h: add extern keyword to functions
"git rm" used to refuse to remove a submodule when it has its own
git repository embedded in its working tree. It learned to move
the repository away to $GIT_DIR/modules/ of the superproject
instead, and allow the submodule to be deleted (as long as there
will be no loss of local modifications, that is).
Will merge to 'master'.
* cc/split-index-config (2016-12-26) 21 commits
- Documentation/git-update-index: explain splitIndex.*
- Documentation/config: add splitIndex.sharedIndexExpire
- read-cache: use freshen_shared_index() in read_index_from()
- read-cache: refactor read_index_from()
- t1700: test shared index file expiration
- read-cache: unlink old sharedindex files
- config: add git_config_get_expiry() from gc.c
- read-cache: touch shared index files when used
- sha1_file: make check_and_freshen_file() non static
- Documentation/config: add splitIndex.maxPercentChange
- t1700: add tests for splitIndex.maxPercentChange
- read-cache: regenerate shared index if necessary
- config: add git_config_get_max_percent_split_change()
- Documentation/git-update-index: talk about core.splitIndex config var
- Documentation/config: add information for core.splitIndex
- t1700: add tests for core.splitIndex
- update-index: warn in case of split-index incoherency
- read-cache: add and then use tweak_split_index()
- split-index: add {add,remove}_split_index() functions
- config: add git_config_get_split_index()
- config: mark an error message up for translation
The experimental "split index" feature has gained a few
configuration variables to make it easier to use.
Waiting for review comments to be addressed.
cf. <20161226102222.17150-1-chriscool@tuxfamily.org>
cf. <a1a44640-ff6c-2294-72ac-46322eff8505@ramsayjones.plus.com>
* bw/push-submodule-only (2016-12-20) 3 commits
- push: add option to push only submodules
- submodules: add RECURSE_SUBMODULES_ONLY value
- transport: reformat flag #defines to be more readable
"git submodule push" learned "--recurse-submodules=only option to
push submodules out without pushing the top-level superproject.
* ls/p4-path-encoding (2016-12-18) 1 commit
- git-p4: fix git-p4.pathEncoding for removed files
When "git p4" imports changelist that removes paths, it failed to
convert pathnames when the p4 used encoding different from the one
used on the Git side. This has been corrected.
Will be rerolled.
cf. <7E1C7387-4F37-423F-803D-3B5690B49D40@gmail.com>
* bw/pathspec-cleanup (2017-01-08) 16 commits
(merged to 'next' on 2017-01-10 at 79291ff506)
+ pathspec: rename prefix_pathspec to init_pathspec_item
+ pathspec: small readability changes
+ pathspec: create strip submodule slash helpers
+ pathspec: create parse_element_magic helper
+ pathspec: create parse_long_magic function
+ pathspec: create parse_short_magic function
+ pathspec: factor global magic into its own function
+ pathspec: simpler logic to prefix original pathspec elements
+ pathspec: always show mnemonic and name in unsupported_magic
+ pathspec: remove unused variable from unsupported_magic
+ pathspec: copy and free owned memory
+ pathspec: remove the deprecated get_pathspec function
+ ls-tree: convert show_recursive to use the pathspec struct interface
+ dir: convert fill_directory to use the pathspec struct interface
+ dir: remove struct path_simplify
+ mv: remove use of deprecated 'get_pathspec()'
(this branch is used by sb/pathspec-errors.)
Code clean-up in the pathspec API.
Will merge to 'master'.
* js/prepare-sequencer-more (2017-01-09) 38 commits
- sequencer (rebase -i): write out the final message
- sequencer (rebase -i): write the progress into files
- sequencer (rebase -i): show the progress
- sequencer (rebase -i): suggest --edit-todo upon unknown command
- sequencer (rebase -i): show only failed cherry-picks' output
- sequencer (rebase -i): show only failed `git commit`'s output
- sequencer: use run_command() directly
- sequencer: make reading author-script more elegant
- sequencer (rebase -i): differentiate between comments and 'noop'
- sequencer (rebase -i): implement the 'drop' command
- sequencer (rebase -i): allow rescheduling commands
- sequencer (rebase -i): respect strategy/strategy_opts settings
- sequencer (rebase -i): respect the rebase.autostash setting
- sequencer (rebase -i): run the post-rewrite hook, if needed
- sequencer (rebase -i): record interrupted commits in rewritten, too
- sequencer (rebase -i): copy commit notes at end
- sequencer (rebase -i): set the reflog message consistently
- sequencer (rebase -i): refactor setting the reflog message
- sequencer (rebase -i): allow fast-forwarding for edit/reword
- sequencer (rebase -i): implement the 'reword' command
- sequencer (rebase -i): leave a patch upon error
- sequencer (rebase -i): update refs after a successful rebase
- sequencer (rebase -i): the todo can be empty when continuing
- sequencer (rebase -i): skip some revert/cherry-pick specific code path
- sequencer (rebase -i): remove CHERRY_PICK_HEAD when no longer needed
- sequencer (rebase -i): allow continuing with staged changes
- sequencer (rebase -i): write an author-script file
- sequencer (rebase -i): implement the short commands
- sequencer (rebase -i): add support for the 'fixup' and 'squash' commands
- sequencer (rebase -i): write the 'done' file
- sequencer (rebase -i): learn about the 'verbose' mode
- sequencer (rebase -i): implement the 'exec' command
- sequencer (rebase -i): implement the 'edit' command
- sequencer (rebase -i): implement the 'noop' command
- sequencer: support a new action: 'interactive rebase'
- sequencer: use a helper to find the commit message
- sequencer: move "else" keyword onto the same line as preceding brace
- sequencer: avoid unnecessary curly braces
The sequencer has further been extended in preparation to act as a
back-end for "rebase -i".
Waiting for review comments to be addressed.
* bw/realpath-wo-chdir (2017-01-09) 7 commits
(merged to 'next' on 2017-01-10 at ed315a40c8)
+ real_path: set errno when max number of symlinks is exceeded
+ real_path: prevent redefinition of MAXSYMLINKS
(merged to 'next' on 2016-12-22 at fea8fa870f)
+ real_path: canonicalize directory separators in root parts
+ real_path: have callers use real_pathdup and strbuf_realpath
+ real_path: create real_pathdup
+ real_path: convert real_path_internal to strbuf_realpath
+ real_path: resolve symlinks by hand
(this branch is tangled with bw/grep-recurse-submodules.)
The implementation of "real_path()" was to go there with chdir(2)
and call getcwd(3), but this obviously wouldn't be usable in a
threaded environment. Rewrite it to manually resolve relative
paths including symbolic links in path components.
Will merge to 'master'.
* js/difftool-builtin (2017-01-09) 5 commits
- t7800: run both builtin and scripted difftool, for now
- difftool: implement the functionality in the builtin
- difftool: add a skeleton for the upcoming builtin
- git_exec_path: do not return the result of getenv()
- git_exec_path: avoid Coverity warning about unfree()d result
Rewrite a scripted porcelain "git difftool" in C.
Expecting a reroll.
cf. <alpine.DEB.2.20.1701091228460.3469@virtualbox>
* sb/push-make-submodule-check-the-default (2016-11-29) 2 commits
(merged to 'next' on 2016-12-12 at 1863e05af5)
+ push: change submodule default to check when submodules exist
+ submodule add: extend force flag to add existing repos
Turn the default of "push.recurseSubmodules" to "check" when
submodules seem to be in use.
Will cook in 'next'.
* kn/ref-filter-branch-list (2017-01-10) 21 commits
- SQUASH???
- 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 an 'rstrip=<N>' option to atoms which deal with refnames
- ref-filter: modify the 'lstrip=<N>' option to work with negative '<N>'
- ref-filter: Do not abruptly die when using the 'lstrip=<N>' option
- ref-filter: rename the 'strip' option to 'lstrip'
- ref-filter: make remote_ref_atom_parser() use refname_atom_parser_internal()
- ref-filter: introduce 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.
I think this is almost ready. Will wait for a few days, squash
fixes in if needed and merge to 'next'.
* jk/no-looking-at-dotgit-outside-repo-final (2016-10-26) 1 commit
(merged to 'next' on 2016-12-05 at 0c77e39cd5)
+ setup_git_env: avoid blind fall-back to ".git"
Originally merged to 'next' on 2016-10-26
This is the endgame of the topic to avoid blindly falling back to
".git" when the setup sequence said we are _not_ in Git repository.
A corner case that happens to work right now may be broken by a
call to die("BUG").
Will cook in 'next'.
* pb/bisect (2016-10-18) 27 commits
- bisect--helper: remove the dequote in bisect_start()
- bisect--helper: retire `--bisect-auto-next` subcommand
- bisect--helper: retire `--bisect-autostart` subcommand
- bisect--helper: retire `--bisect-write` subcommand
- bisect--helper: `bisect_replay` shell function in C
- bisect--helper: `bisect_log` shell function in C
- bisect--helper: retire `--write-terms` subcommand
- bisect--helper: retire `--check-expected-revs` subcommand
- bisect--helper: `bisect_state` & `bisect_head` shell function in C
- bisect--helper: `bisect_autostart` shell function in C
- bisect--helper: retire `--next-all` subcommand
- bisect--helper: retire `--bisect-clean-state` subcommand
- bisect--helper: `bisect_next` and `bisect_auto_next` shell function in C
- t6030: no cleanup with bad merge base
- bisect--helper: `bisect_start` shell function partially in C
- bisect--helper: `get_terms` & `bisect_terms` shell function in C
- bisect--helper: `bisect_next_check` & bisect_voc shell function in C
- bisect--helper: `check_and_set_terms` shell function in C
- bisect--helper: `bisect_write` shell function in C
- bisect--helper: `is_expected_rev` & `check_expected_revs` shell function in C
- bisect--helper: `bisect_reset` shell function in C
- wrapper: move is_empty_file() and rename it as is_empty_or_missing_file()
- t6030: explicitly test for bisection cleanup
- bisect--helper: `bisect_clean_state` shell function in C
- bisect--helper: `write_terms` shell function in C
- bisect: rewrite `check_term_format` shell function in C
- bisect--helper: use OPT_CMDMODE instead of OPT_BOOL
Move more parts of "git bisect" to C.
Expecting a reroll.
cf. <CAFZEwPPXPPHi8KiEGS9ggzNHDCGhuqMgH9Z8-Pf9GLshg8+LPA@mail.gmail.com>
cf. <CAFZEwPM9RSTGN54dzaw9gO9iZmsYjJ_d1SjUD4EzSDDbmh-XuA@mail.gmail.com>
* st/verify-tag (2016-10-10) 7 commits
- t/t7004-tag: Add --format specifier tests
- t/t7030-verify-tag: Add --format specifier tests
- builtin/tag: add --format argument for tag -v
- builtin/verify-tag: add --format to verify-tag
- tag: add format specifier to gpg_verify_tag
- ref-filter: add function to print single ref_array_item
- gpg-interface, tag: add GPG_VERIFY_QUIET flag
"git tag" and "git verify-tag" learned to put GPG verification
status in their "--format=<placeholders>" output format.
Waiting for a reroll.
cf. <20161007210721.20437-1-santiago@nyu.edu>
* sg/fix-versioncmp-with-common-suffix (2017-01-12) 8 commits
- versioncmp: generalize version sort suffix reordering
- versioncmp: factor out helper for suffix matching
- versioncmp: use earliest-longest contained suffix to determine sorting order
- versioncmp: cope with common part overlapping with prerelease suffix
- 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).
Will merge to 'next'.
* jc/merge-drop-old-syntax (2015-04-29) 1 commit
(merged to 'next' on 2016-12-05 at 041946dae0)
+ merge: drop 'git merge <message> HEAD <commit>' syntax
Originally merged to 'next' on 2016-10-11
Stop supporting "git merge <message> HEAD <commit>" syntax that has
been deprecated since October 2007, and issues a deprecation
warning message since v2.5.0.
Will cook in 'next'.
--------------------------------------------------
[Discarded]
* sb/attr (2016-11-11) 35 commits
. completion: clone can initialize specific submodules
. clone: add --init-submodule=<pathspec> switch
. submodule update: add `--init-default-path` switch
. pathspec: allow escaped query values
. pathspec: allow querying for attributes
. pathspec: move prefix check out of the inner loop
. pathspec: move long magic parsing out of prefix_pathspec
. Documentation: fix a typo
. attr: keep attr stack for each check
. attr: convert to new threadsafe API
. attr: make git_check_attr_counted static
. attr.c: outline the future plans by heavily commenting
. attr.c: always pass check[] to collect_some_attrs()
. attr.c: introduce empty_attr_check_elems()
. attr.c: correct ugly hack for git_all_attrs()
. attr.c: rename a local variable check
. attr.c: pass struct git_attr_check down the callchain
. attr.c: add push_stack() helper
. attr: support quoting pathname patterns in C style
. attr: expose validity check for attribute names
. attr: add counted string version of git_check_attr()
. attr: retire git_check_attrs() API
. attr: convert git_check_attrs() callers to use the new API
. attr: convert git_all_attrs() to use "struct git_attr_check"
. attr: (re)introduce git_check_attr() and struct git_attr_check
. attr: rename function and struct related to checking attributes
. attr.c: plug small leak in parse_attr_line()
. attr.c: tighten constness around "git_attr" structure
. attr.c: simplify macroexpand_one()
. attr.c: mark where #if DEBUG ends more clearly
. attr.c: complete a sentence in a comment
. attr.c: explain the lack of attr-name syntax check in parse_attr()
. attr.c: update a stale comment on "struct match_attr"
. attr.c: use strchrnul() to scan for one line
. commit.c: use strchrnul() to scan for one line
The attributes API has been updated so that it can later be
optimized using the knowledge of which attributes are queried.
Building on top of the updated API, the pathspec machinery learned
to select only paths with given attributes set.
Superseded by bw/attr 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