Johannes Sixt writes:
> The Windows CRT implements O_APPEND "manually": on write() calls, the
> file pointer is set to EOF before the data is written. Clearly, this is
> not atomic. And in fact, this is the root cause of failures observed in
> t5552-skipping-fetch-negotiator.sh and
Eric Sunshine writes:
> A here-doc tag can be quoted ('EOF') or escaped (\EOF) to suppress
> interpolation within the body. Although, chainlint recognizes escaped
> tags, it does not know about quoted tags. For completeness, teach it to
> recognize quoted tags, as well.
Is this step merely
Samuel Maftoul writes:
> I'm still missing tests and docs, but if agreed the feature is useful,
> I will write them.
I personally think branch.sort would have about the same value as
the existing tag.sort, so if a patch is done well, it is likely that
users would find it valuable, but let's
Nicholas Guriev writes:
> This eliminates an unnecessary prompt to continue after failed merger.
> The patch uses positional parameters to count files in the list. If only
> one iteration is remained, the prompt_after_failed_merge function is not
s/is remained/remains/, I think.
Other than
SZEDER Gábor writes:
> - echo $(git -C repo log --pretty="%ct" -1) \
> - $(git -C repo rev-parse one) >expect &&
> + {
> + git -C repo log --pretty=format:"%ct " -1 &&
> + git -C repo rev-parse one
> + } >expect &&
Heh, "format:"%ct " to make the
Nguyễn Thái Ngọc Duy writes:
> v4 has a bunch of changes
>
> - 1/5 is a new one to show indented tracing. This way it's less
> misleading to read nested time measurements
> - 3/5 now has the switch/restore cache_bottom logic. Junio suggested a
> check instead in his final note, but I think
Thomas Adam writes:
> On Sun, 12 Aug 2018 at 09:19, Nguyễn Thái Ngọc Duy wrote:
>
> Hi,
>
>> + trace_performance_leave("cache_tree_update");
>
> I would suggest trace_performance_leave() calls use __func__ instead.
> That way, there's no ambiguity if the function name ever changes.
René Scharfe writes:
> @@ -182,19 +181,10 @@ static int fsck_msg_type(enum fsck_msg_id msg_id,
> static void init_skiplist(struct fsck_options *options, const char
> *path)
> {
> - static struct oid_array skiplist = OID_ARRAY_INIT;
> - int sorted;
> FILE *fp;
> struct
Jeff King writes:
> The rule in Git has always been that your very first include must
> always be "git-compat-util.h" or an equivalent header that includes it
> first (like "cache.h"). This is mentioned in CodingGuidelines.
Glad to see that you already have written the above so I don't have
to
frede...@ofb.net writes:
> Hi Jonathan and Git developers,
>
> I poked around today and figured out how to reorder the command
> listings in the manual page, they are taken from git/command-list.txt
> so I just reorder the lines in that file (after disabling sorting in
>
"Johannes Schindelin via GitGitGadget"
writes:
> From: Johannes Schindelin
>
> When displaying a diff of diffs, it is possible that there is an outer
> `+` before a context line. That happens when the context changed between
> old and new commit. When that context line starts with a tab (after
Nguyễn Thái Ngọc Duy writes:
> Paths that only differ in case work fine in a case-sensitive
> filesystems, but if those repos are cloned in a case-insensitive one,
> you'll get problems. The first thing to notice is "git status" will
> never be clean with no indication what exactly is "dirty".
Duy Nguyen writes:
> I was careless and checked the wrong variable (should have checked
> nr_duplicates not state.nr_duplicates; the second is a pointer). So we
> always get this warning (and with no following list of files)
Heh, does that bug go away if you got rid of the pointer-ness of the
Коля Гурьев writes:
> 09.08.2018 18:44, Junio C Hamano пишет:
>> Unlike "-u', "-i" is supported by "git commit" which shares the
>> underlying implementation, and that is the historical reason why we
>> never had "-i" shorthand, I t
Johannes Schindelin writes:
> I'll just try to get that option parsing change in that Eric suggested,
> force-push, then wait for macOS and Linux builds to pass (trusting that
> Windows will follow suite) and hit /submit.
OK. Obviously receiving, applying and inspecting that result will
not be
Brandon Williams writes:
> Introduce a helper function "submodule_name_to_gitdir()" (and the
> submodule--helper subcommand "gitdir") which constructs a path to a
> submodule's gitdir, located in the provided repository's "modules"
> directory.
>
> This consolidates the logic needed to build up
Alban Gruin writes:
>> Hmph. It is easy enough to do the clean-up ourselves in this code,
>> instead of asking the caller to do so. On the other hand, stashing
>> of local changes is done by the caller, so it feels a bit strange
>> way to divide the labor between the two parts.
>>
>> Other
"Johannes Schindelin via GitGitGadget"
writes:
> +
> +#ifndef GIT_WINDOWS_NATIVE
> +int lock_or_unlock_fd_for_appending(int fd, int lock_it)
> +{
> + struct flock flock;
> +
> + flock.l_type = lock_it ? F_WRLCK : F_UNLCK;
> +
> + /* (un-)lock the whole file */
> + flock.l_whence
Alban Gruin writes:
> This rewrites complete_action() from shell to C.
>
> A new mode is added to rebase--helper (`--complete-action`), as well as
> a new flag (`--autosquash`).
>
> Finally, complete_action() is stripped from git-rebase--interactive.sh.
>
> The original complete_action() would
Jeff King writes:
> I have tried to help with the actual problem, by identifying the root
> cause (that the trace code's strategy is not fundamentally broken, but
> that it relies on O_APPEND whose guarantees are obviously not portable
> to Windows) and exploring possible solutions there
Johannes Sixt writes:
> As this buglet looks like a recurring theme, and a proper fix is
> preferable over repeated work-arounds. To me it looks like we need
> some sort of locking on Windows. Unless your friends at Microsoft have
> an ace in their sleeves that lets us have atomic O_APPEND the
Nguyễn Thái Ngọc Duy writes:
> +static void mark_duplicate_entries(const struct checkout *state,
> +struct cache_entry *ce, struct stat *st)
> +{
> + int i;
> + int *count = state->nr_duplicates;
> +
> + if (!count)
> +
Nguyễn Thái Ngọc Duy writes:
> There are lots of suggestions on optimizing this stuff, but since this
> problem does not affect me to begin with, I'm reluctant to make more
> changes and going to stay simple, stupid and slow. I could continue to
> do small updates if needed. But for bigger
Jeff King writes:
> Here it is as a patch on top of jt/fetch-negotiator-skipping, which lets
> us pursue any fix for interleaved trace output on Windows without the
> pressure of an impending flaky test.
>
> My gut says that looking into making O_APPEND work there is going to be
> the nicest
Jeff King writes:
> Here it is as a patch on top of jt/fetch-negotiator-skipping, which lets
> us pursue any fix for interleaved trace output on Windows without the
> pressure of an impending flaky test.
>
> My gut says that looking into making O_APPEND work there is going to be
> the nicest
Elijah Newren writes:
> A possibly crazy idea: Don't bother reporting the other filename; just
> report the OID instead.
>
> "Error: Foo.txt cannot be checked out because another file with hash
> is in the way." Maybe even add a hint for the user: "Run
> `git ls-files -s` to see see all files
Stefan Beller writes:
> All callers use oid_to_hex to convert the desired oid to a string before
> calling submodule_move_head. Defer the conversion to the
> submodule_move_head as it will turn out to be useful in a bit.
>
> Signed-off-by: Stefan Beller
> ---
> entry.c| 6 +++---
>
Jeff King writes:
> Even with keeping the order this can be done in a single linear pass.
> See filter_string_list() for an example.
Heh, I just wasted a few minutes saying the same; I should have
pointed him at these two lines ;-)
Stefan Beller writes:
> Signed-off-by: Stefan Beller
> ---
> sha1-array.c | 39 +++
> sha1-array.h | 3 +++
> 2 files changed, 42 insertions(+)
>
> diff --git a/sha1-array.c b/sha1-array.c
> index 265941fbf40..10eb08b425e 100644
> --- a/sha1-array.c
> +++
Martin Ågren writes:
> On 9 August 2018 at 00:17, Stefan Beller wrote:
>> A string list can be used as a stack, but should we? A later patch shows
>> how useful this will be.
>>
>> Signed-off-by: Stefan Beller
>> ---
>> string-list.c | 8
>> string-list.h | 6 ++
>> 2 files
Stefan Beller writes:
> It is a debugging aid, so it should print to the debugging channel.
Who says? In-tree code may say so, and I do not think any in-flight
topic up to 'pu' uses this to produce non-debugging output, but I do
not think it is healthy attitude to assume that you can take over
Junio C Hamano writes:
> Jeff King writes:
>
>> Are you sure that it's not well-defined? We open the path with O_APPEND,
>> which means every write() will be atomically positioned at the end of
>> file. So we would never lose or overwrite data.
>>
>> We do ou
Paul-Sebastian Ungureanu writes:
>> Good to see that the right way to forward a patch from another
>> person is used, but is this a GSoC project?
>
> Yes, it is. I forgot to add the [GSoC] tag in the last series of patches.
The reason I asked was because IIRC GSoC was not supposed to be team
Elijah Newren writes:
>> Of course, "git rm" and "git mv" must work sensibly, if we want this
>> change to be truly helpful--but if not, they need to be fixed ;-)
>
> That actually brings up an interesting question. Right now, if given
> a path that appears in the index but at a stage greater
Jeff King writes:
> Are you sure that it's not well-defined? We open the path with O_APPEND,
> which means every write() will be atomically positioned at the end of
> file. So we would never lose or overwrite data.
>
> We do our own buffering in a strbuf, writing the result out in a single
>
"Johannes Schindelin via GitGitGadget"
writes:
> From: Johannes Schindelin
>
> This function will be used to make write accesses in trace_write() a bit
> safer.
> ...
> To set a precedent for a better approach, let's introduce a proper
> abstraction: a function that says in its name precisely
d support from this fallback code, but
that would be making two backward incompatible changes in a single
commit, so let's avoid that for now. A follow-up change could do so
if desired.
Helped-by: Vojtech Myslivec
Helped-by: brian m. carlson
Helped-by: Jeff King
Signed-off-by: Junio C Hamano
Elijah Newren writes:
> 1) Representative example: A modify/delete conflict; the path in question
> in the working tree would have conflict information at the top of the file
> followed by the normal file contents; thus it could be of the form:
>
> HEAD
> Conflict hint: This
Elijah Newren writes:
> File/directory conflicts are somewhat difficult to resolve; by way of
> contrast, renames are much easier to handle. For file/directory
> conflicts, we already have to record the file under a different name in
> the working copy due to the directory being in the way; if
Jonathan Tan writes:
> +/*
> + * Write oid to the given struct child_process's stdin, starting it first if
> + * necessary.
> + */
> +static int write_oid(const struct object_id *oid, struct packed_git *pack,
> + uint32_t pos, void *data)
> +{
> + struct child_process *cmd =
Nicholas Guriev writes:
> It allows for uniformity with the --untracked-files option. Also
> the new short flag saves the number of keys to press for the
> typically git-status command.
Unlike "-u', "-i" is supported by "git commit" which shares the
underlying implementation, and that is the
Jeff King writes:
> There was a patch at the start of this thread, but it specifically
> checks for "sigc->result == U". That's probably OK, since I think it
> restores the behavior in earlier versions of Git. But I wonder if we
> should simply be storing the fact that gpg exited non-zero and
"brian m. carlson" writes:
>> FWIW, I'm on board with returning non-zero in any case where gpg would.
>
> I think that's probably the best solution overall.
FWIW, I am not married to the current behaviour. I would not be
surprised if it mostly came by accident and not designed.
> There's a
Jeff King writes:
> I had two minor comments on the first patch. I'll admit my eyes glazed
> over looking at the rest of them, and to make any kind of intelligent
> review I'd need to spend an hour understanding how the sed script works.
> Which frankly, I'm not sure is worth it.
Didn't I make
Jeff King writes:
> I think we really want to avoid doing that normalization ourselves if we
> can. There are just too many filesystem-specific rules.
Exactly; not having to learn these rules is the major (if not whole)
point of the "let checkout notice the collision and then deal with
it"
Junio C Hamano writes:
> Hmph, it came from this message (most headers omitted)
>
> To: =?iso-8859-1?Q?=C6var_Arnfj=F6r=F0?= Bjarmason
> Message-ID: <20180804085247.ge55...@aiede.svl.corp.google.com>
> Content-Type: text/plain; charset=iso-8859-1
>
Junio C Hamano writes:
> Ævar Arnfjörð Bjarmason writes:
>
>>> - else if (!strcmp(value, "preserve"))
>>> + else if (!strcmp(value, "preserve") || !strcmp(value, "p"))
>>> return REBASE_PRESERVE;
>>> - el
`git apply --index-info`.
Signed-off-by: Junio C Hamano
---
Documentation/git-update-index.txt | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/Documentation/git-update-index.txt
b/Documentation/git-update-index.txt
index 4e8e762e68..c62a683648 100644
Elijah Newren writes:
> The following phrase could be interpreted multiple ways:
> "To pretend you have a file with mode and sha1 at path"
>
> In particular, I can think of two:
> 1. Pretend we have some new file, which happens to have a given mode
> and sha1
> 2. Pretend one of the
Stefan Beller writes:
> This is a resend of sb/config-write-fix, with a slightly
> better commit message and a renamed variable.
>
> Thanks,
> Stefan
Thanks. Let's declare victory and mark it to be merged to 'next'.
Paul-Sebastian Ungureanu writes:
> From: Joel Teichroeb
>
> Add a builtin helper for performing stash commands. Converting
> all at once proved hard to review, so starting with just apply
> lets conversion get started without the other commands being
> finished.
>
> The helper is being
Ævar Arnfjörð Bjarmason writes:
>> -else if (!strcmp(value, "preserve"))
>> +else if (!strcmp(value, "preserve") || !strcmp(value, "p"))
>> return REBASE_PRESERVE;
>> -else if (!strcmp(value, "merges"))
>> +else if (!strcmp(value, "merges") || !strcmp(value, "m"))
>>
Stefan Beller writes:
> On Wed, Aug 8, 2018 at 6:51 AM Pratik Karki wrote:
>>
>> This commit introduces a rebase option `--quiet`. While `--quiet` is
>> commonly perceived as opposite to `--verbose`, this is not the case for
>> the rebase command: both `--quiet` and `--verbose` default to
Pratik Karki writes:
> This commit converts the equivalent part of the shell script
> `git-legacy-rebase.sh` to run the pre-rebase hook (unless disabled), and
> to interrupt the rebase with error if the hook fails.
>
> Signed-off-by: Pratik Karki
> ---
Introduction of upstream_arg in this step
Pratik Karki writes:
> This commit implements support for an --onto argument that is actually a
> "symmetric range" i.e. `...`.
>
> The equivalent shell script version of the code offers two different
> error messages for the cases where there is no merge base vs more than
> one merge base.
Pratik Karki writes:
> The `--onto` option is important, as it allows to rebase a range of
> commits onto a different base commit (which gave the command its odd
> name: "rebase").
Is there anything unimportant? A rhetorical question, of course.
The quite casual and natural use of "to rebase"
Junio C Hamano writes:
> Junio C Hamano writes:
>
>> not used behind is *not* OK. And lack of restoring the bottom in
>> the new codepath makes me suspect exactly such a bug _after_ the
>> traversal exits the subtree we are using this new optimization in
>> an
Junio C Hamano writes:
> not used behind is *not* OK. And lack of restoring the bottom in
> the new codepath makes me suspect exactly such a bug _after_ the
> traversal exits the subtree we are using this new optimization in
> and moves on.
Hmph, thinking about this further, I can
Duy Nguyen writes:
> On Mon, Aug 6, 2018 at 5:48 PM Junio C Hamano wrote:
>> > I've also checked about the lookahead thing in unpack_trees() to see
>> > if we accidentally break something there, which is my biggest worry.
>> > See [1] and [2] for context, but I b
Jonathan Tan writes:
>> Just a note (and a request-for-sanity-check) and not meant to be a
>> request to update the code, but with a still-in-pu 4b757a40 ("Use
>> remote_odb_get_direct() and has_remote_odb()", 2018-08-02) in
>> flight, repository_format_partial_clone is now gone.
>> ...
> Thanks
Jeff King writes:
> I think that the for_each_packed_object() interface should visit items
> in pack order.
Yeah, that may make more sense. Any order is more logical than the
object name order (which by definition is random, so useful only
when you want them in a random order), and pack order
"Johannes Schindelin via GitGitGadget"
writes:
> I stumbled over the one in git-compat-util.h while working on an unrelated
> bug fix, and then got curious whether there are other places where we use
> save instead of safe, too. Turns out we do not, but there was another
> grammar error where a
Eric Sunshine writes:
> What does concern me is that read_env_script() doesn't seem to care
> about such a malformed file; it doesn't do any validation at all.
> Contrast that with read_author_ident() which is pretty strict about
> the content it expects to find in the file. So, it might make
Jonathan Tan writes:
>> each other [*1*], so listing them in the offset order (with made-up
>> pathname information to _force_ that objects that live close
>> together in the original pack are grouped together by getting
>> similar names) might give us a better than horrible deltification.
>> I
Brandon Williams writes:
> Introduce a function "strbuf_submodule_gitdir()" which callers can use
> to build a path to a submodule's gitdir. This allows for a single
> location where we can munge the submodule name (by url encoding it)
> before using it as part of a path.
I am not sure about
Jonathan Tan writes:
> @@ -293,6 +346,9 @@ int cmd_repack(int argc, const char **argv, const char
> *prefix)
> if (pack_everything & ALL_INTO_ONE) {
> get_non_kept_pack_filenames(_packs, _pack_list);
>
> + if (repository_format_partial_clone)
> +
Junio C Hamano writes:
> if test -z "$module_path"
> then
> for candidate in \
> /etc/httpd \
> /usr/lib/apache2 \
> /usr/lib/httpd \
I obviously missed semicolon
Sebastian Kisela writes:
> On Fedora-derived systems, the apache httpd package installs modules
> under /usr/lib{,64}/httpd/modules, depending on whether the system is
> 32- or 64-bit. A symlink from /etc/httpd/modules is created which
> points to the proper module path. Use it to support
Eric Sunshine writes:
> On Mon, Aug 6, 2018 at 9:20 PM Hilco Wijbenga
> wrote:
>> But your suggestion did make me think about what behaviour I would
>> like to see, exactly. I like that Git removes commits that no longer
>> serve any purpose (because I've included their changes in earlier
>>
Han-Wen Nienhuys writes:
> Fix nits; remove debug printf.
>
> Han-Wen Nienhuys (1):
> sideband: highlight keywords in remote sideband output
>
> Documentation/config.txt| 12 +++
> help.c | 1 +
> help.h | 1 +
>
Jonathan Tan writes:
> +static int write_oid(const struct object_id *oid, struct packed_git *pack,
> + uint32_t pos, void *data)
> +{
> + int fd = *(int *)data;
> +
> + xwrite(fd, oid_to_hex(oid), GIT_SHA1_HEXSZ);
> + xwrite(fd, "\n", 1);
> + return 0;
> +}
> +
>
Nguyễn Thái Ngọc Duy writes:
> One nice thing about this is we don't need platform specific code for
> detecting the duplicate entries. I think ce_match_stat() works even
> on Windows. And it's now equally expensive on all platforms :D
ce_match_stat() may not be a very good measure to see
Elijah Newren writes:
>> I think 0/5 should fix the real bug you are deliberately keeping in
>> this patch, from the point of view of organization.
>
> You mean 5/5? And yeah, it was just a temporary thing for
> organizational purposes.
I meant "a thing that comes before all the other steps".
Elijah Newren writes:
> A test making use of test_must_fail was failing like this:
> fatal: ambiguous argument '|': unknown revision or path not in the working
> tree.
> when the intent was to verify that a specific string was not found
> in the output of the git diff command, i.e. that grep
Elijah Newren writes:
> test -e, test -s, etc. do not provide nice error messages when we hit
> test failures, so use the test_* helper functions from
> test-lib-functions.sh.
Good explanation.
> Note: The use of 'test_path_is_file submodule/.git' may look odd, but
> it is a file which is
Elijah Newren writes:
> We can get rid of some quoted tabs and make a few tests slightly easier
> to read and edit by just asking for the names of the files modified,
> since that's all these tests were interested in anyway.
Technically the quoted tab was making sure that we do not mistake
Phillip Wood writes:
> Yes I think the earlier approach with the more robust detection you
> suggested is probably a good compromise. Junio does that sound good to
> you?
Surely, and thanks.
Jonathan Nieder writes:
> Both don't seem quite right, since they have an extra space before the
> period. The git-diff(1) seems especially not quite right --- does it
> intend to say something like "See the DIFF ALGORITHMS section for more
> discussion"?
Good suggestion and doing so would
Ævar Arnfjörð Bjarmason writes:
> On Mon, Aug 06 2018, Junio C Hamano wrote:
>
>> * ab/newhash-is-sha256 (2018-08-06) 2 commits
>> - doc hash-function-transition: pick SHA-256 as NewHash
>> - doc hash-function-transition: note the lack of a changelog
>
Ævar Arnfjörð Bjarmason writes:
> On Mon, Aug 06 2018, Junio C Hamano wrote:
>
>> * ab/newhash-is-sha256 (2018-08-06) 2 commits
>> - doc hash-function-transition: pick SHA-256 as NewHash
>> - doc hash-function-transition: note the lack of a changelog
>
Jakub Narebski writes:
> Junio C Hamano writes:
>
>> * ds/commit-graph-with-grafts (2018-07-19) 8 commits
>> (merged to 'next' on 2018-08-02 at 0ee624e329)
>> ...
>> Will merge to 'master'.
>
> Derrick wrote that he will be sending v2 of this patch 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
Han-Wen Nienhuys writes:
>> If your "make test" did not catch this as an error, then we may need
>> to fix t/Makefile, as it is supposed to run test-lint.
>
> I've been running tests individually as
>
> sh t5409-colorize-remote-messages.sh -v -d
During your own development that may be
Stefan Beller writes:
> On Sat, Aug 4, 2018 at 9:57 AM Junio C Hamano wrote:
>>
>> Stefan Beller writes:
>>
>> > This builds on top of sb/range-diff-colors, which builds on js/range-diff.
>>
>> As another round of js/range-diff is expected, according t
Andrei Rybak writes:
> Tests for "git am --[no-]scissors" [1] work in the following way:
>
> 1. Create files with commit messages
> 2. Use these files to create expected commits
> 3. Generate eml file with patch from expected commits
> 4. Create commits using git am with these eml files
>
"Johannes Schindelin via GitGitGadget"
writes:
> From: Johannes Schindelin
>
> Git for Windows' original 4aa8b8c8283 (Teach 'git pull' to handle
> --rebase=interactive, 2011-10-21) had support for the very convenient
> abbreviation
>
> git pull --rebase=i
>
> which was later lost when it
Jeff King writes:
>> > + case "$1" in
>> > + -j)
>> > + parallel=${1#-j} ;;
>>
>> This is curious. Did you mean "-j*)" on the line above this one?
>
> Hmph, yes, I think this was broken even in the original. And after going
> through "rev-parse --parseopt", we should have a separate
Duy Nguyen writes:
> We require the unpacked entry from all input trees to be a tree
> objects (the dirmask thing), so if one tree has 't' as a file,
Ah, OK, this is still part of that "all the trees match cache tree
so we walk the index instead" optimization. I forgot about that.
Jeff King writes:
> +while test $# -gt 0
> +do
> + case "$1" in
> + -j)
> + parallel=${1#-j} ;;
This is curious. Did you mean "-j*)" on the line above this one?
> + -f)
> + force=t ;;
> + --)
> + shift; break ;;
> + *)
> +
Han-Wen Nienhuys writes:
>> I think the code is OK without any assert() or BUG(), and that is
>> because the design is "we just paint the keyword at the beginning of
>> what the other side of the sideband wants us to show as a single
>> unit". If the other side sends a payload with an embedded
Antonio Ospite writes:
>> I also do not see a reason why we want to stop referring to
>> .gitmodules explicitly by name. We do not hide the fact that
>> in-tree .gitignore and .gitattributes files are used to hold the
>> metainformation about the project tree, saying that it is an
>>
Han-Wen Nienhuys writes:
> The Git push process itself prints lots of non-actionable messages
> (eg. bandwidth statistics, object counters for different phases of the
> process), which obscures actionable error messages that servers may
s/which obscures/which obscure/, as I think that "which"
Han-Wen Nienhuys writes:
> Signed-off-by: Han-Wen Nienhuys
> ---
> config.h | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
I think this is good (I read all the comments on v3 and v4 in the
archive before I said this). Let's split it off from the other
patch and queue it on its
Nguyễn Thái Ngọc Duy writes:
> This is a minor update to address Ben's comments and add his
> measurements in the commit message of 2/4 for the record.
Yay.
> I've also checked about the lookahead thing in unpack_trees() to see
> if we accidentally break something there, which is my biggest
Jeff King writes:
> On Mon, Aug 06, 2018 at 09:39:55AM -0400, Jeff King wrote:
>
>> 3. Default to number of CPUs, which is what a lot of other threading
>> in Git does. Unfortunately getting that from the shell is
>> non-trivial. I'm OK with $(grep -c ^processor /proc/cpuinfo), but
Johannes Schindelin writes:
>> If we ever see a todo-list without any pick/merge, then insert_final
>> is still 1 when we leave the loop and we will add one single exec at
>> the end. Which may or may not make sense---I dunno, as I do not
>> offhand think of a reason why the user would give us
Paul Tan writes:
> I've taken a look at the original test, and it is pretty broken. My
> ...
> So, there are 3 problems that will need to be fixed.
> ...
> This fixes problem (3) by using an in-body header.
> ...
> This fixes the first half of problem (2) by making the naming of the
> files the
Stefan Beller writes:
>> You are the second one who were negatively affected by Stefan's
>> "summary" that reads a lot more in what I said than what actually
>> was said by me. Stop paying attention to that message, but do go to
>> the original if you want to hear what I actually said.
>
>
"Johannes Schindelin via GitGitGadget"
writes:
> From: Johannes Schindelin
>
> Technically, it is okay to have line ranges that touch (i.e. the end of
> the first range ends just before the next range begins). However, it is
> inefficient, and when the user provides such touching ranges via
>
Johannes Schindelin writes:
> Hi Junio,
>
> On Thu, 2 Aug 2018, Junio C Hamano wrote:
>
>> * pk/rebase-in-c (2018-07-30) 3 commits
>> - builtin/rebase: support running "git rebase "
>> - rebase: refactor common shell functions into their o
1301 - 1400 of 27729 matches
Mail list logo
