When git grep is run with combined patterns such as '-e p1 --and -e p2'
and surrounding context lines are requested, the output contains
incorrectly highlighted matches.
Consider the following output (highlighted matches are surrounded by '*'
characters):
$ cat testfile
foo a
foo b
Stefan Beller writes:
> From: Stefan Beller
>
> Note that despite the private address being first, Google owns the
> copyright on this patch as any other patch I'll be sending signed off
> by the sbel...@google.com address.
While Googlers are encouraged to interact with external open source
pro
During long fetches with many revisions, some SVN functions are not
always using local pools and some gets into the global pool. Ensure
we free that memory occasionally between SVN::RA::get_log calls to
reduce memory growth.
This reduces memory usage over the course of fetching 10K revisions
usin
From: Stefan Beller
Found by scan.coverity.com (ID: 1248110)
Signed-off-by: Stefan Beller
---
transport.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/transport.c b/transport.c
index 055d2a2..fbab6ee 100644
--- a/transport.c
+++ b/transport.c
@@ -774,6 +774,7 @@ void transport_print_pus
From: Stefan Beller
Note that despite the private address being first, Google owns the
copyright on this patch as any other patch I'll be sending signed off
by the sbel...@google.com address.
Signed-off-by: Stefan Beller
---
.mailmap | 1 +
1 file changed, 1 insertion(+)
diff --git a/.mailmap
This environment variable is added in a1bea2c (ref namespaces:
infrastructure - 2011-07-05). This is clearly repo specific setting
and should not be propagated to subprograms.
In practice, this is not a problem because GIT_NAMESPACE seems
designed for use on the server side and while submodule tra
On 20/10/14 06:28 PM, brian m. carlson wrote:
>> Junio, quite frankly, I don't think that that fix was a good idea. I'd
>> > suggest having a *separate* umask for the pax headers, so that we do
>> > not break this long-lasting stability of "git archive" output in ways
>> > that are unfixable and n
On Mon, Oct 20, 2014 at 3:28 PM, brian m. carlson
wrote:
>
> It doesn't appear that the stability of git archive --format=tar is
> documented anywhere. Given that, it doesn't seem reasonable to expect
> that any tar implementation produces bit-for-bit compatible output
> between versions.
The ke
On Mon, Oct 20, 2014 at 08:25:59AM -0700, Linus Torvalds wrote:
> Junio, Brian,
>
> it seems that the stability of the "git tar" output is broken.
It doesn't appear that the stability of git archive --format=tar is
documented anywhere. Given that, it doesn't seem reasonable to expect
that any
On Mon, Oct 20, 2014 at 02:37:09PM -0400, Konstantin Ryabitsev wrote:
> On 20/10/14 02:28 PM, Junio C Hamano wrote:
> > I have to wonder why 10f343ea (archive: honor tar.umask even for pax
> > headers, 2014-08-03) is a problem but an earlier change v1.8.1.1~8^2
> > (archive-tar: split long paths mo
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
According to tinyurl.com/gitCal, the feature freeze for this cycle
is scheduled to happen at the end of this month. What's in the
'next' branch
Hello,
It would be great if the documentation showed that the git-difftool(1)
command accepted the --cached option. You can probably steal appropriate
verbiage from the git-diff(1) manpage.
$ git --version
git version 2.1.1
Thanks,
--Joe
--
To unsubscribe from this list: send the line "unsubscr
On 20 Oct 2014, at 19:32, Junio C Hamano wrote:
> Perhaps something like this, so that existing users can still use
> "bc3" and other people can use "bc" if it bothers them that they
> have to say "3" when the backend driver works with both 3 and 4?
Thanks for the quick and great feedback.
This l
Junio C Hamano writes:
> "Philip Oakley" writes:
>
>> From: "Junio C Hamano"
>> ...
>>> I think it is just the font. I just opened the above page with
>>> Chrome and futzed the text from '0' to '0123456789' to see how it
>>> look. That round thing is consistent with how other digits are
>>> re
NOTE:THIS IS YOUR PACKAGE REGISTERED CODE NO OVX950.
I want to acknowledge you that we have finally succeeded in getting your ATM
VISA CARD worth’s of $7.5USD out of ECOWAS department with the help of Mr.
James George Attorney General of Federal High Court of Justice so you are
advised to re
"Philip Oakley" writes:
> From: "Junio C Hamano"
> ...
>> I think it is just the font. I just opened the above page with
>> Chrome and futzed the text from '0' to '0123456789' to see how it
>> look. That round thing is consistent with how other digits are
>> rendered.
>>
>> https://plus.google.
Konstantin Ryabitsev writes:
> On 20/10/14 02:28 PM, Junio C Hamano wrote:
>> I have to wonder why 10f343ea (archive: honor tar.umask even for pax
>> headers, 2014-08-03) is a problem but an earlier change v1.8.1.1~8^2
>> (archive-tar: split long paths more carefully, 2013-01-05), which
>> also s
From: "Junio C Hamano"
"Philip Oakley" writes:
From: "Junio C Hamano"
Philip Oakley writes:
...
[ (ASCII 0) change]
The reason I proposed the change is because on the web view, on my
machine, I questioned whether the specially formatted character
(remember its quotation is consumed by
Too late that the original is already in 'next'. Care to reroll as
an incremental, plaese?
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
Sebastian Schuberth writes:
>> Perhaps something like this, so that existing users can still use
>> "bc3" and other people can use "bc" if it bothers them that they
>> have to say "3" when the backend driver works with both 3 and 4?
>
> That indeed sounds like the best approach.
>
>> --- a/git-me
On 20/10/14 02:28 PM, Junio C Hamano wrote:
> I have to wonder why 10f343ea (archive: honor tar.umask even for pax
> headers, 2014-08-03) is a problem but an earlier change v1.8.1.1~8^2
> (archive-tar: split long paths more carefully, 2013-01-05), which
> also should have broken bit-for-bit compati
"W. Trevor King" writes:
> On Sun, Oct 19, 2014 at 03:49:36PM -0700, Junio C Hamano wrote:
>> I'll queue this as-is, but it makes me wonder if we want to do this
>> without if/then/fi, e.g.
>>
>> : ${LOGNAME:=${USER:-$(id -u -n)}
>
> I'm fine with that too.
>
>> Spelling everything out with
Linus Torvalds writes:
> Junio, Brian,
>
> it seems that the stability of the "git tar" output is broken.
>
> On Mon, Oct 20, 2014 at 4:59 AM, Konstantin Ryabitsev
> wrote:
>>
>> Looks like 3.18-rc1 upload didn't work:
>>
>> This is why the front page still lists 3.17 as the latest mainline. W
On 20.10.2014 19:32, Junio C Hamano wrote:
>>> Beyond compare 4 is out since september 2014. The CLI interface
>>> doesn't seem to have changed compared to the version 3.
>>
>> Hmph, if this is identical to mergetools/bc3, why is the patch even
>> needed? Do we auto-detect something and try to us
Dear Sir/Madam, Here is a pdf attachment of my proposal to you. Please
read and reply I would be grateful. Jose Calvache
--
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-
Junio C Hamano writes:
> Olivier Croquette writes:
>
>> Beyond compare 4 is out since september 2014. The CLI interface
>> doesn't seem to have changed compared to the version 3.
>
> Hmph, if this is identical to mergetools/bc3, why is the patch even
> needed? Do we auto-detect something and tr
"Philip Oakley" writes:
> From: "Junio C Hamano"
>> Philip Oakley writes:
>>
>>> Correct backtick quoting for some of the modification states to give
>>> consistent web rendering.
>>
>> This is to match the way how "XY PATH1 -> PATH2" is typeset, I
>> presume. Some in the body text are already
On Mon, Oct 20, 2014 at 09:21:24AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > I think we can take your patch a step further, though, like:
> >
> > -- >8 --
> > Subject: [PATCH] drop add_object_array_with_mode
> > ...
>
> Thanks. I think I picked up all incrementals in this thread,
Junio C Hamano writes:
> Torsten Bögershausen writes:
>
>> - The '+' at an otherwise empty line generates an empty line
>> in html, so s/^$/+/
>
> I think the rule is actually that you cannot have multiple
> paragraphs in an enumerated list the same "headword double-colon and
> then indented p
Olivier Croquette writes:
> Beyond compare 4 is out since september 2014. The CLI interface
> doesn't seem to have changed compared to the version 3.
Hmph, if this is identical to mergetools/bc3, why is the patch even
needed? Do we auto-detect something and try to use bc4 which does
not exist a
Jeff King writes:
> I think we can take your patch a step further, though, like:
>
> -- >8 --
> Subject: [PATCH] drop add_object_array_with_mode
> ...
Thanks. I think I picked up all incrementals in this thread, but
please holler if I missed anything.
--
To unsubscribe from this list: send the
On Sun, Oct 19, 2014 at 03:49:36PM -0700, Junio C Hamano wrote:
> I'll queue this as-is, but it makes me wonder if we want to do this
> without if/then/fi, e.g.
>
> : ${LOGNAME:=${USER:-$(id -u -n)}
I'm fine with that too.
> Spelling everything out with if/then/fi is obviously at the other
Junio, Brian,
it seems that the stability of the "git tar" output is broken.
On Mon, Oct 20, 2014 at 4:59 AM, Konstantin Ryabitsev
wrote:
>
> Looks like 3.18-rc1 upload didn't work:
>
> This is why the front page still lists 3.17 as the latest mainline. Want
> to try again?
Ok, tried again, a
nathdwek schrieb am 17.10.2014 um 19:30:
> Hello,
>
> It seems to me that the colors used to indicate the repo's state in the
> prompt are hardcoded although the top comment says otherwise.
>
> From contrib/completion/git-contrib.sh:
>
> [83]# If you would like a colored hint about the current d
Since a few days, one of our repos is causing problems during git fetch,
basically git fetch over http hangs during find_common. When using ssh,
this does not happen. One thing to noe about this repo is that it has
53000+ refs, though I'm not convinced that that is the cause of my
ptoblem.
Client
> On Oct 19, 2014, at 18:16, Eric Wong wrote:
>
> Jakob Stoklund Olesen wrote:
>> If cached_mergeinfo is using too much memory, you can probably drop
>> that cache entirely. IIRC, it didn't give that much of a speed up.
>>
>> I am surprised that it is using a lot of memory, though. There is on
Beyond compare 4 is out since september 2014. The CLI interface doesn't seem to
have changed compared to the version 3.
Signed-off-by: Olivier Croquette
---
mergetools/bc4 | 25 +
1 files changed, 25 insertions(+), 0 deletions(-)
create mode 100644 mergetools/bc4
dif
From: "Philip Oakley"
From: "Junio C Hamano"
Philip Oakley writes:
..
While at it, use 00 for ASCII NUL to avoid any confusion with the
letter O.
(remember its quotation is consumed by ascidoc) looked too much like
an
I mis-remembered. It's not quoted.
Looking around some more, it's
From: "Junio C Hamano"
Philip Oakley writes:
Correct backtick quoting for some of the modification states to give
consistent web rendering.
This is to match the way how "XY PATH1 -> PATH2" is typeset, I
presume. Some in the body text are already `XY` to match, but some
others are not,
and
On Mon, Oct 20, 2014 at 12:20:35AM +, brian m. carlson wrote:
> This series is designed to implement the changes necessary to build Git
> using Asciidoctor instead of AsciiDoc.
These all looked sane to me from my cursory read (I haven't played with
AsciiDoctor myself yet, but it looks from yo
On Sun, Oct 19, 2014 at 11:40:22PM +1100, Ben Aveling wrote:
> This seems to have worked. I also had to move away the existing .idx and
> copy in a new one before it was happy.
Sorry if I wasn't clear; you do need to copy the .idx files along with
the packfiles (you can regenerate the .idx files
On Sun, Oct 19, 2014 at 01:13:30PM +0200, René Scharfe wrote:
> >We could flip it to give the managed version the short name (and calling
> >the unmanaged version "env_ptr" or something). That would require
> >munging the existing callers, but the tweak would be simple.
>
> Perhaps, but I'm a but
On Sun, Oct 19, 2014 at 01:14:20PM +0200, René Scharfe wrote:
> --- a/wt-status.c
> +++ b/wt-status.c
> @@ -726,14 +726,14 @@ static void wt_status_print_changed(struct wt_status *s)
> static void wt_status_print_submodule_summary(struct wt_status *s, int
> uncommitted)
> {
> struct child
43 matches
Mail list logo
