Re: [PATCH] git-svn: merge: fix rooturl/branchurl match check
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 parent. However, the first may contain a
username, whereas the second does not. In this case the comparison
fails.
Remove the username from $gs-repos_root before performing the
comparison.
Thanks. Commit makes sense, but one of the test cases fails for me,
can you check it out?
$ make make t9161-git-svn-mergeinfo-push.sh -C t GIT_TEST_OPTS='-i -v'
snip successes
ok 11 - reintegration merge
expecting success:
mergeinfo=$(svn_cmd propget svn:mergeinfo $svnrepo/branches/svnb4)
test $mergeinfo = /branches/svnb1:2-4,7-9,13-18
/branches/svnb2:3,8,16-17
/branches/svnb3:4,9
/branches/svnb5:6,11
not ok 12 - check reintegration mergeinfo
#
# mergeinfo=$(svn_cmd propget svn:mergeinfo
$svnrepo/branches/svnb4)
# test $mergeinfo = /branches/svnb1:2-4,7-9,13-18
# /branches/svnb2:3,8,16-17
# /branches/svnb3:4,9
# /branches/svnb5:6,11
#
make: *** [t9161-git-svn-mergeinfo-push.sh] Error 1
make: Leaving directory `/home/ew/git-core/t'
You'll also need to sign-off (see Documentation/SubmittingPatches)
It is required (project policy, not mine)
@@ -729,7 +730,7 @@ sub populate_merge_info {
}
my $branchpath = $1;
- my $ra = Git::SVN::Ra-new($branchurl);
+ my $ra =
Git::SVN::Ra-new(add_path_to_url($gs-repos_root, $branchpath));
Also, please keep long lines wrapped to = 80 columns.
Thanks again.
--
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
Re: [PATCH 2/2] use env_array member of struct child_process
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_process sm_summary = CHILD_PROCESS_INIT;
- struct argv_array env = ARGV_ARRAY_INIT;
struct argv_array argv = ARGV_ARRAY_INIT;
I don't think it belongs in this patch, but a follow-on 3/2 might be to
give argv the same treatment.
-Peff
--
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
Re: [PATCH] receive-pack: plug minor memory leak in unpack()
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 skeptical of big renames. Let's start small and add env_array, and see how far we get with that. Yeah, having basically implemented patches similar to yours, I think that is a good first step. Both of your patches looked good to me. Trickiness makes me nervous, especially in daemon.c. And 5% CPU usage just for waiting sounds awful. Using waitpid(0, ...) is not supported by the current implementation in compat/mingw.c, however. I guess you could use wait() and a counter that you increment whenever you get SIGCLD, but that feels a bit hacky. I wonder how bad a real waitpid would be for mingw. By the way, does getaddrinfo(3) show up in your profiles much? Recently I looked into calling it only on demand instead of for all incoming connections because doing that unconditional with a user-supplied (tainted) hostname just felt wrong. The resulting patch series turned out to be not very pretty and I didn't see any performance improvements in my very limited tests, however; not sure if it's worth it. It shows up in the child, not the parent, so it wasn't part of the profiling I did recently. I did look at it just now, and it does introduce some latency into each request (though not a lot of CPU; mainly it's the DNS request). Like you, I'm nervous about convincing git-daemon to do lookups on random hosts. By itself it's not horrible (except for tying up git-daemon with absurdly long chains of glueless references), but I worry that it could exacerbate other problems (overflows or other bugs in DNS resolvers, as part of a cache-poisoning scheme, orbeing used for DoS amplification). I think doing it on demand would be a lot more sensible. We do not need to do a lookup at all unless the %H, %CH, or %IP interpolated path features are used. And we do not need to do hostname canonicalization unless %CH is used. -Peff -- 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
Re: [RFC/PATCH] fsck: do not canonicalize modes in trees we are checking
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 from the packfiles on the destination, but they're not that big; it's probably easier just to copy them). I'm not sure that what I've done is so different from simply copying the other version of the repository - there shouldn't have been anything in the corrupt version that wasn't also in the good one. But any rate, it worked. Right, a valid technique for repairing corruption is to just blow away the original repo entirely and replace it with a good copy. But this is a way of ensuring that no commits are missed, and keeping the original set of refs, config options, and reflogs. -Peff -- 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
Re: [PATCH v2 0/3] Allow building Git with Asciidoctor
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 your results like you have). I've successfully built the documentation with Asciidoctor using the following command line: make doc ASCIIDOC=asciidoctor ASCIIDOC_HTML=html5 \ ASCIIDOC_DOCBOOK=docbook45 ASCIIDOC_EXTRA='-alitdd=#45;#45;' \ ASCIIDOC_CONF= That incantation is getting a bit hairy. Is it worth adding a meta-macro like USE_ASCIIDOCTOR that encompasses it all? That might encourage other people to play around with it. -Peff -- 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
Re: [PATCH] doc: fix 'git status --help' character quoting
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 match, but some others are not, and you are fixing them, all of which look good. Do you need me to add this to the commit message? While at it, use 00 for ASCII NUL to avoid any confusion with the letter O. I do not think this is particularly a good change. We try to follow the convention of spelling ASCII value in decimal (e.g. ASCII double quote (34)), and 00 is not the way how you usually spell a number in decimal. Existing description is perfectly fine; there is no risk for anybody to mistake O (oh) as part of digits, whether you use decimal or hexadecimal. 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 ascidoc) looked too much like an Oh, so I specially checked on the original .txt to see if it was correct there, which led me to the proposal for '00' in this case. I'd be just as happy with a single zero, as long as it's distinct from O (as you probably know, in the depths of hsitory typewriters didn't even have 0 and 1 keys - the O and l were used interchangably and many fonts keep too much to that pattern of undifferetiability!) Note the more recent http://git-scm.com/docs/git-status has the formatted round o and https://www.kernel.org/pub/software/scm/git/docs/git-status.html (which IIUC is out of date) has an unformatted 0. Looking around some more, it's as if 0) is special cased in some conversion to HTML. If you have an aversion to mentioning ASCII when clarifying which character we talk about, you could of course do s/ASCII 0/'\0'/ but I do not know if that is an improvement. -- Philip -- 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
Re: [PATCH] doc: fix 'git status --help' character quoting
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 mis-remembered. It's not quoted. Looking around some more, it's as if 0) is special cased in some conversion to HTML. This looks to be an issue of the browser display font (Chrome/Chromium/Firefox) where it's almost impossible to distinguish 0 and o without other numbers or letters being present for context. The old kernel.org page appears to specify the font differently and thus provides a clear rendering. Philip -- 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
[PATCH] Copy mergetool bc3 as bc4
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 mergetools/bc4
diff --git a/mergetools/bc4 b/mergetools/bc4
new file mode 100644
index 000..b6319d2
--- /dev/null
+++ b/mergetools/bc4
@@ -0,0 +1,25 @@
+diff_cmd () {
+ $merge_tool_path $LOCAL $REMOTE
+}
+
+merge_cmd () {
+ touch $BACKUP
+ if $base_present
+ then
+ $merge_tool_path $LOCAL $REMOTE $BASE \
+ -mergeoutput=$MERGED
+ else
+ $merge_tool_path $LOCAL $REMOTE \
+ -mergeoutput=$MERGED
+ fi
+ check_unchanged
+}
+
+translate_merge_tool_path() {
+ if type bcomp /dev/null 2/dev/null
+ then
+ echo bcomp
+ else
+ echo bcompare
+ fi
+}
--
1.7.2.5
--
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
Re: git-svn performance
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 memory, though. There is only
one entry per SVN branch.
Something like the below? (on top of your original two patches)
Pushed to my master @ git://bogomips.org/git-svn.git
Yes, but I think you can remove cached_mergeinfo_rev too.
Thanks
/Jakob
Eric Wong (2):
git-svn: reduce check_cherry_pick cache overhead
git-svn: cache only mergeinfo revisions
Jakob Stoklund Olesen (2):
git-svn: only look at the new parts of svn:mergeinfo
git-svn: only look at the root path for svn:mergeinfo
git-svn still seems to have some excessive memory usage problems,
even independenty of mergeinfo stuff.
--8
From: Eric Wong normalper...@yhbt.net
Date: Mon, 20 Oct 2014 01:02:53 +
Subject: [PATCH] git-svn: cache only mergeinfo revisions
This should reduce excessive memory usage from the new mergeinfo
caches without hurting performance too much, assuming reasonable
latency to the SVN server.
Cc: Hin-Tak Leung ht...@users.sourceforge.net
Suggested-by: Jakob Stoklund Olesen stokl...@2pi.dk
Signed-off-by: Eric Wong normalper...@yhbt.net
---
perl/Git/SVN.pm | 22 --
1 file changed, 8 insertions(+), 14 deletions(-)
diff --git a/perl/Git/SVN.pm b/perl/Git/SVN.pm
index 171af37..f8a75b1 100644
--- a/perl/Git/SVN.pm
+++ b/perl/Git/SVN.pm
@@ -1713,13 +1713,10 @@ sub mergeinfo_changes {
# Initialize cache on the first call.
unless (defined $self-{cached_mergeinfo_rev}) {
$self-{cached_mergeinfo_rev} = {};
-$self-{cached_mergeinfo} = {};
}
my $cached_rev = $self-{cached_mergeinfo_rev}{$old_path};
-if (defined $cached_rev $cached_rev == $old_rev) {
-$old_minfo = $self-{cached_mergeinfo}{$old_path};
-} else {
+unless (defined $cached_rev $cached_rev == $old_rev) {
my $ra = $self-ra;
# Give up if $old_path isn't in the repo.
# This is probably a merge on a subtree.
@@ -1728,19 +1725,16 @@ sub mergeinfo_changes {
directory didn't exist in r$old_rev\n;
return {};
}
-my (undef, undef, $props) =
-$self-ra-get_dir($old_path, $old_rev);
-if (defined $props-{svn:mergeinfo}) {
-my %omi = map {split :, $_ } split \n,
-$props-{svn:mergeinfo};
-$old_minfo = \%omi;
-}
-$self-{cached_mergeinfo}{$old_path} = $old_minfo;
-$self-{cached_mergeinfo_rev}{$old_path} = $old_rev;
}
+my (undef, undef, $props) = $self-ra-get_dir($old_path, $old_rev);
+if (defined $props-{svn:mergeinfo}) {
+my %omi = map {split :, $_ } split \n,
+$props-{svn:mergeinfo};
+$old_minfo = \%omi;
+}
+$self-{cached_mergeinfo_rev}{$old_path} = $old_rev;
# Cache the new mergeinfo.
-$self-{cached_mergeinfo}{$path} = \%minfo;
$self-{cached_mergeinfo_rev}{$path} = $rev;
my %changes = ();
--
EW
--
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
git fetch (http) hanging/failing on one specific repository, http only
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 and server are both 2.1.2, the 'dirty' is from some debugging printf's I threw in. I also tested with 1.8.4, which also exhibits this behaviour: GIT_CURL_VERBOSE=1 /home/dkaarsemaker/git/git fetch -vvv * Couldn't find host xxx.booking.com in the .netrc file; using defaults * Expire cleared * About to connect() to xxx.booking.com port 80 (#0) * Trying 10.196.70.243... GET /git/main.git/info/refs?service=git-upload-pack HTTP/1.1 User-Agent: git/2.1.2.dirty Host: xxx.booking.com Accept: */* Accept-Encoding: gzip Pragma: no-cache HTTP/1.1 200 OK Date: Mon, 20 Oct 2014 13:41:00 GMT Server: Apache Expires: Fri, 01 Jan 1980 00:00:00 GMT Pragma: no-cache Cache-Control: no-cache, max-age=0, must-revalidate Transfer-Encoding: chunked Content-Type: application/x-git-upload-pack-advertisement * Expire cleared * Connection #0 to host xxx.booking.com left intact HEADServer supports multi_ack_detailed Server supports no-done Server supports side-band-64k Server supports ofs-delta Server version is git/2.1.2 want dfb112668697c44d3221ce1e603af1ee46fff41e (refs/heads/xxx) want e884b8d79a935fdc9291c2424372cd372f0b7666 (refs/heads/xxx) want d83ee364a2be10ea5d9fa9c19a64d8680f7f2327 (refs/heads/xxx) want 3cf9d21630bb5e380be3537628cd026ddfee8a11 (refs/heads/xxx) want 0ecb911a9062d2a94c5381efab8b10d76acfa487 (refs/heads/xxx) want 53dca992d6162fb08a1c722317621866ade339ca (refs/heads/xxx) want 49de5539e17ed53706159f4fdda2bdacac18f9d6 (refs/heads/xxx) want 6fb579642139bff5e28f313012dbe7ffe4f3aae5 (refs/heads/xxx) want 62bf71564cc70c3d9a5cd8046b09e136f9e27928 (refs/heads/xxx) want c1f98f24174113f901950506ab6a08c54c88e867 (refs/heads/xxx) want 830ee444f8e9f3127ee7c8ac054690581e6bea53 (refs/heads/xxx) want dd7a12a3f7344e78136fe8ea1d8bd5b8a7592bda (refs/heads/xxx) want acc5936de82f6f31a50a3c68dc1fe22bfe5818ef (refs/heads/xxx) want 88c5f7c05e55a83826112c4cc19e2e9fc53bbdfb (refs/heads/xxx) want 639339def49ba7f3d469413e7d26e0d205fa23b7 (refs/heads/xxx) want 65a12becb29987726864709429052f8b63a9e468 (refs/heads/xxx) want 69375797ac43b2427d6c88a07202cb986eb0e91e (refs/heads/xxx) want c32e7a453643f43ad3a840d8972a591345eb4ce6 (refs/heads/xxx) want 024a9c8904934522a8a625145997b118cb07ea85 (refs/heads/xxx) want 7f3b10df5ddb7eb4d8b310812e7406515ff9c439 (refs/heads/xxx) want 762cf79100279f14c1d6089daacd7a800d4574d9 (refs/heads/xxx) want 8b74fe415472720cc72c761af8025e730f8378ce (refs/heads/xxx) want 811b5bea55533bcc158da1a568b92a070a5aff46 (refs/heads/xxx) want 8a46fb3dedb55e63fa580541c9f7633d425a8ea2 (refs/heads/xxx) want d81598d11edcbda0e020b63c3ae6084029b0714c (refs/heads/xxx) want 0641ea1ab05775a73f7e99342859ee638b534159 (refs/heads/xxx) want 837466f5fbd51cf21c93e5d44124dce42deac469 (refs/heads/trunk) want 8225bf4201c14518eef7c81c8964b5f11b12c0eb (refs/heads/xxx) want d366df049d50d879cc3dfaced812ebac91a987ba (refs/heads/xxx) want c47ff2f1b8155dd8a9e0113fd92c3a109dce72b7 (refs/heads/xxx) want dd136cdae6ef772323b922c15b616ad987de (refs/tags/admin-20141016-163909) skip 150-odd tags with the same format skip lots of back anf forth have/ack, here are the apache logs for them 10.189.174.96 - - [20/Oct/2014:15:41:04 +0200] POST /git/main.git/git-upload-pack HTTP/1.1 200 904 10.189.174.96 - - [20/Oct/2014:15:41:04 +0200] POST /git/main.git/git-upload-pack HTTP/1.1 200 1576 10.189.174.96 - - [20/Oct/2014:15:41:04 +0200] POST /git/main.git/git-upload-pack HTTP/1.1 200 3312 10.189.174.96 - - [20/Oct/2014:15:41:04 +0200] POST /git/main.git/git-upload-pack HTTP/1.1 200 6784 10.189.174.96 - - [20/Oct/2014:15:41:04 +0200] POST /git/main.git/git-upload-pack HTTP/1.1 200 13728 10.189.174.96 - - [20/Oct/2014:15:41:05 +0200] POST /git/main.git/git-upload-pack HTTP/1.1 200 27840 10.189.174.96 - - [20/Oct/2014:15:41:05 +0200] POST /git/main.git/git-upload-pack HTTP/1.1 200 55392 10.189.174.96 - - [20/Oct/2014:15:41:05 +0200] POST /git/main.git/git-upload-pack HTTP/1.1 200 112456 10.189.174.96 - - [20/Oct/2014:15:41:06 +0200] POST /git/main.git/git-upload-pack HTTP/1.1 200 169800 10.189.174.96 - - [20/Oct/2014:15:41:06 +0200] POST /git/main.git/git-upload-pack HTTP/1.1 200 227144 skip lots of acks got ack 3 87f1981596402d37d905dfb5356be7aa99020053 got ack 3 5ed75db2add2ae8abfb888fac1502ed3fac0221e got ack 3 ee08fd65a137548c6769bf703f4da07307c3023d skip lots of haves have d6d890f55dcf83d1f6a6328c07a57b0c60f28e30 have bd94ba6d06011aaaf620abcea37e756a590bebd5 have 3946073390c2548a3f065c88f41a4b8964b9a2dd have 34f881dbb4af0e3b090a93b17fba9c31b7771f61 have a7c18a679ce9e6eefe7930556735b29ecfc33952 POST git-upload-pack (gzip 262103 to 130185 bytes) * Couldn't find host xxx.booking.com in the .netrc file; using defaults * Re-using existing
Re: __git_ps1_colorize__gitstring() in git_prompt.sh: colors are hardcoded?
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 state, set
# GIT_PS1_SHOWCOLORHINTS to a nonempty value. The colors are based on
# the colored output of git status -sb and are available only when
# using __git_ps1 for PROMPT_COMMAND or precmd.
That should have said ... on the default colors used for the colored
output of...
[228]__git_ps1_colorize_gitstring ()
{
if [[ -n ${ZSH_VERSION-} ]]; then
local c_red='%F{red}'
local c_green='%F{green}'
local c_lblue='%F{blue}'
local c_clear='%f'
else
# Using \[ and \] around colors is necessary to prevent
# issues with command line editing/browsing/completion!
local c_red='\[\e[31m\]'
local c_green='\[\e[32m\]'
local c_lblue='\[\e[1;34m\]'
local c_clear='\[\e[0m\]'
fi
local bad_color=$c_red
local ok_color=$c_green
local flags_color=$c_lblue
local branch_color=
As expected upon seeing this snippet, the color.status.slot entries in
the git config file do modify the git status -sb output but don't modify
the colors used in the prompt.
Regards,
Nathan
The script could query config for these colors, but that would amount to
4 additional forks and git config calls each time a prompt is
generated. If you want the colors to be configurable, you should
probably rather introduce environment variables - or edit your copy of
the script ;)
Cheers,
Michael
--
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
Re: Sources for 3.18-rc1 not uploaded
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 again?
Ok, tried again, and failed again.
If that still doesn't work, you may have to use version 1.7 of git when
generating the tarball and signature -- I recall Greg having a similar
problem in the past.
Ugh, yes, that seems to be it. Current git generates different
tar-files than older releases do:
tar-1.7.9.7 tar-cur differ: byte 107, line 1
and a quick bisection shows that it is due to commit 10f343ea814f
(archive: honor tar.umask even for pax headers) in the current git
development version.
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 compatible. kernel.org has relied (for a
*long* time) on being able to just upload the signature of the
resulting tar-file, because both sides can generate the same tar-fiel
bit-for-bit.
So instead of using tar_umask, please make it use tar_pax_umask,
and have that default to 000. Ok?
Something like the attached patch.
Or just revert 10f343ea814f entirely.
Linus
From d5ca7ae0a34e31c48397f59b03ecabda7c5c40b2 Mon Sep 17 00:00:00 2001
From: Linus Torvalds torva...@linux-foundation.org
Date: Mon, 20 Oct 2014 08:21:38 -0700
Subject: [PATCH] Don't use the default 'tar.umask' for pax headers
That wasn't the original behavior, and doing so breaks the fact that
tar-files are bit-for-bit compatible across git versions.
If you really want to work around broken receiving tar implementations
(dubious, we've not needed to do so before), use [tar] paxumask in the
git config file. Or maybe we could expose some command line flag to do
so. But don't break existing format compatibility for dubious gains.
Signed-off-by: Linus Torvalds torva...@linux-foundation.org
---
archive-tar.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/archive-tar.c b/archive-tar.c
index df2f4c8a6437..40139ea4ee4e 100644
--- a/archive-tar.c
+++ b/archive-tar.c
@@ -14,6 +14,7 @@ static char block[BLOCKSIZE];
static unsigned long offset;
static int tar_umask = 002;
+static int tar_pax_umask = 000;
static int write_tar_filter_archive(const struct archiver *ar,
struct archiver_args *args);
@@ -192,7 +193,7 @@ static int write_extended_header(struct archiver_args *args,
unsigned int mode;
memset(header, 0, sizeof(header));
*header.typeflag = TYPEFLAG_EXT_HEADER;
- mode = 0100666 ~tar_umask;
+ mode = 0100666 ~tar_pax_umask;
sprintf(header.name, %s.paxheader, sha1_to_hex(sha1));
prepare_header(args, header, mode, size);
write_blocked(header, sizeof(header));
@@ -300,7 +301,7 @@ static int write_global_extended_header(struct archiver_args *args)
strbuf_append_ext_header(ext_header, comment, sha1_to_hex(sha1), 40);
memset(header, 0, sizeof(header));
*header.typeflag = TYPEFLAG_GLOBAL_HEADER;
- mode = 0100666 ~tar_umask;
+ mode = 0100666 ~tar_pax_umask;
strcpy(header.name, pax_global_header);
prepare_header(args, header, mode, ext_header.len);
write_blocked(header, sizeof(header));
@@ -374,6 +375,15 @@ static int git_tar_config(const char *var, const char *value, void *cb)
return 0;
}
+ if (!strcmp(var, tar.paxumask)) {
+ if (value !strcmp(value, user)) {
+ tar_pax_umask = umask(0);
+ } else {
+ tar_pax_umask = git_config_int(var, value);
+ }
+ return 0;
+ }
+
return tar_filter_config(var, value, cb);
}
--
2.1.2.330.g565301e
Re: [PATCH] t1304: Set LOGNAME even if USER is unset or null
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
extreme, i.e.
And I'm fine with this ;).
More importantly, what if none of the alternatives work? I
personally feel it is OK to punt and declare test_done early,
instead of giving false positive breakages like you saw without this
patch.
I can put this into a v2 if you like. Which conditional syntax do you
prefer?
Cheers,
Trevor
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
signature.asc
Description: OpenPGP digital signature
Re: [PATCH] object: make add_object_array_with_mode a static function
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: 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
Re: [PATCH] Copy mergetool bc3 as bc4
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 does
not exist and fail, and we must supply a copy as bc4 to prevent it?
It may feel somewhat strange to have to say mergetool --tool=bc3
when you know what you have is version 4 and not version 3, but in
that case, I wonder if there are reasons why calling both versions
just bc is a bad idea. And assuming that version 5 and later
would keep the same interface, we will not have to worry about that
I have version 7 why do I have to say 3? if we can go that route.
Perhaps version 2 and before are unusable as a mergetool backend or
something?
Signed-off-by: Olivier Croquette ocroque...@free.fr
---
mergetools/bc4 | 25 +
1 files changed, 25 insertions(+), 0 deletions(-)
create mode 100644 mergetools/bc4
diff --git a/mergetools/bc4 b/mergetools/bc4
new file mode 100644
index 000..b6319d2
--- /dev/null
+++ b/mergetools/bc4
@@ -0,0 +1,25 @@
+diff_cmd () {
+ $merge_tool_path $LOCAL $REMOTE
+}
+
+merge_cmd () {
+ touch $BACKUP
+ if $base_present
+ then
+ $merge_tool_path $LOCAL $REMOTE $BASE \
+ -mergeoutput=$MERGED
+ else
+ $merge_tool_path $LOCAL $REMOTE \
+ -mergeoutput=$MERGED
+ fi
+ check_unchanged
+}
+
+translate_merge_tool_path() {
+ if type bcomp /dev/null 2/dev/null
+ then
+ echo bcomp
+ else
+ echo bcompare
+ fi
+}
--
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
Re: [PATCH V2] core.filemode may need manual action
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 and then indented paragraph way, and need to unindent second and subsequent paragraphs, and have + before each of them, i.e. . |core.fileMode:: | Here is my first paragraph. |+ |Here is my second one. . That is how the existing The default is true, except... paragraph is done, and I was hoping that you would notice it and follow that example. I took your v2b and reformatted to follow the above; the result should be queued on 'pu'. 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
Re: [PATCH] object: make add_object_array_with_mode a static function
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, but please holler if I missed anything. I just checked it (using Thomas's excellent tbdiff tool) and you have everything. Thanks, and sorry for feeding it so piecemeal. :) -Peff -- 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
Re: [PATCH] doc: fix 'git status --help' character quoting
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. Some in the body text are already `XY` to match, but some others are not, and you are fixing them, all of which look good. Do you need me to add this to the commit message? Nah, it already mentions consistent; I was just double checking that I correctly understod consistency with what part of existing doc is achieved with the patch. 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 ascidoc) looked too much like an Oh, so I specially checked on the original .txt to see if it was correct there, which led me to the proposal for '00' in this case. I'd be just as happy with a single zero, as long as it's distinct from O (as you probably know, in the depths of hsitory typewriters didn't even have 0 and 1 keys - the O and l were used interchangably and many fonts keep too much to that pattern of undifferetiability!) Yes, and that is why I said there is no risk for anybody to mistake O (oh) as part of digits, whether you use decimal or hexadecimal. ;-) Note the more recent http://git-scm.com/docs/git-status has the formatted round o and 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.com/u/0/+JunioCHamano/posts/dzNXV2FwP6K (sorry for a URL to plus) https://www.kernel.org/pub/software/scm/git/docs/git-status.html (which IIUC is out of date) has an unformatted 0. -- 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
Re: [PATCH] Copy mergetool bc3 as bc4
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 auto-detect something and try to use bc4 which does
not exist and fail, and we must supply a copy as bc4 to prevent it?
It may feel somewhat strange to have to say mergetool --tool=bc3
when you know what you have is version 4 and not version 3, but in
that case, I wonder if there are reasons why calling both versions
just bc is a bad idea. And assuming that version 5 and later
would keep the same interface, we will not have to worry about that
I have version 7 why do I have to say 3? if we can go that route.
Perhaps version 2 and before are unusable as a mergetool backend or
something?
It seems that ffe6dc08 (mergetool--lib: Add Beyond Compare 3 as a
tool, 2011-02-27) is the first mention of Beyond Compare and it
only was interested in version 3 and nothing else.
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?
---
contrib/completion/git-completion.bash | 2 +-
git-mergetool--lib.sh | 2 +-
mergetools/{bc3 = bc} | 0
mergetools/bc3 | 26 +-
4 files changed, 3 insertions(+), 27 deletions(-)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index d548e99..01259cc 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1203,7 +1203,7 @@ _git_diff ()
}
__git_mergetools_common=diffuse diffmerge ecmerge emerge kdiff3 meld opendiff
- tkdiff vimdiff gvimdiff xxdiff araxis p4merge bc3
codecompare
+ tkdiff vimdiff gvimdiff xxdiff araxis p4merge bc
codecompare
_git_difftool ()
diff --git a/git-mergetool--lib.sh b/git-mergetool--lib.sh
index c45a020..1d8a26d 100644
--- a/git-mergetool--lib.sh
+++ b/git-mergetool--lib.sh
@@ -250,7 +250,7 @@ list_merge_tool_candidates () {
tools=opendiff kdiff3 tkdiff xxdiff meld $tools
fi
tools=$tools gvimdiff diffuse diffmerge ecmerge
- tools=$tools p4merge araxis bc3 codecompare
+ tools=$tools p4merge araxis bc bc3 codecompare
fi
case ${VISUAL:-$EDITOR} in
*vim*)
diff --git a/mergetools/bc3 b/mergetools/bc
similarity index 100%
rename from mergetools/bc3
rename to mergetools/bc
diff --git a/mergetools/bc3 b/mergetools/bc3
dissimilarity index 100%
index b6319d2..5d8dd48 100644
--- a/mergetools/bc3
+++ b/mergetools/bc3
@@ -1,25 +1 @@
-diff_cmd () {
- $merge_tool_path $LOCAL $REMOTE
-}
-
-merge_cmd () {
- touch $BACKUP
- if $base_present
- then
- $merge_tool_path $LOCAL $REMOTE $BASE \
- -mergeoutput=$MERGED
- else
- $merge_tool_path $LOCAL $REMOTE \
- -mergeoutput=$MERGED
- fi
- check_unchanged
-}
-
-translate_merge_tool_path() {
- if type bcomp /dev/null 2/dev/null
- then
- echo bcomp
- else
- echo bcompare
- fi
-}
+. $MERGE_TOOLS_DIR/bc
--
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
Please reply
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-info.html
Re: [PATCH] Copy mergetool bc3 as bc4
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 does
not exist and fail, and we must supply a copy as bc4 to prevent it?
The patch is indeed not needed, which is why I haven't cared to provide it so
far although I'm now using Beyond Compare 4 instead of version 3 myself.
It may feel somewhat strange to have to say mergetool --tool=bc3
when you know what you have is version 4 and not version 3, but in
That's exactly the only reason I could think of why it could be nice to have a
bc4.
that case, I wonder if there are reasons why calling both versions
just bc is a bad idea. And assuming that version 5 and later
IMHO, the only reason not to just have a single bc is to maintain backward
compatibility for users already using bc3. But for the sake of cleaner code,
personally I'd be fine with that minor backward compatibility breakage.
Perhaps version 2 and before are unusable as a mergetool backend or
something?
It seems that ffe6dc08 (mergetool--lib: Add Beyond Compare 3 as a
tool, 2011-02-27) is the first mention of Beyond Compare and it
only was interested in version 3 and nothing else.
Beyond Compare versions prior to 3 do not run on Linux, but only on Windows,
which is why I did not care to submit a patch.
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-mergetool--lib.sh
+++ b/git-mergetool--lib.sh
@@ -250,7 +250,7 @@ list_merge_tool_candidates () {
tools=opendiff kdiff3 tkdiff xxdiff meld $tools
fi
tools=$tools gvimdiff diffuse diffmerge ecmerge
- tools=$tools p4merge araxis bc3 codecompare
+ tools=$tools p4merge araxis bc bc3 codecompare
Why keep bc3 here?
And shouldn't we update git-gui/lib/mergetool.tcl, too?
--
Sebastian Schuberth
--
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
Re: Sources for 3.18-rc1 not uploaded
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 page still lists 3.17 as the latest mainline. Want to try again? Ok, tried again, and failed again. If that still doesn't work, you may have to use version 1.7 of git when generating the tarball and signature -- I recall Greg having a similar problem in the past. Ugh, yes, that seems to be it. Current git generates different tar-files than older releases do: tar-1.7.9.7 tar-cur differ: byte 107, line 1 and a quick bisection shows that it is due to commit 10f343ea814f (archive: honor tar.umask even for pax headers) in the current git development version. 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 compatible. kernel.org has relied (for a *long* time) on being able to just upload the signature of the resulting tar-file, because both sides can generate the same tar-fiel bit-for-bit. So instead of using tar_umask, please make it use tar_pax_umask, and have that default to 000. Ok? Something like the attached patch. Or just revert 10f343ea814f entirely. My preference for this particular one however is to simply revert it. I do not see much point in bending backwards to treat older implementations of tar that do not understand extended pax headers very specially by adding a separate option or configuration, even though I wouldn't have minded if the original implementation were to apply the same umask for these entries that look like dummy files to them. 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 compatibility, went unnoticed, though. What I am getting at is that correcting past mistakes in the output should not be forbidden unconditionally with a complaint like this. If 10f343ea were an important fix, then my preference would have been to instead add tar_ignore_umask_in_pax_header to allow those who care more about bit-for-bit compatibility with older broken versions than correctness to conditionally disable its code. But I do not think it is, so my preference isn't. 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
Re: [PATCH] t1304: Set LOGNAME even if USER is unset or null
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 with if/then/fi is obviously at the other
extreme, i.e.
And I'm fine with this ;).
More importantly, what if none of the alternatives work? I
personally feel it is OK to punt and declare test_done early,
instead of giving false positive breakages like you saw without this
patch.
I can put this into a v2 if you like. Which conditional syntax do you
prefer?
Probably
if test -z $LOGNAME
then
LOGNAME=${USER:-$(id -u -n)}
else
: cannot test acl operations without a usable user name
test_punt!
fi
--
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
Re: Sources for 3.18-rc1 not uploaded
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 compatibility, went unnoticed, though. What I am getting at is that correcting past mistakes in the output should not be forbidden unconditionally with a complaint like this. I think Greg actually ran into that one, and uses a separate 1.7 git tree for this reason. I can update our servers to git 2.1 (which most of them already have), which should help with previous incompatibilities -- but not the future ones obviously. :) -K -- 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
Re: [PATCH] Copy mergetool bc3 as bc4
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.
--- a/git-mergetool--lib.sh
+++ b/git-mergetool--lib.sh
@@ -250,7 +250,7 @@ list_merge_tool_candidates () {
tools=opendiff kdiff3 tkdiff xxdiff meld $tools
fi
tools=$tools gvimdiff diffuse diffmerge ecmerge
-tools=$tools p4merge araxis bc3 codecompare
+tools=$tools p4merge araxis bc bc3 codecompare
Why keep bc3 here?
I didn't carefully look at the code that uses this list to see if we
have to list everything or can list just the ones we recommend, and
erred on the safer side (unlike the one for completion where I
omitted bc3 as deprecated).
I'll let mergetools experts decide when rolling the final patch ;-)
And shouldn't we update git-gui/lib/mergetool.tcl, too?
Yes we should, but git-gui is not in my bailiwick, and shouldn't be
done relative to my tree anyway. I'll Cc this message to Pat.
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
Re: [PATCH v2 0/3] Allow building Git with Asciidoctor
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
Re: [PATCH] doc: fix 'git status --help' character quoting
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 specially formatted character (remember its quotation is consumed by ascidoc) looked too much like an Oh, so I specially checked on the original .txt to see if it was correct there, which led me to the proposal for '00' in this case. I'd be just as happy with a single zero, as long as it's distinct from O (as you probably know, in the depths of hsitory typewriters didn't even have 0 and 1 keys - the O and l were used interchangably and many fonts keep too much to that pattern of undifferetiability!) Yes, and that is why I said there is no risk for anybody to mistake O (oh) as part of digits, whether you use decimal or hexadecimal. ;-) Note the more recent http://git-scm.com/docs/git-status has the formatted round o and 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.com/u/0/+JunioCHamano/posts/dzNXV2FwP6K (sorry for a URL to plus) https://www.kernel.org/pub/software/scm/git/docs/git-status.html (which IIUC is out of date) has an unformatted 0. -- I've just had a look at how it formats when the zero is back-tick quoted s /ASCII 0/ASCII `0`/ and it looks OK with both Chromium and Firefox on my hack Ubuntu laptop - the character is colourised and full sized, and the --man page output looks unchanged and clearly a zero. my hacky attempt at an in-line patch (squash in?) below: -- Philip -8 commit 51ec35a196057eae60bb9285c38fb22e49aae1b0 Author: Philip Oakley philipoak...@iee.org Date: Mon Oct 20 20:21:56 2014 +0100 doc: 'git status' quote the zero (NUL) character Newer web rendering of 'git status --help --web' shows the zero in NUL (ASCII 0) as if it is a small 'o' character. Back-tick quote the zero to ensure it is displayed as a full size mono-spaced font. Signed-off-by: Philip Oakley philipoak...@iee.org diff --git a/Documentation/git-status.txt b/Documentation/git-status.txt index 4d8d530..379aa08 100644 --- a/Documentation/git-status.txt +++ b/Documentation/git-status.txt @@ -189,7 +189,7 @@ There is also an alternate -z format recommended for machine parsing. In that format, the status field is the same, but some other things change. First, the '\-' is omitted from rename entries and the field order is reversed (e.g 'from \- to' becomes 'to from'). Second, a NUL -(ASCII 0) follows each filename, replacing space as a field separator +(ASCII `0`) follows each filename, replacing space as a field separator and the terminating newline (but a space still separates the status field from the first filename). Third, filenames containing special characters are not specially formatted; no quoting or -- 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
Re: Sources for 3.18-rc1 not uploaded
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, 2013-01-05), which also should have broken bit-for-bit compatibility, went unnoticed, though. What I am getting at is that correcting past mistakes in the output should not be forbidden unconditionally with a complaint like this. I think Greg actually ran into that one, and uses a separate 1.7 git tree for this reason. I can update our servers to git 2.1 (which most of them already have), which should help with previous incompatibilities -- but not the future ones obviously. :) Updating to 2.1 will hopefully correct the change in v1.8.1.1~8^2, and will break Greg and friends who stick to 1.7 for that reason, though. The breakage in 10f343ea was only in the 'master' branch and upwards, which is not yet released in any tagged version, and I just reverted it from my tree, so people on the cutting edge will be okay in a short order. 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
Re: [PATCH] doc: fix 'git status --help' character quoting
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. https://plus.google.com/u/0/+JunioCHamano/posts/dzNXV2FwP6K (sorry for a URL to plus) https://www.kernel.org/pub/software/scm/git/docs/git-status.html (which IIUC is out of date) has an unformatted 0. -- I've just had a look at how it formats when the zero is back-tick quoted s /ASCII 0/ASCII `0`/ and it looks OK with both Chromium and Firefox on my hack Ubuntu laptop - the character is colourised and full sized, and the --man page output looks unchanged and clearly a zero. my hacky attempt at an in-line patch (squash in?) below: You'd need a matching change to 34 in the same document to preserve the consistency the original patch sought, though ;-) -- 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
NOTE:THIS IS YOUR PACKAGE REGISTERED CODE NO OVX950
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 reconfirm your full delivery information to the Agent Jerry cook right now as he is currently at J.F.K International Airport new York USA, you have to Email him with your Information, because he have be successful arrival with your ATM VISA CARD and also has already called me with his number on his arrival 4hours ago So contact him to deliver your ATM CARD first thing tomorrow morning possibly today Make sure the bellow stated codes are identified when contacting him and also ask him to give you his mobile phone number so that to be having easy conversation with him and to enable you give him your full direction to get your ATM CARD delivered to you and hand you over your ATM CARD safe and sound, Furthermore u are advice 2 be very fast as the Agent Jerry cook has no time to waste due to his flight ticket. so contact him now with the needed Information now From my office and tT56he director of the Company Rev. Dr. DOUGLAS MORRISON SHIPMENT CODE GJK72DWQ PACKAGE REGISTERED CODE NO OVX950. SECURITY CODE EYTU/3055WEZ/263/ TRANSACTION CODE 7126/JLFS/7138/17305/ CERTIFICATE DEPOSIT CODE MCBS/PQLE/2-6/41 Full Name= Mobile Phone Number City Nearest Airport === Country= Current Home Address his name is DIPLOMATIC Jerry Cook Email ;(diplomatjerrycook...@yahoo.com.ph) SINCERELY Rev. Dr. DOUGLAS MORRISON CALL ME AFTER GOING THROUGH THE EMAIL +229-9965 -1107 -- 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
Re: [PATCH] doc: fix 'git status --help' character quoting
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 consistent with how other digits are rendered. https://plus.google.com/u/0/+JunioCHamano/posts/dzNXV2FwP6K (sorry for a URL to plus) https://www.kernel.org/pub/software/scm/git/docs/git-status.html (which IIUC is out of date) has an unformatted 0. -- I've just had a look at how it formats when the zero is back-tick quoted s /ASCII 0/ASCII `0`/ and it looks OK with both Chromium and Firefox on my hack Ubuntu laptop - the character is colourised and full sized, and the --man page output looks unchanged and clearly a zero. my hacky attempt at an in-line patch (squash in?) below: You'd need a matching change to 34 in the same document to preserve the consistency the original patch sought, though ;-) Not that I think such a change makes much sense. If there was a way to force use of a font whose numerals and I/O are more clearly distinguishable and we do so for all HTML documents we generate, that would be a good change that is not limited to these places, though. -- 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
Re: [PATCH] Copy mergetool bc3 as bc4
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 feedback. This looks good to me. I used “bc4 just for consistency sake and to preserve backwards compatibility, but introducing “bc” as a generic backend looks indeed as a better approach. It’s even future safe, because it doesn’t prevent introducing bc5 if required later on. Olivier -- 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
please document --cached option to git-difftool
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 unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
What's cooking in git.git (Oct 2014, #05; Mon, 20)
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 as of today gives us a more or less complete picture, I would think. I'd like to ask area maintainers of git-svn, gitk and git-gui to please prepare to wrap up the accumulated changes for this cycle and throw a pull request to me. Thanks. You can find the changes described here in the integration branches of the repositories listed at http://git-blame.blogspot.com/p/git-public-repositories.html -- [Graduated to master] * bc/asciidoc (2014-10-13) 2 commits (merged to 'next' on 2014-10-14 at d9ff206) + Documentation: fix mismatched delimiters in git-imap-send + Documentation: adjust document title underlining (this branch is used by bc/asciidoctor.) Formatting nitpicks to help a (pickier) reimplementation of AsciiDoc to grok our documentation. * cc/interpret-trailers (2014-10-13) 11 commits (merged to 'next' on 2014-10-17 at ee4519c) + Documentation: add documentation for 'git interpret-trailers' + trailer: add tests for commands in config file + trailer: execute command from 'trailer.name.command' + trailer: add tests for git interpret-trailers + trailer: add interpret-trailers command + trailer: put all the processing together and print + trailer: parse trailers from file or stdin + trailer: process command line trailer arguments + trailer: read and process config information + trailer: process trailers from input message and arguments + trailer: add data structures and basic functions A new filter to programatically edit the tail end of the commit log messages. * jk/test-shell-trace (2014-10-13) 3 commits (merged to 'next' on 2014-10-14 at 9118506) + test-lib.sh: support -x option for shell-tracing + t5304: use helper to report failure of test foo = bar + t5304: use test_path_is_* instead of test -f (this branch is used by jk/prune-mtime.) Test scripts were taught to notice -x option to show shell trace, as if the tests were run under sh -x. * jn/parse-config-slot (2014-10-14) 2 commits (merged to 'next' on 2014-10-14 at 7f0a3ad) + color_parse: do not mention variable name in error message + pass config slots as pointers instead of offsets Code cleanup. * rm/gitweb-start-form (2014-10-16) 1 commit (merged to 'next' on 2014-10-17 at 7ca427f) + gitweb: use start_form, not startform that was removed in CGI.pm 4.04 * rs/receive-pack-argv-leak-fix (2014-10-13) 1 commit (merged to 'next' on 2014-10-14 at e64654d) + receive-pack: plug minor memory leak in unpack() * ss/contrib-subtree-contacts (2014-10-15) 2 commits (merged to 'next' on 2014-10-17 at 4b3a1d9) + contacts: add a Makefile to generate docs and install + subtree: add an install-html target * ta/config-set (2014-10-13) 1 commit (merged to 'next' on 2014-10-14 at ed660e4) + t1308: fix broken here document in test script -- [New Topics] * jk/pack-objects-no-bitmap-when-splitting (2014-10-19) 1 commit - pack-objects: turn off bitmaps when we split packs Splitting pack-objects output into multiple packs is incompatible with the use of reachability bitmap. Will merge to 'next'. * po/doc-status-markup (2014-10-19) 1 commit - doc: fix 'git status --help' character quoting Update documentation mark-up. Will merge to 'next'. * rs/run-command-env-array (2014-10-19) 2 commits - use env_array member of struct child_process - run-command: add env_array, an optional argv_array for env Add managed env array to child_process to clarify the lifetime rules. Will merge to 'next'. * tb/core-filemode-doc (2014-10-19) 1 commit - core.filemode may need manual action Doc update. Will merge to 'next'. * wk/t1304-wo-USER (2014-10-19) 1 commit - t1304: Set LOGNAME even if USER is unset or null Will merge to 'next'. -- [Stalled] * je/quiltimport-no-fuzz (2014-09-26) 2 commits - git-quiltimport: flip the default not to allow fuzz - git-quiltimport.sh: allow declining fuzz with --exact option quiltimport drove git apply always with -C1 option to reduce context of the patch in order to give more chance to somewhat stale patches to apply. Add an --exact option to disable, and also -C$n option to customize this behaviour. The top patch optionally flips the default to --exact. Waiting for an Ack. * tr/remerge-diff (2014-09-08) 8 commits - log --remerge-diff: show what the conflict resolution changed - name-hash: allow dir hashing even when !ignore_case - merge-recursive: allow storing conflict hunks in index - merge_diff_mode: fold all merge diff variants into an enum - combine-diff: do not pass
Re: Sources for 3.18-rc1 not uploaded
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 carefully, 2013-01-05), which also should have broken bit-for-bit compatibility, went unnoticed, though. What I am getting at is that correcting past mistakes in the output should not be forbidden unconditionally with a complaint like this. I think Greg actually ran into that one, and uses a separate 1.7 git tree for this reason. I used to have to do this for the 3.0-stable kernel as one of the files in it ran into the very long path problem. I just ran the latest version of git with that one commit reverted and all was fine. After 3.0 was done, I just dropped that patch from my local version and have been running with the latest git version of git with no problems. I can update our servers to git 2.1 (which most of them already have), which should help with previous incompatibilities -- but not the future ones obviously. :) I thought you already did this. Or was that only the public facing git servers? thanks, greg k-h -- 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
Re: Sources for 3.18-rc1 not uploaded
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 implementation produces bit-for-bit compatible output between versions. After all, look at all the contortions that Debian has had to go through to keep pristine-tar working. 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 compatible. kernel.org has relied (for a *long* time) on being able to just upload the signature of the resulting tar-file, because both sides can generate the same tar-fiel bit-for-bit. It sounds like kernel.org has a bug, then. Perhaps that's the appropriate place to fix the issue. The issue I fixed is that leaving world-writable files around on disk is a great way for people to cause mischief (for example, by filling up other users' quotas), and some tar implementations and all Linux pax implementations extract the pax headers into the working directory, and that's often /tmp. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: Sources for 3.18-rc1 not uploaded
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 between versions. The kernel has simple stability rules: if it breaks users, it gets fixed or reverted. That is a damn good rule. I realize that some other projects are crap, and don't care about their users. I hope and believe that git is not in that sad group. The whole it's not documented excuse is pure and utter bollocks. Users don't care. And stability of data should be *expected*, not need some random documentation entry to make it explicit. Linus -- 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
Re: Sources for 3.18-rc1 not uploaded
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 compatible. kernel.org has relied (for a *long* time) on being able to just upload the signature of the resulting tar-file, because both sides can generate the same tar-fiel bit-for-bit. It sounds like kernel.org has a bug, then. Perhaps that's the appropriate place to fix the issue. It's not a bug, it's a feature (TM). KUP relies on git-archive's ability to create identical tar archives across platforms and versions. The benefit is that Linus or Greg can create a detached PGP signature against a tarball created from git archive [tag] on their system, and just tell kup to create the same archive remotely, thus saving them the trouble of uploading 80Mb each time they cut a release. With their frequent travel to places where upload bandwidth is both slow and unreliable, this ability to not have to upload hundreds of Mbs each time they cut a release is very handy and certainly helps keep kernel releases on schedule. So, while it's fair to point out that git-archive was never intended to always create bit-for-bit identical outputs, it would be *very nice* if this remained in place, as at least one large-ish deployment (us) finds it really handy. -K signature.asc Description: OpenPGP digital signature
[PATCH] environment.c: add GIT_NAMESPACE to local_repo_env
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 traversal
stuff happens on the client side.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
.. looks like the right thing to do..
environment.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/environment.c b/environment.c
index 565f652..16628d3 100644
--- a/environment.c
+++ b/environment.c
@@ -100,6 +100,7 @@ const char * const local_repo_env[] = {
NO_REPLACE_OBJECTS_ENVIRONMENT,
GIT_PREFIX_ENVIRONMENT,
GIT_SHALLOW_FILE_ENVIRONMENT,
+ GIT_NAMESPACE_ENVIRONMENT,
NULL
};
--
2.0.2.841.g8f98430
--
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
[PATCH 1/2] transport: Free leaking head in transport_print_push_status
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 @@ -774,6 +774,7 @@ void transport_print_push_status(const char *dest, struct ref *refs, *reject_reasons |= REJECT_NEEDS_FORCE; } } + free(head); } void transport_verify_remote_names(int nr_heads, const char **heads) -- 2.1.2.332.g8071e93 -- 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
[PATCH 2/2] .mailmap: Add Stefan Bellers corporate mail address
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, 1 insertion(+) diff --git a/.mailmap b/.mailmap index 8aefb5a..bb6f52e 100644 --- a/.mailmap +++ b/.mailmap @@ -205,6 +205,7 @@ Shawn O. Pearce spea...@spearce.org Simon Hausmann hausm...@kde.org si...@lst.de Simon Hausmann hausm...@kde.org shaus...@trolltech.com Stefan Beller stefanbel...@gmail.com stefanbel...@googlemail.com +Stefan Beller stefanbel...@gmail.com sbel...@google.com Stefan Naewe stefan.na...@gmail.com stefan.na...@atlas-elektronik.com Stefan Naewe stefan.na...@gmail.com stefan.na...@googlemail.com Stefan Sperling s...@elego.de s...@stsp.name -- 2.1.2.332.g8071e93 -- 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
[PATCH] git-svn: clear global SVN pool between get_log invocations
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
using a test repository created with the script at the end of this
commit message.
As reported by time(1) on my x86-64 system:
before: 54024k
after: 47344k
-8--
set -e
tmp=$(mktemp -d svntestrepo-)
svnadmin create $tmp
repo=file://$(cd $tmp pwd)
svn co $repo $tmp/wd
cd $tmp/wd
if ! test -f a
then
a
svn add a
svn commit -m 'A'
fi
nr=1
while test $nr -gt 0
do
echo $nr a
svn commit -q -m A
nr=$((nr - 1))
done
echo repository created in $repo
-8--
Signed-off-by: Eric Wong normalper...@yhbt.net
---
Pushed to master of git://bogomips.org/git-svn
However, memory usage still seems to grow infinitely even in this simple
fetch case, so are other memory leaks.
perl/Git/SVN/Ra.pm | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/perl/Git/SVN/Ra.pm b/perl/Git/SVN/Ra.pm
index a7b0119..3df4591 100644
--- a/perl/Git/SVN/Ra.pm
+++ b/perl/Git/SVN/Ra.pm
@@ -237,10 +237,6 @@ sub trees_match {
my $ctx = SVN::Client-new(auth = _auth_providers);
my $out = IO::File-new_tmpfile;
- # older SVN (1.1.x) doesn't take $pool as the last parameter for
- # $ctx-diff(), so we'll create a default one
- my $pool = SVN::Pool-new_default_sub;
-
$ra_invalid = 1; # this will open a new SVN::Ra connection to $url1
$ctx-diff([], $url1, $rev1, $url2, $rev2, 1, 1, 0, $out, $out);
$out-flush;
@@ -453,6 +449,7 @@ sub gs_fetch_loop_common {
$_[0] = undef;
$self = undef;
$RA = undef;
+ SVN::Core-gpool-clear;
$self = Git::SVN::Ra-new($ra_url);
$ra_invalid = undef;
}
@@ -468,6 +465,7 @@ sub gs_fetch_loop_common {
my $k = svn-remote.$g-{remote}.$g-{t}-maxRev;
Git::SVN::tmp_config($k, $max);
}
+ SVN::Core-gpool-clear;
last if $max = $head;
$min = $max + 1;
$max += $inc;
--
EW
--
EW
--
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
Re: [PATCH 2/2] .mailmap: Add Stefan Bellers corporate mail address
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 interact with external open source projects using their corp address when working as new contributors, Googlers are also encouraged to keep using the same pre-corp address when working with projects they have been part of for continuity. After all, even if you send patches from your @gmail.com address while being employed by Google, the patches are copyright Google, not yours, and DCO (a) I have the right to submit covers your submissions just fine (i.e. it does not say I own the copyright), as long as you are cleared to contribute your patches to us by Google's open source office (which I happen to know that you have already done). The mailmap is primarily to correct past mistakes and document the new addresses of those who lost the old address to maintain their reachability. It is not about planning to send patches from two different addresses chosen by the phase of the moon or something. I do not terribly mind, but is this patch really necessary? Signed-off-by: Stefan Beller sbel...@google.com --- .mailmap | 1 + 1 file changed, 1 insertion(+) diff --git a/.mailmap b/.mailmap index 8aefb5a..bb6f52e 100644 --- a/.mailmap +++ b/.mailmap @@ -205,6 +205,7 @@ Shawn O. Pearce spea...@spearce.org Simon Hausmann hausm...@kde.org si...@lst.de Simon Hausmann hausm...@kde.org shaus...@trolltech.com Stefan Beller stefanbel...@gmail.com stefanbel...@googlemail.com +Stefan Beller stefanbel...@gmail.com sbel...@google.com Stefan Naewe stefan.na...@gmail.com stefan.na...@atlas-elektronik.com Stefan Naewe stefan.na...@gmail.com stefan.na...@googlemail.com Stefan Sperling s...@elego.de s...@stsp.name -- 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
[PATCH] grep: fix match highlighting for combined patterns with context lines
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
foo bar
baz bar foo
bar x
bar y
$ git grep -n -C2 -e foo --and -e bar testfile
testfile-1-*foo* a
testfile-2-*foo* b
testfile:3:*foo* *bar*
testfile:4:baz *bar* *foo*
testfile-5-*bar* x
testfile-6-*bar* y
Lines 1, 2, 5 and 6 do not match the combined patterns, they only
contain incorrectly highlighted 'false positives'.
Modify the show_line() function in grep.c to highlight matches only on
lines that match the combined pattern. Do not highlight matches on lines
that provide only context or contain only the function name of the match.
The output of the same command after the change:
$ git grep -n -C2 -e foo --and -e bar testfile
testfile-1-foo a
testfile-2-foo b
testfile:3:*foo* *bar*
testfile:4:baz *bar* *foo*
testfile-5-bar x
testfile-6-bar y
Signed-off-by: Zoltan Klinger zoltan.klin...@gmail.com
---
grep.c | 7 +++--
t/t7810-grep.sh | 90 +
2 files changed, 95 insertions(+), 2 deletions(-)
diff --git a/grep.c b/grep.c
index 4dc31ea..3c4d68e 100644
--- a/grep.c
+++ b/grep.c
@@ -1121,9 +1121,12 @@ static void show_line(struct grep_opt *opt, char *bol,
char *eol,
enum grep_context ctx = GREP_CONTEXT_BODY;
int ch = *eol;
int eflags = 0;
+ char *match_color = NULL;
- if (sign == ':')
+ if (sign == ':') {
line_color = opt-color_selected;
+ match_color = opt-color_match;
+ }
else if (sign == '-')
line_color = opt-color_context;
else if (sign == '=')
@@ -1136,7 +1139,7 @@ static void show_line(struct grep_opt *opt, char *bol,
char *eol,
output_color(opt, bol, match.rm_so, line_color);
output_color(opt, bol + match.rm_so,
match.rm_eo - match.rm_so,
-opt-color_match);
+match_color);
bol += match.rm_eo;
rest -= match.rm_eo;
eflags = REG_NOTBOL;
diff --git a/t/t7810-grep.sh b/t/t7810-grep.sh
index 40615de..b0d6b6f 100755
--- a/t/t7810-grep.sh
+++ b/t/t7810-grep.sh
@@ -1202,4 +1202,94 @@ test_expect_success LIBPCRE 'grep -P ^ ' '
test_cmp expected actual
'
+cat expected EOF
+space-line without leading space1
+space: line REDwith RESETleading space1
+space: line REDwith RESETleading REDspace2RESET
+space: line REDwith RESETleading space3
+space:line without leading REDspace2RESET
+EOF
+
+test_expect_success 'grep --color -e A -e B with context' '
+ test_config color.grep.context normal
+ test_config color.grep.filename normal
+ test_config color.grep.function normal
+ test_config color.grep.linenumber normal
+ test_config color.grep.matchred
+ test_config color.grep.selected normal
+ test_config color.grep.separatornormal
+
+ git grep --color=always -C2 -e with -e space2 space |
+ test_decode_color actual
+ test_cmp expected actual
+'
+
+cat expected EOF
+space-line without leading space1
+space- line with leading space1
+space: line REDwith RESETleading REDspace2RESET
+space- line with leading space3
+space-line without leading space2
+EOF
+
+test_expect_success 'grep --color -e A --and -e B with context' '
+ test_config color.grep.context normal
+ test_config color.grep.filename normal
+ test_config color.grep.function normal
+ test_config color.grep.linenumber normal
+ test_config color.grep.matchred
+ test_config color.grep.selected normal
+ test_config color.grep.separatornormal
+
+ git grep --color=always -C2 -e with --and -e space2 space |
+ test_decode_color actual
+ test_cmp expected actual
+'
+
+cat expected EOF
+space-line without leading space1
+space: line REDwith RESETleading space1
+space- line with leading space2
+space: line REDwith RESETleading space3
+space-line without leading space2
+EOF
+
+test_expect_success 'grep --color -e A --and --not -e B with context' '
+ test_config color.grep.context normal
+ test_config color.grep.filename normal
+ test_config color.grep.function normal
+ test_config color.grep.linenumber normal
+ test_config color.grep.matchred
+ test_config
