"Johannes Schindelin via GitGitGadget"
writes:
> @@ -177,8 +178,16 @@ static unsigned ws_check_emit_1(const char *line, int
> len, unsigned ws_rule,
> if (trailing_whitespace == -1)
> trailing_whitespace = len;
>
> + if ((ws_rule & WS_IGNORE_FIRST_SPACE) && len &&
"Johannes Schindelin via GitGitGadget"
writes:
> From: Johannes Schindelin
>
> When diffing diffs, it can be quite daunting to figure out what the heck
> is going on, as there are nested +/- signs.
>
> Let's make this easier by adding a flag in diff_options that allows
> color-coding the outer
Stefan Beller writes:
> On Sat, Jul 21, 2018 at 3:04 PM Johannes Schindelin via GitGitGadget
> wrote:
>
>> Side note: I work on implementing range-diff not only to make life easier
>> for reviewers who have to suffer through v2, v3, ... of my patch series, but
>> also to verify my changes
Junio C Hamano writes:
> "Johannes Schindelin via GitGitGadget"
> writes:
>
>> diff --git a/contrib/vscode/init.sh b/contrib/vscode/init.sh
>> new file mode 100755
>> index 0..3cc93243f
>> --- /dev/null
>> +++ b/contrib/vscode/init.sh
>
Eric Sunshine writes:
> On Mon, Jul 23, 2018 at 12:03 PM Duy Nguyen wrote:
>> On Sun, Jul 22, 2018 at 11:57 AM Eric Sunshine
>> wrote:
>> > @@ -0,0 +1,17 @@
>> > +void show_interdiff(struct rev_info *rev)
>> > +{
>> > + struct diff_options opts;
>> > +
>> > + memcpy(, >diffopt,
Stefan Beller writes:
> This test was last touched in c66410ed32a (submodule init:
> redirect stdout to stderr, 2016-05-02), merged as f2c96ceb57a
> (Merge branch 'sb/submodule-init', 2016-05-17)
>
> The parallelizing effort was made before that
> (2335b870fa7 (submodule update: expose
"Johannes Schindelin via GitGitGadget"
writes:
> diff --git a/contrib/vscode/init.sh b/contrib/vscode/init.sh
> new file mode 100755
> index 0..3cc93243f
> --- /dev/null
> +++ b/contrib/vscode/init.sh
> @@ -0,0 +1,165 @@
> +#!/bin/sh
This is caued by our usual "git apply
SZEDER Gábor writes:
> Just a couple of minor Coccinelle-related improvements:
>
> - The first two patches are small cleanups.
>
> - The last three could make life perhaps just a tad bit easier for
> devs running 'make coccicheck'.
Thanks. All 5 patches make sense.
Queued.
SZEDER Gábor writes:
> The dependencies of the 'coccicheck' make target are listed with the
> help of the $(patsubst) make function, which in this case doesn't do
> any pattern substitution, but only adds the '.patch' suffix.
>
> Use the shorter and more idiomatic $(addsuffix) make function
SZEDER Gábor writes:
> The 'coccicheck' target doesn't create a file with the same name, so
> mark it as .PHONY.
>
> Signed-off-by: SZEDER Gábor
> ---
Good. It is customary to do so immediately before the target, not
after a blank line, though.
> Makefile | 2 ++
> 1 file changed, 2
"Johannes Schindelin via GitGitGadget"
writes:
> To prevent such false positives from unnecessarily costing time when
> investigating test failures, let's take the exact order of the lines out
> of the equation by sorting them before comparing them.
> ...
> cat +Cloning into
"Johannes Schindelin via GitGitGadget"
writes:
> This fixes a regression test that produces false positives occasionally:
> https://git-for-windows.visualstudio.com/git/_build/results?buildId=14035=logs
>
[jc: forwrding to Torsten for <208b2ede-4833-f062-16f2-f35b8a8ce...@web.de>]
> Johannes
Beat Bolli writes:
> In the interest of code hygiene, make it easier to compile Git with the
> flag -pedantic.
>
> Pure pedantic compilation with GCC 7.3 results in one warning per use of
> the translation macro `N_`:
>
> warning: array initialized from parenthesized string constant
Ævar Arnfjörð Bjarmason writes:
>> +CFLAGS += -pedantic
>> +# don't warn for each N_ use
>> +CFLAGS += -DUSE_PARENS_AROUND_GETTEXT_N=0
>> +endif
>
> ...and set this to "no" not "0" since we document that that's the way to
> toggle it off in the Makefile, i.e. let's be consistent.
The Make
Ben Peart writes:
> On 7/21/2018 2:34 AM, Elijah Newren wrote:
>> From: Ben Peart
>>
>> Signed-off-by: Elijah Newren
>> ---
>> Testcase provided by Ben, so committing with him as the author. Just need
>> a sign off from him.
>
> Thanks Elijah, consider it
>
> Signed-off-by: Ben Peart
>
Nguyễn Thái Ngọc Duy writes:
> Access to e->delta_size_ (and by extension
> pack->delta_size[e - pack->objects]) is unprotected as before, the
> thread scheduler in pack-objects must make sure "e" is never updated
> by two different threads.
OK. Do we need to worry about "e" (e.g.
"brian m. carlson" writes:
> Both AsciiDoc 8.6.10 and Asciidoctor support SOURCE_DATE_EPOCH for
> reproducible builds[0], which should reduce the date noise. We could
> also add a Makefile knob to set git_version to an empty string or an
> --abbrev=0 equivalent for such a situation.
>
> [0]
Derrick Stolee writes:
> There are many places in Git that use a commit walk to determine
> reachability between commits and/or refs. A lot of this logic is
> duplicated.
>
> I wanted to achieve the following:
>
> Consolidate several different commit walks into one file
> Reduce duplicate
"brian m. carlson" writes:
> On Fri, Jul 20, 2018 at 11:22:03AM -0700, Junio C Hamano wrote:
>> Derrick Stolee writes:
>>
>> > diff --git a/Documentation/git-multi-pack-index.txt
>> > b/Documentation/git-multi-pack-index.txt
>> > ne
Stefan Beller writes:
> Signed-off-by: Stefan Beller
> ---
>
> Maybe we rather want to refer to the options that are described further
> down in the document?
I have no strong preference either way.
The patch looks reasonable to me; Christian?
>
> Documentation/git-interpret-trailers.txt |
Elijah Newren writes:
> Ah, okay, that's helpful. So, if there are conflicts, it should be
> free to clear the skip_worktree flag. Since merge-recursive calls
> add_cacheinfo() for all entries it needs to update, which deletes the
> old cache entry and just makes new ones, we get that for
Jeff King writes:
> I suspect it has more to do with system/libc differences between our
> machines, anyway. There was discussion elsewhere in the thread about the
> need to #undef before redefining. I guess this answers that question.
Yes, that is it. For now I can squash this in before
Basin Ilya writes:
> Hi.
>
> I'm trying to make the Cygwin Git understand Mingw-style repo urls:
>
> git config --global \
> file:///cygdrive/c.insteadOf \
> file:///C:
>
> But this fails with:
>
> error: invalid key: file:///cygdrive/c.insteadOf
Understandable.
> Manually
Stefan Beller writes:
> On Fri, Jul 20, 2018 at 12:35 PM Junio C Hamano wrote:
>
>> It is not like anybody (including me) needs realtime up-to-date
>
> I thought the same for a long time, but contributing to other projects
> showed me that this is not necessarily the cas
Elijah Newren writes:
> But that brings up another interesting question. What if a merge
> *does* modify a file for which you have skip-worktree set?
> Previously, it'd clear the bit and write the file to the working tree,
> but that was by no means an explicit decision;
At least in my mind,
Brandon Williams writes:
Is there an end-user visible effect, caused by the lack of "prefix"
being fixed with this patch, that is worth describing here? "The
server ended up showing refs that are irrelevant to the normal clone
request which is only for heads and tags, wasting time and
Johannes Schindelin writes:
> AFAICT there is at least one scenario where you run `rebase -i`, the notes
> get updated, and of course the *reverse mapping* does *not* get updated:
It turns out that I never had a rewrite hook; the notes.rewriteref
mechanism is the only thing that has been used
Jeff King writes:
> Thanks for an interesting (and exotic) counter-point. For strcpy(), you
> always have to run strlen() anyway to know you're not going to overflow,
> so you might as well memcpy() at that point. But if you really are OK
> with truncation, then using strncpy() lets you copy
Jeff King writes:
> This is a patch series to address the discussion in the thread at:
>
> https://public-inbox.org/git/20180713204350.ga16...@sigill.intra.peff.net/
>
> Basically, the question was: can we declare strcpy banned and have a
> linter save us the trouble of finding it in review.
Derrick Stolee writes:
> diff --git a/Documentation/git-multi-pack-index.txt
> b/Documentation/git-multi-pack-index.txt
> new file mode 100644
> index 00..ec9982cbfc
> --- /dev/null
> +++ b/Documentation/git-multi-pack-index.txt
> @@ -0,0 +1,36 @@
> +git-multi-pack-index(1)
>
Derrick Stolee writes:
>> What's the doneness of this one? I vaguely recall that there was
>> an objection against the concept as a whole (i.e. there is a way
>> with less damage to gain the same object-abbrev performance); has
>> it (and if anything else, they) been resolved in
Thanks.
Jeff King writes:
>> Is it a downside that it is cumbersome to override? This is not a
>> rhetorical question. I am not convinced there will not be a legit
>> circumstance that calling strcpy (or whatever we are going to ban)
>> is the best solution and it is safe. By "best", what I mean is
Junio C Hamano writes:
> Sorry, but I do not think I can relay that as an explanation why it
> won't cause problems to a third person.
OK, ignore this. I was being stupid.
> The entries in shallow file says that history behind them may not
> exist in the repository due to its
Jeff King writes:
> For enforcement, we can rely on the compiler and just
> introduce code which breaks compilation when it sees these
> functions. This has a few advantages:
>
> 1. We know it's run as part of a build cycle, so it's
> hard to ignore. Whereas an external linter is an extra
Stefan Beller writes:
> On Thu, Jul 19, 2018 at 2:02 PM Lars Schneider
> wrote:
>>
>> Hi,
>>
>> I have a blob hash and I would like to know what commit referenced
>> this blob first in a given Git repo.
>
> git describe
>
> If the given object refers to a blob, it will be described as
> :,
>
SZEDER Gábor writes:
>> Forgetting the code in git-sh-setup, are we?
>>
>> git_dir_init() rather specifically set GIT_DIR to the absolute path, and
>> since that variable is already exported, the `exec` commands launched via
>> `git-rebase--interactive` all saw it.
>>
>> That is the reason why
Henning Schild writes:
> Looking at "what is cooking" i assume i should not add/fold this to/in
> the serien anymore. So it comes as a separate patch on top.
Thanks. I only said:
I think this round is mostly ready, except for a minor nit in the
last step. I do not mind merging this
Johannes Schindelin writes:
> On Tue, 17 Jul 2018, Junio C Hamano wrote:
>
>> Jeff King writes:
>>
>> > I'm OK with having a partial fix, or one that fixes immediate pain
>> > without doing a big cleanup, as long as it doesn't make anything _worse_
>>
Duy Nguyen writes:
> It turns out gettext is smart! I got this in git.pot
>
> msgid "timestamp too large for this system: %"
OK.
Junio C Hamano writes:
> Imagine that you create a delta and set its size (which happens to
> fit in the entry) and then create another whose size does not fit in
> the entry. How does oe_delta_size() know not to look at
> pack->delta_size[] and instead look at e->delta_s
Duy Nguyen writes:
> @@ -330,20 +330,27 @@ static inline void oe_set_size(struct packing_data
> *pack,
> static inline unsigned long oe_delta_size(struct packing_data *pack,
> const struct object_entry *e)
> {
> - if (e->delta_size_valid)
> + if
Ben Peart writes:
> +/*
> + * struct mpmcq_entry is an opaque structure representing an entry in the
> + * queue.
> + */
> +struct mpmcq_entry {
> + struct mpmcq_entry *next;
> +};
> +
> +/*
> + * struct mpmcq is the concurrent queue structure. Members should not be
> + * modified directly.
Stefan Beller writes:
> v6:
> * fixed issues hinted at by Andrei, thanks! (range-diff below)
> * incorporates the new config option, sent separately previously.
Let's declare victory and move to incremental by merging to 'next',
if nobody spots anything more serious than just a missing SP
Nguyễn Thái Ngọc Duy writes:
> if (flags & CONNECT_VERBOSE) {
> - fprintf_ln(stderr, "done.");
> - fprintf(stderr, "Connecting to %s (port %s) ... ", host, port);
> + /* TRANSLATORS: this is the end of "Looking up %s ... " */
> +
Nguyễn Thái Ngọc Duy writes:
> @@ -149,7 +149,7 @@ static void *get_delta(struct object_entry *entry)
> delta_buf = diff_delta(base_buf, base_size,
> buf, size, _size, 0);
> if (!delta_buf || delta_size != DELTA_SIZE(entry))
> - die("delta
Junio C Hamano writes:
>> @@ -622,7 +626,7 @@ int cmd_config(int argc, const char **argv, const char
>> *prefix)
>> * location; error out even if XDG_CONFIG_HOME
>> * is set and p
Nguyễn Thái Ngọc Duy 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
Nguyễn Thái Ngọc Duy 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
Nguyễn Thái Ngọc Duy writes:
> static void check_argc(int argc, int min, int max) {
> if (argc >= min && argc <= max)
> return;
> - error("wrong number of arguments");
> + if (min == max)
> + error("wrong number of arguments, should be %d", min);
> +
Stefan Beller writes:
> "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
Junio C Hamano writes:
> Johannes Schindelin writes:
>
>> I would like to ask you to reinstate the post-rewrite hook, as it still
>> improves the situation over the current one.
>
> Without post-rewrite I seem to be getting correct amlog entries for
> commits crea
Eric Sunshine writes:
> I guess the two fixup!'s were meant to be squashed (and it's probably
> too late to do so now?).
I guess so. That is what we get from trying to be nice to reduce
the number of iterations and cheating by short-circuitting the
process X-<.
Stefan Beller writes:
>> It seems to pass its own self-tests standalone, but seems to break
>> horribly when merged to 'pu'.
>
> It actually breaks combined with sb/submodule-core-worktree :-(
> as that introduces another user of $name in git-submodule.sh
> which we eliminate in this series.
Stefan Beller writes:
> On Wed, Jul 18, 2018 at 10:45 AM Junio C Hamano wrote:
>>
>> Stefan Beller writes:
>>
>> > diff --git a/Documentation/diff-options.txt
>> > b/Documentation/diff-options.txt
>> > index 143acd9417e..8da7fed4e22 100644
>
Ben Peart writes:
> + * Fetch the tree from the ODB for each peer directory in the
> + * n commits.
> + *
> + * For 2- and 3-way traversals, we try to avoid hitting the
> + * ODB twice for the same OID. This should yield a nice speed
> + * up in checkouts and
Jeff King writes:
> This was added as a NEEDSWORK in 3c36d7de2 (replace-object:
I'll do s/3c36d7de2/c&/; while queuing.
Like you, I do not think one is vastly better than the other between
these two names, but since a patch has been written, so ...
> check_replace_refs is safe in multi repo
Jeff King writes:
> Commit afc711b8e1 (rename read_replace_refs to
> check_replace_refs, 2014-02-18) added a comment mentioning
> that check_replace_refs is set in two ways:
>
> - from user intent via --no-replace-objects, etc
>
> - after seeing there are no replace refs to respect
>
> Since
Signed-off-by: Stefan Beller
> - Signed-off-by: Junio C Hamano
>
> diff --git a/builtin/submodule--helper.c b/builtin/submodule--helper.c
> --- a/builtin/submodule--helper.c
> @@ -74,7 +73,7 @@
> +deter
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'. The ones marked with '.' do not appear in any of
the integration branches, but I am still holding onto them.
Many topics have moved to
Eric Sunshine writes:
> I did consider placing the range-diff before the diffstat, however,
> what convinced me to position range-diff last was that the diffstat is
> usually short and easy to skip over both visually and via scrolling,
> whereas the range-diff often is long and noisy, thus more
Stefan Beller writes:
>> - existing users of for_each_replace_ref() who were all happy
>>working in the_repository have to pass it explicitly, even
>>thought they do not have any need to.
>
> All callbacks that are passed to for_each_replace_ref now
> operate on 'r' instead of
Jeff King writes:
> On Wed, Jul 18, 2018 at 11:19:01AM -0700, Junio C Hamano wrote:
>
>> > It's also still inconsistent in the daemonize case. The run that yields
>> > the error won't return a non-zero exit. But the next run will exit with
>> > "2
"Stefan Beller via GitGitGadget" writes:
> From: Stefan Beller
>
> Signed-off-by: Stefan Beller
> Signed-off-by: Derrick Stolee
> ---
> builtin/replace.c | 8
> refs.c| 9 -
> refs.h| 2 +-
> replace-object.c | 5 +++--
> 4 files changed, 12
Andrei Rybak writes:
> Add missing colon in two places to fix formatting of options.
>
> Signed-off-by: Andrei Rybak
> ---
>
> Done on top of maint.
>
> The earliest this patch applies is on top of commit aebd23506e ("Merge
> branch 'jk/ui-color-always-to-auto-maint' into
>
Jeff King writes:
>> Perhaps we should exit with 2 (not 0) in that "previous error" case
>> by default, and then have a configuration knob to turn that 2 into 0
>> for those who cannot easily modify the calling script? That way, we
>> by default will *not* break those who have been paying
mory leaks in ref-filter: that would
>> > be my next task that I will work on. Since I did not generate any new
>> > leaks in this patch (just use existing ones), I decided to put this
>> > part on a review and fix leaks as a separate task.
>>
>> UPDATES since v1:
esn't care if a space separates it and
the filename it reads from.
With SunOS sed, the space is required.
Signed-off-by: Alejandro R. Sedeño
Reviewed-by: Eric Sunshine
Signed-off-by: Junio C Hamano
---
Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a
Stefan Beller 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=::
> This
Phillip Wood writes:
>> The only consumer of a faulty author script written by the sequencer
>> is read_env_script() in sequencer.c which doesn't worry about
>> checking that quotes are paired.
>
> That's not quite true anymore, recently another consumer
> read_author_ident() was added which
Phillip Wood writes:
>> (I think we had code to do so in "git am"
>> that was rewritten in C first).
>
> The code in builtin/am.c doesn't try to write valid posix shell (if
> one assumes it is the only consumer of the author script then it
> doesn't need to) which results in simpler code, but
Henning Schild writes:
>> > + unset GIT_COMMITTER_EMAIL &&
>> > + git config user.email hasno...@nowhere.com &&
>> > + git config user.signingkey "" &&
>> > + test_must_fail git push --signed dst noop ff +noff &&
>>
>> This is OK for a test that is known to be always at the end, but
>>
Duy Nguyen writes:
>> In other words: if you see something that you don't like about
>> GitGitGadget, get your butts off the ground and contribute a fix.
>
> Thank you for the frank words. I will choose to not review any mails
> coming from GitGitGadget.
I wouldn't say I will choose not to, but
Jeff King writes:
>> There's nothing for the calling program to act on on the basis of that
>> error. Use status 0 consistently instead, to indicate that we decided
>> not to run a gc (just like if no housekeeping was required). This
>> way, repo and similar tools can get the benefit of the
I'll squash the following in (which I have been carrying in 'pu' for
the past few days) unless I hear otherwise soonish to correct the
issues raised during the review.
Thanks.
t/t3404-rebase-interactive.sh | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git
Оля Тележная writes:
>> Hmph, doesn't this belong to the previous step? In other words,
>> isn't the result of applying 1-3/4 has a bug that can leave eaten
>> uninitialized (and base decision to free(buf) later on it), and
>> isn't this change a fix for it?
>
> Oh. I was thinking that it was
SZEDER Gábor writes:
>> +fprintf(stdout, submodule_strategy_to_string(_strategy));
>
> Various compilers warn about the potential insecurity of the above
> call:
>
> CC builtin/submodule--helper.o
> builtin/submodule--helper.c: In function ‘module_update_module_mode’:
>
Stefan Beller writes:
>> As I most often edit the log message and material below three-dash
>> lines (long) _after_ format-patch produced files, I do not think it
>> is a win to force me to push and ask to pull
>
> Ah, that is an interesting workflow. Do you keep patch files/emails
> around
Henning Schild writes:
> Test setting gpg.format to both invalid and valid values.
>
> Signed-off-by: Henning Schild
> ---
> t/t7510-signed-commit.sh | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/t/t7510-signed-commit.sh b/t/t7510-signed-commit.sh
> index
Henning Schild writes:
> diff --git a/t/lib-gpg.sh b/t/lib-gpg.sh
> index a5d3b2cba..3fe02876c 100755
> --- a/t/lib-gpg.sh
> +++ b/t/lib-gpg.sh
> @@ -38,7 +38,33 @@ then
> "$TEST_DIRECTORY"/lib-gpg/ownertrust &&
> gpg --homedir "${GNUPGHOME}" /dev/null 2>&1 \
Henning Schild writes:
> gnupg does print the keyid followed by a space and the signer comes
> next. The same pattern is also used in gpgsm, but there the key length
> would be 40 instead of 16. Instead of hardcoding the expected length,
> find the first space and calculate it.
> Input that does
Henning Schild writes:
> Create a struct that holds the format details for the supported formats.
> At the moment that is still just "openpgp". This commit prepares for the
> introduction of more formats, that might use other programs and match
> other signatures.
>
> Signed-off-by: Henning
Stefan Beller writes:
> Actually I thought it was really cool, i.e. when using your queued branch
> instead of my last sent branch, I can see any edits *you* did
> (including fixing up typos or applying at slightly different bases).
Absolutely. I did not say that there needs a mode to ignore
Paul-Sebastian Ungureanu writes:
> @@ -1769,7 +1831,8 @@ void maybe_die_on_misspelt_object_name(const char
> *name, const char *prefix)
>
> int get_oid_with_context(const char *str, unsigned flags, struct object_id
> *oid, struct object_context *oc)
> {
> - if (flags &
Paul-Sebastian Ungureanu writes:
> Add `get_tree_entry_gently()`, `find_tree_entry_gently()`
> and `get_tree_entry_follow_symlinks_gently()`, which will
> make `get_oid()` to be more gently.
>
> Since `get_tree_entry()` is used in more than 20 places,
> adding a new parameter will make this
5740 ! 1: bbc8697a8ca git-submodule.sh: align error reporting
>> for update mode to use path
>> @@ -6,7 +6,6 @@
>> on its path, so let's do that for invalid update modes, too.
>>
>> Signed-off-by: Stefan Beller
>> -Signed-of
Jonathan Nieder writes:
> A value of -1 returned from cmd_gc gets propagated to exit(),
> resulting in an exit status of 255. Use die instead for a clearer
> error message and a controlled exit.
>
> Signed-off-by: Jonathan Nieder
> ---
> As in
>
Jonathan Nieder writes:
> - avoid being confused by a gc.log larger than INT_MAX bytes
;-)
>
> Noticed by code inspection.
>
> Signed-off-by: Jonathan Nieder
> ---
Looks good.
Jonathan Nieder writes:
> That doesn't really solve the problem:
>
> 1. "gc --auto" would produce noise *every time it runs* until gc.log
> is removed, for example via expiry
>
> 2. "gc --auto" would not do any garbage collection until gc.log is
> removed, for example by expiry
>
> 3.
Junio C Hamano writes:
>> So, this SQUASH looks like the correct way forward. Hopefully, Junio
>> can just squash it so I don't have to flood the list again with this
>> long series.
>
> The topic already has another dependent topic so rerolling or
> squashing would
Junio C Hamano writes:
> But by splitting these into separate tests, the patch makes such a
> potential failure with "git commit --short" break the later steps.
>
> Not very nice.
>
> It may be a better change to just do in the original one
>
> git add tes
Samuel Lijin writes:
> diff --git a/wt-status.c b/wt-status.c
> index 75d389944..4ba657978 100644
> --- a/wt-status.c
> +++ b/wt-status.c
> @@ -718,6 +718,39 @@ static void wt_status_collect_untracked(struct wt_status
> *s)
> s->untracked_in_ms = (getnanotime() - t_begin) /
Samuel Lijin writes:
> To fix the breakages documented by t7501, the next patch in this series
> will teach wt_status_collect() to set the committable bit, instead of
> having wt_longstatus_print_updated() and show_merge_in_progress() set it
> (which is what currently happens). Unfortunately,
Samuel Lijin writes:
> The behavior of git commit when doing a dry run changes if there are
> unfixed/fixed merge conflits, but the test suite currently only asserts
> that `git commit --dry-run` succeeds when all merge conflicts are fixed.
>
> Add tests to document the behavior of all flags
Jeff King writes:
> I'm OK with having a partial fix, or one that fixes immediate pain
> without doing a big cleanup, as long as it doesn't make anything _worse_
> in a user-visible way. And that's really my question: is pruning here
> going to bite people unexpectedly (not rhetorical -- I
Jeff King writes:
> On Mon, Jul 16, 2018 at 02:56:34PM -0700, Junio C Hamano wrote:
>
>> >> I'm okay with us forcing "openpgp". That seems sane enough for now, and
>> >> if people scream loudly, we can loosen it.
>> >
>> >
Jonathan Tan writes:
> Introduce a new negotiation algorithm used during fetch that skips
> commits in an effort to find common ancestors faster. The skips grow
> similarly to the Fibonacci sequence as the commit walk proceeds further
> away from the tips. The skips may cause unnecessary commits
Jules Maselbas writes:
> The variable smtp_encryption must keep it's value between two batches.
> Otherwise the authentication is skipped after the first batch.
>
> Signed-off-by: Jules Maselbas
> ---
> git-send-email.perl | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff
Jeff King writes:
> On Sat, Jul 14, 2018 at 06:13:47PM +, brian m. carlson wrote:
>
>> On Tue, Jul 10, 2018 at 12:56:38PM -0400, Jeff King wrote:
>> > On Tue, Jul 10, 2018 at 12:54:13PM -0400, Jeff King wrote:
>> >
>> > > Should we allow:
>> > >
>> > > [gpg "OpenPGP"]
>> > > program =
Eric Sunshine writes:
> On Mon, Jul 16, 2018 at 11:51 AM Johannes Schindelin
> wrote:
>> On Mon, 16 Jul 2018, Johannes Schindelin wrote:
>> > > - git submodule add --force bogus-url submod &&
>> > > + git submodule add --force /bogus-url submod &&
>> >
>> > This breaks on
1601 - 1700 of 27729 matches
Mail list logo
