From: Kunal Tyagi
Report the current hunk count and total number of hunks for the current
file in the prompt
Adjust the expected output in some tests to account for new data on the prompt
Signed-off-by: Kunal Tyagi
---
git-add--interactive.perl | 2 +-
t/t3701-add-interactive.sh | 2 +-
2 fil
Hi git contributors!
I'm Kunal Tyagi. While I was choosing the relevant patches for a commit
using the git add -p command, I found that there was no feedback regarding
how many hunks from the current file had been processed and how many were
left. So I decided to add a small change to the prompt w
Now that object reading operations are internally protected, the
submodule initialization functions at builtin/grep.c:grep_submodule()
are very close to being thread-safe. Let's take a look at each call and
remove from the critical section what we can, for better performance:
- submodule_from_path
In builtin/grep.c:add_work() we pre-load the userdiff drivers before
adding the grep_source in the todo list. This operation is currently
being performed after acquiring the grep_mutex, but as it's already
thread-safe, we don't need to protect it here. So let's move it out of
the critical section w
Some fields in struct raw_object_store are lazy initialized by the
thread-unsafe packfile.c:prepare_packed_git(). Although this function is
present in the call stack of git-grep threads, all paths to it are
currently protected by obj_read_lock() (and the main thread usually
indirectly calls it befo
Currently, submodule-config.c doesn't have an externally acessible
function to read gitmodules only if it wasn't already read. But this
exactly behavior is internally implemented by gitmodules_read_check(),
to perform a lazy load. Let's merge this function with
repo_read_gitmodules() adding an 'ski
They were disabled at 53b8d93 ("grep: disable threading in non-worktree
case", 12-12-2011), due to observable performance drops (to the point
that using a single thread would be faster than multiple threads). But
now that zlib inflation can be performed in parallel we can regain the
speedup, so let
Allow object reading to be performed by multiple threads protecting it
with an internal lock. The lock usage can be toggled with
enable_obj_read_lock() and disable_obj_read_lock(). Currently, the
functions which can be safely called in parallel are:
read_object_file_extended(), repo_read_object_fil
git-grep uses 'grep_read_mutex' to protect its calls to object reading
operations. But these have their own internal lock now, which ensures a
better performance (allowing parallel access to more regions). So, let's
remove the former and, instead, activate the latter with
enable_obj_read_lock().
S
replace-object functions are very close to being thread-safe: the only
current racy section is the lazy initialization at
prepare_replace_object(). The following patches will protect some object
reading operations to be called threaded, but before that, replace
functions must be protected. To do so
There're currently two function calls in builtin/grep.c:grep_submodule()
which might result in race conditions:
- submodule_from_path(): it has config_with_options() in its call stack
which, in turn, may have read_object_file() in its own. Therefore,
calling the first function without acquirin
git-grep uses an internal grep_read_mutex to protect object reading
operations. Similarly, there's a grep_attr_mutex to protect calls to the
gitattributes machinery. However, two of the three functions protected
by the last mutex may also perform object reading, as seen bellow:
- userdiff_get_text
This series focus on re-enabling threads at git-grep for the
non-worktree case. They are currently disabled due to being slower than
single-threaded grep in this case. However, by allowing parallel zlib
inflation when reading objects, speedups of up to 3x were observed.
The patchset also contains
deref_tag() calls is_promisor_object() and parse_object(), both of which
perform lazy initializations and other thread-unsafe operations. If it
was only called by grep_objects() this wouldn't be a problem as the
latter is only executed by the main thread. However, deref_tag() is also
present in rea
Alex Henrie writes:
> The condition "if (q->nr <= j)" checks whether the loop exited normally
> or via a break statement. This check can be avoided by replacing the
> jump out of the inner loop with a jump to the end of the outer loop.
>
> With the break replaced by a goto, the two diff_q calls t
"Kunal Tyagi via GitGitGadget" writes:
> From: Kunal Tyagi
> Subject: Re: [PATCH v2 1/1] git-add--interactive.perl: Add progress counter
> in the prompt
Either of these two, perhaps (I'd use the former if I were writing
this patch):
add -i: show progress counter in the prompt
Alex Henrie writes:
> The variable g was being set to the same value both at the beginning of
> the function and before the loop. The assignment before the loop was
> kept because it helps clarify what the loop does, and the redundant
> assignment at the beginning of the function was removed.
Wr
CB Bailey writes:
> For easier discussion, I've snipped the original patch and replaced with
> one with enough context to show the entire function.
>
> I was reviewing this patch and it appeared to introduce a change in
> behaviour.
>
>> diff --git a/diffcore-break.c b/diffcore-break.c
>> index 8
The condition "if (q->nr <= j)" checks whether the loop exited normally
or via a break statement. This check can be avoided by replacing the
jump out of the inner loop with a jump to the end of the outer loop.
With the break replaced by a goto, the two diff_q calls then can be
replaced with a sing
On Sun, Sep 29, 2019 at 3:37 AM CB Bailey wrote:
>
> Previously, if the condition matched in the inner loop, the function
> would null out the entry in the queue that that inner loop had reached
> (q->queue[j] = NULL) and then break out of the inner loop. This meant
> that the outer loop would ski
Hi guys, any updates?
On 22.09.19 02:36, Alicenab wrote:
Hi there!
I have a translated ProGit2 book to Azerbaijan language.
As code of country name name for our country(az) have already taken, I
have created "aze" version of it.
I hope it will be no problem for you.
Partial translations availa
Since this is a git-gui dialog/prompt, why not use the git-gui icon?
This will mean some uniformity between all the platforms (though I'm not
sure if other platforms even use GIT_ASK_YESNO). It would also probably
save you the hacks needed to find out the git-for-windows icon.
Well, there is th
One minor nitpick: please add a comment at the top of the file
documenting the `--title` option, and the usage of the program in
general.
Other than that, looks good. Thanks.
On 26/09/19 08:29AM, Johannes Schindelin via GitGitGadget wrote:
> From: Johannes Schindelin
>
> "Question?" is maybe
What is the difference between SSH_ASKPASS and GIT_ASKPASS? On my first
read, I assumed SSH_ASKPASS is replaced by GIT_ASKPASS, but I might be
wrong.
On 26/09/19 08:29AM, Johannes Schindelin via GitGitGadget wrote:
> From: Johannes Schindelin
>
> Signed-off-by: Johannes Schindelin
> ---
> gi
On 26/09/19 08:29AM, Heiko Voigt via GitGitGadget wrote:
> From: Heiko Voigt
>
> Make use of the new environment variable GIT_ASK_YESNO to support the
> recently implemented fallback in case unlink, rename or rmdir fail for
> files in use on Windows. The added dialog will present a yes/no questio
Hi Philip, Bert,
Is there any way I can test this change? Philip, I ran the rebase you
mention in the GitHub issue [0], and I get that '9c8cba6862abe5ac821' is
an unknown revision.
Is there any quick way I can reproduce this (maybe on a sample repo)?
[0] https://github.com/git-for-windows/git/
On Sat, Sep 28, 2019 at 06:56:46PM -0600, Alex Henrie wrote:
> The condition "if (q->nr <= j)" checks whether the loop exited normally
> or via a break statement. This check can be avoided by replacing the
> jump to the end of the loop with a jump to the end of the function.
>
> With the break rep
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'. The ones marked with '.' do not appear in any of
the integration branches, but I am still holding onto them.
I've been offline for a week or so
Eric Wong writes:
> Patches 1-11 are largely unchanged from the original series with the
> exception of 2, which is new and posted at:
>
> https://public-inbox.org/git/20190908074953.kux7zz4y7iolqko4@whir/
>
> 12-17 take further steps to get us away from hashmap_entry being
> the first elem
29 matches
Mail list logo
