Tommaso Colombo tommaso.colo...@outlook.com wrote:
When populating svn:mergeinfo, git-svn merge checks if the merge parent
of the merged branch is under the same root as the git-svn repository.
This was implemented comparing $gs-repos_root with the return value of
of cmt_metadata for the merge
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
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 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 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
From: Junio C Hamano gits...@pobox.com
Philip Oakley philipoak...@iee.org 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
From: Philip Oakley philipoak...@iee.org
From: Junio C Hamano gits...@pobox.com
Philip Oakley philipoak...@iee.org 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
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 ocroque...@free.fr
---
mergetools/bc4 | 25 +
1 files changed, 25 insertions(+), 0 deletions(-)
create mode 100644
On Oct 19, 2014, at 18:16, Eric Wong normalper...@yhbt.net wrote:
Jakob Stoklund Olesen stokl...@2pi.dk 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
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
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 dirty
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
konstan...@linuxfoundation.org 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
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
Jeff King p...@peff.net 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:
Olivier Croquette ocroque...@free.fr 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
Junio C Hamano gits...@pobox.com writes:
Torsten Bögershausen tbo...@web.de 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
On Mon, Oct 20, 2014 at 09:21:24AM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net 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,
Philip Oakley philipoak...@iee.org writes:
From: Junio C Hamano gits...@pobox.com
Philip Oakley philipoak...@iee.org 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.
Junio C Hamano gits...@pobox.com writes:
Olivier Croquette ocroque...@free.fr 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
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
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 use bc4 which
Linus Torvalds torva...@linux-foundation.org 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
konstan...@linuxfoundation.org wrote:
Looks like 3.18-rc1 upload didn't work:
This is why the front
W. Trevor King wk...@tremily.us 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
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
Sebastian Schuberth sschube...@gmail.com 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.
---
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
From: Junio C Hamano gits...@pobox.com
Philip Oakley philipoak...@iee.org writes:
From: Junio C Hamano gits...@pobox.com
Philip Oakley philipoak...@iee.org writes:
...
[ (ASCII 0) change]
The reason I proposed the change is because on the web view, on my
machine, I questioned whether the
Konstantin Ryabitsev konstan...@linuxfoundation.org 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,
Philip Oakley philipoak...@iee.org writes:
From: Junio C Hamano gits...@pobox.com
...
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.
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
Junio C Hamano gits...@pobox.com writes:
Philip Oakley philipoak...@iee.org writes:
From: Junio C Hamano gits...@pobox.com
...
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
On 20 Oct 2014, at 19:32, Junio C Hamano gits...@pobox.com 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
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
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'
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 more
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 tar
On Mon, Oct 20, 2014 at 3:28 PM, brian m. carlson
sand...@crustytoothpaste.net 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
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 not
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
From: Stefan Beller sbel...@google.com
Found by scan.coverity.com (ID: 1248110)
Signed-off-by: Stefan Beller sbel...@google.com
---
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
@@
From: Stefan Beller sbel...@google.com
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 sbel...@google.com
---
.mailmap | 1 +
1 file changed,
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
Stefan Beller stefanbel...@gmail.com writes:
From: Stefan Beller sbel...@google.com
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
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
44 matches
Mail list logo
