Re: [PATCH] __git_ps1: Don't kill shell if user types `set -e`

"Tom \"Ravi\" Hale" writes: > If a user types `set -e` in an interactive shell, and is using __git_ps1 > to set > their prompt, the shell will die if the current directory isn't inside a git > repository. > > This is because `set -e` instructs the shell to exit upon a command >

Re: [PATCH 3/3] rebase: pass --[no-]signoff option to git am

Giuseppe Bilotta writes: > Damnit! I just realized that I forgot to amend before the format-patch: > > On Sat, Apr 15, 2017 at 4:41 PM, Giuseppe Bilotta > wrote: > >> +signoff! passed to 'git am' > > This should be without the !

Re: Index files autocompletion too slow in big repositories (w / suggestion for improvement)

Johannes Sixt writes: > Cc Gábor. > > Am 15.04.2017 um 00:33 schrieb Ævar Arnfjörð Bjarmason: >> On Sat, Apr 15, 2017 at 12:08 AM, Carlos Pita >> wrote: >>> This is much faster (below 0.1s): >>> >>> __git_index_files () >>> { >>> local

Re: [PATCH] push: document & test --force-with-lease with multiple remotes

Ævar Arnfjörð Bjarmason writes: > Document & test for cases where there are two remotes pointing to the > same URL, and a background fetch & subsequent `git push > --force-with-lease` shouldn't clobber un-updated references we haven't > fetched. > > Some editors like

Re: [PATCH v5 4/8] convert: Separate generic structures and variables from the filter specific ones

Lars Schneider writes: >> -static struct cmd2process *find_multi_file_filter_entry(struct hashmap >> *hashmap, const char *cmd) >> +static struct subprocess_entry *find_multi_file_filter_entry(const char >> *cmd) > > I am curious why you removed the hashmap parameter

Re: [PATCH] submodule: prevent backslash expantion in submodule names

Jeff King writes: > The reason I mentioned escaping earlier is I wondered what would happen > when the submodule starts with a double-quote, or has a newline in the > name. Git's normal quoting would include backslash escape sequences, and > I wondered if we might be relying on

Re: [PATCH 2/2] config: handle conditional include when $GIT_DIR is not set up

On Sun, Apr 16, 2017 at 11:51:32AM -0400, Jeff King wrote: > > diff --git a/cache.h b/cache.h > > index e29a093839..27b7286f99 100644 > > --- a/cache.h > > +++ b/cache.h > > @@ -1884,6 +1884,8 @@ enum config_origin_type { > > > > struct config_options { > > unsigned int respect_includes :

Re: [PATCH v3 1/2] Fix nonnull errors reported by UBSAN with GCC 7.

Martin Liška writes: > From 0bdf4d717d3d368dd9676d15d20f8592c4d22fde Mon Sep 17 00:00:00 2001 > From: marxin > Date: Wed, 5 Apr 2017 14:31:32 +0200 > Subject: [PATCH 1/2] Fix nonnull errors reported by UBSAN with GCC 7. > > Replace call to memmove with newly

Re: [PATCH 1/2] config: prepare to pass more info in git_config_with_options()

On Sun, Apr 16, 2017 at 11:31:28AM -0400, Jeff King wrote: > On Sun, Apr 16, 2017 at 05:41:24PM +0700, Nguyễn Thái Ngọc Duy wrote: > > > So far we can only pass one flag, respect_includes, to thie function. We > > need to pass some more (non-flag even), so let's make it accept a struct > >

Re: [PATCH] sha1_file: remove an used fd variable

On Sun, Apr 16, 2017 at 07:04:01PM +, Sebastian Schuberth wrote: > Signed-off-by: Sebastian Schuberth > --- > sha1_file.c | 3 --- > 1 file changed, 3 deletions(-) > > diff --git a/sha1_file.c b/sha1_file.c > index 7106389..9ecf71f 100644 > --- a/sha1_file.c > +++

Re: [PATCH] server-info: avoid calling fclose(3) twice in update_info_file()

On Sun, Apr 16, 2017 at 06:55:58PM +0200, René Scharfe wrote: > If an error occurs when or after closing the stream we call fclose(3) > again in the error handler. The second call can exhibit undefined > behavior, so make sure to call fclose(3) at most once. Yikes. Good catch. > Also avoid >

Re: [PATCH v4 0/5] Kill manual ref parsing code in worktree.c

Duy Nguyen writes: > This is embarassing. I worked on and off on this series over a long > period of time. I guess at the end I thought everything was ok "since > the last time" and just sent it away without realizing I hadn't > actually run the test suite, because it does

Re: [PATCH] connect.c: handle errors from split_cmdline

Ævar Arnfjörð Bjarmason writes: > On Tue, Apr 11, 2017 at 12:54 PM, Jeff King wrote: >> On Tue, Apr 11, 2017 at 11:27:57AM +0200, Ævar Arnfjörð Bjarmason wrote: >> >>> Junio: If you're not in some rush to pick this up I'll take this, fix >>> up a bunch of other

Re: [PATCH] connect.c: handle errors from split_cmdline

Ævar Arnfjörð Bjarmason writes: >> That's fine by me. We may want to pick up the segfault one separately >> (though I don't think it's security-interesting). > > Up to you, but in case it's less work for you & Junio I already have > it in my branch of fallout from this

Re: [PATCH] Make git log work for git CWD outside of work tree

Jeff King writes: >> cwd with prefix. I was kinda hoping "super prefix" would solve it, but >> that one seems designed specifically for submodules. > > Ah, right. I think the issue is that "prefix" really serves two uses. > For things like command-line arguments, we use to find

Re: Feature request: --format=json

Ævar Arnfjörð Bjarmason writes: > On Sat, Apr 8, 2017 at 6:07 PM, Fred .Flintstone wrote: >> $ git log --format=json >> [{ >> "commit": "64eabf050e315a4c7a11e0c05ca163be7cf9075e", >> "tree": "b1e977800f40bbf6de906b1fe4f2de4b4b14f0fd", >>

Re: What's cooking in git.git (Apr 2017, #02; draft as of Sat, 15)

Duy Nguyen writes: >> * nd/worktree-add-lock (2017-04-15) 2 commits >> - SQUASH??? >> - worktree add: add --lock option >> > > Allow to lock a workktree immediately after it's created. This helps > prevent a race between "git worktree add; git worktree lock" and "git >

Re: [PATCH 01/12] grep: add ability to disable threading with --threads=0 or grep.threads=0

On Fri, Apr 14, 2017 at 11:23 PM, Jeff King wrote: > On Tue, Apr 11, 2017 at 10:56:01PM +0200, Ævar Arnfjörð Bjarmason wrote: > >> > Right, my suggestion was to teach "grep" to treat --threads=1 as "do not >> > spawn any other threads". I.e., to make it like the "0" case you were

[PATCH v2 4/8] grep: skip pthreads overhead when using one thread

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.

[PATCH v2 5/8] tests: add a PTHREADS prerequisite

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

[PATCH v2 6/8] pack-object & index-pack: add test for --threads warning under NO_PTHREADS

Add a test for the warning that's emitted when --threads or pack.threads is provided under NO_PTHREADS. This uses the new PTHREADS prerequisite. The assertion for !GETTEXT_POISON in the latter test is currently redundant, since unlike index-pack the pack-objects warnings aren't i18n'd. However

[PATCH v2 7/8] pack-objects: fix buggy warning about threads under NO_PTHREADS=YesPlease

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.

[PATCH v2 8/8] grep: given --threads with NO_PTHREADS=YesPlease, warn

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

[PATCH v2 3/8] grep: don't redundantly compile throwaway patterns under threading

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

[PATCH v2 2/8] grep: add tests for --threads=N and grep.threads

Add tests for when --threads=N is supplied on the command-line or when grep.threads is 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 for

[PATCH v2 1/8] grep: assert that threading is enabled when calling grep_{lock,unlock}

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

[PATCH v2 0/8] grep threading cleanup & tests

This is the spiritual successor to the "grep: add ability to disable threading with --threads=0 or grep.threads=0" patch I submitted as part of my PCRE series (<20170408132506.5415-2-ava...@gmail.com>). There's a long back & forth thread between me and Jeff King as a follow-up to that which I'll

Re: [PATCH] Documentation/git-checkout: make doc. of checkout clearer

On Sun, 2017-04-16 at 22:25 +0100, Philip Oakley wrote: > From: "Christoph Michelbach" > > It's: git checkout [-p|--patch] [] [--] ... > The one I quoted is direct from the Synopsis, which does indicate > there are  > potentially more aspects to resolve, such as the

Re: [PATCH] Documentation/git-checkout: make doc. of checkout clearer

From: "Christoph Michelbach" On Sun, 2017-04-16 at 19:03 +0100, Philip Oakley wrote: From: "Christoph Michelbach" > > On Sun, 2017-04-16 at 00:28 +0100, Philip Oakley wrote: > > > > From: "Christoph Michelbach" > > > > >

[PATCH] sha1_file: remove an used fd variable

Signed-off-by: Sebastian Schuberth --- sha1_file.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/sha1_file.c b/sha1_file.c index 7106389..9ecf71f 100644 --- a/sha1_file.c +++ b/sha1_file.c @@ -3970,7 +3970,6 @@ int read_loose_object(const char *path,

Re: [PATCH] Documentation/git-checkout: make doc. of checkout clearer

On Sun, 2017-04-16 at 19:03 +0100, Philip Oakley wrote: > From: "Christoph Michelbach" > > > > On Sun, 2017-04-16 at 00:28 +0100, Philip Oakley wrote: > > > > > > From: "Christoph Michelbach" > > > > > > > > > > > > While technically in the

Re: [BUG] ls-files '**' globstar matches one or more directories instead of zero or more directories

On IRC someone pointed me to the glossary section for pathspec, and I find that even more confusing. In the section about ":(glob)" it says: > For example, "**/foo" matches file or directory "foo" anywhere, the same as > pattern "foo". This is not true for ls-files: ":(glob)**/.gitignore" is

Re: [PATCH] Documentation/git-checkout: make doc. of checkout clearer

From: "Christoph Michelbach" On Sun, 2017-04-16 at 00:28 +0100, Philip Oakley wrote: From: "Christoph Michelbach" > > While technically in the documentation, the fact that changes > introduced by a checkout are staged automatically, was > not

[PATCH] files_for_each_reflog_ent_reverse(): close stream and free strbuf on error

Exit the loop orderly through the cleanup code, instead of dashing out with logfp still open and sb leaking. Found with Cppcheck. Signed-off-by: Rene Scharfe --- refs/files-backend.c | 20 1 file changed, 12 insertions(+), 8 deletions(-) diff --git

[PATCH] server-info: avoid calling fclose(3) twice in update_info_file()

If an error occurs when or after closing the stream we call fclose(3) again in the error handler. The second call can exhibit undefined behavior, so make sure to call fclose(3) at most once. Also avoid calling close(2) after fd has been successfully associated with the stream, as fclose(3) has

[PATCH] am: close stream on error, but not stdin

Avoid closing stdin, but do close an actual input file on error exit. Found with Cppcheck. Signed-off-by: Rene Scharfe --- builtin/am.c | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/builtin/am.c b/builtin/am.c index f7a7a971fb..805f56cec2 100644 ---

Re: [BUG] ls-files '**' globstar matches one or more directories instead of zero or more directories

On 16 April 2017 at 12:25, Duy Nguyen wrote: > git ls-files ':(glob)**/*' > > Without that '**' is a normal '*' and matching just subdirs is expected. But '*/' should match exactly one subdirectory deep. Instead it matches one more more subdirectories. Meaning it behaves the

Re: [PATCH 2/2] config: handle conditional include when $GIT_DIR is not set up

On Sun, Apr 16, 2017 at 05:41:25PM +0700, Nguyễn Thái Ngọc Duy wrote: > If setup_git_directory() and friends have not been called, > get_git_dir() (because of includeIf.gitdir:XXX) would lead to > > die("BUG: setup_git_env called without repository"); > > There are two cases when a config

Re: [PATCH 1/2] config: prepare to pass more info in git_config_with_options()

On Sun, Apr 16, 2017 at 05:41:24PM +0700, Nguyễn Thái Ngọc Duy wrote: > So far we can only pass one flag, respect_includes, to thie function. We > need to pass some more (non-flag even), so let's make it accept a struct > instead of an integer. Yeah, this makes sense. But... > diff --git

Re: [PATCH v1] travis-ci: add static analysis build job to run coccicheck

On 2017-04-11 09:26, Lars Schneider wrote: Add a dedicated build job for static analysis. As a starter we only run coccicheck but in the future we could run Clang Static Analyzer or similar tools, too. Just FYI, some time ago someone (I don't recall who) signed up Git with Coverity's free

Re: [PATCH] Documentation/git-checkout: make doc. of checkout clearer

On Sun, 2017-04-16 at 00:28 +0100, Philip Oakley wrote: > From: "Christoph Michelbach" > > > > While technically in the documentation, the fact that changes > > introduced by a checkout are staged automatically, was > > not obvious when reading its documentation. It is

Re: [BUG] ls-files '**' globstar matches one or more directories instead of zero or more directories

On Sat, Apr 15, 2017 at 2:17 AM, Alistair Buxton wrote: > To reproduce, go to any git repository and run: > > diff <(git ls-files '**/*' | sort) <(git ls-files | sort) Actually the '**/' magic only kicks in if you write git ls-files ':(glob)**/*' Without that '**' is

Re: [BUG] ls-files '**' globstar matches one or more directories instead of zero or more directories

On Sat, Apr 15, 2017 at 2:17 AM, Alistair Buxton wrote: > To reproduce, go to any git repository and run: > > diff <(git ls-files '**/*' | sort) <(git ls-files | sort) > > Expected result: No output since both commands should produce identical > output. > > Actual

Re: What's cooking in git.git (Apr 2017, #02; draft as of Sat, 15)

On Sat, Apr 15, 2017 at 5:14 PM, Junio C Hamano wrote: > * nd/conditional-config-include (2017-04-14) 2 commits > - config: resolve symlinks in conditional include's patterns > - path.c: and an option to call real_path() in expand_user_path() > $GIT_DIR may in some cases be

[PATCH 2/2] config: handle conditional include when $GIT_DIR is not set up

If setup_git_directory() and friends have not been called, get_git_dir() (because of includeIf.gitdir:XXX) would lead to die("BUG: setup_git_env called without repository"); There are two cases when a config file could be read before $GIT_DIR is located. The first one is

[PATCH 1/2] config: prepare to pass more info in git_config_with_options()

So far we can only pass one flag, respect_includes, to thie function. We need to pass some more (non-flag even), so let's make it accept a struct instead of an integer. Signed-off-by: Nguyễn Thái Ngọc Duy --- Prep patch for the bug fix in 2/2. builtin/config.c | 21

[PATCH] __git_ps1: Don't kill shell if user types `set -e`

If a user types `set -e` in an interactive shell, and is using __git_ps1 to set their prompt, the shell will die if the current directory isn't inside a git repository. This is because `set -e` instructs the shell to exit upon a command returning a non-zero exit status, and the following command

Business Proposal

Dear Friend, I would like to discuss a very important issue with you. I am writing to find out if this is your valid email. Please, let me know if this email is valid Kind regards Adrien Saif Attorney to Quatif Group of Companies

Re: Feature request: Configurable branch colors in git status --short --branch

On Sat, Apr 15, 2017 at 01:00:51PM -0700, Stephen Kent wrote: > It would be nice if the branch, remote tracking branch, and branch commit > comparison count colors in git status --short --branch were configurable > like the other git status colors. That seems like a reasonable thing to want. I

[PATCH v3 14/20] do_for_each_entry_in_dir(): eliminate `offset` argument

It was never used. Signed-off-by: Michael Haggerty --- refs/files-backend.c | 4 ++-- refs/ref-cache.c | 6 +++--- refs/ref-cache.h | 11 +-- 3 files changed, 10 insertions(+), 11 deletions(-) diff --git a/refs/files-backend.c b/refs/files-backend.c

[PATCH v3 12/20] ref-cache: use a callback function to fill the cache

It is a leveling violation for `ref_cache` to know about `files_ref_store` or that it should call `read_loose_refs()` to lazily fill cache directories. So instead, have its constructor take as an argument a callback function that it should use for lazy-filling, and change `files_ref_store` to

[PATCH v3 16/20] get_loose_ref_cache(): new function

Extract a new function, `get_loose_ref_cache()`, from get_loose_ref_dir(). The function returns the `ref_cache` for the loose refs of a `files_ref_store`. Signed-off-by: Michael Haggerty --- refs/files-backend.c | 9 +++-- 1 file changed, 7 insertions(+), 2

[PATCH v3 02/20] refs_read_raw_ref(): new function

Extract a new function from `refs_resolve_ref_unsafe()`. It will be useful elsewhere. Signed-off-by: Michael Haggerty --- refs.c | 11 +-- refs/refs-internal.h | 4 2 files changed, 13 insertions(+), 2 deletions(-) diff --git a/refs.c b/refs.c

[PATCH v3 09/20] refs: split `ref_cache` code into separate files

The `ref_cache` code is currently too tightly coupled to `files-backend`, making the code harder to understand and making it awkward for new code to use `ref_cache` (as we indeed have planned). Start loosening that coupling by splitting `ref_cache` into a separate module. This commit moves code,

[PATCH v3 17/20] cache_ref_iterator_begin(): make function smarter

Change `cache_ref_iterator_begin()` to take two new arguments: * `prefix` -- to iterate only over references with the specified prefix. * `prime_dir` -- to "prime" (i.e., pre-load) the cache before starting the iteration. The new functionality makes it possible for

[PATCH v3 04/20] refs_verify_refname_available(): implement once for all backends

It turns out that we can now implement `refs_verify_refname_available()` based on the other virtual functions, so there is no need for it to be defined at the backend level. Instead, define it once in `refs.c` and remove the `files_backend` definition. Signed-off-by: Michael Haggerty

[PATCH v3 05/20] refs_verify_refname_available(): use function in more places

Change `lock_raw_ref()` and `lock_ref_sha1_basic()` to use `refs_verify_refname_available()` instead of `verify_refname_available_dir()`. This means that those callsites now check for conflicts with all references rather than just packed refs, but the performance cost shouldn't be significant (and

[PATCH v3 20/20] do_for_each_entry_in_dir(): delete function

Its only remaining caller was itself. Signed-off-by: Michael Haggerty --- refs/ref-cache.c | 21 - refs/ref-cache.h | 11 --- 2 files changed, 32 deletions(-) diff --git a/refs/ref-cache.c b/refs/ref-cache.c index b3a30350d7..6059362f1d 100644

[PATCH v3 06/20] ref-cache: rename `add_ref()` to `add_ref_entry()`

This function's visibility is about to be increased, so give it a more distinctive name. Signed-off-by: Michael Haggerty --- refs/files-backend.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/refs/files-backend.c b/refs/files-backend.c index

[PATCH v3 07/20] ref-cache: rename `find_ref()` to `find_ref_entry()`

This function's visibility is about to be increased, so give it a more distinctive name. Signed-off-by: Michael Haggerty --- refs/files-backend.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/refs/files-backend.c b/refs/files-backend.c index

[PATCH v3 03/20] refs_ref_iterator_begin(): new function

Extract a new function from `do_for_each_ref()`. It will be useful elsewhere. Signed-off-by: Michael Haggerty --- refs.c | 15 +-- refs/refs-internal.h | 11 +++ 2 files changed, 24 insertions(+), 2 deletions(-) diff --git a/refs.c

[PATCH v3 19/20] files_pack_refs(): use reference iteration

Use reference iteration rather than `do_for_each_entry_in_dir()` in the definition of `files_pack_refs()`. This makes the code shorter and easier to follow, because the logic can be inline rather than spread between the main function and a callback function, and it removes the need to use

[PATCH v3 13/20] refs: handle "refs/bisect/" in `loose_fill_ref_dir()`

That "refs/bisect/" has to be handled specially when filling the ref_cache for loose references is a peculiarity of the files backend, and the ref-cache code shouldn't need to know about it. So move this code to the callback function, `loose_fill_ref_dir()`. Signed-off-by: Michael Haggerty

[PATCH v3 11/20] refs: record the ref_store in ref_cache, not ref_dir

Instead of keeping a pointer to the `ref_store` in every `ref_dir` entry, store it once in `struct ref_cache`, and change `struct ref_dir` to include a pointer to its containing `ref_cache` instead. This makes it easier to add to the information that is accessible from a `ref_dir` without

[PATCH v3 10/20] ref-cache: introduce a new type, ref_cache

For now, it just wraps a `ref_entry *` that points at the root of the tree. Soon it will hold more information. Add two new functions, `create_ref_cache()` and `free_ref_cache()`. Make `free_ref_entry()` private. Change files-backend to use this type to hold its caches. Signed-off-by: Michael

[PATCH v3 18/20] commit_packed_refs(): use reference iteration

Use reference iteration rather than do_for_each_entry_in_dir() in the definition of commit_packed_refs(). Note that an internal consistency check that was previously done in `write_packed_entry_fn()` is not there anymore. This is actually an improvement: The old error message was emitted when

[PATCH v3 08/20] ref-cache: rename `remove_entry()` to `remove_entry_from_dir()`

This function's visibility is about to be increased, so give it a more distinctive name. Signed-off-by: Michael Haggerty --- refs/files-backend.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/refs/files-backend.c b/refs/files-backend.c index

[PATCH v3 15/20] get_loose_ref_dir(): function renamed from get_loose_refs()

The new name is more analogous to `get_packed_ref_dir()`. Signed-off-by: Michael Haggerty --- refs/files-backend.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/refs/files-backend.c b/refs/files-backend.c index c0550ad9d6..3beab0b752 100644 ---

[PATCH v3 01/20] get_ref_dir(): don't call read_loose_refs() for "refs/bisect"

Since references under "refs/bisect/" are per-worktree, they have to be sought in the worktree rather than in the main repository. But since loose references are found by traversing directories, the reference iterator won't even get the idea to look for a "refs/bisect/" directory in the worktree

[PATCH v3 00/20] Separate `ref_cache` into a separate module

This is v3 of a patch series to separate the reference caching code into a separate module that interacts with `files_ref_cache` more at arm's length. Thanks to Stefan and Duy for their feedback about v2 [1]. This version has only minor changes since v2 (and indeed since v1 [2]): * Rebased onto

Business Proposal

Dear Friend, I would like to discuss a very important issue with you. I am writing to find out if this is your valid email. Please, let me know if this email is valid Kind regards Adrien Saif Attorney to Quatif Group of Companies

Re: [PATCH v2 00/20] Separate `ref_cache` into a separate module

On 04/07/2017 01:53 PM, Duy Nguyen wrote: > On Wed, Apr 5, 2017 at 9:03 PM, Duy Nguyen wrote: >> On Sat, Apr 1, 2017 at 12:16 PM, Michael Haggerty >> wrote: >>> Duy, have you looked over my patch series? Since you've been working in >>> the area, your

Re: [PATCH v2 19/20] files_pack_refs(): use reference iteration

On 04/07/2017 01:51 PM, Duy Nguyen wrote: > On Fri, Mar 31, 2017 at 9:11 PM, Michael Haggerty > wrote: >> Use reference iteration rather than do_for_each_entry_in_dir() in the >> definition of files_pack_refs(). > > A "why" is missing here. My guess is