On Fri, Oct 27, 2017 at 2:18 AM, Isabella Stephens
wrote:
> On 27/10/17 12:58 pm, Junio C Hamano wrote:
>> There should be an "is the range sensible?" check after all the
>> tweaking to bottom and top are done, I think.
>
> My mistake. I missed that case. I think this section of code is a little
>
On 27/10/17 12:58 pm, Junio C Hamano wrote:
> Isabella Stephens writes:
>
>> diff --git a/builtin/blame.c b/builtin/blame.c
>> index 67adaef4d..b5b9db147 100644
>> --- a/builtin/blame.c
>> +++ b/builtin/blame.c
>> @@ -878,13 +878,13 @@ int cmd_blame(int argc, const char **argv, const char
>> *pr
Junio C Hamano writes:
> Stefan Beller writes:
>
>> (1<<5) is taken twice now.
>
> Good eyes. I think we use bits #1-#8 now (bit #0 is vacant, so are
> #9-#31).
Let's do this bit-shuffling as a preliminary clean-up.
-- >8 --
Subject: [PATCH] xdiff: reassign xpparm_t.flags bits
We have packed
On Fri, Oct 27, 2017 at 4:57 AM, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> It is fine to leave the original code broken at this step while we
>> purely move the lines around, and hopefully this will be corrected
>> in a later step in the series (I am responding as I read on, so I do
>>
On 10/26/2017 5:27 PM, Alex Vandiver wrote:
On Thu, 26 Oct 2017, Ben Peart wrote:
On 10/25/2017 9:31 PM, Alex Vandiver wrote:
diff --git a/fsmonitor.c b/fsmonitor.c
index 7c1540c05..0d26ff34f 100644
--- a/fsmonitor.c
+++ b/fsmonitor.c
@@ -121,6 +121,7 @@ static int query_fsmonitor(int version
On 10/26/2017 5:29 PM, Alex Vandiver wrote:
On Thu, 26 Oct 2017, Ben Peart wrote:
On 10/25/2017 9:31 PM, Alex Vandiver wrote:
diff --git a/t/t7519/fsmonitor-watchman b/t/t7519/fsmonitor-watchman
index a3e30bf54..79f24325c 100755
--- a/t/t7519/fsmonitor-watchman
+++ b/t/t7519/fsmonitor-watchma
Junio C Hamano writes:
> It is fine to leave the original code broken at this step while we
> purely move the lines around, and hopefully this will be corrected
> in a later step in the series (I am responding as I read on, so I do
> not yet know at which patch that happens in this series).
Actu
Junio C Hamano writes:
> For example, with an empty file (i.e. lno == 0), you can ask "git
> blame -L1,-4 ("i.e. "at most four lines, ending at line #1") and the
> code silently accepts the input without noticing that the request is
> an utter nonsense; "file X has only 0 lines" error is given a
Isabella Stephens writes:
> diff --git a/builtin/blame.c b/builtin/blame.c
> index 67adaef4d..b5b9db147 100644
> --- a/builtin/blame.c
> +++ b/builtin/blame.c
> @@ -878,13 +878,13 @@ int cmd_blame(int argc, const char **argv, const char
> *prefix)
> nth_line_cb,
SZEDER Gábor writes:
> The descriptions of the options '--parents', '--children' and
> '--graph' say "see 'History Simplification' below", although the
> referred section is in fact above the description of these options.
>
> Send readers in the right direction by saying "above" instead of
> "bel
Jeff Hostetler writes:
> From: Jeff Hostetler
>
> Refactor add_excludes() to separate the reading of the
> exclude file into a buffer and the parsing of the buffer
> into exclude_list items.
>
> Add add_excludes_from_blob_to_list() to allow an exclude
> file be specified with an OID without assu
Jacob Keller writes:
> I don't think you're missing anything. I think the idea here is: "do
> any users who actively run the test suite care if we start using
> local". I don't think the goal is to allow use of local in non-test
> suite code. At least, that's not how I interpreted it.
>
> Thus it
Ross Kabus writes:
> Is "* -text" in any way different than "-text" (without the * asterisk)? All
> of my .gitattributes files have "-text" (no * asterisk) and I haven't noticed
> any difference but could I be missing something subtle?
>
> ~Ross
A line in the .gitattibute file is of the form
Ramsay Jones writes:
> On 24/10/17 06:28, Junio C Hamano wrote:
> [snip]>
>> * tg/deprecate-stash-save (2017-10-23) 3 commits
>> - stash: remove now superfluos help for "stash push"
>> - mark git stash push deprecated in the man page
>> - replace git stash save with git stash push in the docu
If the -L option is used to specify a line range in git blame, and the
end of the range is past the end of the file, at present git will fail
with a fatal error. This commit prevents such behavior - instead the
blame is displayed for existing lines within the specified range.
Blaming a range that i
On 27/10/17 2:31 am, SZEDER Gábor wrote:
>> If the -L option is used to specify a line range in git blame, and the
>> end of the range is past the end of the file, at present git will fail
>> with a fatal error. This commit prevents such behaviour - instead the
>> blame is display for any existing
On 26/10/17 7:48 pm, Jacob Keller wrote:
> On Thu, Oct 26, 2017 at 12:01 AM, Isabella Stephens
> wrote:
>> If the -L option is used to specify a line range in git blame, and the
>> end of the range is past the end of the file, at present git will fail
>> with a fatal error. This commit prevents su
Is "* -text" in any way different than "-text" (without the * asterisk)? All
of my .gitattributes files have "-text" (no * asterisk) and I haven't noticed
any difference but could I be missing something subtle?
~Ross
Would be useful if these missing options could be added.
Was just checking the version using regular git when I noticed.
$ git --version
git version 2.7.4
I'm not a member of the list, so please cc me in any replies.
Cheers, Jonny
On Thu, Oct 26, 2017 at 2:33 PM, Jonathan Nieder wrote:
> Hi again,
>
> Mkrtchyan, Tigran wrote:
>> Jonathan Nieder wrote:
>>> Tigran Mkrtchyan wrote:
>
In some workflows we have no control on how git command is executed,
however a signed tags are required.
>>>
>>> Don't leave me hanging
Hi again,
Mkrtchyan, Tigran wrote:
> Jonathan Nieder wrote:
>> Tigran Mkrtchyan wrote:
>>> In some workflows we have no control on how git command is executed,
>>> however a signed tags are required.
>>
>> Don't leave me hanging: this leaves me super curious. Can you tell me
>> more about these
On Thu, 26 Oct 2017, Ben Peart wrote:
> On 10/25/2017 9:31 PM, Alex Vandiver wrote:
> > diff --git a/t/t7519/fsmonitor-watchman b/t/t7519/fsmonitor-watchman
> > index a3e30bf54..79f24325c 100755
> > --- a/t/t7519/fsmonitor-watchman
> > +++ b/t/t7519/fsmonitor-watchman
> > @@ -50,7 +50,7 @@ launch_w
On Thu, 26 Oct 2017, Ben Peart wrote:
> On 10/25/2017 9:31 PM, Alex Vandiver wrote:
> > diff --git a/fsmonitor.c b/fsmonitor.c
> > index 7c1540c05..0d26ff34f 100644
> > --- a/fsmonitor.c
> > +++ b/fsmonitor.c
> > @@ -121,6 +121,7 @@ static int query_fsmonitor(int version, uint64_t
> > last_update,
Well, this is a build/release process where we can't pass additional
command line options to git. TO be hones, is case of annotated tags
there is already option tag.forceSignAnnotated. However, non annotated
tags are not forced to be signed.
Additionally, the proposed option is symmetric with comm
Hi,
Tigran Mkrtchyan wrote:
> In some workflows we have no control on how git command is executed,
> however a signed tags are required.
Don't leave me hanging: this leaves me super curious. Can you tell me
more about these workflows?
Thanks and hope that helps,
Jonathan
On 10/26, Ramsay Jones wrote:
>
>
> On 24/10/17 06:28, Junio C Hamano wrote:
> [snip]>
> > * tg/deprecate-stash-save (2017-10-23) 3 commits
> > - stash: remove now superfluos help for "stash push"
> > - mark git stash push deprecated in the man page
> > - replace git stash save with git stash
Thank you for the clarification, it's much appreciated.
-- Hannes
On 10/26/2017 4:05 PM, Ben Peart wrote:
On 10/25/2017 9:31 PM, Alex Vandiver wrote:
This provides modest performance savings. Benchmarking with the
following program, with and without `--no-pretty`, we find savings of
23% (0.316s -> 0.242s) in the git repository, and savings of 8% (5.24s
->
Johannes Sixt wrote:
> Am 26.10.2017 um 13:01 schrieb Lars Schneider:
>> * -text
>> *.sh text eol=lf
>
> Why would that be necessary? I cannot have CRLF in shell scripts etc., not
> even on Windows. (And in addition I do not mind CR in C++ source code.) All
> I want is: Git, please, by all m
On 10/25/2017 9:31 PM, Alex Vandiver wrote:
If the fsmonitor extension is used in conjunction with the split index
extension, the set of entries in the index when it is first loaded is
only a subset of the real index. This leads to only the non-"base"
index being marked as CE_FSMONITOR_VALID.
Am 26.10.2017 um 13:01 schrieb Lars Schneider:
On 26 Oct 2017, at 09:09, Johannes Sixt wrote:
Am 25.10.2017 um 14:19 schrieb Johannes Schindelin:
I envy you for the blessing of such a clean C++ source that you do not
have any, say, Unix shell script in it. Try this, and weep:
$ printf '
On 10/25/2017 9:31 PM, Alex Vandiver wrote:
This provides modest performance savings. Benchmarking with the
following program, with and without `--no-pretty`, we find savings of
23% (0.316s -> 0.242s) in the git repository, and savings of 8% (5.24s
-> 4.86s) on a large repository with 580k fil
In some workflows we have no control on how git command is executed,
however a signed tags are required.
The new config-file option tag.gpgSign enforces signed tags. Additional
command line option --no-gpg-sign is added to disable such behavior if
needed. E.g.:
$ git tag -m "commit message"
On 10/25/2017 9:31 PM, Alex Vandiver wrote:
The fsmonitor command inherits the PWD of its caller, which may be
anywhere in the working copy. This makes is difficult for the
fsmonitor command to operate on the whole repository. Specifically,
for the watchman integration, this causes each subdi
On Thu, Oct 26, 2017 at 01:01:25PM +0200, Lars Schneider wrote:
>
> > On 26 Oct 2017, at 09:09, Johannes Sixt wrote:
> >
> > Am 25.10.2017 um 14:19 schrieb Johannes Schindelin:
> >> I envy you for the blessing of such a clean C++ source that you do not
> >> have any, say, Unix shell script in it
On Wed, Oct 25, 2017 at 10:13:57AM -0700, Jonathan Nieder wrote:
> Hi again,
>
> Lars Schneider wrote:
> >> On 24 Oct 2017, at 20:14, Jonathan Nieder wrote:
>
> >> In any event, you also probably want to declare what you're doing
> >> using .gitattributes. By checking in the files as CRLF, you
This .gitignore file does not work as expected with git-check-ignore:
*.o
!a.o
It seems that “git check-ignore a.o” ignores that “a.o” was re-included. This
is what happens:
$ git --version
git version 2.15.0.rc2.48.g4e40fb302
$ mkdir repo
$ cd repo
$ git init
I
On 10/25/2017 11:47 PM, Junio C Hamano wrote:
Jeff Hostetler writes:
The existing code handles use cases where you want to read the
exclusion list from a pathname in the worktree -- or from blob
named in the index when the pathname is not populated (presumably
because of the skip-worktree bi
From: Jeff Hostetler
I pulled commit 01/13 from Tuesday's partial clone part 1 patch series [1]
and refactored the changes in dir.c to try to address Junio's comments in [2]
WRT sharing more code with the existing read_skip_worktree_file_from_index().
This patch can be discussed independently of
From: Jeff Hostetler
Refactor add_excludes() to separate the reading of the
exclude file into a buffer and the parsing of the buffer
into exclude_list items.
Add add_excludes_from_blob_to_list() to allow an exclude
file be specified with an OID without assuming a local
worktree or index exists.
On Thu, Oct 26, 2017 at 1:42 AM, Jacob Keller wrote:
>>
>> Hello,
>>
>> I'm not sure if this is a good default. I think it's not obvious
>> that moved code gets treated differently than regular changes. I
>> wouldn't expect git diff to ignore whitespace changes (without me
>> telling it to) and s
On Thu, Oct 26, 2017 at 10:41 AM, Joe Perches wrote:
> On Thu, 2017-10-26 at 09:58 -0700, Stefan Beller wrote:
>> + Avar who knows a thing about pcre (I assume the regex compilation
>> has impact on grep speed)
>>
>> On Thu, Oct 26, 2017 at 8:02 AM, Joe Perches wrote:
>> > Comparing a cache warm
Am 25.10.2017 um 20:49 schrieb Stefan Beller:
> The implementations in diff.c to detect moved lines needs to compare
> strings and hash strings, which is implemented in that file, as well
> as in the xdiff library.
>
> Remove the rather recent implementation in diff.c and rely on the well
> exerci
On Thu, 2017-10-26 at 09:58 -0700, Stefan Beller wrote:
> + Avar who knows a thing about pcre (I assume the regex compilation
> has impact on grep speed)
>
> On Thu, Oct 26, 2017 at 8:02 AM, Joe Perches wrote:
> > Comparing a cache warm git grep vs command line grep
> > shows significant differen
On Thu, Oct 26, 2017 at 4:53 AM, Sebastian Schuberth
wrote:
> Signed-off-by: Sebastian Schuberth
> ---
> Documentation/git-rev-parse.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/git-rev-parse.txt b/Documentation/git-rev-parse.txt
> index 0917b8207b9d
Am 25.10.2017 um 20:49 schrieb Stefan Beller:
> +/*
> + * Compare the strings l1 with l2 which are of size s1 and s2 respectively.
> + * Returns 1 if the strings are deemed equal, 0 otherwise.
> + * The `flags` given as XDF_WHITESPACE_FLAGS determine how white spaces
> + * are treated for the compa
Am 24.10.2017 um 22:42 schrieb Stefan Beller:
> On Tue, Oct 24, 2017 at 1:23 PM, René Scharfe wrote:
>
>> xdl_recmatch() is already exported; why not use it without this
>> wrapper?
>
> It is exported in xdiff/xutils.h, to be used by various xdiff/*.c files, but
> not outside of xdiff/. This one
+ Avar who knows a thing about pcre (I assume the regex compilation
has impact on grep speed)
On Thu, Oct 26, 2017 at 8:02 AM, Joe Perches wrote:
> Comparing a cache warm git grep vs command line grep
> shows significant differences in cpu & wall clock.
>
> Any ideas how to improve this?
>
> $ ti
On 24/10/17 06:28, Junio C Hamano wrote:
[snip]>
> * tg/deprecate-stash-save (2017-10-23) 3 commits
> - stash: remove now superfluos help for "stash push"
> - mark git stash push deprecated in the man page
> - replace git stash save with git stash push in the documentation
>
> "git stash sa
On Thu, 2017-10-26 at 18:13 +0200, SZEDER Gábor wrote:
> > Comparing a cache warm git grep vs command line grep
> > shows significant differences in cpu & wall clock.
> >
> > Any ideas how to improve this?
> >
> > $ time git grep "\bseq_.*%p\W" | wc -l
> > 112
> >
> > real0m4.271s
> > us
> Comparing a cache warm git grep vs command line grep
> shows significant differences in cpu & wall clock.
>
> Any ideas how to improve this?
>
> $ time git grep "\bseq_.*%p\W" | wc -l
> 112
>
> real 0m4.271s
> user 0m15.520s
> sys 0m0.395s
>
> $ time grep -r --include=*.[ch] "\bseq_.*%p\W
We can help you with a genuine loan to meet your needs.Do you need a personal
or business loan without stress andQuick approval?Do you need an urgent loan
today? No Credit Checks* LOAN APPROVAL IN 60MINS !!* GUARANTEED SAME DAY
TRANSFER !!* 100% APPROVAL RATE !!* LOW INTEREST RATE !!RegardsMrs
On Thu, 2017-10-26 at 17:11 +0200, Han-Wen Nienhuys wrote:
> On Thu, Oct 26, 2017 at 5:02 PM, Joe Perches wrote:
> > Comparing a cache warm git grep vs command line grep
> > shows significant differences in cpu & wall clock.
> >
> > Any ideas how to improve this?
>
> Is git-grep multithreaded?
> If the -L option is used to specify a line range in git blame, and the
> end of the range is past the end of the file, at present git will fail
> with a fatal error. This commit prevents such behaviour - instead the
> blame is display for any existing lines within the specified range.
s/is displ
The descriptions of the options '--parents', '--children' and
'--graph' say "see 'History Simplification' below", although the
referred section is in fact above the description of these options.
Send readers in the right direction by saying "above" instead of
"below".
Signed-off-by: SZEDER Gábor
On Thu, Oct 26, 2017 at 5:02 PM, Joe Perches wrote:
> Comparing a cache warm git grep vs command line grep
> shows significant differences in cpu & wall clock.
>
> Any ideas how to improve this?
Is git-grep multithreaded? IIRC, grep -r uses multiple threads. (Do
you have a 4-core machine?)
--
G
Comparing a cache warm git grep vs command line grep
shows significant differences in cpu & wall clock.
Any ideas how to improve this?
$ time git grep "\bseq_.*%p\W" | wc -l
112
real0m4.271s
user0m15.520s
sys 0m0.395s
$ time grep -r --include=*.[ch] "\bseq_.*%p\W" * | wc -l
112
rea
I have a business proposal 15,500,000 GBP.
Felicitări ați câștigat de 650.000€.00 Milioane de Euro/Google Promo
extrageri lunare a avut loc Pe 1 octombrie 2017.
Contactați pretinde agent de e-Mail: janosiklubos...@gmail.com
1. Nume complet:
2. Adresa:
3. Sex:
4. Varsta:
5. Ocupația:
6. Telefon:
Robert Avtandiltayn
Online coordonatoru
Signed-off-by: Sebastian Schuberth
---
Documentation/git-rev-parse.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/git-rev-parse.txt b/Documentation/git-rev-parse.txt
index 0917b8207b9d6..95326b85ff68e 100644
--- a/Documentation/git-rev-parse.txt
+++ b/Docume
> On 25 Oct 2017, at 19:13, Jonathan Nieder wrote:
>
> Hi again,
>
> Lars Schneider wrote:
>>> On 24 Oct 2017, at 20:14, Jonathan Nieder wrote:
>
>>> In any event, you also probably want to declare what you're doing
>>> using .gitattributes. By checking in the files as CRLF, you are
>>> decl
> On 26 Oct 2017, at 09:09, Johannes Sixt wrote:
>
> Am 25.10.2017 um 14:19 schrieb Johannes Schindelin:
>> I envy you for the blessing of such a clean C++ source that you do not
>> have any, say, Unix shell script in it. Try this, and weep:
>> $ printf 'echo \\\r\n\t123\r\n' >a1
>> $
--
Assalamu Alaikum.
I am Mrs Azeezah Lawal from France, I am 58 years old woman
suffering from Endometrial cancer and I live in west Africa, please i
want you help me create a charitable project with the money that I
inherited from my deceased husband, I crave your indulgence as a God
fearing in
On Thu, Oct 26, 2017 at 2:07 AM, Jacob Keller wrote:
> On Wed, Oct 25, 2017 at 10:38 PM, Junio C Hamano wrote:
>> Johannes Schindelin writes:
>>
>>> Note that the correct blib path starts with `C:\BuildAgent\_work` and
>>> the line
>>>
>>> use lib (split(/:/, $ENV{GITPERLLIB}));
>>>
>>> sp
On Thu, Oct 26, 2017 at 2:07 AM, Jacob Keller wrote:
> On Wed, Oct 25, 2017 at 10:38 PM, Junio C Hamano wrote:
>> Johannes Schindelin writes:
>>
>>> Note that the correct blib path starts with `C:\BuildAgent\_work` and
>>> the line
>>>
>>> use lib (split(/:/, $ENV{GITPERLLIB}));
>>>
>>> sp
On Wed, Oct 25, 2017 at 10:38 PM, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
>> Note that the correct blib path starts with `C:\BuildAgent\_work` and
>> the line
>>
>> use lib (split(/:/, $ENV{GITPERLLIB}));
>>
>> splits off the drive letter from the rest of the path. Obviously,
On Thu, Oct 26, 2017 at 12:01 AM, Isabella Stephens
wrote:
> If the -L option is used to specify a line range in git blame, and the
> end of the range is past the end of the file, at present git will fail
> with a fatal error. This commit prevents such behaviour - instead the
> blame is display fo
On 10/26/2017 10:40 AM, Jacob Keller wrote:
> On Thu, Oct 26, 2017 at 1:28 AM, Eric Sunshine
> wrote:
>> On Thu, Oct 26, 2017 at 4:18 AM, Michael Haggerty
>> wrote:
>>> Add a test balloon to see if we get complaints from anybody who is
>>> using a shell that doesn't support the "local" keyword.
On Thu, Oct 26, 2017 at 12:22 AM, Simon Ruderich wrote:
> On Wed, Oct 25, 2017 at 03:46:18PM -0700, Stefan Beller wrote:
>> On Mon, Oct 23, 2017 at 7:52 PM, Stefan Beller wrote[1]:
>>> On Mon, Oct 23, 2017 at 6:54 PM, Junio C Hamano wrote:
* As moved-lines display is mostly a presentati
On Thu, Oct 26, 2017 at 1:28 AM, Eric Sunshine wrote:
> On Thu, Oct 26, 2017 at 4:18 AM, Michael Haggerty
> wrote:
>> Add a test balloon to see if we get complaints from anybody who is
>> using a shell that doesn't support the "local" keyword. If so, this
>> test can be reverted. If not, we migh
On Thu, Oct 26, 2017 at 4:18 AM, Michael Haggerty wrote:
> Add a test balloon to see if we get complaints from anybody who is
> using a shell that doesn't support the "local" keyword. If so, this
> test can be reverted. If not, we might want to consider using "local"
> in shell code throughout the
Add a test balloon to see if we get complaints from anybody who is
using a shell that doesn't support the "local" keyword. If so, this
test can be reverted. If not, we might want to consider using "local"
in shell code throughout the git code base.
Signed-off-by: Michael Haggerty
---
This has bee
On 10/26/2017 08:46 AM, Junio C Hamano wrote:
> Michael Haggerty writes:
>
>> Even when we are deleting references, we needn't overwrite the
>> `packed-refs` file if the references that we are deleting are not
>> present in that file. Implement this optimization as follows:
>
> This goal I can u
On Wed, Oct 25, 2017 at 03:46:18PM -0700, Stefan Beller wrote:
> On Mon, Oct 23, 2017 at 7:52 PM, Stefan Beller wrote[1]:
>> On Mon, Oct 23, 2017 at 6:54 PM, Junio C Hamano wrote:
>>>
>>> * As moved-lines display is mostly a presentation thing, I wonder
>>>if it makes sense to always match loo
Am 25.10.2017 um 14:19 schrieb Johannes Schindelin:
I envy you for the blessing of such a clean C++ source that you do not
have any, say, Unix shell script in it. Try this, and weep:
$ printf 'echo \\\r\n\t123\r\n' >a1
$ sh a1
a1: 2: a1: 123: not found
I was bitten by
On 26/10/17 5:15 pm, Junio C Hamano wrote:
> Isabella Stephens writes:
>
>> If the -L option is used to specify a line range in git blame, and the
>> end of the range is past the end of the file, git will fail with a fatal
>> error. It may instead be desirable to perform a git blame for the line
If the -L option is used to specify a line range in git blame, and the
end of the range is past the end of the file, at present git will fail
with a fatal error. This commit prevents such behaviour - instead the
blame is display for any existing lines within the specified range.
Signed-off-by: Isa
77 matches
Mail list logo
