* Re: [PATCH v3 07/10] fetch: implement fetch.fsck.*
@ 2018-07-27 21:08 5% ` Junio C Hamano
0 siblings, 0 replies; 114+ results
From: Junio C Hamano @ 2018-07-27 21:08 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason
Cc: git, Johannes Schindelin, Jeff King, Eric Sunshine,
Christian Couder
Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
> - argv_array_push(&cmd.args, "--strict");
> + argv_array_pushf(&cmd.args, "--strict%s",
> + fsck_msg_types.buf);
> ...
> + if (git_config_pathname(&path, var, value))
> + return 1;
> + strbuf_addf(&fsck_msg_types, "%cskiplist=%s",
> + fsck_msg_types.len ? ',' : '=', path);
> ...
> + if (is_valid_msg_type(var, value))
> + strbuf_addf(&fsck_msg_types, "%c%s=%s",
> + fsck_msg_types.len ? ',' : '=', var, value);
> + else
> + warning("Skipping unknown msg id '%s'", var);
This follows quite familiar pattern found in receive_pack_config();
looking good.
> diff --git a/t/t5504-fetch-receive-strict.sh b/t/t5504-fetch-receive-strict.sh
> index 57ff78c201..004bfebe98 100755
> --- a/t/t5504-fetch-receive-strict.sh
> +++ b/t/t5504-fetch-receive-strict.sh
> @@ -145,6 +145,20 @@ test_expect_success 'push with receive.fsck.skipList' '
> git push --porcelain dst bogus
> '
>
> +test_expect_success 'fetch with fetch.fsck.skipList' '
> + commit="$(git hash-object -t commit -w --stdin <bogus-commit)" &&
> + refspec=refs/heads/bogus:refs/heads/bogus &&
> + git push . $commit:refs/heads/bogus &&
I see this used in the previous test for receive.fsck.skipList, but
it is an interesting implementation of "git update-ref" that could
be affected by potential fsck error in push-to-receive-pack transport.
As we are interested in transport into "dst" and we want this creation
of our 'bogus' branch to succeed no matter what, it probably is not
a good idea to use "git push ." like this in the context of this test.
Perhaps leave a 'leftoverbits' comment to force us remember to update
all these uses of local push from the script in the future?
> + rm -rf dst &&
> + git init dst &&
> + git --git-dir=dst/.git config fetch.fsckObjects true &&
> + test_must_fail git --git-dir=dst/.git fetch "file://$(pwd)" $refspec &&
We see that by default fetch.fsckObjects errors out when it notices
the bogus commit object.
> + git --git-dir=dst/.git config fetch.fsck.skipList dst/.git/SKIP &&
> + echo $commit >dst/.git/SKIP &&
And then we set up a skip to see ...
> + git --git-dir=dst/.git fetch "file://$(pwd)" $refspec
... if that is ignored. Looks great.
Would this second attempt succeed _without_ the SKIP list, I wonder,
though?
After the initial attempt that transferred the object, inspected it
and then aborted before pointing a ref to make the object reachable,
wouldn't it be possible for the quickfetch codepath to say "ah, we
locally have that object, so let's see it is a descendant of the tip
of one of our refs *and* all the objects it points at (recursively)
are all available in this repository", as we do not quarantine on
the fetch side?
^ permalink raw reply [relevance 5%]
* Re: [PATCH v2 02/23] archive-tar.c: mark more strings for translation
2018-07-19 18:21 6% ` Junio C Hamano
@ 2018-07-21 6:18 0% ` Duy Nguyen
0 siblings, 0 replies; 114+ results
From: Duy Nguyen @ 2018-07-21 6:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List, Elijah Newren, Derrick Stolee
On Thu, Jul 19, 2018 at 8:21 PM Junio C Hamano <gitster@pobox.com> wrote:
>
> Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
>
> > @@ -256,7 +256,7 @@ static int write_tar_entry(struct archiver_args *args,
> > *header.typeflag = TYPEFLAG_REG;
> > mode = (mode | ((mode & 0100) ? 0777 : 0666)) & ~tar_umask;
> > } else {
> > - return error("unsupported file mode: 0%o (SHA1: %s)",
> > + return error(_("unsupported file mode: 0%o (SHA1: %s)"),
> > mode, oid_to_hex(oid));
>
> This is no longer sha1_to_hex(); the "SHA1" in the message should
> probably have been updated when it happened.
>
> Cleaning it up is outside the scope of this patch.
Yeah. I also asked Brian [1] what to use here instead. I think it's
much easier to go through git.pot then fix all at once. Whatever
leftover after that could be fixed as we see them.
[1] https://public-inbox.org/git/20180603182724.GA288937@genre.crustytoothpaste.net/
> #leftoverbits
--
Duy
^ permalink raw reply [relevance 0%]
* Re: [PATCH v2 03/23] archive-zip.c: mark more strings for translation
@ 2018-07-19 18:26 6% ` Junio C Hamano
0 siblings, 0 replies; 114+ results
From: Junio C Hamano @ 2018-07-19 18:26 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git, Elijah Newren, Derrick Stolee
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> - return error("path too long (%d chars, SHA1: %s): %s",
> + return error(_("path too long (%d chars, SHA1: %s): %s"),
> - return error("unsupported file mode: 0%o (SHA1: %s)", mode,
> + return error(_("unsupported file mode: 0%o (SHA1: %s)"), mode,
The same #leftoverbits comment as 02/23 applies here.
> @@ -601,7 +601,7 @@ static void dos_time(timestamp_t *timestamp, int *dos_date, int *dos_time)
> struct tm *t;
>
> if (date_overflows(*timestamp))
> - die("timestamp too large for this system: %"PRItime,
> + die(_("timestamp too large for this system: %"PRItime),
> *timestamp);
I suspect that this won't do the right "cross-platform" thing. For
built-in PRItype formats gettext tool knows about, *.po files let
translators translate original with "%<PRItype>" into localized text
with the same "%<PRItype>" left, and the runtime does the right
thing, but for a custom format like PRItime there is no such
support.
^ permalink raw reply [relevance 6%]
* Re: [PATCH v2 02/23] archive-tar.c: mark more strings for translation
@ 2018-07-19 18:21 6% ` Junio C Hamano
2018-07-21 6:18 0% ` Duy Nguyen
0 siblings, 1 reply; 114+ results
From: Junio C Hamano @ 2018-07-19 18:21 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git, Elijah Newren, Derrick Stolee
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> @@ -256,7 +256,7 @@ static int write_tar_entry(struct archiver_args *args,
> *header.typeflag = TYPEFLAG_REG;
> mode = (mode | ((mode & 0100) ? 0777 : 0666)) & ~tar_umask;
> } else {
> - return error("unsupported file mode: 0%o (SHA1: %s)",
> + return error(_("unsupported file mode: 0%o (SHA1: %s)"),
> mode, oid_to_hex(oid));
This is no longer sha1_to_hex(); the "SHA1" in the message should
probably have been updated when it happened.
Cleaning it up is outside the scope of this patch.
#leftoverbits
^ permalink raw reply [relevance 6%]
* Re: [PATCH] diff.c: offer config option to control ws handling in move detection
@ 2018-07-19 17:29 6% ` Stefan Beller
0 siblings, 0 replies; 114+ results
From: Stefan Beller @ 2018-07-19 17:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
On Thu, Jul 19, 2018 at 9:29 AM Junio C Hamano <gitster@pobox.com> wrote:
>
> Stefan Beller <sbeller@google.com> writes:
>
> > On Wed, Jul 18, 2018 at 10:45 AM Junio C Hamano <gitster@pobox.com> wrote:
> >>
> >> Stefan Beller <sbeller@google.com> writes:
> >>
> >> > diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
> >> > index 143acd9417e..8da7fed4e22 100644
> >> > --- a/Documentation/diff-options.txt
> >> > +++ b/Documentation/diff-options.txt
> >> > @@ -294,8 +294,11 @@ dimmed_zebra::
> >> >
> >> > --color-moved-ws=<modes>::
> >> > This configures how white spaces are ignored when performing the
> >> > - move detection for `--color-moved`. These modes can be given
> >> > - as a comma separated list:
> >> > + move detection for `--color-moved`.
> >> > +ifdef::git-diff[]
> >> > + It can be set by the `diff.colorMovedWS` configuration setting.
> >> > +endif::git-diff[]
> >>
> >> The patch to diff.c::git_diff_ui_config() we see below does not seem
> >> to make any effort to make sure that this new configuration applies
> >> only to "git diff" and that other commands like "git log" that call
> >> git_diff_ui_config() are not affected.
> >
> > That is as intended. (We want to have it in git-log)
>
> Ah, I think what is going on here, and I think I asked a wrong
> question.
>
> * diff-options.txt is used by the family of diff plumbing commands
> (which actively do not want to participate in the coloring game
> and do not call git_diff_ui_config()) as well as log family of
> commands (which do pay attention to the config).
>
> * "git grep '^:git-diff:'" hits only Documentation/git-diff.txt.
>
> What the system currently does (which may not match what it should
> do) is that Porcelain "diff", "log", etc. pay attention to the
> configuration while plumbing "diff-{files,index,tree}" don't, and
> use of ifdef/endif achieves only half of that (i.e. excludes the
> sentence from plumbing manual pages). It excludes too much and does
> not say "log", "show", etc. also honor the configuration.
>
> I think the set of asciidoc attrs diff-options.txt files uses need
> some serious clean-up. For example, it defines :git-diff-core: that
> is only used once, whose intent seems to be "we are describing diff
> plumbing". However, the way it does so is by excluding known
> Porcelain; if we ever add new diff porcelain (e.g. "range-diff"),
> that way of 'definition by exclusion' would break. The scheme is
> already broken by forcing git-show.txt to define 'git-log' just like
> git-log.txt does, meaning that it is not possible to make "show" to
> be described differently from "log". But let's leave that outside
> this topic.
Then let's call this #leftoverbits ?
> Back to a more on-topic tangent.
>
> How does this patch (and all the recent "color" options you added
> recently) avoid spending unnecessary cycles and contaminating "git
> format-patch" output, by the way? builtin/log.c::cmd_format_patch()
> seems to eventually call into git_log_config() that ends with a call
> to diff_ui_config().
The color options are only using CPU cycles when we actually need to
color things (if no-color is set, then the move detection is off).
"git format-patch HEAD^ --color" produces red/green output
(like git log would), so I do not see why --color-moved should impact
format-patch differently. (i.e. if the user requests format-patch with
color-moved we can do it, otherwise, when colors are off, we do not
spend cycles to compute the moves)
Maybe I did not understand the gist of your question, still?
Stefan
^ permalink raw reply [relevance 6%]
* Re: [PATCH 4/8] gpg-interface: introduce an abstraction for multiple gpg formats
@ 2018-07-10 15:51 6% ` Junio C Hamano
0 siblings, 0 replies; 114+ results
From: Junio C Hamano @ 2018-07-10 15:51 UTC (permalink / raw)
To: Jeff King
Cc: Martin Ågren, Henning Schild, Git Mailing List, Ben Toews,
Taylor Blau, brian m . carlson, Eric Sunshine
Jeff King <peff@peff.net> writes:
> On Fri, Jul 06, 2018 at 10:24:58AM -0700, Junio C Hamano wrote:
>
>> What we've been avoiding was the comma after the last element in the
>> enum (in other words, if PGP_FMT had ',' after it in the above
>> quoted addition, that would have been violation of that rule), as
>> having such a trailing comma used to be ANSI C violation as well. I
>> do not recall offhand if we loosened that deliberately.
>>
>> 4b05548f ("enums: omit trailing comma for portability", 2010-05-14),
>> c9b6782a ("enums: omit trailing comma for portability", 2011-03-16)
>
> I think we accidentally did a weather-balloon in e1327023ea (grep:
> refactor the concept of "grep source" into an object, 2012-02-02).
> It's still there and nobody has complained about it yet.
>
> So I think we can consider that requirement loosened at this point.
#leftoverbits: update CodingGuidelines and refer to these three
commits.
Takers?
^ permalink raw reply [relevance 6%]
* Re: [PATCH v3 4/4] builtin/rebase: support running "git rebase <upstream>"
2018-07-07 6:45 6% ` Christian Couder
2018-07-07 11:59 0% ` Johannes Schindelin
@ 2018-07-07 16:24 6% ` Junio C Hamano
1 sibling, 0 replies; 114+ results
From: Junio C Hamano @ 2018-07-07 16:24 UTC (permalink / raw)
To: Christian Couder
Cc: Pratik Karki, git, Johannes Schindelin, Stefan Beller,
Alban Gruin
Christian Couder <christian.couder@gmail.com> writes:
>> + default:
>> + BUG("Unhandled rebase type %d", opts->type);
>> + break;
>
> Nit: I think the "break;" line could be removed as the BUG() should always exit.
>
> A quick grep shows that there are other places where there is a
> "break;" line after a BUG() though. Maybe one of the #leftoverbits
> could be about removing those "break;" lines.
I do not see the above as nit, though. "could" is often quite a
different thing from "should", and in this case (and all the other
cases you incorrectly mark with %leftoverbits) removal of these
lines does not improve readability. In fact, if there were another
case arm after this one, having "break" there would help those who
scan the code, as the person who wants to ensure what that next case
arm does is correct is given a strong hint by "break;" immediately
before it that nothing in the previous case arm matters and does not
have to even be looked at. By removing it you force such a reader
to notice BUG() and reason that it does not matter because it does
not return control to us (hence no fallthru).
^ permalink raw reply [relevance 6%]
* Re: [PATCH v3 4/4] builtin/rebase: support running "git rebase <upstream>"
2018-07-07 6:45 6% ` Christian Couder
@ 2018-07-07 11:59 0% ` Johannes Schindelin
2018-07-07 16:24 6% ` Junio C Hamano
1 sibling, 0 replies; 114+ results
From: Johannes Schindelin @ 2018-07-07 11:59 UTC (permalink / raw)
To: Christian Couder
Cc: Pratik Karki, git, Stefan Beller, Alban Gruin, Junio C Hamano
Hi Christian,
On Sat, 7 Jul 2018, Christian Couder wrote:
> On Fri, Jul 6, 2018 at 2:08 PM, Pratik Karki <predatoramigo@gmail.com> wrote:
>
> > + switch (opts->type) {
> > + case REBASE_AM:
> > + backend = "git-rebase--am";
> > + backend_func = "git_rebase__am";
> > + break;
> > + case REBASE_INTERACTIVE:
> > + backend = "git-rebase--interactive";
> > + backend_func = "git_rebase__interactive";
> > + break;
> > + case REBASE_MERGE:
> > + backend = "git-rebase--merge";
> > + backend_func = "git_rebase__merge";
> > + break;
> > + case REBASE_PRESERVE_MERGES:
> > + backend = "git-rebase--preserve-merges";
> > + backend_func = "git_rebase__preserve_merges";
> > + break;
> > + default:
> > + BUG("Unhandled rebase type %d", opts->type);
> > + break;
>
> Nit: I think the "break;" line could be removed as the BUG() should always exit.
>
> A quick grep shows that there are other places where there is a
> "break;" line after a BUG() though. Maybe one of the #leftoverbits
> could be about removing those "break;" lines.
But what if there is a bug in the BUG() function? Shouldn't we then not
call `die()` directly after the `BUG()`?
Okay, sorry, I let myself loose a little, as I think that we are still
safely in the territory where the code needs to be made correct. We can
nitpick when there are no "biggies" left to comment about. Maybe focus a
little more on whether the code does what it should do, rather than
whether some stylistic guidelines are violated?
I mean, we can argue back and forth about white-space, indentation,
superfluous break statements, etc. But that way, we won't get anywhere
with the builtin rebase.
Let's help Pratik instead to complete his project, okay?
Ciao,
Dscho
^ permalink raw reply [relevance 0%]
* Re: [PATCH v3 4/4] builtin/rebase: support running "git rebase <upstream>"
@ 2018-07-07 6:45 6% ` Christian Couder
2018-07-07 11:59 0% ` Johannes Schindelin
2018-07-07 16:24 6% ` Junio C Hamano
0 siblings, 2 replies; 114+ results
From: Christian Couder @ 2018-07-07 6:45 UTC (permalink / raw)
To: Pratik Karki
Cc: git, Johannes Schindelin, Stefan Beller, Alban Gruin,
Junio C Hamano
On Fri, Jul 6, 2018 at 2:08 PM, Pratik Karki <predatoramigo@gmail.com> wrote:
> + switch (opts->type) {
> + case REBASE_AM:
> + backend = "git-rebase--am";
> + backend_func = "git_rebase__am";
> + break;
> + case REBASE_INTERACTIVE:
> + backend = "git-rebase--interactive";
> + backend_func = "git_rebase__interactive";
> + break;
> + case REBASE_MERGE:
> + backend = "git-rebase--merge";
> + backend_func = "git_rebase__merge";
> + break;
> + case REBASE_PRESERVE_MERGES:
> + backend = "git-rebase--preserve-merges";
> + backend_func = "git_rebase__preserve_merges";
> + break;
> + default:
> + BUG("Unhandled rebase type %d", opts->type);
> + break;
Nit: I think the "break;" line could be removed as the BUG() should always exit.
A quick grep shows that there are other places where there is a
"break;" line after a BUG() though. Maybe one of the #leftoverbits
could be about removing those "break;" lines.
> + }
^ permalink raw reply [relevance 6%]
* Re: [BUG] url schemes should be case-insensitive
2018-06-26 12:21 0% ` Jeff King
@ 2018-06-26 17:09 0% ` Junio C Hamano
0 siblings, 0 replies; 114+ results
From: Junio C Hamano @ 2018-06-26 17:09 UTC (permalink / raw)
To: Jeff King; +Cc: git
Jeff King <peff@peff.net> writes:
>> > We seem to match url schemes case-sensitively:
>> >
>> > $ git clone SSH://example.com/repo.git
>> > Cloning into 'repo'...
>> > fatal: Unable to find remote helper for 'SSH'
>> >
>> > whereas rfc3986 is clear that the scheme portion is case-insensitive.
>> > We probably ought to match at least our internal ones with strcasecmp.
>>
>> That may break if somebody at DevToolGroup@$BIGCOMPANY got cute and
>> named their custom remote helper SSH:// that builds on top of the
>> normal ssh:// protocol with something extra and gave it to their
>> developers (and they named the http counterpart that has the same
>> extra HTTP://, of course).
>
> True, though I am on the fence whether that is a property worth
> maintaining. AFAIK it was not planned and is just a "this is how it
> happened to work" case that is (IMHO) doing the wrong thing.
FWIW, I fully agree with the assessment; sorry for not saying that
together with the devil's advocate comment to save a round-tip.
> It may also interact in a funny way with our allowed-protocol code, if
> "SSH" gets a pass as "ssh" under the default config, but actually runs
> the otherwise-disallowed git-remote-SSH (though one would _hope_ if you
> have such a git-remote-SSH that it behaves just like an ssh remote).
True. I did not offhand recall how protocol whitelist matches the
protocol name with config, but transport.c::get_protocol_config()
seems to say that the <name> part of "protocol.<name>.allow" is case
sensitive, and we match known-safe (and known-unsafe "ext::")
protocols with strcmp() not strcasecmp(). We need to figure out the
implications of allowing SSH:// not to error out but pretending as
if it were ssh:// on those who have protocol.ssh.allow defined.
>> > We could probably also give an advise() message in the above output,
>> > suggesting that the problem is likely one of:
>> >
>> > 1. They misspelled the scheme.
>> >
>> > 2. They need to install the appropriate helper.
>> >
>> > This may be a good topic for somebody looking for low-hanging fruit to
>> > get involved in development (I'd maybe call it a #leftoverbits, but
>> > since I didn't start on it, I'm not sure if it counts as "left over" ;)).
>> [..]
>> It may probably be a good idea to do an advice, but I'd think
>> "Untable to find remote helper for 'SSH'" may be clear enough. If
>> anything, perhaps saying "remote helper for 'SSH' protocol" would
>> make it even clear? I dunno.
>
> I think it doesn't help much if the user does not know what a remote
> helper is, or why Git is looking for one.
True.
$ git clone SSH://example.com/repo.git
fatal: unable to handle URL that begins with SSH://
would be clear enough, perhaps? At least this line of change is a
small first step that would improve the situation without potential
to break anybody who has been abusing the case sensitivity loophole.
^ permalink raw reply [relevance 0%]
* Re: [BUG] url schemes should be case-insensitive
2018-06-25 18:19 6% ` Junio C Hamano
@ 2018-06-26 12:21 0% ` Jeff King
2018-06-26 17:09 0% ` Junio C Hamano
0 siblings, 1 reply; 114+ results
From: Jeff King @ 2018-06-26 12:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
On Mon, Jun 25, 2018 at 11:19:51AM -0700, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > We seem to match url schemes case-sensitively:
> >
> > $ git clone SSH://example.com/repo.git
> > Cloning into 'repo'...
> > fatal: Unable to find remote helper for 'SSH'
> >
> > whereas rfc3986 is clear that the scheme portion is case-insensitive.
> > We probably ought to match at least our internal ones with strcasecmp.
>
> That may break if somebody at DevToolGroup@$BIGCOMPANY got cute and
> named their custom remote helper SSH:// that builds on top of the
> normal ssh:// protocol with something extra and gave it to their
> developers (and they named the http counterpart that has the same
> extra HTTP://, of course).
True, though I am on the fence whether that is a property worth
maintaining. AFAIK it was not planned and is just a "this is how it
happened to work" case that is (IMHO) doing the wrong thing.
c.f. https://xkcd.com/1172/
Is this a hypothetical, or do you know of a $BIGCOMPANY that uses this?
The only similar case I know of is contrib/persistent-https, where we
realized the better way to do it is:
[url "my-custom-ssh://"]
insteadOf = ssh://
> If we probe for git-remote-SSH first and
> then fall back to git-remote-ssh, then we won't break these people,
> though. I agree that it may be a good bite-sized #leftoverbit
> material.
This is probably a little tricky to implement, since there is no
git-remote-ssh, and we handle it internally in a totally separate
code path. So "probe for git-remote-SSH" is probably not "try to run
it", but really "search the PATH for something plausible". That may be
good enough.
It may also interact in a funny way with our allowed-protocol code, if
"SSH" gets a pass as "ssh" under the default config, but actually runs
the otherwise-disallowed git-remote-SSH (though one would _hope_ if you
have such a git-remote-SSH that it behaves just like an ssh remote).
> > We could probably also give an advise() message in the above output,
> > suggesting that the problem is likely one of:
> >
> > 1. They misspelled the scheme.
> >
> > 2. They need to install the appropriate helper.
> >
> > This may be a good topic for somebody looking for low-hanging fruit to
> > get involved in development (I'd maybe call it a #leftoverbits, but
> > since I didn't start on it, I'm not sure if it counts as "left over" ;)).
> [..]
> It may probably be a good idea to do an advice, but I'd think
> "Untable to find remote helper for 'SSH'" may be clear enough. If
> anything, perhaps saying "remote helper for 'SSH' protocol" would
> make it even clear? I dunno.
I think it doesn't help much if the user does not know what a remote
helper is, or why Git is looking for one. Though at least it gives a
term to start searching for, I guess. The original motivation for my
mail was the real-world report at:
https://github.com/git/git-scm.com/issues/1219
-Peff
^ permalink raw reply [relevance 0%]
* Re: [BUG] url schemes should be case-insensitive
2018-06-24 8:56 6% [BUG] url schemes should be case-insensitive Jeff King
@ 2018-06-25 18:19 6% ` Junio C Hamano
2018-06-26 12:21 0% ` Jeff King
0 siblings, 1 reply; 114+ results
From: Junio C Hamano @ 2018-06-25 18:19 UTC (permalink / raw)
To: Jeff King; +Cc: git
Jeff King <peff@peff.net> writes:
> We seem to match url schemes case-sensitively:
>
> $ git clone SSH://example.com/repo.git
> Cloning into 'repo'...
> fatal: Unable to find remote helper for 'SSH'
>
> whereas rfc3986 is clear that the scheme portion is case-insensitive.
> We probably ought to match at least our internal ones with strcasecmp.
That may break if somebody at DevToolGroup@$BIGCOMPANY got cute and
named their custom remote helper SSH:// that builds on top of the
normal ssh:// protocol with something extra and gave it to their
developers (and they named the http counterpart that has the same
extra HTTP://, of course). If we probe for git-remote-SSH first and
then fall back to git-remote-ssh, then we won't break these people,
though. I agree that it may be a good bite-sized #leftoverbit
material.
> Possibly we should also normalize external helpers (so "FOO://bar" would
> always call git-remote-foo, never git-remote-FOO).
> We could probably also give an advise() message in the above output,
> suggesting that the problem is likely one of:
>
> 1. They misspelled the scheme.
>
> 2. They need to install the appropriate helper.
>
> This may be a good topic for somebody looking for low-hanging fruit to
> get involved in development (I'd maybe call it a #leftoverbits, but
> since I didn't start on it, I'm not sure if it counts as "left over" ;)).
Well, noticing an issue, analysing and discussing potential
improvements and their ramifications is already half the work, so it
does count as left-over, I would say.
It may probably be a good idea to do an advice, but I'd think
"Untable to find remote helper for 'SSH'" may be clear enough. If
anything, perhaps saying "remote helper for 'SSH' protocol" would
make it even clear? I dunno.
^ permalink raw reply [relevance 6%]
* [BUG] url schemes should be case-insensitive
@ 2018-06-24 8:56 6% Jeff King
2018-06-25 18:19 6% ` Junio C Hamano
0 siblings, 1 reply; 114+ results
From: Jeff King @ 2018-06-24 8:56 UTC (permalink / raw)
To: git
We seem to match url schemes case-sensitively:
$ git clone SSH://example.com/repo.git
Cloning into 'repo'...
fatal: Unable to find remote helper for 'SSH'
whereas rfc3986 is clear that the scheme portion is case-insensitive.
We probably ought to match at least our internal ones with strcasecmp.
Possibly we should also normalize external helpers (so "FOO://bar" would
always call git-remote-foo, never git-remote-FOO).
We could probably also give an advise() message in the above output,
suggesting that the problem is likely one of:
1. They misspelled the scheme.
2. They need to install the appropriate helper.
This may be a good topic for somebody looking for low-hanging fruit to
get involved in development (I'd maybe call it a #leftoverbits, but
since I didn't start on it, I'm not sure if it counts as "left over" ;)).
-Peff
^ permalink raw reply [relevance 6%]
* Re: [PATCH 0/7] grep.c: teach --column to 'git-grep(1)'
2018-06-19 17:33 0% ` René Scharfe
@ 2018-06-19 17:44 0% ` Taylor Blau
0 siblings, 0 replies; 114+ results
From: Taylor Blau @ 2018-06-19 17:44 UTC (permalink / raw)
To: René Scharfe; +Cc: Jeff King, Taylor Blau, git, avarab, gitster
On Tue, Jun 19, 2018 at 07:33:39PM +0200, René Scharfe wrote:
> Am 19.06.2018 um 18:35 schrieb Jeff King:
> > On Mon, Jun 18, 2018 at 06:43:01PM -0500, Taylor Blau wrote:
> >> The notable case that it does _not_ cover is matching the following
> >> line:
> >>
> >> a ... b
> >>
> >> with the following expression
> >>
> >> git grep --column -e b --or -e a
> >>
> >> This will produce the column for 'b' rather than the column for 'a',
> >> since we short-circuit an --or when the left child finds a match, in
> >> this case 'b'. So, we break the semantics for this case, at the benefit
> >> of not having to do twice the work.
> >>
> >> In the future, I'd like to revisit this, since any performance gains
> >> that we _do_ make in this area are moot when we rescan all lines in
> >> show_line() with --color. A path forward, I imagine, would look like a
> >> list of regmatch_t's, or a set of locations in the expression tree, such
> >> that we could either enumerate the list or walk the tree in order to
> >> colorize the line. But, I think for now that is #leftoverbits.
> >
> > The key thing about this iteration is that it doesn't regress
> > performance, because we always short-circuit where we used to. The other
> > obvious route is to stop short-circuiting only when "--column" is in
> > effect, which would have the same property (at the expense of a little
> > extra code in match_expr_eval()).
>
> The performance impact of the exhaustive search for --color scales with
> the number of shown lines, while it would scale with the total number of
> lines for --column. Coloring the results of highly selective patterns
> is relatively cheap, short-circuiting them still helps significantly.
Sure. I was pointing out that we are repeating work in cases where it is
unnecessary to do so. It seems natural to me to take one of the two
above approaches, and optimize where we can.
> Disabling that optimization for --column wouldn't be a regression since
> it's a new option.. Picking a random result (based on the order of
> evaluation) seems sloppy and is probably going to surprise users.
That's fair, and something I'm happy to do if others feel OK about it.
Here is a patch to that effect:
diff --git a/grep.c b/grep.c
index f3329d82ed..a09935d8c5 100644
--- a/grep.c
+++ b/grep.c
@@ -1257,8 +1257,8 @@ static int match_one_pattern(struct grep_pat *p, char *bol, char *eol,
return hit;
}
-static int match_expr_eval(struct grep_expr *x, char *bol, char *eol,
- enum grep_context ctx, ssize_t *col,
+static int match_expr_eval(struct grep_opt *opt, struct grep_expr *x, char *bol,
+ char *eol, enum grep_context ctx, ssize_t *col,
ssize_t *icol, int collect_hits)
{
int h = 0;
@@ -1282,26 +1282,27 @@ static int match_expr_eval(struct grep_expr *x, char *bol, char *eol,
/*
* Upon visiting a GREP_NODE_NOT, col and icol become swapped.
*/
- h = !match_expr_eval(x->u.unary, bol, eol, ctx, icol, col, 0);
+ h = !match_expr_eval(opt, x->u.unary, bol, eol, ctx, icol, col, 0);
break;
case GREP_NODE_AND:
- if (!match_expr_eval(x->u.binary.left, bol, eol, ctx, col,
+ if (!match_expr_eval(opt, x->u.binary.left, bol, eol, ctx, col,
icol, 0))
return 0;
- h = match_expr_eval(x->u.binary.right, bol, eol, ctx, col,
+ h = match_expr_eval(opt, x->u.binary.right, bol, eol, ctx, col,
icol, 0);
break;
case GREP_NODE_OR:
- if (!collect_hits)
- return (match_expr_eval(x->u.binary.left, bol, eol, ctx,
+ if (!(collect_hits || opt->columnnum))
+ return (match_expr_eval(opt, x->u.binary.left, bol, eol, ctx,
col, icol, 0) ||
- match_expr_eval(x->u.binary.right, bol, eol,
+ match_expr_eval(opt, x->u.binary.right, bol, eol,
ctx, col, icol, 0));
- h = match_expr_eval(x->u.binary.left, bol, eol, ctx, col,
+ h = match_expr_eval(opt, x->u.binary.left, bol, eol, ctx, col,
icol, 0);
- x->u.binary.left->hit |= h;
- h |= match_expr_eval(x->u.binary.right, bol, eol, ctx, col,
- icol, 1);
+ if (collect_hits)
+ x->u.binary.left->hit |= h;
+ h |= match_expr_eval(opt, x->u.binary.right, bol, eol, ctx, col,
+ icol, collect_hits);
break;
default:
die("Unexpected node type (internal error) %d", x->node);
@@ -1316,7 +1317,7 @@ static int match_expr(struct grep_opt *opt, char *bol, char *eol,
ssize_t *icol, int collect_hits)
{
struct grep_expr *x = opt->pattern_expression;
- return match_expr_eval(x, bol, eol, ctx, col, icol, collect_hits);
+ return match_expr_eval(opt, x, bol, eol, ctx, col, icol, collect_hits);
}
static int match_line(struct grep_opt *opt, char *bol, char *eol,
> We could add an optimizer pass to reduce the number of regular
> expressions in certain cases if that is really too slow. E.g. this:
>
> $ git grep -e b -e a
>
> ... is equivalent to:
>
> $ git grep -e '\(b\)\|\(a\)'
>
> In that example the optimizer should use a single kwset instead of a
> regex, but you get the idea, namely to leave the short-circuiting to the
> regex engine or kwset, which probably do a good job of it.
I think that--while this pushes that decision to the appropriate level
of indirection--that it is out of scope for this series, and that the
above patch should do a sufficient job at not surprising users.
> René
Thanks,
Taylor
^ permalink raw reply related [relevance 0%]
* Re: [PATCH 0/7] grep.c: teach --column to 'git-grep(1)'
2018-06-19 16:35 0% ` Jeff King
@ 2018-06-19 17:33 0% ` René Scharfe
2018-06-19 17:44 0% ` Taylor Blau
0 siblings, 1 reply; 114+ results
From: René Scharfe @ 2018-06-19 17:33 UTC (permalink / raw)
To: Jeff King, Taylor Blau; +Cc: git, avarab, gitster
Am 19.06.2018 um 18:35 schrieb Jeff King:
> On Mon, Jun 18, 2018 at 06:43:01PM -0500, Taylor Blau wrote:
>> The notable case that it does _not_ cover is matching the following
>> line:
>>
>> a ... b
>>
>> with the following expression
>>
>> git grep --column -e b --or -e a
>>
>> This will produce the column for 'b' rather than the column for 'a',
>> since we short-circuit an --or when the left child finds a match, in
>> this case 'b'. So, we break the semantics for this case, at the benefit
>> of not having to do twice the work.
>>
>> In the future, I'd like to revisit this, since any performance gains
>> that we _do_ make in this area are moot when we rescan all lines in
>> show_line() with --color. A path forward, I imagine, would look like a
>> list of regmatch_t's, or a set of locations in the expression tree, such
>> that we could either enumerate the list or walk the tree in order to
>> colorize the line. But, I think for now that is #leftoverbits.
>
> The key thing about this iteration is that it doesn't regress
> performance, because we always short-circuit where we used to. The other
> obvious route is to stop short-circuiting only when "--column" is in
> effect, which would have the same property (at the expense of a little
> extra code in match_expr_eval()).
The performance impact of the exhaustive search for --color scales with
the number of shown lines, while it would scale with the total number of
lines for --column. Coloring the results of highly selective patterns
is relatively cheap, short-circuiting them still helps significantly.
Disabling that optimization for --column wouldn't be a regression since
it's a new option.. Picking a random result (based on the order of
evaluation) seems sloppy and is probably going to surprise users.
We could add an optimizer pass to reduce the number of regular
expressions in certain cases if that is really too slow. E.g. this:
$ git grep -e b -e a
... is equivalent to:
$ git grep -e '\(b\)\|\(a\)'
In that example the optimizer should use a single kwset instead of a
regex, but you get the idea, namely to leave the short-circuiting to the
regex engine or kwset, which probably do a good job of it.
René
^ permalink raw reply [relevance 0%]
* Re: [PATCH 0/7] grep.c: teach --column to 'git-grep(1)'
2018-06-18 23:43 5% [PATCH 0/7] grep.c: teach --column to 'git-grep(1)' Taylor Blau
@ 2018-06-19 16:35 0% ` Jeff King
2018-06-19 17:33 0% ` René Scharfe
0 siblings, 1 reply; 114+ results
From: Jeff King @ 2018-06-19 16:35 UTC (permalink / raw)
To: Taylor Blau; +Cc: git, avarab, gitster
On Mon, Jun 18, 2018 at 06:43:01PM -0500, Taylor Blau wrote:
> Attached is a ``fresh start'' of my series to teach 'git grep --column'.
> Since the last time I sent this, much has changed, notably the semantics
> for deciding which column is the first when given (1) extended
> expressions and (2) --invert.
>
> Both (1) and (2) are described in-depth in patch 2/7, but I am happy to
> answer more questions should they arise here. Peff and I worked on this
> together off-list, and we are both happy with the semantics, and believe
> that it covers most reasonable cases.
So with the exception of some minor type-quibbling in patch 4, this all
looks good to me. Since we discussed this quite a bit off-list, you can
take that review either with a giant grain of salt (reviewing something
I helped to generate in the first place) or a ringing endorsement (I
thought about it a lot more than I would have for a normal review ;) ).
> The notable case that it does _not_ cover is matching the following
> line:
>
> a ... b
>
> with the following expression
>
> git grep --column -e b --or -e a
>
> This will produce the column for 'b' rather than the column for 'a',
> since we short-circuit an --or when the left child finds a match, in
> this case 'b'. So, we break the semantics for this case, at the benefit
> of not having to do twice the work.
>
> In the future, I'd like to revisit this, since any performance gains
> that we _do_ make in this area are moot when we rescan all lines in
> show_line() with --color. A path forward, I imagine, would look like a
> list of regmatch_t's, or a set of locations in the expression tree, such
> that we could either enumerate the list or walk the tree in order to
> colorize the line. But, I think for now that is #leftoverbits.
The key thing about this iteration is that it doesn't regress
performance, because we always short-circuit where we used to. The other
obvious route is to stop short-circuiting only when "--column" is in
effect, which would have the same property (at the expense of a little
extra code in match_expr_eval()).
-Peff
^ permalink raw reply [relevance 0%]
* [PATCH 0/7] grep.c: teach --column to 'git-grep(1)'
@ 2018-06-18 23:43 5% Taylor Blau
2018-06-19 16:35 0% ` Jeff King
0 siblings, 1 reply; 114+ results
From: Taylor Blau @ 2018-06-18 23:43 UTC (permalink / raw)
To: git; +Cc: avarab, peff, gitster
Hi,
Attached is a ``fresh start'' of my series to teach 'git grep --column'.
Since the last time I sent this, much has changed, notably the semantics
for deciding which column is the first when given (1) extended
expressions and (2) --invert.
Both (1) and (2) are described in-depth in patch 2/7, but I am happy to
answer more questions should they arise here. Peff and I worked on this
together off-list, and we are both happy with the semantics, and believe
that it covers most reasonable cases.
The notable case that it does _not_ cover is matching the following
line:
a ... b
with the following expression
git grep --column -e b --or -e a
This will produce the column for 'b' rather than the column for 'a',
since we short-circuit an --or when the left child finds a match, in
this case 'b'. So, we break the semantics for this case, at the benefit
of not having to do twice the work.
In the future, I'd like to revisit this, since any performance gains
that we _do_ make in this area are moot when we rescan all lines in
show_line() with --color. A path forward, I imagine, would look like a
list of regmatch_t's, or a set of locations in the expression tree, such
that we could either enumerate the list or walk the tree in order to
colorize the line. But, I think for now that is #leftoverbits.
Thanks especially to the last round of reviewers for their detailed
feedback, and I hope that starting in a new series will be OK. I figure
that enough has changed that I'd rather not clutter an already busy
thread.
Thanks,
Taylor
Taylor Blau (7):
Documentation/config.txt: camel-case lineNumber for consistency
grep.c: expose {,inverted} match column in match_line()
grep.[ch]: extend grep_opt to allow showing matched column
grep.c: display column number of first match
builtin/grep.c: add '--column' option to 'git-grep(1)'
grep.c: add configuration variables to show matched option
contrib/git-jump/git-jump: jump to exact location
Documentation/config.txt | 7 ++-
Documentation/git-grep.txt | 9 +++-
builtin/grep.c | 1 +
contrib/git-jump/README | 12 ++++-
contrib/git-jump/git-jump | 2 +-
grep.c | 95 +++++++++++++++++++++++++++++---------
grep.h | 2 +
t/t7810-grep.sh | 63 +++++++++++++++++++++++++
8 files changed, 163 insertions(+), 28 deletions(-)
--
2.17.0.582.gccdcbd54c
^ permalink raw reply [relevance 5%]
* Re: Is origin/HEAD only being created on clone a bug? #leftoverbits
2018-05-30 2:46 8% ` Junio C Hamano
@ 2018-06-01 6:51 8% ` Jeff King
0 siblings, 0 replies; 114+ results
From: Jeff King @ 2018-06-01 6:51 UTC (permalink / raw)
To: Junio C Hamano
Cc: Ævar Arnfjörð Bjarmason, Git List,
Johannes Schindelin
On Wed, May 30, 2018 at 11:46:16AM +0900, Junio C Hamano wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
> > - When we fetch from a remote that has refs/remotes/$name/HEAD, and
> > if the protocol notices that their HEAD today is pointing to a
> > branch different from what our side has, should we repoint ours
> > to match?
> >
> > I am leaning against doing this, but mostly out of superstition.
> > ...
> > interested in". But once fetch starts messing with where
> > origin/HEAD points at, that would no longer be the case, which is
> > why I am against doing something magical like that.
>
> Well, I shouldn't say "I am against" on the last line; rather, "I
> feel uneasy".
I didn't bother to dig up the past discussions, but I am pretty sure we
intentionally avoided updating origin/HEAD without an explicit action
from the user. Because what the other side considers "the default
branch" and what you consider "the default branch" when dealing with the
remote are not necessarily the same thing. If we auto-adjust the symref
on fetch, we might be undoing the user's previous "git remote set-head"
operation.
I don't have any real problem with creating it if it _doesn't_ exist,
though. (I think ideally it would get created by "remote add", but that
command does not always talk to the remote, so this kind of
delayed-create is probably the best we can do).
-Peff
^ permalink raw reply [relevance 8%]
* Re: Is origin/HEAD only being created on clone a bug? #leftoverbits
2018-05-31 7:42 8% ` Ævar Arnfjörð Bjarmason
@ 2018-06-01 1:32 8% ` Junio C Hamano
0 siblings, 0 replies; 114+ results
From: Junio C Hamano @ 2018-06-01 1:32 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason; +Cc: Git List, Johannes Schindelin
Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
> We already have to deal with this special case of origin/HEAD
> being re-pointed in a repository that we "clone", so we would just
> do whatever happens to a repository that's cloned.
OK. Not visiting that issue while we discuss this "origin/HEAD is
useful, so create it even for non-initial-clone case" topic makes it
simpler to discuss.
^ permalink raw reply [relevance 8%]
* Re: Is origin/HEAD only being created on clone a bug? #leftoverbits
2018-05-30 1:24 6% ` Junio C Hamano
2018-05-30 2:46 8% ` Junio C Hamano
@ 2018-05-31 7:42 8% ` Ævar Arnfjörð Bjarmason
2018-06-01 1:32 8% ` Junio C Hamano
1 sibling, 1 reply; 114+ results
From: Ævar Arnfjörð Bjarmason @ 2018-05-31 7:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git List, Johannes Schindelin
On Wed, May 30 2018, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
>
>> If you make an initial commit and push to a remote repo "origin", you
>> don't get a remote origin/HEAD reference, and a "fetch" won't create it
>> either.
>> ...
>> Some code spelunking reveals remote_head_points_at, guess_remote_head()
>> etc. in builtin/clone.c. I.e. this is special-cased as part of the
>> "clone".
>
> Correct. Originally, there was *no* way in the protocol to carry
> the information, so the code always had to guess. The point of
> setting origin/HEAD was mostly so that you can say "log origin.."
> and rely on it getting dwimmed down to "refs/remotes/%s/HEAD..",
> and it wasn't a common practice to interact with multiple remotes
> with remote tracking branches (integrator interacting with dozens
> of remotes, responding to pull requests using explicit URL but
> without configured remotes was not uncommon), so it was sufficient
> for "git clone" to create it, and "git remote add" did not exist
> back then anyway.
>
> There are two aspects in my answer to your question.
>
> - If we create additional remote (that is, other than the one we
> get when we create a repository via "clone", so if your "origin"
> is from "git init there && cd there && git remote add origin", it
> does count in this category), should we get a remote-tracking
> symref $name/HEAD so that we can say "log $name.."?
>
> We absolutely should. We (eh, rather, those who added "remote
> add"; this was not my itch and I am using "royal we" in this
> sentence) just did not bother to and I think it is a bug that you
> cannot say "log $name.." Of course, it is just a "git symbolic-ref"
> away to make it possible locally, so it is understandable if
> "remote add" did not bother to.
>
> - When we fetch from a remote that has refs/remotes/$name/HEAD, and
> if the protocol notices that their HEAD today is pointing to a
> branch different from what our side has, should we repoint ours
> to match?
>
> I am leaning against doing this, but mostly out of superstition.
> Namely, I feel uneasy about the fact that the meaning of "log
> ..origin" changes across a fetch in this sequence:
>
> log ..origin && fetch origin && log ..origin
>
> Without repointing origin/HEAD, two occurrences of "log ..origin"
> both means "how much ahead the primary branch we have been
> interested in from this remote is, relative to our effort?".
> Even though we fully expect that two "log ..origin" would report
> different results (after all, that is the whole point of doing
> another one after "fetch" in such a sequence like this example),
> our question is about the same "primary branch we have been
> interested in". But once fetch starts messing with where
> origin/HEAD points at, that would no longer be the case, which is
> why I am against doing something magical like that.
We already have to deal with this special case of origin/HEAD being
re-pointed in a repository that we "clone", so we would just do whatever
happens to a repository that's cloned.
I.e. the "clone" sets the origin/HEAD up as a one-off, and then keeps
updating it on the basis of updating existing refs. We'd similarly set
it up as a one-off if we ever "fetch" and notice that the ref doesn't
exist yet, and then we'd update it in the same way we update it now.
So this seems like a non-issue to me as far as me coming up with some
patch to one-off write the origin/HEAD on the first "fetch", or am I
missing something?
^ permalink raw reply [relevance 8%]
* Re: Is origin/HEAD only being created on clone a bug? #leftoverbits
2018-05-30 1:24 6% ` Junio C Hamano
@ 2018-05-30 2:46 8% ` Junio C Hamano
2018-06-01 6:51 8% ` Jeff King
2018-05-31 7:42 8% ` Ævar Arnfjörð Bjarmason
1 sibling, 1 reply; 114+ results
From: Junio C Hamano @ 2018-05-30 2:46 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason; +Cc: Git List, Johannes Schindelin
Junio C Hamano <gitster@pobox.com> writes:
> - When we fetch from a remote that has refs/remotes/$name/HEAD, and
> if the protocol notices that their HEAD today is pointing to a
> branch different from what our side has, should we repoint ours
> to match?
>
> I am leaning against doing this, but mostly out of superstition.
> ...
> interested in". But once fetch starts messing with where
> origin/HEAD points at, that would no longer be the case, which is
> why I am against doing something magical like that.
Well, I shouldn't say "I am against" on the last line; rather, "I
feel uneasy".
^ permalink raw reply [relevance 8%]
* Re: Is origin/HEAD only being created on clone a bug? #leftoverbits
2018-05-29 18:30 14% Is origin/HEAD only being created on clone a bug? #leftoverbits Ævar Arnfjörð Bjarmason
2018-05-29 19:17 8% ` Brandon Williams
@ 2018-05-30 1:24 6% ` Junio C Hamano
2018-05-30 2:46 8% ` Junio C Hamano
2018-05-31 7:42 8% ` Ævar Arnfjörð Bjarmason
1 sibling, 2 replies; 114+ results
From: Junio C Hamano @ 2018-05-30 1:24 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason; +Cc: Git List, Johannes Schindelin
Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
> If you make an initial commit and push to a remote repo "origin", you
> don't get a remote origin/HEAD reference, and a "fetch" won't create it
> either.
> ...
> Some code spelunking reveals remote_head_points_at, guess_remote_head()
> etc. in builtin/clone.c. I.e. this is special-cased as part of the
> "clone".
Correct. Originally, there was *no* way in the protocol to carry
the information, so the code always had to guess. The point of
setting origin/HEAD was mostly so that you can say "log origin.."
and rely on it getting dwimmed down to "refs/remotes/%s/HEAD..",
and it wasn't a common practice to interact with multiple remotes
with remote tracking branches (integrator interacting with dozens
of remotes, responding to pull requests using explicit URL but
without configured remotes was not uncommon), so it was sufficient
for "git clone" to create it, and "git remote add" did not exist
back then anyway.
There are two aspects in my answer to your question.
- If we create additional remote (that is, other than the one we
get when we create a repository via "clone", so if your "origin"
is from "git init there && cd there && git remote add origin", it
does count in this category), should we get a remote-tracking
symref $name/HEAD so that we can say "log $name.."?
We absolutely should. We (eh, rather, those who added "remote
add"; this was not my itch and I am using "royal we" in this
sentence) just did not bother to and I think it is a bug that you
cannot say "log $name.." Of course, it is just a "git symbolic-ref"
away to make it possible locally, so it is understandable if
"remote add" did not bother to.
- When we fetch from a remote that has refs/remotes/$name/HEAD, and
if the protocol notices that their HEAD today is pointing to a
branch different from what our side has, should we repoint ours
to match?
I am leaning against doing this, but mostly out of superstition.
Namely, I feel uneasy about the fact that the meaning of "log
..origin" changes across a fetch in this sequence:
log ..origin && fetch origin && log ..origin
Without repointing origin/HEAD, two occurrences of "log ..origin"
both means "how much ahead the primary branch we have been
interested in from this remote is, relative to our effort?".
Even though we fully expect that two "log ..origin" would report
different results (after all, that is the whole point of doing
another one after "fetch" in such a sequence like this example),
our question is about the same "primary branch we have been
interested in". But once fetch starts messing with where
origin/HEAD points at, that would no longer be the case, which is
why I am against doing something magical like that.
^ permalink raw reply [relevance 6%]
* Re: Is origin/HEAD only being created on clone a bug? #leftoverbits
2018-05-29 18:30 14% Is origin/HEAD only being created on clone a bug? #leftoverbits Ævar Arnfjörð Bjarmason
@ 2018-05-29 19:17 8% ` Brandon Williams
2018-05-30 1:24 6% ` Junio C Hamano
1 sibling, 0 replies; 114+ results
From: Brandon Williams @ 2018-05-29 19:17 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason; +Cc: Git List, Johannes Schindelin
On 05/29, Ævar Arnfjörð Bjarmason wrote:
> Here's some more #leftoverbits where we have a clone/fetch feature
> discrepancy and where clone is magical in ways that "fetch" isn't.
>
> If you make an initial commit and push to a remote repo "origin", you
> don't get a remote origin/HEAD reference, and a "fetch" won't create it
> either.
>
> You will get it if you subseuqently "clone" the repo, but not if you use
> "git init / remote add / fetch / git checkout -t" which should otherwise
> be equivalent.
>
> If you push to "master" (or whatever HEAD is) from the clone the
> origin/HEAD will be updated accordingly, but from the repo you pushed
> from & the one you did init+fetch instead of clone you'll never see it.
>
> Some code spelunking reveals remote_head_points_at, guess_remote_head()
> etc. in builtin/clone.c. I.e. this is special-cased as part of the
> "clone".
>
> Can anyone thing of a reason for why this shouldn't be fixed as a bug?
> I've tried searching the archives but "origin/HEAD" comes up with too
> many
> results. https://public-inbox.org/git/alpine.LSU.1.00.0803020556380.22527@racer.site/#t
> seems to be the patch that initially added it, but it is not discussed
> why this should be a clone-only special case that doesn't apply to
> "fetch".
I believe the issue has to deal with how symrefs are handled. I don't
think any of the fetch code path does anything special with symrefs.
Symref info does get sent over the wire for the HEAD symref but i think
its just ignored. You'll see updates for origin/HEAD when you
subsequently fetch most likely because its recorded as a symref locally
which points at origin/master. This means that when you fetch
origin/master, origin/HEAD will also but updated just because its
locally a pointer to origin/master.
With that said, yes we should probably fix this issue with fetch because
I added symref support to protocol v2 so now symref information for refs
other than HEAD can be sent across the wire but the client just throws
that info away at the moment.
--
Brandon Williams
^ permalink raw reply [relevance 8%]
* Is origin/HEAD only being created on clone a bug? #leftoverbits
@ 2018-05-29 18:30 14% Ævar Arnfjörð Bjarmason
2018-05-29 19:17 8% ` Brandon Williams
2018-05-30 1:24 6% ` Junio C Hamano
0 siblings, 2 replies; 114+ results
From: Ævar Arnfjörð Bjarmason @ 2018-05-29 18:30 UTC (permalink / raw)
To: Git List; +Cc: Johannes Schindelin
Here's some more #leftoverbits where we have a clone/fetch feature
discrepancy and where clone is magical in ways that "fetch" isn't.
If you make an initial commit and push to a remote repo "origin", you
don't get a remote origin/HEAD reference, and a "fetch" won't create it
either.
You will get it if you subseuqently "clone" the repo, but not if you use
"git init / remote add / fetch / git checkout -t" which should otherwise
be equivalent.
If you push to "master" (or whatever HEAD is) from the clone the
origin/HEAD will be updated accordingly, but from the repo you pushed
from & the one you did init+fetch instead of clone you'll never see it.
Some code spelunking reveals remote_head_points_at, guess_remote_head()
etc. in builtin/clone.c. I.e. this is special-cased as part of the
"clone".
Can anyone thing of a reason for why this shouldn't be fixed as a bug?
I've tried searching the archives but "origin/HEAD" comes up with too
many
results. https://public-inbox.org/git/alpine.LSU.1.00.0803020556380.22527@racer.site/#t
seems to be the patch that initially added it, but it is not discussed
why this should be a clone-only special case that doesn't apply to
"fetch".
^ permalink raw reply [relevance 14%]
* [PATCH 2/5] log_write_email_headers: use strbufs
@ 2018-05-19 1:57 5% ` Jeff King
0 siblings, 0 replies; 114+ results
From: Jeff King @ 2018-05-19 1:57 UTC (permalink / raw)
To: git
When we write a MIME attachment, we write the mime headers
into fixed-size buffers. These are likely to be big enough
in practice, but technically the input could be arbitrarily
large (e.g., if the caller provided a lot of content in the
extra_headers string), in which case we'd quietly truncate
it and generate bogus output. Let's convert these buffers to
strbufs.
The memory ownership here is a bit funny. The original fixed
buffers were static, and we merely pass out pointers to them
to be used by the caller (and in one case, we even just
stuff our value into the opt->diffopt.stat_sep value).
Ideally we'd actually pass back heap buffers, and the caller
would be responsible for freeing them.
This patch punts on that cleanup for now, and instead just
marks the strbufs as static. That means we keep ownership in
this function, making it not a complete leak. This also
takes us one step closer to fixing it in the long term
(since we can eventually use strbuf_detach() to hand
ownership to the caller, once it's ready).
Signed-off-by: Jeff King <peff@peff.net>
---
The rest of that cleanup is a possible #leftoverbits.
log-tree.c | 16 ++++++++++------
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/log-tree.c b/log-tree.c
index d1c0bedf24..1173fdb057 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -386,11 +386,15 @@ void log_write_email_headers(struct rev_info *opt, struct commit *commit,
graph_show_oneline(opt->graph);
}
if (opt->mime_boundary) {
- static char subject_buffer[1024];
- static char buffer[1024];
+ static struct strbuf subject_buffer = STRBUF_INIT;
+ static struct strbuf buffer = STRBUF_INIT;
struct strbuf filename = STRBUF_INIT;
*need_8bit_cte_p = -1; /* NEVER */
- snprintf(subject_buffer, sizeof(subject_buffer) - 1,
+
+ strbuf_reset(&subject_buffer);
+ strbuf_reset(&buffer);
+
+ strbuf_addf(&subject_buffer,
"%s"
"MIME-Version: 1.0\n"
"Content-Type: multipart/mixed;"
@@ -405,13 +409,13 @@ void log_write_email_headers(struct rev_info *opt, struct commit *commit,
extra_headers ? extra_headers : "",
mime_boundary_leader, opt->mime_boundary,
mime_boundary_leader, opt->mime_boundary);
- extra_headers = subject_buffer;
+ extra_headers = subject_buffer.buf;
if (opt->numbered_files)
strbuf_addf(&filename, "%d", opt->nr);
else
fmt_output_commit(&filename, commit, opt);
- snprintf(buffer, sizeof(buffer) - 1,
+ strbuf_addf(&buffer,
"\n--%s%s\n"
"Content-Type: text/x-patch;"
" name=\"%s\"\n"
@@ -422,7 +426,7 @@ void log_write_email_headers(struct rev_info *opt, struct commit *commit,
filename.buf,
opt->no_inline ? "attachment" : "inline",
filename.buf);
- opt->diffopt.stat_sep = buffer;
+ opt->diffopt.stat_sep = buffer.buf;
strbuf_release(&filename);
}
*extra_headers_p = extra_headers;
--
2.17.0.1052.g7d69f75dbf
^ permalink raw reply related [relevance 5%]
* Re: [PATCH v5 5/7] builtin/grep.c: add '--column' option to 'git-grep(1)'
@ 2018-05-12 3:27 5% ` Taylor Blau
0 siblings, 0 replies; 114+ results
From: Taylor Blau @ 2018-05-12 3:27 UTC (permalink / raw)
To: Junio C Hamano
Cc: Martin Ågren, Phillip Wood, Git Mailing List,
Ævar Arnfjörð Bjarmason, René Scharfe,
Nguyễn Thái Ngọc Duy, Jeff King, Eric Sunshine
On Thu, May 10, 2018 at 09:04:34AM +0900, Junio C Hamano wrote:
> Taylor Blau <me@ttaylorr.com> writes:
>
> > This check we should retain and change the wording to mention '--and',
> > '--or', and '--not' specifically.
>
> Why are these problematic in the first place? If I said
>
> $ git grep -e first --and -e these
> $ git grep -e first --and --not -e those
> $ git grep -e first --or -e those
>
> I'd expect that the first line of this paragraph will hit, and the
> first hit for these three are "these", "first" and "first",
> respectively. Most importantly, in the last one, "--or" can be
> omitted and the whole thing stops being "extended", so rejecting
> extended as a whole does not make much sense.
Agreed that this is what I would expect, too. The trouble is that we
never do a compilation step from containing --and, --or, --not to a
POSIX regexp. So, if we're extended, we have to assume that there might
not be an answer.
Given this, I don't think we should categorically die() when we
encounter this (more below in the next hunk of this mail). I think this
thread has established that there are certainly cases where we cannot
provide a meaningful answer, (--not at the top-level, for instance) but
there are cases where we can (as you indicate above).
One day, I would like to support --column with --and, --or, or --not in
cases where there _is_ a definite answer. That said, omitting this
information for now and at least not die()-ing I think is worth taking
this patch earlier, and leaving some #leftoverbits.
> $ git grep -v second
> $ git grep --not -e second
>
> may hit all lines in this message (except for the obvious two
> lines), but we cannot say which column we found a hit. I am
> wondering if it is too grave a sin to report "the whole line is what
> satisfied the criteria given" and say the match lies at column #1.
I think that is sensible. I previously was opposed to this because I
thought that it would be too difficult to script around the 'sometimes
we have columns but other times not' and 'I gave --column' but have to
check whether or not they are really there.
I no longer believe that my above argument is sound. It simplifies the
matter greatly to simply not share columns when we don't have a good
answer, and do when we do.
In other terms:
* not giving '--column' will _never_ give a column,
* '--column --invert' will _always_ die(), and
* '--column --[and | or | not]' will _never_ give a column.
Thanks,
Taylor
^ permalink raw reply [relevance 5%]
* [GSoC] Some #leftoverbits for anyone looking for little projects
@ 2018-03-17 21:20 6% Ævar Arnfjörð Bjarmason
0 siblings, 0 replies; 114+ results
From: Ævar Arnfjörð Bjarmason @ 2018-03-17 21:20 UTC (permalink / raw)
To: Git Mailing List
In lieu of sending a PR to https://git.github.io/SoC-2018-Microprojects/
I thought I'd list a few more suggestions, and hopefully others will
chime in.
This is all TODO stuff I've been meaning to do myself, but wouldn't mind
at all if someone else tackled.
I'm not interested in mentoring GSoC, but these are all small enough to
need to special help from me (or anyone in particular), and if nobody
picks them up I can refer back to this mail for my own use.
* Having grep support the -o option like GNU grep et al.
We have most of the code for this already in the form of our color
hi-lighting, it would mostly just be a matter of "just print out the
stuff you'd have colored", with the small exception that if you have
more than one match on a line they should be printed out on their own
lines.
* Give "rebase -i" some option so when you "reword" the patch is
included in the message.
I keep going to the shell because I have no idea what change I'm
describing.
* Add more config IncludeIf conditions.
Recently there was a mention on git-users to excend the includeIf
statement to read config:
https://groups.google.com/forum/?fromgroups#!searchin/git-users/includeif%7Csort:date/git-users/SHd506snwSk/UdVCsCILBwAJ
Now that seems like a nasty circular dependency but there's other
low-hanging fruit there, like make it match a given env name to a
value (or glob?).
* Add another set of GIT_{AUTHOR,COMMITTER}_{NAME,EMAIL} with lower
priorities.
There is a script at work which I have to manually blacklist which
sets git author names & e-mails via LDAP for all logged in users via
/etc/profile (and gets my name wrong)[1].
It would be nice if git supported a way to do this that didn't either
involve overriding everything (as the current env vars do) or munging
the user's ~ config (ew!). I.e. the priority of these new env vars
would come after reading from the config, not overriding the config
as the current ones do. So it could be used to make a suggestion if
no other value was found.
* Write git-unpack-{refs,objects}
I don't know if this is small enough (maybe the refs part?). This
would give you purely loose objects & refs. This is a terrible idea
for any "real" use, but very useful for testing.
Now when I'm testing repack I need to keep an old copy of the repo
around, because there's no easy way (that I know of) to pack things
and then get back to loose object state. Ditto for packing refs.
* I had a previous TODO list of "small" things at
https://public-inbox.org/git/CACBZZX5wdnA-96e11edE7xRnAHo19RFTrZmqFQj-0ogLOJTncQ@mail.gmail.com/
1. At work like in so many companies LDAP is synced everywhere, but of
course that means catering to the lowest common denominator. Last I
heard attempts to give me a non-ASCII name (in the GEOS field) had
failed because some phone or printer somewhere refused to accept it.
^ permalink raw reply [relevance 6%]
* Re: [PATCH v3 14/35] connect: request remote refs using v2
2018-02-27 21:58 0% ` Junio C Hamano
@ 2018-02-27 22:04 0% ` Jeff King
0 siblings, 0 replies; 114+ results
From: Jeff King @ 2018-02-27 22:04 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jonathan Nieder, Jonathan Tan, Brandon Williams, git, sbeller,
stolee, git, pclouds
On Tue, Feb 27, 2018 at 01:58:00PM -0800, Junio C Hamano wrote:
> Jonathan Nieder <jrnieder@gmail.com> writes:
>
> > Jonathan Tan wrote:
> >> On Thu, 22 Feb 2018 13:26:58 -0500
> >> Jeff King <peff@peff.net> wrote:
> >
> >>> I agree that it shouldn't matter much here. But if the name argv_array
> >>> is standing in the way of using it, I think we should consider giving it
> >>> a more general name. I picked that not to evoke "this must be arguments"
> >>> but "this is terminated by a single NULL".
> > [...]
> >> This sounds reasonable - I withdraw my comment about using struct
> >> string_list.
> >
> > Marking with #leftoverbits as a reminder to think about what such a
> > more general name would be (or what kind of docs to put in
> > argv-array.h) and make it so the next time I do a search for that
> > keyword.
>
> So are we looking for a natural name to call an array of trings? I
> personally do not mind argv_array too much, but perhaps we can call
> it a string_array and then everybody will be happy?
That would be fine with me. Though I would love it if we could find a
shorter name for the associated functions. For example,
argv_array_pushf() can make lines quite long, and something like
argv_pushf() is easier to read (in my opinion). And that might work
because "argv" is pretty unique by itself, but "string" is not.
Some one-word name like "strarray" might work, though I find that is not
quite catchy. I guess "strv" is short if you assume that people know the
"v" suffix means "vector".
It may not be worth worrying too much about, though. We already have
24-character monstrosities like string_list_append_nodup(). ;)
-Peff
^ permalink raw reply [relevance 0%]
* Re: [PATCH v3 14/35] connect: request remote refs using v2
2018-02-27 6:21 6% ` Jonathan Nieder
@ 2018-02-27 21:58 0% ` Junio C Hamano
2018-02-27 22:04 0% ` Jeff King
0 siblings, 1 reply; 114+ results
From: Junio C Hamano @ 2018-02-27 21:58 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Jonathan Tan, Jeff King, Brandon Williams, git, sbeller, stolee,
git, pclouds
Jonathan Nieder <jrnieder@gmail.com> writes:
> Jonathan Tan wrote:
>> On Thu, 22 Feb 2018 13:26:58 -0500
>> Jeff King <peff@peff.net> wrote:
>
>>> I agree that it shouldn't matter much here. But if the name argv_array
>>> is standing in the way of using it, I think we should consider giving it
>>> a more general name. I picked that not to evoke "this must be arguments"
>>> but "this is terminated by a single NULL".
> [...]
>> This sounds reasonable - I withdraw my comment about using struct
>> string_list.
>
> Marking with #leftoverbits as a reminder to think about what such a
> more general name would be (or what kind of docs to put in
> argv-array.h) and make it so the next time I do a search for that
> keyword.
So are we looking for a natural name to call an array of trings? I
personally do not mind argv_array too much, but perhaps we can call
it a string_array and then everybody will be happy?
^ permalink raw reply [relevance 0%]
* Re: [PATCH v3 14/35] connect: request remote refs using v2
@ 2018-02-27 6:21 6% ` Jonathan Nieder
2018-02-27 21:58 0% ` Junio C Hamano
0 siblings, 1 reply; 114+ results
From: Jonathan Nieder @ 2018-02-27 6:21 UTC (permalink / raw)
To: Jonathan Tan
Cc: Jeff King, Brandon Williams, git, sbeller, gitster, stolee, git,
pclouds
Jonathan Tan wrote:
> On Thu, 22 Feb 2018 13:26:58 -0500
> Jeff King <peff@peff.net> wrote:
>> I agree that it shouldn't matter much here. But if the name argv_array
>> is standing in the way of using it, I think we should consider giving it
>> a more general name. I picked that not to evoke "this must be arguments"
>> but "this is terminated by a single NULL".
[...]
> This sounds reasonable - I withdraw my comment about using struct
> string_list.
Marking with #leftoverbits as a reminder to think about what such a
more general name would be (or what kind of docs to put in
argv-array.h) and make it so the next time I do a search for that
keyword.
Thanks,
Jonathan
^ permalink raw reply [relevance 6%]
* Re: [PATCH] describe: confirm that blobs actually exist
@ 2018-02-12 17:29 6% ` Jeff King
0 siblings, 0 replies; 114+ results
From: Jeff King @ 2018-02-12 17:29 UTC (permalink / raw)
To: git; +Cc: Michael Haggerty, Stefan Beller
On Mon, Feb 12, 2018 at 12:23:06PM -0500, Jeff King wrote:
> We can fix this by replacing the lookup_blob() call with a
> check of the true type via sha1_object_info(). This is not
> quite as efficient as we could possibly make this check. We
> know in most cases that the object was already parsed in the
> earlier commit lookup, so we could call lookup_object(),
> which does auto-create, and check the resulting struct's
> type (or NULL). However it's not worth the fragility nor
> code complexity to save a single object lookup.
By the way, I did notice one other inefficiency here: we always call
lookup_commit_reference_gently() first, which will call parse_object().
So if you were to "git describe" an enormous blob, we'd load the whole
thing into memory for no purpose. We could structure this as:
type = sha1_object_info(oid.hash, NULL);
if (type == OBJ_BLOB)
describe_blob(&oid);
else if (lookup_commit_reference_gently(&oid, 1))
describe_commit(&oid);
else
describe("neither commit nor blob");
That incurs an extra object lookup for the commit case, but potentially
saves reading the blob. We could have our cake and eat it, too, if
sha1_file.c had a function like "parse this object unless it's a blob,
in which case just fill in the type info".
Arguably that should be the default when parse_object() is called on a
blob, but I suspect some older code may rely on parse_object() to check
that the object is present and consistent.
Anyway, I don't know that it's really worth caring about too much, but
just something I noticed.
Maybe a #leftoverbits if somebody cares.
-Peff
^ permalink raw reply [relevance 6%]
* Re: [PATCH v2 05/27] upload-pack: factor out processing lines
@ 2018-01-31 14:08 6% ` Derrick Stolee
0 siblings, 0 replies; 114+ results
From: Derrick Stolee @ 2018-01-31 14:08 UTC (permalink / raw)
To: Brandon Williams, Stefan Beller
Cc: git, Junio C Hamano, Jeff King, Philip Oakley, Jonathan Nieder
On 1/26/2018 4:33 PM, Brandon Williams wrote:
> On 01/26, Stefan Beller wrote:
>> On Thu, Jan 25, 2018 at 3:58 PM, Brandon Williams <bmwill@google.com> wrote:
>>> Factor out the logic for processing shallow, deepen, deepen_since, and
>>> deepen_not lines into their own functions to simplify the
>>> 'receive_needs()' function in addition to making it easier to reuse some
>>> of this logic when implementing protocol_v2.
>>>
>>> Signed-off-by: Brandon Williams <bmwill@google.com>
>>> ---
>>> upload-pack.c | 113 ++++++++++++++++++++++++++++++++++++++--------------------
>>> 1 file changed, 74 insertions(+), 39 deletions(-)
>>>
>>> diff --git a/upload-pack.c b/upload-pack.c
>>> index 2ad73a98b..42d83d5b1 100644
>>> --- a/upload-pack.c
>>> +++ b/upload-pack.c
>>> @@ -724,6 +724,75 @@ static void deepen_by_rev_list(int ac, const char **av,
>>> packet_flush(1);
>>> }
>>>
>>> +static int process_shallow(const char *line, struct object_array *shallows)
>>> +{
>>> + const char *arg;
>>> + if (skip_prefix(line, "shallow ", &arg)) {
>> stylistic nit:
>>
>> You could invert the condition in each of the process_* functions
>> to just have
>>
>> if (!skip_prefix...))
>> return 0
>>
>> /* less indented code goes here */
>>
>> return 1;
>>
>> That way we have less indentation as well as easier code.
>> (The reader doesn't need to keep in mind what the else
>> part is about; it is a rather local decision to bail out instead
>> of having the return at the end of the function.)
> I was trying to move the existing code into helper functions so
> rewriting them in transit may make it less reviewable?
I think the way you kept to the existing code as much as possible is
good and easier to review. Perhaps a style pass after the patch lands is
good for #leftoverbits.
>>
>>> + struct object_id oid;
>>> + struct object *object;
>>> + if (get_oid_hex(arg, &oid))
>>> + die("invalid shallow line: %s", line);
>>> + object = parse_object(&oid);
>>> + if (!object)
>>> + return 1;
>>> + if (object->type != OBJ_COMMIT)
>>> + die("invalid shallow object %s", oid_to_hex(&oid));
>>> + if (!(object->flags & CLIENT_SHALLOW)) {
>>> + object->flags |= CLIENT_SHALLOW;
>>> + add_object_array(object, NULL, shallows);
>>> + }
>>> + return 1;
>>> + }
>>> +
>>> + return 0;
>>> +}
>>> +
>>> +static int process_deepen(const char *line, int *depth)
>>> +{
>>> + const char *arg;
>>> + if (skip_prefix(line, "deepen ", &arg)) {
>>> + char *end = NULL;
>>> + *depth = (int) strtol(arg, &end, 0);
nit: space between (int) and strtol?
>>> + if (!end || *end || *depth <= 0)
>>> + die("Invalid deepen: %s", line);
>>> + return 1;
>>> + }
>>> +
>>> + return 0;
>>> +}
>>> +
>>> +static int process_deepen_since(const char *line, timestamp_t *deepen_since, int *deepen_rev_list)
>>> +{
>>> + const char *arg;
>>> + if (skip_prefix(line, "deepen-since ", &arg)) {
>>> + char *end = NULL;
>>> + *deepen_since = parse_timestamp(arg, &end, 0);
>>> + if (!end || *end || !deepen_since ||
>>> + /* revisions.c's max_age -1 is special */
>>> + *deepen_since == -1)
>>> + die("Invalid deepen-since: %s", line);
>>> + *deepen_rev_list = 1;
>>> + return 1;
>>> + }
>>> + return 0;
>>> +}
>>> +
>>> +static int process_deepen_not(const char *line, struct string_list *deepen_not, int *deepen_rev_list)
>>> +{
>>> + const char *arg;
>>> + if (skip_prefix(line, "deepen-not ", &arg)) {
>>> + char *ref = NULL;
>>> + struct object_id oid;
>>> + if (expand_ref(arg, strlen(arg), &oid, &ref) != 1)
>>> + die("git upload-pack: ambiguous deepen-not: %s", line);
>>> + string_list_append(deepen_not, ref);
>>> + free(ref);
>>> + *deepen_rev_list = 1;
>>> + return 1;
>>> + }
>>> + return 0;
>>> +}
>>> +
>>> static void receive_needs(void)
>>> {
>>> struct object_array shallows = OBJECT_ARRAY_INIT;
>>> @@ -745,49 +814,15 @@ static void receive_needs(void)
>>> if (!line)
>>> break;
>>>
>>> - if (skip_prefix(line, "shallow ", &arg)) {
>>> - struct object_id oid;
>>> - struct object *object;
>>> - if (get_oid_hex(arg, &oid))
>>> - die("invalid shallow line: %s", line);
>>> - object = parse_object(&oid);
>>> - if (!object)
>>> - continue;
>>> - if (object->type != OBJ_COMMIT)
>>> - die("invalid shallow object %s", oid_to_hex(&oid));
>>> - if (!(object->flags & CLIENT_SHALLOW)) {
>>> - object->flags |= CLIENT_SHALLOW;
>>> - add_object_array(object, NULL, &shallows);
>>> - }
>>> + if (process_shallow(line, &shallows))
>>> continue;
>>> - }
>>> - if (skip_prefix(line, "deepen ", &arg)) {
>>> - char *end = NULL;
>>> - depth = strtol(arg, &end, 0);
>>> - if (!end || *end || depth <= 0)
>>> - die("Invalid deepen: %s", line);
>>> + if (process_deepen(line, &depth))
>>> continue;
>>> - }
>>> - if (skip_prefix(line, "deepen-since ", &arg)) {
>>> - char *end = NULL;
>>> - deepen_since = parse_timestamp(arg, &end, 0);
>>> - if (!end || *end || !deepen_since ||
>>> - /* revisions.c's max_age -1 is special */
>>> - deepen_since == -1)
>>> - die("Invalid deepen-since: %s", line);
>>> - deepen_rev_list = 1;
>>> + if (process_deepen_since(line, &deepen_since, &deepen_rev_list))
>>> continue;
>>> - }
>>> - if (skip_prefix(line, "deepen-not ", &arg)) {
>>> - char *ref = NULL;
>>> - struct object_id oid;
>>> - if (expand_ref(arg, strlen(arg), &oid, &ref) != 1)
>>> - die("git upload-pack: ambiguous deepen-not: %s", line);
>>> - string_list_append(&deepen_not, ref);
>>> - free(ref);
>>> - deepen_rev_list = 1;
>>> + if (process_deepen_not(line, &deepen_not, &deepen_rev_list))
>>> continue;
>>> - }
>>> +
>>> if (!skip_prefix(line, "want ", &arg) ||
>>> get_oid_hex(arg, &oid_buf))
>>> die("git upload-pack: protocol error, "
>>> --
>>> 2.16.0.rc1.238.g530d649a79-goog
>>>
^ permalink raw reply [relevance 6%]
* Re: [PATCH] sha1_file: remove static strbuf from sha1_file_name()
@ 2018-01-17 17:55 5% ` Christian Couder
0 siblings, 0 replies; 114+ results
From: Christian Couder @ 2018-01-17 17:55 UTC (permalink / raw)
To: Jeff Hostetler
Cc: Derrick Stolee, git, Junio C Hamano, Jeff Hostetler, Jonathan Tan,
Christian Couder
On Tue, Jan 16, 2018 at 8:00 PM, Jeff Hostetler <git@jeffhostetler.com> wrote:
>
>
> On 1/16/2018 9:01 AM, Derrick Stolee wrote:
>>
>> On 1/16/2018 2:18 AM, Christian Couder wrote:
>>>
>>> Using a static buffer in sha1_file_name() is error prone
>>> and the performance improvements it gives are not needed
>>> in most of the callers.
>>>
>>> So let's get rid of this static buffer and, if necessary
>>> or helpful, let's use one in the caller.
>>
>>
>> First: this is a good change for preventing bugs in the future. Do not let
>> my next thought deter you from making this change.
>>
>> Second: I wonder if there is any perf hit now that we are allocating
>> buffers much more often.
When I though that the caller might be performance sensitive, I used a
"static struct strbuf" in the caller to avoid any performance
regression.
Yeah, that means that further work is needed if we want to get rid of
all the static buffers, but that is not my goal. I am just concerned
with cleaning up sha1_file_name() before changing it, and avoiding
some possible trouble when using it.
Feel free to improve on that or even take over this series, otherwise
it can be part of the #leftoverbits.
>> Also, how often does get_object_directory() change,
>> so in some cases we could cache the buffer and only append the parts for the
>> loose object (and not reallocate because the filenames will have equal
>> length).
Again feel free to work on this kind of optimizations on top of this series.
>> I'm concerned about the perf implications when inspecting many loose
>> objects (100k+) but these code paths seem to be involved with more
>> substantial work, such as opening and parsing the objects, so keeping a
>> buffer in-memory is probably unnecessary.
Yeah, I also think it is not necessary to optimize too much.
>>> diff --git a/sha1_file.c b/sha1_file.c
>>> index 3da70ac650..f66c21b2da 100644
>>> --- a/sha1_file.c
>>> +++ b/sha1_file.c
>>> @@ -321,15 +321,11 @@ static void fill_sha1_path(struct strbuf *buf,
>>> const unsigned char *sha1)
>>> }
>>> }
>>> -const char *sha1_file_name(const unsigned char *sha1)
>>> +void sha1_file_name(struct strbuf *buf, const unsigned char *sha1)
>>> {
>>> - static struct strbuf buf = STRBUF_INIT;
>>> -
>>> - strbuf_reset(&buf);
>>> - strbuf_addf(&buf, "%s/", get_object_directory());
>>> + strbuf_addf(buf, "%s/", get_object_directory());
>>> - fill_sha1_path(&buf, sha1);
>>> - return buf.buf;
>>> + fill_sha1_path(buf, sha1);
>>> }
>>
>>
>> Could you change this to use strbuf_addstr(buf, get_object_directory())
>> followed by a strbuf_addch(buf, '/')? This format string is unnecessary and
>> could become slow if this method is called in a tight loop.
>
> Yes, an _addstr() and _addch() would avoid a sprintf and
> we've seen perf problems with this before.
>
> Could we also add seed the initial buffer size to avoid
> any need to realloc as the buffer is filled in?
>
> Something like:
> size_t len = strlen(get_object_directory()) + GIT_MAX_HEXSZ + 3;
> strbuf_reset(&buf);
> if (len > strbuf_avail(&buf))
> strbuf_grow(&buf, len);
> strbuf_addstr(&buf, ...);
Ok, I did something like that in another patch on top of the first
patch which is just about using a "struct strbuf *" passed as an
argument instead of a static buffer.
>>> struct strbuf *alt_scratch_buf(struct alternate_object_database *alt)
>>> @@ -710,7 +706,12 @@ int check_and_freshen_file(const char *fn, int
>>> freshen)
>>> static int check_and_freshen_local(const unsigned char *sha1, int
>>> freshen)
>>> {
>>> - return check_and_freshen_file(sha1_file_name(sha1), freshen);
>>> + static struct strbuf buf = STRBUF_INIT;
>>> +
>>> + strbuf_reset(&buf);
>>> + sha1_file_name(&buf, sha1);
>>> +
>>> + return check_and_freshen_file(buf.buf, freshen);
>>> }
>
> Does "buf" really need to be static here? Doesn't this just move the
> problem from sha1_file_name() to here?
Yes, but maybe check_and_freshen_local() is performance sensitive, so
I think it is safer performance wise to still use a static buf.
If there is a consensus that it is ok to not use one here, I am ok to
change that. On the other hand the change could also be part of
another patch on top of this one...
>>> static int check_and_freshen_nonlocal(const unsigned char *sha1, int
>>> freshen)
>>> @@ -866,8 +867,12 @@ static int stat_sha1_file(const unsigned char *sha1,
>>> struct stat *st,
>>> const char **path)
>>> {
>>> struct alternate_object_database *alt;
>>> + static struct strbuf buf = STRBUF_INIT;
>>> +
>>> + strbuf_reset(&buf);
>>> + sha1_file_name(&buf, sha1);
>>> + *path = buf.buf;
>>> - *path = sha1_file_name(sha1);
>>> if (!lstat(*path, st))
>>> return 0;
>
> Again, making "buf" static here feels wrong. Perhaps, change the signature
> of the static function to drop the const on the "path" and strbuf_detach
> buf.buf
> and give it to the caller (if path is not NULL) and otherwise release it
> here.
I don't think it is a good idea to do too many things in this patch,
so I think it should be part of another patch to change the way
stat_sha1_file() works.
>>> @@ -891,8 +896,12 @@ static int open_sha1_file(const unsigned char *sha1,
>>> const char **path)
>>> int fd;
>>> struct alternate_object_database *alt;
>>> int most_interesting_errno;
>>> + static struct strbuf buf = STRBUF_INIT;
>>> +
>>> + strbuf_reset(&buf);
>>> + sha1_file_name(&buf, sha1);
>>> + *path = buf.buf;
>>> - *path = sha1_file_name(sha1);
>>> fd = git_open(*path);
>>> if (fd >= 0)
>>> return fd;
>
> Same comment here about the static strbuf.
Same comment for me too.
>> The check_and_freshen_nonlocal() and open_sha1_file() method comments
Actually I think it is stat_sha1_file() and open_sha1_file() that have
those comments.
>> warn
>> about the 'path' pointer and how it could be overwritten with another call
>> to sha1_file_name(). Your patch fixes that issue, so the comments can be
>> removed.
>
> Wait, we've eliminated the static buffer inside sha1_file_name(), but
> all of these callers currently define their own static buffers, so the
> comments still apply, right?
Yeah right, that's why I didn't change the comments.
> There is also an effectively static buffer in each of the alternates
> that is used by alt_sha1_path().
Yeah and I didn't change that, so anyway, if you want to get rid of
all the static buffers, other work than just this patch is needed.
>> Since these methods are currently being extra careful about the 'path'
>> parameter, perhaps these are candidates to keep a static buffer around?
>
> If I have multiple threads (as part of say a threaded checkout), we're
> still going to stumble over these static loose object pathname buffers,
> right?
I agree but again getting rid of all the static buffers is not the
goal of this patch series.
[...]
>> Thanks for this cleanup!
>
> Yes, thanks for digging into this!
Thanks for your comments,
Christian.
^ permalink raw reply [relevance 5%]
* Re: [PATCH v3 1/7] git-compat-util: introduce skip_to_optional_arg()
@ 2017-12-11 5:56 6% ` Christian Couder
0 siblings, 0 replies; 114+ results
From: Christian Couder @ 2017-12-11 5:56 UTC (permalink / raw)
To: Jeff King
Cc: git, Junio C Hamano, Donald R Laster Jr, Jacob Keller,
Christian Couder
On Sun, Dec 10, 2017 at 3:39 PM, Jeff King <peff@peff.net> wrote:
> On Sun, Dec 10, 2017 at 09:31:18AM -0500, Jeff King wrote:
>
>> On Sat, Dec 09, 2017 at 09:40:07PM +0100, Christian Couder wrote:
>>
>> > The changes compared to v2 are:
>> >
>> > - s/_val/_arg/ in the name of the functions
>> > - s/val/arg/ in the name of the third argument of the functions
>> > - works with NULL as third argument of the functions
>>
>> This whole series looks OK to me, but this third point made me wonder:
>> what would be the use of allowing NULL for the "arg" parameter?
>>
>> I didn't see any use of this in the series, and I'm having trouble
>> figuring out how it would be useful. E.g., if I do:
>>
>> if (skip_to_optional_arg(arg, "--foo", NULL))
>> ...
>>
>> what can I do in "..."? I know we matched _some_ type of "--foo", but I
>> cannot know whether it was "--foo" or "--foo=bar", nor what "bar" is. It
>> could only be used by some kind of vague validator to say "well, at
>> least this looks like an option that I _could_ parse if I wanted to".
>>
>> So I guess I don't mind it, as it does the most reasonable thing it can
>> when passed NULL, but I would be surprised if we ever actually exercise
>> the code path.
>
> And of course as soon as I sent this, I went back and double-checked.
> And indeed I totally missed this call:
>
> + else if (starts_with(arg, "-B") ||
> + skip_to_optional_arg(arg, "--break-rewrites", NULL)) {
> if ((options->break_opt = diff_scoreopt_parse(arg)) == -1)
Yeah, calls like this were discussed in:
https://public-inbox.org/git/xmqqh8t6o9me.fsf@gitster.mtv.corp.google.com/
> So that's kind-of weird, because we are parsing "-B", etc, and then
> expecting it to be _reparsed_ by diff_scoreopt_parse. So the two
> callsites must always match. IMHO this ought to do either:
>
> - we should just ask diff_scoreopt_parser to tell us if this was a
> valid option that it understood
>
> or
>
> - parse up to the "=", and then ask the scoreopt parser to parse the
> remainder. This would require us passing 'B'/'C'/'M' to the
> function ourselves, I think that's a better pattern. It means we
> could reuse the parser for things like config values if we wanted to
> (our current diff.renames is a bool, but it would not be
> unreasonable for it to take a score).
>
> None of that is a mess of your creation, though, so I'm OK punting on it
> for now.
Yeah, this could be part of the #leftoverbits.
^ permalink raw reply [relevance 6%]
* Re: [PATCH V4] config: add --expiry-date
2017-11-20 20:37 0% ` Jeff King
@ 2017-11-30 11:18 0% ` Heiko Voigt
0 siblings, 0 replies; 114+ results
From: Heiko Voigt @ 2017-11-30 11:18 UTC (permalink / raw)
To: Jeff King; +Cc: Stefan Beller, Junio C Hamano, hsed, git
On Mon, Nov 20, 2017 at 03:37:03PM -0500, Jeff King wrote:
> On Mon, Nov 20, 2017 at 12:28:11PM -0800, Stefan Beller wrote:
>
> > > +cc Stefan, who added the die(). It may be that we don't care that much
> > > these days about recovering from broken .gitmodules files.
> >
> > By that you mean commits like 37f52e9344 (submodule-config:
> > keep shallow recommendation around, 2016-05-26) for example?
> > That adds a git_config_bool to the submodule config machinery.
>
> I actually meant ea2fa5a338 (submodule-config: keep update strategy
> around, 2016-02-29), which adds an actual die() into parse_config(). But
> yeah, I think the end result is the same.
>
> > I agree that we'd want to be more careful, but for now I'd put it to the
> > #leftoverbits.
>
> Fine by me. While I think the original intent was to be more lenient to
> malformed .gitmodules, it's not like we're seeing bug reports about it.
My original intent was not about being more lenient about malformed
.gitmodules but having a way to deal with repository history that might
have a malformed .gitmodules in its history. Since depending on the
branch it is on it might be quite carved in stone.
On an active project it would not be that easy to rewrite history to get
out of that situation.
When a .gitmodules file in the worktree is malformed it is easy to fix.
That is not the case when we are reading configurations from blobs.
My guess why there are no reports is that maybe not too many users are
using this infrastructure yet, plus it is probably seldom that someone
edits the .gitmodules file by hand which could lead to such a situation.
But if such an error occurs it will be very annoying if we die while
parsing submodule configurations. The only solution I see currently is
to turn submodule recursion off completely.
But maybe I am being overly cautious here.
Cheers Heiko
^ permalink raw reply [relevance 0%]
* Re: [RFC PATCH v2] builtin/worktree: enhance worktree removal
@ 2017-11-28 16:46 6% ` Kaartic Sivaraam
0 siblings, 0 replies; 114+ results
From: Kaartic Sivaraam @ 2017-11-28 16:46 UTC (permalink / raw)
To: Junio C Hamano, Eric Sunshine
Cc: Nguyễn Thái Ngọc Duy, Git Mailing List
On Tuesday 28 November 2017 09:34 AM, Junio C Hamano wrote:
> Eric Sunshine <sunshine@sunshineco.com> writes:
>
>> With this approach, validate_worktree() will print an error message
>> saying that the worktree directory is missing before the control info
>> is actually removed. Kaartic's original patch silenced the message
>> (and _all_ error messages from validate_worktree()) by passing 1 as
>> the second argument. That seemed heavy-handed, so I suggested keeping
>> the validate_worktree() call as-is but doing the directory-missing
>> check first as a special case.
>>
>> But perhaps that special case isn't necessary.
>
> I do not think the user minds to see "there is no such directory
> there"; actually that would be beneficial, even.
>
> But you are right; validate_worktree() would need to become aware of
> the possibility that it can be passed such a "corrupt" worktree to
> handle if that approach is followed.
>
> The case we are discussing, i.e. the user removed the directory
> without telling Git to give it a chance to remove control
> information, may be common enough that it becomes a worthwhile
> addition to make the "quiet" boolean that occupies a whole int to an
> unsigned that is a collection of bits, and pass "missing_ok" bit in
> that flag word to the validate_worktree() to tell that the caller
> can tolerate the "user removed it while we were looking the other
> way" case and can handle it gracefully. But that would be a lot
> larger change, and "the caller checks before calling validate" as
> done with this [RFC v2] may be a good way to add the feature with
> the least impact to the codebase.
>
>> I had envisioned a simple 'goto remove_control_info' rather than extra
>> nesting or refactoring, but that's a minor point.
>
> Yes, use of goto is also a good way to avoid having to worry about
> the future evolution of the codeflow in this function.
>
> So perhaps
>
> if (the directory is no longer there)
> goto cleanup;
> if (the worktree does not validate)
> return -1;
> ... the original code to (carefully) remove the
> ... worktree itself
>
> cleanup:
>
> ... remove control info
> ... free resources held in variables
> ... return from the function
>
> is what we want?
>
Probably but I'm not interested in going for a v3 that does that as I
just wanted to show that worktree remove could be enhanced in this
aspect and show how it could be done. So, I'll leave this in the
#leftoverbits for the person who would be re-rolling nd/worktree-move.
---
Kaartic
^ permalink raw reply [relevance 6%]
* Re: [PATCH 1/1] diffcore: add a filter to find a specific blob
2017-11-20 22:25 3% ` [PATCH 1/1] diffcore: add a filter to find a specific blob Stefan Beller
@ 2017-11-24 7:43 0% ` Junio C Hamano
0 siblings, 0 replies; 114+ results
From: Junio C Hamano @ 2017-11-24 7:43 UTC (permalink / raw)
To: Stefan Beller; +Cc: git
Stefan Beller <sbeller@google.com> writes:
> Sometimes users are given a hash of an object and they want to
> identify it further (ex.: Use verify-pack to find the largest blobs,
> but what are these? or [1])
>
> One might be tempted to extend git-describe to also work with blobs,
> such that `git describe <blob-id>` gives a description as
> '<commit-ish>:<path>'. This was implemented at [2]; as seen by the sheer
> number of responses (>110), it turns out this is tricky to get right.
> The hard part to get right is picking the correct 'commit-ish' as that
> could be the commit that (re-)introduced the blob or the blob that
> removed the blob; the blob could exist in different branches.
>
> Junio hinted at a different approach of solving this problem, which this
> patch implements. Teach the diff machinery another flag for restricting
> the information to what is shown. For example:
>
> $ ./git log --oneline --blobfind=v2.0.0:Makefile
> b2feb64309 Revert the whole "ask curl-config" topic for now
> 47fbfded53 i18n: only extract comments marked with "TRANSLATORS:"
>
> we observe that the Makefile as shipped with 2.0 was introduced in
> v1.9.2-471-g47fbfded53 and replaced in v2.0.0-rc1-5-gb2feb64309 by
> a different blob.
>
> [1] https://stackoverflow.com/questions/223678/which-commit-has-this-blob
> [2] https://public-inbox.org/git/20171028004419.10139-1-sbeller@google.com/
>
> Signed-off-by: Stefan Beller <sbeller@google.com>
> ---
>
> On playing around with this, trying to find more interesting cases, I observed:
>
> git log --oneline --blobfind=HEAD:COPYING
> 703601d678 Update COPYING with GPLv2 with new FSF address
>
> git log --oneline --blobfind=703601d678^:COPYING
> 459b8d22e5 tests: do not borrow from COPYING and README from the real source
> 703601d678 Update COPYING with GPLv2 with new FSF address
> 075b845a85 Add a COPYING notice, making it explicit that the license is GPLv2.
>
> t/diff-lib/COPYING may need an update of the adress of the FSF,
> # leftoverbits I guess.
I do not think so. See tz/fsf-address-update topic for details.
Please do not contaminate the list archive with careless mention of
"hash-mark plus left over bits", as it will make searching the real
good bits harder. Thanks.
> Another interesting case that I found was
> git log --oneline --blobfind=v2.14.0:Makefile
> 3921a0b3c3 perf: add test for writing the index
> 36f048c5e4 sha1dc: build git plumbing code more explicitly
> 2118805b92 Makefile: add style build rule
>
> all of which were after v2.14, such that the introduction of that blob doesn't
> show up; I suspect it came in via a merge as unrelated series may have updated
> the Makefile in parallel, though git-log should have told me?
If that is the case, shouldn't we make this new mode imply
--full-history to forbid history simplification? "git log" is a
tool to find _an_ explanation of the current state, and the usual
history simplification makes tons of sense there, but blobfind is
run most likely in order to find _all_ mention of the set of blobs
given.
> diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
> index dd0dba5b1d..252a21cc19 100644
> --- a/Documentation/diff-options.txt
> +++ b/Documentation/diff-options.txt
> @@ -500,6 +500,10 @@ information.
> --pickaxe-regex::
> Treat the <string> given to `-S` as an extended POSIX regular
> expression to match.
> +--blobfind=<blob-id>::
> + Restrict the output such that one side of the diff
> + matches the given blob-id.
> +
> endif::git-format-patch[]
Can we have a blank line between these enumerations to make the
source easier to read? Thanks.
> diff --git a/diffcore-blobfind.c b/diffcore-blobfind.c
> new file mode 100644
> index 0000000000..5d222fc336
> --- /dev/null
> +++ b/diffcore-blobfind.c
> @@ -0,0 +1,51 @@
> +/*
> + * Copyright (c) 2017 Google Inc.
> + */
> +#include "cache.h"
> +#include "diff.h"
> +#include "diffcore.h"
> +
> +static void diffcore_filter_blobs(struct diff_queue_struct *q,
> + struct diff_options *options)
> +{
> + int i, j = 0, c = q->nr;
> +
> + if (!options->blobfind)
> + BUG("blobfind oidset not initialized???");
> +
> + for (i = 0; i < q->nr; i++) {
> + struct diff_filepair *p = q->queue[i];
> +
> + if (DIFF_PAIR_UNMERGED(p) ||
> + (DIFF_FILE_VALID(p->one) &&
> + oidset_contains(options->blobfind, &p->one->oid)) ||
> + (DIFF_FILE_VALID(p->two) &&
> + oidset_contains(options->blobfind, &p->two->oid)))
> + continue;
So, we keep an unmerged pair, a pair that mentions a sought-blob on
one side or the other side? I am not sure if we want to keep the
unmerged pair for the purpose of this one.
> + diff_free_filepair(p);
> + q->queue[i] = NULL;
> + c--;
Also, if you are doing the in-place shrinking and have already
introduced another counter 'j' that is initialized to 0, I think it
makes more sense to do the shrinking in-place. 'i' will stay to be
the source-scan pointer that runs 0 thru q->nr, while 'j' can be
used in this loop (where you have 'continue') to move the current
one that is determined to survive from q->queue[i] to q->queue[j++].
Then you do not need 'c'; when the loop ends, 'j' would be the
number of surviving entries and q->nr can be adjusted to it. Unlike
the usual pattern taken by the other diffcore transformations where
a new queue is populated and the old one discarded, this would leave
the q->queue[] over-allocated, but I do not think it is too bad.
^ permalink raw reply [relevance 0%]
* Re: [PATCH 1/8] ssh test: make copy_ssh_wrapper_as clean up after itself
@ 2017-11-21 1:24 6% ` Junio C Hamano
0 siblings, 0 replies; 114+ results
From: Junio C Hamano @ 2017-11-21 1:24 UTC (permalink / raw)
To: Jonathan Nieder
Cc: git, Brandon Williams, Stefan Beller, Jonathan Tan, Segev Finer,
Johannes Schindelin
Jonathan Nieder <jrnieder@gmail.com> writes:
> +test_expect_success 'set up ssh wrapper' '
> + cp "$GIT_BUILD_DIR/t/helper/test-fake-ssh$X" \
> + "$TRASH_DIRECTORY/ssh$X" &&
> + GIT_SSH="$TRASH_DIRECTORY/ssh$X" &&
> + export GIT_SSH &&
> + export TRASH_DIRECTORY &&
> + >"$TRASH_DIRECTORY"/ssh-output
> +'
>
> copy_ssh_wrapper_as () {
> cp "$TRASH_DIRECTORY/ssh$X" "${1%$X}$X" &&
> + test_when_finished "rm -f ${1%$X}$X" &&
> GIT_SSH="${1%$X}$X" &&
As we can clearly see in the context, this is not a new issue, but I
find the users of this helper that benefit from the "${1%$X}$X"
magic somewhat iffy.
There are callers of this helper that pass "somedir/plink" and
"somedir/plink.exe", but behind these callers that _think_ they are
testing the variant with and without the trailing ".exe", the helper
always add ".exe" (after stripping an existing one) on $X=.exe
platforms, ending up in testing the same thing twice. On platforms
with $X='', testing two different command names may have "some"
value, but I wonder if it is cleaner to use a much less magical
"$1$X" here, and skip the test with a caller that gives ".exe"
variant using a test prerequisite on $X=.exe platforms to avoid
redundant tests?
This is totally outside the scope of this series; I mention this
only because this may be a possible #leftoverbits.
Thanks.
^ permalink raw reply [relevance 6%]
* [PATCH 1/1] diffcore: add a filter to find a specific blob
@ 2017-11-20 22:25 3% ` Stefan Beller
2017-11-24 7:43 0% ` Junio C Hamano
0 siblings, 1 reply; 114+ results
From: Stefan Beller @ 2017-11-20 22:25 UTC (permalink / raw)
To: git; +Cc: Stefan Beller
Sometimes users are given a hash of an object and they want to
identify it further (ex.: Use verify-pack to find the largest blobs,
but what are these? or [1])
One might be tempted to extend git-describe to also work with blobs,
such that `git describe <blob-id>` gives a description as
'<commit-ish>:<path>'. This was implemented at [2]; as seen by the sheer
number of responses (>110), it turns out this is tricky to get right.
The hard part to get right is picking the correct 'commit-ish' as that
could be the commit that (re-)introduced the blob or the blob that
removed the blob; the blob could exist in different branches.
Junio hinted at a different approach of solving this problem, which this
patch implements. Teach the diff machinery another flag for restricting
the information to what is shown. For example:
$ ./git log --oneline --blobfind=v2.0.0:Makefile
b2feb64309 Revert the whole "ask curl-config" topic for now
47fbfded53 i18n: only extract comments marked with "TRANSLATORS:"
we observe that the Makefile as shipped with 2.0 was introduced in
v1.9.2-471-g47fbfded53 and replaced in v2.0.0-rc1-5-gb2feb64309 by
a different blob.
[1] https://stackoverflow.com/questions/223678/which-commit-has-this-blob
[2] https://public-inbox.org/git/20171028004419.10139-1-sbeller@google.com/
Signed-off-by: Stefan Beller <sbeller@google.com>
---
On playing around with this, trying to find more interesting cases, I observed:
git log --oneline --blobfind=HEAD:COPYING
703601d678 Update COPYING with GPLv2 with new FSF address
git log --oneline --blobfind=703601d678^:COPYING
459b8d22e5 tests: do not borrow from COPYING and README from the real source
703601d678 Update COPYING with GPLv2 with new FSF address
075b845a85 Add a COPYING notice, making it explicit that the license is GPLv2.
t/diff-lib/COPYING may need an update of the adress of the FSF,
#leftoverbits I guess.
Another interesting case that I found was
git log --oneline --blobfind=v2.14.0:Makefile
3921a0b3c3 perf: add test for writing the index
36f048c5e4 sha1dc: build git plumbing code more explicitly
2118805b92 Makefile: add style build rule
all of which were after v2.14, such that the introduction of that blob doesn't
show up; I suspect it came in via a merge as unrelated series may have updated
the Makefile in parallel, though git-log should have told me?
Thanks,
Stefan
Documentation/diff-options.txt | 4 ++++
Makefile | 1 +
builtin/log.c | 2 +-
diff.c | 20 ++++++++++++++++-
diff.h | 3 +++
diffcore-blobfind.c | 51 ++++++++++++++++++++++++++++++++++++++++++
diffcore.h | 1 +
revision.c | 3 ++-
t/t4064-diff-blobfind.sh | 35 +++++++++++++++++++++++++++++
9 files changed, 117 insertions(+), 3 deletions(-)
create mode 100644 diffcore-blobfind.c
create mode 100755 t/t4064-diff-blobfind.sh
diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
index dd0dba5b1d..252a21cc19 100644
--- a/Documentation/diff-options.txt
+++ b/Documentation/diff-options.txt
@@ -500,6 +500,10 @@ information.
--pickaxe-regex::
Treat the <string> given to `-S` as an extended POSIX regular
expression to match.
+--blobfind=<blob-id>::
+ Restrict the output such that one side of the diff
+ matches the given blob-id.
+
endif::git-format-patch[]
-O<orderfile>::
diff --git a/Makefile b/Makefile
index ee9d5eb11e..fdfa8f38f6 100644
--- a/Makefile
+++ b/Makefile
@@ -775,6 +775,7 @@ LIB_OBJS += date.o
LIB_OBJS += decorate.o
LIB_OBJS += diffcore-break.o
LIB_OBJS += diffcore-delta.o
+LIB_OBJS += diffcore-blobfind.o
LIB_OBJS += diffcore-order.o
LIB_OBJS += diffcore-pickaxe.o
LIB_OBJS += diffcore-rename.o
diff --git a/builtin/log.c b/builtin/log.c
index 6c1fa896ad..7b91f61423 100644
--- a/builtin/log.c
+++ b/builtin/log.c
@@ -181,7 +181,7 @@ static void cmd_log_init_finish(int argc, const char **argv, const char *prefix,
init_display_notes(&rev->notes_opt);
if (rev->diffopt.pickaxe || rev->diffopt.filter ||
- rev->diffopt.flags.follow_renames)
+ rev->diffopt.flags.follow_renames || rev->diffopt.blobfind)
rev->always_show_header = 0;
if (source)
diff --git a/diff.c b/diff.c
index 0763e89263..8861f89ab1 100644
--- a/diff.c
+++ b/diff.c
@@ -4082,6 +4082,7 @@ void diff_setup(struct diff_options *options)
options->interhunkcontext = diff_interhunk_context_default;
options->ws_error_highlight = ws_error_highlight_default;
options->flags.rename_empty = 1;
+ options->blobfind = NULL;
/* pathchange left =NULL by default */
options->change = diff_change;
@@ -4487,6 +4488,19 @@ static int parse_ws_error_highlight_opt(struct diff_options *opt, const char *ar
return 1;
}
+static int parse_blobfind_opt(struct diff_options *opt, const char *arg)
+{
+ struct object_id oid;
+
+ if (get_oid_blob(arg, &oid) || sha1_object_info(oid.hash, NULL) != OBJ_BLOB)
+ return error("object '%s' is not a blob", arg);
+
+ if (!opt->blobfind)
+ opt->blobfind = xcalloc(1, sizeof(*opt->blobfind));
+ oidset_insert(opt->blobfind, &oid);
+ return 1;
+}
+
int diff_opt_parse(struct diff_options *options,
const char **av, int ac, const char *prefix)
{
@@ -4736,7 +4750,8 @@ int diff_opt_parse(struct diff_options *options,
else if ((argcount = short_opt('O', av, &optarg))) {
options->orderfile = prefix_filename(prefix, optarg);
return argcount;
- }
+ } else if (skip_prefix(arg, "--blobfind=", &arg))
+ return parse_blobfind_opt(options, arg);
else if ((argcount = parse_long_opt("diff-filter", av, &optarg))) {
int offending = parse_diff_filter_opt(optarg, options);
if (offending)
@@ -5770,6 +5785,9 @@ void diffcore_std(struct diff_options *options)
diffcore_skip_stat_unmatch(options);
if (!options->found_follow) {
/* See try_to_follow_renames() in tree-diff.c */
+
+ if (options->blobfind)
+ diffcore_blobfind(options);
if (options->break_opt != -1)
diffcore_break(options->break_opt);
if (options->detect_rename)
diff --git a/diff.h b/diff.h
index 0fb18dd735..9178e498fa 100644
--- a/diff.h
+++ b/diff.h
@@ -7,6 +7,7 @@
#include "tree-walk.h"
#include "pathspec.h"
#include "object.h"
+#include "oidset.h"
struct rev_info;
struct diff_options;
@@ -174,6 +175,8 @@ struct diff_options {
enum diff_words_type word_diff;
enum diff_submodule_format submodule_format;
+ struct oidset *blobfind;
+
/* this is set by diffcore for DIFF_FORMAT_PATCH */
int found_changes;
diff --git a/diffcore-blobfind.c b/diffcore-blobfind.c
new file mode 100644
index 0000000000..5d222fc336
--- /dev/null
+++ b/diffcore-blobfind.c
@@ -0,0 +1,51 @@
+/*
+ * Copyright (c) 2017 Google Inc.
+ */
+#include "cache.h"
+#include "diff.h"
+#include "diffcore.h"
+
+static void diffcore_filter_blobs(struct diff_queue_struct *q,
+ struct diff_options *options)
+{
+ int i, j = 0, c = q->nr;
+
+ if (!options->blobfind)
+ BUG("blobfind oidset not initialized???");
+
+ for (i = 0; i < q->nr; i++) {
+ struct diff_filepair *p = q->queue[i];
+
+ if (DIFF_PAIR_UNMERGED(p) ||
+ (DIFF_FILE_VALID(p->one) &&
+ oidset_contains(options->blobfind, &p->one->oid)) ||
+ (DIFF_FILE_VALID(p->two) &&
+ oidset_contains(options->blobfind, &p->two->oid)))
+ continue;
+
+ diff_free_filepair(p);
+ q->queue[i] = NULL;
+ c--;
+ }
+
+ /* Keep it sorted. */
+ i = 0; j = 0;
+ while (i < c) {
+ while (!q->queue[j])
+ j++;
+ q->queue[i] = q->queue[j];
+ i++; j++;
+ }
+
+ q->nr = c;
+
+ if (!c) {
+ free(q->queue);
+ DIFF_QUEUE_CLEAR(q);
+ }
+}
+
+void diffcore_blobfind(struct diff_options *options)
+{
+ diffcore_filter_blobs(&diff_queued_diff, options);
+}
diff --git a/diffcore.h b/diffcore.h
index a30da161da..431917672f 100644
--- a/diffcore.h
+++ b/diffcore.h
@@ -107,6 +107,7 @@ extern struct diff_filepair *diff_queue(struct diff_queue_struct *,
struct diff_filespec *);
extern void diff_q(struct diff_queue_struct *, struct diff_filepair *);
+extern void diffcore_blobfind(struct diff_options *);
extern void diffcore_break(int);
extern void diffcore_rename(struct diff_options *);
extern void diffcore_merge_broken(void);
diff --git a/revision.c b/revision.c
index e2e691dd5a..6449619c0a 100644
--- a/revision.c
+++ b/revision.c
@@ -2409,7 +2409,8 @@ int setup_revisions(int argc, const char **argv, struct rev_info *revs, struct s
/* Pickaxe, diff-filter and rename following need diffs */
if (revs->diffopt.pickaxe ||
revs->diffopt.filter ||
- revs->diffopt.flags.follow_renames)
+ revs->diffopt.flags.follow_renames ||
+ revs->diffopt.blobfind)
revs->diff = 1;
if (revs->topo_order)
diff --git a/t/t4064-diff-blobfind.sh b/t/t4064-diff-blobfind.sh
new file mode 100755
index 0000000000..b2c2964d77
--- /dev/null
+++ b/t/t4064-diff-blobfind.sh
@@ -0,0 +1,35 @@
+#!/bin/sh
+
+test_description='test finding specific blobs in the revision walking'
+. ./test-lib.sh
+
+test_expect_success 'setup ' '
+ git commit --allow-empty -m "empty initial commit" &&
+
+ echo "Hello, world!" >greeting &&
+ git add greeting &&
+ git commit -m "add the greeting blob" && # borrowed from Git from the Bottom Up
+ git tag -m "the blob" greeting $(git rev-parse HEAD:greeting) &&
+
+ echo asdf >unrelated &&
+ git add unrelated &&
+ git commit -m "unrelated history" &&
+
+ git revert HEAD^ &&
+
+ git commit --allow-empty -m "another unrelated commit"
+'
+
+test_expect_success 'find the greeting blob' '
+ cat >expect <<-EOF &&
+ Revert "add the greeting blob"
+ add the greeting blob
+ EOF
+
+ git log --abbrev=12 --oneline --blobfind=greeting^{blob} >actual.raw &&
+ cut -c 14- actual.raw >actual &&
+
+ test_cmp expect actual
+'
+
+test_done
--
2.15.0.128.gcadd42da22
^ permalink raw reply related [relevance 3%]
* Re: [PATCH V4] config: add --expiry-date
2017-11-20 20:28 6% ` Stefan Beller
@ 2017-11-20 20:37 0% ` Jeff King
2017-11-30 11:18 0% ` Heiko Voigt
0 siblings, 1 reply; 114+ results
From: Jeff King @ 2017-11-20 20:37 UTC (permalink / raw)
To: Stefan Beller; +Cc: Junio C Hamano, hsed, git, Heiko Voigt
On Mon, Nov 20, 2017 at 12:28:11PM -0800, Stefan Beller wrote:
> > +cc Stefan, who added the die(). It may be that we don't care that much
> > these days about recovering from broken .gitmodules files.
>
> By that you mean commits like 37f52e9344 (submodule-config:
> keep shallow recommendation around, 2016-05-26) for example?
> That adds a git_config_bool to the submodule config machinery.
I actually meant ea2fa5a338 (submodule-config: keep update strategy
around, 2016-02-29), which adds an actual die() into parse_config(). But
yeah, I think the end result is the same.
> I agree that we'd want to be more careful, but for now I'd put it to the
> #leftoverbits.
Fine by me. While I think the original intent was to be more lenient to
malformed .gitmodules, it's not like we're seeing bug reports about it.
-Peff
^ permalink raw reply [relevance 0%]
* Re: [PATCH V4] config: add --expiry-date
2017-11-20 17:04 0% ` Jeff King
@ 2017-11-20 20:28 6% ` Stefan Beller
2017-11-20 20:37 0% ` Jeff King
0 siblings, 1 reply; 114+ results
From: Stefan Beller @ 2017-11-20 20:28 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, hsed, git, Heiko Voigt
On Mon, Nov 20, 2017 at 9:04 AM, Jeff King <peff@peff.net> wrote:
> On Sat, Nov 18, 2017 at 12:37:03PM +0900, Junio C Hamano wrote:
>
>> > +int git_config_expiry_date(timestamp_t *timestamp, const char *var, const char *value)
>> > +{
>> > + if (!value)
>> > + return config_error_nonbool(var);
>> > + if (parse_expiry_date(value, timestamp))
>> > + return error(_("'%s' for '%s' is not a valid timestamp"),
>> > + value, var);
>> > + return 0;
>> > +}
>> > +
>>
>> I think this is more correct even within the context of this
>> function than dying, which suggests the need for a slightly related
>> (which is not within the scope of this change) clean-up within this
>> file as a #leftoverbits task. I think dying in these value parsers
>> goes against the point of having die_on_error bit in the
>> config-source structure; Heiko and Peff CC'ed for b2dc0945 ("do not
>> die when error in config parsing of buf occurs", 2013-07-12).
>
> Yes, I agree that ideally the value parsers should avoid dying.
> Unfortunately I think it will involve some heavy refactoring, since
> git_config_bool(), for instance, does not even have a spot in its
> interface to return an error.
>
> Of course we can leave those other helpers in place and add a "gently"
> form for each. It is really only submodule-config.c that wants to be
> careful in its callback, so we could just port that. Skimming it over,
> it looks like there are a few git_config_bool() and straight-up die()
> calls that could be more forgiving.
>
> +cc Stefan, who added the die(). It may be that we don't care that much
> these days about recovering from broken .gitmodules files.
By that you mean commits like 37f52e9344 (submodule-config:
keep shallow recommendation around, 2016-05-26) for example?
That adds a git_config_bool to the submodule config machinery.
I agree that we'd want to be more careful, but for now I'd put it to the
#leftoverbits.
Thanks,
Stefan
^ permalink raw reply [relevance 6%]
* Re: [PATCH] Makefile: check that tcl/tk is installed
@ 2017-11-20 18:12 5% ` Christian Couder
0 siblings, 0 replies; 114+ results
From: Christian Couder @ 2017-11-20 18:12 UTC (permalink / raw)
To: Todd Zullinger
Cc: Junio C Hamano, git, Jeff King, Dominik Mahrer, Christian Couder
On Fri, Nov 17, 2017 at 6:42 PM, Todd Zullinger <tmz@pobox.com> wrote:
> Christian Couder wrote:
>>
>> On Thu, Nov 16, 2017 at 2:35 AM, Junio C Hamano <gitster@pobox.com> wrote:
>>>
>>> I suspect that this change will hurt those who package Git for other
>>> people.
>>
>>
>> Maybe a little bit, but in my opinion it should not be a big problem for
>> them to install Tcl/Tk and its dependencies on the build machine.
>
> It's not a big burden, but it is a seemingly unnecessary build-time
> dependency.
>
>>> It used to be that, as long as they have msgfmt installed, they only
>>> needed to _know_ what the path on the users' box to "wish" is, and set it to
>>> TCLTK_PATH, and if they are distro packagers, most likely they already have
>>> such an automated set-up working. Now with this change, they are forced to
>>> install tcl/tk on their possibly headless box where tcl/tk is useless, and
>>> worse yet, an attempt to install it may bring in tons of unwanted stuff
>>> related to X that is irrelevant on such a headless development environment.
>>
>> Yeah, but if they build gitk and git-gui, there is a significant chance
>> that they build other graphical software too, and that this will require
>> installing stuff related to X anyway.
>
> Most distributions build packages in individual container or chroots, to
> increase the stability and reproducibility of the builds. So package builds
> don't run on systems where any deps have already been installed.
>
> To be fair, it looks like pulling in tcl/tk would add only around 8MB to the
> Fedora build root for git. That's not egregious, to be sure. But it really
> isn't a necessary build-time dependency either. I don't know if there are
> other distros who would strongly object to pulling in tcl/tk. Some are much
> more sensitive to build root sizes and unnecessary dependencies.
Yeah, I still think that when packaging graphical tools, packagers
should be used to managing builds that need a lot of dependencies
(especially X related dependencies). I used to be a KDE developer in a
previous life and the amount of dependencies to build KDE was much
larger than what is required for everything in the git repo (git,
gitk, git-gui, git-svn, etc).
>> In general I think packagers are much more able to deal with those kinds
>> of problems than most regular developers who want to hack on Git.
>
> I agree. Packagers also provide git builds to the vast majority of
> end-users, so we should make their task easier whenever possible. :)
Yeah, but you might have noticed that such checks might be a good
thing for packagers, as it makes the build fail right away with a
clear error message. So in the long run, I think this kind of patches
will make it easier also for packagers.
>> So asking packagers to either set NO_TCLTK or BYPASS_TCLTK_CHECK or to
>> install Tcl/Tk would not burden them much, especially compared to what
>> regular developers have to deal with these days when trying to build Git.
>
> Presuming this new BYPASS_TCLTK_CHECK is communicated well and that the
> failure when not using it is clear, this doesn't seem likely to cause
> problems.
Yeah I agree.
> (I'll leave it to others whether there's a better way to solve
> the msgfmt fallthrough issue. I didn't even know such a fallthrough existed
> until yesterday.)
I might also send a similar patch for the msgfmt issue, otherwise it
may be a good #leftoverbit for someone starting to hack on Git.
But anyway it is a separate issue.
> I think it's important to ensure that automated package builds of a newer
> git don't simply skip parts of the build which used to work and so packagers
> reading the failed builds logs can easily see what they need to adjust.
I agree and the patch doesn't skip parts of the build that used to
work, and actually it makes logs easier to understand and build
failures easier to fix.
> Just dropping the new variable in the Makefile and waiting for package
> builds to fail or not package gitk & git-gui at the next release would be a
> bit unkind, I think. Posting this to the git-packagers group[1] which Ævar
> created would be useful. It /might/ even be worth asking there if any
> distros have strong opinions on the subject.
>
> [1] https://groups.google.com/forum/#!forum/git-packagers and
> git-packagers@googlegroups.com
I cc'ed this list when I sent version 2 of the patch.
>>> I think "If I cannot run either wish or msgfmt, then barf and give an
>>> error message" might at least be needed. Am I misinterpreting the
>>> motivation of the patch?
>>
>> I'd rather add a separate check for msgfmt than mixing the 2 issues,
>> because I think that unless it has been explicitly told to do so, Git should
>> not try to build git-gui and gitk in the first place if there is a big
>> chance that those tools will not work.
>
> If that's a motivation, wouldn't a check in the gitk and git-gui scripts
> handle it? That would provide an error at run time to the user. This
> change is about helping the user who builds their own git and then runs it,
> so if they built git without wish installed and then ran git-gui, they'd get
> a clear error that wish is missing and could easily install it. It's not
> needed for the build, so they wouldn't need to rebuild anything.
This change is not just about people who want to build and run those
tools, but it already helps them by improving build error messages a
lot.
^ permalink raw reply [relevance 5%]
* Re: [PATCH V4] config: add --expiry-date
2017-11-18 3:37 6% ` Junio C Hamano
2017-11-20 14:53 0% ` hsed
@ 2017-11-20 17:04 0% ` Jeff King
2017-11-20 20:28 6% ` Stefan Beller
1 sibling, 1 reply; 114+ results
From: Jeff King @ 2017-11-20 17:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Stefan Beller, hsed, git, Heiko Voigt
On Sat, Nov 18, 2017 at 12:37:03PM +0900, Junio C Hamano wrote:
> > +int git_config_expiry_date(timestamp_t *timestamp, const char *var, const char *value)
> > +{
> > + if (!value)
> > + return config_error_nonbool(var);
> > + if (parse_expiry_date(value, timestamp))
> > + return error(_("'%s' for '%s' is not a valid timestamp"),
> > + value, var);
> > + return 0;
> > +}
> > +
>
> I think this is more correct even within the context of this
> function than dying, which suggests the need for a slightly related
> (which is not within the scope of this change) clean-up within this
> file as a #leftoverbits task. I think dying in these value parsers
> goes against the point of having die_on_error bit in the
> config-source structure; Heiko and Peff CC'ed for b2dc0945 ("do not
> die when error in config parsing of buf occurs", 2013-07-12).
Yes, I agree that ideally the value parsers should avoid dying.
Unfortunately I think it will involve some heavy refactoring, since
git_config_bool(), for instance, does not even have a spot in its
interface to return an error.
Of course we can leave those other helpers in place and add a "gently"
form for each. It is really only submodule-config.c that wants to be
careful in its callback, so we could just port that. Skimming it over,
it looks like there are a few git_config_bool() and straight-up die()
calls that could be more forgiving.
+cc Stefan, who added the die(). It may be that we don't care that much
these days about recovering from broken .gitmodules files.
> Thanks; will queue.
Thanks for reviewing. This was from the hackathon last weekend, but I
missed the later re-rolls amidst my return travel.
(And thank you, Haaris, for seeing it through!)
-Peff
^ permalink raw reply [relevance 0%]
* Re: [PATCH V4] config: add --expiry-date
2017-11-18 3:37 6% ` Junio C Hamano
@ 2017-11-20 14:53 0% ` hsed
2017-11-20 17:04 0% ` Jeff King
1 sibling, 0 replies; 114+ results
From: hsed @ 2017-11-20 14:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git, Jeff King
On 2017-11-18 03:37, Junio C Hamano wrote:
>
> I think this is more correct even within the context of this
> function than dying, which suggests the need for a slightly related
> (which is not within the scope of this change) clean-up within this
> file as a #leftoverbits task. I think dying in these value parsers
> goes against the point of having die_on_error bit in the
> config-source structure; Heiko and Peff CC'ed for b2dc0945 ("do not
> die when error in config parsing of buf occurs", 2013-07-12).
>
> Thanks; will queue.
Thanks a lot for all your help and I hope to do more patches in future!
Kind Regards,
Haaris
^ permalink raw reply [relevance 0%]
* Re: [PATCH V4] config: add --expiry-date
@ 2017-11-18 3:37 6% ` Junio C Hamano
2017-11-20 14:53 0% ` hsed
2017-11-20 17:04 0% ` Jeff King
0 siblings, 2 replies; 114+ results
From: Junio C Hamano @ 2017-11-18 3:37 UTC (permalink / raw)
To: hsed; +Cc: git, Heiko Voigt, Jeff King
hsed@unimetic.com writes:
> diff --git a/config.c b/config.c
> index 903abf953..64f8aa42b 100644
> --- a/config.c
> +++ b/config.c
> @@ -990,6 +990,16 @@ int git_config_pathname(const char **dest, const char *var, const char *value)
> return 0;
> }
>
> +int git_config_expiry_date(timestamp_t *timestamp, const char *var, const char *value)
> +{
> + if (!value)
> + return config_error_nonbool(var);
> + if (parse_expiry_date(value, timestamp))
> + return error(_("'%s' for '%s' is not a valid timestamp"),
> + value, var);
> + return 0;
> +}
> +
I think this is more correct even within the context of this
function than dying, which suggests the need for a slightly related
(which is not within the scope of this change) clean-up within this
file as a #leftoverbits task. I think dying in these value parsers
goes against the point of having die_on_error bit in the
config-source structure; Heiko and Peff CC'ed for b2dc0945 ("do not
die when error in config parsing of buf occurs", 2013-07-12).
Thanks; will queue.
^ permalink raw reply [relevance 6%]
* Re: some apparent inaccuracies in "man git-worktree"
2017-11-14 18:33 5% ` Eric Sunshine
@ 2017-11-14 20:10 0% ` Robert P. J. Day
0 siblings, 0 replies; 114+ results
From: Robert P. J. Day @ 2017-11-14 20:10 UTC (permalink / raw)
To: Eric Sunshine; +Cc: Git Mailing list
On Tue, 14 Nov 2017, Eric Sunshine wrote:
> On Tue, Nov 14, 2017 at 3:43 AM, Robert P. J. Day <rpjday@crashcourse.ca> wrote:
> > from "man git-worktree", there seem to be some inaccuracies in the
> > SYNOPSIS regarding the "add" subcommand:
> >
> > git worktree add \
> > [-f] [--detach] [--checkout] [--lock] [-b <new-branch>] <path> [<branch>]
> >
> > first, there's no mention of "-B" in that SYNOPSIS, even though it's
> > explained further down the man page.
>
> Omission of "-B" from the synopsis was intentional. From cbdf60fa18
> (worktree: add -b/-B options, 2015-07-06):
>
> worktree: add -b/-B options
>
> One of git-worktree's roles is to populate the new worktree, much like
> git-checkout, and thus, for convenience, ought to support several of the
> same shortcuts. Toward this goal, add -b/-B options to create a new
> branch and check it out in the new worktree.
>
> (For brevity, only -b is mentioned in the synopsis; -B is omitted.)
>
> Whether or not the omission was actually a good decision is
> questionable. The thinking, at the time, may have been that users
> already familiar with "-b" in 'git checkout' would likewise be
> familiar with (and be able to infer) "-B", thus it wasn't important to
> state its existence explicitly in the synopsis, which was already
> getting lengthy. Of course, that decision does not assist newcomers,
> so adding "-B" to the synopsis would help the page better stand on its
> own.
>
> > next, the SYNOPSIS seems misleading as it doesn't make clear that
> > the options -b, -B and --detach are mutually exclusive, which is made
> > clear in the worktree.c source:
> >
> > if (!!opts.detach + !!opts.new_branch + !!new_branch_force > 1)
> > die(_("-b, -B, and --detach are mutually exclusive"));
>
> Failure to update the synopsis to indicate mutual exclusion appears to
> be a simple oversight in ab0b2c53ed (worktree: make --detach mutually
> exclusive with -b/-B, 2015-07-17) in response to:
> https://public-inbox.org/git/55A8F4B1.9060304@drmicha.warpmail.net/
>
> > finally (and maybe i'm just not reading carefully enough), it's not
> > clear what happens if you add a worktree at a given commit without
> > specifying *any* of -b, -B or --detach. the obvious result should be a
> > new worktree checked out at a detached HEAD and, interestingly, if i
> > do that, then from the main tree, i see:
> >
> > $ git worktree list
> > /home/rpjday/k/git 516fb7f2e73d [master]
> > /home/rpjday/k/temp c470abd4fde4 (detached HEAD)
> > $
> >
> > but from within the worktree, if i ask for the status, i see only:
> >
> > $ git status
> > Not currently on any branch.
> > nothing to commit, working tree clean
> > $
> >
> > where i would normally have expected to see "detached HEAD", is there
> > a reason that's not displayed?
>
> Someone more familiar with this bit can correct me if I'm wrong, but I
> believe that the "HEAD detached at/from <branch>" you normally see
> with 'git status' is derived from the reflog, and if it can't find the
> information in the reflog, it instead shows the generic "Not currently
> on any branch" (which is the equivalent of the "(detached HEAD)" you
> see in "git worktree list").
>
> Each worktree has its own newly-created reflog, which does _not_
> contain enough information for 'git status' to present the more
> detailed "detached" message, thus it falls back to the generic one.
> Perhaps seeding the worktree's reflog with a bit more information at
> creation time would be a good #leftoverbits task.
i'm not sure what i can add to this, but i'm going to leave it to
folks higher up the food chain than me to resolve any of the above.
rday
--
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================
^ permalink raw reply [relevance 0%]
* Re: some apparent inaccuracies in "man git-worktree"
@ 2017-11-14 18:33 5% ` Eric Sunshine
2017-11-14 20:10 0% ` Robert P. J. Day
0 siblings, 1 reply; 114+ results
From: Eric Sunshine @ 2017-11-14 18:33 UTC (permalink / raw)
To: Robert P. J. Day; +Cc: Git Mailing list
On Tue, Nov 14, 2017 at 3:43 AM, Robert P. J. Day <rpjday@crashcourse.ca> wrote:
> from "man git-worktree", there seem to be some inaccuracies in the
> SYNOPSIS regarding the "add" subcommand:
>
> git worktree add \
> [-f] [--detach] [--checkout] [--lock] [-b <new-branch>] <path> [<branch>]
>
> first, there's no mention of "-B" in that SYNOPSIS, even though it's
> explained further down the man page.
Omission of "-B" from the synopsis was intentional. From cbdf60fa18
(worktree: add -b/-B options, 2015-07-06):
worktree: add -b/-B options
One of git-worktree's roles is to populate the new worktree, much like
git-checkout, and thus, for convenience, ought to support several of the
same shortcuts. Toward this goal, add -b/-B options to create a new
branch and check it out in the new worktree.
(For brevity, only -b is mentioned in the synopsis; -B is omitted.)
Whether or not the omission was actually a good decision is
questionable. The thinking, at the time, may have been that users
already familiar with "-b" in 'git checkout' would likewise be
familiar with (and be able to infer) "-B", thus it wasn't important to
state its existence explicitly in the synopsis, which was already
getting lengthy. Of course, that decision does not assist newcomers,
so adding "-B" to the synopsis would help the page better stand on its
own.
> next, the SYNOPSIS seems misleading as it doesn't make clear that
> the options -b, -B and --detach are mutually exclusive, which is made
> clear in the worktree.c source:
>
> if (!!opts.detach + !!opts.new_branch + !!new_branch_force > 1)
> die(_("-b, -B, and --detach are mutually exclusive"));
Failure to update the synopsis to indicate mutual exclusion appears to
be a simple oversight in ab0b2c53ed (worktree: make --detach mutually
exclusive with -b/-B, 2015-07-17) in response to:
https://public-inbox.org/git/55A8F4B1.9060304@drmicha.warpmail.net/
> finally (and maybe i'm just not reading carefully enough), it's not
> clear what happens if you add a worktree at a given commit without
> specifying *any* of -b, -B or --detach. the obvious result should be a
> new worktree checked out at a detached HEAD and, interestingly, if i
> do that, then from the main tree, i see:
>
> $ git worktree list
> /home/rpjday/k/git 516fb7f2e73d [master]
> /home/rpjday/k/temp c470abd4fde4 (detached HEAD)
> $
>
> but from within the worktree, if i ask for the status, i see only:
>
> $ git status
> Not currently on any branch.
> nothing to commit, working tree clean
> $
>
> where i would normally have expected to see "detached HEAD", is there
> a reason that's not displayed?
Someone more familiar with this bit can correct me if I'm wrong, but I
believe that the "HEAD detached at/from <branch>" you normally see
with 'git status' is derived from the reflog, and if it can't find the
information in the reflog, it instead shows the generic "Not currently
on any branch" (which is the equivalent of the "(detached HEAD)" you
see in "git worktree list").
Each worktree has its own newly-created reflog, which does _not_
contain enough information for 'git status' to present the more
detailed "detached" message, thus it falls back to the generic one.
Perhaps seeding the worktree's reflog with a bit more information at
creation time would be a good #leftoverbits task.
^ permalink raw reply [relevance 5%]
* Re: [PATCH] apply: avoid out-of-bounds access in fuzzy_matchlines()
@ 2017-11-12 4:45 6% ` Junio C Hamano
0 siblings, 0 replies; 114+ results
From: Junio C Hamano @ 2017-11-12 4:45 UTC (permalink / raw)
To: René Scharfe; +Cc: mqudsi, git, Giuseppe Bilotta
René Scharfe <l.s.r@web.de> writes:
> fuzzy_matchlines() uses a pointers to the first and last characters of
> two lines to keep track while matching them. This makes it impossible
> to deal with empty strings. It accesses characters before the start of
> empty lines. It can also access characters after the end when checking
> for trailing whitespace in the main loop.
>
> Avoid that by using pointers to the first character and the one *after*
> the last one. This is well-defined as long as the latter is not
> dereferenced. Basically rewrite the function based on that premise; it
> becomes much simpler as a result. There is no need to check for
> leading whitespace outside of the main loop anymore.
I recall vaguely that we were bitten by a bug or two due to another
instance of <begin,end> that deviates from the usual "close on the
left end, open on the right end" convention somewhere in the system
recently?
I think the fix of the function is correct, but at the same time, we
would want to clean it up after this fix lands by replacing the
function with the line comparison function we already have in the
xdiff/ layer, so that we can (1) reduce the code duplication and (2)
more importantly, do not have to be constrained by the (mistakenly
narrow) policy decision we currently seem to have to support only
"ignore-whitespace-change" and nothing else. Of course, that should
not be done as part of this fix. It is strictly a #leftoverbits item.
Thanks.
> Reported-by: Mahmoud Al-Qudsi <mqudsi@neosmart.net>
> Signed-off-by: Rene Scharfe <l.s.r@web.de>
> ---
> apply.c | 59 ++++++++++++++++++++---------------------------------------
> 1 file changed, 20 insertions(+), 39 deletions(-)
>
> diff --git a/apply.c b/apply.c
> index d676debd59..b8087bd29c 100644
> --- a/apply.c
> +++ b/apply.c
> @@ -300,52 +300,33 @@ static uint32_t hash_line(const char *cp, size_t len)
> static int fuzzy_matchlines(const char *s1, size_t n1,
> const char *s2, size_t n2)
> {
> - const char *last1 = s1 + n1 - 1;
> - const char *last2 = s2 + n2 - 1;
> - int result = 0;
> + const char *end1 = s1 + n1;
> + const char *end2 = s2 + n2;
>
> /* ignore line endings */
> - while ((*last1 == '\r') || (*last1 == '\n'))
> - last1--;
> - while ((*last2 == '\r') || (*last2 == '\n'))
> - last2--;
> -
> - /* skip leading whitespaces, if both begin with whitespace */
> - if (s1 <= last1 && s2 <= last2 && isspace(*s1) && isspace(*s2)) {
> - while (isspace(*s1) && (s1 <= last1))
> - s1++;
> - while (isspace(*s2) && (s2 <= last2))
> - s2++;
> - }
> - /* early return if both lines are empty */
> - if ((s1 > last1) && (s2 > last2))
> - return 1;
> - while (!result) {
> - result = *s1++ - *s2++;
> - /*
> - * Skip whitespace inside. We check for whitespace on
> - * both buffers because we don't want "a b" to match
> - * "ab"
> - */
> - if (isspace(*s1) && isspace(*s2)) {
> - while (isspace(*s1) && s1 <= last1)
> + while (s1 < end1 && (end1[-1] == '\r' || end1[-1] == '\n'))
> + end1--;
> + while (s2 < end2 && (end2[-1] == '\r' || end2[-1] == '\n'))
> + end2--;
> +
> + while (s1 < end1 && s2 < end2) {
> + if (isspace(*s1)) {
> + /*
> + * Skip whitespace. We check on both buffers
> + * because we don't want "a b" to match "ab".
> + */
> + if (!isspace(*s2))
> + return 0;
> + while (s1 < end1 && isspace(*s1))
> s1++;
> - while (isspace(*s2) && s2 <= last2)
> + while (s2 < end2 && isspace(*s2))
> s2++;
> - }
> - /*
> - * If we reached the end on one side only,
> - * lines don't match
> - */
> - if (
> - ((s2 > last2) && (s1 <= last1)) ||
> - ((s1 > last1) && (s2 <= last2)))
> + } else if (*s1++ != *s2++)
> return 0;
> - if ((s1 > last1) && (s2 > last2))
> - break;
> }
>
> - return !result;
> + /* If we reached the end on one side only, lines don't match. */
> + return s1 == end1 && s2 == end2;
> }
>
> static void add_line_info(struct image *img, const char *bol, size_t len, unsigned flag)
^ permalink raw reply [relevance 6%]
* Re: [PATCH v2 Outreachy] mru: use double-linked list from list.h
2017-11-08 1:44 0% ` Junio C Hamano
@ 2017-11-08 4:22 0% ` Jeff King
0 siblings, 0 replies; 114+ results
From: Jeff King @ 2017-11-08 4:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Olga Telezhnaya, git
On Wed, Nov 08, 2017 at 10:44:46AM +0900, Junio C Hamano wrote:
> > We could also consider it a #leftoverbits that perhaps some other
> > Outreachy candidate would pick up[1].
> >
> > In the meantime, Junio, I think we'd want to queue this with the intent
> > to graduate it to "pu" or possibly "next", but not "master". Then if
> > somebody (Olga or another applicant) produces the endgame patch, we can
> > queue it on top and move it further. And if nobody does, I can pick it
> > after the application period is over.
>
> So... do we still want to keep this in 'next', or does somebody
> wants to do honors?
>
> I'd really prefer *not* to see you or me ending up finishing it up,
> but at the same time, I really hate seeing a halfway or 3/4 done
> topic hanging around in 'pu'.
We hung back on it to leave it as low-hanging fruit for other Outreachy
applicants. Perhaps Olga would like to pick it up now that the
application period is over.
Alternatively, it might be a nice task for the Bloomberg hackathon this
weekend. I'll add it to the list of topics there, too.
-Peff
^ permalink raw reply [relevance 0%]
* Re: [PATCH] completion: add missing completions for log, diff, show
2017-11-08 2:33 5% ` Junio C Hamano
@ 2017-11-08 3:30 0% ` Max Rothman
0 siblings, 0 replies; 114+ results
From: Max Rothman @ 2017-11-08 3:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
>> Teach git-log tab completion about the --no-* options for ease of use
>> at the command line.
>>
>> Similarly, teach git-show tab completion about the --no-abbrev-commit,
>> --expand-tabs, and --no-expand-tabs options.
>>
>> Also, teach git-diff (and all commands that use its options) tab
>> completion about the --textconv and --indent-heuristic families of
>> options. --indent-heuristic is no longer experimental, so there's no
>> reason it should be left out of tab completion any more, and textconv
>> seems to have simply been missed.
>
> A couple of things that I found questionable in the above
> descriptions are:
>
> * We do not write git subcommand names like git-foo these days, as
> nobody type them like so.
My bad, that's still how they're named when using manpages, so that's
what my muscle memory did.
>
> * The patch is not teaching git-foo about completing its options.
> It teaches the bash completion about options for git subcommands
> it did not know about.
>
> So perhaps
>
> The bash completion script knows some options to the "git
> log" only in the positive form (e.g. "--abbrev-commit") but
> not in their negated form (e.g. "--no-abbrev-commit"). Add
> them.
>
> and similar?
How about this:
The bash completion script knows some options to "git log" and
"git show" only in the positive form, (e.g. "--abbrev-commit"), but not
in their negative form (e.g. "--no-abbrev-commit"). Adds them.
Also, the bash completion script is missing some other options to
"git diff", and "git show" (and thus, all other commands that take
"git diff"'s options). Adds them. Of note, since "--indent-heuristic" is
no longer experimental, adds that too.
>
>> ---
>
> Missed sign-off?
Whoops, there doesn't seem to be a way to add that separately from the
commit message in the submitGit interface. I'll try adding it, but
gmail might turn all the tabs into spaces, so if it does, I'll try to
figure out how to resubmit.
>
>> @@ -1759,16 +1765,19 @@ _git_log ()
>> ...
>> - --decorate --decorate=
>> + --decorate --decorate= --no-decorate
>> ...
>> @@ -2816,8 +2825,9 @@ _git_show ()
>> return
>> ;;
>> --*)
>> - __gitcomp "--pretty= --format= --abbrev-commit --oneline
>> - --show-signature
>> + __gitcomp "--pretty= --format= --abbrev-commit --no-abbrev-commit
>> + --oneline --show-signature --patch
>> + --expand-tabs --expand-tabs= --no-expand-tabs
>> $__git_diff_common_options
>> "
>> return
>
> It's a bit sad that the completion support does not know that "git
> show" belongs to the "git log" family of commands. A consequence of
> this is that "git show --no-decorate" is perfectly acceptable but
> needs to be taught separately to _git_show if we wanted to.
>
> Perhaps some selected options _git_log understands may need to be
> split $__git_log_ui_common_options [*1*], like we do for "git diff"
> family with $__git_diff_common_options, and shared between _git_log
> and _git_show.
>
> I am mentioning this primarily as #leftoverbits and I do not want to
> see such a change mixed into this patch, as it is totally outside
> the scope of it. It is (if you are inclined to do so) OK to make
> this into two patch series, with 1/2 doing such a refactoring
> without changing any externally visible functionality (i.e. just
> move the ones _git_show knows about to $__git_log_ui_common_options,
> and have _git_show and _git_log use it), and 2/2 adding more options
> to that list to achieve what you wanted to do with this patch, though.
I think I'll stick with this patch for now (it's my first!), but I
might come around and do refactoring in a second pass.
Thanks,
Max
^ permalink raw reply [relevance 0%]
* Re: [PATCH] completion: add missing completions for log, diff, show
@ 2017-11-08 2:33 5% ` Junio C Hamano
2017-11-08 3:30 0% ` Max Rothman
0 siblings, 1 reply; 114+ results
From: Junio C Hamano @ 2017-11-08 2:33 UTC (permalink / raw)
To: Max Rothman; +Cc: git
Max Rothman <max.r.rothman@gmail.com> writes:
> From: Max Rothman <max-rothman@pluralsight.com>
Thanks.
>
> Teach git-log tab completion about the --no-* options for ease of use
> at the command line.
>
> Similarly, teach git-show tab completion about the --no-abbrev-commit,
> --expand-tabs, and --no-expand-tabs options.
>
> Also, teach git-diff (and all commands that use its options) tab
> completion about the --textconv and --indent-heuristic families of
> options. --indent-heuristic is no longer experimental, so there's no
> reason it should be left out of tab completion any more, and textconv
> seems to have simply been missed.
A couple of things that I found questionable in the above
descriptions are:
* We do not write git subcommand names like git-foo these days, as
nobody type them like so.
* The patch is not teaching git-foo about completing its options.
It teaches the bash completion about options for git subcommands
it did not know about.
So perhaps
The bash completion script knows some options to the "git
log" only in the positive form (e.g. "--abbrev-commit") but
not in their negated form (e.g. "--no-abbrev-commit"). Add
them.
and similar?
> ---
Missed sign-off?
> @@ -1759,16 +1765,19 @@ _git_log ()
> ...
> - --decorate --decorate=
> + --decorate --decorate= --no-decorate
> ...
> @@ -2816,8 +2825,9 @@ _git_show ()
> return
> ;;
> --*)
> - __gitcomp "--pretty= --format= --abbrev-commit --oneline
> - --show-signature
> + __gitcomp "--pretty= --format= --abbrev-commit --no-abbrev-commit
> + --oneline --show-signature --patch
> + --expand-tabs --expand-tabs= --no-expand-tabs
> $__git_diff_common_options
> "
> return
It's a bit sad that the completion support does not know that "git
show" belongs to the "git log" family of commands. A consequence of
this is that "git show --no-decorate" is perfectly acceptable but
needs to be taught separately to _git_show if we wanted to.
Perhaps some selected options _git_log understands may need to be
split $__git_log_ui_common_options [*1*], like we do for "git diff"
family with $__git_diff_common_options, and shared between _git_log
and _git_show.
I am mentioning this primarily as #leftoverbits and I do not want to
see such a change mixed into this patch, as it is totally outside
the scope of it. It is (if you are inclined to do so) OK to make
this into two patch series, with 1/2 doing such a refactoring
without changing any externally visible functionality (i.e. just
move the ones _git_show knows about to $__git_log_ui_common_options,
and have _git_show and _git_log use it), and 2/2 adding more options
to that list to achieve what you wanted to do with this patch, though.
Thanks.
[Footnote]
*1* $__git_log_common_options is taken and it is about options
common to "log/shortlog/gitk" but contains some that are not
relevant to "git show", and that is why I am suggesting a
separate and new variable.
^ permalink raw reply [relevance 5%]
* Re: [PATCH v2 Outreachy] mru: use double-linked list from list.h
2017-10-02 8:20 6% ` Jeff King
@ 2017-11-08 1:44 0% ` Junio C Hamano
2017-11-08 4:22 0% ` Jeff King
0 siblings, 1 reply; 114+ results
From: Junio C Hamano @ 2017-11-08 1:44 UTC (permalink / raw)
To: Jeff King; +Cc: Olga Telezhnaya, git
Jeff King <peff@peff.net> writes:
> I do think there are a few ugly bits in the result (like that
> initializer for packed_git_mru :) ), so I'd prefer not to merge this
> down until we do that final step.
>
> So the big question is: who wants to do it?
>
> I think you've done a good job here, and this would count for your
> Outreachy application's contribution. But if you'd like to do that next
> step, you are welcome to.
>
> We could also consider it a #leftoverbits that perhaps some other
> Outreachy candidate would pick up[1].
>
> In the meantime, Junio, I think we'd want to queue this with the intent
> to graduate it to "pu" or possibly "next", but not "master". Then if
> somebody (Olga or another applicant) produces the endgame patch, we can
> queue it on top and move it further. And if nobody does, I can pick it
> after the application period is over.
So... do we still want to keep this in 'next', or does somebody
wants to do honors?
I'd really prefer *not* to see you or me ending up finishing it up,
but at the same time, I really hate seeing a halfway or 3/4 done
topic hanging around in 'pu'.
> [1] For those who find this mail through the archive, there's more
> discussion in this thread:
>
> https://public-inbox.org/git/CAL21BmnvJSaN+Tnw7Hdc5P5biAnM5dfWR7gX5FrAG1r_D8th=A@mail.gmail.com/
^ permalink raw reply [relevance 0%]
* Re: [PATCH] wt-status: actually ignore submodules when requested
2017-11-06 22:44 5% ` Stefan Beller
@ 2017-11-06 22:52 0% ` Brandon Williams
0 siblings, 0 replies; 114+ results
From: Brandon Williams @ 2017-11-06 22:52 UTC (permalink / raw)
To: Stefan Beller; +Cc: git, Orgad Shaneh, Johannes Schindelin
On 11/06, Stefan Beller wrote:
> On Mon, Nov 6, 2017 at 2:08 PM, Brandon Williams <bmwill@google.com> wrote:
> > Since ff6f1f564 (submodule-config: lazy-load a repository's .gitmodules
> > file, 2017-08-03) rebase interactive fails if there are any submodules
> > with unstaged changes which have been configured with a value for
> > 'submodule.<name>.ignore' in the repository's config.
> >
> > This is due to how configured values of 'submodule.<name>.ignore' are
> > handled in addition to a change in how the submodule config is loaded.
> > When the diff machinery hits a submodule (gitlink as well as a
> > corresponding entry in the submodule subsystem) it will read the value
> > of 'submodule.<name>.ignore' stored in the repository's config and if
> > the config is present it will clear the 'IGNORE_SUBMODULES' (which is
> > the flag explicitly requested by rebase interactive),
> > 'IGNORE_UNTRACKED_IN_SUBMODULES', and 'IGNORE_DIRTY_SUBMODULES' diff
> > flags and then set one of them based on the configured value.
> >
> > Historically this wasn't a problem because the submodule subsystem
> > wasn't initialized because the .gitmodules file wasn't explicitly loaded
> > by the rebase interactive command. So when the diff machinery hit a
> > submodule it would skip over reading any configured values of
> > 'submodule.<name>.ignore'.
> >
> > In order to preserve the behavior of submodules being ignored by rebase
> > interactive, also set the 'OVERRIDE_SUBMODULE_CONFIG' diff flag when
> > submodules are requested to be ignored when checking for unstaged
> > changes.
> >
> > Reported-by: Orgad Shaneh <orgads@gmail.com>
> > Signed-off-by: Brandon Williams <bmwill@google.com>
> > ---
> > t/t3426-rebase-submodule.sh | 16 ++++++++++++++++
> > wt-status.c | 4 +++-
> > 2 files changed, 19 insertions(+), 1 deletion(-)
> >
> > diff --git a/t/t3426-rebase-submodule.sh b/t/t3426-rebase-submodule.sh
> > index ebf4f5e4b..760c872e2 100755
> > --- a/t/t3426-rebase-submodule.sh
> > +++ b/t/t3426-rebase-submodule.sh
> > @@ -40,4 +40,20 @@ git_rebase_interactive () {
> >
> > test_submodule_switch "git_rebase_interactive"
> >
> > +test_expect_success 'rebase interactive ignores modified submodules' '
> > + test_when_finished "rm -rf super sub" &&
> > + git init sub &&
> > + git -C sub commit --allow-empty -m "Initial commit" &&
> > + git init super &&
> > + git -C super submodule add ../sub &&
> > + git -C super config submodule.sub.ignore dirty &&
> > + > super/foo &&
> > + git -C super add foo &&
> > + git -C super commit -m "Initial commit" &&
> > + test_commit -C super a &&
> > + test_commit -C super b &&
> > + test_commit -C super/sub c &&
+ set_fake_editor &&
> > + git -C super rebase -i HEAD^^
>
> The previous test `set_fake_editor` already, though I am unsure
> about the current directory. It turns out that the setting of the fake
> editor is done via environment variable using absolute path to
> the generated `fake_editor.sh`, hence it works even when
> invoking a rebase in another directory/repo. Spooky.
>
> Also we do want to be able to skip previous tests,
> which this might be a problem for. Can we have a 'setup'
> that sets up the fake editor instead of repeating it here or
> hoping the previous tests has run? (Calling for a refactoring
> during a regression fix is bad taste, so maybe just take this
> patch as is and put it to the #leftoverbits ?)
Thanks for catching that. 'set_fake_editor' definitely needs to be set
(like what i did above in-line).
>
> > +'
> > +
> > test_done
> > diff --git a/wt-status.c b/wt-status.c
> > index 29bc64cc0..94e5ebaf8 100644
> > --- a/wt-status.c
> > +++ b/wt-status.c
> > @@ -2262,8 +2262,10 @@ int has_unstaged_changes(int ignore_submodules)
> > int result;
> >
> > init_revisions(&rev_info, NULL);
> > - if (ignore_submodules)
> > + if (ignore_submodules) {
> > DIFF_OPT_SET(&rev_info.diffopt, IGNORE_SUBMODULES);
> > + DIFF_OPT_SET(&rev_info.diffopt, OVERRIDE_SUBMODULE_CONFIG);
> > + }
>
> There are a couple of submodule related flags:
>
> #define DIFF_OPT_IGNORE_SUBMODULES (1 << 18)
> ...
> #define DIFF_OPT_DIRTY_SUBMODULES (1 << 24)
> #define DIFF_OPT_IGNORE_UNTRACKED_IN_SUBMODULES (1 << 25)
> #define DIFF_OPT_IGNORE_DIRTY_SUBMODULES (1 << 26)
> #define DIFF_OPT_OVERRIDE_SUBMODULE_CONFIG (1 << 27)
>
> We don't need to pay attention to 24,25,26 here, because
> DIRTY_SUBMODULES and IGN_* are only used to specify further
> interest, the generic INORE_SUBMODULES turns off any submodule
> handling. (so if we were to turn them on as well, it would still be correct,
> though it may have performance impact -- I shortly wondered if we'd rather
> want to have a mask covering all submodule related flags, specifically
> all flags invented in the future ;) )
>
> The patch looks good to me (i.e. I am convinced by review it fixes the
> regression), so maybe we can put the test refactor on top of it, which
> then doesn't need fast-tracking down to the maintenance track?
>
> Thanks,
> Stefan
--
Brandon Williams
^ permalink raw reply [relevance 0%]
* Re: [PATCH] wt-status: actually ignore submodules when requested
@ 2017-11-06 22:44 5% ` Stefan Beller
2017-11-06 22:52 0% ` Brandon Williams
0 siblings, 1 reply; 114+ results
From: Stefan Beller @ 2017-11-06 22:44 UTC (permalink / raw)
To: Brandon Williams; +Cc: git, Orgad Shaneh, Johannes Schindelin
On Mon, Nov 6, 2017 at 2:08 PM, Brandon Williams <bmwill@google.com> wrote:
> Since ff6f1f564 (submodule-config: lazy-load a repository's .gitmodules
> file, 2017-08-03) rebase interactive fails if there are any submodules
> with unstaged changes which have been configured with a value for
> 'submodule.<name>.ignore' in the repository's config.
>
> This is due to how configured values of 'submodule.<name>.ignore' are
> handled in addition to a change in how the submodule config is loaded.
> When the diff machinery hits a submodule (gitlink as well as a
> corresponding entry in the submodule subsystem) it will read the value
> of 'submodule.<name>.ignore' stored in the repository's config and if
> the config is present it will clear the 'IGNORE_SUBMODULES' (which is
> the flag explicitly requested by rebase interactive),
> 'IGNORE_UNTRACKED_IN_SUBMODULES', and 'IGNORE_DIRTY_SUBMODULES' diff
> flags and then set one of them based on the configured value.
>
> Historically this wasn't a problem because the submodule subsystem
> wasn't initialized because the .gitmodules file wasn't explicitly loaded
> by the rebase interactive command. So when the diff machinery hit a
> submodule it would skip over reading any configured values of
> 'submodule.<name>.ignore'.
>
> In order to preserve the behavior of submodules being ignored by rebase
> interactive, also set the 'OVERRIDE_SUBMODULE_CONFIG' diff flag when
> submodules are requested to be ignored when checking for unstaged
> changes.
>
> Reported-by: Orgad Shaneh <orgads@gmail.com>
> Signed-off-by: Brandon Williams <bmwill@google.com>
> ---
> t/t3426-rebase-submodule.sh | 16 ++++++++++++++++
> wt-status.c | 4 +++-
> 2 files changed, 19 insertions(+), 1 deletion(-)
>
> diff --git a/t/t3426-rebase-submodule.sh b/t/t3426-rebase-submodule.sh
> index ebf4f5e4b..760c872e2 100755
> --- a/t/t3426-rebase-submodule.sh
> +++ b/t/t3426-rebase-submodule.sh
> @@ -40,4 +40,20 @@ git_rebase_interactive () {
>
> test_submodule_switch "git_rebase_interactive"
>
> +test_expect_success 'rebase interactive ignores modified submodules' '
> + test_when_finished "rm -rf super sub" &&
> + git init sub &&
> + git -C sub commit --allow-empty -m "Initial commit" &&
> + git init super &&
> + git -C super submodule add ../sub &&
> + git -C super config submodule.sub.ignore dirty &&
> + > super/foo &&
> + git -C super add foo &&
> + git -C super commit -m "Initial commit" &&
> + test_commit -C super a &&
> + test_commit -C super b &&
> + test_commit -C super/sub c &&
> + git -C super rebase -i HEAD^^
The previous test `set_fake_editor` already, though I am unsure
about the current directory. It turns out that the setting of the fake
editor is done via environment variable using absolute path to
the generated `fake_editor.sh`, hence it works even when
invoking a rebase in another directory/repo. Spooky.
Also we do want to be able to skip previous tests,
which this might be a problem for. Can we have a 'setup'
that sets up the fake editor instead of repeating it here or
hoping the previous tests has run? (Calling for a refactoring
during a regression fix is bad taste, so maybe just take this
patch as is and put it to the #leftoverbits ?)
> +'
> +
> test_done
> diff --git a/wt-status.c b/wt-status.c
> index 29bc64cc0..94e5ebaf8 100644
> --- a/wt-status.c
> +++ b/wt-status.c
> @@ -2262,8 +2262,10 @@ int has_unstaged_changes(int ignore_submodules)
> int result;
>
> init_revisions(&rev_info, NULL);
> - if (ignore_submodules)
> + if (ignore_submodules) {
> DIFF_OPT_SET(&rev_info.diffopt, IGNORE_SUBMODULES);
> + DIFF_OPT_SET(&rev_info.diffopt, OVERRIDE_SUBMODULE_CONFIG);
> + }
There are a couple of submodule related flags:
#define DIFF_OPT_IGNORE_SUBMODULES (1 << 18)
...
#define DIFF_OPT_DIRTY_SUBMODULES (1 << 24)
#define DIFF_OPT_IGNORE_UNTRACKED_IN_SUBMODULES (1 << 25)
#define DIFF_OPT_IGNORE_DIRTY_SUBMODULES (1 << 26)
#define DIFF_OPT_OVERRIDE_SUBMODULE_CONFIG (1 << 27)
We don't need to pay attention to 24,25,26 here, because
DIRTY_SUBMODULES and IGN_* are only used to specify further
interest, the generic INORE_SUBMODULES turns off any submodule
handling. (so if we were to turn them on as well, it would still be correct,
though it may have performance impact -- I shortly wondered if we'd rather
want to have a mask covering all submodule related flags, specifically
all flags invented in the future ;) )
The patch looks good to me (i.e. I am convinced by review it fixes the
regression), so maybe we can put the test refactor on top of it, which
then doesn't need fast-tracking down to the maintenance track?
Thanks,
Stefan
^ permalink raw reply [relevance 5%]
* Re: Git Open Source Weekend London 11th/12th November
2017-11-04 9:28 6% ` Jeff King
@ 2017-11-04 17:15 0% ` Philip Oakley
0 siblings, 0 replies; 114+ results
From: Philip Oakley @ 2017-11-04 17:15 UTC (permalink / raw)
To: Jeff King, Thomas Gummerer; +Cc: Git Mailing List, hkleynhans
From: "Jeff King" <peff@peff.net>
> On Wed, Nov 01, 2017 at 04:36:24PM +0000, Thomas Gummerer wrote:
>
>> Normally attendees work in small groups on a specific task to
>> prevent anyone from getting stuck. Per usual, Bloomberg will
>> provide the venue, mentors, snacks and drinks. Bring your
>> enthusiasm (and your laptop!) and come share in the fun! The
>> event is also open to everyone, so feel free to pass on the
>> invite!
>
> I think it will help if the experienced members of the community (both
> those who will be at the event and not) can come up with some possible
> topics to work on (though of course I'd be glad for participants to come
> with their own itch to scratch).
>
> We've started using the #leftoverbits tag to allow searching in the
> archive:
>
> https://public-inbox.org/git/?q=leftoverbits
>
> Some of those have since been completed, but others are left open.
> There's not really a master list, but it's a potential source for
> digging for gold (well, if you want to call leftover bugs gold :) ).
>
> I started a list over the summer of larger items that people might want
> to pick up. Here it is in no particular order:
>
> - the pager.<cmd> config is mis-designed, because our config keys
> cannot represent all possible command names (e.g., case folding and
> illegal characters). This should be pager.<cmd>.enable or similar.
> Some discussion in (this message and the surrounding thread):
>
>
> https://public-inbox.org/git/20170711101942.h2uwxtgzvgguzivu@sigill.intra.peff.net/
>
> But I think you could find more by searching the archive.
>
> - ditto for alias.* config, which has the same syntax problems.
>
> - auto-gc is sometimes over-anxious to run if you have a lot of
> unreachable loose objects. We should pack unreachables into a single
> pack. That solves the --auto problem, and is also way more efficient.
> The catch is expiration. Some discussion here (and especially
> down-thread):
>
>
> https://public-inbox.org/git/20170711101942.h2uwxtgzvgguzivu@sigill.intra.peff.net/
>
> - git-config's "--get-color" is unlike all the other types in that it
> takes a "default" value if the config key isn't set. This makes it
> annoyingly
> inconsistent, but there's also no way to ask Git to interpret other
> values (e.g., you might want it to expand "--path" or an "--int"). It
> would be nice to have a general "--default" option so you could do:
>
> # same as git config --get-color color.diff.old red
> git config --default red --color color.diff.old
>
> or
>
> # not currently possible to ask git to interpret "10k"
> git config --default 10k --int some.integer.key
>
> - git's internal config can parse expiration dates (see
> parse_expiry_date()), but you can't do so from git-config. It should
> probably have a type for "--expiry-date" (which would of course be
> more useful with the --default option above).
>
> - there's no efficient way to ask git-config for several keys with a
> specific type (or even multiple different types). You can use
> "--list" to get their strings, but you can't get any interpretation
> (like colors, integers, etc). Invoking git-config many times can have
> a noticeable speed impact for a script. There should probably be a
> "--stdin" mode (or maybe "--get-stdin" if we would one day want to
> have a "--set-stdin") that takes a list of keys, optional types, and
> optional defaults (that "--default" again!) and outputs them to
> stdout.
>
>
> Those were just sitting on my ideas list. I'm happy to go into more
> detail if anybody's interested in discussing any of them. Some of them
> may be half-baked.
>
> And of course I'd be happy if people wanted to contribute more items to
> the list.
>
A few I've seen recently are:
* The provison of a `git resolve -X <ours|theirs> -- <pathspec>` command to
simplify the manual resolution of remaining conflicts.
https://public-inbox.org/git/8737615iu5.fsf@javad.com/ Sergey Organov: How
to re-merge paths differently?
* (Git for Windows/HFS): Detect directory capitalisation changes when
switching branches, and rename them correctly on case preserving, case
insensitive file systems. Optimisation: If the underlying tree is identical
then do not update the modified dates.
https://github.com/git-for-windows/git/issues/1333 Chuck Lu: Folder name
should be case sensitive when switch branches.
* (Git for Windows/HFS) (long standing):
detect branch name capitalisation issues
- may need a struct to carry both the filename and pathname down the
different parts of the code base so that the FS name of the requested
ref/heads/ can be checked and warned.
e.g. https://github.com/git-for-windows/git/issues/852 "`git checkout head`
inconsistent behavior"
- ('head' finds 'HEAD', but also 'branch' finds 'Branch');
https://github.com/git-for-windows/git/issues/852#issuecomment-239675187 ->
"rambling notes" for partial analysis.
https://github.com/git-for-windows/git/issues/752 "git checkout creating
tracking branch using case-insensitive match?"
- Is this part of the same problem?
* Documentation:
There's always the newby role at the hackathon of collating
all the "what does this command do/mean?" questions that could be resolved
by simple updates, or capturing locally written explanations to improve the
manual pages. (easy patch practice)
Perhaps see how `git rerere` could be better explained and integrated onto
the other man pages so that more folk naturally know of it and use it. (see
also the `git resolve` question above)
Also for case sensitivity documentation
https://github.com/git-for-windows/git/issues/908#issuecomment-325116189
--
Philip
^ permalink raw reply [relevance 0%]
* Re: Git Open Source Weekend London 11th/12th November
@ 2017-11-04 9:28 6% ` Jeff King
2017-11-04 17:15 0% ` Philip Oakley
0 siblings, 1 reply; 114+ results
From: Jeff King @ 2017-11-04 9:28 UTC (permalink / raw)
To: Thomas Gummerer; +Cc: Git Mailing List, hkleynhans
On Wed, Nov 01, 2017 at 04:36:24PM +0000, Thomas Gummerer wrote:
> Normally attendees work in small groups on a specific task to
> prevent anyone from getting stuck. Per usual, Bloomberg will
> provide the venue, mentors, snacks and drinks. Bring your
> enthusiasm (and your laptop!) and come share in the fun! The
> event is also open to everyone, so feel free to pass on the
> invite!
I think it will help if the experienced members of the community (both
those who will be at the event and not) can come up with some possible
topics to work on (though of course I'd be glad for participants to come
with their own itch to scratch).
We've started using the #leftoverbits tag to allow searching in the
archive:
https://public-inbox.org/git/?q=leftoverbits
Some of those have since been completed, but others are left open.
There's not really a master list, but it's a potential source for
digging for gold (well, if you want to call leftover bugs gold :) ).
I started a list over the summer of larger items that people might want
to pick up. Here it is in no particular order:
- the pager.<cmd> config is mis-designed, because our config keys
cannot represent all possible command names (e.g., case folding and
illegal characters). This should be pager.<cmd>.enable or similar.
Some discussion in (this message and the surrounding thread):
https://public-inbox.org/git/20170711101942.h2uwxtgzvgguzivu@sigill.intra.peff.net/
But I think you could find more by searching the archive.
- ditto for alias.* config, which has the same syntax problems.
- auto-gc is sometimes over-anxious to run if you have a lot of
unreachable loose objects. We should pack unreachables into a single
pack. That solves the --auto problem, and is also way more efficient.
The catch is expiration. Some discussion here (and especially
down-thread):
https://public-inbox.org/git/20170711101942.h2uwxtgzvgguzivu@sigill.intra.peff.net/
- git-config's "--get-color" is unlike all the other types in that it
takes a "default" value if the config key isn't set. This makes it annoyingly
inconsistent, but there's also no way to ask Git to interpret other
values (e.g., you might want it to expand "--path" or an "--int"). It
would be nice to have a general "--default" option so you could do:
# same as git config --get-color color.diff.old red
git config --default red --color color.diff.old
or
# not currently possible to ask git to interpret "10k"
git config --default 10k --int some.integer.key
- git's internal config can parse expiration dates (see
parse_expiry_date()), but you can't do so from git-config. It should
probably have a type for "--expiry-date" (which would of course be
more useful with the --default option above).
- there's no efficient way to ask git-config for several keys with a
specific type (or even multiple different types). You can use
"--list" to get their strings, but you can't get any interpretation
(like colors, integers, etc). Invoking git-config many times can have
a noticeable speed impact for a script. There should probably be a
"--stdin" mode (or maybe "--get-stdin" if we would one day want to
have a "--set-stdin") that takes a list of keys, optional types, and
optional defaults (that "--default" again!) and outputs them to
stdout.
Those were just sitting on my ideas list. I'm happy to go into more
detail if anybody's interested in discussing any of them. Some of them
may be half-baked.
And of course I'd be happy if people wanted to contribute more items to
the list.
-Peff
^ permalink raw reply [relevance 6%]
* Re: [PATCHv2 6/7] builtin/describe.c: describe a blob
@ 2017-11-03 15:02 6% ` Junio C Hamano
0 siblings, 0 replies; 114+ results
From: Junio C Hamano @ 2017-11-03 15:02 UTC (permalink / raw)
To: git; +Cc: Johannes Schindelin, Stefan Beller, Kevin Daudt, Jacob Keller
Jacob Keller <jacob.keller@gmail.com> writes:
> On Thu, Nov 2, 2017 at 10:18 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> ...
>> It is easy to imagine that we can restrict "git log" traversal with
>> a "--blobchange=<blob>" option instead of (or in addition to) the
>> limitation <pathspec> gives us. Instead of treating a commit whose
>> diff against its parent commit has any filepair that is different
>> within <pathspec> as "!TREESAME", we can treat a commit whose diff
>> against its parent commit has a filepair that has the <blob> on
>> either side of the filepair as "!TREESAME" (in other words, we
>> ignore a transition that is not about introducing or forgetting the
>> <blob> we are looking for as an "interesting change"). That would
>> give you a commit history graph in which only (and all) such commits
>> that either adds or removes the <blob> in it.
>>
>> Hmm?
>
> This seems quite useful in the context of figuring out how a file got
> to such a state. This is useful to me, since if I know the state of a
> file (ie: it's exact contents) I can determine the blob name, and then
> use that to lookup where it was introduced.
This is probably a bit harder than an average #leftoverbits, but if
somebody wants to get their hands dirty, it should be reasonably
straightforward. The needed changes would roughly go like so:
- Add "struct oid *blob_change;" to diff_options, initialized to
NULL.
- Teach diff_opt_parse() a new option "--blobchange=<blob>".
Allocate a struct oid when you parse this option and point at it
with the blob_change field above.
- Write diffcore-blobchange.c, modeled after diffcore-pickaxe.c,
but this should be a lot simpler (as there is no need for an
equivalent for "pickaxe-all" option). It would
- prepare an empty diff_queue_struct "outq";
- iterate over the given diff_queue "q", and
- a filepair p whose p->one is blob_change and p->two is not,
(or the other way around) is added to outq with diff_q()
- a filepair whose p->one/p->two do not involve blob_change
is freed with diff_free_filepair().
- replace "q" with "outq".
- Add a call to diffcore_blobchange() early in diffcore_std(),
probably immediately after skip-stat-unmatch, when blob_change
field is not NULL.
- Arrange that blob_change is propagated to revs->pruning in
setup_revisions().
^ permalink raw reply [relevance 6%]
* Re: [PATCH 1/2] xdiff-interface: export comparing and hashing strings
2017-10-27 7:12 5% ` Junio C Hamano
@ 2017-10-27 17:15 6% ` Stefan Beller
0 siblings, 0 replies; 114+ results
From: Stefan Beller @ 2017-10-27 17:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: René Scharfe, git, Jonathan Nieder, Jeff King
On Fri, Oct 27, 2017 at 12:12 AM, Junio C Hamano <gitster@pobox.com> wrote:
> René Scharfe <l.s.r@web.de> writes:
>
>> Am 25.10.2017 um 20:49 schrieb Stefan Beller:
>>> +/*
>>> + * Compare the strings l1 with l2 which are of size s1 and s2 respectively.
>>> + * Returns 1 if the strings are deemed equal, 0 otherwise.
>>> + * The `flags` given as XDF_WHITESPACE_FLAGS determine how white spaces
>>> + * are treated for the comparision.
>>> + */
>>> +extern int xdiff_compare_lines(const char *l1, long s1,
>>> + const char *l2, long s2, long flags);
>>
>> With the added comment it's OK here.
>>
>> Still, I find the tendency in libxdiff to use the shortest possible
>> variable names to be hard on the eyes. That math-like notation may have
>> its place in that external library, but I think we should be careful
>> lest it spreads.
>
> Yeah, I tend to agree. The xdiff-interface is at the (surprise!)
> interface layer, so we could make it follow the style of either one,
> but we seem to have picked up the convention of the lower layer,
> so...
>
> By the way, I was looking at the code around this area while
> reviewing the cr-at-eol thing, and noticed a couple of things:
>
>
> * combine-diff.c special cases only IGNORE_WHITESPACE and
> IGNORE_WHITESPACE_CHANGE but no other IGNORE_WHITESPACE things; I
> have a suspicion that this is not because IGNORE_WHITESPACE_AT_EOL
> does not have to special cased by the codepath, but only because
> the combine-diff.c refactoring predates the introduction of
> ws-at-eol thing?
I wonder how much overlap between the IGNORE_WHITESPACE_AT_EOL
and CRLF-AT-EOL is (maybe these can be combined, as per the root of
this discussion)
> The machinery uses its own match_string_spaces() helper; it may
> make sense to use the same xdiff_compare_lines() in its callers
> and get rid of this helper function.
Speaking of xdiff_compare_lines, it serves the special purpose of the
move detection as well as its internal use cases, but we may need to
change its interface/implementation in the future, to align it with strcmp,
currently the compare function only returns equality, not an order.
> * diff_setup_done() sets DIFF_FROM_CONTENTS when any of the
> IGNORE_WHITESPACE bits is true, to allow "git diff -q
> --ignore-something" would do the right thing. We do not however
> give a similar special case to XDF_IGNORE_BLANK_LINES.
>
> $ echo >>Makefile && git diff $option --ignore-blank-lines Makefile
>
> exits with 1 when option=--exit-code and it exits with 0 when
> option=-q
>
>
> For now I'll leve these as #leftoverbits, but I may come back to the
> latter soonish. I won't come back to the former until Stefan's
> refactor hits 'master', though.
which is presumably after the 2.15 release.
To tack on the #leftoverbits: The --color-moved detection doesn't
pay attention to XDF_IGNORE_BLANK_LINES (which is tricky as
it is on the per-line layer. If we want to ignore spurious blank lines,
we'd have to check for this flag in diff.c in mark_color_as_moved(..)
in the block
/* Check any potential block runs, advance each or nullify */
Thanks,
Stefan
^ permalink raw reply [relevance 6%]
* Re: [PATCH 1/2] xdiff-interface: export comparing and hashing strings
@ 2017-10-27 7:12 5% ` Junio C Hamano
2017-10-27 17:15 6% ` Stefan Beller
0 siblings, 1 reply; 114+ results
From: Junio C Hamano @ 2017-10-27 7:12 UTC (permalink / raw)
To: Stefan Beller, René Scharfe; +Cc: git, jrnieder, peff
René Scharfe <l.s.r@web.de> writes:
> Am 25.10.2017 um 20:49 schrieb Stefan Beller:
>> +/*
>> + * Compare the strings l1 with l2 which are of size s1 and s2 respectively.
>> + * Returns 1 if the strings are deemed equal, 0 otherwise.
>> + * The `flags` given as XDF_WHITESPACE_FLAGS determine how white spaces
>> + * are treated for the comparision.
>> + */
>> +extern int xdiff_compare_lines(const char *l1, long s1,
>> + const char *l2, long s2, long flags);
>
> With the added comment it's OK here.
>
> Still, I find the tendency in libxdiff to use the shortest possible
> variable names to be hard on the eyes. That math-like notation may have
> its place in that external library, but I think we should be careful
> lest it spreads.
Yeah, I tend to agree. The xdiff-interface is at the (surprise!)
interface layer, so we could make it follow the style of either one,
but we seem to have picked up the convention of the lower layer,
so...
By the way, I was looking at the code around this area while
reviewing the cr-at-eol thing, and noticed a couple of things:
* combine-diff.c special cases only IGNORE_WHITESPACE and
IGNORE_WHITESPACE_CHANGE but no other IGNORE_WHITESPACE things; I
have a suspicion that this is not because IGNORE_WHITESPACE_AT_EOL
does not have to special cased by the codepath, but only because
the combine-diff.c refactoring predates the introduction of
ws-at-eol thing?
The machinery uses its own match_string_spaces() helper; it may
make sense to use the same xdiff_compare_lines() in its callers
and get rid of this helper function.
* diff_setup_done() sets DIFF_FROM_CONTENTS when any of the
IGNORE_WHITESPACE bits is true, to allow "git diff -q
--ignore-something" would do the right thing. We do not however
give a similar special case to XDF_IGNORE_BLANK_LINES.
$ echo >>Makefile && git diff $option --ignore-blank-lines Makefile
exits with 1 when option=--exit-code and it exits with 0 when
option=-q
For now I'll leve these as #leftoverbits, but I may come back to the
latter soonish. I won't come back to the former until Stefan's
refactor hits 'master', though.
^ permalink raw reply [relevance 5%]
* Re: Consequences of CRLF in index?
2017-10-25 4:53 4% ` Junio C Hamano
@ 2017-10-25 16:44 0% ` Stefan Beller
0 siblings, 0 replies; 114+ results
From: Stefan Beller @ 2017-10-25 16:44 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jonathan Nieder, Lars Schneider, git, Torsten Bögershausen,
Jeff King, Johannes Schindelin
On Tue, Oct 24, 2017 at 9:53 PM, Junio C Hamano <gitster@pobox.com> wrote:
>
> Here is a lunch-time hack to add that option. As you can see from
> the lack of docs, tests and a proper log message, I haven't played
> with it long enough to know how buggy it is, though. I am not all
> that interested in polishing it to completion myself and prefer to
> leave it as #leftoverbits ;-)
Ok, nevertheless a review pointing out a couple things would be
useful for those who pick it up later, I assume.
> Also I didn't bother teaching this to Stefan's color-moved thing, as
> the line comparator it uses will hopefully be unified with the one I
> am touching in xdiff/ with this patch.
which will be rerolled shortly fixing just the parameter names as Eric
mentioned.
> diff.c | 5 ++++-
> merge-recursive.c | 2 ++
> xdiff/xdiff.h | 3 ++-
> xdiff/xutils.c | 34 ++++++++++++++++++++++++++++++++--
> 4 files changed, 40 insertions(+), 4 deletions(-)
>
> diff --git a/diff.c b/diff.c
> index 6fd288420b..eeca0fd3b8 100644
> --- a/diff.c
> +++ b/diff.c
> @@ -4202,7 +4202,8 @@ void diff_setup_done(struct diff_options *options)
>
> if (DIFF_XDL_TST(options, IGNORE_WHITESPACE) ||
> DIFF_XDL_TST(options, IGNORE_WHITESPACE_CHANGE) ||
> - DIFF_XDL_TST(options, IGNORE_WHITESPACE_AT_EOL))
> + DIFF_XDL_TST(options, IGNORE_WHITESPACE_AT_EOL) ||
> + DIFF_XDL_TST(options, IGNORE_CR_AT_EOL))
This highlights another part of the flag macros, that could be made nicer.
All these flags combined are XDF_WHITESPACE_FLAGS, so this
if could be written without the macros as
if (options->xdl_ops & XDF_WHITESPACE_FLAGS)
which we might want to hide in a macro
DIFF_XDL_MASK_TST(options, mask)
or such?
> #define XDF_IGNORE_WHITESPACE_AT_EOL (1 << 4)
> -#define XDF_WHITESPACE_FLAGS (XDF_IGNORE_WHITESPACE | XDF_IGNORE_WHITESPACE_CHANGE | XDF_IGNORE_WHITESPACE_AT_EOL)
> +#define XDF_IGNORE_CR_AT_EOL (1 << 5)
> +#define XDF_WHITESPACE_FLAGS (XDF_IGNORE_WHITESPACE | XDF_IGNORE_WHITESPACE_CHANGE | XDF_IGNORE_WHITESPACE_AT_EOL | XDF_IGNORE_CR_AT_EOL)
>
> #define XDF_PATIENCE_DIFF (1 << 5)
(1<<5) is taken twice now. Currently there is only one
unused free bit (but that was used once upon a time);
so we have to think how we revamp the flag system to
support more than 32 bits.
See also the answers to
https://public-inbox.org/git/20171024000931.14814-1-sbeller@google.com/
as that started this discussion already.
> #define XDF_HISTOGRAM_DIFF (1 << 6)
> diff --git a/xdiff/xutils.c b/xdiff/xutils.c
> index 04d7b32e4e..8720e272b9 100644
> --- a/xdiff/xutils.c
> +++ b/xdiff/xutils.c
> @@ -156,6 +156,21 @@ int xdl_blankline(const char *line, long size, long flags)
> return (i == size);
> }
>
> +/*
> + * Have we eaten everything on the line, except for an optional
> + * CR at the very end?
> + */
> +static int ends_with_optional_cr(const char *l, long s, long i)
> +{
> + if (s && l[s-1] == '\n')
> + s--;
so first we cut off the '\n',
> + if (s == i)
> + return 1;
then we either have an ending without
> + if (s == i + 1 && l[i] == '\r')
> + return 1;
or with a '\r' before.
That seems correct after some thought; I might offer
another easier to understand (for me) solution,
which is
{
/* cut of ending LF */
if (s && l[s-1] == '\n')
s--;
/* do we only need to cut LF? */
if (i == s)
return 1;
/* cut of ending CR */
if (s && l[s-1] == '\r')
s--;
/* was this everything to cut? */
return i == s
}
Though this seems even more complicated
after having it written down.
> * Each flavor of ignoring needs different logic to skip whitespaces
> * while we have both sides to compare.
> @@ -204,6 +220,14 @@ int xdl_recmatch(const char *l1, long s1, const char *l2, long s2, long flags)
> i1++;
> i2++;
> }
> + } else if (flags & XDF_IGNORE_CR_AT_EOL) {
> + /* Find the first difference and see how the line ends */
> + while (i1 < s1 && i2 < s2 && l1[i1] == l2[i2]) {
> + i1++;
> + i2++;
> + }
> + return (ends_with_optional_cr(l1, s1, i1) &&
> + ends_with_optional_cr(l2, s2, i2));
> }
>
> /*
> @@ -230,9 +254,15 @@ static unsigned long xdl_hash_record_with_whitespace(char const **data,
> char const *top, long flags) {
> unsigned long ha = 5381;
> char const *ptr = *data;
> + int cr_at_eol_only = (flags & XDF_WHITESPACE_FLAGS) == XDF_IGNORE_CR_AT_EOL;
>
> for (; ptr < top && *ptr != '\n'; ptr++) {
> - if (XDL_ISSPACE(*ptr)) {
> + if (cr_at_eol_only) {
> + if (*ptr == '\r' &&
> + (top <= ptr + 1 || ptr[1] == '\n'))
> + continue;
> + }
> + else if (XDL_ISSPACE(*ptr)) {
> const char *ptr2 = ptr;
> int at_eol;
> while (ptr + 1 < top && XDL_ISSPACE(ptr[1])
>
>
^ permalink raw reply [relevance 0%]
* Re: Consequences of CRLF in index?
@ 2017-10-25 4:53 4% ` Junio C Hamano
2017-10-25 16:44 0% ` Stefan Beller
0 siblings, 1 reply; 114+ results
From: Junio C Hamano @ 2017-10-25 4:53 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Lars Schneider, git, Torsten Bögershausen, Jeff King,
Johannes Schindelin
Junio C Hamano <gitster@pobox.com> writes:
> Jonathan Nieder <jrnieder@gmail.com> writes:
>
>> I'd be interested to hear what happens when diff-ing across a line
>> ending fixup commit. Is this an area where Git needs some
>> improvement? "git merge" knows an -Xrenormalize option to deal with a
>> related problem --- it's possible that "git diff" needs to learn a
>> similar trick.
>
> My knee-jerk reaction is that (1) the end user definitely wants to
> see preimage and postimage lines are different in such a commit by
> default, one side has and the other side lacks ^M at the end., and
> (2) one of the "whitespace ignoring" options (namely, "ignore space
> at eol") may suffice, but if not, it should be easy to invent a new
> one "ignore CR at eol".
Here is a lunch-time hack to add that option. As you can see from
the lack of docs, tests and a proper log message, I haven't played
with it long enough to know how buggy it is, though. I am not all
that interested in polishing it to completion myself and prefer to
leave it as #leftoverbits ;-)
Also I didn't bother teaching this to Stefan's color-moved thing, as
the line comparator it uses will hopefully be unified with the one I
am touching in xdiff/ with this patch.
Have fun.
diff.c | 5 ++++-
merge-recursive.c | 2 ++
xdiff/xdiff.h | 3 ++-
xdiff/xutils.c | 34 ++++++++++++++++++++++++++++++++--
4 files changed, 40 insertions(+), 4 deletions(-)
diff --git a/diff.c b/diff.c
index 6fd288420b..eeca0fd3b8 100644
--- a/diff.c
+++ b/diff.c
@@ -4202,7 +4202,8 @@ void diff_setup_done(struct diff_options *options)
if (DIFF_XDL_TST(options, IGNORE_WHITESPACE) ||
DIFF_XDL_TST(options, IGNORE_WHITESPACE_CHANGE) ||
- DIFF_XDL_TST(options, IGNORE_WHITESPACE_AT_EOL))
+ DIFF_XDL_TST(options, IGNORE_WHITESPACE_AT_EOL) ||
+ DIFF_XDL_TST(options, IGNORE_CR_AT_EOL))
DIFF_OPT_SET(options, DIFF_FROM_CONTENTS);
else
DIFF_OPT_CLR(options, DIFF_FROM_CONTENTS);
@@ -4659,6 +4660,8 @@ int diff_opt_parse(struct diff_options *options,
DIFF_XDL_SET(options, IGNORE_WHITESPACE_CHANGE);
else if (!strcmp(arg, "--ignore-space-at-eol"))
DIFF_XDL_SET(options, IGNORE_WHITESPACE_AT_EOL);
+ else if (!strcmp(arg, "--ignore-cr-at-eol"))
+ DIFF_XDL_SET(options, IGNORE_CR_AT_EOL);
else if (!strcmp(arg, "--ignore-blank-lines"))
DIFF_XDL_SET(options, IGNORE_BLANK_LINES);
else if (!strcmp(arg, "--indent-heuristic"))
diff --git a/merge-recursive.c b/merge-recursive.c
index 1d3f8f0d22..4a49ec93b1 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -2251,6 +2251,8 @@ int parse_merge_opt(struct merge_options *o, const char *s)
DIFF_XDL_SET(o, IGNORE_WHITESPACE);
else if (!strcmp(s, "ignore-space-at-eol"))
DIFF_XDL_SET(o, IGNORE_WHITESPACE_AT_EOL);
+ else if (!strcmp(s, "ignore-cr-at-eol"))
+ DIFF_XDL_SET(o, IGNORE_CR_AT_EOL);
else if (!strcmp(s, "renormalize"))
o->renormalize = 1;
else if (!strcmp(s, "no-renormalize"))
diff --git a/xdiff/xdiff.h b/xdiff/xdiff.h
index b090ad8eac..ff16243da9 100644
--- a/xdiff/xdiff.h
+++ b/xdiff/xdiff.h
@@ -32,7 +32,8 @@ extern "C" {
#define XDF_IGNORE_WHITESPACE (1 << 2)
#define XDF_IGNORE_WHITESPACE_CHANGE (1 << 3)
#define XDF_IGNORE_WHITESPACE_AT_EOL (1 << 4)
-#define XDF_WHITESPACE_FLAGS (XDF_IGNORE_WHITESPACE | XDF_IGNORE_WHITESPACE_CHANGE | XDF_IGNORE_WHITESPACE_AT_EOL)
+#define XDF_IGNORE_CR_AT_EOL (1 << 5)
+#define XDF_WHITESPACE_FLAGS (XDF_IGNORE_WHITESPACE | XDF_IGNORE_WHITESPACE_CHANGE | XDF_IGNORE_WHITESPACE_AT_EOL | XDF_IGNORE_CR_AT_EOL)
#define XDF_PATIENCE_DIFF (1 << 5)
#define XDF_HISTOGRAM_DIFF (1 << 6)
diff --git a/xdiff/xutils.c b/xdiff/xutils.c
index 04d7b32e4e..8720e272b9 100644
--- a/xdiff/xutils.c
+++ b/xdiff/xutils.c
@@ -156,6 +156,21 @@ int xdl_blankline(const char *line, long size, long flags)
return (i == size);
}
+/*
+ * Have we eaten everything on the line, except for an optional
+ * CR at the very end?
+ */
+static int ends_with_optional_cr(const char *l, long s, long i)
+{
+ if (s && l[s-1] == '\n')
+ s--;
+ if (s == i)
+ return 1;
+ if (s == i + 1 && l[i] == '\r')
+ return 1;
+ return 0;
+}
+
int xdl_recmatch(const char *l1, long s1, const char *l2, long s2, long flags)
{
int i1, i2;
@@ -170,7 +185,8 @@ int xdl_recmatch(const char *l1, long s1, const char *l2, long s2, long flags)
/*
* -w matches everything that matches with -b, and -b in turn
- * matches everything that matches with --ignore-space-at-eol.
+ * matches everything that matches with --ignore-space-at-eol,
+ * which in turn matches everything that matches with --ignore-cr-at-eol.
*
* Each flavor of ignoring needs different logic to skip whitespaces
* while we have both sides to compare.
@@ -204,6 +220,14 @@ int xdl_recmatch(const char *l1, long s1, const char *l2, long s2, long flags)
i1++;
i2++;
}
+ } else if (flags & XDF_IGNORE_CR_AT_EOL) {
+ /* Find the first difference and see how the line ends */
+ while (i1 < s1 && i2 < s2 && l1[i1] == l2[i2]) {
+ i1++;
+ i2++;
+ }
+ return (ends_with_optional_cr(l1, s1, i1) &&
+ ends_with_optional_cr(l2, s2, i2));
}
/*
@@ -230,9 +254,15 @@ static unsigned long xdl_hash_record_with_whitespace(char const **data,
char const *top, long flags) {
unsigned long ha = 5381;
char const *ptr = *data;
+ int cr_at_eol_only = (flags & XDF_WHITESPACE_FLAGS) == XDF_IGNORE_CR_AT_EOL;
for (; ptr < top && *ptr != '\n'; ptr++) {
- if (XDL_ISSPACE(*ptr)) {
+ if (cr_at_eol_only) {
+ if (*ptr == '\r' &&
+ (top <= ptr + 1 || ptr[1] == '\n'))
+ continue;
+ }
+ else if (XDL_ISSPACE(*ptr)) {
const char *ptr2 = ptr;
int at_eol;
while (ptr + 1 < top && XDL_ISSPACE(ptr[1])
^ permalink raw reply related [relevance 4%]
* Re: [PATCH 2/2] fetch, push: keep separate lists of submodules and gitlinks
@ 2017-10-23 18:05 6% ` Stefan Beller
0 siblings, 0 replies; 114+ results
From: Stefan Beller @ 2017-10-23 18:05 UTC (permalink / raw)
To: Heiko Voigt
Cc: Junio C Hamano, Jens Lehmann, Brandon Williams,
git@vger.kernel.org, Jonathan Nieder
On Mon, Oct 23, 2017 at 7:12 AM, Heiko Voigt <hvoigt@hvoigt.net> wrote:
> On Thu, Oct 19, 2017 at 11:11:09AM -0700, Stefan Beller wrote:
>> Currently when fetching we collect the names of submodules to be fetched
>> in a list. As we also want to support fetching 'gitlinks, that happen to
>> have a repo checked out at the right place', we'll just pretend that these
>> are submodules. We do that by assuming their path is their name. This in
>> turn can yield collisions between the name-namespace and the
>> path-namespace. (See the previous test for a demonstration.)
>>
>> This patch rewrites the code such that we treat the 'real submodule' case
>> differently from the 'gitlink, but ok' case. This introduces a bit
>> of code duplication, but gets rid of the confusing mapping between names
>> and paths.
>>
>> The test is incomplete as the long term vision is not achieved yet.
>> (which would be fetching both the renamed submodule as well as
>> the gitlink thing, putting them in place via e.g. git-pull)
>>
>> Signed-off-by: Stefan Beller <sbeller@google.com>
>> ---
>>
>> Heiko,
>> Junio,
>>
>> I assumed the code would ease up a lot more, but now I am undecided if
>> I want to keep arguing as the code is not stopping to be ugly. :)
>
> So we are basically coming to the same conclusion? :) My previous
> fallback approach basically did the same but with the old architecture
> (without parallel fetch, ...) and was already ugly.
It depends on the conclusion you drew. ;)
Here is my conclusion:
* It would really be nice to have this fallback separated out.
* However for the current state the ugliness of such code trumps the
more maintainable, long term oriented thing with path/names not
clashing. I could not spend more time polishing these patches,
so I could not ask you to do it either
-> I think your patches are fine as is for inclusion
-> We may have #leftoverbits here to clear up the confusion around
path/names, as well as making the code more pleasant to read.
> With the fallback on submodule default names approach we can keep most
> of the old functionality and keep the code that handles that minimal.
>
> Since there is only a small (IMO quite unlikely) cornercase that could
> break peoples expectations I would like to have a look whether anyone
> even notices the behavioral change on next or master. If there are
> complaints we can still extend and add the two lists.
That sounds good to me.
>
>> The idea is to treat submodule and gitlinks separately, with submodules
>> supporting renames, and gitlinks as a historic artefact.
>>
>> Sorry for the noise about code ugliness.
>
> Why sorry? For me it is actually interesting to see you basically coming
> to the same conclusions.
I thought I might come off awkwardly criticizing code for ugliness without
having a better alternative to show.
Thanks for working on this,
Stefan
>
> Cheers Heiko
^ permalink raw reply [relevance 6%]
* Re: [PATCH] builtin/push.c: add push.pushOption config
@ 2017-10-21 1:33 5% ` Junio C Hamano
0 siblings, 0 replies; 114+ results
From: Junio C Hamano @ 2017-10-21 1:33 UTC (permalink / raw)
To: Marius Paliga
Cc: Stefan Beller, Christian Couder, git@vger.kernel.org, Jeff King,
Thais Diniz
Marius Paliga <marius.paliga@gmail.com> writes:
> Should we also mention that this option can take multiple values from
> the command line?
>
> -o <option>::
> --push-option=<option>::
> Transmit the given string to the server, which passes them to
> the pre-receive as well as the post-receive hook. The given string
> must not contain a NUL or LF character.
> + Multiple `--push-option=<option>` are allowed on the command line.
> When no `--push-option=<option>` is given from the command
> line, the values of configuration variable `push.pushOption`
> are used instead.
My first reaction was "Do we do that for other options that can be
given multiple times? If not, perhaps this is not needed."
Then my second reaction was "Do we have that many options that can
be given multiple times in the first place? If not, perhaps a
change like this to highlight these oddball options may not be a bad
idea."
And my third reaction was "Well, even if we have many such options,
and even if most of them are not explicitly marked as usable
multiple times in the current documentation, that's not a reason to
keep it that way---the readers ought to be able to find out which
ones can be used multiple times and how these multiple instances
interact with each other, because the usual rule for single-instance
options is 'the last one wins' (e.g. 'git status -uall -uno' should
be the same as 'git status -uno') but to these multi-value options
that rule does not hold".
So, yes, I think it is a good idea.
But it opens a tangent #leftoverbits. Among the most commonly used
commands listed in "git --help", there indeed are some commands that
take multiple options of the same kind (even if we do not count an
obvious exception "--verbose", which everybody understands as the
number of times it is given indicates the verbosity level).
Somebody needs to go over their documentation and add "this can be
given multiple times from the command line, and here is what happens
to them".
In your suggestion for "push -o <value1> -o <value2>", "here is what
happens" is missing. Perhaps
When multiple `--push-option=<option>` are given, they are
all sent to the other side in the order listed on the
command line.
or something like that.
Thanks.
^ permalink raw reply [relevance 5%]
* Re: [PATCH 5/5] diff: handle NULs in get_string_hash()
2017-10-19 20:31 5% ` [PATCH 5/5] diff: handle NULs in get_string_hash() Jeff King
@ 2017-10-19 21:31 0% ` Stefan Beller
0 siblings, 0 replies; 114+ results
From: Stefan Beller @ 2017-10-19 21:31 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git@vger.kernel.org, Orgad Shaneh
On Thu, Oct 19, 2017 at 1:31 PM, Jeff King <peff@peff.net> wrote:
> For computing moved lines, we feed the characters of each
> line into a hash. When we've been asked to ignore
> whitespace, then we pick each character using next_byte(),
> which returns -1 on end-of-string, which it determines using
> the start/end pointers we feed it.
>
> However our check of its return value treats "0" the same as
> "-1", meaning we'd quit if the string has an embedded NUL.
I agree. The code looks correct.
> This is unlikely to ever come up in practice since our line
> boundaries generally come from calling strlen() in the first
> place.
get_string_hash is called from
prepare_entry, which in turn is called from
add_lines_to_move_detection or mark_color_as_moved
diff_flush_patch_all_file_pairs
that constructs the arguments in
diff_flush_patch
run_diff
run_diff_cmd
builtin_diff (part "/* Crazy xdl interfaces.. */")
xdi_diff_outf( fn_out_consume as arg!)
xdi_diff
xdl_diff
xdl_call_hunk_func
-> fn_out_consume(cb, line, len)
xdl_call_hunk_func however uses pointer arithmetic instead
of strlen. So I think this sentence is not a good idea to put in
the commit message.
It may not occur in practice, due to binary files detection using
NUL as a signal, but conceptually our move-colored(!) diffs
should be compatible with NULs with this patch now.
> But it was a bit surprising to me as a reader of the
> next_byte() code. And it's possible that we may one day feed
> this function with more exotic input, which otherwise works
> with arbitrary ptr/len pairs.
Good point.
>
> Signed-off-by: Jeff King <peff@peff.net>
> ---
> I noticed that we make an extra copy of each line here, just to feed it
> to memihash! I guess "-w" is not a critical-performance code path, but
> this could be fixed if we could do memhash() incrementally (e.g., by
> putting the FNV state into a struct and letting callers "add" to it
> incrementally). Maybe an interesting #leftoverbits, though I'd want to
> see timing tests that show it's worth doing.
>
I agree.
Thanks,
Stefan
^ permalink raw reply [relevance 0%]
* [PATCH 5/5] diff: handle NULs in get_string_hash()
@ 2017-10-19 20:31 5% ` Jeff King
2017-10-19 21:31 0% ` Stefan Beller
0 siblings, 1 reply; 114+ results
From: Jeff King @ 2017-10-19 20:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Stefan Beller, git, orgads
For computing moved lines, we feed the characters of each
line into a hash. When we've been asked to ignore
whitespace, then we pick each character using next_byte(),
which returns -1 on end-of-string, which it determines using
the start/end pointers we feed it.
However our check of its return value treats "0" the same as
"-1", meaning we'd quit if the string has an embedded NUL.
This is unlikely to ever come up in practice since our line
boundaries generally come from calling strlen() in the first
place.
But it was a bit surprising to me as a reader of the
next_byte() code. And it's possible that we may one day feed
this function with more exotic input, which otherwise works
with arbitrary ptr/len pairs.
Signed-off-by: Jeff King <peff@peff.net>
---
I noticed that we make an extra copy of each line here, just to feed it
to memihash! I guess "-w" is not a critical-performance code path, but
this could be fixed if we could do memhash() incrementally (e.g., by
putting the FNV state into a struct and letting callers "add" to it
incrementally). Maybe an interesting #leftoverbits, though I'd want to
see timing tests that show it's worth doing.
diff.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/diff.c b/diff.c
index 09081a207c..c4a669ffa8 100644
--- a/diff.c
+++ b/diff.c
@@ -782,7 +782,7 @@ static unsigned get_string_hash(struct emitted_diff_symbol *es, struct diff_opti
strbuf_reset(&sb);
while (ae > ap && isspace(ae[-1]))
ae--;
- while ((c = next_byte(&ap, &ae, o)) > 0)
+ while ((c = next_byte(&ap, &ae, o)) >= 0)
strbuf_addch(&sb, c);
return memhash(sb.buf, sb.len);
--
2.15.0.rc1.560.g5f0609e481
^ permalink raw reply related [relevance 5%]
* Re: [PATCH 2/4] remote: handle broken symrefs
@ 2017-10-19 17:53 6% ` Jeff King
0 siblings, 0 replies; 114+ results
From: Jeff King @ 2017-10-19 17:53 UTC (permalink / raw)
To: Andrey Okoshkin
Cc: gitster, git, pclouds, l.s.r, avarab, krh, rctay89,
Ivan Arishchenko, Mikhail Labiuk
On Thu, Oct 19, 2017 at 01:47:30PM -0400, Jeff King wrote:
> This is hard to trigger in practice, since this function is
> used as a callback to for_each_ref(), which will skip broken
> refs in the first place (so it would have to be broken
> racily, or for us to see a transient filesystem error).
>
> If we see such a racy broken outcome let's treat it as "not
> a symref". This is exactly the same thing that would happen
> in the non-racy case (our function would not be called at
> all, as for_each_ref would skip the broken symref).
The fact that we have to re-resolve the ref here to find the symref
points to a short-coming in the for_each_ref() interface. It resolved
the ref already to get us the oid, so it should (or at least could) know
the symref details already. But it doesn't record them or make them
available to callers.
Ditto for patch 3. It doesn't use for_each_ref(), but I suspect it could
be recording the value of HEAD more carefully from the prior lookup,
avoiding the re-resolution completely.
Refactoring for_each_ref() is probably a bit big for a #leftoverbits,
but looking into the case in patch 3 might not be.
-Peff
^ permalink raw reply [relevance 6%]
* Re: [PATCH] patch reply
2017-10-17 4:01 0% ` Junio C Hamano
@ 2017-10-17 7:15 0% ` Marius Paliga
0 siblings, 0 replies; 114+ results
From: Marius Paliga @ 2017-10-17 7:15 UTC (permalink / raw)
To: Junio C Hamano
Cc: Thais Diniz, Christian Couder, git, Jeff King, Stefan Beller
I just sent a patch to a new thread which is not what I wanted.
However I already sent the same patch a few days ago:
https://public-inbox.org/git/CAK7vU=2ePR3jQsgu=RxSMrxytAAHqxC0SFrN5YozLzQzP2ZT2A@mail.gmail.com/
2017-10-17 6:01 GMT+02:00 Junio C Hamano <gitster@pobox.com>:
> Thais Diniz <thais.dinizbraz@gmail.com> writes:
>
>> +Just to clarify I did not see Marius patch.
>> +Did see Marius' comment saying he would look it in the leftoverbits list,
>> +but since i didn't see any patch i thought i could work on it and did so based on Stephan's comment
>> +(which i suppose Mario also did and that is why the code resulted to be similar).
>
> In any case, both versions share exactly the same "don't call
> get_multi() to grab the same configuration values from inside the
> callback of git_config()" issue, so whoever works on it to complete
> the topic, it needs further work.
^ permalink raw reply [relevance 0%]
* Re: [PATCH] patch reply
2017-10-17 3:47 10% ` [PATCH] patch reply Thais Diniz
@ 2017-10-17 4:01 0% ` Junio C Hamano
2017-10-17 7:15 0% ` Marius Paliga
0 siblings, 1 reply; 114+ results
From: Junio C Hamano @ 2017-10-17 4:01 UTC (permalink / raw)
To: Thais Diniz; +Cc: christian.couder, git, marius.paliga, peff, sbeller
Thais Diniz <thais.dinizbraz@gmail.com> writes:
> +Just to clarify I did not see Marius patch.
> +Did see Marius' comment saying he would look it in the leftoverbits list,
> +but since i didn't see any patch i thought i could work on it and did so based on Stephan's comment
> +(which i suppose Mario also did and that is why the code resulted to be similar).
In any case, both versions share exactly the same "don't call
get_multi() to grab the same configuration values from inside the
callback of git_config()" issue, so whoever works on it to complete
the topic, it needs further work.
^ permalink raw reply [relevance 0%]
* Re: [PATCH][Outreachy] New git config variable to specify string that will be automatically passed as --push-option
2017-10-12 3:26 0% ` Junio C Hamano
2017-10-17 3:47 10% ` [PATCH] patch reply Thais Diniz
@ 2017-10-17 3:58 6% ` thais braz
1 sibling, 0 replies; 114+ results
From: thais braz @ 2017-10-17 3:58 UTC (permalink / raw)
To: Junio C Hamano
Cc: Christian Couder, marius.paliga, git, Stefan Beller, Jeff King
Just to clarify I did not see Marius patch.
Did see Marius' comment saying he would look it in the leftoverbits list,
but since i didn't see any patch i thought i could work on it and did
so based on Stephan's comment
(which i suppose Mario also did and that is why the code resulted to
be similar).
And sorry send this email as patch. Didn't know how to use git
send-email just as reply
On Thu, Oct 12, 2017 at 12:26 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Christian Couder <christian.couder@gmail.com> writes:
>
>>> Can somebody explain what is going on?
>>>
>>> I am guessing that Thais and marius are different people (judging by
>>> the fact that one CC's a message to the other). Are you two
>>> collaborating on this change, or something?
>>
>> I guess that Thais decided to work on this, because we ask Outreachy
>> applicants to search for #leftoverbits mentions in the mailing list
>> archive to find small tasks they could work on.
>>
>> In this case it looks like Marius sent a patch a few hours before
>> Thais also sent one.
>
> ... after seeing Marius's already working on it, I think.
>
>> Thais, I am sorry, but as Marius sent a patch first, I think it is
>> better if you search for another different small task to work on.
>
> In general, I do not mind seeing people working together well, and
> it is one of the more important skills necessary in the open source
> community. I however tend to agree with you that this is a bit too
> small a topic for multiple people to be working on.
>
>> Also please keep Peff and me in cc.
>
> Yup, that is always a good idea.
>
--
Atenciosamente Thais Diniz Braz
^ permalink raw reply [relevance 6%]
* [PATCH] patch reply
2017-10-12 3:26 0% ` Junio C Hamano
@ 2017-10-17 3:47 10% ` Thais Diniz
2017-10-17 4:01 0% ` Junio C Hamano
2017-10-17 3:58 6% ` [PATCH][Outreachy] New git config variable to specify string that will be automatically passed as --push-option thais braz
1 sibling, 1 reply; 114+ results
From: Thais Diniz @ 2017-10-17 3:47 UTC (permalink / raw)
To: gitster
Cc: christian.couder, git, marius.paliga, peff, sbeller,
thais.dinizbraz
From: Thais Diniz Braz <thais.dinizbraz@gmail.com>
---
emailReply | 4 ++++
1 file changed, 4 insertions(+)
create mode 100644 emailReply
diff --git a/emailReply b/emailReply
new file mode 100644
index 000000000..2d591b55b
--- /dev/null
+++ b/emailReply
@@ -0,0 +1,4 @@
+Just to clarify I did not see Marius patch.
+Did see Marius' comment saying he would look it in the leftoverbits list,
+but since i didn't see any patch i thought i could work on it and did so based on Stephan's comment
+(which i suppose Mario also did and that is why the code resulted to be similar).
--
2.15.0.rc0.39.g2f0e14e.dirty
^ permalink raw reply related [relevance 10%]
* Re: [PATCH 3/3] branch: forbid refs/heads/HEAD
2017-10-13 13:15 6% ` Jeff King
@ 2017-10-14 2:11 0% ` Junio C Hamano
0 siblings, 0 replies; 114+ results
From: Junio C Hamano @ 2017-10-14 2:11 UTC (permalink / raw)
To: Jeff King; +Cc: git
Jeff King <peff@peff.net> writes:
> On Fri, Oct 13, 2017 at 02:11:32PM +0900, Junio C Hamano wrote:
>
>> strbuf_check_branch_ref() is the central place where many codepaths
>> see if a proposed name is suitable for the name of a branch. It was
>> designed to allow us to get stricter than the check_refname_format()
>> check used for refnames in general, and we already use it to reject
>> a branch whose name begins with a '-'.
>>
>> Use it to also reject "HEAD" as a branch name.
>
> Heh, I just pointed somebody to this a day or two ago as #leftoverbit. I
> guess it's taken now. :)
Didn't notice /remember it; sorry about that. I can retract it if
you want, but perhaps they cannot unsee it ;-)
>> diff --git a/t/t1430-bad-ref-name.sh b/t/t1430-bad-ref-name.sh
>> index e88349c8a0..3ecb2eab0c 100755
>> --- a/t/t1430-bad-ref-name.sh
>> +++ b/t/t1430-bad-ref-name.sh
>> @@ -331,4 +331,12 @@ test_expect_success 'update-ref --stdin -z fails delete with bad ref name' '
>> grep "fatal: invalid ref format: ~a" err
>> '
>>
>> +test_expect_success 'branch rejects HEAD as a branch name' '
>> + test_must_fail git branch HEAD HEAD^
>> +'
>> +
>> +test_expect_success 'checkout -b rejects HEAD as a branch name' '
>> + test_must_fail git checkout -B HEAD HEAD^
>> +'
>
> Should we test that:
>
> git update-ref refs/heads/HEAD HEAD^
>
> continues to work?
Perhaps. Also we may want to make sure that "git branch -D HEAD"
still works as a way to recover from historical mistakes.
^ permalink raw reply [relevance 0%]
* Re: [PATCH 3/3] branch: forbid refs/heads/HEAD
@ 2017-10-13 13:15 6% ` Jeff King
2017-10-14 2:11 0% ` Junio C Hamano
0 siblings, 1 reply; 114+ results
From: Jeff King @ 2017-10-13 13:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
On Fri, Oct 13, 2017 at 02:11:32PM +0900, Junio C Hamano wrote:
> strbuf_check_branch_ref() is the central place where many codepaths
> see if a proposed name is suitable for the name of a branch. It was
> designed to allow us to get stricter than the check_refname_format()
> check used for refnames in general, and we already use it to reject
> a branch whose name begins with a '-'.
>
> Use it to also reject "HEAD" as a branch name.
Heh, I just pointed somebody to this a day or two ago as #leftoverbit. I
guess it's taken now. :)
Related to this: should we do a better job of confirming that the
refname is available for use?
If you do:
git branch foo
git checkout -b foo/bar
then "foo/bar" is not available. And for "checkout -b", we'd notice when
we tried to create the ref. But for:
git checkout --orphan foo/bar
we'd update HEAD with a non-viable name, and only find out later during
"git commit". That's not the end of the world, but it might be nice to
complain when writing the symlink.
Largely orthogonal to the problem you're solving here, but I suspect it
may touch the same code, so it might be worth thinking about while we're
here.
> diff --git a/t/t1430-bad-ref-name.sh b/t/t1430-bad-ref-name.sh
> index e88349c8a0..3ecb2eab0c 100755
> --- a/t/t1430-bad-ref-name.sh
> +++ b/t/t1430-bad-ref-name.sh
> @@ -331,4 +331,12 @@ test_expect_success 'update-ref --stdin -z fails delete with bad ref name' '
> grep "fatal: invalid ref format: ~a" err
> '
>
> +test_expect_success 'branch rejects HEAD as a branch name' '
> + test_must_fail git branch HEAD HEAD^
> +'
> +
> +test_expect_success 'checkout -b rejects HEAD as a branch name' '
> + test_must_fail git checkout -B HEAD HEAD^
> +'
Should we test that:
git update-ref refs/heads/HEAD HEAD^
continues to work?
-Peff
^ permalink raw reply [relevance 6%]
* Re: [PATCH][Outreachy] New git config variable to specify string that will be automatically passed as --push-option
2017-10-12 2:41 6% ` Christian Couder
@ 2017-10-12 3:26 0% ` Junio C Hamano
2017-10-17 3:47 10% ` [PATCH] patch reply Thais Diniz
2017-10-17 3:58 6% ` [PATCH][Outreachy] New git config variable to specify string that will be automatically passed as --push-option thais braz
0 siblings, 2 replies; 114+ results
From: Junio C Hamano @ 2017-10-12 3:26 UTC (permalink / raw)
To: Christian Couder
Cc: Thais D. Braz, marius.paliga, git, Stefan Beller, Jeff King
Christian Couder <christian.couder@gmail.com> writes:
>> Can somebody explain what is going on?
>>
>> I am guessing that Thais and marius are different people (judging by
>> the fact that one CC's a message to the other). Are you two
>> collaborating on this change, or something?
>
> I guess that Thais decided to work on this, because we ask Outreachy
> applicants to search for #leftoverbits mentions in the mailing list
> archive to find small tasks they could work on.
>
> In this case it looks like Marius sent a patch a few hours before
> Thais also sent one.
... after seeing Marius's already working on it, I think.
> Thais, I am sorry, but as Marius sent a patch first, I think it is
> better if you search for another different small task to work on.
In general, I do not mind seeing people working together well, and
it is one of the more important skills necessary in the open source
community. I however tend to agree with you that this is a bit too
small a topic for multiple people to be working on.
> Also please keep Peff and me in cc.
Yup, that is always a good idea.
^ permalink raw reply [relevance 0%]
* Re: [PATCH][Outreachy] New git config variable to specify string that will be automatically passed as --push-option
@ 2017-10-12 2:41 6% ` Christian Couder
2017-10-12 3:26 0% ` Junio C Hamano
0 siblings, 1 reply; 114+ results
From: Christian Couder @ 2017-10-12 2:41 UTC (permalink / raw)
To: Junio C Hamano, Thais D. Braz
Cc: marius.paliga, git, Stefan Beller, Jeff King
On Thu, Oct 12, 2017 at 3:21 AM, Junio C Hamano <gitster@pobox.com> wrote:
> "Thais D. Braz" <thais.dinizbraz@gmail.com> writes:
>
>> ---
>> Documentation/git-push.txt | 3 +++
>> builtin/push.c | 9 ++++++++-
>> 2 files changed, 11 insertions(+), 1 deletion(-)
>
> Can somebody explain what is going on?
>
> I am guessing that Thais and marius are different people (judging by
> the fact that one CC's a message to the other). Are you two
> collaborating on this change, or something?
I guess that Thais decided to work on this, because we ask Outreachy
applicants to search for #leftoverbits mentions in the mailing list
archive to find small tasks they could work on.
In this case it looks like Marius sent a patch a few hours before
Thais also sent one.
Thais, I am sorry, but as Marius sent a patch first, I think it is
better if you search for another different small task to work on.
Also please keep Peff and me in cc.
Thanks.
^ permalink raw reply [relevance 6%]
* Re: Enhancement request: git-push: Allow (configurable) default push-option
2017-10-11 7:14 0% ` Marius Paliga
@ 2017-10-11 9:18 0% ` Marius Paliga
0 siblings, 0 replies; 114+ results
From: Marius Paliga @ 2017-10-11 9:18 UTC (permalink / raw)
To: Stefan Beller; +Cc: git@vger.kernel.org
Found one possible issue when looking for duplicates, we need to use
"unsorted_string_list_has_string" instead of "string_list_has_string"
- if (!string_list_has_string(&push_options,
item->string))
+ if
(!unsorted_string_list_has_string(&push_options, item->string)) {
New (fixed) patch follows...
Signed-off-by: Marius Paliga <marius.paliga@gmail.com>
---
Documentation/git-push.txt | 3 +++
builtin/push.c | 11 ++++++++++-
t/t5545-push-options.sh | 48 ++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 61 insertions(+), 1 deletion(-)
diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index 3e76e99f3..133c42183 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -161,6 +161,9 @@ already exists on the remote side.
Transmit the given string to the server, which passes them to
the pre-receive as well as the post-receive hook. The given string
must not contain a NUL or LF character.
+ Default push options can also be specified with configuration
+ variable `push.optiondefault`. String(s) specified here will always
+ be passed to the server without need to specify it using `--push-option`
--receive-pack=<git-receive-pack>::
--exec=<git-receive-pack>::
diff --git a/builtin/push.c b/builtin/push.c
index 2ac810422..ab458419a 100644
--- a/builtin/push.c
+++ b/builtin/push.c
@@ -32,6 +32,8 @@ static const char **refspec;
static int refspec_nr;
static int refspec_alloc;
+static struct string_list push_options = STRING_LIST_INIT_DUP;
+
static void add_refspec(const char *ref)
{
refspec_nr++;
@@ -467,6 +469,8 @@ static int git_push_config(const char *k, const
char *v, void *cb)
{
int *flags = cb;
int status;
+ const struct string_list *default_push_options;
+ struct string_list_item *item;
status = git_gpg_config(k, v, NULL);
if (status)
@@ -505,6 +509,12 @@ static int git_push_config(const char *k, const
char *v, void *cb)
recurse_submodules = val;
}
+ default_push_options = git_config_get_value_multi("push.optiondefault");
+ if (default_push_options)
+ for_each_string_list_item(item, default_push_options)
+ if (!unsorted_string_list_has_string(&push_options, item->string))
+ string_list_append(&push_options, item->string);
+
return git_default_config(k, v, NULL);
}
@@ -515,7 +525,6 @@ int cmd_push(int argc, const char **argv, const
char *prefix)
int push_cert = -1;
int rc;
const char *repo = NULL; /* default repository */
- struct string_list push_options = STRING_LIST_INIT_DUP;
const struct string_list_item *item;
struct option options[] = {
diff --git a/t/t5545-push-options.sh b/t/t5545-push-options.sh
index 90a4b0d2f..575f3dc38 100755
--- a/t/t5545-push-options.sh
+++ b/t/t5545-push-options.sh
@@ -140,6 +140,54 @@ test_expect_success 'push options and submodules' '
test_cmp expect parent_upstream/.git/hooks/post-receive.push_options
'
+test_expect_success 'default push option' '
+ mk_repo_pair &&
+ git -C upstream config receive.advertisePushOptions true &&
+ (
+ cd workbench &&
+ test_commit one &&
+ git push --mirror up &&
+ test_commit two &&
+ git -c push.optiondefault=default push up master
+ ) &&
+ test_refs master master &&
+ echo "default" >expect &&
+ test_cmp expect upstream/.git/hooks/pre-receive.push_options &&
+ test_cmp expect upstream/.git/hooks/post-receive.push_options
+'
+
+test_expect_success 'two default push options' '
+ mk_repo_pair &&
+ git -C upstream config receive.advertisePushOptions true &&
+ (
+ cd workbench &&
+ test_commit one &&
+ git push --mirror up &&
+ test_commit two &&
+ git -c push.optiondefault=default1 -c
push.optiondefault=default2 push up master
+ ) &&
+ test_refs master master &&
+ printf "default1\ndefault2\n" >expect &&
+ test_cmp expect upstream/.git/hooks/pre-receive.push_options &&
+ test_cmp expect upstream/.git/hooks/post-receive.push_options
+'
+
+test_expect_success 'default and manual push options' '
+ mk_repo_pair &&
+ git -C upstream config receive.advertisePushOptions true &&
+ (
+ cd workbench &&
+ test_commit one &&
+ git push --mirror up &&
+ test_commit two &&
+ git -c push.optiondefault=default push --push-option=manual up master
+ ) &&
+ test_refs master master &&
+ printf "default\nmanual\n" >expect &&
+ test_cmp expect upstream/.git/hooks/pre-receive.push_options &&
+ test_cmp expect upstream/.git/hooks/post-receive.push_options
+'
+
. "$TEST_DIRECTORY"/lib-httpd.sh
start_httpd
--
2.14.1
2017-10-11 9:14 GMT+02:00 Marius Paliga <marius.paliga@gmail.com>:
> Including proposed patch...
>
>
> Signed-off-by: Marius Paliga <marius.paliga@gmail.com>
> ---
> Documentation/git-push.txt | 3 +++
> builtin/push.c | 11 ++++++++++-
> t/t5545-push-options.sh | 48 ++++++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 61 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
> index 3e76e99f3..133c42183 100644
> --- a/Documentation/git-push.txt
> +++ b/Documentation/git-push.txt
> @@ -161,6 +161,9 @@ already exists on the remote side.
> Transmit the given string to the server, which passes them to
> the pre-receive as well as the post-receive hook. The given string
> must not contain a NUL or LF character.
> + Default push options can also be specified with configuration
> + variable `push.optiondefault`. String(s) specified here will always
> + be passed to the server without need to specify it using `--push-option`
>
> --receive-pack=<git-receive-pack>::
> --exec=<git-receive-pack>::
> diff --git a/builtin/push.c b/builtin/push.c
> index 2ac810422..4dd5d6f0e 100644
> --- a/builtin/push.c
> +++ b/builtin/push.c
> @@ -32,6 +32,8 @@ static const char **refspec;
> static int refspec_nr;
> static int refspec_alloc;
>
> +static struct string_list push_options = STRING_LIST_INIT_DUP;
> +
> static void add_refspec(const char *ref)
> {
> refspec_nr++;
> @@ -467,6 +469,8 @@ static int git_push_config(const char *k, const
> char *v, void *cb)
> {
> int *flags = cb;
> int status;
> + const struct string_list *default_push_options;
> + struct string_list_item *item;
>
> status = git_gpg_config(k, v, NULL);
> if (status)
> @@ -505,6 +509,12 @@ static int git_push_config(const char *k, const
> char *v, void *cb)
> recurse_submodules = val;
> }
>
> + default_push_options = git_config_get_value_multi("push.optiondefault");
> + if (default_push_options)
> + for_each_string_list_item(item, default_push_options)
> + if (!string_list_has_string(&push_options, item->string))
> + string_list_append(&push_options, item->string);
> +
> return git_default_config(k, v, NULL);
> }
>
> @@ -515,7 +525,6 @@ int cmd_push(int argc, const char **argv, const
> char *prefix)
> int push_cert = -1;
> int rc;
> const char *repo = NULL; /* default repository */
> - struct string_list push_options = STRING_LIST_INIT_DUP;
> const struct string_list_item *item;
>
> struct option options[] = {
> diff --git a/t/t5545-push-options.sh b/t/t5545-push-options.sh
> index 90a4b0d2f..575f3dc38 100755
> --- a/t/t5545-push-options.sh
> +++ b/t/t5545-push-options.sh
> @@ -140,6 +140,54 @@ test_expect_success 'push options and submodules' '
> test_cmp expect parent_upstream/.git/hooks/post-receive.push_options
> '
>
> +test_expect_success 'default push option' '
> + mk_repo_pair &&
> + git -C upstream config receive.advertisePushOptions true &&
> + (
> + cd workbench &&
> + test_commit one &&
> + git push --mirror up &&
> + test_commit two &&
> + git -c push.optiondefault=default push up master
> + ) &&
> + test_refs master master &&
> + echo "default" >expect &&
> + test_cmp expect upstream/.git/hooks/pre-receive.push_options &&
> + test_cmp expect upstream/.git/hooks/post-receive.push_options
> +'
> +
> +test_expect_success 'two default push options' '
> + mk_repo_pair &&
> + git -C upstream config receive.advertisePushOptions true &&
> + (
> + cd workbench &&
> + test_commit one &&
> + git push --mirror up &&
> + test_commit two &&
> + git -c push.optiondefault=default1 -c
> push.optiondefault=default2 push up master
> + ) &&
> + test_refs master master &&
> + printf "default1\ndefault2\n" >expect &&
> + test_cmp expect upstream/.git/hooks/pre-receive.push_options &&
> + test_cmp expect upstream/.git/hooks/post-receive.push_options
> +'
> +
> +test_expect_success 'default and manual push options' '
> + mk_repo_pair &&
> + git -C upstream config receive.advertisePushOptions true &&
> + (
> + cd workbench &&
> + test_commit one &&
> + git push --mirror up &&
> + test_commit two &&
> + git -c push.optiondefault=default push --push-option=manual up master
> + ) &&
> + test_refs master master &&
> + printf "default\nmanual\n" >expect &&
> + test_cmp expect upstream/.git/hooks/pre-receive.push_options &&
> + test_cmp expect upstream/.git/hooks/post-receive.push_options
> +'
> +
> . "$TEST_DIRECTORY"/lib-httpd.sh
> start_httpd
>
> --
> 2.14.1
>
>
> 2017-10-04 17:20 GMT+02:00 Marius Paliga <marius.paliga@gmail.com>:
>> Hi Stefan,
>>
>> I will look at it.
>>
>> Thanks,
>> Marius
>>
>>
>> 2017-10-03 18:53 GMT+02:00 Stefan Beller <sbeller@google.com>:
>>> On Tue, Oct 3, 2017 at 3:15 AM, Marius Paliga <marius.paliga@gmail.com> wrote:
>>>> There is a need to pass predefined push-option during "git push"
>>>> without need to specify it explicitly.
>>>>
>>>> In another words we need to have a new "git config" variable to
>>>> specify string that will be automatically passed as "--push-option"
>>>> when pushing to remote.
>>>>
>>>> Something like the following:
>>>>
>>>> git config push.optionDefault AllowMultipleCommits
>>>>
>>>> and then command
>>>> git push
>>>> would silently run
>>>> git push --push-option "AllowMultipleCommits"
>>>
>>> We would need to
>>> * design this feature (seems like you already have a good idea what you need)
>>> * implement it (see builtin/push.c):
>>> - move "struct string_list push_options = STRING_LIST_INIT_DUP;"
>>> to be a file-static variable, such that we have access to it outside
>>> of cmd_push.
>>> - In git_push_config in builtin/push.c that parses the config, we'd
>>> need to check
>>> for "push.optionDefault" and add these to the push_options (I assume multiple
>>> are allowed)
>>> * document it (Documentation/git-push.txt)
>>> * add a test for it ? (t/t5545-push-options.sh)
>>>
>>> Care to write a patch? Otherwise I'd mark it up as part of
>>> #leftoverbits for now,
>>> as it seems like a good starter project.
>>>
>>> Thanks,
>>> Stefan
^ permalink raw reply related [relevance 0%]
* Re: Enhancement request: git-push: Allow (configurable) default push-option
2017-10-04 15:20 0% ` Marius Paliga
@ 2017-10-11 7:14 0% ` Marius Paliga
2017-10-11 9:18 0% ` Marius Paliga
1 sibling, 1 reply; 114+ results
From: Marius Paliga @ 2017-10-11 7:14 UTC (permalink / raw)
To: Stefan Beller; +Cc: git@vger.kernel.org
Including proposed patch...
Signed-off-by: Marius Paliga <marius.paliga@gmail.com>
---
Documentation/git-push.txt | 3 +++
builtin/push.c | 11 ++++++++++-
t/t5545-push-options.sh | 48 ++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 61 insertions(+), 1 deletion(-)
diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index 3e76e99f3..133c42183 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -161,6 +161,9 @@ already exists on the remote side.
Transmit the given string to the server, which passes them to
the pre-receive as well as the post-receive hook. The given string
must not contain a NUL or LF character.
+ Default push options can also be specified with configuration
+ variable `push.optiondefault`. String(s) specified here will always
+ be passed to the server without need to specify it using `--push-option`
--receive-pack=<git-receive-pack>::
--exec=<git-receive-pack>::
diff --git a/builtin/push.c b/builtin/push.c
index 2ac810422..4dd5d6f0e 100644
--- a/builtin/push.c
+++ b/builtin/push.c
@@ -32,6 +32,8 @@ static const char **refspec;
static int refspec_nr;
static int refspec_alloc;
+static struct string_list push_options = STRING_LIST_INIT_DUP;
+
static void add_refspec(const char *ref)
{
refspec_nr++;
@@ -467,6 +469,8 @@ static int git_push_config(const char *k, const
char *v, void *cb)
{
int *flags = cb;
int status;
+ const struct string_list *default_push_options;
+ struct string_list_item *item;
status = git_gpg_config(k, v, NULL);
if (status)
@@ -505,6 +509,12 @@ static int git_push_config(const char *k, const
char *v, void *cb)
recurse_submodules = val;
}
+ default_push_options = git_config_get_value_multi("push.optiondefault");
+ if (default_push_options)
+ for_each_string_list_item(item, default_push_options)
+ if (!string_list_has_string(&push_options, item->string))
+ string_list_append(&push_options, item->string);
+
return git_default_config(k, v, NULL);
}
@@ -515,7 +525,6 @@ int cmd_push(int argc, const char **argv, const
char *prefix)
int push_cert = -1;
int rc;
const char *repo = NULL; /* default repository */
- struct string_list push_options = STRING_LIST_INIT_DUP;
const struct string_list_item *item;
struct option options[] = {
diff --git a/t/t5545-push-options.sh b/t/t5545-push-options.sh
index 90a4b0d2f..575f3dc38 100755
--- a/t/t5545-push-options.sh
+++ b/t/t5545-push-options.sh
@@ -140,6 +140,54 @@ test_expect_success 'push options and submodules' '
test_cmp expect parent_upstream/.git/hooks/post-receive.push_options
'
+test_expect_success 'default push option' '
+ mk_repo_pair &&
+ git -C upstream config receive.advertisePushOptions true &&
+ (
+ cd workbench &&
+ test_commit one &&
+ git push --mirror up &&
+ test_commit two &&
+ git -c push.optiondefault=default push up master
+ ) &&
+ test_refs master master &&
+ echo "default" >expect &&
+ test_cmp expect upstream/.git/hooks/pre-receive.push_options &&
+ test_cmp expect upstream/.git/hooks/post-receive.push_options
+'
+
+test_expect_success 'two default push options' '
+ mk_repo_pair &&
+ git -C upstream config receive.advertisePushOptions true &&
+ (
+ cd workbench &&
+ test_commit one &&
+ git push --mirror up &&
+ test_commit two &&
+ git -c push.optiondefault=default1 -c
push.optiondefault=default2 push up master
+ ) &&
+ test_refs master master &&
+ printf "default1\ndefault2\n" >expect &&
+ test_cmp expect upstream/.git/hooks/pre-receive.push_options &&
+ test_cmp expect upstream/.git/hooks/post-receive.push_options
+'
+
+test_expect_success 'default and manual push options' '
+ mk_repo_pair &&
+ git -C upstream config receive.advertisePushOptions true &&
+ (
+ cd workbench &&
+ test_commit one &&
+ git push --mirror up &&
+ test_commit two &&
+ git -c push.optiondefault=default push --push-option=manual up master
+ ) &&
+ test_refs master master &&
+ printf "default\nmanual\n" >expect &&
+ test_cmp expect upstream/.git/hooks/pre-receive.push_options &&
+ test_cmp expect upstream/.git/hooks/post-receive.push_options
+'
+
. "$TEST_DIRECTORY"/lib-httpd.sh
start_httpd
--
2.14.1
2017-10-04 17:20 GMT+02:00 Marius Paliga <marius.paliga@gmail.com>:
> Hi Stefan,
>
> I will look at it.
>
> Thanks,
> Marius
>
>
> 2017-10-03 18:53 GMT+02:00 Stefan Beller <sbeller@google.com>:
>> On Tue, Oct 3, 2017 at 3:15 AM, Marius Paliga <marius.paliga@gmail.com> wrote:
>>> There is a need to pass predefined push-option during "git push"
>>> without need to specify it explicitly.
>>>
>>> In another words we need to have a new "git config" variable to
>>> specify string that will be automatically passed as "--push-option"
>>> when pushing to remote.
>>>
>>> Something like the following:
>>>
>>> git config push.optionDefault AllowMultipleCommits
>>>
>>> and then command
>>> git push
>>> would silently run
>>> git push --push-option "AllowMultipleCommits"
>>
>> We would need to
>> * design this feature (seems like you already have a good idea what you need)
>> * implement it (see builtin/push.c):
>> - move "struct string_list push_options = STRING_LIST_INIT_DUP;"
>> to be a file-static variable, such that we have access to it outside
>> of cmd_push.
>> - In git_push_config in builtin/push.c that parses the config, we'd
>> need to check
>> for "push.optionDefault" and add these to the push_options (I assume multiple
>> are allowed)
>> * document it (Documentation/git-push.txt)
>> * add a test for it ? (t/t5545-push-options.sh)
>>
>> Care to write a patch? Otherwise I'd mark it up as part of
>> #leftoverbits for now,
>> as it seems like a good starter project.
>>
>> Thanks,
>> Stefan
^ permalink raw reply related [relevance 0%]
* [PATCH 0/2] Do not call cmd_*() as a subroutine
2017-09-05 10:03 6% ` Junio C Hamano
@ 2017-10-10 4:06 6% ` Junio C Hamano
0 siblings, 0 replies; 114+ results
From: Junio C Hamano @ 2017-10-10 4:06 UTC (permalink / raw)
To: git
These two patches are for a recent #leftoverbits topic.
https://public-inbox.org/git/xmqqr2vlbgyk.fsf@gitster.mtv.corp.google.com/
The cmd_foo() function is a moral equivalent of 'main' for a Git
subcommand 'git foo', and as such, it is allowed to do many things
that make it unsuitable to be called as a subroutine, including
- call exit(3) to terminate the process;
- allocate resource held and used throughout its lifetime, without
releasing it upon return/exit;
- rely on global variables being initialized at program startup,
and update them as needed, making another clean invocation of the
function impossible.
Correcting two callers by using helper API calls is not so hard.
Junio C Hamano (2):
describe: do not use cmd_*() as a subroutine
merge-ours: do not use cmd_*() as a subroutine
builtin/describe.c | 15 +++++++++++----
builtin/merge-ours.c | 16 +++++++---------
2 files changed, 18 insertions(+), 13 deletions(-)
--
2.15.0-rc0-203-g4c8d0e28b1
^ permalink raw reply [relevance 6%]
* Re: [PATCH 2/3] for-each-ref: let upstream/push optionally report merge name.
@ 2017-10-05 9:14 6% ` Junio C Hamano
0 siblings, 0 replies; 114+ results
From: Junio C Hamano @ 2017-10-05 9:14 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, J Wyman
Junio C Hamano <gitster@pobox.com> writes:
> I think the remaining points from my reviews are:
>
> - It would be better to compute precomputable stuff when used atoms
> are parsed, instead of running starts_with() in these functions;
After reading the original (before these three patches) code for
populate_value(), I think reverting this mess back to how the thing
was originally envisioned to be would be outside the scope of this
addition. It was way too messy before your series than I expected.
So, unless you or your collaborator feel like helping us to clean up
the codebase for better future, let's forget about that point, and
leave the cleaning up for now.
For those who want to help with the #leftoverbits, the first step of
cleaning up would be to introduce an enum field that sits next to
used_atom[i].name, and have the if/else if/... cascades use that
instead of these starts_with(name) to choose what value to grab from
the given ref.
^ permalink raw reply [relevance 6%]
* Re: Enhancement request: git-push: Allow (configurable) default push-option
2017-10-03 16:53 6% ` Stefan Beller
@ 2017-10-04 15:20 0% ` Marius Paliga
2017-10-11 7:14 0% ` Marius Paliga
0 siblings, 2 replies; 114+ results
From: Marius Paliga @ 2017-10-04 15:20 UTC (permalink / raw)
To: Stefan Beller; +Cc: git@vger.kernel.org
Hi Stefan,
I will look at it.
Thanks,
Marius
2017-10-03 18:53 GMT+02:00 Stefan Beller <sbeller@google.com>:
> On Tue, Oct 3, 2017 at 3:15 AM, Marius Paliga <marius.paliga@gmail.com> wrote:
>> There is a need to pass predefined push-option during "git push"
>> without need to specify it explicitly.
>>
>> In another words we need to have a new "git config" variable to
>> specify string that will be automatically passed as "--push-option"
>> when pushing to remote.
>>
>> Something like the following:
>>
>> git config push.optionDefault AllowMultipleCommits
>>
>> and then command
>> git push
>> would silently run
>> git push --push-option "AllowMultipleCommits"
>
> We would need to
> * design this feature (seems like you already have a good idea what you need)
> * implement it (see builtin/push.c):
> - move "struct string_list push_options = STRING_LIST_INIT_DUP;"
> to be a file-static variable, such that we have access to it outside
> of cmd_push.
> - In git_push_config in builtin/push.c that parses the config, we'd
> need to check
> for "push.optionDefault" and add these to the push_options (I assume multiple
> are allowed)
> * document it (Documentation/git-push.txt)
> * add a test for it ? (t/t5545-push-options.sh)
>
> Care to write a patch? Otherwise I'd mark it up as part of
> #leftoverbits for now,
> as it seems like a good starter project.
>
> Thanks,
> Stefan
^ permalink raw reply [relevance 0%]
* Re: What means "git config bla ~/"?
@ 2017-10-04 4:01 6% ` Junio C Hamano
0 siblings, 0 replies; 114+ results
From: Junio C Hamano @ 2017-10-04 4:01 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Jonathan Nieder, rpjday, Git Mailing List
Matthieu Moy <git@matthieu-moy.fr> writes:
> "Junio C Hamano" <gitster@pobox.com> writes:
>
>> Jonathan Nieder <jrnieder@gmail.com> writes:
>>
>>>> what's with that "git config bla ~/"? is this some config keyword
>>>> or something?
>>> ...
>> git config section.var ~/some/thing
>> ...
>
> I prefer your "section.var" proposal above. I think people who really understand shell quoting do not need the explanations, and others probably need the example.
>
> While we're there, the formatting is also wrong ('' quoting, while we normally use `` quoting for shell commands).
>
> Sounds like a nice microproject for my students :-). A patch should follow soon.
OK, thanks. Lest we forget, this is #leftoverbits for now.
^ permalink raw reply [relevance 6%]
* Re: [PATCH] branch: reset instead of release a strbuf
2017-10-03 21:14 6% [PATCH] branch: reset instead of release a strbuf Stefan Beller
@ 2017-10-03 21:46 0% ` Jonathan Nieder
0 siblings, 0 replies; 114+ results
From: Jonathan Nieder @ 2017-10-03 21:46 UTC (permalink / raw)
To: Stefan Beller; +Cc: git
Hi,
Stefan Beller wrote:
> Our documentation advises to not re-use a strbuf, after strbuf_release
> has been called on it. Use the proper reset instead.
I'm super surprised at this documentation. strbuf_release maintains
the invariant that a strbuf is always usable (i.e., that we do not have
to fear use-after-free problems).
On second thought, though, strbuf_release is a more expensive operation
than strbuf_reset --- constantly free()-ing and re-malloc()ing is
unnecessary churn in malloc data structures. So maybe that is the
motivation here?
> Signed-off-by: Stefan Beller <sbeller@google.com>
> ---
>
> Maybe one of the #leftoverbits is to remove the re-init call in release
> and see what breaks? (And then fixing up more of such cases as presented
> in this patch)
As mentioned above: please no. That would be problematic both for
ease of development and for the risk of security bugs.
> builtin/branch.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/builtin/branch.c b/builtin/branch.c
> index b998e16d0c..9758012390 100644
> --- a/builtin/branch.c
> +++ b/builtin/branch.c
> @@ -217,7 +217,7 @@ static int delete_branches(int argc, const char **argv, int force, int kinds,
> if (!head_rev)
> die(_("Couldn't look up commit object for HEAD"));
> }
> - for (i = 0; i < argc; i++, strbuf_release(&bname)) {
> + for (i = 0; i < argc; i++, strbuf_reset(&bname)) {
> char *target = NULL;
> int flags = 0;
Should there be a strbuf_release (or UNLEAK if you are very very sure)
call at the end of the function to replace this?
With that change (but not without it),
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Thanks.
^ permalink raw reply [relevance 0%]
* [PATCH] branch: reset instead of release a strbuf
@ 2017-10-03 21:14 6% Stefan Beller
2017-10-03 21:46 0% ` Jonathan Nieder
0 siblings, 1 reply; 114+ results
From: Stefan Beller @ 2017-10-03 21:14 UTC (permalink / raw)
To: git; +Cc: Stefan Beller
Our documentation advises to not re-use a strbuf, after strbuf_release
has been called on it. Use the proper reset instead.
Signed-off-by: Stefan Beller <sbeller@google.com>
---
Maybe one of the #leftoverbits is to remove the re-init call in release
and see what breaks? (And then fixing up more of such cases as presented
in this patch)
Thanks,
Stefan
builtin/branch.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/branch.c b/builtin/branch.c
index b998e16d0c..9758012390 100644
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@ -217,7 +217,7 @@ static int delete_branches(int argc, const char **argv, int force, int kinds,
if (!head_rev)
die(_("Couldn't look up commit object for HEAD"));
}
- for (i = 0; i < argc; i++, strbuf_release(&bname)) {
+ for (i = 0; i < argc; i++, strbuf_reset(&bname)) {
char *target = NULL;
int flags = 0;
--
2.14.0.rc0.3.g6c2e499285
^ permalink raw reply related [relevance 6%]
* Re: Enhancement request: git-push: Allow (configurable) default push-option
@ 2017-10-03 16:53 6% ` Stefan Beller
2017-10-04 15:20 0% ` Marius Paliga
0 siblings, 1 reply; 114+ results
From: Stefan Beller @ 2017-10-03 16:53 UTC (permalink / raw)
To: Marius Paliga; +Cc: git@vger.kernel.org
On Tue, Oct 3, 2017 at 3:15 AM, Marius Paliga <marius.paliga@gmail.com> wrote:
> There is a need to pass predefined push-option during "git push"
> without need to specify it explicitly.
>
> In another words we need to have a new "git config" variable to
> specify string that will be automatically passed as "--push-option"
> when pushing to remote.
>
> Something like the following:
>
> git config push.optionDefault AllowMultipleCommits
>
> and then command
> git push
> would silently run
> git push --push-option "AllowMultipleCommits"
We would need to
* design this feature (seems like you already have a good idea what you need)
* implement it (see builtin/push.c):
- move "struct string_list push_options = STRING_LIST_INIT_DUP;"
to be a file-static variable, such that we have access to it outside
of cmd_push.
- In git_push_config in builtin/push.c that parses the config, we'd
need to check
for "push.optionDefault" and add these to the push_options (I assume multiple
are allowed)
* document it (Documentation/git-push.txt)
* add a test for it ? (t/t5545-push-options.sh)
Care to write a patch? Otherwise I'd mark it up as part of
#leftoverbits for now,
as it seems like a good starter project.
Thanks,
Stefan
^ permalink raw reply [relevance 6%]
* Re: [PATCH v2 Outreachy] mru: use double-linked list from list.h
@ 2017-10-02 8:20 6% ` Jeff King
2017-11-08 1:44 0% ` Junio C Hamano
0 siblings, 1 reply; 114+ results
From: Jeff King @ 2017-10-02 8:20 UTC (permalink / raw)
To: Olga Telezhnaya; +Cc: Junio C Hamano, git
On Sat, Sep 30, 2017 at 05:51:01PM +0000, Olga Telezhnaya wrote:
> Simplify mru.[ch] and related code by reusing the double-linked list
> implementation from list.h instead of a custom one.
> This commit is an intermediate step. Our final goal is to get rid of
> mru.[ch] at all and inline all logic.
Thanks, this version looks correct to me.
I do think there are a few ugly bits in the result (like that
initializer for packed_git_mru :) ), so I'd prefer not to merge this
down until we do that final step.
So the big question is: who wants to do it?
I think you've done a good job here, and this would count for your
Outreachy application's contribution. But if you'd like to do that next
step, you are welcome to.
We could also consider it a #leftoverbits that perhaps some other
Outreachy candidate would pick up[1].
In the meantime, Junio, I think we'd want to queue this with the intent
to graduate it to "pu" or possibly "next", but not "master". Then if
somebody (Olga or another applicant) produces the endgame patch, we can
queue it on top and move it further. And if nobody does, I can pick it
after the application period is over.
-Peff
[1] For those who find this mail through the archive, there's more
discussion in this thread:
https://public-inbox.org/git/CAL21BmnvJSaN+Tnw7Hdc5P5biAnM5dfWR7gX5FrAG1r_D8th=A@mail.gmail.com/
^ permalink raw reply [relevance 6%]
* Re: [PATCH v5 6/6] ref-filter.c: parse trailers arguments with %(contents) atom
2017-10-02 5:12 6% ` Taylor Blau
@ 2017-10-02 5:14 0% ` Jeff King
0 siblings, 0 replies; 114+ results
From: Jeff King @ 2017-10-02 5:14 UTC (permalink / raw)
To: Taylor Blau; +Cc: git, gitster
On Sun, Oct 01, 2017 at 10:12:16PM -0700, Taylor Blau wrote:
> > Doh, that string_list behavior is what I was missing in my earlier
> > comments. I agree this is probably the best way of doing it. I'm tempted
> > to say that parse_ref_filter_atom() should do a similar thing. Right now
> > we've got:
> >
> > $ git for-each-ref --format='%(refname)' | wc
> > 2206 2206 79929
> > $ git for-each-ref --format='%(refname:short)' | wc
> > 2206 2206 53622
> > $ git for-each-ref --format='%(refname:)' | wc
> > fatal: unrecognized %(refname:) argument:
> > 0 0 0
> >
> > which seems a bit unfriendly. As we're on v6 here, I don't want to
> > suggest it as part of this series. But maybe a #leftoverbits candidate,
> > if others agree it's a good direction.
>
> I think #leftoverbits is fine here, but I think addressing this before
> 2.15 is reasonable. I can take a look at this in a future patch series.
I think it would be to just do it as a standalone patch immediately. I
just didn't want to hold your series hostage to a potential
disagreement.
-Peff
^ permalink raw reply [relevance 0%]
* Re: [PATCH v5 6/6] ref-filter.c: parse trailers arguments with %(contents) atom
2017-10-02 5:03 6% ` Jeff King
@ 2017-10-02 5:12 6% ` Taylor Blau
2017-10-02 5:14 0% ` Jeff King
0 siblings, 1 reply; 114+ results
From: Taylor Blau @ 2017-10-02 5:12 UTC (permalink / raw)
To: Jeff King; +Cc: git, gitster
On Mon, Oct 02, 2017 at 01:03:51AM -0400, Jeff King wrote:
> On Sun, Oct 01, 2017 at 05:33:04PM -0700, Taylor Blau wrote:
>
> > The %(contents) atom takes a contents "field" as its argument. Since
> > "trailers" is one of those fields, extend contents_atom_parser to parse
> > "trailers"'s arguments when used through "%(contents)", like:
> >
> > %(contents:trailers:unfold,only)
> >
> > A caveat: trailers_atom_parser expects NULL when no arguments are given
> > (see: `parse_ref_filter_atom`). This is because string_list_split (given
> > a maxsplit of -1) returns a 1-ary string_list* containing the given
> > string if the delimiter could not be found using `strchr`.
> >
> > To simulate this behavior without teaching trailers_atom_parser to
> > accept strings with length zero, conditionally pass NULL to
> > trailers_atom_parser if the arguments portion of the argument to
> > %(contents) is empty.
>
> Doh, that string_list behavior is what I was missing in my earlier
> comments. I agree this is probably the best way of doing it. I'm tempted
> to say that parse_ref_filter_atom() should do a similar thing. Right now
> we've got:
>
> $ git for-each-ref --format='%(refname)' | wc
> 2206 2206 79929
> $ git for-each-ref --format='%(refname:short)' | wc
> 2206 2206 53622
> $ git for-each-ref --format='%(refname:)' | wc
> fatal: unrecognized %(refname:) argument:
> 0 0 0
>
> which seems a bit unfriendly. As we're on v6 here, I don't want to
> suggest it as part of this series. But maybe a #leftoverbits candidate,
> if others agree it's a good direction.
I think #leftoverbits is fine here, but I think addressing this before
2.15 is reasonable. I can take a look at this in a future patch series.
--
- Taylor
^ permalink raw reply [relevance 6%]
* Re: [PATCH v5 6/6] ref-filter.c: parse trailers arguments with %(contents) atom
@ 2017-10-02 5:03 6% ` Jeff King
2017-10-02 5:12 6% ` Taylor Blau
0 siblings, 1 reply; 114+ results
From: Jeff King @ 2017-10-02 5:03 UTC (permalink / raw)
To: Taylor Blau; +Cc: git, gitster
On Sun, Oct 01, 2017 at 05:33:04PM -0700, Taylor Blau wrote:
> The %(contents) atom takes a contents "field" as its argument. Since
> "trailers" is one of those fields, extend contents_atom_parser to parse
> "trailers"'s arguments when used through "%(contents)", like:
>
> %(contents:trailers:unfold,only)
>
> A caveat: trailers_atom_parser expects NULL when no arguments are given
> (see: `parse_ref_filter_atom`). This is because string_list_split (given
> a maxsplit of -1) returns a 1-ary string_list* containing the given
> string if the delimiter could not be found using `strchr`.
>
> To simulate this behavior without teaching trailers_atom_parser to
> accept strings with length zero, conditionally pass NULL to
> trailers_atom_parser if the arguments portion of the argument to
> %(contents) is empty.
Doh, that string_list behavior is what I was missing in my earlier
comments. I agree this is probably the best way of doing it. I'm tempted
to say that parse_ref_filter_atom() should do a similar thing. Right now
we've got:
$ git for-each-ref --format='%(refname)' | wc
2206 2206 79929
$ git for-each-ref --format='%(refname:short)' | wc
2206 2206 53622
$ git for-each-ref --format='%(refname:)' | wc
fatal: unrecognized %(refname:) argument:
0 0 0
which seems a bit unfriendly. As we're on v6 here, I don't want to
suggest it as part of this series. But maybe a #leftoverbits candidate,
if others agree it's a good direction.
-Peff
^ permalink raw reply [relevance 6%]
* RE: Is finalize_object_file in sha1_file.c handling errno from "rename" correctly?
2017-09-15 18:18 5% ` Wesley Smith
@ 2017-09-29 23:21 0% ` Johannes Schindelin
0 siblings, 0 replies; 114+ results
From: Johannes Schindelin @ 2017-09-29 23:21 UTC (permalink / raw)
To: Wesley Smith; +Cc: Junio C Hamano, git@vger.kernel.org
Hi,
On Fri, 15 Sep 2017, Wesley Smith wrote:
> Thanks for your response. I'm glad to see that you've been able to understand the problem. I'm working with the Windows git team to properly return EACCESS when "rename" fails due to access permissions, but it also sounds like there will need to be a fix to finalize_object_file to better handle the case of an existing file when renaming.
The Windows part of the problem was fixed in v2.14.2.
Ciao,
Johannes
[ leaving the rest of the quoted mail intact intentionally, to give
readers a chance to read up on the context ]
> Wesley Smith
> T: 503.597.0556 | WSMITH@GREATERGIVING.COM
>
> -----Original Message-----
> From: Junio C Hamano [mailto:gitster@pobox.com]
> Sent: Thursday, September 14, 2017 11:51 PM
> To: Wesley Smith
> Cc: git@vger.kernel.org
> Subject: Re: Is finalize_object_file in sha1_file.c handling errno from "rename" correctly?
>
> Wesley Smith <wsmith@greatergiving.com> writes:
>
> > 1) This bug is triggered because "git fetch" is causing a pack file to
> > be written when that same pack file already exists. It seems like
> > this is harmless and shouldn't cause a problem. Is that correct?
>
> The final name of the packfile is derived from the entire contents of the packfile; it should be harmless when we attempt to rename a new file, which has exactly the same contents as an existing file, to the existing file and see a failure out of that attempt.
>
> > 2) It seems that finalize_object_file is not accounting for the fact
> > that "link" will return EEXIST if the destination file already exists
> > but is not writeable, whereas "rename" will return EACCESS in this
> > case. Is that correct? If so, should finalize_object_file be fixed
> > to account for this? Perhaps it should check if the newfile exists
> > before calling rename. Or, should the Windows mingw_rename function
> > be modified to return EEXIST in this case, even though that's not the
> > standard errno for that situation?
>
> The codepath that is triggered by OBJECT_CREATION_USES_RENAMES ought to behave correctly even on non-Windows platforms, so bending the error code of rename() only on Windows to fit the existing error handling would not be a smart thing to do. Rather, the rename() emulation should leave a correct errno and the caller should be updated to be aware of that error that is not EEXIST, which it currently knows about.
>
> Thanks for spotting a problem and digging to its cause.
>
> This is a #leftoverbits tangent, and should be done separately from your "OBJECT_CREATION_USES_RENAMES is broken" topic, but I think it is a bug to use finalize_object_file() directly to "finalize"
> anything but an individual loose object file in the first place.
>
> We should create a new shared helper that does what the function currently does, make finalize_object_file() call that new shared helper, and make sure finalize_object_file() is called only on a newly created loose object file. The codepath that creates a new packfile and other things and moves them to the final name should not call finalize_object_file() but the new shared helper instead.
>
> That way, we could later implement the "collision? check" alluded by the in-code comment in finailize_object_file(), and we won't have to worry about affecting callers other than the one that creates a loose object file with such an enhancement.
>
>
^ permalink raw reply [relevance 0%]
* Re: [PATCH 1/3] validate_headref: NUL-terminate HEAD buffer
2017-09-27 7:06 6% ` Junio C Hamano
@ 2017-09-27 7:16 0% ` Jeff King
0 siblings, 0 replies; 114+ results
From: Jeff King @ 2017-09-27 7:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
On Wed, Sep 27, 2017 at 04:06:22PM +0900, Junio C Hamano wrote:
> A few tangents I noticed:
>
> - the result of readlink should be checked with starts_with() in
> the modern codebase (#leftoverbits).
Yes, though it needs to NUL-terminate, too (readlink does not do so
automatically). Again, we seem to have left room for the NUL but didn't
bother to put it there.
> - buffer[256] would mean that we cannot have a branch whose name is
> more than a couple of hundred bytes long; as you said, we may be
> better off using strbuf_read to read the whole thing.
Heh, I almost talked about this in the cover letter, but didn't want to
go off on a tangent. But since you mention it...
I had the same concern, but actually truncation is not a problem here
(for a symlink or a symref). We are only seeing if the contents look
vaguely correct, so really we never parse past "refs/" in either case.
The real symref resolution happens in refs/files-backend.c these days,
and does use a strbuf.
-Peff
^ permalink raw reply [relevance 0%]
* Re: [PATCH 1/3] validate_headref: NUL-terminate HEAD buffer
@ 2017-09-27 7:06 6% ` Junio C Hamano
2017-09-27 7:16 0% ` Jeff King
0 siblings, 1 reply; 114+ results
From: Junio C Hamano @ 2017-09-27 7:06 UTC (permalink / raw)
To: Jeff King; +Cc: git
Jeff King <peff@peff.net> writes:
> diff --git a/path.c b/path.c
> index b533ec938d..3e4d7505ef 100644
> --- a/path.c
> +++ b/path.c
> @@ -662,6 +662,10 @@ int validate_headref(const char *path)
> len = read_in_full(fd, buffer, sizeof(buffer)-1);
> close(fd);
>
> + if (len < 0)
> + return -1;
> + buffer[len] = '\0';
> +
> /*
> * Is it a symbolic ref?
> */
A few tangents I noticed:
- the result of readlink should be checked with starts_with() in
the modern codebase (#leftoverbits).
- buffer[256] would mean that we cannot have a branch whose name is
more than a couple of hundred bytes long; as you said, we may be
better off using strbuf_read to read the whole thing.
Neither should be touched by this patch, of course.
Thanks.
^ permalink raw reply [relevance 6%]
* Re: -X theirs does not resolve symlink conflict Was: BUG: merge -s theirs is not in effect
2017-09-26 2:39 6% ` Junio C Hamano
@ 2017-09-26 13:37 0% ` Yaroslav Halchenko
0 siblings, 0 replies; 114+ results
From: Yaroslav Halchenko @ 2017-09-26 13:37 UTC (permalink / raw)
To: git@vger.kernel.org
On Tue, 26 Sep 2017, Junio C Hamano wrote:
> >> I do not recall people talking about symbolic links but the case of
> >> binary files has been on the wishlist for a long time, and I do not
> >> know of anybody who is working on (or is planning to work on) it.
> > Ah, I misremembered.
> > We've addressed the "binary files" case back in 2012 with a944af1d
> > ("merge: teach -Xours/-Xtheirs to binary ll-merge driver",
> > 2012-09-08). I do not know offhand if it is just as easy to plumb
> > the MERGE_FAVOR_{OURS,THEIRS} bits thru the symbolic link codepath,
> > like that patch did to the binary file codepath.
> Perhaps the attached (totally untested) patch might be a good
> starting point. I do not know if you are interested in hacking on
> Git, and I do not feel offended if you are not, but perhaps somebody
I would have felt honored to "hack on Git" but neither my C-foo is up to
par, neither there would be more time I could adequately allocate for
such endeavor. So meanwhile I am trying to contribute in hopefully
constructive "whining" while exploiting git.
> else might get interested in seeing if this #leftoverbits is a good
> direction to go in, and finishing it with docs and tests if it is
> ;-)
> merge-recursive.c | 17 +++++++++++++----
> 1 file changed, 13 insertions(+), 4 deletions(-)
> >...<
This patch worked beautifully in my usecase!:
$> rm -rf /tmp/repo1; mkdir /tmp/repo1; cd /tmp/repo1; git init .; ln -s sym1 link; echo 1 > file; git add file link; git commit -m 'common'; git co -b b1 ; ln -sf b1link link; echo "b1 file" >| file; git commit -m 'b2 changes' -a; git co master; ln -sf masterlink link; echo "master file" >| file; git commit -m 'also modified in master' -a; git merge -X theirs --no-edit b1; ls -l link; cat file
warning: templates not found /home/yoh/share/git-core/templates
Initialized empty Git repository in /tmp/repo1/.git/
[master (root-commit) d2e9010] common
2 files changed, 2 insertions(+)
create mode 100644 file
create mode 120000 link
Switched to a new branch 'b1'
[b1 a2b1321] b2 changes
2 files changed, 2 insertions(+), 2 deletions(-)
Switched to branch 'master'
[master fbb4ba7] also modified in master
2 files changed, 2 insertions(+), 2 deletions(-)
Auto-merging link
Auto-merging file
Merge made by the 'recursive' strategy.
file | 2 +-
link | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
lrwxrwxrwx 1 yoh yoh 6 Sep 26 09:32 link -> b1link
b1 file
I also tried -s ours and no explicit -s, and they did as prescribed as
well
PS thanks for the CCs
--
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419
WWW: http://www.linkedin.com/in/yarik
^ permalink raw reply [relevance 0%]
* Re: -X theirs does not resolve symlink conflict Was: BUG: merge -s theirs is not in effect
@ 2017-09-26 2:39 6% ` Junio C Hamano
2017-09-26 13:37 0% ` Yaroslav Halchenko
0 siblings, 1 reply; 114+ results
From: Junio C Hamano @ 2017-09-26 2:39 UTC (permalink / raw)
To: Yaroslav Halchenko; +Cc: git@vger.kernel.org
Junio C Hamano <gitster@pobox.com> writes:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> I do not recall people talking about symbolic links but the case of
>> binary files has been on the wishlist for a long time, and I do not
>> know of anybody who is working on (or is planning to work on) it.
>
> Ah, I misremembered.
>
> We've addressed the "binary files" case back in 2012 with a944af1d
> ("merge: teach -Xours/-Xtheirs to binary ll-merge driver",
> 2012-09-08). I do not know offhand if it is just as easy to plumb
> the MERGE_FAVOR_{OURS,THEIRS} bits thru the symbolic link codepath,
> like that patch did to the binary file codepath.
Perhaps the attached (totally untested) patch might be a good
starting point. I do not know if you are interested in hacking on
Git, and I do not feel offended if you are not, but perhaps somebody
else might get interested in seeing if this #leftoverbits is a good
direction to go in, and finishing it with docs and tests if it is
;-)
merge-recursive.c | 17 +++++++++++++----
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/merge-recursive.c b/merge-recursive.c
index 1d3f8f0d22..3605275ca3 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -1026,10 +1026,19 @@ static int merge_file_1(struct merge_options *o,
&b->oid,
!o->call_depth);
} else if (S_ISLNK(a->mode)) {
- oidcpy(&result->oid, &a->oid);
-
- if (!oid_eq(&a->oid, &b->oid))
- result->clean = 0;
+ switch (o->recursive_variant) {
+ case MERGE_RECURSIVE_NORMAL:
+ oidcpy(&result->oid, &a->oid);
+ if (!oid_eq(&a->oid, &b->oid))
+ result->clean = 0;
+ break;
+ case MERGE_RECURSIVE_OURS:
+ oidcpy(&result->oid, &a->oid);
+ break;
+ case MERGE_RECURSIVE_THEIRS:
+ oidcpy(&result->oid, &b->oid);
+ break;
+ }
} else
die("BUG: unsupported object type in the tree");
}
^ permalink raw reply related [relevance 6%]
* Re: [PATCH v2 4/6] object_array: use `object_array_clear()`, not `free()`
@ 2017-09-23 4:04 5% ` Jeff King
0 siblings, 0 replies; 114+ results
From: Jeff King @ 2017-09-23 4:04 UTC (permalink / raw)
To: Martin Ågren; +Cc: git
On Sat, Sep 23, 2017 at 01:34:52AM +0200, Martin Ågren wrote:
> Instead of freeing `foo.objects` for an object array `foo` (sometimes
> conditionally), call `object_array_clear(&foo)`. This means we don't
> poke as much into the implementation, which is already a good thing, but
> also that we release the individual entries as well, thereby fixing at
> least one memory-leak (in diff-lib.c).
>
> If someone is holding on to a pointer to an element's `name` or `path`,
> that is now a dangling pointer, i.e., we'd be turning an unpleasant
> situation into an outright bug. To the best of my understanding no such
> long-term pointers are being taken.
It would be nice if we had a good way to verify this automatically, but
I couldn't think of one. It passes the test suite with ASan, but of
course our coverage is not 100%.
We do know a few things:
1. Any caller which keeps a pointer to the object-entries themselves
is already broken, since we free that already. We only have to care
about the name and path strings.
2. Any caller which uses add_object_array() has a NULL path, so we
don't have to worry about leaving that dangling.
3. Most of the callers outside of revision.c use a NULL name argument,
as well.
So let's see:
> diff --git a/builtin/reflog.c b/builtin/reflog.c
> index e237d927a..6b34f23e7 100644
> --- a/builtin/reflog.c
> +++ b/builtin/reflog.c
> @@ -182,8 +182,8 @@ static int commit_is_complete(struct commit *commit)
> found.objects[i].item->flags |= SEEN;
> }
> /* free object arrays */
> - free(study.objects);
> - free(found.objects);
> + object_array_clear(&study);
> + object_array_clear(&found);
> return !is_incomplete;
> }
These ones always have NULL names and paths, so are good.
(An orthogonal low-hanging fruit: these probably ought to use
OBJECT_ARRAY_INIT instead of memset. Maybe a good #leftoverbits for some
of the Outreachy applicants).
> diff --git a/diff-lib.c b/diff-lib.c
> index 2a52b0795..4e0980caa 100644
> --- a/diff-lib.c
> +++ b/diff-lib.c
> @@ -549,7 +549,6 @@ int index_differs_from(const char *def, int diff_flags,
> rev.diffopt.flags |= diff_flags;
> rev.diffopt.ita_invisible_in_index = ita_invisible_in_index;
> run_diff_index(&rev, 1);
> - if (rev.pending.alloc)
> - free(rev.pending.objects);
> + object_array_clear(&rev.pending);
> return (DIFF_OPT_TST(&rev.diffopt, HAS_CHANGES) != 0);
> }
This one gets the entries from setup_revisions(), so they may have
actual names. It calls diff_flush() before the clear, though, so I'm
pretty sure we would have dropped any queued entries (and I'm also
pretty sure that the queued entries make their own copies of any names
anyway). So this one isn't trivial, but I think it's fine.
> diff --git a/submodule.c b/submodule.c
> index 36f45f5a5..79fd01f7b 100644
> --- a/submodule.c
> +++ b/submodule.c
> @@ -1728,7 +1728,7 @@ static int find_first_merges(struct object_array *result, const char *path,
> add_object_array(merges.objects[i].item, NULL, result);
> }
>
> - free(merges.objects);
> + object_array_clear(&merges);
> return result->nr;
> }
Another always-NULL case.
> @@ -1833,7 +1833,7 @@ int merge_submodule(struct object_id *result, const char *path,
> print_commit((struct commit *) merges.objects[i].item);
> }
>
> - free(merges.objects);
> + object_array_clear(&merges);
> return 0;
> }
This one is fed by the "result" array of find_first_merges(), which is
also always-NULL.
> diff --git a/upload-pack.c b/upload-pack.c
> index 7efff2fbf..ec0eee8fc 100644
> --- a/upload-pack.c
> +++ b/upload-pack.c
> @@ -888,7 +888,7 @@ static void receive_needs(void)
> }
>
> shallow_nr += shallows.nr;
> - free(shallows.objects);
> + object_array_clear(&shallows);
> }
Also always NULL.
So I think all of these cases are good (and weren't actually leaking in
the first place, since the only thing to get rid of was the entries
themselves).
> The way we handle `study` in builting/reflog.c still looks like it might
> leak. That will be addressed in the next commit.
This confused me for a minute, since the leak is not visible in the
context. ;) But reading the next commit, it makes sense.
-Peff
^ permalink raw reply [relevance 5%]
* Re: My first contribution. Outreachy
[not found] <CAL21Bm=zQ2ADTOSVk5kL1q=VyLV91J+VbsLLFbSdgPxeg3FW1g@mail.gmail.com>
@ 2017-09-21 5:30 7% ` Jeff King
0 siblings, 0 replies; 114+ results
From: Jeff King @ 2017-09-21 5:30 UTC (permalink / raw)
To: Оля Тележная
Cc: Christian Couder, git
[Note that your email didn't make it to the mailing list because it
was formatted as HTML. You may want to tweak your gmail settings to
send plain text. Those of us on the to/cc did get it, though].
On Tue, Sep 19, 2017 at 03:45:18PM +0300, Оля Тележная wrote:
> If you could help me with choosing my first task and give some
> thoughts about where to look to solve the problem - that would be
> great.
Here are a few possibilities:
- The task mentioned in:
https://public-inbox.org/git/20170912172839.GB144745@aiede.mtv.corp.google.com/
to convert the ad-hoc doubly-linked list implementation used in
mru.c and mru.h to use the implementation from list.h.
Note that I've pointed a few other people at this task, so you may
find other candidates working on it, too (and it's possible if we
get multiple good versions submitted yours might not get applied; I
still think it's a good simple task that will help get you familiar
with writing and submitting a patch).
- We've been working with some leak-checking tools lately to try to
find memory leaks in Git by running the test suite. You can see some
example patches:
https://public-inbox.org/git/1505936846-2195-1-git-send-email-martin.agren@gmail.com/
https://public-inbox.org/git/1505936846-2195-2-git-send-email-martin.agren@gmail.com/
https://public-inbox.org/git/1505936846-2195-3-git-send-email-martin.agren@gmail.com/
You can find more instances by building with the leak-checker
(you'll need to have a recent version of gcc or clang as your
compiler):
make SANITIZE=leak
and then running individual test scripts, seeing what fails, and
investigating the leak-checker output. There's a bit more discussion
in the cover letter here:
https://public-inbox.org/git/20170905130149.agc3zp3s6i6e5aki@sigill.intra.peff.net/
Even though the patches are relatively small, there are a lot of
things to learn here about building Git and running the tests. Don't
hesitate to ask if you get stuck.
- We've started marking small unfinished tasks with the
"#leftoverbits" tag in emails, which can then be searched in the
mailing list archive:
https://public-inbox.org/git/?q=leftoverbits
We don't use a formal bug-tracker, so this is a good way of seeing
which discussions people feel newcomers may be able to jump in on.
You may need to read the surrounding thread to get context, but
again, don't hesitate to ask if you need help figuring out exactly
what the task is or how it should be done.
-Peff
^ permalink raw reply [relevance 7%]
* Re: My first contribution
[not found] <CAL21Bm=e9C4ANTsc4n1BG3xqjCJmORDSPcS5QEXYKUkK3cAH6w@mail.gmail.com>
@ 2017-09-19 8:05 7% ` Christian Couder
0 siblings, 0 replies; 114+ results
From: Christian Couder @ 2017-09-19 8:05 UTC (permalink / raw)
To: Оля Тележная
Cc: Jeff King, git
Hi Olga,
On Tue, Sep 19, 2017 at 8:44 AM, Оля Тележная <olyatelezhnaya@gmail.com> wrote:
> Hello Jeff,
> I want to try myself into new role of a Git contributor.
Welcome to Git!
> All of the projects sound super interesting for me and I am ready to take
> part in all of them, but the project "Unifying Git's format languages" will
> be super useful for me myself, so my dream is to try solve that task first.
Great that you found a project you like!
> I need help to choose my first task in the project, because first steps are
> usually the most frightening.
> I am familiar enough with C and there's no problem to read any docs, but
> please help me choosing the first task. If you have any guidance like "how
> to start" or "how to choose tasks", please send that links also.
You can try to work first on the project you are interested in or you
can find and work on a small project first.
One way to find a small project is to see what people are
talking about on the mailing list[1]. Quite often there are bugs
that can be fixed, and more experienced people may help sketch out
a solution. You can also find small items good for newcomers marked
with the "leftoverbits" tag, which you can search for in the
mailing list[2].
We don't have a written guide specifically downloading git, getting it
built, running the tests, and so forth, but you might start with:
git clone https://github.com/git/git
and reading the INSTALL file.
As the mailing list can be a bit intimidating at first, we don't mind
working with you one-on-one a bit during the application period.
About the mailing list, please add [Outreachy] in the subject to make
it clear that you are applying for the Outreachy program.
While at it on the Git mailing list we are used to replying to parts
of message after those parts. We don't usually reply before the
message. In other words we are used to "inline replying", not "top
posting" (see https://en.wikipedia.org/wiki/Posting_style). Please try
to use the same posting style as us, it will help keep discussions
more standard and easier to understand.
Also we feel free to remove parts of the messages we are quoting that
are not relevant anymore.
For getting in touch with us, direct email is our preferred method. We
could also meet on IRC if you like, but it looks like our timezones
might not overlap much. Still, we can probably set up a time.
Let us know if you have any questions at all. This is our first time
mentoring for Outreachy, so we've surely forgotten to mention some
obvious thing you would want to know. :)
Thanks,
Christian.
[1] There are details of the list at https://git-scm.com/community,
but you may want to just browse the archive at:
https://public-inbox.org/git
[2] https://public-inbox.org/git/?q=leftoverbits
^ permalink raw reply [relevance 7%]
* Re: [OUTREACHY] pack: make packed_git_mru global a value instead of a pointer
@ 2017-09-19 5:20 6% ` Jeff King
0 siblings, 0 replies; 114+ results
From: Jeff King @ 2017-09-19 5:20 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: phionah bugosi, git
On Mon, Sep 18, 2017 at 04:17:24PM -0700, Jonathan Nieder wrote:
> phionah bugosi wrote:
>
> > Just to reecho a previous change requested before in one of the mail
> > threads, we currently have two global variables declared:
> >
> > struct mru packed_git_mru_storage;
> > struct mru *packed_git_mru = &packed_git_mru_storage;
> >
> > We normally use pointers in C to point or refer to the same location
> > or space in memory from multiple places. That means in situations
> > where we will have the pointer be assigned to in many places in our
> > code. But in this case, we do not have any other logic refering or
> > assigning to the pointer packed_git_mru. In simple words we actually
> > dont need a pointer in this case.
> >
> > Therefore this patch makes packed_git_mru global a value instead of
> > a pointer and makes use of list.h
> >
> > Signed-off-by: phionah bugosi <bugosip@gmail.com>
> > ---
> > builtin/pack-objects.c | 5 +++--
> > cache.h | 7 -------
> > list.h | 6 ++++++
> > packfile.c | 12 ++++++------
> > 4 files changed, 15 insertions(+), 15 deletions(-)
>
> *puzzled* This appears to already be in "pu", with a different author.
> Did you independently make the same change? Or are you asking for a
> progress report on that change, and just phrasing it in a confusing
> way?
I pointed Phionah at your #leftoverbits comment in:
https://public-inbox.org/git/20170912172839.GB144745@aiede.mtv.corp.google.com/
about moving packed_git_mru to list.h. But I'm afraid I wasn't very
clear in giving further guidance.
The goal is to build on _top_ of the patch in that message, and convert
the doubly-linked list implementation used in "struct mru" to use the
shared code in list.h. That should mostly involve touching mru.c and
mru.h, though I think we'd need to tweak the name of the "next" pointer
during the traversal, too.
-Peff
^ permalink raw reply [relevance 6%]
* RE: Is finalize_object_file in sha1_file.c handling errno from "rename" correctly?
2017-09-15 6:50 5% ` Junio C Hamano
@ 2017-09-15 18:18 5% ` Wesley Smith
2017-09-29 23:21 0% ` Johannes Schindelin
0 siblings, 1 reply; 114+ results
From: Wesley Smith @ 2017-09-15 18:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git@vger.kernel.org
Junio,
Thanks for your response. I'm glad to see that you've been able to understand the problem. I'm working with the Windows git team to properly return EACCESS when "rename" fails due to access permissions, but it also sounds like there will need to be a fix to finalize_object_file to better handle the case of an existing file when renaming.
Wesley Smith
T: 503.597.0556 | WSMITH@GREATERGIVING.COM
-----Original Message-----
From: Junio C Hamano [mailto:gitster@pobox.com]
Sent: Thursday, September 14, 2017 11:51 PM
To: Wesley Smith
Cc: git@vger.kernel.org
Subject: Re: Is finalize_object_file in sha1_file.c handling errno from "rename" correctly?
Wesley Smith <wsmith@greatergiving.com> writes:
> 1) This bug is triggered because "git fetch" is causing a pack file to
> be written when that same pack file already exists. It seems like
> this is harmless and shouldn't cause a problem. Is that correct?
The final name of the packfile is derived from the entire contents of the packfile; it should be harmless when we attempt to rename a new file, which has exactly the same contents as an existing file, to the existing file and see a failure out of that attempt.
> 2) It seems that finalize_object_file is not accounting for the fact
> that "link" will return EEXIST if the destination file already exists
> but is not writeable, whereas "rename" will return EACCESS in this
> case. Is that correct? If so, should finalize_object_file be fixed
> to account for this? Perhaps it should check if the newfile exists
> before calling rename. Or, should the Windows mingw_rename function
> be modified to return EEXIST in this case, even though that's not the
> standard errno for that situation?
The codepath that is triggered by OBJECT_CREATION_USES_RENAMES ought to behave correctly even on non-Windows platforms, so bending the error code of rename() only on Windows to fit the existing error handling would not be a smart thing to do. Rather, the rename() emulation should leave a correct errno and the caller should be updated to be aware of that error that is not EEXIST, which it currently knows about.
Thanks for spotting a problem and digging to its cause.
This is a #leftoverbits tangent, and should be done separately from your "OBJECT_CREATION_USES_RENAMES is broken" topic, but I think it is a bug to use finalize_object_file() directly to "finalize"
anything but an individual loose object file in the first place.
We should create a new shared helper that does what the function currently does, make finalize_object_file() call that new shared helper, and make sure finalize_object_file() is called only on a newly created loose object file. The codepath that creates a new packfile and other things and moves them to the final name should not call finalize_object_file() but the new shared helper instead.
That way, we could later implement the "collision? check" alluded by the in-code comment in finailize_object_file(), and we won't have to worry about affecting callers other than the one that creates a loose object file with such an enhancement.
^ permalink raw reply [relevance 5%]
* Re: Is finalize_object_file in sha1_file.c handling errno from "rename" correctly?
@ 2017-09-15 6:50 5% ` Junio C Hamano
2017-09-15 18:18 5% ` Wesley Smith
0 siblings, 1 reply; 114+ results
From: Junio C Hamano @ 2017-09-15 6:50 UTC (permalink / raw)
To: Wesley Smith; +Cc: git@vger.kernel.org
Wesley Smith <wsmith@greatergiving.com> writes:
> 1) This bug is triggered because "git fetch" is causing a pack
> file to be written when that same pack file already exists. It
> seems like this is harmless and shouldn't cause a problem. Is
> that correct?
The final name of the packfile is derived from the entire contents
of the packfile; it should be harmless when we attempt to rename a
new file, which has exactly the same contents as an existing file,
to the existing file and see a failure out of that attempt.
> 2) It seems that finalize_object_file is not accounting for the
> fact that "link" will return EEXIST if the destination file
> already exists but is not writeable, whereas "rename" will return
> EACCESS in this case. Is that correct? If so, should
> finalize_object_file be fixed to account for this? Perhaps it
> should check if the newfile exists before calling rename. Or,
> should the Windows mingw_rename function be modified to return
> EEXIST in this case, even though that's not the standard errno for
> that situation?
The codepath that is triggered by OBJECT_CREATION_USES_RENAMES ought
to behave correctly even on non-Windows platforms, so bending the
error code of rename() only on Windows to fit the existing error
handling would not be a smart thing to do. Rather, the rename()
emulation should leave a correct errno and the caller should be
updated to be aware of that error that is not EEXIST, which it
currently knows about.
Thanks for spotting a problem and digging to its cause.
This is a #leftoverbits tangent, and should be done separately from
your "OBJECT_CREATION_USES_RENAMES is broken" topic, but I think it
is a bug to use finalize_object_file() directly to "finalize"
anything but an individual loose object file in the first place.
We should create a new shared helper that does what the function
currently does, make finalize_object_file() call that new shared
helper, and make sure finalize_object_file() is called only on a
newly created loose object file. The codepath that creates a new
packfile and other things and moves them to the final name should
not call finalize_object_file() but the new shared helper instead.
That way, we could later implement the "collision? check" alluded by
the in-code comment in finailize_object_file(), and we won't have to
worry about affecting callers other than the one that creates a
loose object file with such an enhancement.
^ permalink raw reply [relevance 5%]
* [PATCH 1/4] pack: make packed_git_mru global a value instead of a pointer
@ 2017-09-12 17:28 4% ` Jonathan Nieder
0 siblings, 0 replies; 114+ results
From: Jonathan Nieder @ 2017-09-12 17:28 UTC (permalink / raw)
To: git; +Cc: Stefan Beller, Jeff King, Junio C Hamano
The MRU cache that keeps track of recently used packs is represented
using two global variables:
struct mru packed_git_mru_storage;
struct mru *packed_git_mru = &packed_git_mru_storage;
Callers never assign to the packed_git_mru pointer, though, so we can
simplify by eliminating it and using &packed_git_mru_storage (renamed
to &packed_git_mru) directly. This variable is only used by the
packfile subsystem, making this a relatively uninvasive change (and
any new unadapted callers would trigger a compile error).
Noticed while moving these globals to the object_store struct.
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Acked-by: Jeff King <peff@peff.net>
---
Unchanged from
https://public-inbox.org/git/20170830064827.GB153983@aiede.mtv.corp.google.com/.
I agree with the comments there that it would be nice to make this use
list.h (#leftoverbits) and would be happy to read a patch doing that.
Once we're done adapting the object store to work with arbitrary
repositories we may come back to this, but I'd be happier if it's just
already taken care of for us.
builtin/pack-objects.c | 4 ++--
cache.h | 4 ++--
packfile.c | 12 +++++-------
3 files changed, 9 insertions(+), 11 deletions(-)
diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c
index a57b4f058d..f721137eaf 100644
--- a/builtin/pack-objects.c
+++ b/builtin/pack-objects.c
@@ -1012,7 +1012,7 @@ static int want_object_in_pack(const unsigned char *sha1,
return want;
}
- for (entry = packed_git_mru->head; entry; entry = entry->next) {
+ for (entry = packed_git_mru.head; entry; entry = entry->next) {
struct packed_git *p = entry->item;
off_t offset;
@@ -1030,7 +1030,7 @@ static int want_object_in_pack(const unsigned char *sha1,
}
want = want_found_object(exclude, p);
if (!exclude && want > 0)
- mru_mark(packed_git_mru, entry);
+ mru_mark(&packed_git_mru, entry);
if (want != -1)
return want;
}
diff --git a/cache.h b/cache.h
index a916bc79e3..49b083ee0a 100644
--- a/cache.h
+++ b/cache.h
@@ -4,6 +4,7 @@
#include "git-compat-util.h"
#include "strbuf.h"
#include "hashmap.h"
+#include "mru.h"
#include "advice.h"
#include "gettext.h"
#include "convert.h"
@@ -1589,8 +1590,7 @@ extern struct packed_git {
* A most-recently-used ordered version of the packed_git list, which can
* be iterated instead of packed_git (and marked via mru_mark).
*/
-struct mru;
-extern struct mru *packed_git_mru;
+extern struct mru packed_git_mru;
struct pack_entry {
off_t offset;
diff --git a/packfile.c b/packfile.c
index f86fa051c9..f69a5c8d60 100644
--- a/packfile.c
+++ b/packfile.c
@@ -40,9 +40,7 @@ static unsigned int pack_max_fds;
static size_t peak_pack_mapped;
static size_t pack_mapped;
struct packed_git *packed_git;
-
-static struct mru packed_git_mru_storage;
-struct mru *packed_git_mru = &packed_git_mru_storage;
+struct mru packed_git_mru;
#define SZ_FMT PRIuMAX
static inline uintmax_t sz_fmt(size_t s) { return s; }
@@ -861,9 +859,9 @@ static void prepare_packed_git_mru(void)
{
struct packed_git *p;
- mru_clear(packed_git_mru);
+ mru_clear(&packed_git_mru);
for (p = packed_git; p; p = p->next)
- mru_append(packed_git_mru, p);
+ mru_append(&packed_git_mru, p);
}
static int prepare_packed_git_run_once = 0;
@@ -1832,9 +1830,9 @@ int find_pack_entry(const unsigned char *sha1, struct pack_entry *e)
if (!packed_git)
return 0;
- for (p = packed_git_mru->head; p; p = p->next) {
+ for (p = packed_git_mru.head; p; p = p->next) {
if (fill_pack_entry(sha1, e, p->item)) {
- mru_mark(packed_git_mru, p);
+ mru_mark(&packed_git_mru, p);
return 1;
}
}
--
2.14.1.690.gbb1197296e
^ permalink raw reply related [relevance 4%]
* Re: [PATCH 4/4] imap-send: use curl by default
2017-09-12 7:02 0% ` Junio C Hamano
@ 2017-09-12 8:24 0% ` Nicolas Morey-Chaisemartin
0 siblings, 0 replies; 114+ results
From: Nicolas Morey-Chaisemartin @ 2017-09-12 8:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git
Le 12/09/2017 à 09:02, Junio C Hamano a écrit :
> Junio C Hamano <gitster@pobox.com> writes:
>
>> I was sweeping my mailbox to collect loose ends that haven't been
>> tied down, and noticed that this topic does not seem to have reached
>> a conclusion. Do we want to reboot the effort? Or should we just
>> throw it in the #leftoverbits bin for now?
> Ahh, I failed to find newer incarnations of this topic (there was v3 that
> starts at <087f5907-6558-ce32-2f5c-2e418522c030@morey-chaisemartin.com>)
> when I wrote it. Sorry about pinging a wrong/old article.
>
> I just gave a cursory re-read of the review thread over the v3
> series; it appears that we were very close to the finishing line
> already?
>
> Or am I yet missing/forgetting some later developments that made
> this topic obsolete?
>
> Thanks.
>
v3 needs just a few bits fixed:
- Fix the bads return code in patch #1.
- Reword patch #4 was you found confusing. I sent a proposal fix that you probably missed:
Is something like this clearer ?
Author: Nicolas Morey-Chaisemartin <nicolas@morey-chaisemartin.com>
Date: Sun Aug 6 21:30:15 2017 +0200
imap-send: use curl by default when possible
Set curl as the runtime default when it is available.
When linked against older curl versions (< 7_34_0) or without curl,
use the legacy imap implementation.
The goal is to validate feature parity between the legacy and
the curl implementation, deprecate the legacy implementation
later on and in the long term, hopefully drop it altogether.
Signed-off-by: Nicolas Morey-Chaisemartin <nicolas@morey-chaisemartin.com>
If you're happy with this log message, I've v4 ready to post.
Nicolas
^ permalink raw reply [relevance 0%]
* Re: [PATCH 4/4] imap-send: use curl by default
2017-09-12 6:46 6% ` Junio C Hamano
@ 2017-09-12 7:02 0% ` Junio C Hamano
2017-09-12 8:24 0% ` Nicolas Morey-Chaisemartin
0 siblings, 1 reply; 114+ results
From: Junio C Hamano @ 2017-09-12 7:02 UTC (permalink / raw)
To: Nicolas Morey-Chaisemartin; +Cc: Jeff King, git
Junio C Hamano <gitster@pobox.com> writes:
> I was sweeping my mailbox to collect loose ends that haven't been
> tied down, and noticed that this topic does not seem to have reached
> a conclusion. Do we want to reboot the effort? Or should we just
> throw it in the #leftoverbits bin for now?
Ahh, I failed to find newer incarnations of this topic (there was v3 that
starts at <087f5907-6558-ce32-2f5c-2e418522c030@morey-chaisemartin.com>)
when I wrote it. Sorry about pinging a wrong/old article.
I just gave a cursory re-read of the review thread over the v3
series; it appears that we were very close to the finishing line
already?
Or am I yet missing/forgetting some later developments that made
this topic obsolete?
Thanks.
^ permalink raw reply [relevance 0%]
* Re: [PATCH v3 1/2 / RFC] builtin/branch: stop supporting the use of --set-upstream option
2017-09-12 6:49 6% ` Junio C Hamano
@ 2017-09-12 7:00 0% ` Kaartic Sivaraam
0 siblings, 0 replies; 114+ results
From: Kaartic Sivaraam @ 2017-09-12 7:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, martin.agren
On Tue, 2017-09-12 at 15:49 +0900, Junio C Hamano wrote:
> Kaartic Sivaraam <kaarticsivaraam91196@gmail.com> writes:
>
> > Thanks. Now I get it. What about doing that check in
> > branch.c::create_branch or branch.c::validate_new_branchname? I guess
> > creating a branch named HEAD isn't that good an idea in any case. Doing
> > the check there might prevent a similar situation in future, I guess.
> > Further "branch" and "checkout" do call branch.c::create_branch which
> > in turn calls branch.c::validate_new_branchname.
>
> The above analysis sounds sensible, so it appears that you already
> found a function that is shared in the two codepaths, and have a
> good plan to make them consistent?
>
Yes, I was just waiting for this reply. In the mean time I thought of
sending a patch for this but was procrastinating as I felt a little
lazy.
> I was sweeping my mailbox to collect loose ends that haven't been
> tied down, and noticed that this topic does not seem to reach a
> conclusion. Do we want to reboot the effort? Or should we just
> throw it in the #leftoverbits bin for now?
>
Don't worry I'll send a patch for this, soon. I mean it :)
--
Kaartic
^ permalink raw reply [relevance 0%]
* Re: Suggestion: better error message when an ambiguous checkout is executed
@ 2017-09-12 6:53 6% ` Junio C Hamano
0 siblings, 0 replies; 114+ results
From: Junio C Hamano @ 2017-09-12 6:53 UTC (permalink / raw)
To: Mahmoud Al-Qudsi; +Cc: git
Junio C Hamano <gitster@pobox.com> writes:
> Mahmoud Al-Qudsi <mqudsi@neosmart.net> writes:
>
>> The default git behavior when attempting to `git checkout xxx` for
>> some value of "xxx" that cannot be resolved to a single, unique
>> file/path/branch/tag/commit/etc is to display the following:
> ...
> So a possible implementation approach would be
>
> - to let the current code do what it is doing
>
> - except that you add new code immediately before the code that
> issues 'xxx' did not match (i.e. the code already checked that
> 'xxx' taken as a pathspec does not match anything, and about to
> give the error message but hasn't done so just yet).
>
> - your new code
>
> . checks if 'xxx' could be an attempt to refer to a rev but
> insufficiently spelled out (e.g. both origin[12]/xxx exists, or
> for a bonus point, a similarly named origin/xxy exists and
> could be a typo).
>
> . if the above check found something, then you report it and
> terminate without complaining "pathspec 'xxx' did not
> match..."
>
> . on the other hand, if the above check did not find anything,
> then you let the current code issue the same error message as
> before.
I was sweeping my mailbox to collect loose ends that haven't been
tied down, and noticed that this topic does not seem to have reached
a conclusion. Do we want to reboot the effort? Or should we just
throw it in the #leftoverbits bin for now?
Thanks.
^ permalink raw reply [relevance 6%]
* Re: [PATCH v3 1/2 / RFC] builtin/branch: stop supporting the use of --set-upstream option
@ 2017-09-12 6:49 6% ` Junio C Hamano
2017-09-12 7:00 0% ` Kaartic Sivaraam
0 siblings, 1 reply; 114+ results
From: Junio C Hamano @ 2017-09-12 6:49 UTC (permalink / raw)
To: Kaartic Sivaraam; +Cc: git, martin.agren
Kaartic Sivaraam <kaarticsivaraam91196@gmail.com> writes:
> On Wed, 2017-08-16 at 12:09 -0700, Junio C Hamano wrote:
>> You said that "checkout" does not do a necessary check that is done
>> in "branch", so presumably "branch" already has a code to do so that
>> is not called by the current "checkout", right? Then you would add
>> a new caller in "checkout" to trigger the same check that is already
>> done in "branch", but the code "branch" uses _might_ be too specific
>> to the kind of data the current implementation of "branch" uses and
>> it _may_ not be easy to call it directly from "checkout" (I didn't
>> check if that is the case). If so, then the check implemented in
>> the current "branch" may need to be refactored before it can easily
>> be called from the new caller you would be adding to "checkout".
>>
>>
> Thanks. Now I get it. What about doing that check in
> branch.c::create_branch or branch.c::validate_new_branchname? I guess
> creating a branch named HEAD isn't that good an idea in any case. Doing
> the check there might prevent a similar situation in future, I guess.
> Further "branch" and "checkout" do call branch.c::create_branch which
> in turn calls branch.c::validate_new_branchname.
The above analysis sounds sensible, so it appears that you already
found a function that is shared in the two codepaths, and have a
good plan to make them consistent?
I was sweeping my mailbox to collect loose ends that haven't been
tied down, and noticed that this topic does not seem to reach a
conclusion. Do we want to reboot the effort? Or should we just
throw it in the #leftoverbits bin for now?
Thanks.
^ permalink raw reply [relevance 6%]
* Re: [PATCH 4/4] imap-send: use curl by default
@ 2017-09-12 6:46 6% ` Junio C Hamano
2017-09-12 7:02 0% ` Junio C Hamano
0 siblings, 1 reply; 114+ results
From: Junio C Hamano @ 2017-09-12 6:46 UTC (permalink / raw)
To: Nicolas Morey-Chaisemartin, Jeff King; +Cc: git
Jeff King <peff@peff.net> writes:
> On Mon, Aug 07, 2017 at 04:04:05PM +0200, Nicolas Morey-Chaisemartin wrote:
>
>> Signed-off-by: Nicolas Morey-Chaisemartin <nicolas@morey-chaisemartin.com>
>
> Thanks for moving forward with this.
>
> Can you please flesh out your commit messages with some of the reasoning
> and related discussion? I know from a nearby thread why we want to flip
> the default, but people reading `git log` much later will not have that
> context.
> ...
I was sweeping my mailbox to collect loose ends that haven't been
tied down, and noticed that this topic does not seem to reach a
conclusion. Do we want to reboot the effort? Or should we just
throw it in the #leftoverbits bin for now?
Thanks.
^ permalink raw reply [relevance 6%]
* Re: "git shortlog -sn --follow -- <path>" counts all commits to entire repo
2017-09-09 6:52 6% ` Jeff King
@ 2017-09-10 7:36 6% ` Junio C Hamano
0 siblings, 0 replies; 114+ results
From: Junio C Hamano @ 2017-09-10 7:36 UTC (permalink / raw)
To: Jeff King
Cc: Stefan Beller,
Валентин,
git@vger.kernel.org
Jeff King <peff@peff.net> writes:
> On Sat, Sep 09, 2017 at 02:37:20AM +0900, Junio C Hamano wrote:
>
>> Using log-tree traversal machinery instead of just get_revision()
>> would probably mean we would slow it down quite a bit unless we are
>> careful, but at the same time, things like "git shortlog -G<string>"
>> would suddenly start working, so this is not just helping the
>> "--follow" hack.
>
> I didn't notice that, but I'm not surprised that there are more options
> that shortlog doesn't quite work with.
>
> I don't plan on working on this myself any time soon, so maybe it's a
> good #leftoverbits candidate (though it's perhaps a little more involved
> than some).
I agree that I do not mind seeing those who haven't really touched
the inner core of the system to try this change, so marking this
discussion with #leftoverbits may be a good idea, but I have this
gut feeling that "a little more involved" might be a bit of an
understatement ;-)
But still I think it is a very good suggestion to allow log-tree to
filter things more so that "shortlog $args" can become a more
faithful imitation of "log $args | shortlog".
Thanks.
^ permalink raw reply [relevance 6%]
* Re: "git shortlog -sn --follow -- <path>" counts all commits to entire repo
@ 2017-09-09 6:52 6% ` Jeff King
2017-09-10 7:36 6% ` Junio C Hamano
0 siblings, 1 reply; 114+ results
From: Jeff King @ 2017-09-09 6:52 UTC (permalink / raw)
To: Junio C Hamano
Cc: Stefan Beller,
Валентин,
git@vger.kernel.org
On Sat, Sep 09, 2017 at 02:37:20AM +0900, Junio C Hamano wrote:
> > That said, I don't think we can go wrong by making shortlog's traversal
> > more like log's. Any changes we make to --follow will be aimed at and
> > tested with git-log, so the more code they share the more likely it is
> > that shortlog won't bitrot.
>
> Both true.
>
> Using log-tree traversal machinery instead of just get_revision()
> would probably mean we would slow it down quite a bit unless we are
> careful, but at the same time, things like "git shortlog -G<string>"
> would suddenly start working, so this is not just helping the
> "--follow" hack.
I didn't notice that, but I'm not surprised that there are more options
that shortlog doesn't quite work with.
I don't plan on working on this myself any time soon, so maybe it's a
good #leftoverbits candidate (though it's perhaps a little more involved
than some).
-Peff
^ permalink raw reply [relevance 6%]
* Re: [PATCH 01/39] pack: make packed_git_mru global a value instead of a pointer
2017-08-30 19:44 6% ` Jeff King
@ 2017-09-06 19:51 0% ` Junio C Hamano
0 siblings, 0 replies; 114+ results
From: Junio C Hamano @ 2017-09-06 19:51 UTC (permalink / raw)
To: Jeff King; +Cc: Jonathan Nieder, git, Stefan Beller, brian m. carlson
Jeff King <peff@peff.net> writes:
> As an aside, the mru code could probably be simplified a bit by reusing
> the list implementation from list.h (both were added around the same
> time, and it wasn't worth creating a dependency then, but I think list.h
> is useful and here to stay at this point).
>
> It's definitely not critical to put that into this already-large series,
> though. Maybe we can use Junio's #leftoverbits tag. :)
I had the same reaction while reading it; perhaps I should read the
responses from trusted reviewers first before reading the patches
myself ;-)
Thanks.
^ permalink raw reply [relevance 0%]
* [PATCH] parse-options: warn developers on negated options
2017-09-05 21:38 5% ` Junio C Hamano
@ 2017-09-05 23:08 5% ` Stefan Beller
0 siblings, 0 replies; 114+ results
From: Stefan Beller @ 2017-09-05 23:08 UTC (permalink / raw)
To: gitster; +Cc: git, sbeller
When compiling with -DDEVELOPER set (enabled via the Makefile DEVELOPER
switch), inspect options if they are negated and warn about them.
1. Negated options are usually are problem down the maintenance road:
When a new negated option ("--no-foo") is introduced, then the option
can be negated at run time("--no-no-foo"), which is usually confusing
for boolean options.
2. The handling of negated values (specifically double negations), usually
require more brain power to get it right. In code that we own, we
should strive to avoid double negatives ("!no_foo").
Signed-off-by: Stefan Beller <sbeller@google.com>
---
#leftoverbits
I was wondering if such a patch may be of value eventually (after all
occurrences of "no-" options are fixed).
This patch disallows all no- options, but we could be more open and allow
--no-options that have the NO_NEG bit set.
Makefile | 3 ++-
parse-options.c | 6 ++++++
parse-options.h | 7 +++++--
3 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/Makefile b/Makefile
index aba0f5a0f9..9b87093f99 100644
--- a/Makefile
+++ b/Makefile
@@ -433,7 +433,8 @@ DEVELOPER_CFLAGS = -Werror \
-Wpointer-arith \
-Wstrict-prototypes \
-Wunused \
- -Wvla
+ -Wvla \
+ -DDEVELOPER
LDFLAGS =
ALL_CFLAGS = $(CPPFLAGS) $(CFLAGS)
ALL_LDFLAGS = $(LDFLAGS)
diff --git a/parse-options.c b/parse-options.c
index 0dd9fc6a0d..08db926adf 100644
--- a/parse-options.c
+++ b/parse-options.c
@@ -403,6 +403,12 @@ static void parse_options_check(const struct option *opts)
if (opts->argh &&
strcspn(opts->argh, " _") != strlen(opts->argh))
err |= optbug(opts, "multi-word argh should use dash to separate words");
+#if DEVELOPER
+ if ((opts->flags & PARSE_OPT_ERR_NEGATED) &&
+ !strcmp("no-", opts->long_name))
+ BUG("Get %s fixed! double negation possible",
+ opts->long_name);
+#endif
}
if (err)
exit(128);
diff --git a/parse-options.h b/parse-options.h
index af711227ae..9dc07fd9bb 100644
--- a/parse-options.h
+++ b/parse-options.h
@@ -38,7 +38,8 @@ enum parse_opt_option_flags {
PARSE_OPT_LASTARG_DEFAULT = 16,
PARSE_OPT_NODASH = 32,
PARSE_OPT_LITERAL_ARGHELP = 64,
- PARSE_OPT_SHELL_EVAL = 256
+ PARSE_OPT_SHELL_EVAL = 256,
+ PARSE_OPT_ERR_NEGATED = 512
};
struct option;
@@ -124,7 +125,9 @@ struct option {
(h), PARSE_OPT_NOARG }
#define OPT_SET_INT(s, l, v, h, i) { OPTION_SET_INT, (s), (l), (v), NULL, \
(h), PARSE_OPT_NOARG, NULL, (i) }
-#define OPT_BOOL(s, l, v, h) OPT_SET_INT(s, l, v, h, 1)
+#define OPT_BOOL(s, l, v, h) { OPTION_SET_INT, (s), (l), (v), NULL, \
+ (h), PARSE_OPT_NOARG|PARSE_OPT_ERR_NEGATED, \
+ NULL, 1 }
#define OPT_HIDDEN_BOOL(s, l, v, h) { OPTION_SET_INT, (s), (l), (v), NULL, \
(h), PARSE_OPT_NOARG | PARSE_OPT_HIDDEN, NULL, 1}
#define OPT_CMDMODE(s, l, v, h, i) { OPTION_CMDMODE, (s), (l), (v), NULL, \
--
2.14.0.rc0.3.g6c2e499285
^ permalink raw reply related [relevance 5%]
* Re: [PATCH] builtin/merge: honor commit-msg hook for merges
@ 2017-09-05 21:38 5% ` Junio C Hamano
2017-09-05 23:08 5% ` [PATCH] parse-options: warn developers on negated options Stefan Beller
0 siblings, 1 reply; 114+ results
From: Junio C Hamano @ 2017-09-05 21:38 UTC (permalink / raw)
To: Stefan Beller; +Cc: git
Stefan Beller <sbeller@google.com> writes:
> Similar to 65969d43d1 (merge: honor prepare-commit-msg hook, 2011-02-14)
> merge should also honor the commit-msg hook; the reason is the same as
> in that commit: When a merge is stopped due to conflicts or --no-commit,
> the subsequent commit calls the commit-msg hook. However, it is not
> called after a clean merge. Fix this inconsistency by invoking the hook
> after clean merges as well.
The above reads better without "; the reason is the same as in that
commit"---"Similar to", combined with the clean and concise
explanation after the colon you have, sufficiently justifies why
this is a good change.
Excellent job spotting the precedent and making it consistent ;-).
> This change is motivated by Gerrits commit-msg hook to install a change-id
s/Gerrits/Gerrit's/ perhaps?
> trailer into the commit message. Without such a change id, Gerrit refuses
I do not live in Gerrit land and I do not know which one is the more
preferred one, but be consistent between "change-id" and "change
id".
> to accept (merge) commits by default, such that the inconsistency of
> (not) running commit-msg hook between commit and merge leads to confusion
> and might block people from getting their work done.
Yup. Nicely explained.
I didn't check how "merge --continue" is implemented, but we need to
behave exactly the same way over there, too. Making sure that it is
a case in t7504 may be a good idea, in addition to the test you
added.
> Signed-off-by: Stefan Beller <sbeller@google.com>
> ---
> builtin/merge.c | 8 ++++++++
> t/t7504-commit-msg-hook.sh | 45 +++++++++++++++++++++++++++++++++++++++++----
> 2 files changed, 49 insertions(+), 4 deletions(-)
>
> diff --git a/builtin/merge.c b/builtin/merge.c
> index 7df3fe3927..087efd560d 100644
> --- a/builtin/merge.c
> +++ b/builtin/merge.c
> @@ -73,6 +73,7 @@ static int show_progress = -1;
> static int default_to_upstream = 1;
> static int signoff;
> static const char *sign_commit;
> +static int no_verify;
>
> static struct strategy all_strategy[] = {
> { "recursive", DEFAULT_TWOHEAD | NO_TRIVIAL },
> @@ -236,6 +237,7 @@ static struct option builtin_merge_options[] = {
> N_("GPG sign commit"), PARSE_OPT_OPTARG, NULL, (intptr_t) "" },
> OPT_BOOL(0, "overwrite-ignore", &overwrite_ignore, N_("update ignored files (default)")),
> OPT_BOOL(0, "signoff", &signoff, N_("add Signed-off-by:")),
> + OPT_BOOL(0, "no-verify", &no_verify, N_("bypass pre-commit and commit-msg hooks")),
This allows "--no-no-verify", which may want to be eventually
addressed (either by changing the code not to accept, or declaring
that it is an intended behaviour); I do not offhand know for sure but I
strong suspect "commit" shares the same issue, in which case this
patch is perfectly fine and addressing "--no-no-verify" should be
done for both of them in a separate follow-up topic. #leftoverbits
Thanks. I'll be online starting today, but please expect slow
responses for a few days as there is significant backlog.
^ permalink raw reply [relevance 5%]
* Re: [PATCH] pkt-line: re-'static'-ify buffer in packet_write_fmt_1()
@ 2017-09-05 10:03 6% ` Junio C Hamano
2017-10-10 4:06 6% ` [PATCH 0/2] Do not call cmd_*() as a subroutine Junio C Hamano
0 siblings, 1 reply; 114+ results
From: Junio C Hamano @ 2017-09-05 10:03 UTC (permalink / raw)
To: Jeff King; +Cc: Martin Ågren, Lars Schneider, Git Users
Jeff King <peff@peff.net> writes:
> Overall I suspect that running our cmd_*() functions multiple times in a
> single process is already going to cause chaos, because they often are
> touching static globals, etc. So it's probably not that big a deal in
> practice to add one more variable to the list, and declare that calling
> cmd_ls_files() anywhere except as the main function of ls-files is
> forbidden.
IIRC there were a few existing violators of this rule around "merge"
implementation. It may be a reasonably low hanging fruit to find
and fix them.
#leftoverbits
^ permalink raw reply [relevance 6%]
* Re: [PATCH 01/39] pack: make packed_git_mru global a value instead of a pointer
@ 2017-08-30 19:44 6% ` Jeff King
2017-09-06 19:51 0% ` Junio C Hamano
0 siblings, 1 reply; 114+ results
From: Jeff King @ 2017-08-30 19:44 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git, Stefan Beller, brian m. carlson
On Tue, Aug 29, 2017 at 11:48:27PM -0700, Jonathan Nieder wrote:
> The MRU cache that keeps track of recently used packs is represented
> using two global variables:
>
> struct mru packed_git_mru_storage;
> struct mru *packed_git_mru = &packed_git_mru_storage;
>
> Callers never assign to the packed_git_mru pointer, though, so we can
> simplify by eliminating it and using &packed_git_mru_storage (renamed
> to &packed_git_mru) directly. This variable is only used by the
> packfile subsystem, making this a relatively uninvasive change (and
> any new unadapted callers would trigger a compile error).
>
> Noticed while moving these globals to the object_store struct.
Sounds reasonable. I think I had originally wanted to hide the
implementation and make the MRU more opaque, hence exposing only the
pointer. But since I ended up just letting people directly walk over the
struct pointers to do iteration, it needs to expose the struct internals
anyway, and this layer of indirection isn't useful.
> ---
> builtin/pack-objects.c | 4 ++--
> cache.h | 4 ++--
> packfile.c | 12 +++++-------
> 3 files changed, 9 insertions(+), 11 deletions(-)
The patch looks good to me.
As an aside, the mru code could probably be simplified a bit by reusing
the list implementation from list.h (both were added around the same
time, and it wasn't worth creating a dependency then, but I think list.h
is useful and here to stay at this point).
It's definitely not critical to put that into this already-large series,
though. Maybe we can use Junio's #leftoverbits tag. :)
-Peff
^ permalink raw reply [relevance 6%]
* Re: Should rerere auto-update a merge resolution?
@ 2017-08-25 17:08 6% ` Junio C Hamano
0 siblings, 0 replies; 114+ results
From: Junio C Hamano @ 2017-08-25 17:08 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Git Mailing List
Junio C Hamano <gitster@pobox.com> writes:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> Martin Langhoff <martin.langhoff@gmail.com> writes:
>>
>>> - when I tell it to forget, won't it forget the pre-resolution state?
>>
>> I do not recall the details of what I did ;-) so I played around a
>> bit. Here is what I did:
>> ...
>> After git rerere forget, I observe (check subdirectories in
>> .git/rr-cache/ whose timestamps are recent) that postimage gets
>> removed but preimage and thisimage stay.
>
> Having said that, I suspect that it may be a bug if this procedure
> kept the original preimage. It should either remove it, or update
> it to record the state before the ealier resolution was applied
> (i.e. make the updated preimage identical to thisimage, so that a
> corrected resolution can be taken from the working tree to pair with
> it).
I just made a cursory scan of rerere.c again, and it seems we are
doing the right thing. The details are in rerere_forget_one_path()
where we unlink postimage, we recreate the conflicted state from the
stages in the index and update preimage.
It seems that code gives up if you already declared that you'd take
the previous resolution by adding the result to the index. It may
probably be a good idea to unmerge such a merged index entry instead
of giving up. #leftoverbits
So, yes, it will forget both preimage and postimage, and it should
update the preimage with the conflict you got during _this_ merge,
so that the resolution you make _this_ time will become usable as
the corresponding postimage for the next time.
^ permalink raw reply [relevance 6%]
* Re: What's cooking in git.git (Aug 2017, #04; Fri, 18)
@ 2017-08-20 17:04 6% ` Junio C Hamano
0 siblings, 0 replies; 114+ results
From: Junio C Hamano @ 2017-08-20 17:04 UTC (permalink / raw)
To: Jeff King; +Cc: Martin Ågren, Jacob Keller, git
Jeff King <peff@peff.net> writes:
> On Fri, Aug 18, 2017 at 02:26:14PM -0700, Junio C Hamano wrote:
>
>> * jk/trailers-parse (2017-08-15) 8 commits
>> - pretty: support normalization options for %(trailers)
>> - t4205: refactor %(trailers) tests
>> - pretty: move trailer formatting to trailer.c
>> - interpret-trailers: add --parse convenience option
>> - interpret-trailers: add an option to unfold values
>> - interpret-trailers: add an option to show only existing trailers
>> - interpret-trailers: add an option to show only the trailers
>> - trailer: put process_trailers() options into a struct
>>
>> "git interpret-trailers" has been taught a "--parse" and a few
>> other options to make it easier for scripts to grab existing
>> trailer lines from a commit log message.
>>
>> Will merge to 'next'.
>
> I saw that this was merged and ended up with a few conflicts related to
> the other interpret-trailers series (sorry). Your resolution looks good
> to me.
Thanks for double checking. This was an easy conflict--the only
remotely tricky part was "list.nr -> !list_empty(&list)".
> There are a few leftover bits I think we could do on top:
>
> - we disallow "--trailer" with "--only-input", because the former is
> quietly ignored. After the two series are merged, I think "--where",
> etc should probably get the same treatment (the behavior without it
> isn't horrible, but it's nice to warn the user that what they asked
> for is bogus).
Sounds good. I didn't think about that case.
The implementation would have to add another variable whose sole
purpose is to keep track of "have we ever seen any of these
options?" and flip it in the callbacks that implement these options,
as there is no way to tell between WHERE_DEFAULT that is set from
the command line, from the configuration, or left as-is without
either.
> - Martin pointed out a typo in the new documentation
>
> - I just noticed that ref-filter understands "%(trailer)", too
> (courtesy of Jacob's original series from last year; I didn't think
> to even check for it). It probably should learn to support the
> additional options, too. I didn't look, but it probably could just
> reuse the new trailer.c formatting function I added.
>
> There's a patch for the second one below.
>
> None for the other two right now, as I'm just trying to clear out
> backlog before going offline for a few days (but I'd be happy if anybody
> wanted to take a crack at them in the meantime).
Thanks. Have a good time (I am assuming you'd be having fun, as
opposed to having to become offline to tend to unpleasant duties).
We probably want some convention to mark the messages with these
"leftover bits that are relatively low hanging fruits", so that
archive search can find them easily. #leftoverbits perhaps?
That way, hopefully people can look for messages with such mark that
came from those list participants with known-good taste. That would
be far easier than a general bug tracker anybody can throw garbage
at, and requires constant attention to winnow only good ones out of
chaff.
> -- >8 --
> From: =?UTF-8?q?Martin=20=C3=85gren?= <martin.agren@gmail.com>
> Subject: [PATCH] doc/interpret-trailers: fix "the this" typo
>
> Signed-off-by: Jeff King <peff@peff.net>
> ---
> I put Martin as the author since he noticed the bug, but I think we are
> OK without a signoff for this trivial change (normally I'd have just
> squashed, but the topic is in 'next' now).
>
> Documentation/git-interpret-trailers.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/git-interpret-trailers.txt b/Documentation/git-interpret-trailers.txt
> index 1df8aabf51..2e22210734 100644
> --- a/Documentation/git-interpret-trailers.txt
> +++ b/Documentation/git-interpret-trailers.txt
> @@ -21,7 +21,7 @@ This command reads some patches or commit messages from either the
> <file> arguments or the standard input if no <file> is specified. If
> `--parse` is specified, the output consists of the parsed trailers.
>
> -Otherwise, the this command applies the arguments passed using the
> +Otherwise, this command applies the arguments passed using the
> `--trailer` option, if any, to the commit message part of each input
> file. The result is emitted on the standard output.
^ permalink raw reply [relevance 6%]
Results 401-514 of 514 prev (newer) | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
2017-08-07 21:49 Suggestion: better error message when an ambiguous checkout is executed Mahmoud Al-Qudsi
2017-08-07 22:44 ` Junio C Hamano
2017-09-12 6:53 6% ` Junio C Hamano
2017-08-08 17:11 [PATCH v2 1/2 / RFC] builtin/branch: stop supporting the use of --set-upstream option Kaartic Sivaraam
2017-08-14 8:54 ` [PATCH v3 " Kaartic Sivaraam
2017-08-14 20:19 ` Junio C Hamano
2017-08-15 10:56 ` Kaartic Sivaraam
2017-08-15 18:58 ` Junio C Hamano
2017-08-16 18:13 ` Kaartic Sivaraam
2017-08-16 19:09 ` Junio C Hamano
2017-08-17 2:04 ` Kaartic Sivaraam
2017-09-12 6:49 6% ` Junio C Hamano
2017-09-12 7:00 0% ` Kaartic Sivaraam
2017-08-18 21:26 What's cooking in git.git (Aug 2017, #04; Fri, 18) Junio C Hamano
2017-08-20 9:40 ` Jeff King
2017-08-20 17:04 6% ` Junio C Hamano
2017-08-23 19:39 Should rerere auto-update a merge resolution? Martin Langhoff
2017-08-23 20:34 ` Junio C Hamano
2017-08-23 21:12 ` Martin Langhoff
2017-08-25 15:16 ` Junio C Hamano
2017-08-25 16:07 ` Junio C Hamano
2017-08-25 17:08 6% ` Junio C Hamano
2017-08-27 7:37 [PATCH] pkt-line: re-'static'-ify buffer in packet_write_fmt_1() Martin Ågren
2017-08-27 18:21 ` Lars Schneider
2017-08-27 19:09 ` Martin Ågren
2017-08-27 20:04 ` Lars Schneider
2017-08-27 23:23 ` Jeff King
2017-08-28 4:11 ` Martin Ågren
2017-08-29 17:51 ` Lars Schneider
2017-08-29 18:53 ` Jeff King
2017-08-29 19:22 ` Martin Ågren
2017-08-29 21:48 ` Jeff King
2017-08-30 5:31 ` Jeff King
2017-09-05 10:03 6% ` Junio C Hamano
2017-10-10 4:06 6% ` [PATCH 0/2] Do not call cmd_*() as a subroutine Junio C Hamano
2017-08-30 6:46 [PATCH 00/39] per-repository object store, part 1 Jonathan Nieder
2017-08-30 6:48 ` [PATCH 01/39] pack: make packed_git_mru global a value instead of a pointer Jonathan Nieder
2017-08-30 19:44 6% ` Jeff King
2017-09-06 19:51 0% ` Junio C Hamano
2017-09-05 21:01 [PATCH] builtin/merge: honor commit-msg hook for merges Stefan Beller
2017-09-05 21:38 5% ` Junio C Hamano
2017-09-05 23:08 5% ` [PATCH] parse-options: warn developers on negated options Stefan Beller
2017-09-07 18:13 "git shortlog -sn --follow -- <path>" counts all commits to entire repo Валентин
2017-09-07 19:30 ` Stefan Beller
2017-09-08 5:10 ` Jeff King
2017-09-08 6:38 ` Junio C Hamano
2017-09-08 7:49 ` Jeff King
2017-09-08 17:37 ` Junio C Hamano
2017-09-09 6:52 6% ` Jeff King
2017-09-10 7:36 6% ` Junio C Hamano
[not found] <c74c8c386f2c2d8b6cebd4addf925d0121986067.1502114584.git.nicolas@morey-chaisemartin.com>
2017-08-07 14:04 ` [PATCH 4/4] imap-send: use curl by default Nicolas Morey-Chaisemartin
2017-08-07 20:01 ` Jeff King
2017-09-12 6:46 6% ` Junio C Hamano
2017-09-12 7:02 0% ` Junio C Hamano
2017-09-12 8:24 0% ` Nicolas Morey-Chaisemartin
2017-09-12 17:23 [PATCH 0/4] Fixes from the per-repository object store series Jonathan Nieder
2017-09-12 17:28 4% ` [PATCH 1/4] pack: make packed_git_mru global a value instead of a pointer Jonathan Nieder
2017-09-15 6:18 Is finalize_object_file in sha1_file.c handling errno from "rename" correctly? Wesley Smith
2017-09-15 6:50 5% ` Junio C Hamano
2017-09-15 18:18 5% ` Wesley Smith
2017-09-29 23:21 0% ` Johannes Schindelin
2017-09-18 17:21 [OUTREACHY] pack: make packed_git_mru global a value instead of a pointer phionah bugosi
2017-09-18 23:17 ` Jonathan Nieder
2017-09-19 5:20 6% ` Jeff King
[not found] <CAL21Bm=e9C4ANTsc4n1BG3xqjCJmORDSPcS5QEXYKUkK3cAH6w@mail.gmail.com>
2017-09-19 8:05 7% ` My first contribution Christian Couder
2017-09-20 20:02 [PATCH] diff-lib: clear `pending` object-array in `index_differs_from()` Jeff King
2017-09-22 23:34 ` [PATCH v2 0/6] reroll ma/plugleaks; more `object_array`-fixes Martin Ågren
2017-09-22 23:34 ` [PATCH v2 4/6] object_array: use `object_array_clear()`, not `free()` Martin Ågren
2017-09-23 4:04 5% ` Jeff King
[not found] <CAL21Bm=zQ2ADTOSVk5kL1q=VyLV91J+VbsLLFbSdgPxeg3FW1g@mail.gmail.com>
2017-09-21 5:30 7% ` My first contribution. Outreachy Jeff King
2017-09-25 0:02 BUG: merge -s theirs is not in effect (does the same as -s ours) Yaroslav Halchenko
2017-09-25 1:08 ` Junio C Hamano
2017-09-25 3:17 ` Yaroslav Halchenko
2017-09-25 5:33 ` Re* " Junio C Hamano
2017-09-25 14:30 ` -X theirs does not resolve symlink conflict Was: BUG: merge -s theirs is not in effect Yaroslav Halchenko
2017-09-26 1:56 ` Junio C Hamano
2017-09-26 2:16 ` Junio C Hamano
2017-09-26 2:39 6% ` Junio C Hamano
2017-09-26 13:37 0% ` Yaroslav Halchenko
2017-09-27 6:16 [PATCH 0/3] validate_headref: avoid reading uninitialized bytes Jeff King
2017-09-27 6:17 ` [PATCH 1/3] validate_headref: NUL-terminate HEAD buffer Jeff King
2017-09-27 7:06 6% ` Junio C Hamano
2017-09-27 7:16 0% ` Jeff King
2017-09-28 8:38 [PATCH Outreachy] mru: use double-linked list from list.h Olga Telezhnaya
2017-09-30 17:51 ` [PATCH v2 " Olga Telezhnaya
2017-10-02 8:20 6% ` Jeff King
2017-11-08 1:44 0% ` Junio C Hamano
2017-11-08 4:22 0% ` Jeff King
2017-10-02 0:31 [PATCH v5 0/6] Support %(trailers) arguments in for-each-ref(1) Taylor Blau
2017-10-02 0:32 ` [PATCH v5 1/6] pretty.c: delimit "%(trailers)" arguments with "," Taylor Blau
2017-10-02 0:33 ` [PATCH v5 6/6] ref-filter.c: parse trailers arguments with %(contents) atom Taylor Blau
2017-10-02 5:03 6% ` Jeff King
2017-10-02 5:12 6% ` Taylor Blau
2017-10-02 5:14 0% ` Jeff King
2017-10-02 10:13 What means "git config bla ~/"? rpjday
2017-10-02 17:13 ` Jonathan Nieder
2017-10-03 0:08 ` Junio C Hamano
2017-10-03 11:45 ` Matthieu Moy
2017-10-04 4:01 6% ` Junio C Hamano
2017-10-02 13:56 [PATCH 0/3] for-each-ref: add :remote-ref and :remote-name specifiers Johannes Schindelin
2017-10-02 13:57 ` [PATCH 2/3] for-each-ref: let upstream/push optionally report merge name Johannes Schindelin
2017-10-04 9:12 ` Junio C Hamano
2017-10-04 11:41 ` Junio C Hamano
2017-10-05 9:14 6% ` Junio C Hamano
2017-10-03 10:15 Enhancement request: git-push: Allow (configurable) default push-option Marius Paliga
2017-10-03 16:53 6% ` Stefan Beller
2017-10-04 15:20 0% ` Marius Paliga
2017-10-11 7:14 0% ` Marius Paliga
2017-10-11 9:18 0% ` Marius Paliga
2017-10-11 20:25 ` Thais D. Braz
2017-10-11 20:25 ` [PATCH][Outreachy] New git config variable to specify string that will be automatically passed as --push-option Thais D. Braz
2017-10-12 1:21 ` Junio C Hamano
2017-10-12 2:41 6% ` Christian Couder
2017-10-12 3:26 0% ` Junio C Hamano
2017-10-17 3:47 10% ` [PATCH] patch reply Thais Diniz
2017-10-17 4:01 0% ` Junio C Hamano
2017-10-17 7:15 0% ` Marius Paliga
2017-10-17 3:58 6% ` [PATCH][Outreachy] New git config variable to specify string that will be automatically passed as --push-option thais braz
2017-10-03 21:14 6% [PATCH] branch: reset instead of release a strbuf Stefan Beller
2017-10-03 21:46 0% ` Jonathan Nieder
2017-10-13 5:11 [PATCH 0/3] a small branch API clean-up Junio C Hamano
2017-10-13 5:11 ` [PATCH 3/3] branch: forbid refs/heads/HEAD Junio C Hamano
2017-10-13 13:15 6% ` Jeff King
2017-10-14 2:11 0% ` Junio C Hamano
2017-10-18 1:04 [PATCH] Added support for new configuration parameter push.pushOption Junio C Hamano
2017-10-19 17:47 ` [PATCH] builtin/push.c: add push.pushOption config Marius Paliga
2017-10-19 19:46 ` Stefan Beller
2017-10-20 2:19 ` Junio C Hamano
2017-10-20 6:17 ` Junio C Hamano
2017-10-20 6:18 ` Junio C Hamano
2017-10-20 8:52 ` Marius Paliga
2017-10-21 1:33 5% ` Junio C Hamano
2017-10-19 0:35 [PATCH v4 2/3] implement fetching of moved submodules Junio C Hamano
2017-10-19 18:11 ` [PATCH 1/2] t5526: check for name/path collision in submodule fetch Stefan Beller
2017-10-19 18:11 ` [PATCH 2/2] fetch, push: keep separate lists of submodules and gitlinks Stefan Beller
2017-10-23 14:12 ` Heiko Voigt
2017-10-23 18:05 6% ` Stefan Beller
2017-10-19 17:44 [PATCH v2] commit: check result of resolve_ref_unsafe Jeff King
2017-10-19 17:47 ` [PATCH 2/4] remote: handle broken symrefs Jeff King
2017-10-19 17:53 6% ` Jeff King
2017-10-19 20:23 [PATCH 0/5] fix "diff --color-moved --ignore-space-at-eol" Jeff King
2017-10-19 20:31 5% ` [PATCH 5/5] diff: handle NULs in get_string_hash() Jeff King
2017-10-19 21:31 0% ` Stefan Beller
2017-10-24 17:48 Consequences of CRLF in index? Lars Schneider
2017-10-24 18:14 ` Jonathan Nieder
2017-10-25 1:51 ` Junio C Hamano
2017-10-25 4:53 4% ` Junio C Hamano
2017-10-25 16:44 0% ` Stefan Beller
2017-10-25 5:11 [PATCHv2 0/2] (x)diff cleanup: remove duplicate code Junio C Hamano
2017-10-25 18:49 ` [PATCHv3 " Stefan Beller
2017-10-25 18:49 ` [PATCH 1/2] xdiff-interface: export comparing and hashing strings Stefan Beller
2017-10-26 17:12 ` René Scharfe
2017-10-27 7:12 5% ` Junio C Hamano
2017-10-27 17:15 6% ` Stefan Beller
2017-10-31 0:33 [PATCH 0/7] git-describe <blob> Stefan Beller
2017-10-31 21:18 ` [PATCHv2 0/7] git describe blob Stefan Beller
2017-10-31 21:18 ` [PATCHv2 6/7] builtin/describe.c: describe a blob Stefan Beller
2017-11-01 4:11 ` Junio C Hamano
2017-11-01 12:32 ` Johannes Schindelin
2017-11-01 17:59 ` Stefan Beller
2017-11-01 21:05 ` Jacob Keller
2017-11-01 22:12 ` Johannes Schindelin
2017-11-01 22:21 ` Stefan Beller
2017-11-01 22:41 ` Johannes Schindelin
2017-11-02 6:05 ` Jacob Keller
2017-11-03 5:18 ` Junio C Hamano
2017-11-03 6:55 ` Jacob Keller
2017-11-03 15:02 6% ` Junio C Hamano
2017-11-01 16:36 Git Open Source Weekend London 11th/12th November Thomas Gummerer
2017-11-04 9:28 6% ` Jeff King
2017-11-04 17:15 0% ` Philip Oakley
[not found] <CAGHpTB+jKiXr45tKVEVTtszN7OBTW7W_FqKu7aAjsB8Tmx9N3Q@mail.gmail.com>
2017-11-06 22:08 ` [PATCH] wt-status: actually ignore submodules when requested Brandon Williams
2017-11-06 22:44 5% ` Stefan Beller
2017-11-06 22:52 0% ` Brandon Williams
2017-11-07 20:48 No log --no-decorate completion? Stefan Beller
2017-11-07 21:22 ` [PATCH] completion: add missing completions for log, diff, show Max Rothman
2017-11-08 2:33 5% ` Junio C Hamano
2017-11-08 3:30 0% ` Max Rothman
2017-11-08 16:58 Invalid memory access in `git apply` mqudsi
2017-11-11 14:10 ` [PATCH] apply: avoid out-of-bounds access in fuzzy_matchlines() René Scharfe
2017-11-12 4:45 6% ` Junio C Hamano
2017-11-14 8:43 some apparent inaccuracies in "man git-worktree" Robert P. J. Day
2017-11-14 18:33 5% ` Eric Sunshine
2017-11-14 20:10 0% ` Robert P. J. Day
2017-11-15 12:52 [PATCH] Makefile: check that tcl/tk is installed Christian Couder
2017-11-16 1:35 ` Junio C Hamano
2017-11-17 15:35 ` Christian Couder
2017-11-17 17:42 ` Todd Zullinger
2017-11-20 18:12 5% ` Christian Couder
2017-11-16 0:54 [PATCH V3] config: add --expiry-date Junio C Hamano
2017-11-18 2:27 ` [PATCH V4] " hsed
2017-11-18 3:37 6% ` Junio C Hamano
2017-11-20 14:53 0% ` hsed
2017-11-20 17:04 0% ` Jeff King
2017-11-20 20:28 6% ` Stefan Beller
2017-11-20 20:37 0% ` Jeff King
2017-11-30 11:18 0% ` Heiko Voigt
2017-11-20 21:21 [PATCH v3 0/8] Coping with unrecognized ssh wrapper scripts in GIT_SSH Jonathan Nieder
2017-11-20 21:22 ` [PATCH 1/8] ssh test: make copy_ssh_wrapper_as clean up after itself Jonathan Nieder
2017-11-21 1:24 6% ` Junio C Hamano
2017-11-20 22:25 [PATCH 0/1] Teaching the diff machinery about blobfind [WAS: git describe <blob>] Stefan Beller
2017-11-20 22:25 3% ` [PATCH 1/1] diffcore: add a filter to find a specific blob Stefan Beller
2017-11-24 7:43 0% ` Junio C Hamano
2017-11-22 17:51 [RFC PATCH] builtin/worktree: enhance worktree removal Kaartic Sivaraam
2017-11-27 17:36 ` [RFC PATCH v2] " Kaartic Sivaraam
2017-11-28 3:02 ` Junio C Hamano
2017-11-28 3:48 ` Eric Sunshine
2017-11-28 4:04 ` Junio C Hamano
2017-11-28 16:46 6% ` Kaartic Sivaraam
2017-12-09 20:40 [PATCH v3 1/7] git-compat-util: introduce skip_to_optional_arg() Christian Couder
2017-12-10 14:31 ` Jeff King
2017-12-10 14:39 ` Jeff King
2017-12-11 5:56 6% ` Christian Couder
2018-01-03 0:18 [PATCH 00/26] protocol version 2 Brandon Williams
2018-01-25 23:58 ` [PATCH v2 00/27] " Brandon Williams
2018-01-25 23:58 ` [PATCH v2 05/27] upload-pack: factor out processing lines Brandon Williams
2018-01-26 20:12 ` Stefan Beller
2018-01-26 21:33 ` Brandon Williams
2018-01-31 14:08 6% ` Derrick Stolee
2018-02-07 1:12 ` [PATCH v3 00/35] protocol version 2 Brandon Williams
2018-02-07 1:12 ` [PATCH v3 14/35] connect: request remote refs using v2 Brandon Williams
2018-02-21 22:54 ` Jonathan Tan
2018-02-22 18:19 ` Brandon Williams
2018-02-22 18:26 ` Jeff King
2018-02-22 19:25 ` Jonathan Tan
2018-02-27 6:21 6% ` Jonathan Nieder
2018-02-27 21:58 0% ` Junio C Hamano
2018-02-27 22:04 0% ` Jeff King
2018-01-16 7:18 [PATCH] sha1_file: remove static strbuf from sha1_file_name() Christian Couder
2018-01-16 14:01 ` Derrick Stolee
2018-01-16 19:00 ` Jeff Hostetler
2018-01-17 17:55 5% ` Christian Couder
2018-02-12 17:23 [PATCH] describe: confirm that blobs actually exist Jeff King
2018-02-12 17:29 6% ` Jeff King
2018-03-17 21:20 6% [GSoC] Some #leftoverbits for anyone looking for little projects Ævar Arnfjörð Bjarmason
2018-04-21 3:45 [PATCH 1/6] grep.c: take regmatch_t as argument in match_line() Taylor Blau
2018-05-09 2:13 ` [PATCH v5 0/7] Teach '--column' to 'git-grep(1)' Taylor Blau
2018-05-09 2:13 ` [PATCH v5 5/7] builtin/grep.c: add '--column' option " Taylor Blau
2018-05-09 10:41 ` Phillip Wood
2018-05-09 17:26 ` Martin Ågren
2018-05-09 23:52 ` Taylor Blau
2018-05-10 0:04 ` Junio C Hamano
2018-05-12 3:27 5% ` Taylor Blau
2018-05-19 1:54 [PATCH 0/5] snprintf truncation fixes Jeff King
2018-05-19 1:57 5% ` [PATCH 2/5] log_write_email_headers: use strbufs Jeff King
2018-05-25 19:28 [PATCH v2 0/5] fsck: doc fixes & fetch.fsck.* implementation Ævar Arnfjörð Bjarmason
2018-07-27 14:37 ` [PATCH v3 07/10] fetch: implement fetch.fsck.* Ævar Arnfjörð Bjarmason
2018-07-27 21:08 5% ` Junio C Hamano
2018-05-29 18:30 14% Is origin/HEAD only being created on clone a bug? #leftoverbits Ævar Arnfjörð Bjarmason
2018-05-29 19:17 8% ` Brandon Williams
2018-05-30 1:24 6% ` Junio C Hamano
2018-05-30 2:46 8% ` Junio C Hamano
2018-06-01 6:51 8% ` Jeff King
2018-05-31 7:42 8% ` Ævar Arnfjörð Bjarmason
2018-06-01 1:32 8% ` Junio C Hamano
2018-06-18 23:43 5% [PATCH 0/7] grep.c: teach --column to 'git-grep(1)' Taylor Blau
2018-06-19 16:35 0% ` Jeff King
2018-06-19 17:33 0% ` René Scharfe
2018-06-19 17:44 0% ` Taylor Blau
2018-06-24 8:56 6% [BUG] url schemes should be case-insensitive Jeff King
2018-06-25 18:19 6% ` Junio C Hamano
2018-06-26 12:21 0% ` Jeff King
2018-06-26 17:09 0% ` Junio C Hamano
2018-06-28 7:46 [GSoC] [PATCH 0/5] rebase: rewrite rebase in C Pratik Karki
2018-07-06 12:08 ` [GSoC] [PATCH v3 0/4] " Pratik Karki
2018-07-06 12:08 ` [PATCH v3 4/4] builtin/rebase: support running "git rebase <upstream>" Pratik Karki
2018-07-07 6:45 6% ` Christian Couder
2018-07-07 11:59 0% ` Johannes Schindelin
2018-07-07 16:24 6% ` Junio C Hamano
2018-07-03 12:38 [PATCH 0/8] X509 (gpgsm) commit signing support Henning Schild
2018-07-03 12:38 ` [PATCH 4/8] gpg-interface: introduce an abstraction for multiple gpg formats Henning Schild
2018-07-04 7:10 ` Martin Ågren
2018-07-06 17:24 ` Junio C Hamano
2018-07-10 15:37 ` Jeff King
2018-07-10 15:51 6% ` Junio C Hamano
2018-07-18 0:53 [PATCH] diff.c: offer config option to control ws handling in move detection Stefan Beller
2018-07-18 17:45 ` Junio C Hamano
2018-07-18 18:16 ` Stefan Beller
2018-07-19 16:29 ` Junio C Hamano
2018-07-19 17:29 6% ` Stefan Beller
2018-07-18 16:10 [PATCH v2 00/23] Mark strings for translation Nguyễn Thái Ngọc Duy
2018-07-18 16:10 ` [PATCH v2 02/23] archive-tar.c: mark more " Nguyễn Thái Ngọc Duy
2018-07-19 18:21 6% ` Junio C Hamano
2018-07-21 6:18 0% ` Duy Nguyen
2018-07-18 16:10 ` [PATCH v2 03/23] archive-zip.c: " Nguyễn Thái Ngọc Duy
2018-07-19 18:26 6% ` Junio C Hamano
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).