On 2017-05-26 07:51, Yu-Hsuan Chen wrote:
> Dear maintainer,
>
> There is a bug where committing a large file corrupts the pack file in
> Windows. Steps to recreate are:
>
> 1. git init
> 2. stage and commit a file larger than 4 GB (not entirely sure about this
> size)
> 3. git checkout -f
>
>
On Fri, May 26, 2017 at 01:51:34PM +0800, Yu-Hsuan Chen wrote:
> There is a bug where committing a large file corrupts the pack file in
> Windows. Steps to recreate are:
>
> 1. git init
> 2. stage and commit a file larger than 4 GB (not entirely sure about this
> size)
> 3. git checkout -f
>
>
Tyler Brazier writes:
> On Thu, May 25, 2017 at 6:33 PM, Junio C Hamano wrote:
>> Jeff King writes:
>>
>>> Anyway. All this has shown me is that it's probably pointless to do this
>>> timing at all on Linux. Somebody on Windows might get better results.
>>>
>>> But regardless, we need to do som
Dear maintainer,
There is a bug where committing a large file corrupts the pack file in
Windows. Steps to recreate are:
1. git init
2. stage and commit a file larger than 4 GB (not entirely sure about this size)
3. git checkout -f
The file checked out is much smaller than the original file size.
Does git accept outside pull requests? I wouldn't mind committing the
fix for this once it's been decided what the fix should be. (It might
help my resume ;)
On Thu, May 25, 2017 at 6:33 PM, Junio C Hamano wrote:
> Jeff King writes:
>
>> Anyway. All this has shown me is that it's probably pointl
Obviously correct. Thanks.
From: Nguyễn Thái Ngọc Duy
Noticed-by: Jeff King
Signed-off-by: Nguyễn Thái Ngọc Duy
Signed-off-by: Junio C Hamano
---
builtin/log.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/builtin/log.c b/builtin/log.c
index 26d6a3cf14..f075838df9 100644
--- a/builtin
From: Nguyễn Thái Ngọc Duy
We are supposed to report errno from fopen(). fclose() between fopen()
and the report function could either change errno or reset it.
Signed-off-by: Junio C Hamano
---
rerere.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/rerere.c b/rerere.c
From: Nguyễn Thái Ngọc Duy
After the last patch, this function is not used outside anymore. Keep it
static.
Noticed-by: Ramsay Jones
Signed-off-by: Junio C Hamano
---
git-compat-util.h | 2 --
wrapper.c | 10 +-
2 files changed, 5 insertions(+), 7 deletions(-)
diff --git a/g
Our code often opens a path to an optional file, to work on its
contents when we can successfully open it. We can ignore a failure
to open if such an optional file does not exist, but we do want to
report a failure in opening for other reasons (e.g. we got an I/O
error, or the file is there, but w
When asked to open/fopen a path, e.g. "a/b:/c", which does not exist
on the filesystem, Windows (correctly) fails to open it but sets
EINVAL to errno because the pathname has characters that cannot be
stored in its filesystem.
As this is an expected failure, teach is_missing_file_error() helper
ab
From: Ramsay Jones
If git is built with the FREAD_READS_DIRECTORIES build variable set, this
would cause sparse to issue a 'not declared, should it be static?' warning
on Linux. This is a result of the method employed by 'compat/fopen.c' to
suppress the (possible) redefinition of the (system) fop
From: Nguyễn Thái Ngọc Duy
When fopen() returns NULL, it could be because the given path does not
exist, but it could also be some other errors and the caller has to
check. Add a wrapper so we don't have to repeat the same error check
everywhere.
Signed-off-by: Nguyễn Thái Ngọc Duy
Signed-off-b
From: Nguyễn Thái Ngọc Duy
Signed-off-by: Nguyễn Thái Ngọc Duy
Signed-off-by: Junio C Hamano
---
builtin/log.c | 3 ++-
rerere.c | 4 ++--
xdiff-interface.c | 4 ++--
3 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/builtin/log.c b/builtin/log.c
index b3b10cc1ed..26d
These are taken from https://github.com/pclouds/git/commits/fopen-or-warn
cf.
with a few bits salvaged from its v2 version.
Ramsay Jones (1):
git_fopen: fix a sparse 'not declared' warning
Nguyễn Thái Ngọc Duy (9):
use xfopen() in more places
clone: use xfopen() instead of fopen()
confi
From: Nguyễn Thái Ngọc Duy
In many places, Git warns about an inaccessible file after a fopen()
failed. To discern these cases from other cases where we want to warn
about inaccessible files, introduce a new helper specifically to test
whether fopen() failed because the current user lacks the per
From: Nguyễn Thái Ngọc Duy
xfopen()
- provides error details
- explains error on reading, or writing, or whatever operation
- has l10n support
- prints file name in the error
Some of these are missing in the places that are replaced with xfopen(),
which is a clear win. In some other places,
From: Nguyễn Thái Ngọc Duy
This variable is added [1] with the assumption that on a sane system,
fopen(, "r") should return NULL. Linux and FreeBSD do not meet this
expectation while at least Windows and AIX do. Let's make sure they
behave the same way.
I only tested one version on Linux (4.7.0
From: Nguyễn Thái Ngọc Duy
copy_alternates() called fopen() without handling errors. By switching
to xfopen(), this bug is fixed.
Signed-off-by: Nguyễn Thái Ngọc Duy
Signed-off-by: Junio C Hamano
---
builtin/clone.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/c
Signed-off-by: Junio C Hamano
---
config.mak.uname | 1 +
1 file changed, 1 insertion(+)
diff --git a/config.mak.uname b/config.mak.uname
index a25ffddb3e..1743890164 100644
--- a/config.mak.uname
+++ b/config.mak.uname
@@ -110,6 +110,7 @@ ifeq ($(uname_S),Darwin)
BASIC_CFLAGS += -DPRECO
Hi Johannes,
Johannes Schindelin writes:
> This operation has quadratic complexity, which is especially painful
> on Windows, where shell scripts are *already* slow (mainly due to the
> overhead of the POSIX emulation layer).
>
> Let's reimplement this with linear complexity (using a hash map to
Hi Johannes,
Johannes Schindelin writes:
> The commands used to be indented, and it is nice to look at, but when we
> transform the SHA-1s, the indentation is removed. So let's do away with it.
>
> For the moment, at least: when we will use the upcoming rebase--helper
> to transform the SHA-1s,
Hi Johannes,
Johannes Schindelin writes:
> This is crucial to improve performance on Windows, as the speed is now
> mostly dominated by the SHA-1 transformation (because it spawns a new
> rev-parse process for *every* line, and spawning processes is pretty
> slow from Git for Windows' MSYS2 Bash)
Hi Johannes,
Johannes Schindelin writes:
> The first step of an interactive rebase is to generate the so-called "todo
> script", to be stored in the state directory as "git-rebase-todo" and to
> be edited by the user.
>
> Originally, we adjusted the output of `git log ` using a simple
> sed scri
Hi Johannes,
Johannes Schindelin writes:
> This patch series reimplements the expensive pre- and post-processing of
> the todo script in C.
>
> And it concludes the work I did to accelerate rebase -i.
>
> Changes since v3:
>
> - removed the no-longer-used transform_todo_ids shell function
>
> - s
Duy Nguyen writes:
> On Mon, May 22, 2017 at 1:11 PM, Junio C Hamano wrote:
>> * nd/fopen-errors (2017-05-09) 23 commits
>> - t1308: add a test case on open a config directory
>> - config.c: handle error on failing to fopen()
>> - xdiff-interface.c: report errno on failure to stat() or fopen(
Jeff King writes:
> But let's consider related invocations and whether we're
> making them better or worse:
>
>- git log :/foo
> (when "foo" matches a commit message)
>
> This one should remain the same. Like the existing
> wildcard rule, we're touching only verify_filename(
Stefan Beller writes:
> As you turn on/off normal coloring via "color.diff" and this only extends
> the coloring scheme, I have the impression "color" is the right section.
> Maybe color.diffStyle=[normal/enhanced] and "enhanced" means this
> feature for now?
Hmph, I thought the intent of color.
Stefan Beller writes:
> Yes, this is essentially the v4 with small indentation fixes, so I
> assumed your signoff is still valid.
OK. I just didn't expect to see one without "no changes since v4"
under the three-dash line.
Thanks.
Samuel Lijin writes:
> On Wed, May 24, 2017 at 12:14 AM, Torsten Bögershausen wrote:
>>
>>> diff --git a/builtin/clean.c b/builtin/clean.c
>>> index d861f836a..937eb17b6 100644
>>> --- a/builtin/clean.c
>>> +++ b/builtin/clean.c
>>> @@ -857,6 +857,38 @@ static void interactive_main_loop(void)
>>
Ævar Arnfjörð Bjarmason writes:
> I think it's a pointless distraction to start speculating in this
> commit message what we're going to do with --debug it if it ever
> starts emitting some debugging information at pattern execution time.
OK.
> As an aside, I'd very much like to remove both --d
So it will be easy to track that we don't accidentally commit huge files.
What do you think?
Jeff King writes:
> Anyway. All this has shown me is that it's probably pointless to do this
> timing at all on Linux. Somebody on Windows might get better results.
>
> But regardless, we need to do something. Correctness must trump
> optimizations, and the question is whether we can throw out th
Ævar Arnfjörð Bjarmason writes:
> But from what you're saying here that seems like a non-issue, i.e. in
> such a scenario we'd just mirror the original repo[1], change the URL
> in git.git to that, and then anyone could easily use older history
> since it would be pointing to the new mirror.
Tho
Jeff King writes:
> I dunno. I was thinking there might be a quick tweak, but I'm wondering
> if this arcane case is worth the restructuring we'd have to do to
> support it. It only comes up when you've moved the server repo's HEAD to
> an unborn branch _and_ you have other refs (since otherwise
Signed-off-by: SZEDER Gábor
---
Documentation/config.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 475e874d5..f9adc9afa 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -334,7 +334,7 @@ core
Johannes Sixt writes:
>>> So in short:
>>>
>>> (1) Hannes's patches are good, but they solve a problem that is
>>> different from what their log messages say; the log message
>>> needs to be updated;
>
> I do not resend patch 1/2 as it is unchanged in all regards. This 2/2
> changes
On Fri, May 26, 2017 at 08:37:41AM +1200, Adrian Forbes wrote:
> Yep, but how do I send it back to you? As a mail attachment?
Usually you'd send it to the list, with the commit message in the body
and the patch inline below, as generated by "git format-patch".
Unfortunately gmail is notorious fo
On Thu, May 18, 2017 at 10:13 PM, Ben Peart wrote:
> This hook script integrates the new fsmonitor capabilities of git with
> the cross platform Watchman file watching service. To use the script:
>
> Download and install Watchman from https://facebook.github.io/watchman/
> and instruct Watchman to
Add support for v2 of the PCRE API. This is a new major version of
PCRE that came out in early 2015[1].
The regular expression syntax is the same, but while the API is
similar, pretty much every function is either renamed or takes
different arguments. Thus using it via entirely new functions makes
Change the grep PCRE v1 code to use JIT when available. When PCRE
support was initially added in commit 63e7e9d8b6 ("git-grep: Learn
PCRE", 2011-05-09) PCRE had no JIT support, it was integrated into
8.20 released on 2011-10-21.
Enabling JIT support usually improves performance by more than
40%. T
Amend my change earlier in this series ("grep: add support for the
PCRE v1 JIT API", 2017-04-11) to un-break the build on PCRE v1
versions earlier than 8.20.
The 8.20 release was the first release to have JIT & pcre_jit_stack in
the headers, so a mock type needs to be provided for it on those
rele
Amend my change earlier in this series ("grep: add support for the
PCRE v1 JIT API", 2017-04-11) to un-break the build on PCRE v1
versions earlier than 8.32.
The JIT support was added in version 8.20 released on 2011-10-21, but
it wasn't until 8.32 released on 2012-11-30 that the fast code path to
Add a short -P option as a synonym for the longer --perl-regexp, for
consistency with the options the corresponding grep invocations
accept.
This was intentionally omitted in commit 727b6fc3ed ("log --grep:
accept --basic-regexp and --perl-regexp", 2012-10-03) for unspecified
future use.
Make it
Change the pattern compilation logic under threading so that grep
doesn't compile a pattern it never ends up using on the non-threaded
code path, only to compile it again N times for N threads which will
each use their own copy, ignoring the initially compiled pattern.
This redundant compilation d
Skip the administrative overhead of using pthreads when only using one
thread. Instead take the non-threaded path which would be taken under
NO_PTHREADS.
The threading support was initially added in commit
5b594f457a ("Threaded grep", 2010-01-25) with a hardcoded compile-time
number of 8 threads.
See <20170523192453.14172-1-ava...@gmail.com> for v2
(https://public-inbox.org/git/20170523192453.14172-1-ava...@gmail.com/).
This on top of "[PATCH v4 00/31] Easy to review grep & pre-PCRE
changes".
This hopefully addresses all the comments I had on v2. Comments below:
Ævar Arnfjörð Bjarmason (
Change the grep_{lock,unlock} functions to assert that num_threads is
true, instead of only locking & unlocking the pthread mutex lock when
it is.
These functions are never called when num_threads isn't true, this
logic has gone through multiple iterations since the initial
introduction of grep th
Fix a buggy warning about threads under NO_PTHREADS=YesPlease. Due to
re-using the delta_search_threads variable for both the state of the
"pack.threads" config & the --threads option, setting "pack.threads"
but not supplying --threads would trigger the warning for both
"pack.threads" & --threads.
Move the is_fixed() function which are currently only used in
compile_regexp() earlier so it can be used in the PCRE family of
functions in a later change.
Signed-off-by: Ævar Arnfjörð Bjarmason
---
grep.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --g
Add a PTHREADS prerequisite which is false when git is compiled with
NO_PTHREADS=YesPlease.
There's lots of custom code that runs when threading isn't available,
but before this prerequisite there was no way to test it.
Signed-off-by: Ævar Arnfjörð Bjarmason
---
Makefile | 1 +
t/README
Add a die(...) to a default case for the switch statement selecting
between grep pattern types under --recurse-submodules.
Normally this would be caught by -Wswitch, but the grep_pattern_type
type is converted to int by going through parse_options(). Changing
the argument type passed to compile_su
Remove redundant assignments to the "regflags" variable. This variable
is only used set under GREP_PATTERN_TYPE_ERE, so there's no need to
un-set it under GREP_PATTERN_TYPE_{FIXED,BRE,PCRE}.
Back in 5010cb5fcc[1], we did do "opt.regflags &= ~REG_EXTENDED" upon
seeing "-G" on the command line and f
Add a warning about missing thread support when grep.threads or
--threads is set to a non 0 (default) or 1 (no parallelism) value
under NO_PTHREADS=YesPlease.
This is for consistency with the index-pack & pack-objects commands,
which also take a --threads option & are configurable via
pack.threads
Add a test for the warning that's emitted when --threads or
pack.threads is provided under NO_PTHREADS=YesPlease. This uses the
new PTHREADS prerequisite.
The assertion for C_LOCALE_OUTPUT in the latter test is currently
redundant, since unlike index-pack the pack-objects warnings aren't
i18n'd. H
Change the internal PCRE variable & function names to have a "1"
suffix. This is for preparation for libpcre2 support, where having
non-versioned names would be confusing.
An earlier change in this series ("grep: change the internal PCRE
macro names to be PCRE1", 2017-04-07) elaborates on the moti
Factor the test for \0 in grep patterns into a function. Since commit
9eceddeec6 ("Use kwset in grep", 2011-08-21) any pattern containing a
\0 is considered fixed as regcomp() can't handle it.
This change makes later changes that make use of either has_null() or
is_fixed() (but not both) smaller.
Add a performance comparison test of grep regex engines given fixed
strings.
The current logic in compile_regexp() ignores the engine parameter and
uses kwset() to search for these, so this test shows no difference
between engines right now:
$ GIT_PERF_REPEAT_COUNT=10 GIT_PERF_LARGE_REPO=~/g/
Change the internal USE_LIBPCRE define, & build options flag to use a
naming convention ending in PCRE1, without changing the long-standing
USE_LIBPCRE Makefile flag which enables this code.
This is for preparation for libpcre2 support where having things like
USE_LIBPCRE and USE_LIBPCRE2 in any m
Add a very basic performance comparison test comparing the POSIX
basic, extended and perl engines.
In theory the "basic" and "extended" engines should be implemented
using the same underlying code with a slightly different pattern
parser, but some implementations may not do this. Jump through some
Add a git GIT_PERF_MAKE_COMMAND variable to compliment the existing
GIT_PERF_MAKE_OPTS facility. This allows specifying an arbitrary shell
command to execute instead of 'make'.
This is useful e.g. in cases where the name, semantics or defaults of
a Makefile flag have changed over time. It can even
Amend the t/perf/run output so that in addition to the "Running N
tests" heading currently being emitted, it also emits "Unpacking $rev"
and "Building $rev" when setting up the build/$rev directory & when
building it, respectively.
This makes it easier to see what's going on and what revision is b
Add a performance comparison test of log --grepgrep regex engines
given fixed strings.
See the preceding fixed-string t/perf change ("perf: add a comparison
test of grep regex engines with -F", 2017-04-21) for notes about this,
in particular this mostly tests exactly the same codepath now, but
mig
Add a very basic performance comparison test comparing the POSIX
basic, extended and perl engines with patterns matching log messages
via --grep=.
$ GIT_PERF_REPEAT_COUNT=10 GIT_PERF_LARGE_REPO=~/g/linux ./run
p4220-log-grep-engines.sh
[...]
Test
Add a helper function to make the tests which check for patterns with
\0 in them more succinct. Right now this isn't a big win, but
subsequent commits will add a lot more of these tests.
The helper is based on the match() function in t3070-wildmatch.sh.
Signed-off-by: Ævar Arnfjörð Bjarmason
---
Add setup code needed for testing regexes that contain both binary
data and regex metacharacters.
The POSIX regcomp() function inherently can't support that, because it
takes a \0-delimited char *, but other regex engines APIs like PCRE v2
take a pattern/length pair, and are thus able to handle \0
Address a big blind spot in the tests for patterns containing \0. The
is_fixed() function considers any string that contains \0 fixed, even
if it contains regular expression metacharacters, those patterns are
currently matched with kwset.
Before this change removing that memchr(s, 0, len) check fr
Make the --regexp-ignore-case option work with --perl-regexp. This
never worked, and there was no test for this. Fix the bug and add a
test.
When PCRE support was added in commit 63e7e9d8b6 ("git-grep: Learn
PCRE", 2011-05-09) compile_pcre_regexp() would only check
opt->ignore_case, but when the -
Amend the submodule recursion test to prepare it for subsequent tests
of whether it passes along the grep.patternType to the submodule
greps.
This is the result of searching & replacing:
foobar -> (1|2)d(3|4)
foo-> (1|2)
bar-> (3|4)
Currently there's no tests for whether e.g.
Add a test for backreferences such as (.)\1 in PCRE patterns. This
test ensures that the PCRE_NO_AUTO_CAPTURE option isn't turned
on. Before this change turning it on would break these sort of
patterns, but wouldn't break any tests.
Signed-off-by: Ævar Arnfjörð Bjarmason
---
t/t7810-grep.sh | 7
Change a non-ASCII case-insensitive test case to stop using --debug,
and instead simply test for the expected results.
The test coverage remains the same with this change, but the test
won't break due to internal refactoring.
This test was added in commit 793dc676e0 ("grep/icase: avoid kwsset
whe
Add a test asserting that when --perl-regexp (and -P for grep) is
given to git-grep & git-log that we die with an error.
In developing the PCRE v2 series I introduced a regression where -P
would (through control-flow fall-through) become synonymous with basic
POSIX matching. I.e. 'git grep -P '[\d
Add tests for --threads=N being supplied on the command-line, or when
grep.threads=N being supplied in the configuration.
When the threading support was made run-time configurable in commit
89f09dd34e ("grep: add --threads= option and grep.threads
configuration", 2015-12-15) no tests were added fo
Add testing for grep pattern types being correctly passed to
submodules. The pattern "(.|.)[\d]" matches differently under
fixed (not at all), and then matches different lines under
basic/extended & perl regular expressions, so this change asserts that
the pattern type is passed along correctly.
S
Reword an outdated & inaccurate comment which suggests that only
git-grep can use PCRE.
This comment was added back when PCRE support was initially added in
commit 63e7e9d8b6 ("git-grep: Learn PCRE", 2011-05-09), and was true
at the time.
It hasn't been telling the full truth since git-log learne
Stop promising in our grep & rev-list options documentation that we're
always going to be using libpcre when given the --perl-regexp option.
Instead talk about using "Perl-compatible regular expressions" and
using these types of patterns using "a compile-time dependency".
Saying "libpcre" means t
Add exhaustive tests for how the different grep.patternType options &
the corresponding command-line options affect git-log.
Before this change it was possible to patch revision.c so that the
--basic-regexp option was synonymous with --extended-regexp, and
--perl-regexp wasn't recognized at all, a
Rename the LIBPCRE prerequisite to PCRE. This is for preparation for
libpcre2 support, where having just "LIBPCRE" would be confusing as it
implies v1 of the library.
None of these tests are incompatible between versions 1 & 2 of
libpcre, it's less confusing to give them a more general name to mak
Easy to review? 29 (I mean 30, I mean 31) patches? Are you kidding
me?!
As noted in v1 (<20170511091829.5634-1-ava...@gmail.com>;
https://public-inbox.org/git/20170511091829.5634-1-ava...@gmail.com/)
these are all doc, test, refactoring etc. changes needed by the
subsequent "PCRE v2, PCRE v1 JIT,
If we successfully parse a symref value like
"HEAD:refs/heads/master", we add the result to a string
list. But because the string list is marked
STRING_LIST_INIT_DUP, the string list code will make a copy
of the string and add the copy.
This patch fixes it by adding the entry with
string_list_appe
On Thu, May 25, 2017 at 11:59:24AM -0400, Jeff King wrote:
> The just-HEAD case could look like:
This patch does work, in the sense that upload-pack advertises the
unborn HEAD symref. But the client doesn't actually do anything with it.
The capability parsing happens in get_remote_heads(), which
I have a git repository linked to a svn repository with git-svn,
including a branch path configuration and an authorsfile for svn
username -> email mapping.
When running `git svn branch new_branch`, git-svn:
* Creates a svn commit creating a new svn branch
* Creates a local git commit linked to t
Add test cases that ensure status results are correct when using the new
fsmonitor extension. Test untracked, modified, and new files by
ensuring the results are identical to when not using the extension.
Add a test to ensure updates to the index properly mark corresponding
entries in the index e
Add a new get_be64 macro to enable 64 bit endian conversions on memory
that may or may not be aligned.
Signed-off-by: Ben Peart
---
compat/bswap.h | 4
1 file changed, 4 insertions(+)
diff --git a/compat/bswap.h b/compat/bswap.h
index d47c003544..f89fe7f4b5 100644
--- a/compat/bswap.h
+++
This hook script integrates the new fsmonitor capabilities of git with
the cross platform Watchman file watching service. To use the script:
Download and install Watchman from https://facebook.github.io/watchman/
and instruct Watchman to watch your working directory for changes
('watchman watch-pr
When the index is read from disk, the query-fsmonitor index extension is
used to flag the last known potentially dirty index and untracked cache
entries.
If git finds out some entries are 'fsmonitor-dirty', but are really
unchanged (e.g. the file was changed, then reverted back), then Git will
cle
This includes the core.fsmonitor setting, the query-fsmonitor hook,
and the fsmonitor index extension.
Signed-off-by: Ben Peart
---
Documentation/config.txt | 7 +++
Documentation/githooks.txt | 23 +++
Documentation/technical/index-format.t
Remove the static qualifier from lookup_untracked() and make it
available to other modules by exporting it from dir.h. This will be
used later when we need to find entries to mark 'fsmonitor dirty.'
Signed-off-by: Ben Peart
---
dir.c | 2 +-
dir.h | 3 +++
2 files changed, 4 insertions(+), 1 de
Changes from V2 include:
- switch to nanoseconds for last update time saved in index extension
and passed to hook
- pass the hook a version to enable simpler future updates
- fixup compiler warnings found with different compilers
- update test to run properly on Mac
- fix documentation form
On Thu, May 25, 2017 at 09:52:42PM +1200, Adrian Forbes wrote:
> Some of the example commands in git-stash documentation should be
> written as comments rather than actual commands:
> https://cloud.githubusercontent.com/assets/24915363/26444394/5cf6a754-4190-11e7-845e-135288c8916e.png
>
> For exa
On Thu, May 25, 2017 at 02:04:07PM -0400, Jeff King wrote:
> > ...that might be something worth thinking about---my gut feeling
> > tells me something but we should go by a measurement, not by gut
> > feeling of a random somebody.
>
> Yeah, I'd agree. I had the impression the original change was
On Wed, May 24, 2017 at 07:40:08AM +0900, Junio C Hamano wrote:
> > But I notice on the run_merge() code path that we do still invoke
> > git-merge.
>
> ... wouldn't that what we want even when the merge happens to be a
> fast-forward one? I am not sure what you meant by this, but...
I just mea
On Wed, May 24, 2017 at 11:44 PM, Junio C Hamano wrote:
> I was trying to see how this is useful in code moving change, with
> this command line:
>
> $ git -c color.moved diff js/blame-lib~6 js/blame-lib blame.c blame.h
> builtin/blame.c
>
> Some random observations:
>
> * You do not seem to hav
Dear Good day,
I sent this mail praying for it to reach you in good health, since I
myself are in a very critical health condition in which I sleep every
night without knowing if I may be alive to see the next day. I am a
widow suffering from long time illness. I have some funds I inherited
from
On Thu, May 25, 2017 at 12:13:03PM +0900, Junio C Hamano wrote:
> >> So if we wanted to improve this, I think the first step would be for the
> >> server to start sending symref lines for HEAD, even when it does not
> >> resolve to anything.
> >
> > Yup, noticed the same and I agree with your conc
On Wed, May 24, 2017 at 12:14 AM, Torsten Bögershausen wrote:
>
>> diff --git a/builtin/clean.c b/builtin/clean.c
>> index d861f836a..937eb17b6 100644
>> --- a/builtin/clean.c
>> +++ b/builtin/clean.c
>> @@ -857,6 +857,38 @@ static void interactive_main_loop(void)
>> }
>> }
>> +static
For commands that take revisions and pathspecs, magic
pathspecs like ":^Documentation" or ":/Documentation" have
to appear on the right-hand side of the disambiguating "--",
like:
git log -- :^Documentation
This makes them more annoying to use than they need to be.
We loosened the rules for wil
On 5/24/2017 6:54 AM, Christian Couder wrote:
Design
~~
A new git hook (query-fsmonitor) must exist and be enabled
(core.fsmonitor=true) that takes a time_t formatted as a string and
outputs to stdout all files that have been modified since the requested
time.
Is there a reason why there
On 5/22/2017 1:28 PM, Ævar Arnfjörð Bjarmason wrote:
On Mon, May 22, 2017 at 6:18 PM, Ben Peart wrote:
On 5/20/2017 8:10 AM, Ævar Arnfjörð Bjarmason wrote:
+== File System Monitor cache
+
+ The file system monitor cache tracks files for which the
query-fsmonitor
+ hook has told us about c
On Mon, May 22, 2017 at 1:11 PM, Junio C Hamano wrote:
> * nd/fopen-errors (2017-05-09) 23 commits
> - t1308: add a test case on open a config directory
> - config.c: handle error on failing to fopen()
> - xdiff-interface.c: report errno on failure to stat() or fopen()
> - wt-status.c: report
1 - 100 of 108 matches
Mail list logo
