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 pclo...@gmail.com
Signed-off-by: Junio C Hamano gits...@pobox.com
---
dir.c | 2 +-
1 file changed, 1
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 sand...@crustytoothpaste.net
Signed-off-by: Nguyễn Thái Ngọc Duy
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
Helped-by: Eric Sunshine sunsh...@sunshineco.com
Helped-by: Junio C Hamano gits...@pobox.com
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
Documentation/git-update-index.txt | 6 ++
builtin/update-index.c | 168 +
2 files changed, 174
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 pclo...@gmail.com
Signed-off-by: Junio C Hamano gits...@pobox.com
---
builtin/commit.c | 5 +++--
wt-status.c | 2 ++
2 files changed, 5 insertions(+), 2
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.
Helped-by: Eric Sunshine sunsh...@sunshineco.com
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
Signed-off-by: Junio C Hamano gits...@pobox.com
---
compat/mingw.c | 11 +++
compat/mingw.h | 9 +
2 files changed, 20 insertions(+)
diff --git a/compat/mingw.c
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
Signed-off-by: Junio C Hamano gits...@pobox.com
---
.gitignore | 1 +
Makefile | 1 +
t/t7063-status-untracked-cache.sh (new +x) | 353 +
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
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
This could be used to verify correct behavior in tests
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
Signed-off-by: Junio C Hamano gits...@pobox.com
---
dir.c | 12
1 file changed, 12 insertions(+)
diff --git a/dir.c b/dir.c
index 439ff22..c5ca5ce 100644
--- a/dir.c
+++
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
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
+++
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
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 pclo...@gmail.com
Signed-off-by: Junio C Hamano gits...@pobox.com
---
dir.c | 26 +-
1 file changed, 25 insertions(+),
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
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
This allows us to feed different info to read_directory_recursive()
based on untracked cache in the next patch.
Helped-by: Ramsay Jones ram...@ramsay1.demon.co.uk
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
Signed-off-by: Junio C Hamano gits...@pobox.com
---
dir.c | 55
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
Signed-off-by: Junio C Hamano gits...@pobox.com
---
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
+++
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
Signed-off-by: Junio C Hamano gits...@pobox.com
---
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
---
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
Documentation/technical/index-format.txt | 58 +
cache.h | 3 +
dir.c| 136 +++
dir.h| 1
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
Signed-off-by: Junio C Hamano gits...@pobox.com
---
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
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
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
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 pclo...@gmail.com
Signed-off-by: Junio C Hamano
Helped-by: Eric Sunshine sunsh...@sunshineco.com
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
t/t3080-list-files.sh (new +x) | 134 +
1 file changed, 134 insertions(+)
create mode 100755 t/t3080-list-files.sh
diff --git
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
Signed-off-by: Junio C Hamano gits...@pobox.com
---
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
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 pclo...@gmail.com
---
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
Signed-off-by: Junio C Hamano gits...@pobox.com
---
Documentation/git-ls-files.txt | 6 ++
builtin/ls-files.c | 28
2 files changed, 34 insertions(+)
diff --git a/Documentation/git-ls-files.txt
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 pclo...@gmail.com
Signed-off-by: Junio C Hamano gits...@pobox.com
---
builtin/ls-files.c | 2 +-
1 file
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
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
Signed-off-by: Junio C Hamano gits...@pobox.com
---
Documentation/git-ls-files.txt | 7 +++
builtin/ls-files.c | 38 +++---
2 files changed, 42 insertions(+), 3 deletions(-)
diff --git
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
Signed-off-by: Junio C Hamano gits...@pobox.com
---
Documentation/git-ls-files.txt | 7 +++
builtin/ls-files.c | 7 +++
2 files changed, 14 insertions(+)
diff --git a/Documentation/git-ls-files.txt
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
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
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
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
Signed-off-by: Junio C Hamano gits...@pobox.com
---
Documentation/git-list-files.txt | 3 +++
builtin/ls-files.c | 2 ++
2 files changed, 5 insertions(+)
diff --git a/Documentation/git-list-files.txt
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 pclo...@gmail.com
Signed-off-by: Junio C Hamano gits...@pobox.com
---
builtin/ls-files.c | 48 +++-
1 file
This is the second (and preferred) source for color information. This
will override $LS_COLORS.
Helped-by: Michael Blume blume.m...@gmail.com
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
Documentation/config.txt | 11 +++
ls_colors.c | 30
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 pclo...@gmail.com
Signed-off-by: Junio C Hamano gits...@pobox.com
---
color.h | 2 ++
ls_colors.c | 66
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
Signed-off-by: Junio C Hamano gits...@pobox.com
---
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
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
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
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
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
Signed-off-by: Junio C Hamano gits...@pobox.com
---
Documentation/git-list-files.txt | 4
builtin/ls-files.c | 2 ++
2 files changed, 6 insertions(+)
diff --git a/Documentation/git-list-files.txt
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
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 gits...@pobox.com
Helped-by: Torsten Bögershausen tbo...@web.de
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 pclo...@gmail.com
Signed-off-by: Junio C Hamano gits...@pobox.com
---
dir.c | 113
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,
- 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
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.
This opens a door of using submodule with multiple worktrees
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
git-submodule.sh | 2 +-
submodule.c| 6 +++---
t/lib-submodule-update.sh | 8
t/t7400-submodule-basic.sh
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 pclo...@gmail.com
---
Documentation/config.txt | 3 +++
setup.c | 7 ++-
2 files
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
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
/SCRIPT
I.e., the modification marked [!] was silently lost during rebase!
Just a wild guess:
Junio C Hamano gitster at pobox.com writes:
snip
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
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
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
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
It is only used internally now. Document it a little bit better, too.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
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
+++
It makes no sense to delete a reference that is already known not to
exist.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
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
Creating a reference requires a new_sha1 that is not NULL and not
null_sha1.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
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
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
Instead, if old_sha1 is non-NULL, verify it; otherwise, don't.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
builtin/receive-pack.c | 3 +--
builtin/update-ref.c | 5 +++--
refs.c | 11 ++-
refs.h | 6 +++---
4 files changed, 13
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 mhag...@alum.mit.edu
---
branch.c | 5 +++--
builtin/commit.c | 2 +-
builtin/fetch.c| 6 --
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
There is no reason to reserve a gap between the public and private
flags values.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
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
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 mhag...@alum.mit.edu
---
refs.c | 8
refs.h | 15 +++
2 files changed, 15
Instead of having a separate have_old field, record this boolean value
as a bit in the flags field.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
refs.c | 45 -
1 file changed, 28 insertions(+), 17 deletions(-)
diff --git a/refs.c b/refs.c
On Sun, Feb 8, 2015 at 7:05 AM, Joachim Schmitz j...@schmitz-digital.de wrote:
Junio C Hamano gitster at 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
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.
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
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
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 p...@peff.net 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
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 feed
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
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
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 d...@ethzero.com wrote:
Junio C Hamano
Junio C Hamano gits...@pobox.com writes:
I would personally find the feature cute, but
snip
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
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
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 one or
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
#0
From: Jonathon Mah m...@jonathonmah.com
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.
Предлагаю высококачественный кофе от швейцарского производителя
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
On Sun, Feb 8, 2015 at 8:28 PM, Jeff King p...@peff.net 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
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
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 struct
84 matches
Mail list logo