* Re: [RFC 02/14] upload-pack: allow ref name and glob requests
From: Junio C Hamano @ 2017-01-27 1:54 UTC (permalink / raw)
To: Jonathan Tan; +Cc: git
In-Reply-To: <dc09e446-6d29-8b94-f440-6aa094ab9dc9@google.com>
Jonathan Tan <jonathantanmy@google.com> writes:
>> I am not sure if this "at the conclusion of" is sensible. It is OK
>> to assume that what the client side has is fixed, and it is probably
>> OK to desire that what the server side has can change, but at the
>> same time, it feels quite fragile to move the goalpost in between.
>
> Do you have any specific concerns as to this fragility? Peff mentioned
> some concerns with the client making some decisions based on the
> initial SHA-1 vs the SHA-1 reported by "wanted-ref", to which I
> replied [1].
There were two but I think you are aware of both. One is what Peff
already mentioned, the client may want to make the decision before
going through the negotiation. The other is "moving the goalpost",
the history the last server has may violate the view of the history
common between the server and the client that is established during
the negotiation with previous servers.
^ permalink raw reply
* Re: [RFC 03/14] upload-pack: test negotiation with changing repo
From: Jonathan Tan @ 2017-01-27 0:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <xmqq8tpx30zq.fsf@gitster.mtv.corp.google.com>
On 01/26/2017 02:33 PM, Junio C Hamano wrote:
> Jonathan Tan <jonathantanmy@google.com> writes:
>
>> diff --git a/t/lib-httpd/one-time-sed.sh b/t/lib-httpd/one-time-sed.sh
>> new file mode 100644
>> index 000000000..060ec0300
>> --- /dev/null
>> +++ b/t/lib-httpd/one-time-sed.sh
>> @@ -0,0 +1,8 @@
>> +#!/bin/sh
>> +
>> +if [ -e one-time-sed ]; then
>> + "$GIT_EXEC_PATH/git-http-backend" | sed "$(cat one-time-sed)"
>> + rm one-time-sed
>> +else
>> + "$GIT_EXEC_PATH/git-http-backend"
>> +fi
>
> CodingGuidelines?
Thanks - done locally and will send out in the next reroll.
>> +inconsistency() {
>> + # Simulate that the server initially reports $2 as the ref
>> + # corresponding to $1, and after that, $1 as the ref corresponding to
>> + # $1. This corresponds to the real-life situation where the server's
>> + # repository appears to change during negotiation, for example, when
>> + # different servers in a load-balancing arrangement serve (stateless)
>> + # RPCs during a single negotiation.
>> + printf "s/%s/%s/" \
>> + $(git -C "$REPO" rev-parse $1 | tr -d "\n") \
>> + $(git -C "$REPO" rev-parse $2 | tr -d "\n") \
>> + >"$HTTPD_ROOT_PATH/one-time-sed"
>
> I'd prefer for the printf'd result to have a final LF (i.e. not
> leaving the resulting one-time-sed with a final incomplete line).
> Also, do you really need the pipe to tr-d? Doesn't the result of
> $(command substitution) omit the final LF anyway?
>
> $ printf '1 %s 2 %s 3\n' "$(echo foo)" "$(echo bar)"; echo OK
> 1 foo 2 bar 3
> OK
Done.
>> diff --git a/upload-pack.c b/upload-pack.c
>> index b88ed8e26..0678c53d6 100644
>> --- a/upload-pack.c
>> +++ b/upload-pack.c
>> @@ -862,9 +862,13 @@ static void receive_needs(struct string_list *wanted_ns_refs)
>> } else if (skip_prefix(line, "want ", &arg) &&
>> !get_sha1_hex(arg, sha1_buf)) {
>> o = parse_object(sha1_buf);
>> - if (!o)
>> + if (!o) {
>> + packet_write_fmt(1,
>> + "ERR upload-pack: not our ref %s",
>> + sha1_to_hex(sha1_buf));
>> die("git upload-pack: not our ref %s",
>> sha1_to_hex(sha1_buf));
>> + }
>
> This somehow looks like a good thing to do even in production. Am I
> mistaken?
Yes, that's true. If this patch set stalls (for whatever reason), I'll
spin this off into an independent patch.
^ permalink raw reply
* Re: [PATCH] Documentation: implement linkgit macro for Asciidoctor
From: brian m. carlson @ 2017-01-27 0:40 UTC (permalink / raw)
To: Eric Wong
Cc: Junio C Hamano, Jeff King, git, Johannes Schindelin,
Øyvind A. Holm
In-Reply-To: <20170126191841.GA6060@dcvr.yhbt.net>
[-- Attachment #1: Type: text/plain, Size: 1277 bytes --]
On Thu, Jan 26, 2017 at 07:18:41PM +0000, Eric Wong wrote:
> > Eric Wong <e@80x24.org> writes:
> Junio C Hamano <gitster@pobox.com> wrote:
> > + "<citerefentry>\n"
> > + "<refentrytitle>#{target}</refentrytitle>"
> > + "<manvolnum>#{attrs[1]}</manvolnum>\n"
> > + "</citerefentry>\n"
> > end
>
> You need the '\' at the end of those strings, it's not like C
> since Ruby doesn't require semi-colons to terminate lines.
> In other words, that should be:
>
> "<citerefentry>\n" \
> "<refentrytitle>#{target}</refentrytitle>" \
> "<manvolnum>#{attrs[1]}</manvolnum>\n" \
> "</citerefentry>\n"
>
This change is fine with me.
For the record, I don't have a strong opinion one way or the other.
Since this code is related to Asciidoctor and Git has no existing Ruby
style standards, I picked the Asciidoctor house style, which uses
multi-line %(). We could pick [0] as an option, or just argue it out
when someone cares, like here.
[0] https://github.com/bbatsov/ruby-style-guide
--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | https://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: https://keybase.io/bk2204
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 868 bytes --]
^ permalink raw reply
* Re: [RFC 02/14] upload-pack: allow ref name and glob requests
From: Jonathan Tan @ 2017-01-27 0:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <xmqqd1f931g7.fsf@gitster.mtv.corp.google.com>
On 01/26/2017 02:23 PM, Junio C Hamano wrote:
> Jonathan Tan <jonathantanmy@google.com> writes:
>
>> Currently, while performing packfile negotiation [1], upload-pack allows
>> clients to specify their desired objects only as SHA-1s. This causes:
>> (a) vulnerability to failure when an object turns non-existent during
>> negotiation, which may happen if, for example, upload-pack is
>> provided by multiple Git servers in a load-balancing arrangement,
>> and
>> (b) dependence on the server first publishing a list of refs with
>> associated objects.
>>
>> To eliminate (a) and take a step towards eliminating (b), teach
>> upload-pack to support requests in the form of ref names and globs (in
>> addition to the existing support for SHA-1s) through a new line of the
>> form "want-ref <ref>" where ref is the full name of a ref, a glob
>> pattern, or a SHA-1. At the conclusion of negotiation, the server will
>> write "wanted-ref <SHA-1> <name>" for all requests that have been
>> specified this way.
>
> I am not sure if this "at the conclusion of" is sensible. It is OK
> to assume that what the client side has is fixed, and it is probably
> OK to desire that what the server side has can change, but at the
> same time, it feels quite fragile to move the goalpost in between.
Do you have any specific concerns as to this fragility? Peff mentioned
some concerns with the client making some decisions based on the initial
SHA-1 vs the SHA-1 reported by "wanted-ref", to which I replied [1].
> Stepping back a bit, in an environment that involves multiple server
> instances that have inconsistent set of refs, can the negotiation
> even be sensibly and safely implemented? The first server the
> client contacts may, in response to a "have", say "I do have that
> commit so you do not have to send its ancestors to me. We found one
> cut-off point. Please do explore other lines of histories." The
> next server that concludes the negotiation exchange may not have
> that commit and will be unable to produce a pack that excludes the
> objects reachable from that commit---wouldn't that become a problem?
It's true that this patch set wouldn't solve this problem. This problem
only occurs when there is a commit that the client knows but only a few
of the servers know (maybe because the client just pushed it to one of
them). If, for example, the client does not know a commit and only a few
of the servers know it (for example, because another user just pushed
it), this patch set does help. The latter scenario seems like it would
occur relatively commonly.
> One way to prevent such a problem from hurting clients may be for
> these multiple server instances to coordinate and make sure they
> have a shared perception of the common history among them. Some
> pushes may have come to one instance but may not have propagated to
> other instances, and such a commit cannot be accepted as usable
> "have" if the servers anticipate that the final client request would
> go to any of the servers. Otherwise the multiple server arrangement
> would not work safely, methinks.
>
> And if the servers are ensuring the safety using such a mechanism,
> they can use the same mechanism to restrain "faster" instances from
> sending too fresh state of refs that other instances haven't caught
> up to, which would mean they can present a consistent set of refs to
> the client in the first place, no?
>
> So I am not sure if the mechanism to request history by refname
> instead of the tip commit would help the multi-server environment as
> advertised. It may help solving other problems, though (e.g. like
> "somebody pushed to update after the initial advertisement was sent
> out" which can happen even in a single server environment).
This patch set would solve the problem you describe (whether in a single
server environment or the coordination between multiple servers that
provides "strong consistency"). (Although it may not be an important
problem to solve, since it is probably OK if the client got a "slow"
version of the state of the refs.)
>> To be flexible with respect to client needs, the server does not
>> indicate an error if a "want-ref" line corresponds to no refs, but
>> instead relies on the client to ensure that what the user needs has been
>> fetched. For example, a client could reasonably expand an abbreviated
>> name "foo" to "want-ref foo", "want-ref refs/heads/foo", "want-ref
>> refs/tags/foo", among others, and ensure that at least one such ref has
>> been fetched.
>
> Cute. This may be one way to implement the DWIM thing within the
> constraint of eventually wanting to go to "client speaks first, the
> server does not advertise things the client is not interested in"
> world.
>
> But at the same time it may end up bloating the set of refs the
> client asks instead. Instead of receiving the advertisement and
> then sending one request after picking the matching one from it,
> the client needs to send "refs/{heads,tags,whatever}/foo".
That is true, although I think that the client will typically send only
a few ref names (with or without globs), so the request packet is still
not that large.
[1] <67afbb3b-5d0b-8c0d-3f6e-3f559c68f4bd@google.com>
^ permalink raw reply
* Re: [RFC 00/14] Allow fetch-pack to send ref names (globs allowed)
From: Jonathan Tan @ 2017-01-27 0:26 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20170126230046.aknesybfyzxhx3ia@sigill.intra.peff.net>
Thanks for your comments.
On 01/26/2017 03:00 PM, Jeff King wrote:
> On Wed, Jan 25, 2017 at 02:02:53PM -0800, Jonathan Tan wrote:
>
>> Negotiation currently happens by upload-pack initially sending a list of
>> refs with names and SHA-1 hashes, and then several request/response
>> pairs in which the request from fetch-pack consists of SHA-1 hashes
>> (selected from the initial list). Allowing the request to consist of
>> names instead of SHA-1 hashes increases tolerance to refs changing
>> (due to time, and due to having load-balanced servers without strong
>> consistency),
>
> Interesting. My big question is: what happens when a ref _does_ change?
> How does the client handle this?
>
> The existing uploadpack.allowReachableSHA1InWant is there to work around
> the problem that an http client may get a ref advertisement in one step,
> and then come back later to do the want/have negotiation, at which point
> the server has moved on (or maybe it's even a different server). There
> the client says "I want sha1 X", and the server needs to say "well, X
> isn't my tip now, but it's still acceptable for you to fetch".
>
> But this seems to go in the opposite direction. After the advertisement,
> the client decides "OK, I want to fetch refs/heads/master which is at
> SHA1 X". It connects to the server and says "I want refs/heads/master".
> Let's say the server has moved its version of the ref to SHA1 Y.
>
> What happens? I think the server will say "wanted-ref master Y". Does
> the client just decide to use "Y" then? How does that interact with any
> decisions the client might have made about X? I guess things like
> fast-forwards have to be decided after we fetch the objects anyway
> (since we cannot compute them until we get the pack), so maybe there
> aren't any such decisions. I haven't checked.
Yes, the server will say "wanted-ref master Y". The relevant code
regarding the decisions the client makes regarding X or Y is in do_fetch
in builtin/fetch.c.
There, I can see these decisions done using X:
- check_not_current_branch (forbidding fetching that modifies the
current branch) (I just noticed that this has to be done for Y too,
and will do so)
- prune refs [*]
- automatic tag following [*]
[*] X and Y may differ in that one relevant ref appears in one set but
not in the other (because a ref was added or removed in the meantime),
causing a different result if these decisions were to be done using Y,
but I think that it is OK either way.
Fetch optimizations (for example, everything_local in fetch-pack.c) that
check if the client really needs to fetch are also done using X, of
course (and if the optimization succeeds, there is no Y).
Fast-forwards (and everything else in store_updated_refs) are decided
using Y.
>> and is a step towards eliminating the need for the server
>> to send the list of refs first (possibly improving performance).
>
> I'm not sure it is all that useful towards that end. You still have to
> break compatibility so that the client tells the server to suppress the
> ref advertisement. After that, it is just a question of asking for the
> refs. And you have two options:
>
> 1. Ask the server to tell you the values of some subset of the refs,
> pick what you want, and then do the want/have as normal.
>
> 2. Go straight to the want/have, but tell the server the refs you want
> instead of their sha1s.
>
> I think your approach here would lead to (2).
>
> But (1), besides being closer to how the protocol works now, seems like
> it's more flexible. I can ask about the ref state without necessarily
> having to retrieve the objects. How would you write git-ls-remote with
> such a system?
Assuming a new protocol with the appropriate backwards compatibility
(which would have to be done for both options), (2) does save a
request/response pair (because we can send the ref names directly as
"want-ref" in the initial request instead of sending ref names in the
initial request and then confirming them using "want <SHA-1>" in the
subsequent request). Also, (2) is more tolerant towards refs changing
over time. (1) might be closer to the current protocol, but I think that
the difference is not so significant (only in "want-ref" vs "want"
request and the "wanted-ref" response).
As for git-ls-remote, I currently think that it would have to use the
existing protocol.
>> [1] There has been some discussion about whether the server should
>> accept partial ref names, e.g. [2]. In this patch set, I have made the
>> server only accept full names, and it is the responsibility of the
>> client to send the multiple patterns which it wants to match. Quoting
>> from the commit message of the second patch:
>>
>> For example, a client could reasonably expand an abbreviated
>> name "foo" to "want-ref foo", "want-ref refs/heads/foo", "want-ref
>> refs/tags/foo", among others, and ensure that at least one such ref has
>> been fetched.
>
> That has a cost that scales linearly with the number of refs, because
> you have to ask for each name 6 times. After the discussion you linked,
> I think my preference is more like:
>
> 1. Teach servers to accept a list of patterns from the client
> which will be resolved in order. Unlike your system, the client
> only needs to specify the list once per session, rather than once
> per ref.
>
> 2. (Optional) Give a shorthand for the stock patterns that git has had
> in place for years. That saves some bytes over specifying the
> patterns completely (though it's really not _that_ many bytes, so
> perhaps the complication isn't a big deal).
I envision that most fetches would be done on a single name (with or
without globs), that expands to 5 (so it is not so crucial to factor out
the list of patterns). Having said that, I am open to changing this.
^ permalink raw reply
* Re: [PATCH v2 3/3] update-ref: add test cases for bare repository
From: Junio C Hamano @ 2017-01-26 23:41 UTC (permalink / raw)
To: cornelius.weig; +Cc: peff, git
In-Reply-To: <20170126223159.16439-3-cornelius.weig@tngtech.com>
cornelius.weig@tngtech.com writes:
> From: Cornelius Weig <cornelius.weig@tngtech.com>
>
> The default behavior of update-ref to create reflogs differs in
> repositories with worktree and bare ones. The existing tests cover only
> the behavior of repositories with worktree.
>
> This commit adds tests that assert the correct behavior in bare
> repositories for update-ref. Two cases are covered:
>
> - If core.logAllRefUpdates is not set, no reflogs should be created
> - If core.logAllRefUpdates is true, reflogs should be created
>
> Signed-off-by: Cornelius Weig <cornelius.weig@tngtech.com>
> ---
> t/t1400-update-ref.sh | 43 ++++++++++++++++++++++++++++++++++++-------
> 1 file changed, 36 insertions(+), 7 deletions(-)
>
> diff --git a/t/t1400-update-ref.sh b/t/t1400-update-ref.sh
> index b9084ca..bad88c8 100755
> --- a/t/t1400-update-ref.sh
> +++ b/t/t1400-update-ref.sh
> @@ -8,23 +8,33 @@ test_description='Test git update-ref and basic ref logging'
>
> Z=$_z40
>
> -test_expect_success setup '
> +m=refs/heads/master
> +n_dir=refs/heads/gu
> +n=$n_dir/fixes
> +outside=refs/foo
> +bare=bare-repo
>
> +create_test_objects ()
> +{
> + local T, sha1, prfx="$1"
CodingGuidelines. Do not use bash-ism "local" (besides, I do not
think you want to have comma here).
> for name in A B C D E F
> do
> test_tick &&
> T=$(git write-tree) &&
> sha1=$(echo $name | git commit-tree $T) &&
> - eval $name=$sha1
> + eval $prfx$name=$sha1
> done
> +}
^ permalink raw reply
* Re: [PATCH v2 2/3] refs: add option core.logAllRefUpdates = always
From: Junio C Hamano @ 2017-01-26 23:39 UTC (permalink / raw)
To: cornelius.weig; +Cc: peff, git
In-Reply-To: <20170126223159.16439-2-cornelius.weig@tngtech.com>
cornelius.weig@tngtech.com writes:
> From: Cornelius Weig <cornelius.weig@tngtech.com>
>
> When core.logallrefupdates is true, we only create a new reflog for refs
> that are under certain well-known hierarchies. The reason is that we
> know that some hierarchies (like refs/tags) do not typically change, and
s/do not typically/are not meant to/;
> that unknown hierarchies might not want reflogs at all (e.g., a
> hypothetical refs/foo might be meant to change often and drop old
> history immediately).
>
> However, sometimes it is useful to override this decision and simply log
> for all refs, because the safety and audit trail is more important than
> the performance implications of keeping the log around.
>
> This patch introduces a new "always" mode for the core.logallrefupdates
> option which will log updates to everything under refs/, regardless
> where in the hierarchy it is (we still will not log things like
> ORIG_HEAD and FETCH_HEAD, which are known to be transient).
OK.
> diff --git a/Documentation/config.txt b/Documentation/config.txt
> index 3cd8030..2117616 100644
> --- a/Documentation/config.txt
> +++ b/Documentation/config.txt
> @@ -522,6 +522,8 @@ core.logAllRefUpdates::
> refs/heads/), remote refs (i.e. under refs/remotes/),
> `refs/heads/`), remote refs (i.e. under `refs/remotes/`),
Ahh, the answer to my question on 1/3 is "no, the commit that the
patch was taken out of was already wrong, still having the old line
in front of its rewrite".
> note refs (i.e. under `refs/notes/`), and the symbolic ref `HEAD`.
> + If it is set to `always`, then a missing reflog is automatically
> + created for any ref under `refs/`.
> +
OK.
> diff --git a/Documentation/git-tag.txt b/Documentation/git-tag.txt
> index 5055a96..2ac25a9 100644
> --- a/Documentation/git-tag.txt
> +++ b/Documentation/git-tag.txt
> @@ -150,7 +150,8 @@ This option is only applicable when listing tags without annotation lines.
> 'strip' removes both whitespace and commentary.
>
> --create-reflog::
> - Create a reflog for the tag.
> + Create a reflog for the tag. To globally enable reflogs for tags, see
> + `core.logAllRefUpdates` in linkgit:git-config[1].
OK.
> diff --git a/builtin/checkout.c b/builtin/checkout.c
> index bfe685c..1db0b44 100644
> --- a/builtin/checkout.c
> +++ b/builtin/checkout.c
> @@ -612,7 +612,7 @@ static void update_refs_for_switch(const struct checkout_opts *opts,
> const char *old_desc, *reflog_msg;
> if (opts->new_branch) {
> if (opts->new_orphan_branch) {
> - if (opts->new_branch_log && !log_all_ref_updates) {
> + if (opts->new_branch_log && should_autocreate_reflog("refs/heads/")) {
This is inviting a maintenance nightmare. The helper function is
defined to take the final refname, not a leading directory name.
That is why you named the parameter "refname" in your patch like
this:
--- a/refs.h
+++ b/refs.h
@@ -64,6 +64,8 @@ int read_ref(const char *refname, unsigned char *sha1);
int ref_exists(const char *refname);
+int should_autocreate_reflog(const char *refname);
+
int is_branch(const char *refname);
The callers are not supposed to know that its current implementation
happens to only use the leading prefix. When the definition of this
helper function is changed (e.g. imagine a future where this
"log.allrefupdate" is further enhanced to take glob patterns to
match the refname against), this may break and nobody would notice
for a few weeks, and we will get a regression report after a release
is made.
Don't we have the refname for the branch already in this codepath?
> diff --git a/t/t1400-update-ref.sh b/t/t1400-update-ref.sh
> index d4fb977..b9084ca 100755
> --- a/t/t1400-update-ref.sh
> +++ b/t/t1400-update-ref.sh
> @@ -93,6 +93,42 @@ test_expect_success 'update-ref creates reflogs with --create-reflog' '
> git reflog exists $outside
> '
>
> +test_expect_success 'core.logAllRefUpdates=true does not create reflog by default' '
> + test_config core.logAllRefUpdates true &&
> + test_when_finished "git update-ref -d $outside" &&
> + git update-ref $outside $A &&
> + git rev-parse $A >expect &&
> + git rev-parse $outside >actual &&
> + test_cmp expect actual &&
> + test_must_fail git reflog exists $outside
> +'
> +
> +test_expect_success 'core.logAllRefUpdates=always creates reflog by default' '
> + test_config core.logAllRefUpdates always &&
> + test_when_finished "git update-ref -d $outside" &&
> + git update-ref $outside $A &&
> + git rev-parse $A >expect &&
> + git rev-parse $outside >actual &&
> + test_cmp expect actual &&
> + git reflog exists $outside
> +'
You might want to add two tests for your original motivation, i.e.
test_config core.logAllRefUpdates always &&
git tag a-tag &&
git reflog exists refs/tags/a-tag
and the other one that does not give reflog for a tag.
Other than that, looks good to me.
^ permalink raw reply
* Re: [RFC 03/14] upload-pack: test negotiation with changing repo
From: Junio C Hamano @ 2017-01-26 22:33 UTC (permalink / raw)
To: Jonathan Tan; +Cc: git
In-Reply-To: <afe5d7d3f876893fdad318665805df1e056717c6.1485381677.git.jonathantanmy@google.com>
Jonathan Tan <jonathantanmy@google.com> writes:
> diff --git a/t/lib-httpd/one-time-sed.sh b/t/lib-httpd/one-time-sed.sh
> new file mode 100644
> index 000000000..060ec0300
> --- /dev/null
> +++ b/t/lib-httpd/one-time-sed.sh
> @@ -0,0 +1,8 @@
> +#!/bin/sh
> +
> +if [ -e one-time-sed ]; then
> + "$GIT_EXEC_PATH/git-http-backend" | sed "$(cat one-time-sed)"
> + rm one-time-sed
> +else
> + "$GIT_EXEC_PATH/git-http-backend"
> +fi
CodingGuidelines?
> +inconsistency() {
> + # Simulate that the server initially reports $2 as the ref
> + # corresponding to $1, and after that, $1 as the ref corresponding to
> + # $1. This corresponds to the real-life situation where the server's
> + # repository appears to change during negotiation, for example, when
> + # different servers in a load-balancing arrangement serve (stateless)
> + # RPCs during a single negotiation.
> + printf "s/%s/%s/" \
> + $(git -C "$REPO" rev-parse $1 | tr -d "\n") \
> + $(git -C "$REPO" rev-parse $2 | tr -d "\n") \
> + >"$HTTPD_ROOT_PATH/one-time-sed"
I'd prefer for the printf'd result to have a final LF (i.e. not
leaving the resulting one-time-sed with a final incomplete line).
Also, do you really need the pipe to tr-d? Doesn't the result of
$(command substitution) omit the final LF anyway?
$ printf '1 %s 2 %s 3\n' "$(echo foo)" "$(echo bar)"; echo OK
1 foo 2 bar 3
OK
> diff --git a/upload-pack.c b/upload-pack.c
> index b88ed8e26..0678c53d6 100644
> --- a/upload-pack.c
> +++ b/upload-pack.c
> @@ -862,9 +862,13 @@ static void receive_needs(struct string_list *wanted_ns_refs)
> } else if (skip_prefix(line, "want ", &arg) &&
> !get_sha1_hex(arg, sha1_buf)) {
> o = parse_object(sha1_buf);
> - if (!o)
> + if (!o) {
> + packet_write_fmt(1,
> + "ERR upload-pack: not our ref %s",
> + sha1_to_hex(sha1_buf));
> die("git upload-pack: not our ref %s",
> sha1_to_hex(sha1_buf));
> + }
This somehow looks like a good thing to do even in production. Am I
mistaken?
^ permalink raw reply
* Re: [PATCH] git-bisect: allow running in a working tree subdirectory
From: Junio C Hamano @ 2017-01-26 23:22 UTC (permalink / raw)
To: Johannes Sixt; +Cc: marcandre.lureau, git, chriscool
In-Reply-To: <96afaa1d-31d7-0b7e-d2b3-77a455158638@kdbg.org>
Johannes Sixt <j6t@kdbg.org> writes:
> Am 26.01.2017 um 19:30 schrieb marcandre.lureau@redhat.com:
>> From: Marc-André Lureau <marcandre.lureau@redhat.com>
>>
>> It looks like it can do it.
>>
>> Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
>> ---
>> git-bisect.sh | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/git-bisect.sh b/git-bisect.sh
>> index ae3cb013e..b0bd604d4 100755
>> --- a/git-bisect.sh
>> +++ b/git-bisect.sh
>> @@ -1,5 +1,6 @@
>> #!/bin/sh
>>
>> +SUBDIRECTORY_OK=Yes
>> USAGE='[help|start|bad|good|new|old|terms|skip|next|reset|visualize|replay|log|run]'
>> LONG_USAGE='git bisect help
>> print this long help message.
>>
>
> Does it also work to drive git bisect from a subdirectory and pass a
> file name (or pathspec) that is relative to that subdirectory rather
> than relative to the root of the worktree? Can `git bisect good` or
> `git bisect bad` of later bisection steps be invoked from different
> subdirectories or the root?
I think the answers are no and no. Entries in BISECT_NAMES and
BISECT_LOG are not getting any prefix.
^ permalink raw reply
* Re: [PATCH v2 1/3] config: add markup to core.logAllRefUpdates doc
From: Junio C Hamano @ 2017-01-26 23:24 UTC (permalink / raw)
To: cornelius.weig; +Cc: peff, git
In-Reply-To: <20170126223159.16439-1-cornelius.weig@tngtech.com>
cornelius.weig@tngtech.com writes:
> From: Cornelius Weig <cornelius.weig@tngtech.com>
>
> Signed-off-by: Cornelius Weig <cornelius.weig@tngtech.com>
> ---
>
> Notes:
> As suggested, I moved the modification of the markup to its own commit.
>
> Documentation/config.txt | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/config.txt b/Documentation/config.txt
> index af2ae4c..3cd8030 100644
> --- a/Documentation/config.txt
> +++ b/Documentation/config.txt
> @@ -517,10 +517,11 @@ core.logAllRefUpdates::
> "`$GIT_DIR/logs/<ref>`", by appending the new and old
> SHA-1, the date/time and the reason of the update, but
> only when the file exists. If this configuration
> - variable is set to true, missing "`$GIT_DIR/logs/<ref>`"
> + variable is set to `true`, missing "`$GIT_DIR/logs/<ref>`"
> file is automatically created for branch heads (i.e. under
> refs/heads/), remote refs (i.e. under refs/remotes/),
> - note refs (i.e. under refs/notes/), and the symbolic ref HEAD.
> + `refs/heads/`), remote refs (i.e. under `refs/remotes/`),
> + note refs (i.e. under `refs/notes/`), and the symbolic ref `HEAD`.
This is a peculiar patch.
Did you hand edit and lose a leading '-' from one of the lines by
accident, or something?
^ permalink raw reply
* What's cooking in git.git (Jan 2017, #05; Thu, 26)
From: Junio C Hamano @ 2017-01-26 23:19 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]
* js/mingw-hooks-with-exe-suffix (2017-01-26) 1 commit
- mingw: allow hooks to be .exe files
Names of the various hook scripts must be spelled exactly, but on
Windows, an .exe binary must be named with .exe suffix; notice
$GIT_DIR/hooks/<hookname>.exe as a valid <hookname> hook.
Will merge to 'next'.
* js/retire-relink (2017-01-25) 2 commits
- relink: really remove the command
- relink: retire the command
Cruft removal.
Will merge to 'next'.
* js/status-pre-rebase-i (2017-01-26) 1 commit
- status: be prepared for not-yet-started interactive rebase
After starting "git rebase -i", which first opens the user's editor
to edit the series of patches to apply, but before saving the
contents of that file, "git status" failed to show the current
state (i.e. you are in an interactive rebase session, but you have
applied no steps yet) correctly.
Will merge to 'next'.
* ps/urlmatch-wildcard (2017-01-26) 5 commits
- SQUASH???
- urlmatch: allow globbing for the URL host part
- urlmatch: split host and port fields in `struct url_info`
- urlmatch: enable normalization of URLs with globs
- mailmap: add Patrick Steinhardt's work address
The <url> part in "http.<url>.<variable>" configuration variable
can now be spelled with '*' that serves as wildcard.
E.g. "http.https://*.example.com.proxy" can be used to specify the
proxy used for https://a.example.com, https://b.example.com, etc.,
i.e. any host in the example.com domain.
* rs/absolute-pathdup (2017-01-26) 2 commits
- use absolute_pathdup()
- abspath: add absolute_pathdup()
Code cleanup.
Will merge to 'next'.
* sb/submodule-recursive-absorb (2017-01-26) 3 commits
- submodule absorbing: fix worktree/gitdir pointers recursively for non-moves
- cache.h: expose the dying procedure for reading gitlinks
- setup: add gentle version of resolve_git_dir
When a submodule "sub", which has another submodule "module" nested
within it, is "absorbed" into the top-level superproject, the inner
submodule "module" is left in a strange state.
Will merge to 'next'.
* sb/submodule-update-initial-runs-custom-script (2017-01-26) 1 commit
- submodule update: run custom update script for initial populating as well
The user can specify a custom update method that is run when
"submodule update" updates an already checked out submodule. This
was ignored when checking the submodule out for the first time and
we instead always just checked out the commit that is bound to the
path in the superproject's index.
Will merge to 'next'.
* sf/putty-w-args (2017-01-26) 3 commits
- connect: support GIT_SSH_VARIANT and ssh.variant
- connect: rename tortoiseplink and putty variables
- connect: handle putty/plink also in GIT_SSH_COMMAND
The command line options for ssh invocation needs to be tweaked for
some implementations of SSH (e.g. PuTTY plink wants "-P <port>"
while OpenSSH wants "-p <port>" to specify port to connect to), and
the variant was guessed when GIT_SSH environment variable is used
to specify it. Extend the guess to the command specified by the
newer GIT_SSH_COMMAND and also core.sshcommand configuration
variable, and give an escape hatch for users to deal with
misdetected cases.
Expecting a reroll of the last step.
--------------------------------------------------
[Stalled]
* 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]
* sh/grep-tree-obj-tweak-output (2017-01-20) 2 commits
- grep: use '/' delimiter for paths
- grep: only add delimiter if there isn't one already
"git grep", when fed a tree-ish as an input, shows each hit
prefixed with "<tree-ish>:<path>:<lineno>:". As <tree-ish> is
almost always either a commit or a tag that points at a commit, the
early part of the output "<tree-ish>:<path>" can be used as the
name of the blob and given to "git show". When <tree-ish> is a
tree given in the extended SHA-1 syntax (e.g. "<commit>:", or
"<commit>:<dir>"), however, this results in a string that does not
name a blob (e.g. "<commit>::<path>" or "<commit>:<dir>:<path>").
"git grep" has been taught to be a bit more intelligent about these
cases and omit a colon (in the former case) or use slash (in the
latter case) to produce "<commit>:<path>" and
"<commit>:<dir>/<path>" that can be used as the name of a blob.
Waiting for the review discussion to settle, followed by a reroll.
* vp/show-ref-verify-head (2017-01-23) 6 commits
(merged to 'next' on 2017-01-23 at af6dd9d239)
+ show-ref: remove a stale comment
+ show-ref: remove dead `if (verify)' check
+ show-ref: detect dangling refs under --verify as well
+ show-ref: move --quiet handling into show_one()
+ show-ref: allow -d to work with --verify
+ show-ref: accept HEAD with --verify
"git show-ref HEAD" used with "--verify" because the user is not
interested in seeing refs/remotes/origin/HEAD, and used with
"--head" because the user does not want HEAD to be filtered out,
i.e. "git show-ref --head --verify HEAD", did not work as expected.
Will merge to 'master'.
* bc/use-asciidoctor-opt (2017-01-26) 9 commits
- SQUASH???
- Documentation: implement linkgit macro for Asciidoctor
- Makefile: add a knob to enable the use of Asciidoctor
- Documentation: move dblatex arguments into variable
- Documentation: add XSLT to fix DocBook for Texinfo
- Documentation: sort sources for gitman.texi
- Documentation: remove unneeded argument in cat-texi.perl
- Documentation: modernize cat-texi.perl
- Documentation: fix warning in cat-texi.perl
Asciidoctor, an alternative reimplementation of AsciiDoc, still
needs some changes to work with documents meant to be formatted
with AsciiDoc. "make USE_ASCIIDOCTOR=YesPlease" to use it out of
the box to document our pages is getting closer to reality.
* ls/travis-p4-on-macos (2017-01-23) 1 commit
(merged to 'next' on 2017-01-23 at 2d51987faa)
+ travis-ci: fix Perforce install on macOS
Update the definition of the MacOSX test environment used by
TravisCI.
Will merge to 'master'.
* rs/qsort-s (2017-01-23) 5 commits
(merged to 'next' on 2017-01-23 at 7e2813848b)
+ ref-filter: use QSORT_S in ref_array_sort()
+ string-list: use QSORT_S in string_list_sort()
+ perf: add basic sort performance test
+ add QSORT_S
+ compat: add qsort_s()
A few codepaths had to rely on a global variable when sorting
elements of an array because sort(3) API does not allow extra data
to be passed to the comparison function. Use qsort_s() when
natively available, and a fallback implementation of it when not,
to eliminate the need, which is a prerequisite for making the
codepath reentrant.
Will merge to 'master'.
* jk/coding-guidelines-update (2017-01-17) 1 commit
(merged to 'next' on 2017-01-23 at 8c57afa288)
+ CodingGuidelines: clarify multi-line brace style
Developer doc update.
Will merge to 'master'.
* jk/fsck-connectivity-check-fix (2017-01-26) 9 commits
(merged to 'next' on 2017-01-26 at dd03f7a17f)
+ fsck: lazily load types under --connectivity-only
+ fsck: move typename() printing to its own function
(merged to 'next' on 2017-01-25 at f3d7d93785)
+ t1450: use "mv -f" within loose object directory
(merged to 'next' on 2017-01-23 at e8e9b76b84)
+ fsck: check HAS_OBJ more consistently
+ fsck: do not fallback "git fsck <bogus>" to "git fsck"
+ fsck: tighten error-checks of "git fsck <head>"
+ fsck: prepare dummy objects for --connectivity-check
+ fsck: report trees as dangling
+ t1450: clean up sub-objects in duplicate-entry test
"git fsck --connectivity-check" was not working at all.
Will merge to 'master'.
* js/exec-path-coverity-workaround (2017-01-09) 2 commits
(merged to 'next' on 2017-01-23 at bf5dfbf860)
+ git_exec_path: do not return the result of getenv()
+ git_exec_path: avoid Coverity warning about unfree()d result
Code cleanup.
Will merge to 'master'.
Split out of another topic.
* js/mingw-isatty (2017-01-18) 1 commit
(merged to 'next' on 2017-01-23 at ae0f80e058)
+ mingw: follow-up to "replace isatty() hack"
An update to a topic that is already in 'master'.
Will merge to 'master'.
* js/sequencer-i-countdown-3 (2017-01-17) 38 commits
(merged to 'next' on 2017-01-23 at 251dd15139)
+ 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: update reading author-script
+ 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 machinery has been further enhanced so that a later
set of patches can start using it to reimplement "rebase -i".
Will merge to 'master'.
I think I've said everything that needs to be said on this topic.
* jk/clear-delta-base-cache-fix (2017-01-19) 1 commit
(merged to 'next' on 2017-01-23 at 5f4af2b0a5)
+ clear_delta_base_cache(): don't modify hashmap while iterating
A crashing bug introduced in v2.11 timeframe has been found (it is
triggerable only in fast-import) and fixed.
Will merge to 'master'.
* jk/describe-omit-some-refs (2017-01-23) 5 commits
(merged to 'next' on 2017-01-23 at f8a14b4996)
+ describe: teach describe negative pattern matches
+ describe: teach --match to accept multiple patterns
+ name-rev: add support to exclude refs by pattern match
+ name-rev: extend --refs to accept multiple patterns
+ doc: add documentation for OPT_STRING_LIST
"git describe" and "git name-rev" have been taught to take more
than one refname patterns to restrict the set of refs to base their
naming output on, and also learned to take negative patterns to
name refs not to be used for naming via their "--exclude" option.
Will merge to 'next'.
* js/remote-rename-with-half-configured-remote (2017-01-19) 2 commits
(merged to 'next' on 2017-01-23 at a1b655dbac)
+ remote rename: more carefully determine whether a remote is configured
+ remote rename: demonstrate a bogus "remote exists" bug
With anticipatory tweaking for remotes defined in ~/.gitconfig
(e.g. "remote.origin.prune" set to true, even though there may or
may not actually be "origin" remote defined in a particular Git
repository), "git remote rename" and other commands misinterpreted
and behaved as if such a non-existing remote actually existed.
Will merge to 'master'.
* sb/in-core-index-doc (2017-01-19) 4 commits
(merged to 'next' on 2017-01-23 at 30224463e8)
+ documentation: retire unfinished documentation
+ cache.h: document add_[file_]to_index
+ cache.h: document remove_index_entry_at
+ cache.h: document index_name_pos
Documentation and in-code comments updates.
Will merge to 'master'.
* sb/retire-convert-objects-from-contrib (2017-01-19) 1 commit
(merged to 'next' on 2017-01-23 at decc1e237d)
+ contrib: remove git-convert-objects
Remove an ancient tool left in contrib/.
Will merge to 'master'.
* 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/vreport-sanitize (2017-01-11) 2 commits
(merged to 'next' on 2017-01-18 at 4bbf370981)
+ 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 'master'.
* sb/unpack-trees-super-prefix (2017-01-25) 4 commits
- 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.
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.
* bw/attr (2017-01-23) 27 commits
- attr: reformat git_attr_set_direction() function
- attr: push the bare repo check into read_attr()
- attr: store attribute stack in attr_check structure
- 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.
Expecting a reroll.
* jk/loose-object-fsck (2017-01-15) 6 commits
(merged to 'next' on 2017-01-23 at 4302ad090d)
+ 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.
Will merge to 'master'.
* 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.
* 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>
* 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'.
* 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.
Needs review.
* nd/log-graph-configurable-colors (2017-01-23) 3 commits
(merged to 'next' on 2017-01-23 at c369982ad8)
+ log --graph: customize the graph lines with config log.graphColors
+ color.c: trim leading spaces in color_parse_mem()
+ color.c: fix color_parse_mem() with value_len == 0
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.
Will merge to 'next'.
* 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
(merged to 'next' on 2017-01-23 at d6cd1c60ae)
+ 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.
Will merge to 'master'.
* 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>
* js/difftool-builtin (2017-01-25) 4 commits
(merged to 'next' on 2017-01-25 at 87d2a0976a)
+ difftool: hack around -Wzero-length-format warning
(merged to 'next' on 2017-01-23 at 6f4810dbd9)
+ difftool: retire the scripted version
+ difftool: implement the functionality in the builtin
+ difftool: add a skeleton for the upcoming builtin
Rewrite a scripted porcelain "git difftool" in C.
Will merge to 'master'.
* sb/push-make-submodule-check-the-default (2017-01-26) 3 commits
(merged to 'next' on 2017-01-26 at 5f4715cea6)
+ Revert "push: change submodule default to check when submodules exist"
(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.
I'll probably remove the tip-two commits and advance the bottom one
separately.
* 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 (2017-01-18) 6 commits
(merged to 'next' on 2017-01-23 at 2810959427)
+ 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
+ ref-filter: add function to print single ref_array_item
+ gpg-interface, tag: add GPG_VERIFY_OMIT_STATUS flag
"git tag" and "git verify-tag" learned to put GPG verification
status in their "--format=<placeholders>" output format.
Will merge to 'master'.
* 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]
* 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.
* 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?
^ permalink raw reply
* Re: [RFC 00/14] Allow fetch-pack to send ref names (globs allowed)
From: Jeff King @ 2017-01-26 23:00 UTC (permalink / raw)
To: Jonathan Tan; +Cc: git
In-Reply-To: <cover.1485381677.git.jonathantanmy@google.com>
On Wed, Jan 25, 2017 at 02:02:53PM -0800, Jonathan Tan wrote:
> Negotiation currently happens by upload-pack initially sending a list of
> refs with names and SHA-1 hashes, and then several request/response
> pairs in which the request from fetch-pack consists of SHA-1 hashes
> (selected from the initial list). Allowing the request to consist of
> names instead of SHA-1 hashes increases tolerance to refs changing
> (due to time, and due to having load-balanced servers without strong
> consistency),
Interesting. My big question is: what happens when a ref _does_ change?
How does the client handle this?
The existing uploadpack.allowReachableSHA1InWant is there to work around
the problem that an http client may get a ref advertisement in one step,
and then come back later to do the want/have negotiation, at which point
the server has moved on (or maybe it's even a different server). There
the client says "I want sha1 X", and the server needs to say "well, X
isn't my tip now, but it's still acceptable for you to fetch".
But this seems to go in the opposite direction. After the advertisement,
the client decides "OK, I want to fetch refs/heads/master which is at
SHA1 X". It connects to the server and says "I want refs/heads/master".
Let's say the server has moved its version of the ref to SHA1 Y.
What happens? I think the server will say "wanted-ref master Y". Does
the client just decide to use "Y" then? How does that interact with any
decisions the client might have made about X? I guess things like
fast-forwards have to be decided after we fetch the objects anyway
(since we cannot compute them until we get the pack), so maybe there
aren't any such decisions. I haven't checked.
> and is a step towards eliminating the need for the server
> to send the list of refs first (possibly improving performance).
I'm not sure it is all that useful towards that end. You still have to
break compatibility so that the client tells the server to suppress the
ref advertisement. After that, it is just a question of asking for the
refs. And you have two options:
1. Ask the server to tell you the values of some subset of the refs,
pick what you want, and then do the want/have as normal.
2. Go straight to the want/have, but tell the server the refs you want
instead of their sha1s.
I think your approach here would lead to (2).
But (1), besides being closer to how the protocol works now, seems like
it's more flexible. I can ask about the ref state without necessarily
having to retrieve the objects. How would you write git-ls-remote with
such a system?
> [1] There has been some discussion about whether the server should
> accept partial ref names, e.g. [2]. In this patch set, I have made the
> server only accept full names, and it is the responsibility of the
> client to send the multiple patterns which it wants to match. Quoting
> from the commit message of the second patch:
>
> For example, a client could reasonably expand an abbreviated
> name "foo" to "want-ref foo", "want-ref refs/heads/foo", "want-ref
> refs/tags/foo", among others, and ensure that at least one such ref has
> been fetched.
That has a cost that scales linearly with the number of refs, because
you have to ask for each name 6 times. After the discussion you linked,
I think my preference is more like:
1. Teach servers to accept a list of patterns from the client
which will be resolved in order. Unlike your system, the client
only needs to specify the list once per session, rather than once
per ref.
2. (Optional) Give a shorthand for the stock patterns that git has had
in place for years. That saves some bytes over specifying the
patterns completely (though it's really not _that_ many bytes, so
perhaps the complication isn't a big deal).
-Peff
^ permalink raw reply
* [PATCH v2 1/3] config: add markup to core.logAllRefUpdates doc
From: cornelius.weig @ 2017-01-26 22:31 UTC (permalink / raw)
To: peff; +Cc: git, Cornelius Weig
In-Reply-To: <20170126033547.7bszipvkpi2jb4ad@sigill.intra.peff.net>
From: Cornelius Weig <cornelius.weig@tngtech.com>
Signed-off-by: Cornelius Weig <cornelius.weig@tngtech.com>
---
Notes:
As suggested, I moved the modification of the markup to its own commit.
Documentation/config.txt | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index af2ae4c..3cd8030 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -517,10 +517,11 @@ core.logAllRefUpdates::
"`$GIT_DIR/logs/<ref>`", by appending the new and old
SHA-1, the date/time and the reason of the update, but
only when the file exists. If this configuration
- variable is set to true, missing "`$GIT_DIR/logs/<ref>`"
+ variable is set to `true`, missing "`$GIT_DIR/logs/<ref>`"
file is automatically created for branch heads (i.e. under
refs/heads/), remote refs (i.e. under refs/remotes/),
- note refs (i.e. under refs/notes/), and the symbolic ref HEAD.
+ `refs/heads/`), remote refs (i.e. under `refs/remotes/`),
+ note refs (i.e. under `refs/notes/`), and the symbolic ref `HEAD`.
+
This information can be used to determine what commit
was the tip of a branch "2 days ago".
--
2.10.2
^ permalink raw reply related
* [PATCH v2 3/3] update-ref: add test cases for bare repository
From: cornelius.weig @ 2017-01-26 22:31 UTC (permalink / raw)
To: peff; +Cc: git, Cornelius Weig
In-Reply-To: <20170126223159.16439-1-cornelius.weig@tngtech.com>
From: Cornelius Weig <cornelius.weig@tngtech.com>
The default behavior of update-ref to create reflogs differs in
repositories with worktree and bare ones. The existing tests cover only
the behavior of repositories with worktree.
This commit adds tests that assert the correct behavior in bare
repositories for update-ref. Two cases are covered:
- If core.logAllRefUpdates is not set, no reflogs should be created
- If core.logAllRefUpdates is true, reflogs should be created
Signed-off-by: Cornelius Weig <cornelius.weig@tngtech.com>
---
t/t1400-update-ref.sh | 43 ++++++++++++++++++++++++++++++++++++-------
1 file changed, 36 insertions(+), 7 deletions(-)
diff --git a/t/t1400-update-ref.sh b/t/t1400-update-ref.sh
index b9084ca..bad88c8 100755
--- a/t/t1400-update-ref.sh
+++ b/t/t1400-update-ref.sh
@@ -8,23 +8,33 @@ test_description='Test git update-ref and basic ref logging'
Z=$_z40
-test_expect_success setup '
+m=refs/heads/master
+n_dir=refs/heads/gu
+n=$n_dir/fixes
+outside=refs/foo
+bare=bare-repo
+create_test_objects ()
+{
+ local T, sha1, prfx="$1"
for name in A B C D E F
do
test_tick &&
T=$(git write-tree) &&
sha1=$(echo $name | git commit-tree $T) &&
- eval $name=$sha1
+ eval $prfx$name=$sha1
done
+}
+test_expect_success setup '
+ create_test_objects "" &&
+ mkdir $bare &&
+ cd $bare &&
+ git init --bare &&
+ create_test_objects "bare" &&
+ cd -
'
-m=refs/heads/master
-n_dir=refs/heads/gu
-n=$n_dir/fixes
-outside=refs/foo
-
test_expect_success \
"create $m" \
"git update-ref $m $A &&
@@ -93,6 +103,25 @@ test_expect_success 'update-ref creates reflogs with --create-reflog' '
git reflog exists $outside
'
+test_expect_success 'creates no reflog in bare repository' '
+ git -C $bare update-ref $m $bareA &&
+ git -C $bare rev-parse $bareA >expect &&
+ git -C $bare rev-parse $m >actual &&
+ test_cmp expect actual &&
+ test_must_fail git -C $bare reflog exists $m
+'
+
+test_expect_success 'core.logAllRefUpdates=true creates reflog in bare repository' '
+ test_when_finished "git -C $bare config --unset core.logAllRefUpdates && \
+ rm $bare/logs/$m" &&
+ git -C $bare config core.logAllRefUpdates true &&
+ git -C $bare update-ref $m $bareB &&
+ git -C $bare rev-parse $bareB >expect &&
+ git -C $bare rev-parse $m >actual &&
+ test_cmp expect actual &&
+ git -C $bare reflog exists $m
+'
+
test_expect_success 'core.logAllRefUpdates=true does not create reflog by default' '
test_config core.logAllRefUpdates true &&
test_when_finished "git update-ref -d $outside" &&
--
2.10.2
^ permalink raw reply related
* [PATCH v2 2/3] refs: add option core.logAllRefUpdates = always
From: cornelius.weig @ 2017-01-26 22:31 UTC (permalink / raw)
To: peff; +Cc: git, Cornelius Weig
In-Reply-To: <20170126223159.16439-1-cornelius.weig@tngtech.com>
From: Cornelius Weig <cornelius.weig@tngtech.com>
When core.logallrefupdates is true, we only create a new reflog for refs
that are under certain well-known hierarchies. The reason is that we
know that some hierarchies (like refs/tags) do not typically change, and
that unknown hierarchies might not want reflogs at all (e.g., a
hypothetical refs/foo might be meant to change often and drop old
history immediately).
However, sometimes it is useful to override this decision and simply log
for all refs, because the safety and audit trail is more important than
the performance implications of keeping the log around.
This patch introduces a new "always" mode for the core.logallrefupdates
option which will log updates to everything under refs/, regardless
where in the hierarchy it is (we still will not log things like
ORIG_HEAD and FETCH_HEAD, which are known to be transient).
Based-on-patch-by: Jeff King <peff@peff.net>
Signed-off-by: Cornelius Weig <cornelius.weig@tngtech.com>
Reviewed-by: Jeff King <peff@peff.net>
---
Notes:
Changes with respect to the previous version:
- add test that checks that no reflog is created for ORIG_HEAD if
core.logAllRefUpdates=always
- remove redundant tests that check reflog creation when update-ref is called
with --stdin
- make test description shorter
- make the function should_autocreate_reflog() public and use it in
update_refs_for_switch().
The last item addresses Peff's concern that the previous version only works by
accident and may break in the future (see
20170126033547.7bszipvkpi2jb4ad@sigill.intra.peff.net). In particular, this
concerns the following change:
- if (opts->new_branch_log && !log_all_ref_updates) {
+ if (opts->new_branch_log && should_autocreate_reflog("refs/heads/")) {
The function call to `should_autocreate_reflog()` answers exactly the question
that the original test `!log_all_ref_updates` tried to resolve in the original
version.
Documentation/config.txt | 2 ++
Documentation/git-tag.txt | 3 ++-
branch.c | 2 +-
builtin/checkout.c | 2 +-
builtin/init-db.c | 2 +-
cache.h | 9 ++++++++-
config.c | 7 ++++++-
environment.c | 2 +-
refs.c | 15 ++++++++++-----
refs.h | 2 ++
refs/files-backend.c | 6 +++---
refs/refs-internal.h | 2 --
t/t1400-update-ref.sh | 37 +++++++++++++++++++++++++++++++++++++
13 files changed, 74 insertions(+), 17 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 3cd8030..2117616 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -522,6 +522,8 @@ core.logAllRefUpdates::
refs/heads/), remote refs (i.e. under refs/remotes/),
`refs/heads/`), remote refs (i.e. under `refs/remotes/`),
note refs (i.e. under `refs/notes/`), and the symbolic ref `HEAD`.
+ If it is set to `always`, then a missing reflog is automatically
+ created for any ref under `refs/`.
+
This information can be used to determine what commit
was the tip of a branch "2 days ago".
diff --git a/Documentation/git-tag.txt b/Documentation/git-tag.txt
index 5055a96..2ac25a9 100644
--- a/Documentation/git-tag.txt
+++ b/Documentation/git-tag.txt
@@ -150,7 +150,8 @@ This option is only applicable when listing tags without annotation lines.
'strip' removes both whitespace and commentary.
--create-reflog::
- Create a reflog for the tag.
+ Create a reflog for the tag. To globally enable reflogs for tags, see
+ `core.logAllRefUpdates` in linkgit:git-config[1].
<tagname>::
The name of the tag to create, delete, or describe.
diff --git a/branch.c b/branch.c
index c431cbf..b955d4f 100644
--- a/branch.c
+++ b/branch.c
@@ -298,7 +298,7 @@ void create_branch(const char *name, const char *start_name,
start_name);
if (reflog)
- log_all_ref_updates = 1;
+ log_all_ref_updates = LOG_REFS_NORMAL;
if (!dont_change_ref) {
struct ref_transaction *transaction;
diff --git a/builtin/checkout.c b/builtin/checkout.c
index bfe685c..1db0b44 100644
--- a/builtin/checkout.c
+++ b/builtin/checkout.c
@@ -612,7 +612,7 @@ static void update_refs_for_switch(const struct checkout_opts *opts,
const char *old_desc, *reflog_msg;
if (opts->new_branch) {
if (opts->new_orphan_branch) {
- if (opts->new_branch_log && !log_all_ref_updates) {
+ if (opts->new_branch_log && should_autocreate_reflog("refs/heads/")) {
int ret;
char *refname;
struct strbuf err = STRBUF_INIT;
diff --git a/builtin/init-db.c b/builtin/init-db.c
index 76d68fa..1d4d6a0 100644
--- a/builtin/init-db.c
+++ b/builtin/init-db.c
@@ -262,7 +262,7 @@ static int create_default_files(const char *template_path,
const char *work_tree = get_git_work_tree();
git_config_set("core.bare", "false");
/* allow template config file to override the default */
- if (log_all_ref_updates == -1)
+ if (log_all_ref_updates == LOG_REFS_UNSET)
git_config_set("core.logallrefupdates", "true");
if (needs_work_tree_config(original_git_dir, work_tree))
git_config_set("core.worktree", work_tree);
diff --git a/cache.h b/cache.h
index 00a029a..96eeaaf 100644
--- a/cache.h
+++ b/cache.h
@@ -660,7 +660,6 @@ extern int minimum_abbrev, default_abbrev;
extern int ignore_case;
extern int assume_unchanged;
extern int prefer_symlink_refs;
-extern int log_all_ref_updates;
extern int warn_ambiguous_refs;
extern int warn_on_object_refname_ambiguity;
extern const char *apply_default_whitespace;
@@ -728,6 +727,14 @@ enum hide_dotfiles_type {
};
extern enum hide_dotfiles_type hide_dotfiles;
+enum log_refs_config {
+ LOG_REFS_UNSET = -1,
+ LOG_REFS_NONE = 0,
+ LOG_REFS_NORMAL,
+ LOG_REFS_ALWAYS
+};
+extern enum log_refs_config log_all_ref_updates;
+
enum branch_track {
BRANCH_TRACK_UNSPECIFIED = -1,
BRANCH_TRACK_NEVER = 0,
diff --git a/config.c b/config.c
index b680f79..c6b874a 100644
--- a/config.c
+++ b/config.c
@@ -826,7 +826,12 @@ static int git_default_core_config(const char *var, const char *value)
}
if (!strcmp(var, "core.logallrefupdates")) {
- log_all_ref_updates = git_config_bool(var, value);
+ if (value && !strcasecmp(value, "always"))
+ log_all_ref_updates = LOG_REFS_ALWAYS;
+ else if (git_config_bool(var, value))
+ log_all_ref_updates = LOG_REFS_NORMAL;
+ else
+ log_all_ref_updates = LOG_REFS_NONE;
return 0;
}
diff --git a/environment.c b/environment.c
index 8a83101..c07fb17 100644
--- a/environment.c
+++ b/environment.c
@@ -21,7 +21,6 @@ int ignore_case;
int assume_unchanged;
int prefer_symlink_refs;
int is_bare_repository_cfg = -1; /* unspecified */
-int log_all_ref_updates = -1; /* unspecified */
int warn_ambiguous_refs = 1;
int warn_on_object_refname_ambiguity = 1;
int ref_paranoia = -1;
@@ -64,6 +63,7 @@ int merge_log_config = -1;
int precomposed_unicode = -1; /* see probe_utf8_pathname_composition() */
unsigned long pack_size_limit_cfg;
enum hide_dotfiles_type hide_dotfiles = HIDE_DOTFILES_DOTGITONLY;
+enum log_refs_config log_all_ref_updates = LOG_REFS_UNSET;
#ifndef PROTECT_HFS_DEFAULT
#define PROTECT_HFS_DEFAULT 0
diff --git a/refs.c b/refs.c
index 9bd0bc1..cd36b64 100644
--- a/refs.c
+++ b/refs.c
@@ -638,12 +638,17 @@ int copy_reflog_msg(char *buf, const char *msg)
int should_autocreate_reflog(const char *refname)
{
- if (!log_all_ref_updates)
+ switch (log_all_ref_updates) {
+ case LOG_REFS_ALWAYS:
+ return 1;
+ case LOG_REFS_NORMAL:
+ return starts_with(refname, "refs/heads/") ||
+ starts_with(refname, "refs/remotes/") ||
+ starts_with(refname, "refs/notes/") ||
+ !strcmp(refname, "HEAD");
+ default:
return 0;
- return starts_with(refname, "refs/heads/") ||
- starts_with(refname, "refs/remotes/") ||
- starts_with(refname, "refs/notes/") ||
- !strcmp(refname, "HEAD");
+ }
}
int is_branch(const char *refname)
diff --git a/refs.h b/refs.h
index 6947843..9fbff90 100644
--- a/refs.h
+++ b/refs.h
@@ -64,6 +64,8 @@ int read_ref(const char *refname, unsigned char *sha1);
int ref_exists(const char *refname);
+int should_autocreate_reflog(const char *refname);
+
int is_branch(const char *refname);
extern int refs_init_db(struct strbuf *err);
diff --git a/refs/files-backend.c b/refs/files-backend.c
index f902393..14b17a6 100644
--- a/refs/files-backend.c
+++ b/refs/files-backend.c
@@ -2682,7 +2682,7 @@ static int files_rename_ref(struct ref_store *ref_store,
}
flag = log_all_ref_updates;
- log_all_ref_updates = 0;
+ log_all_ref_updates = LOG_REFS_NONE;
if (write_ref_to_lockfile(lock, orig_sha1, &err) ||
commit_ref_update(refs, lock, orig_sha1, NULL, &err)) {
error("unable to write current sha1 into %s: %s", oldrefname, err.buf);
@@ -2835,8 +2835,8 @@ static int log_ref_write_1(const char *refname, const unsigned char *old_sha1,
{
int logfd, result, oflags = O_APPEND | O_WRONLY;
- if (log_all_ref_updates < 0)
- log_all_ref_updates = !is_bare_repository();
+ if (log_all_ref_updates == LOG_REFS_UNSET)
+ log_all_ref_updates = is_bare_repository() ? LOG_REFS_NONE : LOG_REFS_NORMAL;
result = log_ref_setup(refname, logfile, err, flags & REF_FORCE_CREATE_REFLOG);
diff --git a/refs/refs-internal.h b/refs/refs-internal.h
index 708b260..25444cf 100644
--- a/refs/refs-internal.h
+++ b/refs/refs-internal.h
@@ -133,8 +133,6 @@ int verify_refname_available(const char *newname,
*/
int copy_reflog_msg(char *buf, const char *msg);
-int should_autocreate_reflog(const char *refname);
-
/**
* Information needed for a single ref update. Set new_sha1 to the new
* value or to null_sha1 to delete the ref. To check the old value
diff --git a/t/t1400-update-ref.sh b/t/t1400-update-ref.sh
index d4fb977..b9084ca 100755
--- a/t/t1400-update-ref.sh
+++ b/t/t1400-update-ref.sh
@@ -93,6 +93,42 @@ test_expect_success 'update-ref creates reflogs with --create-reflog' '
git reflog exists $outside
'
+test_expect_success 'core.logAllRefUpdates=true does not create reflog by default' '
+ test_config core.logAllRefUpdates true &&
+ test_when_finished "git update-ref -d $outside" &&
+ git update-ref $outside $A &&
+ git rev-parse $A >expect &&
+ git rev-parse $outside >actual &&
+ test_cmp expect actual &&
+ test_must_fail git reflog exists $outside
+'
+
+test_expect_success 'core.logAllRefUpdates=always creates reflog by default' '
+ test_config core.logAllRefUpdates always &&
+ test_when_finished "git update-ref -d $outside" &&
+ git update-ref $outside $A &&
+ git rev-parse $A >expect &&
+ git rev-parse $outside >actual &&
+ test_cmp expect actual &&
+ git reflog exists $outside
+'
+
+test_expect_success 'core.logAllRefUpdates=always creates no reflog for ORIG_HEAD' '
+ test_config core.logAllRefUpdates always &&
+ git update-ref ORIG_HEAD $A &&
+ test_must_fail git reflog exists ORIG_HEAD
+'
+
+test_expect_success '--no-create-reflog overrides core.logAllRefUpdates=always' '
+ test_config core.logAllRefUpdates true &&
+ test_when_finished "git update-ref -d $outside" &&
+ git update-ref --no-create-reflog $outside $A &&
+ git rev-parse $A >expect &&
+ git rev-parse $outside >actual &&
+ test_cmp expect actual &&
+ test_must_fail git reflog exists $outside
+'
+
test_expect_success \
"create $m (by HEAD)" \
"git update-ref HEAD $A &&
@@ -501,6 +537,7 @@ test_expect_success 'stdin does not create reflogs by default' '
'
test_expect_success 'stdin creates reflogs with --create-reflog' '
+ test_when_finished "git update-ref -d $outside" &&
echo "create $outside $m" >stdin &&
git update-ref --create-reflog --stdin <stdin &&
git rev-parse $m >expect &&
--
2.10.2
^ permalink raw reply related
* Re: [RFC 00/14] Allow fetch-pack to send ref names (globs allowed)
From: Stefan Beller @ 2017-01-26 22:15 UTC (permalink / raw)
To: Jonathan Tan, Jeff King; +Cc: git@vger.kernel.org
In-Reply-To: <cover.1485381677.git.jonathantanmy@google.com>
On Wed, Jan 25, 2017 at 2:02 PM, Jonathan Tan <jonathantanmy@google.com> wrote:
> Hello everyone - this is a proposal for a protocol change to allow the
> fetch-pack/upload-pack to converse in terms of ref names (globs
> allowed), and also an implementation of the server (upload-pack) and
> fetch-from-HTTP client (fetch-pack invoked through fetch).
>
> Negotiation currently happens by upload-pack initially sending a list of
> refs with names and SHA-1 hashes, and then several request/response
> pairs in which the request from fetch-pack consists of SHA-1 hashes
> (selected from the initial list). Allowing the request to consist of
> names instead of SHA-1 hashes increases tolerance to refs changing
> (due to time, and due to having load-balanced servers without strong
> consistency), and is a step towards eliminating the need for the server
> to send the list of refs first (possibly improving performance).
>
> The protocol is extended by allowing fetch-pack to send
> "want-ref <name>", where <name> is a full name (refs/...) [1], possibly
> including glob characters. Upload-pack will inform the client of the
> refs actually matched by sending "wanted-ref <SHA-1> <name>" before
> sending the last ACK or NAK.
I have reviewed the patches and think they are a good idea,
cc'ing Jeff who you linked to and who had some ideas about the protocol as well.
Stefan
^ permalink raw reply
* Re: [RFC 02/14] upload-pack: allow ref name and glob requests
From: Junio C Hamano @ 2017-01-26 22:23 UTC (permalink / raw)
To: Jonathan Tan; +Cc: git
In-Reply-To: <d0d42b3bb4cf755f122591e191354c53848f197d.1485381677.git.jonathantanmy@google.com>
Jonathan Tan <jonathantanmy@google.com> writes:
> Currently, while performing packfile negotiation [1], upload-pack allows
> clients to specify their desired objects only as SHA-1s. This causes:
> (a) vulnerability to failure when an object turns non-existent during
> negotiation, which may happen if, for example, upload-pack is
> provided by multiple Git servers in a load-balancing arrangement,
> and
> (b) dependence on the server first publishing a list of refs with
> associated objects.
>
> To eliminate (a) and take a step towards eliminating (b), teach
> upload-pack to support requests in the form of ref names and globs (in
> addition to the existing support for SHA-1s) through a new line of the
> form "want-ref <ref>" where ref is the full name of a ref, a glob
> pattern, or a SHA-1. At the conclusion of negotiation, the server will
> write "wanted-ref <SHA-1> <name>" for all requests that have been
> specified this way.
I am not sure if this "at the conclusion of" is sensible. It is OK
to assume that what the client side has is fixed, and it is probably
OK to desire that what the server side has can change, but at the
same time, it feels quite fragile to move the goalpost in between.
Stepping back a bit, in an environment that involves multiple server
instances that have inconsistent set of refs, can the negotiation
even be sensibly and safely implemented? The first server the
client contacts may, in response to a "have", say "I do have that
commit so you do not have to send its ancestors to me. We found one
cut-off point. Please do explore other lines of histories." The
next server that concludes the negotiation exchange may not have
that commit and will be unable to produce a pack that excludes the
objects reachable from that commit---wouldn't that become a problem?
One way to prevent such a problem from hurting clients may be for
these multiple server instances to coordinate and make sure they
have a shared perception of the common history among them. Some
pushes may have come to one instance but may not have propagated to
other instances, and such a commit cannot be accepted as usable
"have" if the servers anticipate that the final client request would
go to any of the servers. Otherwise the multiple server arrangement
would not work safely, methinks.
And if the servers are ensuring the safety using such a mechanism,
they can use the same mechanism to restrain "faster" instances from
sending too fresh state of refs that other instances haven't caught
up to, which would mean they can present a consistent set of refs to
the client in the first place, no?
So I am not sure if the mechanism to request history by refname
instead of the tip commit would help the multi-server environment as
advertised. It may help solving other problems, though (e.g. like
"somebody pushed to update after the initial advertisement was sent
out" which can happen even in a single server environment).
> The server indicates that it supports this feature by advertising the
> capability "ref-in-want". Advertisement of this capability is by default
> disabled, but can be enabled through a configuration option.
OK.
> To be flexible with respect to client needs, the server does not
> indicate an error if a "want-ref" line corresponds to no refs, but
> instead relies on the client to ensure that what the user needs has been
> fetched. For example, a client could reasonably expand an abbreviated
> name "foo" to "want-ref foo", "want-ref refs/heads/foo", "want-ref
> refs/tags/foo", among others, and ensure that at least one such ref has
> been fetched.
Cute. This may be one way to implement the DWIM thing within the
constraint of eventually wanting to go to "client speaks first, the
server does not advertise things the client is not interested in"
world.
But at the same time it may end up bloating the set of refs the
client asks instead. Instead of receiving the advertisement and
then sending one request after picking the matching one from it,
the client needs to send "refs/{heads,tags,whatever}/foo".
^ permalink raw reply
* Re: HEAD's reflog entry for a renamed branch
From: Jeff King @ 2017-01-26 21:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Kyle Meyer, git
In-Reply-To: <xmqqk29h33w1.fsf@gitster.mtv.corp.google.com>
On Thu, Jan 26, 2017 at 01:30:54PM -0800, Junio C Hamano wrote:
> > - "git branch -m" does seem to realize when we are renaming HEAD,
> > because it updates HEAD to point to the new branch name. But it
> > should probably insert another reflog entry mentioning the rename
> > (we do for "git checkout foo", even when "foo" has the same sha1 as
> > the current HEAD).
>
> This one I care less (not in the sense that I prefer it not done,
> but in the sense that I do not mind it is left unfixed than the
> other one you pointed out).
I wondered if it might affect how "git checkout -" works. But that
feature looks for reflogs like "checkout: moving from X to Y" to know to
move back to X. So we are fine here. Even though the HEAD reflog does
not show us going _to_ new-master, we would see it in a later entry as
"from new-master to Y". What we are missing is "rename from master to
new-master", but that entry does not matter. There is no "master" to
go back to anymore. :)
-Peff
^ permalink raw reply
* Re: [PATCH] git-bisect: allow running in a working tree subdirectory
From: Johannes Sixt @ 2017-01-26 21:46 UTC (permalink / raw)
To: marcandre.lureau; +Cc: git, chriscool
In-Reply-To: <20170126183030.28632-1-marcandre.lureau@redhat.com>
Am 26.01.2017 um 19:30 schrieb marcandre.lureau@redhat.com:
> From: Marc-André Lureau <marcandre.lureau@redhat.com>
>
> It looks like it can do it.
>
> Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
> ---
> git-bisect.sh | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/git-bisect.sh b/git-bisect.sh
> index ae3cb013e..b0bd604d4 100755
> --- a/git-bisect.sh
> +++ b/git-bisect.sh
> @@ -1,5 +1,6 @@
> #!/bin/sh
>
> +SUBDIRECTORY_OK=Yes
> USAGE='[help|start|bad|good|new|old|terms|skip|next|reset|visualize|replay|log|run]'
> LONG_USAGE='git bisect help
> print this long help message.
>
Does it also work to drive git bisect from a subdirectory and pass a
file name (or pathspec) that is relative to that subdirectory rather
than relative to the root of the worktree? Can `git bisect good` or `git
bisect bad` of later bisection steps be invoked from different
subdirectories or the root?
-- Hannes
^ permalink raw reply
* Re: HEAD's reflog entry for a renamed branch
From: Junio C Hamano @ 2017-01-26 21:30 UTC (permalink / raw)
To: Jeff King; +Cc: Kyle Meyer, git
In-Reply-To: <20170126211205.5gz3zsrptop7n34n@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> It's unfortunate that there's no message. This is because the rename
> calls delete_ref() under the hood, but that function doesn't take a
> reflog message argument at all. It usually doesn't matter because
> deleting the ref will also delete the reflog.
>
> But as your example shows, deletions _can_ get logged in the HEAD
> reflog; the low-level ref code detects when HEAD points to the updated
> ref and logs an entry there, too.
> ...
> I'd say there are two potential improvements:
>
> - delete_ref() should take a reflog message argument, in case it
> updates the HEAD reflog (as a bonus, this will future-proof us for a
> day when we might keep reflogs for deleted refs).
This sounds sensible.
> - "git branch -m" does seem to realize when we are renaming HEAD,
> because it updates HEAD to point to the new branch name. But it
> should probably insert another reflog entry mentioning the rename
> (we do for "git checkout foo", even when "foo" has the same sha1 as
> the current HEAD).
This one I care less (not in the sense that I prefer it not done,
but in the sense that I do not mind it is left unfixed than the
other one you pointed out).
^ permalink raw reply
* Re: "git fetch -p" incorrectly deletes branches
From: Jeff King @ 2017-01-26 21:18 UTC (permalink / raw)
To: Reimar Döffinger; +Cc: git
In-Reply-To: <20170117060428.nanqz5lr4hi6dum6@reimardoeffinger.de>
On Tue, Jan 17, 2017 at 07:04:28AM +0100, Reimar Döffinger wrote:
> Deletes refs/heads/test every second time when run repeatedly:
>
> $ git fetch -p -v origin master:refs/heads/test
> From https://github.com/git/git
> * [new branch] master -> test
> = [up to date] master -> origin/master
> $ git fetch -p -v origin master:refs/heads/test
> From https://github.com/git/git
> - [deleted] (none) -> test
> = [up to date] master -> test
> = [up to date] master -> origin/master
Hmm. It seems like the problem is that "-p" is saying "the other side
does not have refs/heads/test; we must prune it". But I think it is
probably nonsense to apply pruning to a non-wildcard refspec.
> Also note that this behaviour appears also when fetch.prune=yes
> is set in the config (instead of -p on the command-line),
> which makes it much less obvious and there is no option to turn
> of prune just for that command to work-around this.
There is a separate issue of whether it is sane to apply fetch.prune to
a refspec given on the command line; I can imagine it as surprising, to
say the least.
I think "--no-prune" would disable it, though.
-Peff
^ permalink raw reply
* Re: [PATCH v3 4/4] urlmatch: allow globbing for the URL host part
From: Junio C Hamano @ 2017-01-26 21:12 UTC (permalink / raw)
To: Patrick Steinhardt; +Cc: git, Patrick Steinhardt, Philip Oakley
In-Reply-To: <xmqq37g54kdz.fsf@gitster.mtv.corp.google.com>
Junio C Hamano <gitster@pobox.com> writes:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> + while (url_len && pat_len) {
>> + const char *url_next = end_of_token(url, '.', url_len);
>> + const char *pat_next = end_of_token(pat, '.', pat_len);
>> + ...
>> }
>>
>> + return 1;
>
> Embarrassing. The last one must be "have they both run out?" i.e.
>
> return (!url_len && !pat_len);
OK, here is my second try. The added test piece is to catch the
silly mistake I made above.
diff --git a/t/t1300-repo-config.sh b/t/t1300-repo-config.sh
index ec545e0929..33fd59fbb3 100755
--- a/t/t1300-repo-config.sh
+++ b/t/t1300-repo-config.sh
@@ -1177,7 +1177,7 @@ test_expect_success 'urlmatch' '
test_cmp expect actual
'
-test_expect_success 'glob-based urlmatch' '
+test_expect_success 'urlmatch with wildcard' '
cat >.git/config <<-\EOF &&
[http]
sslVerify
@@ -1210,6 +1210,10 @@ test_expect_success 'glob-based urlmatch' '
echo http.sslverify false
} >expect &&
git config --get-urlmatch HTTP https://good.example.com >actual &&
+ test_cmp expect actual &&
+
+ echo http.sslverify >expect &&
+ git config --get-urlmatch HTTP https://more.example.com.au >actual &&
test_cmp expect actual
'
diff --git a/urlmatch.c b/urlmatch.c
index 53ff972a60..0e007a3e07 100644
--- a/urlmatch.c
+++ b/urlmatch.c
@@ -63,36 +63,47 @@ static int append_normalized_escapes(struct strbuf *buf,
return 1;
}
+static const char *end_of_token(const char *s, int c, size_t n)
+{
+ const char *next = memchr(s, c, n);
+ if (!next)
+ next = s + n;
+ return next;
+}
+
static int match_host(const struct url_info *url_info,
const struct url_info *pattern_info)
{
- char *url = xmemdupz(url_info->url + url_info->host_off, url_info->host_len);
- char *pat = xmemdupz(pattern_info->url + pattern_info->host_off, pattern_info->host_len);
- char *url_tok, *pat_tok, *url_save, *pat_save;
- int matching;
-
- url_tok = strtok_r(url, ".", &url_save);
- pat_tok = strtok_r(pat, ".", &pat_save);
-
- for (; url_tok && pat_tok; url_tok = strtok_r(NULL, ".", &url_save),
- pat_tok = strtok_r(NULL, ".", &pat_save)) {
- if (!strcmp(pat_tok, "*"))
- continue; /* a simple glob matches everything */
-
- if (strcmp(url_tok, pat_tok)) {
- /* subdomains do not match */
- matching = 0;
- break;
- }
+ const char *url = url_info->url + url_info->host_off;
+ const char *pat = pattern_info->url + pattern_info->host_off;
+ int url_len = url_info->host_len;
+ int pat_len = pattern_info->host_len;
+
+ while (url_len && pat_len) {
+ const char *url_next = end_of_token(url, '.', url_len);
+ const char *pat_next = end_of_token(pat, '.', pat_len);
+
+ if (pat_next == pat + 1 && pat[0] == '*')
+ /* wildcard matches anything */
+ ;
+ else if ((pat_next - pat) == (url_next - url) &&
+ !memcmp(url, pat, url_next - url))
+ /* the components are the same */
+ ;
+ else
+ return 0; /* found an unmatch */
+
+ if (url_next < url + url_len)
+ url_next++;
+ url_len -= url_next - url;
+ url = url_next;
+ if (pat_next < pat + pat_len)
+ pat_next++;
+ pat_len -= pat_next - pat;
+ pat = pat_next;
}
- /* matching if both URL and pattern are at their ends */
- matching = (url_tok == NULL && pat_tok == NULL);
-
- free(url);
- free(pat);
-
- return matching;
+ return (!url_len && !pat_len);
}
static char *url_normalize_1(const char *url, struct url_info *out_info, char allow_globs)
^ permalink raw reply related
* Re: HEAD's reflog entry for a renamed branch
From: Jeff King @ 2017-01-26 21:12 UTC (permalink / raw)
To: Kyle Meyer; +Cc: git
In-Reply-To: <87pojmwq5y.fsf@kyleam.com>
On Mon, Jan 16, 2017 at 06:17:29PM -0500, Kyle Meyer wrote:
> I noticed that, after renaming the current branch, the corresponding
> message in .git/logs/HEAD is empty.
>
> For example, running
>
> $ mkdir test-repo
> $ cd test-repo
> $ git init
> $ echo abc >file.txt
> $ git add file.txt
> $ git commit -m"Add file.txt"
> $ git branch -m master new-master
Thanks for providing a simple reproduction recipe.
> resulted in the following reflogs:
>
> $ cat .git/logs/refs/heads/new-master
> 00000... 68730... Kyle Meyer <kyle@kyleam.com> 1484607020 -0500 commit (initial): Add file.txt
> 68730... 68730... Kyle Meyer <kyle@kyleam.com> 1484607020 -0500 Branch: renamed refs/heads/master to refs/heads/new-master
>
> $ cat .git/logs/HEAD
> 00000... 68730... Kyle Meyer <kyle@kyleam.com> 1484607020 -0500 commit (initial): Add file.txt
> 68730... 00000... Kyle Meyer <kyle@kyleam.com> 1484607020 -0500
>
> I expected the second line of .git/logs/HEAD to mirror the second line
> of .git/logs/refs/heads/new-master. Are the empty message and null sha1
> in HEAD's entry intentional?
The null sha1 is correct, I think. The branch we were on went away, and
we use the null sha1 to indicate "no value" in both the creation and
deletion cases.
It's unfortunate that there's no message. This is because the rename
calls delete_ref() under the hood, but that function doesn't take a
reflog message argument at all. It usually doesn't matter because
deleting the ref will also delete the reflog.
But as your example shows, deletions _can_ get logged in the HEAD
reflog; the low-level ref code detects when HEAD points to the updated
ref and logs an entry there, too.
You can see the same thing with a simpler example:
$ git init
$ git commit -m foo --allow-empty
$ git update-ref -d refs/heads/master
$ cat .git/logs/HEAD
00000... 8ffd1... Jeff King <peff@peff.net> 1485464779 -0500 commit (initial): foo
8ffd1... 00000... Jeff King <peff@peff.net> 1485464787 -0500
This doesn't come up much because most porcelain commands will refuse to
delete the current branch (notice I had to use "update-ref" and not
"branch -d").
I'd say there are two potential improvements:
- delete_ref() should take a reflog message argument, in case it
updates the HEAD reflog (as a bonus, this will future-proof us for a
day when we might keep reflogs for deleted refs).
- "git branch -m" does seem to realize when we are renaming HEAD,
because it updates HEAD to point to the new branch name. But it
should probably insert another reflog entry mentioning the rename
(we do for "git checkout foo", even when "foo" has the same sha1 as
the current HEAD).
-Peff
^ permalink raw reply
* Re: SubmittingPatches: drop temporal reference for PGP signing
From: Philip Oakley @ 2017-01-26 20:58 UTC (permalink / raw)
To: Junio C Hamano, Cornelius Weig
Cc: Stefan Beller, Johannes Sixt, bitte.keine.werbung.einwerfen, git,
thomas.braun, John Keeping
In-Reply-To: <xmqqpoj965yf.fsf@gitster.mtv.corp.google.com>
From: "Junio C Hamano" <gitster@pobox.com>
> Cornelius Weig <cornelius.weig@tngtech.com> writes:
>
>> How about something along these lines? Does the forward reference
>> break the main line of thought too severly?
>
> I find it a bit distracting for those who know PGP signing has
> nothing to do with signing off your patch, but I think that is OK
> because they are not the primary target audience of this part of the
> document.
Agreed. I this case the target audience was those weren't aware of that.
>
> I however am more worried that it may be misleading to mention these
> two in the same sentence. Those who skim these paragraphs without
> knowing the difference between the two may get a false impression
> that these two may somehow be related because they are mentioned in
> the same sentence.
>
> The retitling of section (5) you did, without any other change,
> might be sufficient. It may also help to be even more explicit in
> the updated title, i.e. s/by signing off/by adding Signed-off-by:/
Maybe even s/by signing off/by adding your Signed-off-by:/ to be sure that
the reader knows that it is _their certification_ that is being sought. Even
if it does double up on the 'your'.
>
> Thanks.
>
>> diff --git a/Documentation/SubmittingPatches
>> b/Documentation/SubmittingPatches
>> index 08352de..c2b0cbe 100644
>> --- a/Documentation/SubmittingPatches
>> +++ b/Documentation/SubmittingPatches
>> @@ -216,12 +216,12 @@ that it will be postponed.
>> Exception: If your mailer is mangling patches then someone may ask
>> you to re-send them using MIME, that is OK.
>>
>> -Do not PGP sign your patch, at least for now. Most likely, your
>> -maintainer or other people on the list would not have your PGP
>> -key and would not bother obtaining it anyway. Your patch is not
>> -judged by who you are; a good patch from an unknown origin has a
>> -far better chance of being accepted than a patch from a known,
>> -respected origin that is done poorly or does incorrect things.
>> +Do not PGP sign your patch, but do sign-off your work as explained in
>> (5).
>> +Most likely, your maintainer or other people on the list would not have
>> your
>> +PGP key and would not bother obtaining it anyway. Your patch is not
>> judged by
>> +who you are; a good patch from an unknown origin has a far better chance
>> of
>> +being accepted than a patch from a known, respected origin that is done
>> poorly
>> +or does incorrect things.
>>
>> If you really really really really want to do a PGP signed
>> patch, format it as "multipart/signed", not a text/plain message
>> @@ -246,7 +246,7 @@ patch.
>> *2* The mailing list: git@vger.kernel.org
>>
>>
>> -(5) Sign your work
>> +(5) Certify your work by signing off
>>
>> To improve tracking of who did what, we've borrowed the
>> "sign-off" procedure from the Linux kernel project on patches
>
^ permalink raw reply
* Re: Force Confirmation for Dropping Changed Lines
From: Junio C Hamano @ 2017-01-26 20:51 UTC (permalink / raw)
To: Hilco Wijbenga; +Cc: Jacob Keller, Git Users
In-Reply-To: <CAE1pOi0foJpZXSpHrbWqvOuG1+VoNKTCMjuLK5TCVcJuGMSOoQ@mail.gmail.com>
Hilco Wijbenga <hilco.wijbenga@gmail.com> writes:
> On 25 January 2017 at 18:32, Junio C Hamano <gitster@pobox.com> wrote:
>> I think you should be able to do something like
>>
>> $ cat >$HOME/bin/fail-3way <<\EOF
>> #!/bin/sh
>> git merge-file "$@"
>> exit 1
>> EOF
>> $ chmod +x $HOME/bin/fail-3way
>> $ cat >>$HOME/.gitconfig <<\EOF
>> [merge "fail"]
>> name = always fail 3-way merge
>> driver = $HOME/bin/fail-3way %A %O %B
>> recursive = text
>> EOF
>> $ echo pom.xml merge=fail >>.gitattributes
>>
>> to define a custom merge driver whose name is "fail", that runs the
>> fail-3way program, which runs the bog standard 3-way merge we use
>> (so that it will do the best-effort textual merge) but always return
>> with a non-zero status to signal that the result is conflicting and
>> needs manual resolution.
>
> Thank you, that's an improvement. :-) Unfortunately, it still
> completes the merge. Is there any way to simply get the
>>>>>>>>>/<<<<<<<< markers?
You can, but you need to write one yourself without relying on "git
merge-file", because the whole point of the 3way merge we implement
(including in that program) is "do not bother the user when both
sides made the same change."
^ 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