Re: Using socks proxy with git for http(s) transport
On Wed, Mar 06, 2013 at 09:12:30AM +0100, Yves Blusseau wrote: i have a socks proxy to access internet. I successed in configuring git (with GIT_PROXY_COMMAND) to use the socks proxy for GIT transport protocol. But how to use this socks proxy with git for HTTP(S) transport protocol ? Try: git config --global http.proxy 'socks://yourhost:port' That will enable it for all git repositories on your machine. Git should also respect any environment variables that curl handles (because we use libcurl under the hood), if you prefer to set it up that way. See man curl for details. -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] Extend runtime prefix computation
Hello Junio, On Tue, Mar 05, 2013 at 08:13:50AM -0800, Junio C Hamano wrote: Support determining the binaries' installation path at runtime even if called without any path components (i.e. via search path). The default for any change is not to include it. Is there any reason why we want this change? It makes a binary git installation fully relocatable. Seeing how git already has basic support for it I thought other people might be interested in this. Thanks, -- Michael Weiserscience + computing ag Senior Systems Engineer Geschaeftsstelle Duesseldorf Martinstrasse 47-55, Haus A phone: +49 211 302 708 32 D-40223 Duesseldorf fax: +49 211 302 708 50 www.science-computing.de -- Vorstandsvorsitzender/Chairman of the board of management: Gerd-Lothar Leonhart Vorstand/Board of Management: Dr. Bernd Finkbeiner, Michael Heinrichs, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Philippe Miltin Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 -- 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 1/4] commit.c: add clear_commit_marks_many()
On Tue, Mar 05, 2013 at 02:47:16PM -0800, Junio C Hamano wrote: clear_commit_marks(struct commit *, unsigned) only can clear flag bits starting from a single commit; introduce an API to allow feeding an array of commits, so that flag bits can be cleared from commits reachable from any of them with a single traversal. Out of curiosity, is that actually measurably more efficient? Since we stop traversing a commit's parents when we see it does not have any of the flags we are clearing, we should visit most commits once. The exception is ones that we hit by multiple paths. But that should be the same whether it is done as part of a single traversal or multiple; in each case, we hit the commit and say Oh, already cleared; do not add it to the parents list. So I would expect it to have little to no impact on performance. I still think it is a sane interface change; I was just curious from the commit message whether there could be a performance impact. -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/4] push --follow-tags
On Tue, Mar 05, 2013 at 02:47:15PM -0800, Junio C Hamano wrote: The primary change since the last round is that it pushes out only annotated tags that are missing from the other side. Like you, I have mixed feelings on treating annotated tags separately. I don't feel like the previous discussion actually came to a conclusion. I kind of lean towards the if we are pushing A..B to a ref, no matter if the remote had the objects already, consider any tag that peels to any commit in A..B. That seems intuitive to me, and reduces the chances of accidentally pushing crufty tags. But I admit it's just a gut feeling. I think the implementation would just be something like: for each ref we are pushing mark ref-old_sha1 as UNINTERESTING add ref-new_sha1 to pending traverse pending commits, marking SEEN for each local tag if tag does not exist on remote commit = lookup_commit_reference_gently(tag) commit-object.flags SEEN push tag -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: auto merge bug
On Tue, Mar 05, 2013 at 11:13:12PM +0100, David Krmpotic wrote: Hi guys! Thank you for responses.. I haven't suspected that repos created via GitHub windows app would have union set by default :( have to ask them about it.. it seems wrong to me… Here are the defaults for a windows repo created with GitHub for windows app: [...] # Custom for Visual Studio *.cs diff=csharp *.slnmerge=union *.csproj merge=union *.vbproj merge=union *.fsproj merge=union *.dbproj merge=union Yeah, I think defaulting to merge=union there is questionable. In an ideal world, the GitHub for Windows folks would ship a specialized merge helper for handling VS project files. It can be open-source and distributed separately for people who don't use GitHub, but they can integrate it seamlessly into the GitHub client. So everybody wins. I see you've already written to GitHub support; thanks. I'll make sure your issue gets routed to the right people, and I'll see if I can convince them to write the specialized tool. :) -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: Using socks proxy with git for http(s) transport
Try: git config --global http.proxy 'socks://yourhost:port' That will enable it for all git repositories on your machine. Git should also respect any environment variables that curl handles (because we use libcurl under the hood), if you prefer to set it up that way. See man curl for details. Thanks Jeff but it's not working. I use git 1.8.15 My socks proxy listen on my localhost at port 1080 so I do: git config --global http.proxy 'socks://127.0.0.1:1080' But when i try to talk with a git server with http protocol i have: GIT_TRACE=1 GIT_CURL_VERBOSE=1 git ls-remote http://git.kernel.org/pub/scm/git/git.git trace: built-in: git 'ls-remote' 'http://git.kernel.org/pub/scm/git/git.git' trace: run_command: 'git-remote-http' 'http://git.kernel.org/pub/scm/git/git.git' 'http://git.kernel.org/pub/scm/git/git.git' * Couldn't find host git.kernel.org in the .netrc file, using defaults * About to connect() to proxy 127.0.0.1 port 1080 * Trying 127.0.0.1... * connected * Connected to 127.0.0.1 (127.0.0.1) port 1080 GET http://git.kernel.org/pub/scm/git/git.git/info/refs?service=git-upload-pack HTTP/1.1 User-Agent: git/1.8.1.5 Host: git.kernel.org Accept: */* Accept-Encoding: gzip Proxy-Connection: Keep-Alive Pragma: no-cache * Empty reply from server * Connection #0 to host 127.0.0.1 left intact error: Empty reply from server while accessing http://git.kernel.org/pub/scm/git/git.git/info/refs?service=git-upload-pack fatal: HTTP request failed As you can see git connect to my socks proxy (Connected to 127.0.0.1 (127.0.0.1) port 1080) but seems to send the http request directly instead of a socks command. So it does'nt work :( Regards, Yves -- 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: Using socks proxy with git for http(s) transport
2013/3/6 Jeff King p...@peff.net:
Try:
git config --global http.proxy 'socks://yourhost:port'
That will enable it for all git repositories on your machine. Git should
also respect any environment variables that curl handles (because we use
libcurl under the hood), if you prefer to set it up that way. See man
curl for details.
-Peff
Also try setting ALL_PROXY environment variable that curl handle:
export ALL_PROXY='socks5://127.0.0.1:1080'
Work with curl:
curl -v
http://git.kernel.org/pub/scm/git/git.git/info/refs?service=git-upload-pack
* About to connect() to proxy 127.0.0.1 port 1080 (#0)
* Trying 127.0.0.1...
% Total% Received % Xferd Average Speed TimeTime Time Current
Dload Upload Total SpentLeft Speed
0 00 00 0 0 0 --:--:-- --:--:--
--:--:-- 0* 198
* 145
* 20
* 140
* Connected to 127.0.0.1 (127.0.0.1) port 1080 (#0)
GET /pub/scm/git/git.git/info/refs?service=git-upload-pack HTTP/1.1
User-Agent: curl/7.29.1-DEV
Host: git.kernel.org
Accept: */*
HTTP/1.1 200 OK
Server: nginx
Date: Wed, 06 Mar 2013 09:33:05 GMT
Content-Type: application/x-git-upload-pack-advertisement
Transfer-Encoding: chunked
Connection: keep-alive
Expires: Fri, 01 Jan 1980 00:00:00 GMT
Pragma: no-cache
Cache-Control: no-cache, max-age=0, must-revalidate
{ [data not shown]
But with git (without the http.proxy configuration in .gitconfig):
GIT_TRACE=1 GIT_CURL_VERBOSE=1 git clone
http://git.kernel.org/pub/scm/git/git.git
trace: built-in: git 'clone' 'http://git.kernel.org/pub/scm/git/git.git'
Cloning into 'git'...
trace: run_command: 'git-remote-http' 'origin'
'http://git.kernel.org/pub/scm/git/git.git'
* Couldn't find host git.kernel.org in the .netrc file, using defaults
* About to connect() to proxy 127.0.0.1 port 1080
* Trying 127.0.0.1... * connected
* Connected to 127.0.0.1 (127.0.0.1) port 1080
GET
http://git.kernel.org/pub/scm/git/git.git/info/refs?service=git-upload-pack
HTTP/1.1
User-Agent: git/1.8.1.5
Host: git.kernel.org
Accept: */*
Accept-Encoding: gzip
Proxy-Connection: Keep-Alive
Pragma: no-cache
* Empty reply from server
* Connection #0 to host 127.0.0.1 left intact
error: Empty reply from server while accessing
http://git.kernel.org/pub/scm/git/git.git/info/refs?service=git-upload-pack
fatal: HTTP request failed
Regards,
Yves
--
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: Using socks proxy with git for http(s) transport
On Wed, Mar 06, 2013 at 10:21:42AM +0100, Yves Blusseau wrote: Try: git config --global http.proxy 'socks://yourhost:port' That will enable it for all git repositories on your machine. Git should also respect any environment variables that curl handles (because we use libcurl under the hood), if you prefer to set it up that way. See man curl for details. Thanks Jeff but it's not working. Hmm. I just double-checked, and it works for me. I use git 1.8.15 I assume you mean 1.8.1.5 here. My socks proxy listen on my localhost at port 1080 so I do: git config --global http.proxy 'socks://127.0.0.1:1080' That looks right to me. But when i try to talk with a git server with http protocol i have: [...] * About to connect() to proxy 127.0.0.1 port 1080 * Trying 127.0.0.1... * connected * Connected to 127.0.0.1 (127.0.0.1) port 1080 GET http://git.kernel.org/pub/scm/git/git.git/info/refs?service=git-upload-pack HTTP/1.1 [...] * Empty reply from server If I set up a simple socks proxy with ssh, like: ssh -v -D 1080 my-ssh-host and run the same command, I get: * About to connect() to proxy localhost port 1080 (#0) * Trying 127.0.0.1... * SOCKS4 request granted. * Connected to localhost (127.0.0.1) port 1080 (#0) GET /pub/scm/git/git.git/info/refs?service=git-upload-pack HTTP/1.1 [...] HTTP/1.1 200 OK and it works. It does look like curl is treating localhost:1080 as a regular http proxy. What version of libcurl do you have? Is there anything in your environment that might be causing it to override the configured proxy setting (e.g., an http_proxy or https_proxy environment variable)? As you can see git connect to my socks proxy (Connected to 127.0.0.1 (127.0.0.1) port 1080) but seems to send the http request directly instead of a socks command. So it does'nt work :( Yeah, that definitely looks like the problem. -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: Using socks proxy with git for http(s) transport
2013/3/6 Jeff King p...@peff.net: On Wed, Mar 06, 2013 at 10:21:42AM +0100, Yves Blusseau wrote: Try: git config --global http.proxy 'socks://yourhost:port' That will enable it for all git repositories on your machine. Git should also respect any environment variables that curl handles (because we use libcurl under the hood), if you prefer to set it up that way. See man curl for details. Thanks Jeff but it's not working. Hmm. I just double-checked, and it works for me. I use git 1.8.15 I assume you mean 1.8.1.5 here. Yes it's 1.8.15 sorry for the mistake My socks proxy listen on my localhost at port 1080 so I do: git config --global http.proxy 'socks://127.0.0.1:1080' That looks right to me. But when i try to talk with a git server with http protocol i have: [...] * About to connect() to proxy 127.0.0.1 port 1080 * Trying 127.0.0.1... * connected * Connected to 127.0.0.1 (127.0.0.1) port 1080 GET http://git.kernel.org/pub/scm/git/git.git/info/refs?service=git-upload-pack HTTP/1.1 [...] * Empty reply from server If I set up a simple socks proxy with ssh, like: ssh -v -D 1080 my-ssh-host My socks proxy is also a socks proxy with ssh and run the same command, I get: * About to connect() to proxy localhost port 1080 (#0) * Trying 127.0.0.1... * SOCKS4 request granted. * Connected to localhost (127.0.0.1) port 1080 (#0) GET /pub/scm/git/git.git/info/refs?service=git-upload-pack HTTP/1.1 [...] HTTP/1.1 200 OK You have a (#0) in the log that i have when using curl directly with the socks proxy and it works. It does look like curl is treating localhost:1080 as a regular http proxy. What version of libcurl do you have? Is there anything in your environment that might be causing it to override the configured proxy setting (e.g., an http_proxy or https_proxy environment variable)? I have try with an old version of curl: 7.15.5 and with the latest in development curl 7.29.1-DEV. But it seem that git-remote-http is compile with the old one. I have no http/proxy environment variables -- 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
feature suggestion: improve rerere
Hello,
I think the following suggestion is sound. And it might even be easy to
implement but I don't know how rerere works, so I might be wrong here.
When applying a patch it's normal to hit a conflict. For me this just
happend:
$ git diff
diff --cc flash_otp_write.c
index f360a3e,648e042..000
--- a/flash_otp_write.c
+++ b/flash_otp_write.c
@@@ -15,8 -15,23 +15,29 @@@
#include mtd/mtd-user.h
++ ours
+#include common.h
+
++||| base
++===
+ ssize_t xread(int fd, void *buf, size_t count)
+ {
+ ssize_t ret, done = 0;
+
+ retry:
+ ret = read(fd, buf + done, count - done);
+ if (ret 0)
+ return ret;
+
+ done += ret;
+
+ if (ret == 0 /* EOF */ || done == count)
+ return done;
+ else
+ goto retry;
+ }
+
++ theirs
int main(int argc,char *argv[])
{
int fd, val, ret, size, wrote, len;
easy to resolve to:
$ git diff
diff --cc flash_otp_write.c
index f360a3e,648e042..000
--- a/flash_otp_write.c
+++ b/flash_otp_write.c
@@@ -15,8 -15,23 +15,25 @@@
#include mtd/mtd-user.h
+#include common.h
+
+ ssize_t xread(int fd, void *buf, size_t count)
+ {
+ ssize_t ret, done = 0;
+
+ retry:
+ ret = read(fd, buf + done, count - done);
+ if (ret 0)
+ return ret;
+
+ done += ret;
+
+ if (ret == 0 /* EOF */ || done == count)
+ return done;
+ else
+ goto retry;
+ }
+
int main(int argc,char *argv[])
{
int fd, val, ret, size, wrote, len;
Now if I shuffle patches and put the new patch before the conflicting
patch, I have to resolve first:
$ git diff
diff --cc flash_otp_write.c
index d407ebb,31b963e..000
--- a/flash_otp_write.c
+++ b/flash_otp_write.c
@@@ -15,6 -15,25 +15,31 @@@
#include mtd/mtd-user.h
++ ours
++||| base
++#include common.h
++
++===
+ #include common.h
+
+ ssize_t xread(int fd, void *buf, size_t count)
+ {
+ ssize_t ret, done = 0;
+
+ retry:
+ ret = read(fd, buf + done, count - done);
+ if (ret 0)
+ return ret;
+
+ done += ret;
+
+ if (ret == 0 /* EOF */ || done == count)
+ return done;
+ else
+ goto retry;
+ }
+
++ theirs
int main(int argc,char *argv[])
{
int fd, val, ret, size, wrote, len;
which is resolved to just adding the function and dropping the #include.
But then readding the 2nd patch it conflicts again:
$ git diff
diff --cc flash_otp_write.c
index 648e042,f360a3e..000
--- a/flash_otp_write.c
+++ b/flash_otp_write.c
@@@ -15,23 -15,8 +15,29 @@@
#include mtd/mtd-user.h
++ ours
+ssize_t xread(int fd, void *buf, size_t count)
+{
+ ssize_t ret, done = 0;
+
+retry:
+ ret = read(fd, buf + done, count - done);
+ if (ret 0)
+ return ret;
+
+ done += ret;
+
+ if (ret == 0 /* EOF */ || done == count)
+ return done;
+ else
+ goto retry;
+}
+
++||| base
++===
+ #include common.h
+
++ theirs
int main(int argc,char *argv[])
{
int fd, val, ret, size, wrote, len;
This is the same conflict as the first one, just with ours and theirs
exchanged. So my suggestion is to make rerere use the resolution
recorded for the first conflict here.
Sounds sensible?
Best regards
Uwe
PS: I'm using Debian's git 1.8.2~rc2-1 and hope I didn't miss this
feature already implemented while looking through v1.8.2..junio/next.
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/ |
--
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: Using socks proxy with git for http(s) transport
On Wed, 6 Mar 2013, Yves Blusseau wrote: I have try with an old version of curl: 7.15.5 and with the latest in development curl 7.29.1-DEV. But it seem that git-remote-http is compile with the old one. libcurl 7.15.5 is over 6 years old. The support for socks[*]:// prefixes in proxy names was added to libcurl 7.21.7 (June 23 2011). -- / daniel.haxx.se -- 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] format-patch: RFC 2047 says multi-octet character may not be split
Intro
-
In 'Subject:' characters are encoded in Q encoding, as per RFC 2047, e.g.
föö
becomes
=?UTF-8?q?f=C3=B6=C3=B6?=
. Long encoded lines must be wrapped to be no longer than 76 bytes.
Also RFC 2047, section 5 (3) says:
Each 'encoded-word' MUST represent an integral number of
characters. A multi-octet character may not be split across
adjacent 'encoded- word's.
that means that for
Subject: föö bar
encoding
Subject: =?UTF-8?q?=20f=C3=B6=C3=B6?=
=?UTF-8?q?=20bar?=
is correct, and
Subject: =?UTF-8?q?=20f=C3=B6=C3?= -- NOTE ö is broken here
=?UTF-8?q?=B6=20bar?=
is not, because ö character UTF-8 encoding C3 B6 is split here across
adjacent encoded words.
As it is now, format-patch does not respect multi-octet charactes may
not be split rule, and so sending patches with non-english subject has
issues:
The problematic case shows in mail readers as fö?? bar.
Solution
I introduce mbs_chrlen() function to compute character length in bytes
for multi-byte text according to encoding, and use it appropriately in
add_rfc2047() in pretty.
So far it works correctly only for UTF-8 encoding, because we have
infrastructure for it in place already, but other encoding could be
supported too in the future with the help of iconv. For now they all, except
UTF-8, are treated as being one-byte encodings, which was format-patch
current behaviour, with appropriate TODO put in mbs_chrlen().
Not sure whether mbs_chrlen() is a good name, but otherwise my
understanding is that the patch is ok to go in.
Thanks.
Cc: Jan H. Schönherr schn...@cs.tu-berlin.de
Signed-off-by: Kirill Smelkov k...@mns.spb.ru
---
pretty.c| 27 +++
t/t4014-format-patch.sh | 27 ++-
utf8.c | 39 +++
utf8.h | 2 ++
4 files changed, 74 insertions(+), 21 deletions(-)
diff --git a/pretty.c b/pretty.c
index b57adef..c9c7ff5 100644
--- a/pretty.c
+++ b/pretty.c
@@ -345,7 +345,7 @@ static int needs_rfc2047_encoding(const char *line, int len,
return 0;
}
-static void add_rfc2047(struct strbuf *sb, const char *line, int len,
+static void add_rfc2047(struct strbuf *sb, const char *line, size_t len,
const char *encoding, enum rfc2047_type type)
{
static const int max_encoded_length = 76; /* per rfc2047 */
@@ -355,9 +355,18 @@ static void add_rfc2047(struct strbuf *sb, const char
*line, int len,
strbuf_grow(sb, len * 3 + strlen(encoding) + 100);
strbuf_addf(sb, =?%s?q?, encoding);
line_len += strlen(encoding) + 5; /* 5 for =??q? */
- for (i = 0; i len; i++) {
- unsigned ch = line[i] 0xFF;
- int is_special = is_rfc2047_special(ch, type);
+
+ while (len) {
+ /*
+* RFC 2047, section 5 (3):
+*
+* Each 'encoded-word' MUST represent an integral number of
+* characters. A multi-octet character may not be split across
+* adjacent 'encoded- word's.
+*/
+ const unsigned char *p = (const unsigned char *)line;
+ int chrlen = mbs_chrlen(line, len, encoding);
+ int is_special = (chrlen 1) || is_rfc2047_special(*p, type);
/*
* According to RFC 2047, we could encode the special character
@@ -367,16 +376,18 @@ static void add_rfc2047(struct strbuf *sb, const char
*line, int len,
* causes ' ' to be encoded as '=20', avoiding this problem.
*/
- if (line_len + 2 + (is_special ? 3 : 1) max_encoded_length) {
+ if (line_len + 2 + (is_special ? 3*chrlen : 1)
max_encoded_length) {
strbuf_addf(sb, ?=\n =?%s?q?, encoding);
line_len = strlen(encoding) + 5 + 1; /* =??q? plus SP */
}
if (is_special) {
- strbuf_addf(sb, =%02X, ch);
- line_len += 3;
+ for (i = 0; i chrlen; i++) {
+ strbuf_addf(sb, =%02X, p[i]);
+ line_len += 3;
+ }
} else {
- strbuf_addch(sb, ch);
+ strbuf_addch(sb, *p);
line_len++;
}
}
diff --git a/t/t4014-format-patch.sh b/t/t4014-format-patch.sh
index 78633cb..b993dae 100755
--- a/t/t4014-format-patch.sh
+++ b/t/t4014-format-patch.sh
@@ -837,25 +837,26 @@ Subject: [PATCH]
=?UTF-8?q?f=C3=B6=C3=B6=20bar=20f=C3=B6=C3=B6=20bar=20f?=
=?UTF-8?q?=C3=B6=C3=B6=20bar=20f=C3=B6=C3=B6=20bar=20f=C3=B6=C3=B6=20bar?=
=?UTF-8?q?=20f=C3=B6=C3=B6=20bar=20f=C3=B6=C3=B6=20bar=20f=C3=B6=C3=B6=20?=
[PATCH v2 0/4] nd/branch-show-rebase-bisect-state updates
Since the previous round:
- reflog format change is dropped
- almost always show HEAD detached from/at xxx instead of
currently not on any branch, where xxx is either a ref, or an
abbreviated sha-1
I wanted to introduce something like @{-1:to} that resolves the to
sha-1 in reflog, in addition to @{-1} which resolves the from part.
But the syntax looks ugly so I dropped it. Meanwhile people could do
git log -1 -g --grep-reflog checkout --pretty=format:%h
to retrieve the same info.
Nguyễn Thái Ngọc Duy (4):
wt-status: split wt_status_state parsing function out
wt-status: move wt_status_get_state() out to wt_status_print()
status: show more info than currently not on any branch
branch: show more information when HEAD is detached
builtin/branch.c| 25 +++-
t/t3203-branch-output.sh| 6 +-
t/t6030-bisect-porcelain.sh | 2 +-
t/t7406-submodule-update.sh | 6 +-
t/t7512-status-help.sh | 52 +--
wt-status.c | 152 ++--
wt-status.h | 7 +-
7 files changed, 190 insertions(+), 60 deletions(-)
--
1.8.1.2.536.gf441e6d
--
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 v2 1/4] wt-status: split wt_status_state parsing function out
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
wt-status.c | 52 +++-
wt-status.h | 5 +++--
2 files changed, 34 insertions(+), 23 deletions(-)
diff --git a/wt-status.c b/wt-status.c
index ef405d0..183aafe 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -970,7 +970,7 @@ static void show_bisect_in_progress(struct wt_status *s,
* Extract branch information from rebase/bisect
*/
static void read_and_strip_branch(struct strbuf *sb,
- const char **branch,
+ char **branch,
const char *path)
{
unsigned char sha1[20];
@@ -994,52 +994,62 @@ static void read_and_strip_branch(struct strbuf *sb,
strbuf_addstr(sb, abbrev);
*branch = sb-buf;
} else if (!strcmp(sb-buf, detached HEAD)) /* rebase */
- ;
+ *branch = NULL;
else/* bisect */
*branch = sb-buf;
+ if (*branch)
+ *branch = xstrdup(*branch);
}
-static void wt_status_print_state(struct wt_status *s)
+void wt_status_get_state(struct wt_status_state *state)
{
- const char *state_color = color(WT_STATUS_HEADER, s);
struct strbuf branch = STRBUF_INIT;
struct strbuf onto = STRBUF_INIT;
- struct wt_status_state state;
struct stat st;
- memset(state, 0, sizeof(state));
+ memset(state, 0, sizeof(*state));
if (!stat(git_path(MERGE_HEAD), st)) {
- state.merge_in_progress = 1;
+ state-merge_in_progress = 1;
} else if (!stat(git_path(rebase-apply), st)) {
if (!stat(git_path(rebase-apply/applying), st)) {
- state.am_in_progress = 1;
+ state-am_in_progress = 1;
if (!stat(git_path(rebase-apply/patch), st)
!st.st_size)
- state.am_empty_patch = 1;
+ state-am_empty_patch = 1;
} else {
- state.rebase_in_progress = 1;
- read_and_strip_branch(branch, state.branch,
+ state-rebase_in_progress = 1;
+ read_and_strip_branch(branch, state-branch,
rebase-apply/head-name);
- read_and_strip_branch(onto, state.onto,
+ read_and_strip_branch(onto, state-onto,
rebase-apply/onto);
}
} else if (!stat(git_path(rebase-merge), st)) {
if (!stat(git_path(rebase-merge/interactive), st))
- state.rebase_interactive_in_progress = 1;
+ state-rebase_interactive_in_progress = 1;
else
- state.rebase_in_progress = 1;
- read_and_strip_branch(branch, state.branch,
+ state-rebase_in_progress = 1;
+ read_and_strip_branch(branch, state-branch,
rebase-merge/head-name);
- read_and_strip_branch(onto, state.onto,
+ read_and_strip_branch(onto, state-onto,
rebase-merge/onto);
} else if (!stat(git_path(CHERRY_PICK_HEAD), st)) {
- state.cherry_pick_in_progress = 1;
+ state-cherry_pick_in_progress = 1;
}
if (!stat(git_path(BISECT_LOG), st)) {
- state.bisect_in_progress = 1;
- read_and_strip_branch(branch, state.branch,
+ state-bisect_in_progress = 1;
+ read_and_strip_branch(branch, state-branch,
BISECT_START);
}
+ strbuf_release(branch);
+ strbuf_release(onto);
+}
+
+static void wt_status_print_state(struct wt_status *s)
+{
+ const char *state_color = color(WT_STATUS_HEADER, s);
+ struct wt_status_state state;
+
+ wt_status_get_state(state);
if (state.merge_in_progress)
show_merge_in_progress(s, state, state_color);
@@ -1051,8 +1061,8 @@ static void wt_status_print_state(struct wt_status *s)
show_cherry_pick_in_progress(s, state, state_color);
if (state.bisect_in_progress)
show_bisect_in_progress(s, state, state_color);
- strbuf_release(branch);
- strbuf_release(onto);
+ free(state.branch);
+ free(state.onto);
}
void wt_status_print(struct wt_status *s)
diff --git a/wt-status.h b/wt-status.h
index 81e1dcf..5ddcbf6 100644
--- a/wt-status.h
+++ b/wt-status.h
@@ -79,13 +79,14 @@ struct wt_status_state {
int rebase_interactive_in_progress;
int cherry_pick_in_progress;
int bisect_in_progress;
- const char *branch;
- const char *onto;
+ char *branch;
+ char *onto;
};
[PATCH v2 2/4] wt-status: move wt_status_get_state() out to wt_status_print()
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
wt-status.c | 37 +++--
1 file changed, 19 insertions(+), 18 deletions(-)
diff --git a/wt-status.c b/wt-status.c
index 183aafe..6a3566b 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -1044,31 +1044,29 @@ void wt_status_get_state(struct wt_status_state *state)
strbuf_release(onto);
}
-static void wt_status_print_state(struct wt_status *s)
+static void wt_status_print_state(struct wt_status *s,
+ struct wt_status_state *state)
{
const char *state_color = color(WT_STATUS_HEADER, s);
- struct wt_status_state state;
-
- wt_status_get_state(state);
-
- if (state.merge_in_progress)
- show_merge_in_progress(s, state, state_color);
- else if (state.am_in_progress)
- show_am_in_progress(s, state, state_color);
- else if (state.rebase_in_progress ||
state.rebase_interactive_in_progress)
- show_rebase_in_progress(s, state, state_color);
- else if (state.cherry_pick_in_progress)
- show_cherry_pick_in_progress(s, state, state_color);
- if (state.bisect_in_progress)
- show_bisect_in_progress(s, state, state_color);
- free(state.branch);
- free(state.onto);
+ if (state-merge_in_progress)
+ show_merge_in_progress(s, state, state_color);
+ else if (state-am_in_progress)
+ show_am_in_progress(s, state, state_color);
+ else if (state-rebase_in_progress ||
state-rebase_interactive_in_progress)
+ show_rebase_in_progress(s, state, state_color);
+ else if (state-cherry_pick_in_progress)
+ show_cherry_pick_in_progress(s, state, state_color);
+ if (state-bisect_in_progress)
+ show_bisect_in_progress(s, state, state_color);
}
void wt_status_print(struct wt_status *s)
{
const char *branch_color = color(WT_STATUS_ONBRANCH, s);
const char *branch_status_color = color(WT_STATUS_HEADER, s);
+ struct wt_status_state state;
+
+ wt_status_get_state(state);
if (s-branch) {
const char *on_what = _(On branch );
@@ -1087,7 +1085,10 @@ void wt_status_print(struct wt_status *s)
wt_status_print_tracking(s);
}
- wt_status_print_state(s);
+ wt_status_print_state(s, state);
+ free(state.branch);
+ free(state.onto);
+
if (s-is_initial) {
status_printf_ln(s, color(WT_STATUS_HEADER, s), );
status_printf_ln(s, color(WT_STATUS_HEADER, s), _(Initial
commit));
--
1.8.1.2.536.gf441e6d
--
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 v2 3/4] status: show more info than currently not on any branch
When a remote ref or a tag is checked out, HEAD is automatically detached. There is no user-friendly way to find out what ref is checked out in this case. This patch digs in reflog for this information and shows HEAD detached from origin/master or HEAD detached at v1.8.0 instead of currently not on any branch. When it cannot figure out the original ref, it shows an abbreviated SHA-1. Currently not on any branch would never display (unless reflog is pruned to near empty that the last checkout entry is lost). Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com --- t/t7406-submodule-update.sh | 6 ++-- t/t7512-status-help.sh | 52 +-- wt-status.c | 85 ++--- wt-status.h | 4 ++- 4 files changed, 121 insertions(+), 26 deletions(-) diff --git a/t/t7406-submodule-update.sh b/t/t7406-submodule-update.sh index 4975ec0..50ac020 100755 --- a/t/t7406-submodule-update.sh +++ b/t/t7406-submodule-update.sh @@ -664,8 +664,10 @@ test_expect_success 'submodule add properly re-creates deeper level submodules' test_expect_success 'submodule update properly revives a moved submodule' ' (cd super +H=$(git rev-parse --short HEAD) git commit -am pre move -git status expect +H2=$(git rev-parse --short HEAD) +git status | sed s/$H/XXX/ expect H=$(cd submodule2; git rev-parse HEAD) git rm --cached submodule2 rm -rf submodule2 @@ -674,7 +676,7 @@ test_expect_success 'submodule update properly revives a moved submodule' ' git config -f .gitmodules submodule.submodule2.path moved/sub module git commit -am post move git submodule update -git status actual +git status | sed s/$H2/XXX/ actual test_cmp expect actual ) ' diff --git a/t/t7512-status-help.sh b/t/t7512-status-help.sh index d2da89a..da22088 100755 --- a/t/t7512-status-help.sh +++ b/t/t7512-status-help.sh @@ -76,7 +76,7 @@ test_expect_success 'status when rebase in progress before resolving conflicts' ONTO=$(git rev-parse --short HEAD^^) test_must_fail git rebase HEAD^ --onto HEAD^^ cat expected -EOF - # Not currently on any branch. + # HEAD detached at $ONTO # You are currently rebasing branch '\''rebase_conflicts'\'' on '\''$ONTO'\''. # (fix conflicts and then run git rebase --continue) # (use git rebase --skip to skip this patch) @@ -103,7 +103,7 @@ test_expect_success 'status when rebase in progress before rebase --continue' ' echo three main.txt git add main.txt cat expected -EOF - # Not currently on any branch. + # HEAD detached at $ONTO # You are currently rebasing branch '\''rebase_conflicts'\'' on '\''$ONTO'\''. # (all conflicts fixed: run git rebase --continue) # @@ -135,7 +135,7 @@ test_expect_success 'status during rebase -i when conflicts unresolved' ' ONTO=$(git rev-parse --short rebase_i_conflicts) test_must_fail git rebase -i rebase_i_conflicts cat expected -EOF - # Not currently on any branch. + # HEAD detached at $ONTO # You are currently rebasing branch '\''rebase_i_conflicts_second'\'' on '\''$ONTO'\''. # (fix conflicts and then run git rebase --continue) # (use git rebase --skip to skip this patch) @@ -161,7 +161,7 @@ test_expect_success 'status during rebase -i after resolving conflicts' ' test_must_fail git rebase -i rebase_i_conflicts git add main.txt cat expected -EOF - # Not currently on any branch. + # HEAD detached at $ONTO # You are currently rebasing branch '\''rebase_i_conflicts_second'\'' on '\''$ONTO'\''. # (all conflicts fixed: run git rebase --continue) # @@ -187,9 +187,10 @@ test_expect_success 'status when rebasing -i in edit mode' ' export FAKE_LINES test_when_finished git rebase --abort ONTO=$(git rev-parse --short HEAD~2) + TGT=$(git rev-parse --short two_rebase_i) git rebase -i HEAD~2 cat expected -EOF - # Not currently on any branch. + # HEAD detached from $TGT # You are currently editing a commit while rebasing branch '\''rebase_i_edit'\'' on '\''$ONTO'\''. # (use git commit --amend to amend the current commit) # (use git rebase --continue once you are satisfied with your changes) @@ -214,8 +215,9 @@ test_expect_success 'status when splitting a commit' ' ONTO=$(git rev-parse --short HEAD~3) git rebase -i HEAD~3 git reset HEAD^ + TGT=$(git rev-parse --short HEAD) cat expected -EOF - # Not currently on any branch. + # HEAD detached at $TGT # You are currently splitting a commit while rebasing branch '\''split_commit'\'' on '\''$ONTO'\''. # (Once
[PATCH v2 4/4] branch: show more information when HEAD is detached
This prints more helpful info when HEAD is detached: is it detached
because of bisect or rebase? What is the original branch name in those
cases? Is it detached because the user checks out a remote ref or a
tag (and which one)?
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
builtin/branch.c| 25 -
t/t3203-branch-output.sh| 6 +++---
t/t6030-bisect-porcelain.sh | 2 +-
3 files changed, 28 insertions(+), 5 deletions(-)
diff --git a/builtin/branch.c b/builtin/branch.c
index 6371bf9..02dee0d 100644
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@ -18,6 +18,7 @@
#include string-list.h
#include column.h
#include utf8.h
+#include wt-status.h
static const char * const builtin_branch_usage[] = {
N_(git branch [options] [-r | -a] [--merged | --no-merged]),
@@ -550,6 +551,28 @@ static int calc_maxwidth(struct ref_list *refs)
return w;
}
+static char *get_head_description()
+{
+ struct strbuf desc = STRBUF_INIT;
+ struct wt_status_state state;
+ wt_status_get_state(state, 1);
+ if (state.rebase_in_progress ||
+ state.rebase_interactive_in_progress)
+ strbuf_addf(desc, _((no branch, rebasing %s)),
+ state.branch);
+ else if (state.bisect_in_progress)
+ strbuf_addf(desc, _((no branch, bisecting %s)),
+ state.branch);
+ else if (state.detached_from)
+ strbuf_addf(desc, _((detached from %s)),
+ state.detached_from);
+ else
+ strbuf_addstr(desc, _((no branch)));
+ free(state.branch);
+ free(state.onto);
+ free(state.detached_from);
+ return strbuf_detach(desc, NULL);
+}
static void show_detached(struct ref_list *ref_list)
{
@@ -557,7 +580,7 @@ static void show_detached(struct ref_list *ref_list)
if (head_commit is_descendant_of(head_commit,
ref_list-with_commit)) {
struct ref_item item;
- item.name = xstrdup(_((no branch)));
+ item.name = get_head_description();
item.width = utf8_strwidth(item.name);
item.kind = REF_LOCAL_BRANCH;
item.dest = NULL;
diff --git a/t/t3203-branch-output.sh b/t/t3203-branch-output.sh
index 76fe7e0..ba4f98e 100755
--- a/t/t3203-branch-output.sh
+++ b/t/t3203-branch-output.sh
@@ -94,13 +94,13 @@ test_expect_success 'git branch -v pattern does not show
branch summaries' '
test_must_fail git branch -v branch*
'
-cat expect 'EOF'
-* (no branch)
+test_expect_success 'git branch shows detached HEAD properly' '
+ cat expect EOF
+* (detached from $(git rev-parse --short HEAD^0))
branch-one
branch-two
master
EOF
-test_expect_success 'git branch shows detached HEAD properly' '
git checkout HEAD^0
git branch actual
test_i18ncmp expect actual
diff --git a/t/t6030-bisect-porcelain.sh b/t/t6030-bisect-porcelain.sh
index 3e0e15f..9b6f0d0 100755
--- a/t/t6030-bisect-porcelain.sh
+++ b/t/t6030-bisect-porcelain.sh
@@ -164,7 +164,7 @@ test_expect_success 'bisect start: existing
.git/BISECT_START not modified if
cp .git/BISECT_START saved
test_must_fail git bisect start $HASH4 foo --
git branch branch.output
- test_i18ngrep * (no branch) branch.output /dev/null
+ test_i18ngrep * (no branch, bisecting other) branch.output
/dev/null
test_cmp saved .git/BISECT_START
'
test_expect_success 'bisect start: no .git/BISECT_START if mistaken rev' '
--
1.8.1.2.536.gf441e6d
--
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 v2 0/4] nd/branch-show-rebase-bisect-state updates
Since the previous round:
- reflog format change is dropped
- almost always show HEAD detached from/at xxx instead of
currently not on any branch, where xxx is either a ref, or an
abbreviated sha-1
I wanted to introduce something like @{-1:to} that resolves the to
sha-1 in reflog, in addition to @{-1} which resolves the from part.
But the syntax looks ugly so I dropped it. Meanwhile people could do
git log -1 -g --grep-reflog checkout --pretty=format:%h
to retrieve the same info.
Nguyễn Thái Ngọc Duy (4):
wt-status: split wt_status_state parsing function out
wt-status: move wt_status_get_state() out to wt_status_print()
status: show more info than currently not on any branch
branch: show more information when HEAD is detached
builtin/branch.c| 25 +++-
t/t3203-branch-output.sh| 6 +-
t/t6030-bisect-porcelain.sh | 2 +-
t/t7406-submodule-update.sh | 6 +-
t/t7512-status-help.sh | 52 +--
wt-status.c | 152 ++--
wt-status.h | 7 +-
7 files changed, 190 insertions(+), 60 deletions(-)
--
1.8.1.2.536.gf441e6d
--
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] help: show manpage for aliased command on git alias --help
Jeff King venit, vidit, dixit 05.03.2013 18:38: On Tue, Mar 05, 2013 at 02:44:41PM +, Ævar Arnfjörð Bjarmason wrote: Change the semantics of git alias --help to show the help for the command alias is aliased to, instead of just saying: `git alias' is aliased to `whatever' E.g. if you have checkout aliased to co you won't get: $ git co --help `git co' is aliased to `checkout' But will instead get the manpage for git-checkout. The behavior this is replacing was originally added by Jeff King in 2156435. I'm changing it because of this off-the-cuff comment on IRC: 14:27:43 @Tux git can be very unhelpful, literally: 14:27:46 @Tux $ git co --help 14:27:46 @Tux `git co' is aliased to `checkout' 14:28:08 @Tux I know!, gimme the help for checkout, please And because I also think it makes more sense than showing you what the thing is aliased to. In this simple case, I think it is helpful to show the checkout manpage, because there is no other information to give (and by showing the checkout manpage, you implicitly indicate that co maps to checkout). Well, even in the simple case one has to wonder: Why does the user invoke help for co? There are two very likely cases: A) User does not remember what co is aliased to. B) User wants to see the man page. If A is not the case then it's easy for the user to request help for checkout (or commit or ...). Removing the only easy way to look up the definition of an alias is a major regression. And no, git config --get alias.co is not an easy way. Removing that easy way would be OK only after introducing a git alias command which works similar to shell's alias. You can even set it up as an alias for git config, of course. But like others, I am concerned about the other cases, where there is no manpage, it is not a git command with a manpage, or it is a git command with options. You are losing useful information that is currently given to the user in all but the single-word case. In an ideal world, we could say here is how the alias expands, and by the way, here is the manpage for the expanded command. And obviously just omit the latter part when there is no such page. But we are relying on external programs to do the presentation and paging. Doing the C equivalent of: echo 'git co' is aliased to 'checkout' man checkout does not quite work, because man will start a pager. We can run our own pager (which should suppress man's invocation), but that is a regression for anyone who uses MANPAGER. The user may also be using help.format to use something besides man. If help.format is set to html, we will spawn a browser. In that case we can still output the alias information, but it may or may not be seen (though come to think of it, that is probably already a problem for git help alias on Windows systems, or anybody invoking git help from a GUI porcelain). So I'd only be in favor of this patch if it managed to avoid information loss in the more complicated cases. And I'm not sure how best to do that. The only trigger for a single-word alias suggestion seems like the least ugly to me. -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
Splitting config.txt
We discussed this before about adding configuration variables into
individual command man pages [1]. This may be a step towards
that. With this, I could add selected configuration variables to
git-push.txt, for example, with a simple patch:
-- 8 --
diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index 1398025..c130c90 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -348,6 +348,13 @@ you are certain that nobody in the meantime fetched your
earlier commit A
overwrite it. In other words, git push --force is a method reserved for
a case where you do mean to lose history.
+CONFIGURATION
+-
+
+include::config/push.default.txt[]
+include::config/remote.name.pushurl.txt[]
+include::config/remote.name.push.txt[]
+
Examples
-- 8 --
I know it makes man pages longer (and more intimidating for new
users), but the point is we could select just important keys for each
man page, instead of all keys affecting the command.
I don't post the final patch that splits config.txt, just the script I
use to split it. You can try it yourself. It puts each config key into
a file under Documentation/config, with some characters mangled to be
more fs friendly. Run it inside Documentation/. generated git-config.1
is the same after the split.
-- 8 --
#!/usr/bin/perl
sub extract {
my ($line) = @_;
open CC, config/$filename || die failed to open config/$filename;
foreach $l (@lines[($start - 1)..($line - 2)]) {
$l =~ s/^include::/include::..\//;
print CC $l;
}
close CC;
print C include::config/$filename . []\n;
}
open C, config.txt || die failed to open config.txt;
our @lines = C;
close C;
our $start = 0;
our $filename;
open F, grep -n '^[a-z].*::\$' config.txt| || die failed to grep;
open C, config.txt.new || die unable to open config.txt.new;
while (F) {
chomp;
$_ =~ m/([^:]*):(.*)/;
my $line = $1;
my $name = $2;
$name =~ s/\*/_/g;
$name =~ s///g;
$name =~ s///g;
$name =~ s/::$//;
$name = http.speedLimit if $name eq http.lowSpeedLimit,
http.lowSpeedTime;
$name = gitcvs.userpass if $name eq gitcvs.dbuser, gitcvs.dbpass;
next if $line - $start == 1;
if ($start 0) {
extract $line;
} else {
foreach $l (@lines[0..($line-2)]) {
print C $l;
}
}
$start = $line;
$filename = $name . .txt;
}
extract $#lines + 2;
close C;
system mv config.txt.new config.txt;
-- 8 --
[1] http://thread.gmane.org/gmane.comp.version-control.git/206780/focus=206939
--
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
feature suggestion: optimize common parts for checkout --conflict=diff3
Hello, Here comes another recipe for a different suggestion: git init echo 1 file git add file git commit -m 'base' git branch branch seq 1 30 | grep -v 15 file git commit -m 'add 2-30 without 15' file git checkout branch seq 1 30 | grep -v 16 file git commit -m 'add 2-30 without 16' file git merge master git diff This yields: diff --cc file index a07e697,5080129..000 --- a/file +++ b/file @@@ -12,7 -12,7 +12,11 @@@ 12 13 14 ++ HEAD +15 ++=== + 16 ++ master 17 18 19 as expected; nice and sweet. After git checkout --conflict=diff3 file however the difference isn't that easy to spot any more. I expected diff --cc file index a07e697,5080129..000 --- a/file +++ b/file @@@ -12,7 -12,7 +12,12 @@@ 12 13 14 ++ ours +15 ++||| base ++=== + 16 ++ theirs 17 18 19 But instead I get diff --cc file index a07e697,5080129..000 --- a/file +++ b/file @@@ -1,29 -1,29 +1,61 @@@ 1 ++ ours +2 +3 +4 +5 +6 +7 +8 +9 +10 +11 +12 +13 +14 +15 +17 +18 +19 +20 +21 +22 +23 +24 +25 +26 +27 +28 +29 +30 ++||| base ++=== + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 + 10 + 11 + 12 + 13 + 14 + 16 + 17 + 18 + 19 + 20 + 21 + 22 + 23 + 24 + 25 + 26 + 27 + 28 + 29 + 30 ++ theirs Of course this is technically correct, just not maximally helpful. Is this a missing optimisation for the diff3 case or did I miss a detail that makes my expectation wrong? Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ | -- 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 1/4] commit.c: add clear_commit_marks_many()
Jeff King p...@peff.net writes: On Tue, Mar 05, 2013 at 02:47:16PM -0800, Junio C Hamano wrote: clear_commit_marks(struct commit *, unsigned) only can clear flag bits starting from a single commit; introduce an API to allow feeding an array of commits, so that flag bits can be cleared from commits reachable from any of them with a single traversal. Out of curiosity, is that actually measurably more efficient? Since we stop traversing a commit's parents when we see it does not have any of the flags we are clearing, we should visit most commits once. The exception is ones that we hit by multiple paths. But that should be the same whether it is done as part of a single traversal or multiple; in each case, we hit the commit and say Oh, already cleared; do not add it to the parents list. So I would expect it to have little to no impact on performance. I still think it is a sane interface change; I was just curious from the commit message whether there could be a performance impact. I agree that the log message should end with with a single API call. to clarify that this is more about eliminating the code overhead (the caller having to loop over an array of things) than about runtime overhead. -- 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/4] push --follow-tags
Jeff King p...@peff.net writes: On Tue, Mar 05, 2013 at 02:47:15PM -0800, Junio C Hamano wrote: The primary change since the last round is that it pushes out only annotated tags that are missing from the other side. Like you, I have mixed feelings on treating annotated tags separately. I don't feel like the previous discussion actually came to a conclusion. I kind of lean towards the if we are pushing A..B to a ref,... I rejected that approach when I started writing the initial round of this topic, primarily because A (i.e. dst_ref-old_sha1) may not necessarily be what the current pusher pushed out during his last push. The criteria for the tip of a branch to be good enough to be pushed out and the criteria for a commit to be good enough to be tagged are different. You may know that a commit together with the history behind it is solid and may be sure that you will not have to rewind beyond that commit---that is when you _can_ push out (you do not have to, and I usually don't, so this is not a problem for me personally). But at that point in time, you may still not know if the commit and the history behind it is the good point to be tagged for a release, or you would still need some other commits on top to polish other areas for the tagged release is complete. As I made a habit of not pushing anything out if I am planning to tag in a near future (and my tagged commits are ones designed to be tagged, not just an ordinary commit that happens to be tagged), it is not a problem for me, but it would be for centralized workflow people, where there is more pressure to publish a commit as early as possible. Once you know the commit is good enough so that you do not anticipate that it will need to be rewound, you want to push it out so that you can unblock others who want to build on it. It is plausible to see: (1) The pumpking pushes 'master' after being satisfied the correctness of the history that leads to it. The pumpking hasn't decided if the commit is to be tagged, or needs some other commits on top, for the next release. But he prefers to push the current state out so that he can unblock other people. (2) Another committer pulls and pushes with his changes. (3) The pumpking tags what he pushed out with (1), attempts a push, fails the ff check, pulls (2) and then pushes the result out with push --follow-tags. -- 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] add: Clarify documentation of -A and -u
Greg Price pr...@mit.edu writes: diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt index 388a225..f89d920 100644 --- a/Documentation/git-add.txt +++ b/Documentation/git-add.txt @@ -105,7 +105,9 @@ apply to the index. See EDITING PATCHES below. will never stage new files, but that it will stage modified new contents of tracked files and that it will remove files from the index if the corresponding files in the working tree - have been removed. + have been removed. By contrast `-A` will add new files as + well as updating and removing existing ones, and the default + behavior will add new files and will not remove existing ones. + If no pathspec is given, the current version of Git defaults to .; in other words, update all tracked files in the current directory I do not know if mentioning what -A does in the description for -u (and vice versa) makes it easier to understand or more confusing (not rhetorical: I suspect some may find it easier and others not). But and the default behaviour will... here _is_ confusing. After reading this patch three times, I still cannot tell what default you are trying to describe. Is it -u without arguments? Is it add without -u nor -A? Is it something else??? Exactly the same comment applies to the other hunk. Having said that, I agree that the current description for -u is way suboptimal. It begins like this: -u:: --update:: Only match pathspec against already tracked files in the index rather than the working tree. That means that it will ... Whenever you see an incomprehensible technobabble followed by That means, In other words, etc., you (not limited to Greg-you but figuratively everybody) should see if it makes it easier to read to remove everything up to that That means and adding a bit more to the remainder. In this particular case, the technobabble is not even correct---matching is only a small part of what add -u does to find what to add. I would suggest rewriting the first part of -u perhaps like this: -u:: --update:: Update modified and/or removed paths in the index that match pathspec with the current state of the working tree files. No new path is added because this considers only the paths that are already in the index. The text for -A may look like this: -A:: --all:: Update the index to record the current state of the working tree files that match pathspec. Note that new paths will be added to the index, in addition to modified and/or removed paths. I agree with your patch that If no pathspec is given should be repeated for both -u and -A. @@ -114,10 +116,17 @@ of Git, hence the form without pathspec should not be used. -A:: --all:: - Like `-u`, but match pathspec against files in the - working tree in addition to the index. That means that it - will find new files as well as staging modified content and - removing files that are no longer in the working tree. + Update the index regarding all files that match pathspec, + either in the index or the working tree. That is, remove + files that are only in the index, add files that are only in + the working tree, and update files that differ between the + two. By contrast `-u` only removes and updates, and the + default behavior only adds and updates. ++ +If no pathspec is given, the current version of Git defaults to +.; in other words, update all tracked files in the current directory +and its subdirectories. This default will change in a future version +of Git, hence the form without pathspec should not be used. -N:: --intent-to-add:: -- 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] git-push.txt: mention about remote.*.push when no refspec is given
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes: remote.*.push is considered before push.default, but there's no mention about that, except a bit in the examples. The description of push.default does say something about this, but it would be easier to find out if it's described here. The first paragraph describing refspec format is moved down, so that the new first paragraph is about unspsecified refspec and the remaining paragraphs refspec format. Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com --- Documentation/git-push.txt | 17 ++--- 1 file changed, 10 insertions(+), 7 deletions(-) diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt index 1398025..20bf2f5 100644 --- a/Documentation/git-push.txt +++ b/Documentation/git-push.txt @@ -33,13 +33,16 @@ OPTIONS[[OPTIONS]] of a remote (see the section REMOTES,REMOTES below). refspec...:: - The format of a refspec parameter is an optional plus - `+`, followed by the source ref src, followed - by a colon `:`, followed by the destination ref dst. - It is used to specify with what src object the dst ref - in the remote repository is to be updated. If not specified, - the behavior of the command is controlled by the `push.default` - configuration variable. + Specify how how refs are pushed. If not specified and + configuration variable `remote.remote.push` is set, the + variable is used as default refspec. If not specified and the + variable is not set, the behavior of the command is controlled + by the `push.default` configuration variable. ++ +The format of a refspec parameter is an optional plus `+`, followed +by the source ref src, followed by a colon `:`, followed by the +destination ref dst. It is used to specify with what src object +the dst ref in the remote repository is to be updated. I agree that saying what it is, what it does or what it is for upfront (i.e. Specifies what are pushed) before how it is spelled is an improvement. I however think describing If not specified here was a mistake, and you are making it worse by burying the description of what happens when refspec... are missing in the middle of the description for refspec... I would rather see this done in the direction the attached how about doing it this way patch illustrates. The way how where and what are determined when the command line does not specify is the proparty of the entire command, not of an individual parameter. Documentation/git-push.txt | 23 ++- 1 file changed, 14 insertions(+), 9 deletions(-) diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt index 1398025..31dad19 100644 --- a/Documentation/git-push.txt +++ b/Documentation/git-push.txt @@ -23,6 +23,17 @@ You can make interesting things happen to a repository every time you push into it, by setting up 'hooks' there. See documentation for linkgit:git-receive-pack[1]. +When the user does not specify where to push with +repository argument, branch.*.remote configuration for the current +branch is consulted to determine where to push. If the +configuration is missing, it defaults to 'origin'. + +When the user does not specify what to push with +refspec... arguments or --all/--mirror/--tags options, the command finds +the default refspec by consulting remote.*.push configuration, and +if it is not found, honors push.default configuration to decide what +to push (See gitlink:git-config[1] for the meaning of push.default). + OPTIONS[[OPTIONS]] -- @@ -33,13 +44,10 @@ OPTIONS[[OPTIONS]] of a remote (see the section REMOTES,REMOTES below). refspec...:: + Specify what destination ref to update with what source object. The format of a refspec parameter is an optional plus - `+`, followed by the source ref src, followed + `+`, followed by the source object src, followed by a colon `:`, followed by the destination ref dst. - It is used to specify with what src object the dst ref - in the remote repository is to be updated. If not specified, - the behavior of the command is controlled by the `push.default` - configuration variable. + The src is often the name of the branch you would want to push, but it can be any arbitrary SHA-1 expression, such as `master~4` or @@ -66,10 +74,7 @@ the remote repository. The special refspec `:` (or `+:` to allow non-fast-forward updates) directs Git to push matching branches: for every branch that exists on the local side, the remote side is updated if a branch of the same name -already exists on the remote side. This is the default operation mode -if no explicit refspec is found (that is neither on the command line -nor in any Push line of the corresponding remotes file---see below) and -no `push.default` configuration variable is set. +already exists on the remote side. --all:: Instead of naming each ref to push,
Re: Merging submodules - best merge-base
On Mon, Feb 25, 2013 at 05:44:05PM +0100, Daniel Bratell wrote: I can phrase this in two ways and I'll start with the short way: Why does a merge of a git submodule use as merge-base the commit that was active in the merge-base of the parent repo, rather than the merge-base of the two commits that are being merged? The long question is: A submodule change can be merged, but only if the merge is a fast-forward which I think is a fair demand, but currently it checks if it's a fast-forward from a commit that might not be very interesting anymore. If two branches A and B split at a point when they used submodule commit S1 (based on S), and both then switched to S2 (also based on S) and B then switched to S21, then it's today not possible to merge B into A, despite S21 being a descendant of S2 and you get a conflict and this warning: warning: Failed to merge submodule S (commits don't follow merge-base) (attempt at ASCII gfx: Submodule tree: S S1 \ \ - S2 -- S21 Main tree: A' (uses S1) --- A (uses S2) \ \ --- B' (uses S2) -- B (uses S21) I would like it to end up as: A' (uses S1) --- A (uses S2) A+ (uses S21) \ / \ --- B' (uses S2) -- B (uses S21)- / And that should be legal since S21 is a descendant of S2. So to summarize what you are requesting: You want a submodule merge be two way in the view of the superproject and calculate the merge base in the submodule from the two commits that are going to be merged? It currently sounds logical but I have to think about it further and whether that might break other use cases. Cheers Heiko -- 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: feature suggestion: optimize common parts for checkout --conflict=diff3
git checkout --conflict=diff3 file
That's somehow unrelated, but shouldn't we have a conflict option to
git-merge as we have for git-checkout ?
With something like this (pasted into gmail):
diff --git a/builtin/merge.c b/builtin/merge.c
index 7c8922c..edad742 100644
--- a/builtin/merge.c
+++ b/builtin/merge.c
@@ -65,6 +65,7 @@ static int abort_current_merge;
static int show_progress = -1;
static int default_to_upstream;
static const char *sign_commit;
+static char *conflict_style;
static struct strategy all_strategy[] = {
{ recursive, DEFAULT_TWOHEAD | NO_TRIVIAL },
@@ -213,6 +214,7 @@ static struct option builtin_merge_options[] = {
{ OPTION_STRING, 'S', gpg-sign, sign_commit, N_(key id),
N_(GPG sign commit), PARSE_OPT_OPTARG, NULL, (intptr_t) },
OPT_BOOLEAN(0, overwrite-ignore, overwrite_ignore, N_(update
ignored files (default))),
+ OPT_STRING(0, conflict, conflict_style, N_(style), N_(conflict
style (merge or diff3))),
OPT_END()
};
@@ -1102,6 +1104,9 @@ int cmd_merge(int argc, const char **argv, const
char *prefix)
if (verbosity 0 show_progress == -1)
show_progress = 0;
+ if (conflict_style)
+ git_xmerge_config(merge.conflictstyle, conflict_style, NULL);
+
if (abort_current_merge) {
int nargc = 2;
const char *nargv[] = {reset, --merge, NULL};
--
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 1/4] wt-status: split wt_status_state parsing function out
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
wt-status.c | 52 +++-
wt-status.h | 5 +++--
2 files changed, 34 insertions(+), 23 deletions(-)
diff --git a/wt-status.c b/wt-status.c
index ef405d0..183aafe 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -970,7 +970,7 @@ static void show_bisect_in_progress(struct wt_status *s,
* Extract branch information from rebase/bisect
*/
static void read_and_strip_branch(struct strbuf *sb,
- const char **branch,
+ char **branch,
const char *path)
{
unsigned char sha1[20];
@@ -994,52 +994,62 @@ static void read_and_strip_branch(struct strbuf *sb,
strbuf_addstr(sb, abbrev);
*branch = sb-buf;
} else if (!strcmp(sb-buf, detached HEAD)) /* rebase */
- ;
+ *branch = NULL;
else/* bisect */
*branch = sb-buf;
+ if (*branch)
+ *branch = xstrdup(*branch);
}
The reason why the original print_state() kept two strbufs in it was
because its use of the return value (in *branch) from this function
was private and it did not want to have to strdup anything.
With this change, I suspect that it is much saner to make this
function *not* take any external strbuf as input, because you are
always returning a piece of memory that belongs to the caller, or a
NULL.
In other words, with the new world order, wouldn't a saner function
signature be:
static const char *read_and_strip_branch(const char **path);
after this patch?
Also I notice that the error-return cases of this function may be
wrong even before your patch. Shouldn't it be doing *branch = NULL
(and 'return NULL' after the suggested change)?
--
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 I want rebase to do
This is how I see what rebase should do: The simple case for rebase starts from P---Q---R---S master \ A---B---C topic Then git checkout topic ; git rebase master will change it to P---Q---R---S master \ A'--B'--C' topic A' is created by a three-way merge that can be symbolized Q--S | | v v A--A' That is, Q, applying the changes from Q to A and the changes from Q to S, becomes A'. After that A--A' | | v v B--B' | | v v C--C' A more complex case is when there is a merge from an external source P---Q---R---S master \ A---M---C topic / ---X We want to produce P---Q---R---S master \ A'--M'--C' topic / ---X So we have to merge Q--S | | v v A--A' | | v v M--M' | | v v C--C' Any evil changes in M will be in the changes A-M (along with the changes introduced from X), and so they will be reincorporated in A'-M'. M' lists A' and X as its parents. (And not M!) If there is an internal merge in the topic branch, things look like this P---Q---R---S master \ \ B \ / \ A M---D topic \ / C and we want to produce this P---Q---R---S master \ \B' \ / \ A'M'--D' topic \ / C' Which can be done with these merges Q--S | | v v A--A'A--A' | | | | v v v v B--B'C--C' There are two choices for constructing M' (which ought to produce the same results under ordinary circumstances) B--B'C--C' | | | | v v v v M--M'M--M' and finally M--M' | | v v D--D' Dale -- 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 3/4] status: show more info than currently not on any branch
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
+static void wt_status_get_detached_from(struct wt_status_state *state)
+{
+ struct grab_1st_switch_cbdata cb;
+ struct commit *commit;
+ unsigned char sha1[20];
+ char *ref = NULL;
+
+ strbuf_init(cb.buf, 0);
+ if (for_each_recent_reflog_ent(HEAD, grab_1st_switch, 4096, cb))
+ for_each_reflog_ent(HEAD, grab_1st_switch, cb);
+ if (!cb.buf.len)
+ return;
Is this correct? What if the recent entries (i.e. the tail 4k) of
the HEAD reflog did not have *any* checkout? Your callback never
returns non-zero, so as long as the HEAD reflog is sufficiently
long, for_each_recent_reflog_ent() will return 0 to signal success,
and you do not dig deeper by retrying the full reflog for HEAD,
missing the checkout that exists before the final 4k, no?
It should be more like this, I would think:
for_each_recent_reflog_ent();
if (!found)
for_each_reflog_ent();
if (!found)
return;
Using cb.buf.len as the found marker may be correct, but I found
it a bit subtle to my taste, without explanation. Adding an
explicit bit to struct grab_1st_switch_cbdata would be cleaner and
more resistant to future changes, I think.
+
+ if (dwim_ref(cb.buf.buf, cb.buf.len, sha1, ref) == 1
+ (commit = lookup_commit_reference_gently(sha1, 1)) != NULL
+ !hashcmp(cb.nsha1, commit-object.sha1)) {
That feels unnecessarily expensive. Why not hashcmp before checking
the type of the object to reject the case where the ref moved since
the last checkout early?
For that matter, does this even need to check the type of the object
that currently sits at the ref? Isn't it sufficient to reject this
case by seeing if sha1 is the same as cb.nsha1?
--
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: feature suggestion: optimize common parts for checkout --conflict=diff3
however the difference isn't that easy to spot any more. I expected diff --cc file index a07e697,5080129..000 --- a/file +++ b/file @@@ -12,7 -12,7 +12,12 @@@ 12 13 14 ++ ours +15 ++||| base ++=== + 16 ++ theirs 17 18 19 This is not correct, it would mean that 12, 13, 14, 17, 18, 19 are in base, while they are not. Cheers, Antoine -- 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: feature suggestion: optimize common parts for checkout --conflict=diff3
On Wed, Mar 06, 2013 at 08:26:57PM +0100, Antoine Pelisse wrote:
however the difference isn't that easy to spot any more. I expected
diff --cc file
index a07e697,5080129..000
--- a/file
+++ b/file
@@@ -12,7 -12,7 +12,12 @@@
12
13
14
++ ours
+15
++||| base
++===
+ 16
++ theirs
17
18
19
This is not correct, it would mean that 12, 13, 14, 17, 18, 19 are in
base, while they are not.
Yeah, I agree it is a bit of a lie, as you are not seeing the full
picture of what was in the base. That is why we intentionally dial down
the conflict simplification level when using diff3. If you apply this
patch to git:
diff --git a/xdiff/xmerge.c b/xdiff/xmerge.c
index 9e13b25..f381e0c 100644
--- a/xdiff/xmerge.c
+++ b/xdiff/xmerge.c
@@ -420,15 +420,6 @@ static int xdl_do_merge(xdfenv_t *xe1, xdchange_t *xscr1,
int style = xmp-style;
int favor = xmp-favor;
- if (style == XDL_MERGE_DIFF3) {
- /*
-* diff3 -m output does not make sense for anything
-* more aggressive than XDL_MERGE_EAGER.
-*/
- if (XDL_MERGE_EAGER level)
- level = XDL_MERGE_EAGER;
- }
-
c = changes = NULL;
while (xscr1 xscr2) {
then it will produce the output that Uwe expects. While it can be
misleading, I also think it can make some conflicts (like this one) much
easier to understand. I don't see any reason we can't have a zealous
diff3 mode to let people view this output, as long as it is not the
default.
-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
[PATCH] xdiff: implement a zealous diff3
zdiff3 is identical to ordinary diff3, only it allows more aggressive
compaction than diff3. This way the displayed base isn't necessary
technically correct, but still this mode might help resolving merge
conflicts between two near identical additions.
Signed-off-by: Uwe Kleine-König u.kleine-koe...@pengutronix.de
---
Hello,
this patch implements what I want. Thanks to Jeff for pointing me to the
right code to modify.
Best regards
Uwe
builtin/merge-file.c | 2 ++
contrib/completion/git-completion.bash | 2 +-
xdiff-interface.c | 2 ++
xdiff/xdiff.h | 1 +
xdiff/xmerge.c | 8 +++-
5 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/builtin/merge-file.c b/builtin/merge-file.c
index c0570f2..4ef86aa 100644
--- a/builtin/merge-file.c
+++ b/builtin/merge-file.c
@@ -32,6 +32,8 @@ int cmd_merge_file(int argc, const char **argv, const char
*prefix)
struct option options[] = {
OPT_BOOLEAN('p', stdout, to_stdout, N_(send results to
standard output)),
OPT_SET_INT(0, diff3, xmp.style, N_(use a diff3 based
merge), XDL_MERGE_DIFF3),
+ OPT_SET_INT(0, zdiff3, xmp.style, N_(use a zealous diff3
based merge),
+ XDL_MERGE_ZEALOUS_DIFF3),
OPT_SET_INT(0, ours, xmp.favor, N_(for conflicts, use our
version),
XDL_MERGE_FAVOR_OURS),
OPT_SET_INT(0, theirs, xmp.favor, N_(for conflicts, use
their version),
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index b62bec0..a0d887e 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1091,7 +1091,7 @@ _git_checkout ()
case $cur in
--conflict=*)
- __gitcomp diff3 merge ${cur##--conflict=}
+ __gitcomp diff3 merge zdiff3 ${cur##--conflict=}
;;
--*)
__gitcomp
diff --git a/xdiff-interface.c b/xdiff-interface.c
index ecfa05f..a911c25 100644
--- a/xdiff-interface.c
+++ b/xdiff-interface.c
@@ -308,6 +308,8 @@ int git_xmerge_config(const char *var, const char *value,
void *cb)
die('%s' is not a boolean, var);
if (!strcmp(value, diff3))
git_xmerge_style = XDL_MERGE_DIFF3;
+ else if (!strcmp(value, zdiff3))
+ git_xmerge_style = XDL_MERGE_ZEALOUS_DIFF3;
else if (!strcmp(value, merge))
git_xmerge_style = 0;
else
diff --git a/xdiff/xdiff.h b/xdiff/xdiff.h
index 219a3bb..9730c63 100644
--- a/xdiff/xdiff.h
+++ b/xdiff/xdiff.h
@@ -64,6 +64,7 @@ extern C {
/* merge output styles */
#define XDL_MERGE_DIFF3 1
+#define XDL_MERGE_ZEALOUS_DIFF3 2
typedef struct s_mmfile {
char *ptr;
diff --git a/xdiff/xmerge.c b/xdiff/xmerge.c
index 9e13b25..4772707 100644
--- a/xdiff/xmerge.c
+++ b/xdiff/xmerge.c
@@ -177,7 +177,7 @@ static int fill_conflict_hunk(xdfenv_t *xe1, const char
*name1,
size += xdl_recs_copy(xe1, m-i1, m-chg1, 1,
dest ? dest + size : NULL);
- if (style == XDL_MERGE_DIFF3) {
+ if (style == XDL_MERGE_DIFF3 || style == XDL_MERGE_ZEALOUS_DIFF3) {
/* Shared preimage */
if (!dest) {
size += marker_size + 1 + marker3_size;
@@ -420,6 +420,12 @@ static int xdl_do_merge(xdfenv_t *xe1, xdchange_t *xscr1,
int style = xmp-style;
int favor = xmp-favor;
+ /*
+* This is the only change between XDL_MERGE_DIFF3 and
+* XDL_MERGE_ZEALOUS_DIFF3. zdiff3 isn't 100% technically correct (as
+* the base might be considerably simplified), but still it might help
+* interpreting conflicts between two big and near identical additions.
+*/
if (style == XDL_MERGE_DIFF3) {
/*
* diff3 -m output does not make sense for anything
--
1.8.2.rc2
--
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: feature suggestion: optimize common parts for checkout --conflict=diff3
Jeff King p...@peff.net writes: then it will produce the output that Uwe expects. While it can be misleading,... Misleading is one thing but in this case isn't it outright wrong? If you remove ours ||| portion from the combined diff output, I would expect that the hunk will apply to the base, but that is no longer true, no? -- 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] xdiff: implement a zealous diff3
On Wed, Mar 06, 2013 at 09:36:42PM +0100, Uwe Kleine-König wrote: zdiff3 is identical to ordinary diff3, only it allows more aggressive compaction than diff3. This way the displayed base isn't necessary technically correct, but still this mode might help resolving merge conflicts between two near identical additions. Signed-off-by: Uwe Kleine-König u.kleine-koe...@pengutronix.de I think the patch is correct, assuming this is the interface we want. It would be more flexible instead to have: 1. user can configure zealous-level of merge via command-line or config (they cannot control it at all right now) 2. when diff3 is used and no level is explicitly given, do not go above EAGER 3. otherwise, respect the level given by the user, even if it is ZEALOUS But that would involve a lot of refactoring. I don't know if it is worth the effort (the bonus is that people can then set the level independently, but I do not know that anyone ever wants to do that). builtin/merge-file.c | 2 ++ contrib/completion/git-completion.bash | 2 +- xdiff-interface.c | 2 ++ xdiff/xdiff.h | 1 + xdiff/xmerge.c | 8 +++- 5 files changed, 13 insertions(+), 2 deletions(-) I think this would need documentation not only to let users know about the feature, but also to warn them of the caveats. -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: feature suggestion: optimize common parts for checkout --conflict=diff3
On Wed, Mar 06, 2013 at 12:40:48PM -0800, Junio C Hamano wrote: Jeff King p...@peff.net writes: then it will produce the output that Uwe expects. While it can be misleading,... Misleading is one thing but in this case isn't it outright wrong? If you remove ours ||| portion from the combined diff output, I would expect that the hunk will apply to the base, but that is no longer true, no? It shifts the concept of what is the base and what is the conflict. In Uwe's example, no, it would not apply to the single-line file that is the true 3-way base. But it would apply to the content that is outside of the hunk marker; we have changed the concept of what is in the base and what is in the conflict by shrinking the conflict to its smallest size. The same is true of the conflict markers produced in the non-diff3 case. It is a property of XDL_MERGE_ZEALOUS, not of the conflict style. If your argument is diff3 means something different than regular conflict markers; it should have the property of being machine-convertible into a patch, but regular markers do not, I'm not sure I agree. It may be used that way, but I think it is mostly used in git to give the reader more context when making a resolution. And anyway, I think the proposed change would not be to change diff3, but to introduce a new diff3-like format that also shrinks the hunk size, so it would not hurt existing users of diff3. -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
[PATCH 2/2] p4merge: create a virtual base if none available
Originally, with no base, Git gave P4Merge $LOCAL as a dummy base:
p4merge $LOCAL $LOCAL $REMOTE $MERGED
Commit 0a0ec7bd changed this to:
p4merge empty file $LOCAL $REMOTE $MERGED
to avoid the problem of being unable to save in some circumstances.
Unfortunately this approach does not produce good results at all on
differing inputs. P4Merge really regards the blank file as the base, and
once you have just a couple of differences between the two branches you
end up with one a massive full-file conflict. The diff is not readable,
and you have to invoke difftool MERGE_HEAD HEAD manually to see a
2-way diff.
The original form appears to have invoked special 2-way comparison
behaviour that occurs only if the base filename is or equal to the
left input. You get a good diff, and it does not auto-resolve in one
direction or the other. (Normally if one branch equals the base, it
would autoresolve to the other branch).
But there appears to be no way of getting this 2-way behaviour and being
able to reliably save. Having base=left appears to be triggering other
assumptions. There are tricks the user can use to force the save icon
on, but it's not intuitive.
So we now follow a suggestion given in the original patch's discussion:
generate a virtual base, consisting of the lines common to the two
branches. It produces a much nicer 3-way diff view than either of the
original forms, and than I suspect other mergetools are managing.
Signed-off-by: Kevin Bracey ke...@bracey.fi
---
git-mergetool--lib.sh | 14 ++
mergetools/p4merge| 2 +-
2 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/git-mergetool--lib.sh b/git-mergetool--lib.sh
index e338be5..5b60cf5 100644
--- a/git-mergetool--lib.sh
+++ b/git-mergetool--lib.sh
@@ -108,6 +108,20 @@ check_unchanged () {
fi
}
+make_virtual_base() {
+ # Copied from git-merge-one-file.sh.
+ # This starts with $LOCAL, and uses git apply to
+ # remove lines that are not in $REMOTE.
+ cp -- $LOCAL $BASE
+ sz0=`wc -c $BASE`
+ @@DIFF@@ -u -La/$BASE -Lb/$BASE $BASE $REMOTE | git
apply --no-add
+ sz1=`wc -c $BASE`
+
+ # If we do not have enough common material, it is not
+ # worth trying two-file merge using common subsections.
+ expr $sz0 \ $sz1 \* 2 /dev/null || : $BASE
+}
+
valid_tool () {
setup_tool $1 return 0
cmd=$(get_merge_tool_cmd $1)
diff --git a/mergetools/p4merge b/mergetools/p4merge
index 46b3a5a..f0a893b 100644
--- a/mergetools/p4merge
+++ b/mergetools/p4merge
@@ -21,7 +21,7 @@ diff_cmd () {
merge_cmd () {
touch $BACKUP
- $base_present || $BASE
+ $base_present || make_virtual_base
$merge_tool_path $BASE $REMOTE $LOCAL $MERGED
check_unchanged
}
--
1.8.2.rc2.5.g1a80410.dirty
--
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: feature suggestion: optimize common parts for checkout --conflict=diff3
Jeff King p...@peff.net writes: But it would apply to the content that is outside of the hunk marker; we have changed the concept of what is in the base and what is in the conflict by shrinking the conflict to its smallest size. Hmm, unless you mean by base something entirely different from what was in the common ancestor version, I do not think I can agree. The point of diff3 mode is to show how it looked line in the common ancestor and what the conflicting sides want to change that common version into; letting the user view three versions to help him decide what to do by only looking at the part inside conflict markers. We show both sides added, either identically or differently as noteworthy events, but the patched code pushes both sides added identically case outside the conflicting hunk, as if what was added relative to the common ancestor version (in Uwe's case, is it 1-14 that is common, or just 10-14?) is not worth looking at when considering what the right resolution is. If it is not worth looking at what was in the original for the conflicting part, why would we be even using diff3 mode in the first place? -- 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: feature suggestion: optimize common parts for checkout --conflict=diff3
On Wed, Mar 06, 2013 at 01:09:41PM -0800, Junio C Hamano wrote: Jeff King p...@peff.net writes: But it would apply to the content that is outside of the hunk marker; we have changed the concept of what is in the base and what is in the conflict by shrinking the conflict to its smallest size. Hmm, unless you mean by base something entirely different from what was in the common ancestor version, I do not think I can agree. I don't know. I didn't use the word base in the first place. I was trying to figure out what you meant. :) My point is that the hunk (everything from to ) is self-consistent. It's just misleading in that the hunk has been shrunk not to include identical bits from each side. IMHO, this is not much different than a nearby change being auto-resolved. The conflict hunks the user sees do not represent the original files, but rather the remains after a first pass at resolving. The point of diff3 mode is to show how it looked line in the common ancestor and what the conflicting sides want to change that common version into; letting the user view three versions to help him decide what to do by only looking at the part inside conflict markers. Right, I agree. We show both sides added, either identically or differently as noteworthy events, but the patched code pushes both sides added identically case outside the conflicting hunk, as if what was added relative to the common ancestor version (in Uwe's case, is it 1-14 that is common, or just 10-14?) is not worth looking at when considering what the right resolution is. If it is not worth looking at what was in the original for the conflicting part, why would we be even using diff3 mode in the first place? I think Uwe's example shows that it _is_ useful. Yes, you no longer have the information about what happened through 1-14 (whether it was really there in the ancestor file, or whether it was simply added identically). But that information might or might not be relevant. In Uwe's example, it is just noise that detracts from the interesting part of the change (or does it? I think the answer is in the eye of the reader). I think it can be helpful to have both types available, and they can pick which one they want; it's just another tool. Another argument is that some people (including me) set merge.conflictstyle to diff3, because they like seeing the extra context when resolving (I find it helps a lot with rebasing, when it is sometimes hard to remember which side is which in the merge). I'd consider setting it to zdiff3 to get the benefits of XDL_MERGE_ZEALOUS, and using git checkout --conflict-style=diff3 if I need to get more information about a specific case. -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
[PATCH 1/2] p4merge: swap LOCAL and REMOTE for mergetool
Reverse LOCAL and REMOTE when invoking P4Merge as a mergetool, so that
the incoming branch is now in the left-hand, blue triangle pane, and the
current branch is in the right-hand, green circle pane.
This change makes use of P4Merge consistent with its built-in help, its
reference documentation, and Perforce itself. But most importantly, it
makes merge results clearer. P4Merge is not totally symmetrical between
left and right; despite changing a few text labels from theirs/ours to
left/right when invoked manually, it still retains its original
Perforce theirs/ours viewpoint.
Most obviously, in the result pane P4Merge shows changes that are common
to both branches in green. This is on the basis of the current branch
being green, as it is when invoked from Perforce; it means that lines in
the result are blue if and only if they are being changed by the merge,
making the resulting diff clearer. Whereas if you use blue as the
current branch, then there is no single colour highlighting changes -
a green line in the result could be a change, but it could also be
something already in the current branch that isn't changed by the merge.
There is no need to swap LOCAL/REMOTE order for difftool; P4Merge is
symmetrical in this case, and a 0- or 1-revision difftool invocation
already gives the working tree (ours) on the right in green, matching
Perforce's equivalent Diff Against Have Revision. And you couldn't
swap it anyway, as it would make 2-revision difftool invocation
back-to-front.
Note that P4Merge now shows ours on the right for both diff and merge,
unlike other diff/mergetools, which always have REMOTE on the right.
But observe that REMOTE is the working tree (ie ours) for a diff,
while it's another branch (ie theirs) for a merge.
Signed-off-by: Kevin Bracey ke...@bracey.fi
---
mergetools/p4merge | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mergetools/p4merge b/mergetools/p4merge
index 8a36916..46b3a5a 100644
--- a/mergetools/p4merge
+++ b/mergetools/p4merge
@@ -22,7 +22,7 @@ diff_cmd () {
merge_cmd () {
touch $BACKUP
$base_present || $BASE
- $merge_tool_path $BASE $LOCAL $REMOTE $MERGED
+ $merge_tool_path $BASE $REMOTE $LOCAL $MERGED
check_unchanged
}
--
1.8.2.rc2.5.g1a80410.dirty
--
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: feature suggestion: optimize common parts for checkout --conflict=diff3
Hello Junio, On Wed, Mar 06, 2013 at 01:09:41PM -0800, Junio C Hamano wrote: Jeff King p...@peff.net writes: But it would apply to the content that is outside of the hunk marker; we have changed the concept of what is in the base and what is in the conflict by shrinking the conflict to its smallest size. Hmm, unless you mean by base something entirely different from what was in the common ancestor version, I do not think I can agree. The point of diff3 mode is to show how it looked line in the common ancestor and what the conflicting sides want to change that common version into; letting the user view three versions to help him decide what to do by only looking at the part inside conflict markers. We show both sides added, either identically or differently as noteworthy events, but the patched code pushes both sides added identically case outside the conflicting hunk, as if what was added I didn't test, but both sides removed identically should be moved out, too, shouldn't it? relative to the common ancestor version (in Uwe's case, is it 1-14 that is common, or just 10-14?) is not worth looking at when considering what the right resolution is. If it is not worth looking at what was in the original for the conflicting part, why would we be even using diff3 mode in the first place? because even zdiff3 contains more information than merge. And compared to diff3 it's smaller sometimes and so easier to understand. Other than that I agree fully to the things Jeff said so far. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ | -- 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: feature suggestion: optimize common parts for checkout --conflict=diff3
Junio C Hamano gits...@pobox.com writes: Jeff King p...@peff.net writes: But it would apply to the content that is outside of the hunk marker; we have changed the concept of what is in the base and what is in the conflict by shrinking the conflict to its smallest size. Hmm, unless you mean by base something entirely different from what was in the common ancestor version, I do not think I can agree. The point of diff3 mode is to show how it looked line in the common ancestor and what the conflicting sides want to change that common version into; letting the user view three versions to help him decide what to do by only looking at the part inside conflict markers. We show both sides added, either identically or differently as noteworthy events, but the patched code pushes both sides added identically case outside the conflicting hunk, as if what was added relative to the common ancestor version (in Uwe's case, is it 1-14 that is common, or just 10-14?) is not worth looking at when considering what the right resolution is. If it is not worth looking at what was in the original for the conflicting part, why would we be even using diff3 mode in the first place? I vaguely recall we did this clip to eager as an explicit bugfix at 83133740d9c8 (xmerge.c: diff3 -m style clips merge reduction level to EAGER or less, 2008-08-29). The list archive around that time may give us more contexts. -- 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] In partial SVN merges, the ranges contains additional character *
See http://www.open.collab.net/community/subversion/articles/merge-info.html
Extract:
The range r30430:30435 that was added to 1.5.x in this merge has a '*'
suffix for 1.5.x\www.
This '*' is the marker for a non-inheritable mergeinfo range.
The '*' means that only the path on which the mergeinfo is explicitly set
has had this range merged into it.
Signed-off-by: Jan Pesta jan.pe...@certicon.cz
---
perl/Git/SVN.pm | 5 +
1 file changed, 5 insertions(+)
diff --git a/perl/Git/SVN.pm b/perl/Git/SVN.pm
index 0ebc68a..74d49bb 100644
--- a/perl/Git/SVN.pm
+++ b/perl/Git/SVN.pm
@@ -1493,6 +1493,11 @@ sub lookup_svn_merge {
my @merged_commit_ranges;
# find the tip
for my $range ( @ranges ) {
+ if ($range =~ /[*]$/) {
+ warn W:Ignoring partial merge in svn:mergeinfo
+ .dirprop: $source:$range\n;
+ next;
+ }
my ($bottom, $top) = split -, $range;
$top ||= $bottom;
my $bottom_commit = $gs-find_rev_after( $bottom, 1, $top );
--
1.8.1.msysgit.1
--
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 v2] tests: make sure rename pretty print works
Add basic use cases and corner cases tests for
git diff -M --summary/stat.
Signed-off-by: Antoine Pelisse apeli...@gmail.com
---
list of fixes:
- Test using diff instead of show
(that is more consistent with commit message).
- add extra spaces around paths
- Use better commit messages
- Moved to existing t4001
t/t4001-diff-rename.sh | 54
1 file changed, 54 insertions(+)
diff --git a/t/t4001-diff-rename.sh b/t/t4001-diff-rename.sh
index 844277c..2f327b7 100755
--- a/t/t4001-diff-rename.sh
+++ b/t/t4001-diff-rename.sh
@@ -102,4 +102,58 @@ test_expect_success 'setup for many rename source
candidates' '
grep warning actual.err
'
+test_expect_success 'rename pretty print with nothing in common' '
+ mkdir -p a/b/
+ : a/b/c
+ git add a/b/c
+ git commit -m create a/b/c
+ mkdir -p c/b/
+ git mv a/b/c c/b/a
+ git commit -m a/b/c - c/b/a
+ git diff -M --summary HEAD^ HEAD output
+ test_i18ngrep a/b/c = c/b/a output
+ git diff -M --stat HEAD^ HEAD output
+ test_i18ngrep a/b/c = c/b/a output
+'
+
+test_expect_success 'rename pretty print with common prefix' '
+ mkdir -p c/d
+ git mv c/b/a c/d/e
+ git commit -m c/b/a - c/d/e
+ git diff -M --summary HEAD^ HEAD output
+ test_i18ngrep c/{b/a = d/e} output
+ git diff -M --stat HEAD^ HEAD output
+ test_i18ngrep c/{b/a = d/e} output
+'
+
+test_expect_success 'rename pretty print with common suffix' '
+ mkdir d
+ git mv c/d/e d/e
+ git commit -m c/d/e - d/e
+ git diff -M --summary HEAD^ HEAD output
+ test_i18ngrep {c/d = d}/e output
+ git diff -M --stat HEAD^ HEAD output
+ test_i18ngrep {c/d = d}/e output
+'
+
+test_expect_success 'rename pretty print with common prefix and suffix' '
+ mkdir d/f
+ git mv d/e d/f/e
+ git commit -m d/e - d/f/e
+ git diff -M --summary HEAD^ HEAD output
+ test_i18ngrep d/{ = f}/e output
+ git diff -M --stat HEAD^ HEAD output
+ test_i18ngrep d/{ = f}/e output
+'
+
+test_expect_success 'rename pretty print common prefix and suffix overlap' '
+ mkdir d/f/f
+ git mv d/f/e d/f/f/e
+ git commit -m d/f/e d/f/f/e
+ git diff -M --summary HEAD^ HEAD output
+ test_i18ngrep d/f/{ = f}/e output
+ git diff -M --stat HEAD^ HEAD output
+ test_i18ngrep d/f/{ = f}/e output
+'
+
test_done
--
1.7.9.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
fetch --no-tags with and w/o --all
Hello $ git --version git version 1.7.10.4 $ git fetch origin --no-tags does what it says $ git fetch --all --no-tags still gets all the tags from the remote. Is this known? Thanks. -- Cristian Tibirna(1-418-) 656-2131 / 4340 Laval University - Quebec, CAN ... http://www.giref.ulaval.ca/~ctibirna Research professional at GIREF ... ctibi...@giref.ulaval.ca -- 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: feature suggestion: optimize common parts for checkout --conflict=diff3
Jeff King p...@peff.net writes: I think Uwe's example shows that it _is_ useful. Yes, you no longer have the information about what happened through 1-14 (whether it was really there in the ancestor file, or whether it was simply added identically). But that information might or might not be relevant. I think it is more like I added bread and my wife added bread to our common shopping list and our two-way RCS merge default is to collapse that case to one loaf of bread on the shopping list. My impression has always been that people who use diff3 mode care about this case and want to know that the original did not have bread on the list in order to decide if one or two loaves of bread should remain in the result. In Uwe's example, it is just noise that detracts from the interesting part of the change (or does it? I think the answer is in the eye of the reader). In other words, you would use the RCS merge style because most of the time you would resolve to one loaf of bread and the fact that it was missing in the original is not needed to decide that. So, it feels strange to use diff3 and still want to discard that information---if it is not relevant, why are you using diff3 mode in the first place? That is the question that is still not answered. -- 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: fetch --no-tags with and w/o --all
Cristian Tibirna ctibi...@giref.ulaval.ca writes: Hello $ git --version git version 1.7.10.4 $ git fetch origin --no-tags does what it says $ git fetch --all --no-tags still gets all the tags from the remote. Is this known? Because --all (or --multiple) to iterate through all remotes does not pass accept any command line refspecs, using these options with --no-tags and/or --tags should be diagnosed as an error, but it appears that the error checking is not done. -- 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
Already up-to-date! merge isn't a no-op?
Hi all- I have a branch history that looks like this: --M-M-- master \ / / x feature \ \ x-A- maint In other words we had a new feature that was so cool that after testing on master was back-ported to maint (luckily we knew ahead of time this was likely). When it came time to merge feature into maint the process looked something like this: Yesterday (not shown above): $ git checkout master $ git merge maint Today: $ git checkout maint $ git merge feature Merge made by the 'recursive' strategy. $ git checkout master $ git merge maint Already up-to-date! Merge made by the 'recursive' strategy. $ git --version git version 1.8.1.5 In the past, I've only seen Already up-to-date! when there is literally nothing to do (all commits are reachable from HEAD). In this case, the merge of feature into maint (commit A) is the only commit not reachable from HEAD, and Git does create a merge commit (though the new commit and the first parent point to the same tree). The fact that a commit is created makes me call this something more than a no-op, even though no content changed. So what is the actual meaning of Already up-to-date!? Is it based on the tree, the reachable commits, or something more complicated? Thanks, Stephen -- 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] tests: make sure rename pretty print works
Antoine Pelisse apeli...@gmail.com writes:
Add basic use cases and corner cases tests for
git diff -M --summary/stat.
Signed-off-by: Antoine Pelisse apeli...@gmail.com
---
list of fixes:
- Test using diff instead of show
(that is more consistent with commit message).
- add extra spaces around paths
- Use better commit messages
- Moved to existing t4001
t/t4001-diff-rename.sh | 54
1 file changed, 54 insertions(+)
Nice.
Will queue, but we may want to make these tests more independent
from each other later. For example, if the first test fails before
its git mv a/b/c c/b/a, the set-up of the second test to further
move it to c/d/e will fail, which is probably not very desirable.
Thanks.
+test_expect_success 'rename pretty print with nothing in common' '
+ mkdir -p a/b/
+ : a/b/c
+ git add a/b/c
+ git commit -m create a/b/c
+ mkdir -p c/b/
+ git mv a/b/c c/b/a
+ git commit -m a/b/c - c/b/a
+ git diff -M --summary HEAD^ HEAD output
+ test_i18ngrep a/b/c = c/b/a output
+ git diff -M --stat HEAD^ HEAD output
+ test_i18ngrep a/b/c = c/b/a output
+'
+
+test_expect_success 'rename pretty print with common prefix' '
+ mkdir -p c/d
+ git mv c/b/a c/d/e
+ git commit -m c/b/a - c/d/e
+ git diff -M --summary HEAD^ HEAD output
+ test_i18ngrep c/{b/a = d/e} output
+ git diff -M --stat HEAD^ HEAD output
+ test_i18ngrep c/{b/a = d/e} output
+'
+
+test_expect_success 'rename pretty print with common suffix' '
+ mkdir d
+ git mv c/d/e d/e
+ git commit -m c/d/e - d/e
+ git diff -M --summary HEAD^ HEAD output
+ test_i18ngrep {c/d = d}/e output
+ git diff -M --stat HEAD^ HEAD output
+ test_i18ngrep {c/d = d}/e output
+'
+
+test_expect_success 'rename pretty print with common prefix and suffix' '
+ mkdir d/f
+ git mv d/e d/f/e
+ git commit -m d/e - d/f/e
+ git diff -M --summary HEAD^ HEAD output
+ test_i18ngrep d/{ = f}/e output
+ git diff -M --stat HEAD^ HEAD output
+ test_i18ngrep d/{ = f}/e output
+'
+
+test_expect_success 'rename pretty print common prefix and suffix overlap' '
+ mkdir d/f/f
+ git mv d/f/e d/f/f/e
+ git commit -m d/f/e d/f/f/e
+ git diff -M --summary HEAD^ HEAD output
+ test_i18ngrep d/f/{ = f}/e output
+ git diff -M --stat HEAD^ HEAD output
+ test_i18ngrep d/f/{ = f}/e output
+'
+
test_done
--
1.7.9.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: Already up-to-date! merge isn't a no-op?
Stephen Bash b...@genarts.com writes: So what is the actual meaning of Already up-to-date!? Is it based on the tree, the reachable commits, or something more complicated? The resulting tree of the merge happened to be the same as the original tree (i.e. git diff HEAD^ HEAD is empty). This happens quite often and is perfectly normal. After merging topics that has been cooking in 'next' to 'master', merging the resulting 'master' to 'next' is likely to result in that situation, unless 'master' has gained some other changes, such as updating the draft release notes with a commit on it, or applying an obvious and trivial fix before cooking it in 'next'. -- 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 0/2] Improve P4Merge mergetool invocation
Two changes to the same piece of code that have greatly improved the behaviour of P4Merge for me. Some of it may also be applicable to other mergetools. I've put probably overly-long-winded explanations in the commit messages. Comments welcome. In particular, I know almost nothing of sh, so I may have made some blunder there. Kevin Bracey (2): p4merge: swap LOCAL and REMOTE for mergetool p4merge: create a virtual base if none available git-mergetool--lib.sh | 14 ++ mergetools/p4merge| 4 ++-- 2 files changed, 16 insertions(+), 2 deletions(-) -- 1.8.2.rc2.5.g1a80410.dirty -- 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 1/4] wt-status: split wt_status_state parsing function out
Junio C Hamano gits...@pobox.com writes: In other words, with the new world order, wouldn't a saner function signature be: static const char *read_and_strip_branch(const char **path); Eh, discard an asterisk from there. Given a string to name the file, read it to find the branch name recorded in it. after this patch? Also I notice that the error-return cases of this function may be wrong even before your patch. Shouldn't it be doing *branch = NULL (and 'return NULL' after the suggested change)? -- 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] help: show manpage for aliased command on git alias --help
Michael J Gruber g...@drmicha.warpmail.net writes: Well, even in the simple case one has to wonder: Why does the user invoke help for co? There are two very likely cases: A) User does not remember what co is aliased to. B) User wants to see the man page. If A is not the case then it's easy for the user to request help for checkout (or commit or ...). Removing the only easy way to look up the definition of an alias is a major regression. Very well said ;-). -- 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] In partial SVN merges, the ranges contains additional character *
Jan Pešta jan.pe...@certicon.cz writes:
See http://www.open.collab.net/community/subversion/articles/merge-info.html
Extract:
The range r30430:30435 that was added to 1.5.x in this merge has a '*'
suffix for 1.5.x\www.
This '*' is the marker for a non-inheritable mergeinfo range.
The '*' means that only the path on which the mergeinfo is explicitly set
has had this range merged into it.
Signed-off-by: Jan Pesta jan.pe...@certicon.cz
---
perl/Git/SVN.pm | 5 +
1 file changed, 5 insertions(+)
diff --git a/perl/Git/SVN.pm b/perl/Git/SVN.pm
index 0ebc68a..74d49bb 100644
--- a/perl/Git/SVN.pm
+++ b/perl/Git/SVN.pm
@@ -1493,6 +1493,11 @@ sub lookup_svn_merge {
my @merged_commit_ranges;
# find the tip
for my $range ( @ranges ) {
+ if ($range =~ /[*]$/) {
+ warn W:Ignoring partial merge in svn:mergeinfo
+ .dirprop: $source:$range\n;
+ next;
+ }
my ($bottom, $top) = split -, $range;
$top ||= $bottom;
my $bottom_commit = $gs-find_rev_after( $bottom, 1, $top );
--
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: fetch --no-tags with and w/o --all
On Wed, Mar 06, 2013 at 01:56:01PM -0800, Junio C Hamano wrote: Cristian Tibirna ctibi...@giref.ulaval.ca writes: Hello $ git --version git version 1.7.10.4 $ git fetch origin --no-tags does what it says $ git fetch --all --no-tags still gets all the tags from the remote. Is this known? Because --all (or --multiple) to iterate through all remotes does not pass accept any command line refspecs, using these options with --no-tags and/or --tags should be diagnosed as an error, but it appears that the error checking is not done. Or we could just pass them through. Looks like this was already fixed by 8556646 (fetch --all: pass --tags/--no-tags through to each remote, 2012-09-05), which is in v1.7.12.2 and higher. -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 1/2] p4merge: swap LOCAL and REMOTE for mergetool
Kevin Bracey ke...@bracey.fi writes: Reverse LOCAL and REMOTE when invoking P4Merge as a mergetool, so that the incoming branch is now in the left-hand, blue triangle pane, and the current branch is in the right-hand, green circle pane. Given that the ordering of the three variants has been the way it is since the very initial version by Scott, I'll sit on this patch until hearing from those Cc'ed (who presumably do use p4merge, unlike I who don't) that it is a good change. 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: fetch --no-tags with and w/o --all
Jeff King p...@peff.net writes: On Wed, Mar 06, 2013 at 01:56:01PM -0800, Junio C Hamano wrote: Cristian Tibirna ctibi...@giref.ulaval.ca writes: Hello $ git --version git version 1.7.10.4 $ git fetch origin --no-tags does what it says $ git fetch --all --no-tags still gets all the tags from the remote. Is this known? Because --all (or --multiple) to iterate through all remotes does not pass accept any command line refspecs, using these options with --no-tags and/or --tags should be diagnosed as an error, but it appears that the error checking is not done. Or we could just pass them through. Looks like this was already fixed by 8556646 (fetch --all: pass --tags/--no-tags through to each remote, 2012-09-05), which is in v1.7.12.2 and higher. ;-) No wonder this looked somewhat familiar. -- 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: feature suggestion: optimize common parts for checkout --conflict=diff3
On Wed, Mar 06, 2013 at 01:50:46PM -0800, Junio C Hamano wrote:
I think it is more like I added bread and my wife added bread to
our common shopping list and our two-way RCS merge default is to
collapse that case to one loaf of bread on the shopping list. My
impression has always been that people who use diff3 mode care
about this case and want to know that the original did not have
bread on the list in order to decide if one or two loaves of bread
should remain in the result.
I think that is only the case sometimes. It depends on what is in the
conflict, and what your data is. I think you are conflating two things,
though: zealousness of merge, and having the original content handy when
resolving. To me, diff3 is about the latter. It can also be a hint that
the user cares about the former, but not necessarily.
In Uwe's example,
it is just noise that detracts from the interesting part of the change
(or does it? I think the answer is in the eye of the reader).
In other words, you would use the RCS merge style because most of
the time you would resolve to one loaf of bread and the fact that
it was missing in the original is not needed to decide that. So, it
feels strange to use diff3 and still want to discard that
information---if it is not relevant, why are you using diff3 mode in
the first place? That is the question that is still not answered.
Because for the lines that _are_ changed, you may want to see what the
original looked like. Here's a more realistic example:
git init repo
cd repo
# Some baseline C code.
cat foo.c \EOF
int foo(int bar)
{
return bar + 5;
}
EOF
git add foo.c
git commit -m base
git tag base
# Simulate a modification to the function.
sed -i '2a\
if (bar 3)\
bar *= 2;
' foo.c
git commit -am multiply
git tag multiply
# And another modification.
sed -i 's/bar + 5/bar + 7/' foo.c
git commit -am plus7
# Now on a side branch...
git checkout -b side base
# let's cherry pick the first change. Obviously
# we could just fast-forward in this toy example,
# but let's try to simulate a real history.
#
# We insert a sleep so that the cherry-pick does not
# accidentally end up with the exact same commit-id (again,
# because this is a toy example).
sleep 1
git cherry-pick multiply
# and now let's make a change that conflicts with later
# changes on master
sed -i 's/bar + 5/bar + 8/' foo.c
git commit -am plus8
# and now merge, getting a conflict
git merge master
# show the result with various marker styles
for i in merge diff3 zdiff3; do
echo
echo == $i
git.compile checkout --conflict=$i foo.c
cat foo.c
done
which produces:
== merge
int foo(int bar)
{
if (bar 3)
bar *= 2;
ours
return bar + 8;
===
return bar + 7;
theirs
}
The ZEALOUS level has helpfully cut out the shared cherry-picked bits,
and let us focus on the real change.
== diff3
int foo(int bar)
{
ours
if (bar 3)
bar *= 2;
return bar + 8;
||| base
return bar + 5;
===
if (bar 3)
bar *= 2;
return bar + 7;
theirs
}
Here we get to see all of the change, but the interesting difference is
overwhelmed by the shared cherry-picked bits. It's only 2 lines here,
but of course it could be much larger in a real example, and the reader
is forced to manually verify that the early parts are byte-for-byte
identical.
== zdiff3
int foo(int bar)
{
if (bar 3)
bar *= 2;
ours
return bar + 8;
||| base
return bar + 5;
===
return bar + 7;
theirs
}
Here we see the hunk cut-down again, removing the cherry-picked parts.
But the presence of the base is still interesting, because we see
something that was not in the merge marker: that we were originally
at 5, and moved to 7 on one side and 8 on the other.
I see conflicts like this when I rebase my topics forward; you may pick
up part of my series, or even make a tweak to a patch in the middle. I
prefer diff3 markers because they carry more information (and use them
automatically via merge.conflictstyle). But in some cases, the lack of
zealous reduction means that I end having to figure out whether and if
anything changed in the seemingly identical bits. Sometimes it is
nothing, and sometimes you tweaked whitespace or fixed a typo, and it
takes a lot of manual looking to figure it out. I hadn't realized it was
related to the
Please pull l10n updates for 1.8.2 round 4
Hi Junio, The following changes since commit 7799588faa2a8071da8ef047c87f9a1520fb8903: Merge git://github.com/git-l10n/git-po (2013-03-04 01:16:02 -0800) are available in the git repository at: git://github.com/git-l10n/git-po master for you to fetch changes up to a7409dfbc1c0d7e0c62f704a03a61bf669e90ae9: l10n: zh_CN.po: translate 1 new message (2013-03-07 08:46:19 +0800) Jiang Xin (2): l10n: git.pot: v1.8.2 round 4 (1 changed) l10n: zh_CN.po: translate 1 new message Peter Krefting (1): l10n: Update Swedish translation (2009t0f0u) Ralf Thielow (1): l10n: de.po: translate 1 new message Tran Ngoc Quan (1): l10n: vi.po: Update translation (2009t0f0u) po/de.po| 16 +--- po/git.pot | 4 ++-- po/sv.po| 8 po/vi.po| 20 ++-- po/zh_CN.po | 8 5 files changed, 29 insertions(+), 27 deletions(-) -- Jiang Xin -- 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: fetch --no-tags with and w/o --all
On Wed, Mar 06, 2013 at 04:41:44PM -0800, Junio C Hamano wrote: Or we could just pass them through. Looks like this was already fixed by 8556646 (fetch --all: pass --tags/--no-tags through to each remote, 2012-09-05), which is in v1.7.12.2 and higher. ;-) No wonder this looked somewhat familiar. I still find it somewhat gross that we actually re-construct the command-line from the parsed flag variables. It seems like it would be easier to simply propagate the argv we got in the first place, and then we would not have any chance of omitting a new option that is added later. Probably not worth worrying about now, though, as the fix is long since shipped. The next person who is adding an option can look at doing that refactoring. And it may be that there are some options we don't propagate intentionally (I didn't look closely). -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
[gitweb] Removed reference to git.kernel.org
git.kernel.org no longer uses gitweb but has switched to cgit. Info about this can be found on: https://www.kernel.org/pelican.html or simply by looking at http://git.kernel.org . This is change since 2013-03-01. Signed-off-by: Fredrik Gustafsson iv...@iveqy.com --- gitweb/README |3 --- 1 fil ändrad, 3 borttagningar(-) diff --git a/gitweb/README b/gitweb/README index 6da4778..471dcfb 100644 --- a/gitweb/README +++ b/gitweb/README @@ -1,9 +1,6 @@ GIT web Interface = -The one working on: - http://git.kernel.org/ - From the git version 1.4.0 gitweb is bundled with git. -- 1.7.10.4 -- 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] p4merge: create a virtual base if none available
On Wed, Mar 6, 2013 at 12:32 PM, Kevin Bracey ke...@bracey.fi wrote:
Originally, with no base, Git gave P4Merge $LOCAL as a dummy base:
p4merge $LOCAL $LOCAL $REMOTE $MERGED
Commit 0a0ec7bd changed this to:
p4merge empty file $LOCAL $REMOTE $MERGED
to avoid the problem of being unable to save in some circumstances.
Unfortunately this approach does not produce good results at all on
differing inputs. P4Merge really regards the blank file as the base, and
once you have just a couple of differences between the two branches you
end up with one a massive full-file conflict. The diff is not readable,
and you have to invoke difftool MERGE_HEAD HEAD manually to see a
2-way diff.
The original form appears to have invoked special 2-way comparison
behaviour that occurs only if the base filename is or equal to the
left input. You get a good diff, and it does not auto-resolve in one
direction or the other. (Normally if one branch equals the base, it
would autoresolve to the other branch).
But there appears to be no way of getting this 2-way behaviour and being
able to reliably save. Having base=left appears to be triggering other
assumptions. There are tricks the user can use to force the save icon
on, but it's not intuitive.
So we now follow a suggestion given in the original patch's discussion:
generate a virtual base, consisting of the lines common to the two
branches. It produces a much nicer 3-way diff view than either of the
original forms, and than I suspect other mergetools are managing.
Signed-off-by: Kevin Bracey ke...@bracey.fi
---
git-mergetool--lib.sh | 14 ++
mergetools/p4merge| 2 +-
2 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/git-mergetool--lib.sh b/git-mergetool--lib.sh
index e338be5..5b60cf5 100644
--- a/git-mergetool--lib.sh
+++ b/git-mergetool--lib.sh
@@ -108,6 +108,20 @@ check_unchanged () {
fi
}
+make_virtual_base() {
+ # Copied from git-merge-one-file.sh.
I think the reasoning behind these patches is good.
How do we feel about this duplication?
Should we make a common function in the git-sh-setup.sh,
or is it okay to have a slightly modified version of this
function in two places?
+ # This starts with $LOCAL, and uses git apply to
+ # remove lines that are not in $REMOTE.
+ cp -- $LOCAL $BASE
+ sz0=`wc -c $BASE`
+ @@DIFF@@ -u -La/$BASE -Lb/$BASE $BASE $REMOTE | git
apply --no-add
+ sz1=`wc -c $BASE`
+
+ # If we do not have enough common material, it is not
+ # worth trying two-file merge using common subsections.
+ expr $sz0 \ $sz1 \* 2 /dev/null || : $BASE
+}
+
valid_tool () {
setup_tool $1 return 0
cmd=$(get_merge_tool_cmd $1)
diff --git a/mergetools/p4merge b/mergetools/p4merge
index 46b3a5a..f0a893b 100644
--- a/mergetools/p4merge
+++ b/mergetools/p4merge
@@ -21,7 +21,7 @@ diff_cmd () {
merge_cmd () {
touch $BACKUP
- $base_present || $BASE
+ $base_present || make_virtual_base
$merge_tool_path $BASE $REMOTE $LOCAL $MERGED
check_unchanged
}
--
1.8.2.rc2.5.g1a80410.dirty
--
David
--
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] p4merge: create a virtual base if none available
On Wed, Mar 6, 2013 at 12:32 PM, Kevin Bracey ke...@bracey.fi wrote:
+make_virtual_base() {
+ # Copied from git-merge-one-file.sh.
+ # This starts with $LOCAL, and uses git apply to
+ # remove lines that are not in $REMOTE.
+ cp -- $LOCAL $BASE
+ sz0=`wc -c $BASE`
+ @@DIFF@@ -u -La/$BASE -Lb/$BASE $BASE $REMOTE | git
apply --no-add
+ sz1=`wc -c $BASE`
+
+ # If we do not have enough common material, it is not
+ # worth trying two-file merge using common subsections.
+ expr $sz0 \ $sz1 \* 2 /dev/null || : $BASE
+}
This seems to be indented deeper then the other functions
(or gmail is whitespace damaging my view).
Please use one hard tab to indent here.
We prefer $(command) instead of `command`.
These should be adjusted.
Also, the @@DIFF@@ string may not work here.
This is a template string that is replaced by the Makefile.
I don't think the tools in the mergetools/ directory go through
cmd_munge_script so this is not going to work as-is.
Can the same thing be accomplished using git diff --no-index
so that we do not need a dependency on an external diff command here?
I am not a regular p4merge user myself so I'll defer to others
on the cc: list for their thoughts. It does seem like a good idea, though.
--
David
--
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] bundle: Add colons to list headings in verify
These slightly improve the reading flow by making it obvious that a list
follows.
Signed-off-by: Lukas Fleischer g...@cryptocrack.de
---
bundle.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/bundle.c b/bundle.c
index 65db53b..8cd8b4f 100644
--- a/bundle.c
+++ b/bundle.c
@@ -183,8 +183,8 @@ int verify_bundle(struct bundle_header *header, int verbose)
struct ref_list *r;
r = header-references;
- printf_ln(Q_(The bundle contains %d ref,
-The bundle contains %d refs,
+ printf_ln(Q_(The bundle contains %d ref:,
+The bundle contains %d refs:,
r-nr),
r-nr);
list_refs(r, 0, NULL);
@@ -192,8 +192,8 @@ int verify_bundle(struct bundle_header *header, int verbose)
if (!r-nr) {
printf_ln(_(The bundle records a complete history.));
} else {
- printf_ln(Q_(The bundle requires this ref,
-The bundle requires these %d refs,
+ printf_ln(Q_(The bundle requires this ref:,
+The bundle requires these %d refs:,
r-nr),
r-nr);
list_refs(r, 0, NULL);
--
1.8.2.rc2.352.g908df73
--
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] bundle: Fix verify output if history is complete
A more informative message for complete bundles was added in commit
8c3710fd. However, the prerequisites ref list is currently read *after*
we check if it equals zero, which means we never actually print the
newly introduced message.
Move the code that reads the prerequisites ref list before the check to
fix this.
Signed-off-by: Lukas Fleischer g...@cryptocrack.de
---
I am not sure whether we should add a test case for such a simple bug.
If you think we should, just let me know and I will add one.
bundle.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/bundle.c b/bundle.c
index 8d12816..65db53b 100644
--- a/bundle.c
+++ b/bundle.c
@@ -188,10 +188,10 @@ int verify_bundle(struct bundle_header *header, int
verbose)
r-nr),
r-nr);
list_refs(r, 0, NULL);
+ r = header-prerequisites;
if (!r-nr) {
printf_ln(_(The bundle records a complete history.));
} else {
- r = header-prerequisites;
printf_ln(Q_(The bundle requires this ref,
The bundle requires these %d refs,
r-nr),
--
1.8.2.rc2.352.g908df73
--
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 1/2] p4merge: swap LOCAL and REMOTE for mergetool
On 07/03/2013 02:36, Junio C Hamano wrote: Kevin Bracey ke...@bracey.fi writes: Reverse LOCAL and REMOTE when invoking P4Merge as a mergetool, so that the incoming branch is now in the left-hand, blue triangle pane, and the current branch is in the right-hand, green circle pane. Given that the ordering of the three variants has been the way it is since the very initial version by Scott, I'll sit on this patch until hearing from those Cc'ed (who presumably do use p4merge, unlike I who don't) that it is a good change. I agree that this is the controversial patch of the two. It's going to chuck away 3-4 years of what Git users are used to, albeit in favour of a decade of what Perforce users are used to. And it also makes it inconsistent with all the other mergetools (at least assuming their display matches their command line). I checked for any historical discussion from when this was added about the order, and there was none. So I'm assuming it was just done to match the other tools, maybe not realising P4Merge's theirs/ours convention. There was no explicit recognition at the time that they were breaking the Perforce convention, or that the order had an effect. I've used both Git and Perforce for quite a while, but have only just started using P4Merge with Git. It seemed weirdly off and unintuitive to me at first, until I suddenly realised that it was just backwards. I would have settled for just having to get used to driving on the other side of the road, and matching other mergetools, until I realised that it effectively broke display of common changes. That's a problem. On consistency, personally, I think there's an argument for reversing all the mergetools to match this way, as I find this orientation more intuitively aligns with difftool. But I'm not bold enough to suggest that. Yet. Kevin -- 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 1/2] p4merge: swap LOCAL and REMOTE for mergetool
Kevin Bracey ke...@bracey.fi writes: I agree that this is the controversial patch of the two. It's going to chuck away 3-4 years of what Git users are used to, albeit in favour of a decade of what Perforce users are used to. And it also makes it inconsistent with all the other mergetools (at least assuming their display matches their command line). If p4merge GUI labels one side clearly as theirs and the other ours, and the way we feed the inputs to it makes the side that is actually ours appear in p4merge GUI labelled as theirs, then I do not think backward compatibility argument does not hold water. It is just correcting a longstanding 3-4 year old bug in a tool that nobody noticed. For people who are very used to the way p4merge shows the merged contents by theirs-base-yours order in side-by-side view, I do not think it is unreasonable to introduce the mergetool.$name.reverse configuration variable and teach the mergetool frontend to pay attention to it. That will allow them to see their merge in reverse order even when they are using a backend other than p4merge. With such a mechanism in place, by default, we can just declare that mergetool.p4merge.reverse is true when unset, while making mergetool.$name.reverse for all the other tools default to false. People who are already used to the way our p4merge integration works can set mergetool.p4merge.reverse to false explicitly to retain the historical behaviour that you are declaring buggy with such a change. How does that sound? David? -- 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] p4merge: create a virtual base if none available
David Aguilar dav...@gmail.com writes: How do we feel about this duplication? Should we make a common function in the git-sh-setup.sh, or is it okay to have a slightly modified version of this function in two places? It probably is a good idea to have it in one place. That would also solve the @@DIFF@@ replacement issue you noticed at the same time. -- 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
