To make it clear, these headers files would allow for compile-time type safety.
When you are parsing serialized data into a data structure, you know
have header files that describe the data type(s).
It would be nice to not have to "guess" about the structure of the
JSON that git produces.
On Mon,
@git
I hear there is a movement underway to have git support JSON for the
purposes of machine readable stdio.
That is all good and well. I want to add to that request. Imagine a
software world were serialized data could be typed. So JSON produced
by C/C++ could be described and the receiving
On Mon, Aug 6, 2018 at 6:36 PM Junio C Hamano wrote:
> * pw/rebase-i-author-script-fix (2018-08-02) 2 commits
> - sequencer: fix quoting in write_author_script
> - sequencer: handle errors in read_author_ident()
> (this branch uses es/rebase-i-author-script-fix.)
>
> Recent "git rebase -i"
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
> commits). So I would not want to
On Tue, Jul 31, 2018 at 11:22 PM, Eric Sunshine wrote:
> On Tue, Jul 31, 2018 at 9:30 PM Hilco Wijbenga
> wrote:
>> On Tue, Jul 31, 2018 at 12:33 AM, Eric Sunshine
>> wrote:
>> > This is a re-roll of [1] which fixes sequencer bugs resulting in commit
>> > object corruption when "rebase -i
Hi,
Stefan Beller wrote:
> --- a/Documentation/diff-options.txt
> +++ b/Documentation/diff-options.txt
> @@ -91,14 +91,18 @@ appearing as a deletion or addition in the output. It
> uses the "patience
> diff" algorithm internally.
>
> --diff-algorithm={patience|minimal|histogram|myers}::
> -
check_one_conflict() compares `i` to `active_nr` in two places to avoid
buffer overruns, but left out an important third location. This has
not previously been a problem, because existing merge strategies have
tended to not create entries at stage #1 that do not have a
corresponding entry at
== Summary ==
For non-textual conflicts, I would like to provide additional information
in the working copy in the form of additional conflict markers and
explanatory text stating what type of non-textual conflict was involved.
This should
* Make it clearer to users what conflicts they are
For non-textual conflicts, provide additional information in the working
copy in the form of additional conflict markers and explanatory text
stating what type of non-textual conflict was involved. In particular,
regular files involved in path-based conflicts would have something like
the
Similar to commit c641ca670729 ("merge-recursive: handle addition of
submodule on our side of history", 2017-11-14) a submodule can be
confused for a D/F conflict for modify/delete and rename/delete
conflicts. (To the code, it appears there is a directory in the way of
us writing our expected
Directory/file conflicts are more difficult than they need to be for users
to resolve (and to un-resolve). Simplify that process by doing to the
index what we do to the working tree: renaming the file in the
directory/file conflict to a different location. This also avoids leaving
cruft
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 we also record
the file under a
Hi everyone,
Last week, Duy posted an interesting RFC patch for improving merge
conflict resolution by coloring the "CONFLICT' messages that are
output during a merge. I have two more ideas (complementary to his)
for improving merge conflict resolution experience. My two ideas are
mostly
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
As a user I wondered what the diff algorithms are about. Offer at least
a basic explanation on the differences of the diff algorithms.
Signed-off-by: Stefan Beller
---
Documentation/diff-options.txt | 10 +++---
Documentation/git-diff.txt | 34 ++
2 files
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
On Mon, Aug 06, 2018 at 02:34:45PM -0400, Noam Postavsky wrote:
> On 30 June 2018 at 08:47, Noam Postavsky
> wrote:
>
> > I'm still having trouble getting a big picture understanding of how
> > the graph struct relates the what gets drawn on screen, but through
> > some poking around with the
On Sat, Jun 30, 2018 at 08:47:16AM -0400, Noam Postavsky wrote:
> I'm still having trouble getting a big picture understanding of how
> the graph struct relates the what gets drawn on screen, but through
> some poking around with the debugger + trial & error, I've arrived at
> a new patch which
On Fri, Aug 03, 2018 at 06:07:46PM -0400, Jeff King wrote:
There's been some work on this lately. See this patch and the response
thread:
https://public-inbox.org/git/20180409204129.43537-9-mastahy...@gmail.com/
The more recent work focused on just doing the minimum to provide
gpg/gpgsm
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 to
>>
>>
>
> Oh right. I forgot to mention
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
The functions present in `git-legacy-rebase.sh` are used by the rebase
backends as they are implemented as shell script functions in the
`git-rebase--` files.
To make the `builtin/rebase.c` work, we have to provide support via
a Unix shell script snippet that uses these functions and so, we
want
This commit imitates the strategy that was used to convert the
difftool to a builtin. We start by renaming the shell script
`git-rebase.sh` to `git-legacy-rebase.sh` and introduce a
`builtin/rebase.c` that simply executes the shell script version,
unless the config setting `rebase.useBuiltin` is
As a GSoC project, I have been working on the builtin rebase.
The motivation behind the rewrite of rebase i.e. from shell script to C
are for following reasons:
1. Writing shell scripts and getting it to production is much faster
than doing the equivalent in C but lacks in performance and
This patch gives life to the skeleton added in the previous patches:
With this change, we can perform a elementary rebase (without any
options).
It can be tested thusly by:
git -c rebase.usebuiltin=true rebase HEAD~2
The rebase backends (i.e. the shell script functions defined in
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
On Mon, Aug 6, 2018 at 8:54 PM Christian Couder
wrote:
> > Is it worth it? The "pahole" comment in this file is up to date. We
> > use 80 bytes per object. This series makes the struct 88 bytes (I've
> > just rerun pahole).
>
> Did you run it on V1 or on V2? I guess on V2, but then what do you
>
On August 6, 2018 1:42 PM, Ævar Arnfjörð Bjarmason wrote:
> On Mon, Aug 06 2018, Randall S. Becker wrote:
>
> > On August 6, 2018 12:40 PM, Ævar Arnfjörð Bjarmason wrote:
> >> On Sat, Aug 04 2018, Junio C Hamano wrote:
> >>
> >> > Duy Nguyen writes:
> >> >
> >> >> On Sat, Aug 4, 2018 at 8:11 AM
On Mon, Aug 06, 2018 at 10:11:19AM -0700, Jonathan Nieder wrote:
> > We're developers ourselves, and we interact with new developers that we
> > want to help. But there are masses of people[1] building Git who are
> > _not_ developers, and want the default to be as robust as possible.
> >
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.
On Mon, Aug 06, 2018 at 11:25:07AM -0700, Junio C Hamano wrote:
> 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?
Hmph, yes, I think this was broken
On Mon, Aug 6, 2018 at 1:45 PM Han-Wen Nienhuys wrote:
> The colorization is controlled with the config setting "color.remote".
> [...]
> Helped-by: Duy Nguyen
> Signed-off-by: Han-Wen Nienhuys
> ---
> diff --git a/Documentation/config.txt b/Documentation/config.txt
> @@ -1263,6 +1263,18 @@
On Mon, Aug 6, 2018 at 5:53 PM, Duy Nguyen wrote:
> On Sun, Aug 5, 2018 at 8:53 PM Christian Couder
> wrote:
>>
>> As you can see the patch 6/6 (in the v2 of this patch series that I
>> just sent) moves `unsigned int tree_depth` from 'struct object_entry'
>> to 'struct packing_data'. I am not
> I had the impression that DEVELOPER=1 was allowed to set flags that old
> versions might not even know about. Hence they might actually barf, even
> without -Werror. Maybe that's better since the introduction of the
> detect-compiler script, though.
>
> I do think we may have a skewed view of
A fair number of tests need to check that the filesystem supports file
names including "funny" characters, like newline, tab, and double-quote.
Jonathan Nieder suggested that this be extracted into a lazy prereq in
the top-level `test-lib.sh`. This patch effects that change.
The FUNNYNAMES prereq
On 30 June 2018 at 08:47, Noam Postavsky wrote:
> I'm still having trouble getting a big picture understanding of how
> the graph struct relates the what gets drawn on screen, but through
> some poking around with the debugger + trial & error, I've arrived at
> a new patch which seems to work.
Chúng tôi mang lại thông báo cho bạn rằng chính phủ của chúng tôi
chiến đấu cho những người lừa đảo bây giờ ở nước ta Togo và chính phủ
của chúng tôi IMF phát hiện ra địa chỉ email của bạn trong danh sách
nạn nhân lừa đảo ở nước ta Togo và từ bi tổng số của bạn $ 850;
000.00. Chúng tôi không thể
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 ;;
> + *)
> +
> The consistency I was referring to is merely in the mechanism used to
> deal with .gitmodules: by always using "submodule--helper config".
>
> As a side argument: in some previous discussion Stefan mentioned the
> possibility that, in the future, he may be interested to explore
> different
On Mon, Aug 6, 2018 at 9:02 AM Jeff King wrote:
> On Sun, Aug 05, 2018 at 04:52:31PM -0400, Jeff King wrote:
> > Perhaps even simpler:
> >
> > test "$1" = "$(find "$1")"
>
> Actually, I guess it needs to add "-print", since IIRC that is not the
> default on some old versions of "find".
You
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
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
5. Compare these commits with
On Mon, Aug 6, 2018 at 7:21 PM Junio C Hamano wrote:
> > + If set, keywords at the start of the line are highlighted. The
> > + keywords are "error", "warning", "hint" and "success", and are
> > + matched case-insensitively. Maybe set to `always`, `false` (or
> > + `never`) or
The colorization is controlled with the config setting "color.remote".
Supported keywords are "error", "warning", "hint" and "success". They
are highlighted if they appear at the start of the line, which is
common in error messages, eg.
ERROR: commit is missing Change-Id
The Git push process
address Jun's comments.
Han-Wen Nienhuys (1):
sideband: highlight keywords in remote sideband output
Documentation/config.txt| 12 +++
help.c | 1 +
help.h | 1 +
sideband.c | 127
On 2018-08-06 10:58, Paul Tan wrote:
>> + git commit -F msg-without-scissors-line &&
>> + git tag scissors-used &&
>
> Nit: I'm not quite sure about naming the tag "scissors-used" though,
> since this commit was not created from the output of "git am
> --scissors". Maybe it should be
On Mon, Aug 06 2018, Randall S. Becker wrote:
> On August 6, 2018 12:40 PM, Ævar Arnfjörð Bjarmason wrote:
>> On Sat, Aug 04 2018, Junio C Hamano wrote:
>>
>> > Duy Nguyen writes:
>> >
>> >> On Sat, Aug 4, 2018 at 8:11 AM Jonathan Nieder
>> wrote:
>> >>> My main concern is not about them but
On Mon, Aug 6, 2018 at 7:21 PM Junio C Hamano wrote:
>
> 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
On Mon, Aug 06 2018, Jeff King wrote:
> On Mon, Aug 06, 2018 at 06:40:14PM +0200, Ævar Arnfjörð Bjarmason wrote:
>
>> Responding to the thread in general, perhaps people would like this more
>> if we turned DEVELOPER=1 DEVOPTS=no-error on by default?
>>
>> That's basically why I added it in
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
>>
On Fri, Aug 03, 2018 at 04:52:05PM -0400, Jeff King wrote:
> I wrote this up for my own use after our discussion in [1]. I'm not sure
> if it's too ugly for inclusion, or if it might be helpful to others.
> I've only just written it, but my plan is to try to run it on anything I
> submit to check
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"
Hi,
Jeff King wrote:
> I had the impression that DEVELOPER=1 was allowed to set flags that old
> versions might not even know about. Hence they might actually barf, even
> without -Werror.
Yes.
[...]
> We're developers ourselves, and we interact with new developers that we
> want to help. But
On August 6, 2018 1:02 PM, Peff wrote:
> To: Ævar Arnfjörð Bjarmason
> Cc: Junio C Hamano ; Duy Nguyen
> ; Jonathan Nieder ; Stefan
> Beller ; Git Mailing List ; git-
> packag...@googlegroups.com; Han-Wen Nienhuys
> Subject: Re: [PATCH] Makefile: enable DEVELOPER by default
>
> On Mon, Aug 06,
On August 6, 2018 12:40 PM, Ævar Arnfjörð Bjarmason wrote:
> On Sat, Aug 04 2018, Junio C Hamano wrote:
>
> > Duy Nguyen writes:
> >
> >> On Sat, Aug 4, 2018 at 8:11 AM Jonathan Nieder
> wrote:
> >>> My main concern is not about them but about other people building
> >>> from source in order to
On Mon, Aug 06, 2018 at 06:40:14PM +0200, Ævar Arnfjörð Bjarmason wrote:
> Responding to the thread in general, perhaps people would like this more
> if we turned DEVELOPER=1 DEVOPTS=no-error on by default?
>
> That's basically why I added it in 99f763baf5 ("Makefile: add a DEVOPTS
> to suppress
On Mon, Aug 06, 2018 at 08:16:47AM -0700, Junio C Hamano wrote:
> It's a bit dissapointing that we cannot express personal preference
> in config.mak ;-)
Try this:
diff --git a/Makefile b/Makefile
index e7994888e8..36bddff3be 100644
--- a/Makefile
+++ b/Makefile
@@ -1119,6 +1119,11 @@ ifdef
On Mon, Aug 06, 2018 at 08:01:00AM -0700, Jonathan Nieder wrote:
> 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
On Sat, Aug 04 2018, Junio C Hamano wrote:
> Duy Nguyen writes:
>
>> On Sat, Aug 4, 2018 at 8:11 AM Jonathan Nieder wrote:
>>> My main concern is not about them but about other
>>> people building from source in order to run (instead of to develop)
>>> Git, and by extension, the people they
On Mon, Aug 6, 2018 at 6:32 PM Junio C Hamano wrote:
> patch and queue it on its own merit (not that I think the other one
> is not yet good enough---I haven't even looked at it yet ;-).
I discovered that emacs tabify will happily also add tabs in the
middle of the line, which breaks in the case
On Mon, Aug 06, 2018 at 06:07:06PM +0200, SZEDER Gábor wrote:
> 'git ls-files' has the options '--exclude', '--exclude-from',
> '--exclude-per-directory', and '--exclude-standard', which all work
> fine. However, it also allows the negated version of all these four
> options, and they definitely
Commit 3ac68a93fd (help: add --config to list all available config -
2018-05-26) makes generate-cmdlist.sh adds a new input source
config.txt but it's not a Makefile dependency. Any changes in
config.txt will not trigger command-list.h regeneration and the config
list in this file becomes
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
On Mon, Aug 6, 2018 at 8:48 AM SZEDER Gábor wrote:
> > @@ -922,7 +928,7 @@ test_expect_success 'submodule update clone shallow
> > submodule' '
> > sed -e "s#url = ../#url = file://$pwd/#" <.gitmodules
> > >.gitmodules.tmp &&
> > mv -f .gitmodules.tmp .gitmodules &&
'git ls-files' has the options '--exclude', '--exclude-from',
'--exclude-per-directory', and '--exclude-standard', which all work
fine. However, it also allows the negated version of all these four
options, and they definitely don't work very well:
$ git ls-files --no-exclude
Segmentation
On 06/08/18 16:23, Phillip Wood wrote:
Hi Johannes
On 06/08/18 10:52, Johannes Schindelin via GitGitGadget wrote:
From: Johannes Schindelin
The idea of `--exec` is to append an `exec` call after each `pick`.
Since the introduction of fixup!/squash! commits, this idea was extended
to apply
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 believe since we can't have D/F
> > conflicts, the
On Sun, Aug 5, 2018 at 8:53 PM Christian Couder
wrote:
>
> On Sun, Jul 22, 2018 at 10:50 AM, Duy Nguyen wrote:
> > On Sun, Jul 22, 2018 at 7:51 AM Christian Couder
> > wrote:
>
> >> diff --git a/pack-objects.h b/pack-objects.h
> >> index edf74dabdd..8eecd67991 100644
> >> --- a/pack-objects.h
>
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
> When a git command is on the left side of a pipe, the pipe will swallow
> its exit status, preventing us from detecting failures in said commands.
> Restructure the tests to put the output in a temporary file to avoid
> this problem.
>
> Signed-off-by: Elijah Newren
> ---
>
On Mon, Aug 6, 2018 at 10:41 AM, Jonathan Nieder wrote:
> Robert Dailey wrote:
>
>> Automatic would be
>> great if submodules were treated as integrated in a similar manner to
>> subtree, but it's not there. I wasn't aware that `submodule update`
Robert Dailey wrote:
> Automatic would be
> great if submodules were treated as integrated in a similar manner to
> subtree, but it's not there. I wasn't aware that `submodule update`
> did a fetch, because sometimes if I do that, I get errors
On Mon, Aug 6, 2018 at 7:59 AM Stefan Beller wrote:
>
> On Fri, Aug 3, 2018 at 11:25 PM Nguyễn Thái Ngọc Duy
> wrote:
> >
> > The color group in config.txt is actually sorted but changes in
> > sb/blame-color broke this. Reorder color.blame.* and move
> > blame.coloring back to the rest of
Jonathan Nieder wrote:
> Johannes Schindelin wrote:
>> It is really, really important to realize how valuable it is to have the
>> regression test as an individual patch that can be used to verify that
>> there is a bug, to pinpoint where it was introduced, to test alternative
>> fixes, to keep
[Resending with Clemens' last used email address.
Clemens, please consider sending a patch to update our .mailmap file.]
On Mon, Aug 6, 2018 at 5:11 PM SZEDER Gábor wrote:
>
> Travis CI changed its default OSX image to use XCode 9.4 on 2018-07-31
> [1]. Since then OSX build jobs fail rather
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.
Signed-off-by: Elijah Newren
---
t/t7406-submodule-update.sh | 8
1 file changed, 4
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 returned
non-zero. Fix the test
Changes since v1:
- Simplify multiple tests using diff --name-only instead of diff --raw;
these tests are only interested in which file was modified anyway.
(Suggested by Junio)
- Avoid putting git commands upstream of a pipe, since we don't run under
set -o pipefail (Suggested by
When a git command is on the left side of a pipe, the pipe will swallow
its exit status, preventing us from detecting failures in said commands.
Restructure the tests to put the output in a temporary file to avoid
this problem.
Signed-off-by: Elijah Newren
---
t/t7406-submodule-update.sh | 24
Hi Johannes
On 06/08/18 10:52, Johannes Schindelin via GitGitGadget wrote:
From: Johannes Schindelin
The idea of `--exec` is to append an `exec` call after each `pick`.
Since the introduction of fixup!/squash! commits, this idea was extended
to apply to "pick, possibly followed by a
On Mon, Aug 6, 2018 at 9:38 AM Alexander Mills
wrote:
> Yeah this concurrency problem is real. Not only does it happen with
> `git status` the same thing happens with `git rev-parse
> --show-toplevel`.
"git rev-parse --show-toplevel" having this same problem helps. This
command should never make
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
Travis CI changed its default OSX image to use XCode 9.4 on 2018-07-31
[1]. Since then OSX build jobs fail rather frequently because of a
SIGPIPE in the tests 'fetch notices corrupt pack' or 'fetch notices
corrupt idx' in 't5570-git-daemon.sh' [2]. I think this is a symptom
a real bug in Git
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
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
> people on non-Linux platforms would have to fill in their own
Hi Dscho,
Johannes Schindelin wrote:
> On Sat, 4 Aug 2018, Jonathan Nieder wrote:
>> Alternatively, could it be squashed in with the patch that fixes it?
>
> There is this really awful trend on this mailing list to suggest
> conflating the demonstration of a bug with the bug fix.
>
> It is
On Thu, Aug 2, 2018 at 1:08 AM, Jonathan Nieder wrote:
> I think I misread this the first time. I got distracted by your
> mention of the --remote option, but you mentioned you want to use the
> SHA-1 of the submodule listed, so that was silly of me.
>
> I think you'll find that "git fetch
The colorization is controlled with the config setting "color.remote".
Supported keywords are "error", "warning", "hint" and "success". They
are highlighted if they appear at the start of the line, which is
common in error messages, eg.
ERROR: commit is missing Change-Id
The Git push process
Address Jun's & Jrn's comments.
Han-Wen Nienhuys (2):
config: document git config getter return value
sideband: highlight keywords in remote sideband output
Documentation/config.txt| 12 +++
config.h| 7 +-
help.c | 1
Signed-off-by: Han-Wen Nienhuys
---
config.h | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/config.h b/config.h
index bb2f506b27..183b31ebf4 100644
--- a/config.h
+++ b/config.h
@@ -188,9 +188,14 @@ struct config_set {
extern void git_configset_init(struct
(administrivia: please don't top-post)
Hi Alex,
Alexander Mills wrote:
> Yeah this concurrency problem is real. Not only does it happen with
> `git status` the same thing happens with `git rev-parse
> --show-toplevel`.
Sorry for the confusion --- I didn't mean to claim your experience was
not
On 8/3/2018 11:58 AM, Duy Nguyen wrote:
On Thu, Aug 02, 2018 at 02:02:00PM -0400, Ben Peart wrote:
But if you still want to push it further, this is something I have in
mind. It probably has bugs, but at least preliminary test shows me
that it could skip 99% work inside unpack_trees()
On Fri, Aug 3, 2018 at 5:52 AM Jonathan Nieder wrote:
>
> Hi,
>
> Han-Wen Nienhuys wrote:
>
> > The colorization is controlled with the config setting "color.remote".
> >
> > Supported keywords are "error", "warning", "hint" and "success". They
> > are highlighted if they appear at the start of
On Sun, Aug 05, 2018 at 08:53:19PM +0200, Christian Couder wrote:
> - 'layer' is used in add_to_write_order() which is called from many
> places in add_descendants_to_write_order() and compute_write_order()
> for example like this:
>
> for (s = DELTA_SIBLING(e); s; s =
On Thu, Aug 2, 2018 at 8:22 PM Junio C Hamano wrote:
> >
> > Helped-by: Duy Nguyen
> > Signed-off-by: Han-Wen Nienhuys
> > ---
> > Documentation/config.txt| 9 +++
> > help.c | 1 +
> > help.h | 1 +
> > sideband.c
On Mon, Aug 06, 2018 at 10:44:14AM +0200, Christian Couder wrote:
> Taking a look at how we use regexec() in our code base, it looks like
> it might be better to use regexec_buf() defined in
> "git-compat-util.h".
>
> I am not completely sure about that because apply.c has:
>
> status =
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
> people on non-Linux
On Sun, Aug 05, 2018 at 08:49:31PM +, brian m. carlson wrote:
> > +parallel=8
>
> I'm not sure -j8 is a great default. There are still a lot of
> two-core/four-thread machines out there, such as my laptop (from 2016).
> Maybe we should default this to 1 unless -j is provided, like make
1 - 100 of 118 matches
Mail list logo
