On 01-09-2019 18:01, Junio C Hamano wrote:
> Ben writes:
>
>>
>> Would you like me to send in another patch or leave it like this?
>
> As long as you make it clear that you are 100% happy with the
> fixed-up result that appeared in 'pu', there is no need
Hi Junio,
On 30-08-2019 22:16, Junio C Hamano wrote:
> Ben Wijen writes:
>
>> -struct object_id head_oid;
>> -if (get_oid("HEAD", &head_oid)) {
>> -ret = error(_("could not determin
On 30-08-2019 22:15, Junio C Hamano wrote:
> Ben Wijen writes:
>
>> +
>> struct commit *head =
>> -lookup_commit_reference(the_repository,
>> -
When doing 'git rebase --autostash ' with a dirty worktree
a 'HEAD is now at ...' message is emitted, which is pointless as it refers to
the old active branch which isn't actually moved.
This commit removes the 'HEAD is now at...' message.
Signed-off-b
When doing 'git rebase --autostash ' with a dirty worktree
a 'HEAD is now at ...' message is emitted, which is pointless as it refers to
the old active branch which isn't actually moved.
This commit removes the 'HEAD is now at...' message.
Signed-off-b
er
git rebase upstream
git stash apply $AUTOSTASH
This commit reinstates the 'legacy script' behavior as introduced with
58794775: rebase: implement --[no-]autostash and rebase.autostash
Signed-off-by: Ben Wijen
---
builtin/rebase.c| 8 ++--
t/t3420-reb
Here are my "fix things without making unnecessary changes"
Fixing a copy-paste fault which I missed in v5...
Ben Wijen (2):
builtin/rebase.c: make sure the active branch isn't moved when
autostashing
builtin/rebase.c: Remove obsolete message
builtin/rebase.c
When doing 'git rebase --autostash ' with a dirty worktree
a 'HEAD is now at ...' message is emitted, which is pointless as it refers to
the old active branch which isn't actually moved.
This commit removes the 'HEAD is now at...' message.
Signed-off-b
er
git rebase upstream
git stash apply $AUTOSTASH
This commit reinstates the 'legacy script' behavior as introduced with
58794775: rebase: implement --[no-]autostash and rebase.autostash
Signed-off-by: Ben Wijen
---
builtin/rebase.c| 8 ++--
t/t3420-reb
Here are my "fix things without making unnecessary changes"
Ben Wijen (2):
builtin/rebase.c: make sure the active branch isn't moved when
autostashing
builtin/rebase.c: Remove obsolete message
builtin/rebase.c| 13 +
t/t3420-rebase-au
ash is re-applied after the rebase, leaving nothing
to be guessed about.
Thank you,
Ben Wijen (1):
rebase.c: make sure the active branch isn't moved when autostashing
builtin/rebase.c| 18 ++
t/t3420-rebase-autostash.sh | 12
2 files changed, 14 insertions(+), 16 deletions(-)
--
2.22.0
...' message has now been removed.
Signed-off-by: Ben Wijen
---
builtin/rebase.c| 18 ++
t/t3420-rebase-autostash.sh | 12
2 files changed, 14 insertions(+), 16 deletions(-)
diff --git a/builtin/rebase.c b/builtin/rebase.c
index 670096c065..a928f44941
...' message has now been removed.
Signed-off-by: Ben Wijen
---
builtin/rebase.c| 18 ++
t/t3420-rebase-autostash.sh | 16
2 files changed, 18 insertions(+), 16 deletions(-)
diff --git a/builtin/rebase.c b/builtin/rebase.c
index 670096c065..a
Hi,
I have done some more tests on what's actually going on.
The active branch is currently reset to master (before the rebase)
The confusion was because of me naming the active branch 'upstream'
I hope this clears things up...
Ben Wijen (1):
rebase.c: make sure the active bra
tash apply $AUTOSTASH
This commit reinstates the 'legacy script' behavior as introduced with
58794775: rebase: implement --[no-]autostash and rebase.autostash
Signed-off-by: Ben Wijen
---
builtin/rebase.c| 18 ++
t/t3420-rebase-autostash.sh | 13 +-
Hi Phillip, Junio,
Thank you for taking the time to look into this.
With this new patch I think I've addressed all your concerns.
Ben Wijen (1):
rebase.c: make sure current branch isn't moved when autostashing
builtin/rebase.c| 18 ++
t/t3420-rebase-au
reset --hard' emits the 'HEAD is now at ...' which was also
included in the builtin rebase
I saw no reason to keep that message as - with my patch - we have concluded the
HEAD must not change.
Ben...
On 20-08-2019 11:00, Phillip Wood wrote:
> Hi Ben
>
> I need to have a lo
In the description of 'objects/pack', 'object' should be
pluralized to match the subject and agree with the
rest of the sentence.
Signed-off-by: Ben Milman
---
Documentation/gitrepository-layout.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documen
reset --hard master
git checkout master
git rebase upstream
git stash apply $AUTOSTASH
So, the problem with the actual behavior is the move of the currently active
branch with 'git reset --hard master'
Best regards,
Ben...
On 19-08-2019 11:26, Phillip Wood wrote:
> H
When using `git rebase --autostash ` and
the workarea is dirty, the active branch is incorrectly reset
to the rebase branch.
This test will check for such behavior.
Signed-off-by: Ben Wijen
---
t/t3420-rebase-autostash.sh | 9 +
1 file changed, 9 insertions(+)
diff --git a/t/t3420
The rebase --autostash incorrectly moved the current branch to orig_head, where
orig_head -- commit object name of tip of the branch before rebasing
It seems this was incorrectly taken over from git-legacy-rebase.sh
Signed-off-by: Ben Wijen
---
builtin/rebase.c| 18
I found an issue with git rebase --autostash with an dirty
worktree/index.
It seems the currently active branch is moved, which is not correct.
The following patches contain both a test and a fix.
Ben Wijen (2):
t3420: never change upstream branch
rebase.c: make sure current branch isn&#
Peff is completely right: the log showed host=smpt.gmail.com:587 as
expected. Keychain confirms.
Thanks!
D. Ben Knoble
P.S. Be sure to delete /tmp/credential.log afterwards to clean up your
passwords.
On Mon, Aug 12, 2019 at 6:18 PM Jeff King wrote:
>
> On Mon, Aug 12, 2019 at 06:0
Hello all,
I spent a frustrating hour today hoping to setup git-send-email with
my gmail account. I've been able to confirm the following:
1. git credential works
# git config credential.helper
osxkeychain
# git credential fill <
Hello My Dear,
We write to let you know that your package is due to be deliver to you
and we can not afford to keep the package in this office any longer.
You need to understand that your package is here to be deliver to you,
not to be dope here without proper arrangement on how to get it to
you.
My good friend
I am Mr. John Ben, the manager of Petroleum Engineer United State Of
America In my department i have a package for you If
you are interested then it is compulsory you contact me with
above details of yours for further procedure.
Your Full Name___
Your Home
> Ben: Could you rerun all your special testcases to make sure things
> are good with this patch too? It'd be much appreciated.
Many thanks for the super fast turnaround Elijah and Szeder!
I can confirm with 2.22.0-rc3 plus your patch this failing testcase
now passes, and indeed our
ult.
I’ll let you know if I get any further investigating this.
Best Regards,
Ben Humphreys
On Tue, Jun 4, 2019 at 6:23 AM Junio C Hamano wrote:
>
> A release candidate Git v2.22.0-rc3 is now available for testing
> at the usual places. It is comprised of 718 non-merge commits
>
superproject.
This patch rectifies this situation. It actually passes `--no-fetch` to
`git submodule update` as well on the grounds they the submodule has only just
been cloned, so fetching from the remote again only serves to slow things down.
Signed-off-by: Ben Avison
---
Documentation/git-clone.txt
On 16/05/2019 12:31, Duy Nguyen wrote:
On Tue, May 14, 2019 at 2:46 AM Ben Avison wrote:
When using `git clone --recurse-submodules` there was previously no way to
pass a `--remote` switch to the implicit `git submodule update` command for
any use case where you want the submodules to be
On 13/05/2019 22:12, Ævar Arnfjörð Bjarmason wrote:
On Mon, May 13 2019, Ben Avison wrote:
+ if (option_remote_submodules == 1) {
I see you copied this from code above the context, but to check a bool
variable just use "if (var)" not "if (var == 1)".
OK
superproject.
This patch rectifies this situation. It actually passes `--no-fetch` to
`git submodule update` as well on the grounds they the submodule has only just
been cloned, so fetching from the remote again only serves to slow things down.
Signed-off-by: Ben Avison
---
Documentation/git-clone.txt
On 4/16/2019 9:19 AM, Junio C Hamano wrote:
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 holdi
> It fixes not just this issue, but now the whole test suite passes with
> GIT_TEST_FSMONITOR, i.e. this test that's been failing for ~2 years also
> works now:
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpubli
> c-
> inbox.org%2Fgit%2F87k1vwn9qe.fsf%40evledraar.gmail.com%2F
On 2/14/2019 5:14 AM, Duy Nguyen wrote:
On Thu, Feb 14, 2019 at 5:02 PM Ævar Arnfjörð Bjarmason
wrote:
Take a look at stat data, st_dev, st_uid, st_gid and st_mode are the
same most of the time. ctime should often be the same (or differs just
slightly). And sometimes mtime is the same as wel
> -Original Message-
> From: Junio C Hamano On Behalf Of Junio C Hamano
> Sent: Friday, February 15, 2019 12:50 PM
> To: Ben Peart
> Cc: Ramsay Jones ; git@vger.kernel.org;
> Ben Peart ; Kevin Willford
> ; sand...@crustytoothpaste.net
> Subject: Re: [PATCH
From: Ben Peart
Add a post-index-change hook that is invoked after the index is written in
do_write_locked_index().
This hook is meant primarily for notification, and cannot affect
the outcome of git commands that trigger the index write.
The hook is passed a flag to indicate whether the
On 2/14/2019 3:33 PM, Junio C Hamano wrote:
Ramsay Jones writes:
On 14/02/2019 14:42, Ben Peart wrote:
From: Ben Peart
Add a post-indexchanged hook that is invoked after the index is written in
s/post-indexchanged/post-index-changed/
Good. I wasn't paying close attention t
From: Ben Peart
Add a post-indexchanged hook that is invoked after the index is written in
do_write_locked_index().
This hook is meant primarily for notification, and cannot affect
the outcome of git commands that trigger the index write.
The hook is passed a flag to indicate whether the
On 2/8/2019 6:53 PM, brian m. carlson wrote:
On Fri, Feb 08, 2019 at 02:51:13PM -0500, Ben Peart wrote:
From: Ben Peart
Add a post-indexchanged hook that is invoked after the index is written in
do_write_locked_index().
This hook is meant primarily for notification, and cannot affect
the
From: Ben Peart
Test the new post-indexchanged hook and ensure it is triggered and passes
the correct flags for various git commands.
Signed-off-by: Ben Peart
---
t/t7113-post-index-changed-hook.sh | 144 +
1 file changed, 144 insertions(+)
create mode 100755 t
From: Ben Peart
Add a post-indexchanged hook that is invoked after the index is written in
do_write_locked_index().
This hook is meant primarily for notification, and cannot affect
the outcome of git commands that trigger the index write.
VFSForGit uses this hook to be notified when a git
From: Ben Peart
Add a post-indexchanged hook that is invoked after the index is written in
do_write_locked_index().
This hook is meant primarily for notification, and cannot affect
the outcome of git commands that trigger the index write.
Signed-off-by: Ben Peart
---
builtin/reset.c
From: Kevin Willford
Document the new post-indexchanged hook with information on when it is
called as well as the flags passed and what each of them mean.
Signed-off-by: Kevin Willford
Signed-off-by: Ben Peart
---
Documentation/githooks.txt | 18 ++
1 file changed, 18
Ping. Any thoughts, comments, feedback, suggestions?
On 12/13/2018 2:41 PM, Ben Peart wrote:
From: Ben Peart
To make git perform well on the very largest repos, we must make git
operations O(modified) instead of O(size of repo). This takes advantage of
the fact that the number of files a
From: Ben Woosley
To avoid partial deletion / zombie rebases.
Example behavior under partial deletion, after
Ctrl-Cing out of a standard rebase:
$ git rebase target
First, rewinding head to replay your work on top of it...
Applying: [...]
^C
$ git status
rebase in
From: Ben Woosley
To avoid partial deletion / zombie rebases.
Example behavior under partial deletion, after
Ctrl-Cing out of a standard rebase:
$ git rebase target
First, rewinding head to replay your work on top of it...
Applying: [...]
^C
$ git status
rebase in
From: Ben Peart
Commit fa655d8411 (checkout: optimize "git checkout -b ",
2018-08-16) introduced an unintentional change in behavior for 'checkout -b'
after doing 'clone --no-checkout'. Add a test to demonstrate the changed
behavior to be used in a later patch to
From: Ben Peart
Minor update to comment from V2. Also wrapped commit messages to be <80
chars wide.
Base Ref: master
Web-Diff: https://github.com/benpeart/git/commit/fef76edbdc
Checkout: git fetch https://github.com/benpeart/git initial-checkout-v3 && git
checkout fef76edbdc
##
From: Ben Peart
When doing a 'checkout -b' do a full checkout including updating the working
tree when doing the initial checkout. As the new test involves an filesystem
access, do it later in the sequence to give chance to other cheaper tests to
leave early. This fixes the reg
On 1/22/2019 1:54 PM, Junio C Hamano wrote:
Ben Peart writes:
diff --git a/builtin/checkout.c b/builtin/checkout.c
index af6b5c8336..9c6e94319e 100644
--- a/builtin/checkout.c
+++ b/builtin/checkout.c
@@ -517,12 +517,6 @@ static int skip_merge_working_tree(const struct
checkout_opts *opts
From: Ben Peart
When doing a 'checkout -b' do a full checkout including updating the working
tree when doing the initial checkout. This fixes the regression in behavior
caused by fa655d8411 (checkout: optimize "git checkout -b ",
2018-08-16)
Signed-off-by: Ben Peart
---
From: Ben Peart
The optimized `checkout -b` doesn�t typically create/update the index and
working directory. Add a new test to detect the case when the call to
`checkout -b` is the first call after doing a `clone --no-checkout` and no
index exists. In this specific case, well now make the call
From: Ben Peart
Commit fa655d8411 (checkout: optimize "git checkout -b ",
2018-08-16)
introduced an unintentional change in behavior for 'checkout -b' after doing
'clone --no-checkout'. Add a test to demonstrate the changed behavior to be
used in a later patch to
From: Ben Peart
When doing a 'checkout -b' do a full checkout including updating the working
tree when doing the initial checkout. This fixes the regression in behavior
caused by fa655d8411 checkout: optimize "git checkout -b "
Signed-off-by: Ben Peart
---
builtin/ch
From: Ben Peart
Anthony Sottile determined that commit fa655d8411
"checkout: optimize "git checkout -b " introduced
an unintentional change in behavior for 'checkout -b' after doing a
'clone --no-checkout'. Create a test to demonstrate the regression then
From: Ben Peart
Commit fa655d8411 checkout: optimize "git checkout -b " introduced
an unintentional change in behavior for 'checkout -b' after doing a
'clone --no-checkout'. Add a test to demonstrate the changed behavior to be
used in a later patch to verify the
On 1/3/2019 5:05 PM, Anthony Sottile wrote:
On Thu, Jan 3, 2019 at 1:51 PM Junio C Hamano wrote:
Anthony Sottile writes:
On Thu, Jan 3, 2019 at 12:26 PM Junio C Hamano wrote:
A "fix" to Ben's optimization for this particular case should be
fairly straight-forward. I think we have a sp
From: Ben Peart
To make git perform well on the very largest repos, we must make git
operations O(modified) instead of O(size of repo). This takes advantage of
the fact that the number of files a developer has modified (especially
in very large repos) is typically a tiny fraction of the overall
On 11/28/2018 8:31 AM, SZEDER Gábor wrote:
On Tue, Nov 27, 2018 at 02:50:57PM -0500, Ben Peart wrote:
diff --git a/t/t1092-virtualworkdir.sh b/t/t1092-virtualworkdir.sh
new file mode 100755
index 00..0cdfe9b362
--- /dev/null
+++ b/t/t1092-virtualworkdir.sh
@@ -0,0 +1,393 @@
+#!/bin
On 11/28/2018 4:37 AM, Johannes Schindelin wrote:
Hi Ben,
On Tue, 27 Nov 2018, Ben Peart wrote:
From: Ben Peart
Add tracing around initializing and discarding mempools. In discard report
on the amount of memory unused in the current block to help tune setting
the initial_size.
Signed-off
From: Ben Peart
Add tracing around initializing and discarding mempools. In discard report
on the amount of memory unused in the current block to help tune setting
the initial_size.
Signed-off-by: Ben Peart
---
Notes:
Base Ref: * git-trace-mempool
Web-Diff: https://github.com/benpeart
From: Ben Peart
To make git perform well on the very largest repos, we must make git
operations O(modified) instead of O(size of repo). This takes advantage of
the fact that the number of files a developer has modified (especially
in very large repos) is typically a tiny fraction of the overall
On 11/26/2018 2:59 PM, Stefan Beller wrote:
+static int record_ieot(void)
+{
+ int val;
+
Initialize stack val to zero to ensure proper default.
I don't think that is needed here, as we only use `val` when
we first write to it via git_config_get_bool.
Did you spot this via code review
-by: Jonathan Nieder
---
Rebased. No other change from v1.
As Jonathan pointed out, it would be nice to have tests here. Ben,
any advice for how I could write some in a followup change? E.g. does
Derrick Stolee's tracing based testing trick apply here?
I suppose a 'test-dump-eoie'
On 11/20/2018 4:26 AM, Ævar Arnfjörð Bjarmason wrote:
On Tue, Nov 20 2018, Jonathan Nieder wrote:
Just commenting here on the end-state of this since it's easier than
each patch at a time:
First, do we still need to be doing %.4s instead of just %s? It would be
easier for translators / to u
On 11/20/2018 1:14 AM, Jonathan Nieder wrote:
If a user explicitly sets
[index]
threads = true
to read the index using multiple threads, ensure that index writes
include the offset table by default to make that possible. This
ensures that the user's intent of turning
On 11/20/2018 1:12 AM, Jonathan Nieder wrote:
As with EOIE, popular versions of Git do not support the new IEOT
extension yet. When accessing a Git repository written by a more
modern version of Git, they correctly ignore the unrecognized section,
but in the process they loudly warn
-by: Jonathan Nieder
---
Rebased. No other change from v1.
As Jonathan pointed out, it would be nice to have tests here. Ben,
any advice for how I could write some in a followup change? E.g. does
Derrick Stolee's tracing based testing trick apply here?
Documentation/config/index.txt |
wrote:
There are a lot of lines introduced by the IEOT extension in these commits:
> Ben Peart 3255089ad: ieot: add Index Entry Offset Table (IEOT)
extension
> Ben Peart 3b1d9e045: eoie: add End of Index Entry (EOIE) extension
> Ben Peart 77ff1127a: read-cache: load cach
On 11/13/2018 10:24 PM, Junio C Hamano wrote:
Jonathan Nieder writes:
We cannot change the past, but for index extensions of the future,
there is a straightforward improvement: silence that message except
when tracing. This way, the message is still available when
debugging, but in everyda
On 11/13/2018 4:08 PM, Jonathan Nieder wrote:
Hi again,
Ben Peart wrote:
On 11/13/2018 1:18 PM, Jonathan Nieder wrote:
Ben Peart wrote:
Why introduce a new setting to disable writing the IEOT extension instead of
just using the existing index.threads setting? If index.threads=1 then
On 11/13/2018 1:18 PM, Jonathan Nieder wrote:
Hi,
Ben Peart wrote:
On 11/12/2018 7:39 PM, Jonathan Nieder wrote:
As with EOIE, popular versions of Git do not support the new IEOT
extension yet. When accessing a Git repository written by a more
modern version of Git, they correctly
On 11/12/2018 7:40 PM, Jonathan Nieder wrote:
Documentation/technical/index-format explains:
4-byte extension signature. If the first byte is 'A'..'Z' the
extension is optional and can be ignored.
This allows gracefully introducing a new index extension without
having to rely on
On 11/12/2018 7:39 PM, Jonathan Nieder wrote:
As with EOIE, popular versions of Git do not support the new IEOT
extension yet. When accessing a Git repository written by a more
modern version of Git, they correctly ignore the unrecognized section,
but in the process they loudly warn
On 11/12/2018 8:05 PM, Junio C Hamano wrote:
Jonathan Nieder writes:
Since 3b1d9e04 (eoie: add End of Index Entry (EOIE) extension,
2018-10-10) Git defaults to writing the new EOIE section when writing
out an index file. Usually that is a good thing because it improves
threaded performance
On 11/4/2018 4:01 PM, brian m. carlson wrote:
On Sun, Nov 04, 2018 at 07:34:01AM +0100, Duy Nguyen wrote:
On Wed, Oct 31, 2018 at 9:53 PM Ben Peart wrote:
It's more than a dynamic sparse-checkout because the same list is also
used to exclude any file/folder not listed. That means any
On 11/5/2018 10:22 AM, Duy Nguyen wrote:
On Sun, Nov 4, 2018 at 10:01 PM brian m. carlson
wrote:
On Sun, Nov 04, 2018 at 07:34:01AM +0100, Duy Nguyen wrote:
On Wed, Oct 31, 2018 at 9:53 PM Ben Peart wrote:
It's more than a dynamic sparse-checkout because the same list is also
us
On 11/5/2018 10:26 AM, Duy Nguyen wrote:
On Mon, Nov 5, 2018 at 12:40 PM Ævar Arnfjörð Bjarmason
wrote:
On Sun, Nov 04 2018, Duy Nguyen wrote:
On Wed, Oct 31, 2018 at 9:53 PM Ben Peart wrote:
+core.virtualFilesystem::
+ If set, the value of this variable is used as a command
On 11/4/2018 7:02 PM, Junio C Hamano wrote:
Ben Peart writes:
+ if (*dtype == DT_UNKNOWN)
+ *dtype = get_dtype(NULL, istate, pathname, pathlen);
We try to defer paying cost to determine unknown *dtype as late as
possible by having this call in
From: Ben Peart
With refresh_index() learning to utilize preload_index() to speed up its
operation there is no longer any benefit to having the caller preload the
index first. Remove those unneeded calls by calling read_index() instead of
the preload variant.
There is no measurable performance
On 11/2/2018 11:23 AM, Junio C Hamano wrote:
Ben Peart writes:
From: Ben Peart
During an "add", a call is made to run_diff_files() which calls
check_remove() for each index-entry. The preload_index() code
distributes some of the costs across multiple threads.
Nice. I pee
From: Ben Peart
During an "add", a call is made to run_diff_files() which calls
check_remove() for each index-entry. The preload_index() code distributes
some of the costs across multiple threads.
Because the files checked are restricted to pathspec, adding individual
files makes no
On 10/31/2018 3:11 PM, Duy Nguyen wrote:
not really a review, just a couple quick notes..
Perfect! As an RFC, I'm more looking for high level thoughts/notes than
a style/syntax code review.
On Tue, Oct 30, 2018 at 9:40 PM Ben Peart wrote:
From: Ben Peart
On index load, clea
On 10/30/2018 7:07 PM, Junio C Hamano wrote:
Ben Peart writes:
diff --git a/config.c b/config.c
index 4051e38823..96e05ee0f1 100644
--- a/config.c
+++ b/config.c
...
@@ -2307,6 +2311,37 @@ int git_config_get_index_threads(void)
return 0; /* auto */
}
+int
From: Ben Peart
On index load, clear/set the skip worktree bits based on the virtual
file system data. Use virtual file system data to update skip-worktree
bit in unpack-trees. Use virtual file system data to exclude files and
folders not explicitly requested.
Signed-off-by: Ben Peart
---
We
From: Ben Peart
Speed up refresh_index() by utilizing preload_index() to do most of the work
spread across multiple threads. This works because most cache entries will
get marked CE_UPTODATE so that refresh_cache_ent() can bail out early when
called from within refresh_index().
On a Windows
On 10/29/2018 1:26 PM, Duy Nguyen wrote:
On Mon, Oct 29, 2018 at 6:21 PM Ben Peart wrote:
@@ -114,6 +104,9 @@ static void preload_index(struct index_state *index,
threads = index->cache_nr / THREAD_COST;
if ((index->cache_nr > 1) && (threads <
On 10/29/2018 1:21 PM, Duy Nguyen wrote:
On Mon, Oct 29, 2018 at 6:05 PM Ben Peart wrote:
@@ -2756,8 +2745,11 @@ static int do_write_index(struct index_state *istate,
struct tempfile *tempfile,
if (ce_write(&c, newfd, &hdr, sizeof(hdr)) < 0)
return -1
On 10/29/2018 10:30 AM, Jeff King wrote:
On Sat, Oct 27, 2018 at 07:30:06PM +0200, Nguyễn Thái Ngọc Duy wrote:
-#ifndef NO_PTHREADS
- nr_threads = git_config_get_index_threads();
+ if (HAVE_THREADS) {
+ nr_threads = git_config_get_index_threads();
- /* TODO: does
On 10/27/2018 1:30 PM, Nguyễn Thái Ngọc Duy wrote:
Signed-off-by: Nguyễn Thái Ngọc Duy
---
preload-index.c | 15 ++-
1 file changed, 2 insertions(+), 13 deletions(-)
diff --git a/preload-index.c b/preload-index.c
index 9e7152ab14..0e24886aca 100644
--- a/preload-index.c
+++ b/
On 10/29/2018 10:30 AM, Jeff King wrote:
On Sat, Oct 27, 2018 at 07:30:06PM +0200, Nguyễn Thái Ngọc Duy wrote:
-#ifndef NO_PTHREADS
- nr_threads = git_config_get_index_threads();
+ if (HAVE_THREADS) {
+ nr_threads = git_config_get_index_threads();
- /* TODO: does
On 10/27/2018 3:10 AM, Nguyễn Thái Ngọc Duy wrote:
Signed-off-by: Nguyễn Thái Ngọc Duy
---
read-cache.c | 49 ++---
1 file changed, 18 insertions(+), 31 deletions(-)
diff --git a/read-cache.c b/read-cache.c
index d57958233e..ba870bc3fd 100644
--
On 10/27/2018 3:10 AM, Nguyễn Thái Ngọc Duy wrote:
Signed-off-by: Nguyễn Thái Ngọc Duy
---
preload-index.c | 15 ++-
1 file changed, 2 insertions(+), 13 deletions(-)
diff --git a/preload-index.c b/preload-index.c
index 9e7152ab14..0e24886aca 100644
--- a/preload-index.c
+++ b/
On 10/23/2018 4:28 PM, Jeff King wrote:
On Thu, Oct 18, 2018 at 08:05:22PM +0200, Nguyễn Thái Ngọc Duy wrote:
On Thu, Oct 18, 2018 at 7:09 PM Jeff King wrote:
In this particular case though I think we should be able to avoid so
much #if if we make a wrapper for pthread api that would retur
On 10/25/2018 5:26 AM, Junio C Hamano wrote:
Junio C Hamano writes:
To be honest, I find the second sentence in your rewrite even more
confusing. It reads as if `reset.quiet` configuration variable
can be used to restore the "show what is yet to be added"
behaviour, due to the parenthetica
diff Peff sent enough or do you want me to send another iteration
on the patch?
Thanks,
Ben
diff --git a/read-cache.c b/read-cache.c
index 78c9516eb7..4b44a2eae5 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -2052,12 +2052,11 @@ static void *load_cache_entries_thread(void *_data)
From: Ben Peart
Updated the wording in the documentation and commit messages to (hopefully)
make it clearer. Added the warning about 'reset --quiet' to the advice
system so that it can be turned off.
Base Ref:
Web-Diff: https://github.com/benpeart/git/commit/8a2fef45d4
Checkout:
From: Ben Peart
When git reset is run with the --quiet flag, don't bother finding any
additional unstaged changes as they won't be output anyway. This speeds up
the git reset command by avoiding having to lstat() every file looking for
changes that aren't going to be report
From: Ben Peart
refresh_index() is done after a reset command as an optimization. Because
it can be an expensive call, warn the user if it takes more than 2 seconds
and tell them how to avoid it using the --quiet command line option or
reset.quiet config setting.
Signed-off-by: Ben Peart
1 - 100 of 878 matches
Mail list logo
