"Johannes Schindelin via GitGitGadget"
writes:
> From: Johannes Schindelin
>
> The Azure Pipelines builds are failing for macOS due to a change in the
> location of the perforce cask. The command outputs the following error:
>
> + brew install caskroom/cask/perforce
> Error: caskroom/cas
The existing wording gives an impression that it only gives the
contents of the $GIT_DIR/rebase-apply/patch file, i.e. the patch
proper, but the option actually emits the entire e-mail message
being processed (iow, one of the output files from "git mailsplit").
Signed-off-by: Juni
Emily Shaffer writes:
> +# Commit
> +
> +This is the one we're all familiar with - commits are those things we write
> at
> +1am, angry at a pesky bug, and label with something like "really fix it this
> +time", right?
> +
> +A commit references exactly one tree. That's the root directory of you
Eric Wong writes:
> What Konstantin said about git repos being transient.
> It wasn't too much work to recreate those blobs from
> scratch since git-apply has done it since 2005.
;-)
> We could get around transient repos with automatic mirroring
> bots which never deletes or overwrites anything
SZEDER Gábor writes:
>> - b9317d55a3 added two new keys to the trie: 'logs/refs/rewritten'
>> and 'logs/refs/worktree', next to the already existing
>> 'logs/refs/bisect'. This resulted in a trie node with the path
>> 'logs/refs', which didn't exist before, and which doesn't have a
"Derrick Stolee via GitGitGadget" writes:
> V4 UPDATE: Rebased on latest master to include ew/hashmap and
> ds/include-exclude in the base.
>
> This series makes the sparse-checkout feature more user-friendly. While
> there, I also present a way to use a limited set of patterns to gain a
> signif
Derrick Stolee writes:
>> I'm slightly wary of changing the output of plumbing commands
>> like this. If a script wants progress output it can already get
>> it by passing --verbose. With this change a script that does not
>> want that output now has to pass --no-verbose.
>
> If a script is calli
SZEDER Gábor writes:
>> +char *base = buf->buf + git_dir_len, *base2 = NULL;
>> +
>> +if (ends_with(base, ".lock"))
>> +base = base2 = xstrndup(base, strlen(base) - 5);
>
> Hm, this adds the magic number 5 and calls strlen(base) twice, because
> ends_with() calls strip_suffix(
"Johannes Schindelin via GitGitGadget"
writes:
> In dcb500dc16c (cherry-pick/revert: advise using --skip, 2019-07-02), we
> introduced a helpful message that suggests to run git cherry-pick --skip
> (instead of the previous message that talked about git reset) when a
> cherry-pick failed due to
"Johannes Schindelin via GitGitGadget"
writes:
> Note: we take pains to handle the situation when a user runs a `git
> cherry-pick` _during_ a rebase. This is quite valid (e.g. in an `exec`
> line in an interactive rebase). On the other hand, it is not possible to
> run a rebase during a cherry-p
Jerome Pouiller writes:
> Hello all,
>
> I try to use "git am" to apply a patch sent using "git send-email". This
> patch does not apply properly. I try to use "git am --show-current-patch"
> to understand the problem. However, since original mail is encoded in quoted-
> printable, data returned
Denton Liu writes:
> According to t/README, test_must_fail() should only be used to test for
> failure in Git commands. Replace the invocations of
> `test_must_fail grep` with `! grep`.
>
> Signed-off-by: Denton Liu
> ---
> *sigh* Here's another cleanup patch for 'dl/submodule-set-branch'. It's
Emily Shaffer writes:
>> ...
>> +/**
>> + * The config API gives callers a way to access Git configuration files
>> + * (and files which have the same syntax). See linkgit:git-config[1] for a
>
> Ah, here's another place where the Asciidoc link isn't going to do
> anything anymore.
>
> Otherwise
Johannes Schindelin writes:
> However, I think this is _really_ ugly and intrusive. The opposite of
> what my goals were.
>
> So I think I'll just bite the bullet and use a temporary copy if the
> argument ends in `.lock`.
Sounds like a quite sensible design decision to me.
Bert Wesarg writes:
> Please ignore this. Will rebase on 2.24-rc0 and will only include the
> test changes.
Thanks.
"Johannes Schindelin via GitGitGadget"
writes:
> Changes since v1:
>
> * Fixed typo "nore" -> "nor" in the commit message.
>
> Johannes Schindelin (2):
> ci(visual-studio): use strict compile flags, and optimization
> ci(visual-studio): actually run the tests in parallel
>
> azure-pipelines
Jeff King writes:
> But here's where it gets tricky. In addition to catching any size
> mismatches, this will also catch signedness problems. I.e., if we make
> OPT_INTEGER() use "intp", then everybody passing in &unsigned_var now
> gets a compiler warning. Which maybe is a good thing, I dunno.
Emily Shaffer writes:
> As for the content of this change, I absolutely approve. I've stumbled
> across some of these empty docs while looking for answers before and
> found it really demoralizing - the community is so interested in
> teaching me how to contribute that they've sat on a TODO for 1
Prarit Bhargava writes:
> Subject: Re: [PATCH] pretty: Add "%aU"|"%au" option to output author's
> username
Downcase "Add" (see "git shortlog --no-merges -100 master" and
mimick the project convention).
> Add a "%aU"|"%au" option that outputs the author's email username.
Even though I persona
Johannes Schindelin writes:
>> This is already in 'next' X-<; reverting a merge is cheap but I
>> prefer to do so when we already have a replacement.
>
> I force-pushed (see https://github.com/gitgitgadget/git/pull/400), and
> once Stolee approves, he will submit v3. This will only change the
> c
Jeff King writes:
>> ...
>> I agree with you that it did correctly sort them in ASCII order.
>
> What's the purpose of sorting them, though? I thought it was less for
> aesthetics and more to to keep lines deterministic (to avoid two
> branches adding the same line in different places, thus causi
Johannes Schindelin writes:
>> ... I do not particularly see this change (there may be similar
>> ones) desirable. I'd find it it be much more natural to sort
>> "commit-anything" after "commit", and that is true with or without
>> the common extension ".o" added to these entries.
>>
>> In short
Jeff King writes:
> I wondered if we could be a bit more clever with the definition of
> "struct option". Something like:
>
> diff --git a/parse-options.h b/parse-options.h
> index 38a33a087e..99c7ff466d 100644
> --- a/parse-options.h
> +++ b/parse-options.h
> @@ -126,7 +126,10 @@ struct option {
Emily Shaffer writes:
> +Under the covers, Git is mostly a directed graph of objects. Those objects
> come
> +in four flavors; from root to leaf (generally), those flavors are:
Is "acyclic" worth mentioning, I wonder.
> +
> +- Tag
> +- Commit
> +- Tree
> +- Blob
> +
> +We'll take a closer look
Philip Oakley writes:
> diff --git a/Documentation/git-config.txt b/Documentation/git-config.txt
> index 899e92a1c9..d4c792076d 100644
> --- a/Documentation/git-config.txt
> +++ b/Documentation/git-config.txt
> @@ -107,7 +107,7 @@ OPTIONS
> For writing options: write to global `~/.gitconfig
Denton Liu writes:
> Since --preserve-merges has been deprecated in favour of
> --rebase-merges, mark this option as hidden so it no longer shows up in
> the usage and completions.
>
> Signed-off-by: Denton Liu
> ---
> This patch continues the deprecation effort and can be based on top of
> `js/
Philip Oakley writes:
> @@ -20,11 +20,14 @@ DESCRIPTION
> Some workflows require that one or more branches of development on one
> machine be replicated on another machine, but the two machines cannot
> be directly connected, and therefore the interactive Git protocols (git,
> +ssh, http) cann
SZEDER Gábor writes:
> On Thu, Oct 17, 2019 at 12:47:33PM +, Johannes Schindelin via
> GitGitGadget wrote:
>> From: Johannes Schindelin
>>
>> The CI builds are failing for Mac OS X due to a change in the
>
> s/CI/Azure Pipelines/
>
> Our Travis CI builds are fine.
>
>> location of the perf
Peter Jones writes:
[jc: won't repeat comments on the title]
> @@ -360,6 +360,12 @@ void die_if_checked_out(const char *branch, int
> ignore_current_worktree)
> wt = find_shared_symref("HEAD", branch);
> if (!wt || (ignore_current_worktree && wt->is_current))
> return;
Peter Jones writes:
Same comment on the commit title as 1/4; also, we tend not to upcase
the first word after the : word and omit the full-stop on the
title (see "git shortlog -32 --no-merges" on our project for
examples).
> Add delete_worktrees_dir_if_empty() and prune_worktree() to the public
Peter Jones writes:
> Subject: Re: [PATCH v2 1/4] libgit: Add a read-only helper to test the
> worktree lock
Having a word "worktree" somewhere on the title is good, but have it
as the "I am changing this area"; "libgit" does not give readers the
hint that this is a step about the worktree subs
SZEDER Gábor writes:
> The reason for that bogus value is that '--total's parameter is parsed
> via parse-options's OPT_INTEGER into a uint64_t variable [1]...
>
> Change the type of that variable from uint64_t to int, to match what
> parse-options expects; in the tests of the progress output we
Philip Oakley writes:
> branch..merge::
> Defines, for the local branch , the upstream branch ref
> _on the remote_ (as given by branch..remote).
> The upstream ref may be different from the local branch ref.
>
> optionally s/different from/ same as/ ?
That "optionally" part is exact
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.
A preview release 2.24-rc0 has bee
Couder, Clément Chigot, Corentin BOMPARD, David Turner,
Denton Liu, Derrick Stolee, Elijah Newren, Emily Shaffer,
Eric Wong, Gabriele Mazzotta, Jeff Hostetler, Jeff King,
Johannes Schindelin, Johannes Sixt, Jonathan Tan, Jon Simons,
Josh Steadmon, Junio C Hamano, Martin Ågren, Masaya Suzuki,
"Carlo Marcelo Arenas Belón via GitGitGadget"
writes:
> builtin/grep.c | 1 +
> grep.c | 34 +-
> grep.h | 1 +
> 3 files changed, 35 insertions(+), 1 deletion(-)
>
> +#if defined(USE_LIBPCRE2)
> + if (!pcre2_global_context)
> +
Philip Oakley writes:
> branch..merge::
> Defines, together with branch..remote, the upstream branch
> - for the given branch. It tells 'git fetch'/'git pull'/'git rebase' which
> + for the given branch. It defines the branch name _on the remote_,
> + which may be different fro
"Johannes Schindelin via GitGitGadget"
writes:
> From: Johannes Schindelin
>
> Ever since worktrees were introduced, the `git_path()` function _really_
> needed to be called e.g. to get at the path to `logs/HEAD` (`HEAD` is
> specific to the worktree). However, the wrong path is returned for
> `
Derrick Stolee writes:
> I hit this very situation recently when I was experimenting with
> 'git fast-import' and accidentally created many parallel, independent
> histories. Running "git log --graph --all --simplify-by-decoration"
> made it look like all the refs were in a line, but they were no
Doan Tran Cong Danh writes:
> Documentation/git-notes.txt | 6 +++---
> builtin/notes.c | 2 +-
> t/t3301-notes.sh| 40 +++--
> 3 files changed, 42 insertions(+), 6 deletions(-)
Thanks, makes sense.
Doan Tran Cong Danh writes:
> If we accidentally lifted the check inside our code base, the test may
> still failed because the provided parameter is not a valid ref.
Makes sense. Another option would be to use a valid ref to make
sure there are no other possible reason for the command to fail,
Denton Liu writes:
> There are many += lists in the Makefile and, over time, they have gotten
> slightly out of order, alphabetically. Alphabetically sort all += lists
> to bring them back in order.
> ...
Hmm. I like the general thrust, but ...
> LIB_OBJS += combine-diff.o
> -LIB_OBJS += comm
Jeff King writes:
> I think this is a good distinction to draw, but...
>
>> Documentation/git-commit-tree.txt | 6 ++
>> 1 file changed, 6 insertions(+)
>
> ...I was surprised to see it here, where I think most users wouldn't
> find it. Would it make sense in git-commit(1), or in the descrip
"Hariom Verma via GitGitGadget" writes:
> -#define OUTPUT_SHOW_AGE_WITH_COLOR 04000
> +#define OUTPUT_ANNOTATE_COMPAT (1<<0)
> +#define OUTPUT_LONG_OBJECT_NAME (1<<1)
> +#define OUTPUT_RAW_TIMESTAMP(1<<2)
> +#define OUTPUT_PORCELAIN(1<<3)
> +#define OUTPUT_SHOW_NAME
"Hariom Verma via GitGitGadget" writes:
> we are looking at bitfield constants, and elsewhere in the Git source code,
> such cases are handled via bit shift operators rather than octal numbers,
> which also makes it easier to spot holes in the range (if, say, 1<<5 was
> missing, it is easier to s
SZEDER Gábor writes:
> However, I'm not sure what the right path should be in the first
> place, given that each working tree has its own 'logs' directory, but
> only for HEAD's reflog, while everything else goes to the main working
> tree's 'logs' directory.
As all worktrees should share the sa
"brian m. carlson" writes:
> Yeah, my default editor configuration for AsciiDoc is two spaces. I
> noticed that Junio's already picked it up for next, but I'll send a v2
> with this fixed in case he wants to merge the fixed version to master
> instead.
>
> If it's more convenient, I can send a f
Jeff King writes:
>> Hmm, I am kind of surprised that the decoding side allowed such a
>> padding.
>
> IIRC, the "padding" is just a sequence of 0-length-plus-continuation-bit
> varint bytes. And for some reason it worked for the size but not for the
> delta offset value.
I think the reason is b
Vegard Nossum writes:
> Step 1:
>
> * git send-email needs to include parent SHA1s and generally all the
> information needed to perfectly recreate the commit when applied so
> that all the SHA1s remain the same
>
> * git am (or an alternative command) needs to recreate the commit
> perfect
Jeff King writes:
> Maybe:
>
> 'git fetch', 'git pull', and 'git clone'
>
> ? Given the repetition below, though:
... including this one, I think you covered everything I wanted to
say on the patch already. Thanks.
Junio C Hamano writes:
>> int graph_next_line(struct git_graph *graph, struct strbuf *sb)
>
> I just noticed it but does this have to be extern? Nobody outside
> graph.[ch] seems to have any reference to it.
I was stupid; strike this part out.
Thanks.
"James Coglan via GitGitGadget" writes:
> This effect is applied to both "normal" two-parent merges, and to
> octopus merges. It also reduces the vertical space needed for pre-commit
> lines, as the merge occupies one less column than usual.
>
> Before: After:
>
> | *
"James Coglan via GitGitGadget" writes:
> From: James Coglan
>
> Now that the display width of graph lines is implicitly tracked via the
> `graph_line` interface, the calls to `graph_pad_horizontally()` no
> longer need to be located inside the individual output functions, where
> the character
"James Coglan via GitGitGadget" writes:
> +struct graph_line {
> + struct strbuf *buf;
> + size_t width;
> +};
> +
> +static inline void graph_line_addch(struct graph_line *line, int c)
> +{
> + strbuf_addch(line->buf, c);
> + line->width++;
> +}
> +
> +static inline void graph_li
James Coglan writes:
>> Is there a reason why you need a pointer to a strbuf that is
>> allocated separately? E.g. would it make it harder to manage
>> if the above were
>>
>> struct graphbuf {
>> struct strbuf buf;
>> int width; /* display width in columns */
>>
William Baker writes:
> At this time there are no other MIDX_* flags and so there's always the option
> to revisit the best way to handle multiple MIDX_* flags if/when additional
> flags are added.
I do not care too deeply either way, but if you wrote it in one way,
how about completing the seri
y.
> So unexperienced users could be misled by the original comment.
>
> There is a small update to clarify it.
>
> Helped-by: Johannes Schindelin
> Helped-by: Junio C Hamano
> Helped-by: SZEDER Gábor
> Signed-off-by: Maxim Belsky
> ---
> contrib/completion/git-compl
Doan Tran Cong Danh writes:
> The target objects for copying notes was defaulted to HEAD from very
> early stage of git-notes.
>
> However, that default was limited by commit bbb1b8a35a, ("notes: check
> number of parameters to "git notes copy"", 2010-06-28).
Sorry, I don't quite get the above.
Johannes Schindelin writes:
> Hi Phillip,
>
> On Tue, 15 Oct 2019, Phillip Wood via GitGitGadget wrote:
>
>> When I converted the sequencer to avoid forking git commit i forgot about
>> the post-commit hook. These patches are based on
>> pw/rebase-i-show-HEAD-to-reword, otherwise the new test fai
Thanks. I think we are ready for 'next'.
Elijah Newren writes:
>> * en/merge-recursive-directory-rename-fixes (2019-10-12) 2 commits
>> (merged to 'next' on 2019-10-15 at ebfdc3ff7b)
>> + merge-recursive: fix merging a subdirectory into the root directory
>> + merge-recursive: clean up get_renamed_dir_portion()
>>
>> A few glitches
Derrick Stolee writes:
> On 10/15/2019 3:11 AM, Eric Wong wrote:
>> Junio C Hamano wrote:
>>> Eric Wong writes:
>>>
>>>> I just took a brief look, but that appears to leak memory.
>>>>
>>>> "hashmap_free(var, 1)" s
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'. The ones marked with '.' do not appear in any of
the integration branches, but I am still holding onto them.
You can find the changes described
Eric Wong writes:
> I just took a brief look, but that appears to leak memory.
>
> "hashmap_free(var, 1)" should be replaced with
> "hashmap_free_entries(var, struct foo, member)"
>
> Only "hashmap_free(var, 0)" can become "hashmap_free(var)"
I deliberately avoided merge-time band-aid fixups on
Wink Saville writes:
> When --prefix-tags is passed to `git remote add` the tagopt is set to
> --prefix-tags and a second fetch line is added so tags are placed in
> a separate hierarchy per remote.
In the olden days, there was no refs/remotes/$remoteName/ hiearchy,
and until we made it the def
Denton Liu writes:
> diff --git a/builtin/log.c b/builtin/log.c
> index d212a8305d..af33fe9ffb 100644
> --- a/builtin/log.c
> +++ b/builtin/log.c
> @@ -1057,6 +1072,44 @@ static void show_diffstat(struct rev_info *rev,
> fprintf(rev->diffopt.file, "\n");
> }
>
> +static void pp_from_desc
Denton Liu writes:
> Since this
> seems to be a Python-ism that's mistakenly leaked into our code, convert
The conclusion is OK, but as the inventor of format-patch and a
non-pythonista, I do not think the above claim is correct, and even
if Thomas thought it was a good idea to follow Pytho
SZEDER Gábor writes:
>> -# The recommended way to install this script is to copy to '~/.zsh/_git',
>> and
>> -# then add the following to your ~/.zshrc file:
>> +# The recommended way to install this script is to make a copy of it in
>> +# ~/.zsh/ directory as ~/.zsh/git-completion.zsh and then
"kdnakt via GitGitGadget" writes:
> @@ -661,7 +662,7 @@ msgstr ""
> #: lib/merge.tcl:108
> #, tcl-format
> msgid "%s of %s"
> -msgstr "%s の %s ブランチ"
> +msgstr "%2$s の %1$s ブランチ"
>
> #: lib/merge.tcl:122
> #, tcl-format
> @@ -956,7 +957,7 @@ msgstr "エラー: コマンドが失敗しました"
> #: lib/checkout_op.t
René Scharfe writes:
> The first step for deleting an item from a linked list is to locate the
> item preceding it. Be more careful in release_request() and handle an
> empty list. This only has consequences for invalid delete requests
> (removing the same item twice, or deleting an item that w
Jakob Jarmar writes:
> git stash push does not recursively stash submodules, but if
> submodule.recurse is set, it may recursively reset --hard them. Having
> only the destructive action recurse is likely to be surprising
> behaviour, and unlikely to be desirable, so the easiest fix should be to
Denton Liu writes:
> Changes since v3:
>
> * Change --infer-cover-subject to --cover-from-description
>
> * No more test cleanup patches (they were merged in
> 'dl/format-patch-doc-test-cleanup')
With these patches, t4013 and t9902 seem to break, when queued on
top of dl/format-patch-doc-test-
Denton Liu writes:
> +format.coverFromDescription::
> + The default mode for format-patch to determine which parts of
> + the cover letter will be populated using the branch's
> + description. See the `--cover-from-description` option in
> + linkgit:git-format-patch[1].
> +
> for
Denton Liu writes:
> -#define THREAD_SHALLOW 1
> -#define THREAD_DEEP 2
> -static int thread;
> +enum thread_level {
> + THREAD_UNSET,
> + THREAD_SHALLOW,
> + THREAD_DEEP
> +};
> +static enum thread_level thread;
As the assignment of values do not change, this is a safe conversion
ev
Beat Bolli writes:
> diff --git a/utf8.c b/utf8.c
> index 3b42fadffd..5c8f151f75 100644
> --- a/utf8.c
> +++ b/utf8.c
> @@ -95,13 +95,11 @@ static int git_wcwidth(ucs_char_t ch)
> return -1;
>
> /* binary search in table of non-spacing characters */
> - if (bisearch(ch,
Jakob Jarmar writes:
> diff --git a/t/t3906-stash-submodule.sh b/t/t3906-stash-submodule.sh
> index d7219d6f8f..83106fa958 100755
> --- a/t/t3906-stash-submodule.sh
> +++ b/t/t3906-stash-submodule.sh
> @@ -1,6 +1,6 @@
> #!/bin/sh
>
> -test_description='stash apply can handle submodules'
> +tes
"Maxim Belsky via GitGitGadget" writes:
> Signed-off-by: Maxim Belsky
> Helped-by: Johannes Schindelin
> Helped-by: Junio C Hamano
No need to resend (as I'll fix it up locally while queuing), but
your sign-off comes last, as we keep these things chronological.
Wi
"William Baker via GitGitGadget" writes:
> +# Test staging/unstaging files that appear at the end of the index. Test
> +# file names begin with 'z' so that they are sorted to the end of the index.
Well, the test is now done in a freshly created repository, so the
z* files are the only thing yo
Daniel Lezcano writes:
> I would like to do something:
>
> git am -s -l "Link: https://lore.kernel.org/r/"
>
> Which will give:
>
> blabla
>
> Signed-off-by: aut...@kairnail.org
> Signed-off-by: commi...@kairnail.org
> Link: https://lore.kernel.org/r/
>
> This way it is compatible with patchwork,
Junio C Hamano writes:
> By the way, I think I made a mistake in my calendar math.
>
> This topic was merged to 'next' on the 7th and it is not especially
> tricky; unless I (or somebody else) find glaring issues in it during
> the final sanity check before merging it to
Jeff King writes:
> As a general rule (and why I'm raising this issue in reply to Jonathan's
> patch), I think most or all sites that want OBJECT_INFO_QUICK will want
> SKIP_FETCH_OBJECT as well, and vice versa. The reasoning is generally
> the same:
>
> - it's OK to racily have a false negativ
Jonathan Tan writes:
>> > Also, I have a slight preference for putting "= 02" on the BLAME_COPY
>> > line but that is not necessary.
>>
>> That is absolutely necessary; it is not like "we do not care what
>> exact value _COPY gets; it can be any value as long as it is _MOVE
>> plus 1", as these
James Coglan writes:
> - We don't want a general solution to this problem for everything
> `strbuf` could be used for; it only needs to address the graph
> padding problem.
Of course. Somebody may use strbuf to hold rows of a table and you
do not want to contaminate strbuf with fields like widt
Jeff King writes:
> The current code does so by creating a new entry in the reused_chunks
> array. In the worst case that can grow to have the same number of
> entries as we have objects. So this code was an attempt to pad the
> header of a shrunken entry to keep it the same size. I don't remembe
Elijah Newren writes:
> Did I shoot myself in the foot by being quick to jump on Rene's couple
> of cosmetic touch-up suggestions he posted over a week after the
> series was originally posted?
If the suggested updates were simple enough to do and would improve
the result sufficiently (which is
Elijah Newren writes:
>> * en/fast-imexport-nested-tags (2019-10-04) 8 commits
>> (merged to 'next' on 2019-10-07 at 3e75779e10)
>> + fast-export: handle nested tags
>> ...
>> + fast-export: fix exporting a tag and nothing else
>>
>> Updates to fast-import/export.
>>
>> Will merge to 'mast
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.
We may want to merge down fixes ac
Jakob Jarmar writes:
> git stash push does not recursively stash submodules, but if
> submodule.recurse is set, it may recursively reset --hard them. Having
> only the destructive action recurse is likely to be surprising
> behaviour, and unlikely to be desirable, so the easiest fix should be to
Denton Liu writes:
> In previous patches, extern was mechanically removed from function
> declarations without care to formatting, causing parameter lists to be
> misaligned. Manually format changed sections such that the parameter
> lists are realigned.
>
> Viewing this patch with 'git diff -w'
Johannes Schindelin writes:
> On Thu, 10 Oct 2019, Maxim Belsky via GitGitGadget wrote:
>
>> From: Maxim Belsky
>>
>> Signed-off-by: Maxim Belsky
>
> I totally agree with the patch, but only because I read a couple of
> reports that users were struggling with this. Maybe add a couple of
> refer
Emily Shaffer writes:
> @@ -77,6 +77,7 @@ API_DOCS = $(patsubst %.txt,%,$(filter-out
> technical/api-index-skel.txt technica
> SP_ARTICLES += $(API_DOCS)
>
> TECH_DOCS += MyFirstContribution
> +TECH_DOCS += MyFirstRevWalk
s/Rev/Object/ probably (if so I can locally amend).
> diff --git a/D
Johannes Schindelin writes:
> I should note that I looked through all of the hits of `git grep -w
> except -- t/` and did not find any other typo.
Thanks.
Thomas Gummerer writes:
> On 10/10, Johannes Schindelin via GitGitGadget wrote:
>> From: Johannes Schindelin
>>
>> The original phrasing of this paragraph made at least one person stumble
>> over the word "from" (thinking that it was a typo and "from" was
>> intended), and other readers chimed
Junio C Hamano writes:
> ... but I'd still wait for a few
> days for people who expressed their Acks but your scan missed, or
> those who wanted to give their Acks but forgot to do so, to raise
> their hands on this thread.
Now, two days and four hours have passed, so I'
Jeff King writes:
> This might provide an alternate solution (or vice versa). I kind of like
> this one better in that it doesn't require the sender to do anything
> differently (but it may be less robust, as it assumes the receiver
> reliably de-mangling).
I share the assessment. I also feel t
Johannes Schindelin writes:
>> diff --git a/builtin/commit.c b/builtin/commit.c
>> index d898a57f5d..adb8c89c60 100644
>> --- a/builtin/commit.c
>> +++ b/builtin/commit.c
>> @@ -1653,7 +1653,7 @@ int cmd_commit(int argc, const char **argv, const char
>> *prefix)
>>
>> repo_rerere(the_reposi
Johannes Schindelin writes:
>> builtin/commit.c | 22 --
>> commit.h | 3 ---
>> sequencer.c | 45 ++---
>> sequencer.h | 2 ++
>> 4 files changed, 36 insertions(+), 36 deletions(-)
>
> Hmm. I would have thought that
"Johannes Schindelin via GitGitGadget"
writes:
> To answer Jonathan's question, at long last, yes, it is useful. A hook is
> not only an opportunity to run code at given points in Git's life cycle, but
> also an opportunity to stop Git in its tracks.
In general that is correct, and especially so
Jonathan Tan writes:
>> -if ((opt & PICKAXE_BLAME_COPY_HARDEST)
>> -|| ((opt & PICKAXE_BLAME_COPY_HARDER)
>> +if ((opt & BLAME_COPY_HARDEST)
>> +|| ((opt & BLAME_COPY_HARDER)
>
> Any reason why the names are renamed to omit "PICKAXE_"? In particular,
> these names are stil
Jeff King writes:
> Yes, I agree that ordering and de-duplication rules are useful, too.
> Some of that can be expressed already in trailer.* config, but I don't
> know if it would be capable enough to do everything you want (though
> again, it would be really nice to _make_ it capable enough so
1 - 100 of 31372 matches
Mail list logo
