On Thu, Apr 13, 2017 at 04:34:16PM -0400, Jeffrey Manian wrote:
> Hello git community,
>
> This is about an issue of language style and punctuation, not anything
> functional. Apologies in advance if I've brought this to the wrong
> place.
>
> There are a bunch of situations in which git will pri
On Fri, Apr 14, 2017 at 3:33 PM, Ævar Arnfjörð Bjarmason
wrote:
> On Sat, Apr 15, 2017 at 12:08 AM, Carlos Pita
> wrote:
>> This is much faster (below 0.1s):
>>
>> __git_index_files ()
>> {
>> local dir="$(__gitdir)" root="${2-.}" file;
>> if [ -d "$dir" ]; then
>> __git_ls_files
On Fri, Apr 14, 2017 at 10:02 AM, Stefan Beller wrote:
> On Fri, Apr 14, 2017 at 9:33 AM, Jacob Keller wrote:
>>
>> Never mind. git ls-files doesn't support showing files for a specific
>> ancient history. (I guess you'd use ls-tree for that?). I'm guessing
>> we want to run in the actual work-tr
This makes it easy to sign off a whole patchset before submission.
To make things work, we also fix a design issue in git-am that made it
ignore the signoff option during rebase (specifically, signoff was
handled in parse_mail(), but not in parse_mail_rebasing()).
This is trivially fixed by movin
On Sat, Apr 15, 2017 at 12:44 AM, Ævar Arnfjörð Bjarmason
wrote:
> On Fri, Apr 14, 2017 at 6:50 PM, Giuseppe Bilotta
> wrote:
>
> It should be --[no-]signoff, not --[no]-signoff, since the latter
> implies that ---signoff works, see my 2c7ee986c7 where I fixed some
> existing instances of this.
On Fri, Apr 14, 2017 at 6:50 PM, Giuseppe Bilotta
wrote:
It should be --[no-]signoff, not --[no]-signoff, since the latter
implies that ---signoff works, see my 2c7ee986c7 where I fixed some
existing instances of this.
On Sat, Apr 15, 2017 at 12:08 AM, Carlos Pita wrote:
> This is much faster (below 0.1s):
>
> __git_index_files ()
> {
> local dir="$(__gitdir)" root="${2-.}" file;
> if [ -d "$dir" ]; then
> __git_ls_files_helper "$root" "$1" | \
> sed -r 's@/.*@@' | uniq | sort | uniq
This is much faster (below 0.1s):
__git_index_files ()
{
local dir="$(__gitdir)" root="${2-.}" file;
if [ -d "$dir" ]; then
__git_ls_files_helper "$root" "$1" | \
sed -r 's@/.*@@' | uniq | sort | uniq
fi
}
time __git_index_files
real0m0.075s
user0m0.083s
s
Brandon Williams wrote:
> On 04/14, Brandon Williams wrote:
> > /*
> > +* restore default signal handlers here, in case
> > +* we catch a signal right before execve below
> > +*/
> > + for (sig = 1; sig < NSIG; sig++) {
> > +
As far as I can tell the only way to clone a given upstream repo,
which has an unknown main branch name without any tags is:
git clone --single-branch &&
cd &&
git tag -d $(git tag -l) &&
git config remote.origin.tagOpt --no-tags
Is there really nothing like:
git clone --s
On Tue, Apr 11, 2017 at 11:22:17PM +0300, Sergey Ryazanov wrote:
> this is few patches, which fixes regressions in the proxy handling.
>
> Both patches are based on the maint branch.
>
> Changes since v3:
> - fix grammar (thanks to Jeff)
>
> Changes since v2:
> - fix grammar (thanks to Ævar)
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
> > proposing, and then leave "0" as "auto-detect". There would be no way
On 4/14/2017 3:52 PM, Jeff King wrote:
On Fri, Apr 14, 2017 at 07:25:54PM +, g...@jeffhostetler.com wrote:
for (i = 0; i < n; i++, dirmask >>= 1) {
- const unsigned char *sha1 = NULL;
- if (dirmask & 1)
- sha1 = names[i].oid->hash;
From: Jeff Hostetler
Teach git to skip verification of the SHA1-1 checksum at the end of
the index file in verify_hdr() which is called from read_index()
unless the "force_verify_index_checksum" global variable is set.
Teach fsck to force this verification.
The checksum verification is for dete
From: Jeff Hostetler
Version 7 of this patch cleans up the fsck test using
test_when_finished and eliminates unnecessary mv/rm's.
Jeff Hostetler (1):
read-cache: force_verify_index_checksum
builtin/fsck.c | 1 +
cache.h | 2 ++
read-cache.c| 7 +++
t/t1450-fsck.sh | 13 ++
On 04/14, Brandon Williams wrote:
> /*
> + * restore default signal handlers here, in case
> + * we catch a signal right before execve below
> + */
> + for (sig = 1; sig < NSIG; sig++) {
> + sighandler_t old = sign
On 04/14, Eric Wong wrote:
> Brandon Williams wrote:
> > +++ b/run-command.c
> > @@ -211,14 +211,82 @@ static const char **prepare_shell_cmd(struct
> > argv_array *out, const char **argv)
> > #ifndef GIT_WINDOWS_NATIVE
> > static int child_notifier = -1;
> >
> > -static void notify_parent(voi
On 04/14, Eric Wong wrote:
> Brandon Williams wrote:
> > + if (cmd->no_stdin || cmd->no_stdout || cmd->no_stderr) {
> > + null_fd = open("/dev/null", O_RDWR | O_CLOEXEC | O_NONBLOCK);
>
> O_NONBLOCK? This was in my original patch, too :x
> Wow, I wonder what I was smoking that day...
I think "harden" is the wrong word to use in the subject - to me,
"harden" implies that you're defending against an invalid use. But here,
not only is the use valid, but this patch also takes steps to support it.
On 04/11/2017 04:49 PM, Stefan Beller wrote:
Early on in submodule_move_head just
On Fri, Apr 14, 2017 at 11:28 AM, Jonathan Tan wrote:
>> @@ -282,12 +283,11 @@ int checkout_entry(struct cache_entry *ce,
>> unlink_or_warn(ce->name);
>>
>> return submodule_move_head(ce->name,
>> -
On Thu, Apr 13, 2017 at 09:35:08PM +0200, SZEDER Gábor wrote:
> >> diff --git a/t/test-lib.sh b/t/test-lib.sh
> >> index 13b569682..d7fa15a69 100644
> >> --- a/t/test-lib.sh
> >> +++ b/t/test-lib.sh
> >> @@ -763,7 +763,7 @@ test_done () {
> >>
> >> test -d "$remove_trash" &&
>
> I
Hi all,
I'm currently using git annex to manage my entire file collection
(including tons of music and books) and I noticed how slow
autocompletion has become for files in the index (say for git add).
The main offender is a while-read-case-echo bash loop in
__git_index_files that can be readily su
From: Jeff Hostetler
Version 5 addresses coding style comments from the mailing list
in the perf test and squashes the changes into 1 commit.
Jeff Hostetler (1):
string-list: use ALLOC_GROW macro when reallocing string_list
string-list.c | 5 +
t/perf/p0005-status.sh | 49 +
On Fri, Apr 14, 2017 at 07:25:54PM +, g...@jeffhostetler.com wrote:
> for (i = 0; i < n; i++, dirmask >>= 1) {
> - const unsigned char *sha1 = NULL;
> - if (dirmask & 1)
> - sha1 = names[i].oid->hash;
> - buf[i] = fill_tree_descript
From: Jeff Hostetler
Use ALLOC_GROW() macro when reallocing a string_list array
rather than simply increasing it by 32. This is a performance
optimization.
During status on a very large repo and there are many changes,
a significant percentage of the total run time is spent
reallocing the wt_st
Brandon Williams wrote:
> + if (cmd->no_stdin || cmd->no_stdout || cmd->no_stderr) {
> + null_fd = open("/dev/null", O_RDWR | O_CLOEXEC | O_NONBLOCK);
O_NONBLOCK? This was in my original patch, too :x
Wow, I wonder what I was smoking that day...
On Thu, Apr 13, 2017 at 04:27:12PM -0400, David Turner wrote:
> Git gc locks the repository (using a gc.pid file) so that other gcs
> don't run concurrently. Make git repack respect this lock.
>
> Now repack, by default, will refuse to run at the same time as a gc.
> This fixes a concurrency issu
On 4/13/2017 8:59 PM, Jeff King wrote:
On Thu, Apr 13, 2017 at 04:11:31PM -0700, Junio C Hamano wrote:
g...@jeffhostetler.com writes:
+ /*
+* Fetch the tree from the ODB for each peer directory in the
+* n commits.
+*
+* For 2- and 3-way traversals, we
From: Jeff Hostetler
Version 4 cleans up the buf[] allocation and freeing as
suggested on the mailing list.
Jeff Hostetler (1):
unpack-trees: avoid duplicate ODB lookups during checkout
unpack-trees.c | 38 +-
1 file changed, 33 insertions(+), 5 deletions(
From: Jeff Hostetler
Teach traverse_trees_recursive() to not do redundant ODB
lookups when both directories refer to the same OID.
In operations such as read-tree and checkout, there will
likely be many peer directories that have the same OID when
the differences between the commits are relative
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 result: '**/*' only matches files at least one directory deep.
The same happens with eg '**/Makefi
From: Jeff Hostetler
Teach add_index_entry_with_check() and has_dir_name()
to see if the path of the new item is greater than the
last path in the index array before attempting to search
for it.
During checkout, merge_working_tree() populates the new
index in sorted order, so this change will sa
From: Jeff Hostetler
Created t/perf/repos/many-files.sh to generate large, but
artificial repositories.
Created t/perf/p0006-read-tree-checkout.sh to measure
performance on various read-tree, checkout, and update-index
operations. This test can run using either artificial repos
described above
From: Jeff Hostetler
Add strcmp_offset() function to also return the offset of the
first change.
Add unit test and helper to verify.
Signed-off-by: Jeff Hostetler
---
Makefile | 1 +
cache.h | 1 +
read-cache.c | 20 +++
From: Jeff Hostetler
Version 10 addresses mailing list comments on coding style in
read-cache.c and in p0006. I've also adjusted the speed-up
algorithm and more thoroughly documented the cases in the code.
We skip the binary searches whenever we can prove that the new
entry (and every sub-direc
Brandon Williams wrote:
> +++ b/run-command.c
> @@ -211,14 +211,82 @@ static const char **prepare_shell_cmd(struct argv_array
> *out, const char **argv)
> #ifndef GIT_WINDOWS_NATIVE
> static int child_notifier = -1;
>
> -static void notify_parent(void)
> +enum child_errcode {
> + CHILD_ER
On 04/11/2017 04:49 PM, Stefan Beller wrote:
In case of a non-forced worktree update, the submodule movement is tested
in a dry run first, such that it doesn't matter if the actual update is
done via the force flag. However for correctness, we want to give the
flag is specified by the user. All c
On Fri, Apr 14, 2017 at 07:04:23PM +0200, Bert Wesarg wrote:
> Dear Duy,
>
> heaving an includeIf in a git config file breaks calling external git
> commands, most prominently git-gui.
>
> $ git --version
> git version 2.12.2.599.gcf11a6797
> $ git rev-parse --is-inside-work-tree
> true
> $ git
Dear Duy,
heaving an includeIf in a git config file breaks calling external git
commands, most prominently git-gui.
$ git --version
git version 2.12.2.599.gcf11a6797
$ git rev-parse --is-inside-work-tree
true
$ git echo
git: 'echo' is not a git command. See 'git --help'.
Did you mean this?
f
On Fri, Apr 14, 2017 at 9:33 AM, Jacob Keller wrote:
>
> Never mind. git ls-files doesn't support showing files for a specific
> ancient history. (I guess you'd use ls-tree for that?). I'm guessing
> we want to run in the actual work-tree for ls-files here.
>
> Does "is_submodule_initialized()" go
Convert the function used to exec from 'execvp()' to 'execv()' as the (p)
variant of exec isn't async-signal-safe and has the potential to call malloc
during the path resolution it performs. Instead we simply do the path
resolution ourselves during the preparation stage prior to forking. There al
In order to avoid allocation between 'fork()' and 'exec()' prepare the
environment to be used in the child process prior to forking.
Switch to using 'execve()' so that the construct child environment can
used in the exec'd process.
Signed-off-by: Brandon Williams
---
run-command.c | 86
All non-Async-Signal-Safe functions (e.g. malloc and die) were removed
between 'fork' and 'exec' in start_command in order to avoid potential
deadlocking when forking while multiple threads are running. This
deadlocking is possible when a thread (other than the one forking) has
acquired a lock and
The post-update hooks created in t5550-http-fetch-dumb.sh is missing the
"!#/bin/sh" line which can cause issues with portability. Instead
create the hook using the 'write_script' function which includes the
proper "#!" line.
Signed-off-by: Brandon Williams
---
t/t5550-http-fetch-dumb.sh | 5 ++
Add a test to 't0061-run-command.sh' to ensure that run_command can
continue to execute scripts which don't include a '#!' line.
Signed-off-by: Brandon Williams
---
t/t0061-run-command.sh | 11 +++
1 file changed, 11 insertions(+)
diff --git a/t/t0061-run-command.sh b/t/t0061-run-comman
From: Eric Wong
Signal handlers of the parent firing in the forked child may
have unintended side effects. Rather than auditing every signal
handler we have and will ever have, block signals while forking
and restore default signal handlers in the child before execve.
Restoring default signal h
Signed-off-by: Brandon Williams
---
run-command.c | 28 +---
1 file changed, 13 insertions(+), 15 deletions(-)
diff --git a/run-command.c b/run-command.c
index 5864b5ff3..ee2c680ab 100644
--- a/run-command.c
+++ b/run-command.c
@@ -117,18 +117,6 @@ static inline void clos
Changes in v3:
* More error handling for dup2/close calls in the child
* Added a test in t0061 to test for regressions in run_command's
ability to interpret scripts without a "#!" line
* In the event execve fails with ENOEXEC, attempt to exec one more
time by invoking the shell to interpre
According to [1] we need to only call async-signal-safe operations between fork
and exec. Using malloc to build the argv array isn't async-signal-safe.
In order to avoid allocation between 'fork()' and 'exec()' prepare the
argv array used in the exec call prior to forking the process.
[1] http:/
Signed-off-by: Brandon Williams
---
run-command.c | 58 ++
1 file changed, 42 insertions(+), 16 deletions(-)
diff --git a/run-command.c b/run-command.c
index 25b487c35..f36eafa8d 100644
--- a/run-command.c
+++ b/run-command.c
@@ -213,6 +213
All of our standard error handling paths have the potential to
call malloc or take stdio locks; so we must avoid them inside
the forked child.
Instead, the child only writes an 8 byte struct atomically to
the parent through the notification pipe to propagate an error.
All user-visible error report
This makes it easy to sign off a whole patchset before submission.
To make things work, we also fix a design issue in git-am that made it
ignore the signoff option during rebase (specifically, signoff was
handled in parse_mail(), but not in parse_mail_rebasing()).
This is trivially fixed by movin
On Thu, Apr 13, 2017 at 12:25 PM, Stefan Beller wrote:
> On Thu, Apr 13, 2017 at 12:12 PM, Jacob Keller wrote:
>> On Thu, Apr 13, 2017 at 12:05 PM, Stefan Beller wrote:
>>> On Thu, Apr 13, 2017 at 11:57 AM, Brandon Williams
>>> wrote:
Add in a check to see if a submodule is active before
- a bit late in providing a comment..
From: "Michael J Gruber"
Ævar Arnfjörð Bjarmason venit, vidit, dixit 12.04.2017 14:18:
On Wed, Apr 12, 2017 at 7:43 AM, Michael J Gruber wrote:
Am 11. April 2017 22:40:14 MESZ schrieb "Ævar Arnfjörð Bjarmason"
:
On Tue, Apr 11, 2017 at 5:13 PM, Enis Bay
On Thu, Apr 13, 2017 at 3:50 PM, Junio C Hamano wrote:
> Nguyễn Thái Ngọc Duy writes:
>
>> As explained in the document. This option has an advantage over the
>> command sequence "git worktree add && git worktree lock": there will be
>> no gap that somebody can accidentally "prune" the new workt
On 4/11/2017 11:12 PM, Junio C Hamano wrote:
g...@jeffhostetler.com writes:
From: Jeff Hostetler
Teach add_index_entry_with_check() and has_dir_name()
to see if the path of the new item is greater than the
last path in the index array before attempting to search
for it.
During checkout, me
On Fri, Apr 14, 2017 at 03:44:46AM -0700, Junio C Hamano wrote:
> Duy Nguyen writes:
>
> > I'll mark this mail and do a follow-up patch once this topic graduates
> > to master. It's less review burden and mail traffic.
>
> I actually do not mind a single replacement patch.
Thanks. Here's the fi
On Fri, Apr 14, 2017 at 5:50 AM, Junio C Hamano wrote:
> Nguyễn Thái Ngọc Duy writes:
>
>> As explained in the document. This option has an advantage over the
>> command sequence "git worktree add && git worktree lock": there will be
>> no gap that somebody can accidentally "prune" the new workt
On Thu, Apr 13, 2017 at 07:02:22PM -0700, Junio C Hamano wrote:
> Oops, I shouldn't have done that. When applied on top of the
> files-backend thing (or have you updated that one and is my tree
> lacking it???), this breaks quite a few tests.
>
> t0001#41 dumps core from "git worktree add ../link
Jeff King writes:
> I think I'm leaning towards the very first patch I posted, that assumes
> 7.11.0 and later. And then hold off on the others for a few years. In
> terms of "number of ifdefs removed" we could go further, but I think it
> was the first patch that removes a lot of the really ques
Duy Nguyen writes:
> I'll mark this mail and do a follow-up patch once this topic graduates
> to master. It's less review burden and mail traffic.
I actually do not mind a single replacement patch.
61 matches
Mail list logo
