Hi everyone,
I am starting to investigate ways to speed up git status and other git
commands for Booking.com (thanks to AEvar) and I'd be happy to discuss
the current status or be pointed to relevant documentation or mailing
list threads.
>From the threads below ([0], [1], [2], [3], [4], [5], [6]
Max Kirillov writes:
> Do not die immediately when the two flags are specified. Instead
> check that the specified range is along first-parent chain. Exploit
> how prepare_revision_walk() handles first_parent_only flag: the commits
> outside of first-parent chain are either unknown (and do not ha
Max Kirillov writes:
> If history contains merges from feature branches, `blame --reverse`
> reports not the commit when the line was actually edited, but head of
> the last merged branch which was created before the edit.
>
> As a workaround, `blame --reverse --first-parent` could be used to fin
Do not die immediately when the two flags are specified. Instead
check that the specified range is along first-parent chain. Exploit
how prepare_revision_walk() handles first_parent_only flag: the commits
outside of first-parent chain are either unknown (and do not have any
children recorded) or ap
Fix indentation.
Max Kirillov (2):
Add test to describe expectation of blame --reverse with branched
history
blame: allow blame --reverse --first-parent when it makes sense
builtin/blame.c | 11 +--
t/t8009-blame-reverse.sh | 39 +++
2
If history contains merges from feature branches, `blame --reverse`
reports not the commit when the line was actually edited, but head of
the last merged branch which was created before the edit.
As a workaround, `blame --reverse --first-parent` could be used to find
the merge of branch containing
On Wed, Oct 21, 2015 at 12:29:12AM -0400, Eric Sunshine wrote:
> On Wed, Oct 21, 2015 at 12:08 AM, Max Kirillov wrote:
>> Do not die immediately when the two flags are specified. Instead
>> check that the specified range is along first-parent chain. Explioit
>
> s/Explioit/Exploit/
Fixed. Thank
Fixed mistype in commit message.
Max Kirillov (2):
Add test to describe expectation of blame --reverse with branched
history
blame: allow blame --reverse --first-parent when it makes sense
builtin/blame.c | 11 +--
t/t8009-blame-reverse.sh | 39 ++
Do not die immediately when the two flags are specified. Instead
check that the specified range is along first-parent chain. Exploit
how prepare_revision_walk() handles first_parent_only flag: the commits
outside of first-parent chain are either unknown (and do not have any
children recorded) or ap
If history contains merges from feature branches, `blame --reverse`
reports not the commit when the line was actually edited, but head of
the last merged branch which was created before the edit.
As a workaround, `blame --reverse --first-parent` could be used to find
the merge of branch containing
Dear git,
I am honored to introduce Asian Language Solutions to you as a representative
of ALS.
Asian Langauge Solutions focuses on providing Asian language solutions to all
of you around the world.
From translation to interpretation, we are experts in every section we are
involved in.
Our are
The change in the endgame since v3 ($gmane/279832) is almost none
(interdiff attached at the end), so I won't be sending the patches
themselves. The bulk out of the miniscule interdiff comes from the
fifth "plug strbuf leak" patch.
The patches have been reordered to make the structure of the seri
Looks good to me, Ack.
Test run with 74301d6 + my TravisCI patch:
https://travis-ci.org/larsxschneider/git/builds/86702932
... on Linux it failed in 1/2 cases after 53min
... on OSX it failed in 2/2 cases after 6min
Test run with 74301d6 + my TravisCI patch + David's t7063 patch:
https://travis-c
On Wed, Oct 21, 2015 at 2:23 PM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> I'd like to counter your argument with quoting code from update_clone
>> method:
>>
>> run_processes_parallel(1, get_next_task, start_failure,
>> task_finished, &pp);
>>
>> if (pp.print_unmatched) {
>>
Dear All,
I am trying to install GIT on web.
Running "git instaweb" gives me this?
$ git instaweb --httpd=lighttpd
Instance already running. Restarting...
No known browser available.
http://127.0.0.1:1234
Any idea? What I need to do on my GIT server?
Thanks
-Gaurav
--
View this message in
Stefan Beller writes:
> I'd like to counter your argument with quoting code from update_clone
> method:
>
> run_processes_parallel(1, get_next_task, start_failure,
> task_finished, &pp);
>
> if (pp.print_unmatched) {
> printf("#unmatched\n");
> return 1;
> }
>
>
On Wed, Oct 21, 2015 at 2:04 PM, Junio C Hamano wrote:
>
> Looking at their final resting place, I do not think so.
Right, I comment along the way without looking ahead, so this was a bad comment.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord
On Wed, Oct 21, 2015 at 1:30 PM, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> And of course we already have these array-clear calls in
>> finish_command().
>>
>> So I agree that deinit helper should exist, but
>>
>> * it should be file-scope static;
>>
>> * it should be called by finish_
On Wed, Oct 21, 2015 at 1:47 PM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> This introduces a new helper function in git submodule--helper
>> which takes care of cloning all submodules, which we want to
>> parallelize eventually.
>>
>> Some tests (such as empty URL, update_mode==none) are
Stefan Beller writes:
> On Mon, Oct 19, 2015 at 12:28 AM, Junio C Hamano wrote:
>> Signed-off-by: Junio C Hamano
>> ---
>> builtin/mailinfo.c | 45 ++---
>> 1 file changed, 26 insertions(+), 19 deletions(-)
>>
>> diff --git a/builtin/mailinfo.c b/builtin
Stefan Beller writes:
> On Mon, Oct 19, 2015 at 12:28 AM, Junio C Hamano wrote:
>> Signed-off-by: Junio C Hamano
>> ---
>> builtin/mailinfo.c | 23 +--
>> 1 file changed, 13 insertions(+), 10 deletions(-)
>>
>> diff --git a/builtin/mailinfo.c b/builtin/mailinfo.c
>> index c
Stefan Beller writes:
> This introduces a new helper function in git submodule--helper
> which takes care of cloning all submodules, which we want to
> parallelize eventually.
>
> Some tests (such as empty URL, update_mode==none) are required in the
> helper to make the decision for cloning. Thes
Hi,
Hope this email finds you well!
Would you be interested in reaching out to "Condominium Owners List” for across
USA with opt-in verified contact information?
We also have the list of Home Owners, Pool Owners, Homes with Swimming Pool,
Time-share Owners, Spa & Resort Visitors, HNI List an
On Mon, Oct 19, 2015 at 12:28 AM, Junio C Hamano wrote:
> Signed-off-by: Junio C Hamano
> ---
> builtin/mailinfo.c | 45 ++---
> 1 file changed, 26 insertions(+), 19 deletions(-)
>
> diff --git a/builtin/mailinfo.c b/builtin/mailinfo.c
> index 2c194da..ec6
On Mon, Oct 19, 2015 at 12:28 AM, Junio C Hamano wrote:
> @@ -733,7 +733,7 @@ static int handle_commit_msg(struct mailinfo *mi, struct
> strbuf *line)
> }
>
> if (mi->use_inbody_headers && mi->header_stage) {
> - mi->header_stage = check_header(mi, line, s_hdr_data,
Junio C Hamano writes:
> And of course we already have these array-clear calls in
> finish_command().
>
> So I agree that deinit helper should exist, but
>
> * it should be file-scope static;
>
> * it should be called by finish_command(); and
>
> * if you are calling it from collect_finished()
On Mon, Oct 19, 2015 at 9:48 PM, David Turner wrote:
> Dirty the test worktree's root directory, as the test expects.
>
> When testing the untracked-cache, we previously assumed that checking
> out master would be sufficient to mark the mtime of the worktree's
> root directory as racily-dirty. Bu
On Mon, Oct 19, 2015 at 12:28 AM, Junio C Hamano wrote:
> Signed-off-by: Junio C Hamano
> ---
> builtin/mailinfo.c | 23 +--
> 1 file changed, 13 insertions(+), 10 deletions(-)
>
> diff --git a/builtin/mailinfo.c b/builtin/mailinfo.c
> index c0522f2..2c8f249 100644
> --- a/bu
On Mon, Oct 19, 2015 at 12:28 AM, Junio C Hamano wrote:
> @@ -28,6 +31,7 @@ static enum {
>
> static struct strbuf charset = STRBUF_INIT;
> static int patch_lines;
> +
nitpicking here. Why is this patch the best in series to introduce a
new line at this position? ;)
> static struct strbuf *
Johannes Sixt writes:
> Am 21.10.2015 um 17:51 schrieb Ramsay Jones:
>> On 20/10/15 22:24, Junio C Hamano wrote:
>>>
>>> time git am mbox >/dev/null
>>>
>>> are
>>>
>>>(master) (with the series)
>>> real0m0.648sreal0m0.537s
>>> user0m
Am 21.10.2015 um 17:51 schrieb Ramsay Jones:
On 20/10/15 22:24, Junio C Hamano wrote:
Junio C Hamano writes:
some numbers on my desktop (Dell T3500 2.66GHz Xeon X5650 with 12GB,
running Ubuntu),
I suspect that I haven't tested exactly the same version as you, but I had
a quick look at testing
Hi Etienne,
thanks for reporting this! Junio is right, I messed that up on my Windows
testing box! :-( Sorry!
If you have any questions around submitting patches I am happy to help as I
just recently went through the learning process myself!
@Dennis: Thanks for the quick patch!
Thanks,
Lars
David Turner writes:
> From: Jeff King
I just made sure this is bit-for-bit identical with the first of the
two patches I received from Peff and I locally have kept.
Re-reading the two patches again, I do not see a reason why we should
reject them. I'll queue this and the other "precious obje
David Turner writes:
> In a moment, we'll create initdb functions for ref backends, and code
> from initdb that calls this function needs to move into the files
> backend. So this function needs to be public.
OK, but unlike the static function, being in public interface part
can invite mistakes
On 21/10/15 18:50, David Turner wrote:
> On Wed, 2015-10-21 at 18:05 +0200, Torsten Bögershausen wrote:
>> On 21.10.15 16:37, Ramsay Jones wrote:
>>> Hi Junio,
>>>
>>> While testing the next branch today, I had a test failure, viz:
>>>
>>> $ tail ntest-out-fail
>>> Test Summary Report
>>>
David Turner writes:
> Stop reusing cache_entry in dir_entry; doing so causes a
> use-after-free bug.
>
> During merges, we free entries that we no longer need in the
> destination index. But those entries might have also been stored in
> the dir_entry cache, and when a later call to add_to_inde
On Wed, 2015-10-21 at 12:38 -0700, Junio C Hamano wrote:
> David Turner writes:
>
> > In a moment, we'll create initdb functions for ref backends, and code
> > from initdb that calls this function needs to move into the files
> > backend. So this function needs to be public.
>
> OK, but unlike
Remi Pommarel wrote:
> Signed-off-by: Remi Pommarel
> Reviewed-by: Jonathan Nieder
Yep. ;)
Thanks.
--
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
Remi Pommarel wrote:
> Signed-off-by: Remi Pommarel
Reviewed-by: Jonathan Nieder
Thanks.
--
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 Thu, 2015-10-15 at 15:46 -0400, David Turner wrote:
> --- a/refs.c
> +++ b/refs.c
> @@ -117,3 +117,60 @@ int update_ref(const char *msg, const char *refname,
> ref_transaction_free(t);
> return 0;
> }
> +
> +
> +static int delete_pseudoref(const char *pseudoref, const unsign
On Thu, 2015-10-15 at 15:46 -0400, David Turner wrote:
> From: Ronnie Sahlberg
>
> Move update_ref() to the refs.c file since this function does not
> contain any backend specific code. Move the ref classifier functions
and write_pseudoref (will fix on reroll).
--
To unsubscribe from this list
From: Junio C Hamano [mailto:jch2...@gmail.com] On Behalf Of Junio C Hamano
[administrivia: please do not cull people out of the Cc: list]
Johan Laenen writes:
> Enrique Tobis twosigma.com> writes:
>
>> There is something I don't understand, though. Johan must be
>> configuring his proxy eith
[administrivia: please do not cull people out of the Cc: list]
Johan Laenen writes:
> Enrique Tobis twosigma.com> writes:
>
>> There is something I don't understand, though. Johan must be
>> configuring his proxy either a) through git config files; or b)
>> through environment variables. Johan
Daniel Steinborn writes:
> currently we are experiencing poor write performance when a repository
> is pushed to a nfs volume. Interestingly, this seems to be a problem
> in newer git versions:
>
> v1.7.12.4: Very good performance
>
> v2.1.4: Bad performance, up to 6 times slower
>
> Are there an
Stop reusing cache_entry in dir_entry; doing so causes a
use-after-free bug.
During merges, we free entries that we no longer need in the
destination index. But those entries might have also been stored in
the dir_entry cache, and when a later call to add_to_index found them,
they would be used a
Alexander Riesen writes:
> Reminder. Is this (or rather the one I'm replying to) patch a better option?
I suspect that the reason why you didn't get any quick response was
because it was unclear from either one of these proposed log
messages why any change is needed in the first place. At least
On Wed, 2015-10-21 at 18:05 +0200, Torsten Bögershausen wrote:
> On 21.10.15 16:37, Ramsay Jones wrote:
> > Hi Junio,
> >
> > While testing the next branch today, I had a test failure, viz:
> >
> > $ tail ntest-out-fail
> > Test Summary Report
> > ---
> > t7063-sta
There are situations, e.g. during cross compilation, where curl-config
program is not present in the PATH.
Make the makefile use a configurable curl-config program passed through
CURL_CONFIG variable which can be set through config.mak.
Also make this variable tunable through use of autoconf/conf
For static linking especially library order while linking is important. For
example, libcurl wants symbols from zlib when building http-push, http-fetch
and remote-curl. So for these programs libcurl has to be linked before zlib.
Signed-off-by: Remi Pommarel
---
Changes to v3:
- Initializ
Remi Pommarel writes:
> On Tue, Oct 20, 2015 at 01:20:18PM -0700, Junio C Hamano wrote:
>>
>> So, what's the status of this patch and other two patches (I
>> consider them as a three-patch series)?
>
> So I have to fix the non initialized variable and to rephrase a litle
> bit the description fo
On Tue, Oct 20, 2015 at 01:20:18PM -0700, Junio C Hamano wrote:
> Remi Pommarel writes:
>
> > On Mon, Oct 05, 2015 at 12:41:34PM -0700, Jonathan Nieder wrote:
> > ...
> >> To protect against a value that might leak in from the environment, this
> >> should say
> >>
> >>IMAP_SEND_LDFLAGS =
>
On Wed, 2015-10-21 at 07:42 +0200, Torsten Bögershausen wrote:
> On 19.10.15 21:48, David Turner wrote:
>
> > + echo test >base && #we need to ensure that the root dir is touched
> > + rm base
> > '
> Thanks for working on this, (I can run the test as soon as I have access to a
> Mac with SS
On 21/10/15 17:05, Torsten Bögershausen wrote:
> On 21.10.15 16:37, Ramsay Jones wrote:
>> Hi Junio,
>>
>> While testing the next branch today, I had a test failure, viz:
>>
>> $ tail ntest-out-fail
>> Test Summary Report
>> ---
>> t7063-status-untracked-cache.sh
On 21.10.15 16:37, Ramsay Jones wrote:
> Hi Junio,
>
> While testing the next branch today, I had a test failure, viz:
>
> $ tail ntest-out-fail
> Test Summary Report
> ---
> t7063-status-untracked-cache.sh (Wstat: 256 Tests: 32
> Failed: 22)
Doe
On 20/10/15 22:24, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> During the discussion on the recent "git am" regression, I noticed
>> that the command reimplemented in C spawns one "mailsplit" and then
>> spawns "mailinfo" followed by "apply --index" to commit the changes
>> described in
Le mercredi 21 octobre 2015, 15:25:59 Thomas Schneider a écrit :
> Signed-off-by: Thomas Schneider
> ---
> po/fr.po | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/po/fr.po b/po/fr.po
> index 581167f..71c4b54 100644
> --- a/po/fr.po
> +++ b/po/fr.po
> @@ -8862,7 +8862,7
Hi Junio,
While testing the next branch today, I had a test failure, viz:
$ tail ntest-out-fail
Test Summary Report
---
t7063-status-untracked-cache.sh (Wstat: 256 Tests: 32
Failed: 22)
Failed tests: 1-18, 20-21, 25, 29
Non-zero exit
Signed-off-by: Thomas Schneider
---
po/fr.po | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/po/fr.po b/po/fr.po
index 581167f..71c4b54 100644
--- a/po/fr.po
+++ b/po/fr.po
@@ -8862,7 +8862,7 @@ msgstr ""
"Si vous souhaitez indiquer l'information de suivi distant pour cette "
Hi,
currently we are experiencing poor write performance when a repository
is pushed to a nfs volume. Interestingly, this seems to be a problem in
newer git versions:
v1.7.12.4: Very good performance
v2.1.4: Bad performance, up to 6 times slower
Are there any changed default settings or new
I was wrong, the script doesn't work on my machine if ctypes is not
imported regardless of python version. I guess I was confused by using
a version of git-p4 before ctypes was introduced, the failing version
and the patched version, as well as several python versions.
Sorry for this misleading cl
Hello,
I couldn't work further on this yesterday (but I read
Documentation/SubmittingPatches, which is a good start I guess). The
diff proposed by Dennis works on my machine, I'll try to figure out
why the original script worked with 2.7.10.
Thanks
2015-10-21 1:00 GMT+02:00 Luke Diamand :
> On 2
Reminder. Is this (or rather the one I'm replying to) patch a better option?
Regards,
Alex
On 10/15/2015 04:38 PM, Alexander Riesen wrote:
The option requiring the explicit reference repositories is a bit of overkill:
the alternates in the original repository *are* reference repositories and
wo
difftool's dir-diff feature was blindly feeding worktree paths
to hash-object without checking whether the path was indeed a
file, causing the feature to fail when repositories contain
symlinks to directories.
Ensure that only files are ever given to hash-object.
Add a test to demonstrate the brea
Enrique Tobis twosigma.com> writes:
> There is something I don't understand, though. Johan must be configuring
his proxy either a) through git
> config files; or b) through environment variables. Johan says his proxy
uses NTLM authentication. If he
> is doing a), then my change should not have ha
64 matches
Mail list logo