Re: git 2.2.2 annotate crash (strbuf.c:32)

On Sun, Feb 8, 2015 at 8:28 PM, Jeff King wrote: > On Sun, Feb 08, 2015 at 10:33:40PM +0100, Dilyan Palauzov wrote: > >> I use git 2.2.2 and on my system git annotate crashed with the following >> log. > > I couldn't reproduce it with a few simple examples. Is it possible for > you to show us the

Высококачественный кофе от швейцарского производителя

Предлагаю высококачественный кофе от швейцарского производителя http://bit.ly/1xqBJAo -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: Fwd: segmentation fault 11

On Sun, Feb 08, 2015 at 06:56:14PM +0100, David Krmpotic wrote: > I updated to 2.3.0 on my OSX 10.9.5 and when trying to push to github > (git push -u origin master), I get: > > Segmentation fault: 11 > > Switched back to 1.8.5.5 and it works... Is this reproducible easily? If so, can you do on

Re: git 2.2.2 annotate crash (strbuf.c:32)

On Sun, Feb 08, 2015 at 10:33:40PM +0100, Dilyan Palauzov wrote: > I use git 2.2.2 and on my system git annotate crashed with the following > log. I couldn't reproduce it with a few simple examples. Is it possible for you to show us the repository and command that caused this? > (gdb) bt full >

Re: [PATCH] Geolocation support

In case I was not clear, I do not think it is likely for us to accept a patch that mucks with object header fields with this information. Have them in the log text and let UI interpret them. On Sun, Feb 8, 2015 at 4:03 PM, Alessandro Di Marco wrote: > Junio C Hamano writes: > >> I would personal

[PATCH 2/2] sha1_file: fix iterating loose alternate objects

From: Jonathon Mah The string in 'base' contains a path suffix to a specific object; when its value is used, the suffix must either be filled (as in stat_sha1_file, open_sha1_file, check_and_freshen_nonlocal) or cleared (as in prepare_packed_git) to avoid junk at the end. 660c889e (sha1_file: ad

[PATCH 1/2] for_each_loose_file_in_objdir: take an optional strbuf path

We feed a root "objdir" path to this iterator function, which then copies the result into a strbuf, so that it can repeatedly append the object sub-directories to it. Let's make it easy for callers to just pass us a strbuf in the first place. We leave the original interface as a convenience for ca

Re: [PATCH] sha1_file.c: make sure open_sha1_file does not open a directory

On Sun, Feb 08, 2015 at 07:54:44PM -0500, Jeff King wrote: > However, the first thing for_each_loose_file_in_objdir is going to do is > stick the path into a strbuf. So perhaps the most sensible thing is to > just teach it to take a strbuf from the caller. I'll work up a patch. > > It looks like

Re: [PATCH] sha1_file.c: make sure open_sha1_file does not open a directory

On Sun, Feb 08, 2015 at 03:05:32PM -0800, Kyle J. McKay wrote: > Since "sha1_file: fix iterating loose alternate objects", it's possible > for the base member of the alt_odb_list structure to be NUL terminated > rather than ending with a '/' when open_sha1_file is called. Good catch. Users of "st

Re: [PATCH] Geolocation support

Junio C Hamano writes: > I would personally find the "feature" cute, but > Wouldn't it be sufficient to treat this in a similar way as > references to tracker entries and references to other commit objects > in the text of the commit message body are treated by gitk and > friends? Just embed

[PATCH] sha1_file.c: make sure open_sha1_file does not open a directory

Since "sha1_file: fix iterating loose alternate objects", it's possible for the base member of the alt_odb_list structure to be NUL terminated rather than ending with a '/' when open_sha1_file is called. Unfortunately this causes a directory to be passed to git_open_noatime instead of a file which

git 2.2.2 annotate crash (strbuf.c:32)

Hello, I use git 2.2.2 and on my system git annotate crashed with the following log. Kind regards Dilyan (gdb) bt full #0 0x7fe420649655 in raise () from /lib64/libc.so.6 No symbol table info available. #1 0x7fe42064aad8 in abort () from /lib64/libc.so.6 No symbol table info avail

Re: [PATCH] config: do not ungetc EOF

On Thu, Feb 05, 2015 at 04:00:24PM -0500, Jeff King wrote: > On Thu, Feb 05, 2015 at 01:53:27AM -0500, Jeff King wrote: > > > I also notice that config_buf_ungetc does not actually ungetc the > > character we give it; it just rewinds one character in the stream. This > > is fine, because we always

Re: [PATCH] config: do not ungetc EOF

On Thu, Feb 05, 2015 at 04:28:47PM -0500, Jeff King wrote: > On Thu, Feb 05, 2015 at 01:16:36PM -0800, Junio C Hamano wrote: > > > Jeff King writes: > > > > > On Thu, Feb 05, 2015 at 01:53:27AM -0500, Jeff King wrote: > > > > > >> I also notice that config_buf_ungetc does not actually ungetc the

Fwd: segmentation fault 11

I updated to 2.3.0 on my OSX 10.9.5 and when trying to push to github (git push -u origin master), I get: Segmentation fault: 11 Switched back to 1.8.5.5 and it works... Report: http://cl.ly/1u3E412N0D2Z Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x00

Re: [PATCH/RFD 0/3] worktree.* config keys and submodule and multiple worktrees

Am 08.02.2015 um 09:36 schrieb Jens Lehmann: Am 08.02.2015 um 05:16 schrieb Nguyễn Thái Ngọc Duy: 1/3 is a more complete version of a patch I posted earlier [1]. It makes sure that worktree.* config keys are stored in a different place than $GIT_DIR/config. This allows us to work around the core

Re: [PATCH/RFD 0/3] worktree.* config keys and submodule and multiple worktrees

Am 08.02.2015 um 05:16 schrieb Nguyễn Thái Ngọc Duy: 1/3 is a more complete version of a patch I posted earlier [1]. It makes sure that worktree.* config keys are stored in a different place than $GIT_DIR/config. This allows us to work around the core.worktree issue in multiple worktree setting.

Re: read() MAX_IO_SIZE bytes, more than SSIZE_MAX?

On Sun, Feb 8, 2015 at 7:05 AM, Joachim Schmitz wrote: > Junio C Hamano pobox.com> writes: >> (1) if Makefile gives one, use it without second-guessing with SSIZE_MAX. >> (2) if SSIZE_MAX is defined, and if it is smaller than our internal >> default, use it. >> (3) all other cases, us our inte

[PATCH] merge-file: correctly open files when in a subdir

run_setup_gently() is called before merge-file. This may result in changing current working directory, which wasn't taken into account when opening a file for writing. Fix by prepending the passed prefix. Previous var is left so that error messages keep referring to the file from the user's workin

[PATCH 11/11] update_ref(): improve documentation

Add a docstring for update_ref(), emphasizing its similarity to ref_transaction_update(). Rename its parameters to match those of ref_transaction_update(). Signed-off-by: Michael Haggerty --- refs.c | 8 refs.h | 15 +++ 2 files changed, 15 insertions(+), 8 deletions(-) di

[PATCH 03/11] struct ref_update: move "have_old" into "flags"

Instead of having a separate have_old field, record this boolean value as a bit in the "flags" field. Signed-off-by: Michael Haggerty --- refs.c | 45 - 1 file changed, 28 insertions(+), 17 deletions(-) diff --git a/refs.c b/refs.c index 477a5b3..851c

[PATCH 02/11] refs: remove the gap in the REF_* constant values

There is no reason to "reserve" a gap between the public and private flags values. Signed-off-by: Michael Haggerty --- refs.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/refs.c b/refs.c index cd5208b..477a5b3 100644 --- a/refs.c +++ b/refs.c @@ -44,7 +44,8 @@ static uns

[PATCH 04/11] ref_transaction_update(): remove "have_old" parameter

Instead, if old_sha1 is non-NULL, verify it; otherwise, don't. ref_transaction_delete() will get the same treatment in a moment. Signed-off-by: Michael Haggerty --- branch.c | 5 +++-- builtin/commit.c | 2 +- builtin/fetch.c| 6 -- builtin/receive-pack.c | 2

[PATCH 00/11] Allow reference values to be checked in a transaction

The main purpose of this series is to simplify the interface to reference transactions as follows: * Remove the need to supply an explicit have_old parameter to ref_transaction_update() and ref_transaction_delete(). Instead, check the old_sha1 if and only if it is non-NULL. * Allow NULL to be

[PATCH 07/11] commit: avoid race when creating orphan commits

If, during the initial check, HEAD doesn't point at anything, then we should make sure that it *still* doesn't point at anything when we are ready to update the reference. Otherwise, another process might commit while we are working (e.g., while we are waiting for the user to edit the commit messag

[PATCH 10/11] ref_transaction_verify(): new function to check a reference's value

If NULL is passed to ref_transaction_update()'s new_sha1 parameter, then just verify old_sha1 (under lock) without trying to change the new value of the reference. Use this functionality to add a new function ref_transaction_verify(), which checks the current value of the reference under lock but

[PATCH 01/11] refs: move REF_DELETING to refs.c

It is only used internally now. Document it a little bit better, too. Signed-off-by: Michael Haggerty --- refs.c | 6 ++ refs.h | 4 +--- 2 files changed, 7 insertions(+), 3 deletions(-) diff --git a/refs.c b/refs.c index c5fa709..cd5208b 100644 --- a/refs.c +++ b/refs.c @@ -35,6 +35,12 @@

[PATCH 09/11] ref_transaction_delete(): check that old_sha1 is not null_sha1

It makes no sense to delete a reference that is already known not to exist. Signed-off-by: Michael Haggerty --- refs.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/refs.c b/refs.c index 8ab1f8e..85815d7 100644 --- a/refs.c +++ b/refs.c @@ -3703,6 +3703,8 @@ int ref_transaction_delete(st

[PATCH 08/11] ref_transaction_create(): check that new_sha1 is valid

Creating a reference requires a new_sha1 that is not NULL and not null_sha1. Signed-off-by: Michael Haggerty --- refs.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/refs.c b/refs.c index 6bd6581..8ab1f8e 100644 --- a/refs.c +++ b/refs.c @@ -3691,6 +3691,8 @@ int ref_transaction_create(s

[PATCH 06/11] commit: add tests of commit races

Committing involves the following steps: 1. Determine the current value of HEAD (if any). 2. Create the new commit object. 3. Update HEAD. Please note that step 2 can take arbitrarily long, because it might involve the user editing a commit message. If a second process sneaks in a commit during

[PATCH 05/11] ref_transaction_delete(): remove "have_old" parameter

Instead, if old_sha1 is non-NULL, verify it; otherwise, don't. Signed-off-by: Michael Haggerty --- builtin/receive-pack.c | 3 +-- builtin/update-ref.c | 5 +++-- refs.c | 11 ++- refs.h | 6 +++--- 4 files changed, 13 insertions(+), 12 deletions(-)

Re: 'git rebase' silently drops changes?

Am 07.02.2015 um 22:32 schrieb Sebastian Schuberth: > On 06.02.2015 22:28, Sergey Organov wrote: > >> # Now rebase my work. >> git rebase -f HEAD~1 >> >> # What? Where is my "Precious" change in "a"??? >> cat a >> >> >> I.e., the modification marked [!] was silently lost during rebase! > > Just

[PATCH 2/3] setup: add worktree.path to shadow core.worktree

They have the same purpose. But they are located in different places: core.worktree in $GIT_DIR/config while worktree.path in $GIT_DIR/config.worktree Signed-off-by: Nguyễn Thái Ngọc Duy --- Documentation/config.txt | 3 +++ setup.c | 7 ++- 2 files changed, 9 insertions(+),

[PATCH 3/3] submodule: use worktree.path instead of core.worktree

This opens a door of using submodule with multiple worktrees Signed-off-by: Nguyễn Thái Ngọc Duy --- git-submodule.sh | 2 +- submodule.c| 6 +++--- t/lib-submodule-update.sh | 8 t/t7400-submodule-basic.sh | 4 +

[PATCH 1/3] config.c: new config namespace worktree.* stored in $GIT_DIR/config.worktree

On the surface, worktree.* variables are just like any other variables. You can read or modify them with `git config` command, or config_* API. Underneath, worktree.* are always stored in $GIT_DIR/config.worktree instead of $GIT_DIR/config (and never in $HOME/.gitconfig or /etc/gitconfig) The reas

[PATCH/RFD 0/3] worktree.* config keys and submodule and multiple worktrees

1/3 is a more complete version of a patch I posted earlier [1]. It makes sure that worktree.* config keys are stored in a different place than $GIT_DIR/config. This allows us to work around the core.worktree issue in multiple worktree setting. I think 1/3 and 2/3 are fine. 3/3 is probably not. It'

Re: read() MAX_IO_SIZE bytes, more than SSIZE_MAX?

Junio C Hamano pobox.com> writes: > > > > something like this: > > > > /* allow overwriting from e.g. Makefile */ > > #if !defined(MAX_IO_SIZE) > > # define MAX_IO_SIZE (8*1024*1024) > > #endif > > /* for plattforms that have SSIZE and have it smaller */ > > #if defined(SSIZE_MAX && (SSIZE_MAX <

[PATCH 21/21] t3080: tests for git-list-files

Helped-by: Eric Sunshine Signed-off-by: Nguyễn Thái Ngọc Duy --- t/t3080-list-files.sh (new +x) | 134 + 1 file changed, 134 insertions(+) create mode 100755 t/t3080-list-files.sh diff --git a/t/t3080-list-files.sh b/t/t3080-list-files.sh new file mode 1

git@vger.kernel.org

Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano --- Documentation/git-list-files.txt | 4 ++-- builtin/ls-files.c | 2 ++ 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/Documentation/git-list-files.txt b/Documentation/git-list-files.txt index 475c6

[PATCH 18/21] list-files: add -F/--classify

This appends an indicator after the file name if it's executable, a directory and so on, like in GNU ls. In fact append_indicator() is a rewrite from get_type_indicator() in coreutils.git commit 7326d1f1a67edf21947ae98194f98c38b6e9e527. Signed-off-by: Nguyễn Thái Ngọc Duy --- Documentation/git-l

[PATCH 14/21] list-files: add -t back

Tag "H" (cached) is not shown though because it's usually the majority and becomes noise. Not showing it makes the other tags stand out. -t is on by default if more than one file category is selected. Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano --- Documentation/git-list-f

[PATCH 17/21] list-files: show directories as well as files

The index does not store directories explicitly (except submodules) so we have to figure them out from file list when output lis depth-limited. The function show_as_directory() deliberately generates duplicate directories and expects the previous patch to remove duplicates. Helped-by: Eric Sunshi

[PATCH 16/21] list-files: do not show duplicate cached entries

With the current show_files() "list-files -tcm" will show foo.c M foo.c The first item is redundant. If "foo.c" is modified, we know it's in the cache. Introduce show_files_compact to do that because ls-files is plumbing and scripts may already depend on current display behavior. Another diffe

[PATCH 13/21] list-files: add -1 short for --no-column

Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano --- Documentation/git-list-files.txt | 3 +++ builtin/ls-files.c | 2 ++ 2 files changed, 5 insertions(+) diff --git a/Documentation/git-list-files.txt b/Documentation/git-list-files.txt index 8d285c1..1c0c877 10064

[PATCH 20/21] list-files: -M aka diff-cached

Signed-off-by: Nguyễn Thái Ngọc Duy --- builtin/ls-files.c | 67 +++--- 1 file changed, 64 insertions(+), 3 deletions(-) diff --git a/builtin/ls-files.c b/builtin/ls-files.c index d3540d1..b5e1a59 100644 --- a/builtin/ls-files.c +++ b/builtin/ls-fi

[PATCH 15/21] list-files: sort output and remove duplicates

When you mix different file types, with ls-files you may get separate listing. For example, "ls-files -cm" will show file "abc" twice: one as part of cached list, one of modified list. With "ls" (and this patch) they will be in a single sorted list (easier for the eye). Duplicate entries are also

[PATCH 08/21] ls-files: support --max-depth

Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano --- Documentation/git-ls-files.txt | 7 +++ builtin/ls-files.c | 7 +++ 2 files changed, 14 insertions(+) diff --git a/Documentation/git-ls-files.txt b/Documentation/git-ls-files.txt index 99328b9..3d921eb 100

[PATCH 12/21] list-files: add -R/--recursive short for --max-depth=-1

Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano --- Documentation/git-list-files.txt | 4 builtin/ls-files.c | 2 ++ 2 files changed, 6 insertions(+) diff --git a/Documentation/git-list-files.txt b/Documentation/git-list-files.txt index 2182a38..8d285c1 1006

[PATCH 07/21] ls-files: add --column

Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano --- Documentation/git-ls-files.txt | 6 ++ builtin/ls-files.c | 28 2 files changed, 34 insertions(+) diff --git a/Documentation/git-ls-files.txt b/Documentation/git-ls-files.txt inde

[PATCH 11/21] list-files: -u does not imply showing stages

Showing full index entry information is something for ls-files only. The users of "git list-files" may just want to know what entries are not unmerged. Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano --- builtin/ls-files.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

[PATCH 09/21] list-files: a user friendly version of ls-files and more

This is more user friendly version of ls-files: * it's automatically colored and columnized * it refreshes the index like all porcelain commands * it defaults to non-recursive behavior like ls * :(glob) is on by default so '*.c' means a.c but not a/b.c, use '**/*.c' for that. * auto pager

[PATCH 06/21] ls-files: add --color to highlight file names

Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano --- Documentation/git-ls-files.txt | 7 +++ builtin/ls-files.c | 38 +++--- 2 files changed, 42 insertions(+), 3 deletions(-) diff --git a/Documentation/git-ls-files.txt b/Document

[PATCH 10/21] list-files: make alias 'ls' default to 'list-files'

Signed-off-by: Nguyễn Thái Ngọc Duy --- Documentation/git-list-files.txt | 3 ++- config.c | 8 2 files changed, 10 insertions(+), 1 deletion(-) diff --git a/Documentation/git-list-files.txt b/Documentation/git-list-files.txt index 3039e1e..2182a38 100644 --- a/D

[PATCH 01/21] ls_colors.c: add $LS_COLORS parsing code

Reusing color settings from $LS_COLORS could give a native look and feel on file coloring. This code is basically from coreutils.git [1], rewritten to fit Git. As this is from GNU ls, the environment variable CLICOLOR is not tested. It is to be decided later whether we should ignore $LS_COLORS if

[PATCH 05/21] ls-files: buffer full item in strbuf before printing

Buffering so that we can manipulate the strings (e.g. coloring) further before finally printing them. Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano --- builtin/ls-files.c | 48 +++- 1 file changed, 35 insertions(+), 13 deletions(-)

[PATCH 02/21] ls_colors.c: parse color.ls.* from config file

This is the second (and preferred) source for color information. This will override $LS_COLORS. Helped-by: Michael Blume Signed-off-by: Nguyễn Thái Ngọc Duy --- Documentation/config.txt | 11 +++ ls_colors.c | 30 +- 2 files changed, 40 insertion

[PATCH 03/21] ls_colors.c: add a function to color a file name

The new function is based on print_color_indicator() from commit 7326d1f1a67edf21947ae98194f98c38b6e9e527 in coreutils.git. Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano --- color.h | 2 ++ ls_colors.c | 66 +

[PATCH 04/21] ls_colors.c: highlight submodules like directories

Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano --- Documentation/config.txt | 3 ++- ls_colors.c | 8 +++- 2 files changed, 9 insertions(+), 2 deletions(-) diff --git a/Documentation/config.txt b/Documentation/config.txt index 2090866..2290c47 100644 --- a/Do

[PATCH 00/21] nd/list-files updates

- 02/21: fix a bug that ignores config keys if $LS_COLORS is not defined - 09/21: use listFiles instead of list-files in config keys - 17/21: incorporate match_pathspec changes from Junio, use strbuf_swap in show_as_directory() - 21/21: use test_decode_color and test_when_finished in t3080 Ful

[PATCH 19/24] update-index: manually enable or disable untracked cache

Overall time saving on "git status" is about 40% in the best case scenario, removing ..collect_untracked() as the most time consuming function. read and refresh index operations are now at the top (which should drop when index-helper and/or watchman support is added). More numbers and analysis belo

[PATCH 18/24] status: enable untracked cache

update_index_if_able() is moved down so that the updated untracked cache could be written out. Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano --- builtin/commit.c | 5 +++-- wt-status.c | 2 ++ 2 files changed, 5 insertions(+), 2 deletions(-) diff --git a/builtin/commit

[PATCH 23/24] untracked cache: guard and disable on system changes

If the user enables untracked cache, then - move worktree to an unsupported filesystem - or simply upgrade OS - or move the whole (portable) disk from one machine to another - or access a shared fs from another machine there's no guarantee that untracked cache can still function properly. Rec

[PATCH 22/24] mingw32: add uname()

Helped-by: Eric Sunshine Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano --- compat/mingw.c | 11 +++ compat/mingw.h | 9 + 2 files changed, 20 insertions(+) diff --git a/compat/mingw.c b/compat/mingw.c index c5c37e5..88140e4 100644 --- a/compat/mingw.c +++ b

[PATCH 17/24] untracked-cache: temporarily disable with $GIT_DISABLE_UNTRACKED_CACHE

This can be used to double check if results with untracked cache are correctly, compared to vanilla version. Untracked cache remains in index, but not used. Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano --- dir.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --

[PATCH 24/24] git-status.txt: advertisement for untracked cache

When a good user sees the "too long, consider -uno" advice when running `git status`, they should check out the man page to find out more. This change suggests they try untracked cache before -uno. Helped-by: brian m. carlson Signed-off-by: Nguyễn Thái Ngọc Duy --- Documentation/git-status.txt

[PATCH 20/24] update-index: test the system before enabling untracked cache

Helped-by: Eric Sunshine Helped-by: Junio C Hamano Signed-off-by: Nguyễn Thái Ngọc Duy --- Documentation/git-update-index.txt | 6 ++ builtin/update-index.c | 168 + 2 files changed, 174 insertions(+) diff --git a/Documentation/git-update-index

[PATCH 21/24] t7063: tests for untracked cache

Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano --- .gitignore | 1 + Makefile | 1 + t/t7063-status-untracked-cache.sh (new +x) | 353 + test-dump-untracked-cache.c (new)

[PATCH 14/24] untracked cache: avoid racy timestamps

When a directory is updated within the same second that its timestamp is last saved, we cannot realize the directory has been updated by checking timestamps. Assume the worst (something is update). See 29e4d36 (Racy GIT - 2005-12-20) for more information. Signed-off-by: Nguyễn Thái Ngọc Duy Signe

[PATCH 15/24] untracked cache: print stats with $GIT_TRACE_UNTRACKED_STATS

This could be used to verify correct behavior in tests Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano --- dir.c | 12 1 file changed, 12 insertions(+) diff --git a/dir.c b/dir.c index 439ff22..c5ca5ce 100644 --- a/dir.c +++ b/dir.c @@ -1922,6 +1922,18 @@ int rea

[PATCH 12/24] untracked cache: invalidate at index addition or removal

Ideally we should implement untracked_cache_remove_from_index() and untracked_cache_add_to_index() so that they update untracked cache right away instead of invalidating it and wait for read_directory() next time to deal with it. But that may need some more work in unpack-trees.c. So stay simple as

[PATCH 13/24] read-cache.c: split racy stat test to a separate function

Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano --- read-cache.c | 24 +++- 1 file changed, 15 insertions(+), 9 deletions(-) diff --git a/read-cache.c b/read-cache.c index d643a3f..f12a185 100644 --- a/read-cache.c +++ b/read-cache.c @@ -270,20 +270,26 @@ s

[PATCH 16/24] untracked cache: mark index dirty if untracked cache is updated

Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano --- cache.h | 1 + dir.c| 9 + read-cache.c | 2 +- 3 files changed, 11 insertions(+), 1 deletion(-) diff --git a/cache.h b/cache.h index f8b3dc5..fca979b 100644 --- a/cache.h +++ b/cache.h @@ -295,6 +295,7 @

[PATCH 11/24] untracked cache: load from UNTR index extension

Signed-off-by: Nguyễn Thái Ngọc Duy --- dir.c| 220 +++ dir.h| 2 + read-cache.c | 5 ++ 3 files changed, 227 insertions(+) diff --git a/dir.c b/dir.c index 1f2d701..e7d7df3 100644 --- a/dir.c +++ b/dir.c @@ -2275,3 +227

[PATCH 09/24] ewah: add convenient wrapper ewah_serialize_strbuf()

Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano --- ewah/ewah_io.c | 13 + ewah/ewok.h| 2 ++ split-index.c | 11 ++- 3 files changed, 17 insertions(+), 9 deletions(-) diff --git a/ewah/ewah_io.c b/ewah/ewah_io.c index 1c2d7af..43481b9 100644 --- a/ew

[PATCH 10/24] untracked cache: save to an index extension

Signed-off-by: Nguyễn Thái Ngọc Duy --- Documentation/technical/index-format.txt | 58 + cache.h | 3 + dir.c| 136 +++ dir.h| 1 + read-cache.c

[PATCH 06/24] untracked cache: record/validate dir mtime and reuse cached output

The main readdir loop in read_directory_recursive() is replaced with a new one that checks if cached results of a directory is still valid. If a file is added or removed from the index, the containing directory is invalidated (but not its subdirs). If directory's mtime is changed, the same happens

[PATCH 08/24] untracked cache: don't open non-existent .gitignore

This cuts down a signficant number of open(.gitignore) because most directories usually don't have .gitignore files. Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano --- dir.c | 26 +- 1 file changed, 25 insertions(+), 1 deletion(-) diff --git a/dir.c b

[PATCH 07/24] untracked cache: mark what dirs should be recursed/saved

If we redo this thing in a functional style, we would have one struct untracked_dir as input tree and another as output. The input is used for verification. The output is a brand new tree, reflecting current worktree. But that means recreate a lot of dir nodes even if a lot could be shared between

[PATCH 00/24] nd/untracked-cache updates

Code changes are all in 20/24, to avoid hard coding the test path. The rest is documentation changes. -- 8<-- diff --git a/Documentation/git-status.txt b/Documentation/git-status.txt index 7850f53..4dcad4e 100644 --- a/Documentation/git-status.txt +++ b/Documentation/git-status.txt @@ -59,7 +59,7

[PATCH 03/24] untracked cache: initial untracked cache validation

Make sure the starting conditions and all global exclude files are good to go. If not, either disable untracked cache completely, or wipe out the cache and start fresh. Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano --- dir.c | 113

[PATCH 04/24] untracked cache: invalidate dirs recursively if .gitignore changes

It's easy to see that if an existing .gitignore changes, its SHA-1 would be different and invalidate_gitignore() is called. If .gitignore is removed, add_excludes() will treat it like an empty .gitignore, which again should invalidate the cached directory data. if .gitignore is added, lookup_untr

[PATCH 05/24] untracked cache: make a wrapper around {open,read,close}dir()

This allows us to feed different info to read_directory_recursive() based on untracked cache in the next patch. Helped-by: Ramsay Jones Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano --- dir.c | 55 +++ 1 file changed, 47 i

[PATCH 02/24] untracked cache: record .gitignore information and dir hierarchy

The idea is if we can capture all input and (non-rescursive) output of read_directory_recursive(), and can verify later that all the input is the same, then the second r_d_r() should produce the same output as in the first run. The requirement for this to work is stat info of a directory MUST chan

[PATCH 01/24] dir.c: optionally compute sha-1 of a .gitignore file

This is not used anywhere yet. But the goal is to compare quickly if a .gitignore file has changed when we have the SHA-1 of both old (cached somewhere) and new (from index or a tree) versions. Helped-by: Junio C Hamano Helped-by: Torsten Bögershausen Signed-off-by: Nguyễn Thái Ngọc Duy Signed-