Re: fix french translation
Please do not forget to reply to all. On Mon, May 27, 2013 at 1:34 AM, 乙酸鋰 ch3co...@gmail.com wrote: git-gui/po/fr.po | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git b/git-gui/po/fr.po a/git-gui/po/fr.po index 0aff186..40441db 100644 --- b/git-gui/po/fr.po +++ a/git-gui/po/fr.po @@ -1139,7 +1139,7 @@ msgstr Standard (rapide, semi-redondant, liens durs) #: lib/choose_repository.tcl:514 msgid Full Copy (Slower, Redundant Backup) -msgstr Copie complète (plus lent, sauvegarde redondante) +msgstr Copy complète (plus lent, sauvegarde redondante) I still don't get why Copie is replaced by Copy ? -- 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] diff: add --ignore-blank-lines option
On Sun, May 26, 2013 at 10:35 PM, Johannes Sixt j...@kdbg.org wrote: Am 26.05.2013 19:58, schrieb Antoine Pelisse: The goal of the patch is to introduce the GNU diff -B/--ignore-blank-lines as closely as possible. The short option is not available because it's already used for break-rewrites. When this option is used, git-diff will not create hunks that simply adds or removes empty lines, but will still show empty lines addition/suppression if they are close enough to valuable changes. So when an addition or removal of a blank line appears in a hunk that also has non-blank-line changes, the addition or removal is not treated specially? Exactly. How is a blank line defined? What happens if a line that has only whitespace is added or removed? xdl_blankline() is the best description of what I considered a blank line. If no --ignore-space-* option is given, it's a line that starts and ends with '\n'. If any --ignore-space-* option is given, it's a line that has any number of isspace(3)-defined characters, followed by '\n'. I'm thinking of diffs of files with CRLF Good you did, because I didn't ;-) line breaks, where the CR would count as whitespace in the line, I think. With the current implementation, an empty line with CRLF will not show as a blank line if no space option is given. As CR is a space according to isspace(3), the line will be removed with any space option. +--ignore-blank-lines:: + Ignore changes whose lines are all blank. I think this is too terse and does not convey what the option really does. That's the description from GNU diff man page. But indeed it could be more precise. +test_expect_success 'ignore-blank-lines: only new lines' ' + seq 5 x Please use test_seq instead of seq in all new tests. Will fix. -- Hannes -- 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] credential-osxkeychain: support more protocols
Add protocol ftp, smtp, and ssh for credential-osxkeychain.
---
contrib/credential/osxkeychain/git-credential-osxkeychain.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/contrib/credential/osxkeychain/git-credential-osxkeychain.c
b/contrib/credential/osxkeychain/git-credential-osxkeychain.c
index 3940202..4ddcfb3 100644
--- a/contrib/credential/osxkeychain/git-credential-osxkeychain.c
+++ b/contrib/credential/osxkeychain/git-credential-osxkeychain.c
@@ -127,10 +127,16 @@ static void read_credential(void)
*v++ = '\0';
if (!strcmp(buf, protocol)) {
- if (!strcmp(v, https))
+ if (!strcmp(v, ftp))
+ protocol = kSecProtocolTypeFTP;
+ else if (!strcmp(v, https))
protocol = kSecProtocolTypeHTTPS;
else if (!strcmp(v, http))
protocol = kSecProtocolTypeHTTP;
+ else if (!strcmp(v, smtp))
+ protocol = kSecProtocolTypeSMTP;
+ else if (!strcmp(v, ssh))
+ protocol = kSecProtocolTypeSSH;
else /* we don't yet handle other protocols */
exit(0);
}
--
1.8.3
--
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: contrib/git-normal-to-bare.sh
Zenaan Harkness z...@freedbms.net writes: rm -rf $repo The user would appreciate if you check that there are no uncommited changes and no untracked files (at least no untracked and not ignored files) before running this. Also, it's $repo, not just $repo, or you'll get surprising behavior if $repo contain spaces. The safe way would actually be stg like: rm -fr -- $repo in case $repo starts with a dash. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- 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: fix french translation
Antoine Pelisse apeli...@gmail.com writes: -msgstr Copie complète (plus lent, sauvegarde redondante) +msgstr Copy complète (plus lent, sauvegarde redondante) I still don't get why Copie is replaced by Copy ? Yes, this is clearly wrong. Copie is french, Copy is not. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- 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: contrib/git-normal-to-bare.sh
On 5/27/13, Matthieu Moy matthieu@grenoble-inp.fr wrote: Zenaan Harkness z...@freedbms.net writes: rm -rf $repo The user would appreciate if you check that there are no uncommited changes and no untracked files (at least no untracked and not ignored files) before running this. Also, it's $repo, not just $repo, or you'll get surprising behavior if $repo contain spaces. The safe way would actually be stg like: rm -fr -- $repo Thanks. In my later email, I changed it to mv - should have highlighted there was a change. I got bitten, on a small repo thankfully, where a perms or ownership problem caused the whole repo to disappear. So mv it is :) BTW, I've subscribed for a little while now... Thanks again Zenaan -- 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: contrib/git-normal-to-bare.sh
On Mon, May 27, 2013 at 07:43:13PM +1000, Zenaan Harkness wrote: In my later email, I changed it to mv - should have highlighted there was a change. I got bitten, on a small repo thankfully, where a perms or ownership problem caused the whole repo to disappear. So mv it is :) Do you really need bash for that script or will it do with sh? I think sh is preferred. Also a mv instead of a rm will require a lot of disc space if you have a big repository. -- Med vänliga hälsningar Fredrik Gustafsson tel: 0733-608274 e-post: iv...@iveqy.com -- 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] credential-osxkeychain: support more protocols
On Mon, May 27, 2013 at 3:57 AM, Xidorn Quan quanxunz...@gmail.com wrote:
Add protocol ftp, smtp, and ssh for credential-osxkeychain.
---
contrib/credential/osxkeychain/git-credential-osxkeychain.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/contrib/credential/osxkeychain/git-credential-osxkeychain.c
b/contrib/credential/osxkeychain/git-credential-osxkeychain.c
index 3940202..4ddcfb3 100644
--- a/contrib/credential/osxkeychain/git-credential-osxkeychain.c
+++ b/contrib/credential/osxkeychain/git-credential-osxkeychain.c
@@ -127,10 +127,16 @@ static void read_credential(void)
*v++ = '\0';
if (!strcmp(buf, protocol)) {
- if (!strcmp(v, https))
+ if (!strcmp(v, ftp))
+ protocol = kSecProtocolTypeFTP;
+ else if (!strcmp(v, https))
protocol = kSecProtocolTypeHTTPS;
else if (!strcmp(v, http))
protocol = kSecProtocolTypeHTTP;
+ else if (!strcmp(v, smtp))
+ protocol = kSecProtocolTypeSMTP;
+ else if (!strcmp(v, ssh))
+ protocol = kSecProtocolTypeSSH;
else /* we don't yet handle other protocols */
exit(0);
This looks pretty good, except the last one raises a question. I'm
using Mac OS X, and ssh already interacts with keychain to get my SSH
key password. Is this mainly for password logins via SSH? Assuming
that's the case:
Signed-off-by: John Szakmeister j...@szakmeister.net
-John
--
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: What's cooking in git.git (May 2013, #04; Wed, 15)
On Mon, May 20, 2013 at 11:17 PM, Junio C Hamano gits...@pobox.com wrote: Think why the user has such a hard to type ref in the first place. The user may have done this previously, thinking that he is detaching the HEAD to fix an earlier mistake in a branch: $ BAD_COMMIT=$(git rev-parse nd/magic~8) $ git checkout $BAD_COMMIT but by mistake gave a -b after checkout, i.e. $ git checkout -b $BAD_COMMIT After this, commands that want to work on branch name would still work as expected, with the expectation being the user would be working on the refs/heads/$BAD_COMMIT branch, e.g. $ git checkout $BAD_COMMIT $ git branch -m $BAD_COMMIT nd/magic-fix but commands that want to work on commit object name will resolve it to the $BAD_COMMIT object (i.e. nd/magic~8), e.g. $ git log $BAD_COMMIT and needs disambiguation if the user wants to work on the commit at the tip of the branch, e.g. $ git log heads/$BAD_COMMIT So we really do want the users to notice and take corrective action, and one way to attract the attention of the users is to phrase the message more explicitly to let them know what is going on. Point taken. I guess the message would be something like this? Refname '%.*s' is ignored. It may be created by mistake. Or should we be more elaborate? -- Duy -- 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] prune-packed: avoid implying 1 is DRY_RUN in prune_packed_objects()
Commit b60daf0 (Make git-prune-packed a bit more chatty. - 2007-01-12)
changes the meaning of prune_packed_objects()'s argument, from dry
run or not dry run to a bitmap.
It however forgot to update prune_packed_objects() caller in
builtin/prune.c to use new DRY_RUN macro. It's fine (for a long time!)
but there is a risk that someday someone may change the value of
DRY_RUN to something else and builtin/prune.c suddenly breaks. Avoid
that possibility.
While at there, change opts == VERBOSE to opts VERBOSE as there
is no obvious reason why we only be chatty when DRY_RUN is not set.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
builtin.h | 3 +++
builtin/prune-packed.c | 15 +++
builtin/prune.c| 2 +-
3 files changed, 11 insertions(+), 9 deletions(-)
diff --git a/builtin.h b/builtin.h
index faef559..64bab6b 100644
--- a/builtin.h
+++ b/builtin.h
@@ -12,6 +12,9 @@
extern const char git_usage_string[];
extern const char git_more_info_string[];
+#define PRUNE_PACKED_DRY_RUN 01
+#define PRUNE_PACKED_VERBOSE 02
+
extern void prune_packed_objects(int);
struct fmt_merge_msg_opts {
diff --git a/builtin/prune-packed.c b/builtin/prune-packed.c
index 83382c1..fa6ce42 100644
--- a/builtin/prune-packed.c
+++ b/builtin/prune-packed.c
@@ -8,9 +8,6 @@ static const char * const prune_packed_usage[] = {
NULL
};
-#define DRY_RUN 01
-#define VERBOSE 02
-
static struct progress *progress;
static void prune_dir(int i, DIR *dir, char *pathname, int len, int opts)
@@ -29,7 +26,7 @@ static void prune_dir(int i, DIR *dir, char *pathname, int
len, int opts)
if (!has_sha1_pack(sha1))
continue;
memcpy(pathname + len, de-d_name, 38);
- if (opts DRY_RUN)
+ if (opts PRUNE_PACKED_DRY_RUN)
printf(rm -f %s\n, pathname);
else
unlink_or_warn(pathname);
@@ -44,7 +41,7 @@ void prune_packed_objects(int opts)
const char *dir = get_object_directory();
int len = strlen(dir);
- if (opts == VERBOSE)
+ if (opts PRUNE_PACKED_VERBOSE)
progress = start_progress_delay(Removing duplicate objects,
256, 95, 2);
@@ -71,10 +68,12 @@ void prune_packed_objects(int opts)
int cmd_prune_packed(int argc, const char **argv, const char *prefix)
{
- int opts = isatty(2) ? VERBOSE : 0;
+ int opts = isatty(2) ? PRUNE_PACKED_VERBOSE : 0;
const struct option prune_packed_options[] = {
- OPT_BIT('n', dry-run, opts, N_(dry run), DRY_RUN),
- OPT_NEGBIT('q', quiet, opts, N_(be quiet), VERBOSE),
+ OPT_BIT('n', dry-run, opts, N_(dry run),
+ PRUNE_PACKED_DRY_RUN),
+ OPT_NEGBIT('q', quiet, opts, N_(be quiet),
+ PRUNE_PACKED_VERBOSE),
OPT_END()
};
diff --git a/builtin/prune.c b/builtin/prune.c
index 85843d4..59d1fdc 100644
--- a/builtin/prune.c
+++ b/builtin/prune.c
@@ -165,7 +165,7 @@ int cmd_prune(int argc, const char **argv, const char
*prefix)
stop_progress(progress);
prune_object_dir(get_object_directory());
- prune_packed_objects(show_only);
+ prune_packed_objects(show_only ? PRUNE_PACKED_DRY_RUN : 0);
remove_temporary_files(get_object_directory());
s = mkpathdup(%s/pack, get_object_directory());
remove_temporary_files(s);
--
1.8.2.83.gc99314b
--
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] fetch: don't try to update unfetched tracking refs
Since commit f269048 (fetch: opportunistically update tracking refs,
2013-05-11) we update tracking refs opportunistically when fetching
remote branches. However, if a refspec is given on the command line
that does not include a configured (non-pattern) refspec a fatal error
occurs.
Fix this by setting the missing_ok flag when calling get_fetch_map.
Signed-off-by: John Keeping j...@keeping.me.uk
---
builtin/fetch.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/fetch.c b/builtin/fetch.c
index e41cc0d..d15a734 100644
--- a/builtin/fetch.c
+++ b/builtin/fetch.c
@@ -183,7 +183,7 @@ static struct ref *get_ref_map(struct transport *transport,
old_tail = tail;
for (i = 0; i transport-remote-fetch_refspec_nr; i++)
get_fetch_map(ref_map, transport-remote-fetch[i],
- tail, 0);
+ tail, 1);
for (rm = *old_tail; rm; rm = rm-next)
rm-fetch_head_status = FETCH_HEAD_IGNORE;
} else {
--
1.8.3.rc3.438.gb3e4ae3
--
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] credential-osxkeychain: support more protocols
On Mon, May 27, 2013 at 6:27 PM, John Szakmeister j...@szakmeister.net wrote:
On Mon, May 27, 2013 at 3:57 AM, Xidorn Quan quanxunz...@gmail.com wrote:
Add protocol ftp, smtp, and ssh for credential-osxkeychain.
---
contrib/credential/osxkeychain/git-credential-osxkeychain.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/contrib/credential/osxkeychain/git-credential-osxkeychain.c
b/contrib/credential/osxkeychain/git-credential-osxkeychain.c
index 3940202..4ddcfb3 100644
--- a/contrib/credential/osxkeychain/git-credential-osxkeychain.c
+++ b/contrib/credential/osxkeychain/git-credential-osxkeychain.c
@@ -127,10 +127,16 @@ static void read_credential(void)
*v++ = '\0';
if (!strcmp(buf, protocol)) {
- if (!strcmp(v, https))
+ if (!strcmp(v, ftp))
+ protocol = kSecProtocolTypeFTP;
+ else if (!strcmp(v, https))
protocol = kSecProtocolTypeHTTPS;
else if (!strcmp(v, http))
protocol = kSecProtocolTypeHTTP;
+ else if (!strcmp(v, smtp))
+ protocol = kSecProtocolTypeSMTP;
+ else if (!strcmp(v, ssh))
+ protocol = kSecProtocolTypeSSH;
else /* we don't yet handle other protocols */
exit(0);
This looks pretty good, except the last one raises a question. I'm
using Mac OS X, and ssh already interacts with keychain to get my SSH
key password. Is this mainly for password logins via SSH? Assuming
that's the case:
Signed-off-by: John Szakmeister j...@szakmeister.net
-John
I thought that SSH password logins can benefit from it, but I just
found that it is wrong because it seems that SSH client is responsible
for authenticating. Consequently, supporting SSH here is useless.
I will remove that lines and send this patch again.
Since it is the first time I submit a patch to git, I am not very
familiar with the convention here. Should I send the modified patch
to the maintainer directly? And what information should I append to
my patch before it can get merged?
--
Xidorn Quan
--
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] commit: don't use-editor when allow-empty-message
Commit a24a41e (git-commit: only append a newline to -m mesg if necessary, 2013-02-18) introduced a regression: when --allow-empty-message is used and an empty message is explicitly specified with -m , git commit still launches $EDITOR unnecessarily. The commit (correctly) fixes opt_parse_m() to not fill in two newlines into the message buffer unconditionally. The real problem is that launching $EDITOR only depends on use_editor and whether message is empty. Fix the problem by setting use_editor to 0 when --allow-empty-message is specified in the codepath where an explicit string is passed via -m. Reported-by: Mislav Marohnić mislav.maroh...@gmail.com Signed-off-by: Ramkumar Ramachandra artag...@gmail.com --- builtin/commit.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/builtin/commit.c b/builtin/commit.c index d2f30d9..1f5da9d 100644 --- a/builtin/commit.c +++ b/builtin/commit.c @@ -128,6 +128,8 @@ static int opt_parse_m(const struct option *opt, const char *arg, int unset) strbuf_addch(buf, '\n'); strbuf_addstr(buf, arg); strbuf_complete_line(buf); + if (allow_empty_message) + use_editor = 0; } return 0; } -- 1.8.3.1.g33669de -- 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] commit: don't use-editor when allow-empty-message
Ramkumar Ramachandra wrote: builtin/commit.c | 2 ++ 1 file changed, 2 insertions(+) I just made this dependent on the order in which options are parsed. If --allow-empty-message is specified before -m , it works. Otherwise, not. Sorry about the stupidity. -- 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] commit: don't use-editor when allow-empty-message
Commit a24a41e (git-commit: only append a newline to -m mesg if
necessary, 2013-02-18) introduced a regression: when
--allow-empty-message is used and an empty message is explicitly
specified with -m , git commit still launches $EDITOR unnecessarily.
The commit (correctly) fixes opt_parse_m() to not fill in two newlines
into the message buffer unconditionally. The real problem is that
launching $EDITOR only depends on use_editor and whether message is
empty. Fix the problem by setting explicit_message in the codepath
where an explicit string is passed via -m, and then checking it before
launching $EDITOR.
Reported-by: Mislav Marohnić mislav.maroh...@gmail.com
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
Works?
builtin/commit.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/builtin/commit.c b/builtin/commit.c
index d2f30d9..7d72ba7 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -108,6 +108,7 @@ static const char *cleanup_arg;
static enum commit_whence whence;
static int use_editor = 1, include_status = 1;
static int show_ignored_in_status;
+static int explicit_message = 0;
static const char *only_include_assumed;
static struct strbuf message = STRBUF_INIT;
@@ -128,6 +129,7 @@ static int opt_parse_m(const struct option *opt, const char
*arg, int unset)
strbuf_addch(buf, '\n');
strbuf_addstr(buf, arg);
strbuf_complete_line(buf);
+ explicit_message = 1;
}
return 0;
}
@@ -824,7 +826,7 @@ static int prepare_to_commit(const char *index_file, const
char *prefix,
git_path(commit_editmsg), hook_arg1, hook_arg2, NULL))
return 0;
- if (use_editor) {
+ if (use_editor !explicit_message) {
char index[PATH_MAX];
const char *env[2] = { NULL };
env[0] = index;
--
1.8.3.1.g33669de.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: git hangs on pthread_join
I forgot to reply to the mailing list and now something went wrong with the messages in mutt =P Recap:ing: On Thursday, May 23, 2013 07:01:43 am you wrote: I'm running a rather special configuration, basically i have a gerrit server pushing ... I have found git receive-packs that has been running for days/weeks without terminating ... Anyone that has any clues about what could be going wrong? -- Have you narrowed down whether this is a git client problem, or a server problem (gerrit in your case). Is this a repeatable issue. Try the same operation against a clone of the repo using just git. Check on the server side for .noz files in you repo (a jgit thing), --- This happens both using gerrit and using git directly... My thought is more that git doesn't handle dodgy connections over openvpn (udp) that goes over dodgy international vpn links. I conclusion has always been that it ends up in a unpredictable state, like a blocking read or so that just
Re: [PATCH] credential-osxkeychain: support more protocols
On Mon, May 27, 2013 at 9:55 AM, Xidorn Quan quanxunz...@gmail.com wrote: [snip] I thought that SSH password logins can benefit from it, but I just found that it is wrong because it seems that SSH client is responsible for authenticating. Consequently, supporting SSH here is useless. I will remove that lines and send this patch again. Since it is the first time I submit a patch to git, I am not very familiar with the convention here. Should I send the modified patch to the maintainer directly? And what information should I append to my patch before it can get merged? You'll need to read Documentation/SubmittingPatches (here's a link to a version online: https://github.com/git/git/blob/master/Documentation/SubmittingPatches). You should resend this patch with the fix and change [PATCH] to [PATCH v2], so the folks involved know that this is the second iteration. You also need to include a Signed-off-by line in your patch, which means you agree to the agreement set forth in the Developer's Certificate of Origin (which is in the SubmittingPatches documentation). You can easily include this line when you make the commit by using the `-s` option on `git commit`. You can also add an Acked-by line for me (since I reviewed and approve of the change): Acked-by: John Szakmeister j...@szakmeister.net HTH! -John -- 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] credential-osxkeychain: support more protocols
Add protocol ftp and smtp for credential-osxkeychain.
Acked-by: John Szakmeister j...@szakmeister.net
Signed-off-by: Xidorn Quan quanxunz...@gmail.com
---
contrib/credential/osxkeychain/git-credential-osxkeychain.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/contrib/credential/osxkeychain/git-credential-osxkeychain.c
b/contrib/credential/osxkeychain/git-credential-osxkeychain.c
index 3940202..648fadd 100644
--- a/contrib/credential/osxkeychain/git-credential-osxkeychain.c
+++ b/contrib/credential/osxkeychain/git-credential-osxkeychain.c
@@ -127,10 +127,14 @@ static void read_credential(void)
*v++ = '\0';
if (!strcmp(buf, protocol)) {
- if (!strcmp(v, https))
+ if (!strcmp(v, ftp))
+ protocol = kSecProtocolTypeFTP;
+ else if (!strcmp(v, https))
protocol = kSecProtocolTypeHTTPS;
else if (!strcmp(v, http))
protocol = kSecProtocolTypeHTTP;
+ else if (!strcmp(v, smtp))
+ protocol = kSecProtocolTypeSMTP;
else /* we don't yet handle other protocols */
exit(0);
}
--
1.8.3
--
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] commit: don't use-editor when allow-empty-message
So now we have two fixes for the same issue, don't we ?
You probably missed $gmane/225534.
On Mon, May 27, 2013 at 4:20 PM, Ramkumar Ramachandra
artag...@gmail.com wrote:
Commit a24a41e (git-commit: only append a newline to -m mesg if
necessary, 2013-02-18) introduced a regression: when
--allow-empty-message is used and an empty message is explicitly
specified with -m , git commit still launches $EDITOR unnecessarily.
The commit (correctly) fixes opt_parse_m() to not fill in two newlines
into the message buffer unconditionally. The real problem is that
launching $EDITOR only depends on use_editor and whether message is
empty. Fix the problem by setting explicit_message in the codepath
where an explicit string is passed via -m, and then checking it before
launching $EDITOR.
Reported-by: Mislav Marohnić mislav.maroh...@gmail.com
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
Works?
builtin/commit.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/builtin/commit.c b/builtin/commit.c
index d2f30d9..7d72ba7 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -108,6 +108,7 @@ static const char *cleanup_arg;
static enum commit_whence whence;
static int use_editor = 1, include_status = 1;
static int show_ignored_in_status;
+static int explicit_message = 0;
static const char *only_include_assumed;
static struct strbuf message = STRBUF_INIT;
@@ -128,6 +129,7 @@ static int opt_parse_m(const struct option *opt, const
char *arg, int unset)
strbuf_addch(buf, '\n');
strbuf_addstr(buf, arg);
strbuf_complete_line(buf);
+ explicit_message = 1;
}
return 0;
}
@@ -824,7 +826,7 @@ static int prepare_to_commit(const char *index_file,
const char *prefix,
git_path(commit_editmsg), hook_arg1, hook_arg2, NULL))
return 0;
- if (use_editor) {
+ if (use_editor !explicit_message) {
char index[PATH_MAX];
const char *env[2] = { NULL };
env[0] = index;
--
1.8.3.1.g33669de.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
--
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] credential-osxkeychain: support more protocols
On Mon, May 27, 2013 at 10:28 PM, John Szakmeister j...@szakmeister.net wrote: [snip] You'll need to read Documentation/SubmittingPatches (here's a link to a version online: https://github.com/git/git/blob/master/Documentation/SubmittingPatches). You should resend this patch with the fix and change [PATCH] to [PATCH v2], so the folks involved know that this is the second iteration. You also need to include a Signed-off-by line in your patch, which means you agree to the agreement set forth in the Developer's Certificate of Origin (which is in the SubmittingPatches documentation). You can easily include this line when you make the commit by using the `-s` option on `git commit`. You can also add an Acked-by line for me (since I reviewed and approve of the change): Acked-by: John Szakmeister j...@szakmeister.net HTH! Thx for your explaining, it helps a lot! After reading the doc, I have a question that when can I affirm that the list reaches a consensus? -- Xidorn Quan -- 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] credential-osxkeychain: support more protocols
On Mon, May 27, 2013 at 10:35:59PM +0800, Xidorn Quan wrote:
diff --git a/contrib/credential/osxkeychain/git-credential-osxkeychain.c
b/contrib/credential/osxkeychain/git-credential-osxkeychain.c
index 3940202..648fadd 100644
--- a/contrib/credential/osxkeychain/git-credential-osxkeychain.c
+++ b/contrib/credential/osxkeychain/git-credential-osxkeychain.c
@@ -127,10 +127,14 @@ static void read_credential(void)
*v++ = '\0';
if (!strcmp(buf, protocol)) {
- if (!strcmp(v, https))
+ if (!strcmp(v, ftp))
+ protocol = kSecProtocolTypeFTP;
+ else if (!strcmp(v, https))
protocol = kSecProtocolTypeHTTPS;
else if (!strcmp(v, http))
protocol = kSecProtocolTypeHTTP;
+ else if (!strcmp(v, smtp))
+ protocol = kSecProtocolTypeSMTP;
else /* we don't yet handle other protocols */
exit(0);
This looks good to me. Git will ask for protocol=ftp when
accessing the dumb protocol over ftp. And it will ask for smtp via
git-send-email since 4d31a44 (git-send-email: use git credential to
obtain password, 2013-02-12).
While we are in the area it may be worth thinking if there are other
schemes we would want to support. Git might feed any URL scheme that
curl accepts, so I think we would want to handle FTPS alongside FTP, no?
We may also eventually want IMAP for git-imap-send, but we have not yet
implemented credential-helper support there. We may also want http/socks
proxy authentication, but we also have not implemented the git side of
that yet. So I think both of those can wait for now.
-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 v2] difftool --dir-diff: always use identical working tree file
When deciding whether or not we should link a working tree file into
the temporary right-hand directory for a directory diff, we
currently behave differently in the --symlink and --no-symlink
cases. If using symlinks any identical files are linked across but
with --no-symlink only files that contain unstaged changes are
copied back into the working tree.
Change this so that identical files are copied back as well. This
is beneficial because it widens the set of circumstances in which we
copy changes made by the user back into the working tree.
Signed-off-by: Kenichi Saita nito...@gmail.com
---
git-difftool.perl |9 ++---
t/t7800-difftool.sh | 19 +++
2 files changed, 21 insertions(+), 7 deletions(-)
diff --git a/git-difftool.perl b/git-difftool.perl
index 8a75205..e57d3d1 100755
--- a/git-difftool.perl
+++ b/git-difftool.perl
@@ -85,13 +85,9 @@ sub exit_cleanup
sub use_wt_file
{
- my ($repo, $workdir, $file, $sha1, $symlinks) = @_;
+ my ($repo, $workdir, $file, $sha1) = @_;
my $null_sha1 = '0' x 40;
- if ($sha1 ne $null_sha1 and not $symlinks) {
- return 0;
- }
-
if (! -e $workdir/$file) {
# If the file doesn't exist in the working tree, we cannot
# use it.
@@ -213,8 +209,7 @@ EOF
if ($rmode ne $null_mode) {
my ($use, $wt_sha1) = use_wt_file($repo, $workdir,
- $dst_path, $rsha1,
- $symlinks);
+ $dst_path, $rsha1);
if ($use) {
push @working_tree, $dst_path;
$wtindex .= $rmode $wt_sha1\t$dst_path\0;
diff --git a/t/t7800-difftool.sh b/t/t7800-difftool.sh
index d46f041..2418528 100755
--- a/t/t7800-difftool.sh
+++ b/t/t7800-difftool.sh
@@ -385,6 +385,25 @@ test_expect_success PERL,SYMLINKS 'difftool --dir-diff
--symlink without unstage
test_cmp actual expect
'
+write_script modify-right-file \EOF
+echo new content $2/file
+EOF
+
+run_dir_diff_test 'difftool --dir-diff syncs worktree with unstaged change' '
+ test_when_finished git reset --hard
+ echo orig content file
+ git difftool -d $symlinks --extcmd $(pwd)/modify-right-file branch
+ echo new content expect
+ test_cmp expect file
+'
+
+run_dir_diff_test 'difftool --dir-diff syncs worktree without unstaged change'
'
+ test_when_finished git reset --hard
+ git difftool -d $symlinks --extcmd $(pwd)/modify-right-file branch
+ echo new content expect
+ test_cmp expect file
+'
+
write_script modify-file \EOF
echo new content file
EOF
--
1.7.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
git-svn too slow, contacts upstream svn repo
hello list,
I have been using git-svn in an corporate environment where svn repo has lot of
branches, (lot means 100). To avoid cloning all branches my config looks as
below
[svn-remote svn]
url = svn+ssh://url
fetch = srcroot/trunk:refs/remotes/trunk
branches = srcroot/branches/{branch_1, branch_2,
branch_3}:refs/remotes/*
Now, when a new branch of my interest is added in svn repo, I had like it to be
in my git-repo as well. In an ideal world, one shall simply add that branch
name to list in curly braces above, but that does not work. I had love to be
proved wrong here. Somebody on stackoverflow.com suggested (to else's question,
not mine) to add one more fetch as show below.
[svn-remote svn]
url = svn+ssh://url
fetch = srcroot/trunk:refs/remotes/trunk
fetch = srcroot/branch_4:refs/remotes/* # NEW BRANCH
branches = srcroot/branches/{branch_1, branch_2,
branch_3}:refs/remotes/*
haven't tried it, neither do I like it.
I do have a solution which WORKS, it is modified version of an example from
\doc\git\html\git-svn.html page. Below I have pasted the example and modified
it to reflect my specifics.
# assume an existing git-svn repo
D:\sourcecode
# Clone locally - make sure the refs/remotes/ space matches the server
mkdir project
cd project
git init
git remote add origin file:///D:/sourcecode # file:// is delibrate,
want true n/w behaviour
git config --replace-all remote.origin.fetch
'+refs/remotes/*:refs/remotes/*'
git fetch
# Prevent fetch/pull from local git repo,
# we only want to use git svn for form here
git config --remove-section remote.origin
# Create a local branch from one of the branches just fetched
git checkout -b master FETCH_HEAD
# Initialize 'git svn' locally (be sure to use the same URL and -T/-b/-t
options as were used on server)
git svn init http://svn.example.com/project
# edit config to include newly added branch in curly braces
# Pull the latest changes from Subversion
git svn fetch -r recentish rev, say BEGIN:HEAD
Above works exactly as I want, except the last step of git-svn fetch connects
to svn repo for each revision from BEGIN to HEAD. I want fairly long history
(for pretty blame). Which implies my BEGIN is not so recentish adterall. Hence,
it takes awfully long to finish, 2 days typically.
When GIT_TRACE is 1, below is output received
trace: exec: 'git-svn' 'fetch'
trace: run_command: 'git-svn' 'fetch'
trace: built-in: git 'config' '--bool' '--get' 'svn.fetchall'
trace: built-in: git 'config' '--bool' '--get' 'svn.parent'
trace: built-in: git 'config' '--bool' '--get' 'svn.noauthcache'
trace: built-in: git 'config' '--get' 'svn.revision'
trace: built-in: git 'config' '--bool' '--get' 'svn.nocheckout'
trace: built-in: git 'config' '--get' 'svn.authorsprog'
trace: built-in: git 'config' '--bool' '--get' 'svn.followparent'
trace: built-in: git 'config' '--get' 'svn.authorsfile'
trace: built-in: git 'config' '--bool' '--get' 'svn.useSvmProps'
trace: built-in: git 'config' '--get' 'svn.username'
trace: built-in: git 'config' '--get' 'svn.repackflags'
trace: built-in: git 'config' '--bool' '--get' 'svn.localtime'
trace: built-in: git 'config' '--int' '--get' 'svn.repack'
trace: built-in: git 'config' '--get' 'svn.ignorepaths'
trace: built-in: git 'config' '--int' '--get' 'svn.logwindowsize'
trace: built-in: git 'config' '--bool' '--get' 'svn.quiet'
trace: built-in: git 'config' '--get' 'svn.ignorerefs'
trace: built-in: git 'config' '--get' 'svn.configdir'
trace: built-in: git 'config' '--bool' '--get' 'svn.addauthorfrom'
trace: built-in: git 'config' '--bool' '--get' 'svn.useSvnsyncProps'
trace: built-in: git 'config' '--bool' '--get' 'svn.noMetadata'
trace: built-in: git 'config' '--bool' '--get' 'svn.uselogauthor'
trace: built-in: git 'rev-parse' '--symbolic' '--all'
trace: built-in: git 'config' '-l'
trace: built-in: git 'config' '-l'
trace: built-in: git 'config' '--bool' 'svn.useSvmProps'
trace: built-in: git 'config' '-l'
trace: built-in: git 'config' 'svn-remote.svn.branches-maxRev' '524908'
trace: built-in: git 'rev-list' '--pretty=raw' '--reverse'
'9f1414be94ab007b62ace31bf4d210a069276127..refs/remotes/branch_1' '--'
trace: built-in: git 'rev-list' '--pretty=raw' '--reverse'
'5eb0a454bcf066a8199b851add9ec07cde80119d..refs/remotes/branch_2' '--'
trace: built-in: git 'rev-list' '--pretty=raw' '--reverse'
'383b68b8514010a71efe10821e5ccc3541903ceb..refs/remotes/branch_3' '--'
trace: built-in: git 'rev-list' '--pretty=raw' '--reverse'
'89fe1a1d2cfca0886003f043c408fb5afadfec93..refs/remotes/trunk' '--'
I keep an watch for svn-remote.svn.branches-maxRev, this serves as my
progress. This wait is too much for a simple branch. Though, I must point out,
day feels fresh once it finishes :) Does any one know any for this?
If you paid attention this is Windows machine
git version 1.8.1.msysgit.1
thanks,
Quark
--
Re: [PATCH] fetch: don't try to update unfetched tracking refs
On Mon, May 27, 2013 at 12:40:25PM +0100, John Keeping wrote: Since commit f269048 (fetch: opportunistically update tracking refs, 2013-05-11) we update tracking refs opportunistically when fetching remote branches. However, if a refspec is given on the command line that does not include a configured (non-pattern) refspec a fatal error occurs. I'm not sure I understand what the last sentence means. I tried to add a test like: diff --git a/t/t5510-fetch.sh b/t/t5510-fetch.sh index ff43e08..02e30e1 100755 --- a/t/t5510-fetch.sh +++ b/t/t5510-fetch.sh @@ -422,6 +422,16 @@ test_expect_success 'configured fetch updates tracking' ' ) ' +test_expect_success 'non-configured ref does not confuse tracking update' ' + cd $D + git update-ref refs/odd/location HEAD + ( + cd three + git fetch origin refs/odd/location + git rev-parse --verify FETCH_HEAD + ) +' + test_expect_success 'pushing nonexistent branch by mistake should not segv' ' cd $D but it does not fail with the existing code. Can you give an example that fails? -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] credential-osxkeychain: support more protocols
On Mon, May 27, 2013 at 11:08 PM, Jeff King p...@peff.net wrote: [snip] This looks good to me. Git will ask for protocol=ftp when accessing the dumb protocol over ftp. And it will ask for smtp via git-send-email since 4d31a44 (git-send-email: use git credential to obtain password, 2013-02-12). While we are in the area it may be worth thinking if there are other schemes we would want to support. Git might feed any URL scheme that curl accepts, so I think we would want to handle FTPS alongside FTP, no? Good point, I'll add that. We may also eventually want IMAP for git-imap-send, but we have not yet implemented credential-helper support there. We may also want http/socks proxy authentication, but we also have not implemented the git side of that yet. So I think both of those can wait for now. Hope the helpers will be implemented soon. IMO, we can add IMAP and SOCKS for now since the protocol names are clear, while it is unclear what protocol name will be used for HTTP/HTTPS proxy. I guess that some may prefer using http/https as protocol name instead of something specific. What do you think? -- Xidorn Quan -- 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] fetch: don't try to update unfetched tracking refs
On Mon, May 27, 2013 at 11:42:52AM -0400, Jeff King wrote: On Mon, May 27, 2013 at 12:40:25PM +0100, John Keeping wrote: Since commit f269048 (fetch: opportunistically update tracking refs, 2013-05-11) we update tracking refs opportunistically when fetching remote branches. However, if a refspec is given on the command line that does not include a configured (non-pattern) refspec a fatal error occurs. I'm not sure I understand what the last sentence means. I tried to add a test like: diff --git a/t/t5510-fetch.sh b/t/t5510-fetch.sh index ff43e08..02e30e1 100755 --- a/t/t5510-fetch.sh +++ b/t/t5510-fetch.sh @@ -422,6 +422,16 @@ test_expect_success 'configured fetch updates tracking' ' ) ' +test_expect_success 'non-configured ref does not confuse tracking update' ' + cd $D + git update-ref refs/odd/location HEAD + ( + cd three + git fetch origin refs/odd/location + git rev-parse --verify FETCH_HEAD + ) +' + test_expect_success 'pushing nonexistent branch by mistake should not segv' ' cd $D but it does not fail with the existing code. Can you give an example that fails? I have this in my .git/config for git.git: [remote origin] url = git://github.com/gitster/git fetch = +refs/heads/*:refs/remotes/origin/* fetch = +refs/notes/amlog:refs/notes/amlog Then doing git fetch origin master fails because: fatal: Couldn't find remote ref refs/notes/amlog The following test fails for me (and passes with my patch) - note that in two, remote.one.fetch is configured as refs/heads/master:refs/heads/one. -- 8 -- diff --git a/t/t5510-fetch.sh b/t/t5510-fetch.sh index ff43e08..c540257 100755 --- a/t/t5510-fetch.sh +++ b/t/t5510-fetch.sh @@ -422,6 +422,19 @@ test_expect_success 'configured fetch updates tracking' ' ) ' +test_expect_success 'configured ref does not confuse tracking' ' + + cd $D + ( + cd one + git branch -f side + ) + ( + cd two + git fetch one side + ) +' + test_expect_success 'pushing nonexistent branch by mistake should not segv' ' cd $D -- 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] credential-osxkeychain: support more protocols
On Mon, May 27, 2013 at 11:46:24PM +0800, Xidorn Quan wrote: We may also eventually want IMAP for git-imap-send, but we have not yet implemented credential-helper support there. We may also want http/socks proxy authentication, but we also have not implemented the git side of that yet. So I think both of those can wait for now. Hope the helpers will be implemented soon. IMO, we can add IMAP and SOCKS for now since the protocol names are clear, while it is unclear what protocol name will be used for HTTP/HTTPS proxy. I guess that some may prefer using http/https as protocol name instead of something specific. What do you think? Yes, I think git will need to munge the protocol to indicate to the helper that it is a proxy (or alternatively, add a new key proxy=1 or something). So it would make sense to wait until the git side of the code materializes so that the helpers knows what to expect. There was some work done in this area last May, but there are a lot of corner cases with knowing exactly what the proxy URL is (because in some cases, curl pulls it from the environment without git's knowledge). There was a patch series under consideration for libcurl that would let us supply an authentication callback to curl that would be called when credentials were needed. But I have not kept track of the state of that patch and whether it ever got merged upstream into libcurl. -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] fetch: don't try to update unfetched tracking refs
On Mon, May 27, 2013 at 05:01:29PM +0100, John Keeping wrote: I'm not sure I understand what the last sentence means. I tried to add a test like: [...] but it does not fail with the existing code. Can you give an example that fails? I have this in my .git/config for git.git: [remote origin] url = git://github.com/gitster/git fetch = +refs/heads/*:refs/remotes/origin/* fetch = +refs/notes/amlog:refs/notes/amlog Ah, I see. It is not the refspec on the command-line does not match a configured refspec, but rather there exists a configured non-pattern refspec that does not match what was on the command-line (even if what was on the command-line did match another refspec). So your fix makes perfect sense. Do you mind squashing in this test below? I think it is a little less subtle than what you posted, as it sets up the situation explicitly in the test. It also checks that the refs we _did_ match still get updated (master in this case). diff --git a/t/t5510-fetch.sh b/t/t5510-fetch.sh index ff43e08..fde6891 100755 --- a/t/t5510-fetch.sh +++ b/t/t5510-fetch.sh @@ -422,6 +422,22 @@ test_expect_success 'configured fetch updates tracking' ' ) ' +test_expect_success 'non-matching refspecs do not confuse tracking update' ' + cd $D + git update-ref refs/odd/location HEAD + ( + cd three + git update-ref refs/remotes/origin/master base-origin-master + git config --add remote.origin.fetch \ + refs/odd/location:refs/remotes/origin/odd + o=$(git rev-parse --verify refs/remotes/origin/master) + git fetch origin master + n=$(git rev-parse --verify refs/remotes/origin/master) + test $o != $n + test_must_fail git rev-parse --verify refs/remotes/origin/odd + ) +' + test_expect_success 'pushing nonexistent branch by mistake should not segv' ' cd $D Thanks for the fix. Acked-by: Jeff King p...@peff.net -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 v4 14/21] remote-hg: show more proper errors
Hey Felipe,
I know that has been integrated a while ago.
On Thu, Apr 11, 2013 at 2:23 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
When cloning or pushing fails, we don't want to show a stack-trace.
diff --git a/contrib/remote-helpers/git-remote-hg
b/contrib/remote-helpers/git-remote-hg
index ff89725..3ae3598 100755
--- a/contrib/remote-helpers/git-remote-hg
+++ b/contrib/remote-helpers/git-remote-hg
@@ -284,11 +284,17 @@ def get_repo(url, alias):
else:
local_path = os.path.join(dirname, 'clone')
if not os.path.exists(local_path):
-peer, dstpeer = hg.clone(myui, {}, url, local_path,
update=False, pull=True)
+try:
+peer, dstpeer = hg.clone(myui, {}, url, local_path,
update=True, pull=True)
+except:
+die('Repository error')
repo = dstpeer.local()
Can you explain why update went from False to True ? That can be a
problem if the repository is BIG (two working directories instead of
one can raise space issues).
The commit message is not so helpful here ;)
--
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] fetch: don't try to update unfetched tracking refs
Since commit f269048 (fetch: opportunistically update tracking refs,
2013-05-11) we update tracking refs opportunistically when fetching
remote branches. However, if there is a configured non-pattern refspec
that does not match any of the refspecs given on the command line then a
fatal error occurs.
Fix this by setting the missing_ok flag when calling get_fetch_map.
Test-added-by: Jeff King p...@peff.net
Signed-off-by: John Keeping j...@keeping.me.uk
Acked-by: Jeff King p...@peff.net
---
On Mon, May 27, 2013 at 12:19:34PM -0400, Jeff King wrote:
On Mon, May 27, 2013 at 05:01:29PM +0100, John Keeping wrote:
I'm not sure I understand what the last sentence means. I tried to add a
test like:
[...]
but it does not fail with the existing code. Can you give an example
that fails?
I have this in my .git/config for git.git:
[remote origin]
url = git://github.com/gitster/git
fetch = +refs/heads/*:refs/remotes/origin/*
fetch = +refs/notes/amlog:refs/notes/amlog
Ah, I see. It is not the refspec on the command-line does not match a
configured refspec, but rather there exists a configured non-pattern
refspec that does not match what was on the command-line (even if what
was on the command-line did match another refspec).
Exactly. I've changed the commit message to (hopefully) make this
clearer.
So your fix makes perfect sense. Do you mind squashing in this test
below? I think it is a little less subtle than what you posted, as it
sets up the situation explicitly in the test. It also checks that the
refs we _did_ match still get updated (master in this case).
Done.
builtin/fetch.c | 2 +-
t/t5510-fetch.sh | 16
2 files changed, 17 insertions(+), 1 deletion(-)
diff --git a/builtin/fetch.c b/builtin/fetch.c
index e41cc0d..d15a734 100644
--- a/builtin/fetch.c
+++ b/builtin/fetch.c
@@ -183,7 +183,7 @@ static struct ref *get_ref_map(struct transport *transport,
old_tail = tail;
for (i = 0; i transport-remote-fetch_refspec_nr; i++)
get_fetch_map(ref_map, transport-remote-fetch[i],
- tail, 0);
+ tail, 1);
for (rm = *old_tail; rm; rm = rm-next)
rm-fetch_head_status = FETCH_HEAD_IGNORE;
} else {
diff --git a/t/t5510-fetch.sh b/t/t5510-fetch.sh
index ff43e08..fde6891 100755
--- a/t/t5510-fetch.sh
+++ b/t/t5510-fetch.sh
@@ -422,6 +422,22 @@ test_expect_success 'configured fetch updates tracking' '
)
'
+test_expect_success 'non-matching refspecs do not confuse tracking update' '
+ cd $D
+ git update-ref refs/odd/location HEAD
+ (
+ cd three
+ git update-ref refs/remotes/origin/master base-origin-master
+ git config --add remote.origin.fetch \
+ refs/odd/location:refs/remotes/origin/odd
+ o=$(git rev-parse --verify refs/remotes/origin/master)
+ git fetch origin master
+ n=$(git rev-parse --verify refs/remotes/origin/master)
+ test $o != $n
+ test_must_fail git rev-parse --verify refs/remotes/origin/odd
+ )
+'
+
test_expect_success 'pushing nonexistent branch by mistake should not segv' '
cd $D
--
1.8.3.rc3.438.gb3e4ae3
--
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] fetch: don't try to update unfetched tracking refs
On Mon, May 27, 2013 at 05:33:09PM +0100, John Keeping wrote: Ah, I see. It is not the refspec on the command-line does not match a configured refspec, but rather there exists a configured non-pattern refspec that does not match what was on the command-line (even if what was on the command-line did match another refspec). Exactly. I've changed the commit message to (hopefully) make this clearer. It does. To me, anyway. :) Thanks again. -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 v4 14/21] remote-hg: show more proper errors
On Mon, May 27, 2013 at 11:30 AM, Antoine Pelisse apeli...@gmail.com wrote:
Hey Felipe,
I know that has been integrated a while ago.
On Thu, Apr 11, 2013 at 2:23 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
When cloning or pushing fails, we don't want to show a stack-trace.
diff --git a/contrib/remote-helpers/git-remote-hg
b/contrib/remote-helpers/git-remote-hg
index ff89725..3ae3598 100755
--- a/contrib/remote-helpers/git-remote-hg
+++ b/contrib/remote-helpers/git-remote-hg
@@ -284,11 +284,17 @@ def get_repo(url, alias):
else:
local_path = os.path.join(dirname, 'clone')
if not os.path.exists(local_path):
-peer, dstpeer = hg.clone(myui, {}, url, local_path,
update=False, pull=True)
+try:
+peer, dstpeer = hg.clone(myui, {}, url, local_path,
update=True, pull=True)
+except:
+die('Repository error')
repo = dstpeer.local()
Can you explain why update went from False to True ? That can be a
problem if the repository is BIG (two working directories instead of
one can raise space issues).
The commit message is not so helpful here ;)
Good catch. It was probably a mistake. However, I already sent a patch
that overrides this so update=False again.
--
Felipe Contreras
--
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] cherry-pick: a fix and a new option
Hi, It doesn't make sense for the user to be interrupted constantly. Felipe Contreras (2): sequencer: trivial fix cherry-pick: add --skip-commits option Documentation/git-cherry-pick.txt | 3 +++ builtin/revert.c| 2 ++ sequencer.c | 12 +--- sequencer.h | 1 + t/t3508-cherry-pick-many-commits.sh | 13 + 5 files changed, 28 insertions(+), 3 deletions(-) -- 1.8.3.rc3.312.g47657de -- 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] sequencer: trivial fix
We should free objects before leaving.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
sequencer.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/sequencer.c b/sequencer.c
index ab6f8a7..7eeae2f 100644
--- a/sequencer.c
+++ b/sequencer.c
@@ -626,12 +626,15 @@ static int do_pick_commit(struct commit *commit, struct
replay_opts *opts)
rerere(opts-allow_rerere_auto);
} else {
int allow = allow_empty(opts, commit);
- if (allow 0)
- return allow;
+ if (allow 0) {
+ res = allow;
+ goto leave;
+ }
if (!opts-no_commit)
res = run_git_commit(defmsg, opts, allow);
}
+leave:
free_message(msg);
free(defmsg);
--
1.8.3.rc3.312.g47657de
--
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] cherry-pick: add --skip-commits option
Pretty much what it says on the tin.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
Documentation/git-cherry-pick.txt | 3 +++
builtin/revert.c| 2 ++
sequencer.c | 5 -
sequencer.h | 1 +
t/t3508-cherry-pick-many-commits.sh | 13 +
5 files changed, 23 insertions(+), 1 deletion(-)
diff --git a/Documentation/git-cherry-pick.txt
b/Documentation/git-cherry-pick.txt
index c205d23..fccd936 100644
--- a/Documentation/git-cherry-pick.txt
+++ b/Documentation/git-cherry-pick.txt
@@ -129,6 +129,9 @@ effect to your index in a row.
redundant commits are ignored. This option overrides that behavior and
creates an empty commit object. Implies `--allow-empty`.
+--skip-empty::
+ Instead of failing, skip commits that are or become empty.
+
--strategy=strategy::
Use the given merge strategy. Should only be used once.
See the MERGE STRATEGIES section in linkgit:git-merge[1]
diff --git a/builtin/revert.c b/builtin/revert.c
index 0401fdb..0e5ce71 100644
--- a/builtin/revert.c
+++ b/builtin/revert.c
@@ -118,6 +118,7 @@ static void parse_args(int argc, const char **argv, struct
replay_opts *opts)
OPT_END(),
OPT_END(),
OPT_END(),
+ OPT_END(),
};
if (opts-action == REPLAY_PICK) {
@@ -127,6 +128,7 @@ static void parse_args(int argc, const char **argv, struct
replay_opts *opts)
OPT_BOOLEAN(0, allow-empty, opts-allow_empty,
N_(preserve initially empty commits)),
OPT_BOOLEAN(0, allow-empty-message,
opts-allow_empty_message, N_(allow commits with empty messages)),
OPT_BOOLEAN(0, keep-redundant-commits,
opts-keep_redundant_commits, N_(keep redundant, empty commits)),
+ OPT_BOOLEAN(0, skip-empty, opts-skip_empty,
N_(skip empty commits)),
OPT_END(),
};
if (parse_options_concat(options, ARRAY_SIZE(options),
cp_extra))
diff --git a/sequencer.c b/sequencer.c
index 7eeae2f..86e8e78 100644
--- a/sequencer.c
+++ b/sequencer.c
@@ -625,7 +625,10 @@ static int do_pick_commit(struct commit *commit, struct
replay_opts *opts)
print_advice(res == 1, opts);
rerere(opts-allow_rerere_auto);
} else {
- int allow = allow_empty(opts, commit);
+ int allow;
+ if (opts-skip_empty is_index_unchanged() == 1)
+ goto leave;
+ allow = allow_empty(opts, commit);
if (allow 0) {
res = allow;
goto leave;
diff --git a/sequencer.h b/sequencer.h
index 1fc22dc..3b04844 100644
--- a/sequencer.h
+++ b/sequencer.h
@@ -34,6 +34,7 @@ struct replay_opts {
int allow_empty;
int allow_empty_message;
int keep_redundant_commits;
+ int skip_empty;
int mainline;
diff --git a/t/t3508-cherry-pick-many-commits.sh
b/t/t3508-cherry-pick-many-commits.sh
index 19c99d7..3dc19c6 100755
--- a/t/t3508-cherry-pick-many-commits.sh
+++ b/t/t3508-cherry-pick-many-commits.sh
@@ -187,4 +187,17 @@ test_expect_success 'cherry-pick --stdin works' '
check_head_differs_from fourth
'
+test_expect_success 'cherry-pick skip empty' '
+ git clean -fxd
+ git checkout -b empty fourth
+ git commit --allow-empty -m empty
+ test_commit ontop
+ git checkout -f master
+ git reset --hard fourth
+ git cherry-pick --skip-empty fourth..empty
+ echo ontop expected
+ git log --format=%s fourth..HEAD actual
+ test_cmp expected actual
+'
+
test_done
--
1.8.3.rc3.312.g47657de
--
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] commit: don't use-editor when allow-empty-message
Antoine Pelisse wrote: So now we have two fixes for the same issue, don't we ? You probably missed $gmane/225534. Gah, missed that. Sorry for the noise. -- 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 RESEND v2] path: Fix a sparse warning
On MinGW, sparse issues an 'get_st_mode_bits' not declared. Should it be static? warning. The MinGW and MSVC builds do not see the declaration of this function, within git-compat-util.h, due to its placement within an preprocessor conditional. In order to suppress the warning, we simply move the declaration to the top level of the header. Signed-off-by: Ramsay Jones ram...@ramsay1.demon.co.uk --- Hi Junio, Now that v1.8.3 is out, I note that this patch seems to have been dropped (or did I miss something?). This used to be [PATCH 2/6] path: Make the 'get_st_mode_bits' symbol a file static but the change in implementation required a change in title. This version simply moves the declaration so that the MinGW and MSVC builds can see it. ATB, Ramsay Jones git-compat-util.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/git-compat-util.h b/git-compat-util.h index e955bb5..0e5e4f8 100644 --- a/git-compat-util.h +++ b/git-compat-util.h @@ -163,7 +163,6 @@ typedef long intptr_t; typedef unsigned long uintptr_t; #endif -int get_st_mode_bits(const char *path, int *mode); #if defined(__CYGWIN__) #undef _XOPEN_SOURCE #include grp.h @@ -176,6 +175,8 @@ int get_st_mode_bits(const char *path, int *mode); #endif #endif +extern int get_st_mode_bits(const char *path, int *mode); + /* used on Mac OS X */ #ifdef PRECOMPOSE_UNICODE #include compat/precompose_utf8.h -- 1.8.3 -- 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 Request for the Git Bundler
On Mon, 27 May 2013 16:11:06 +0430, Omid Mo'menzadeh omid.mnza...@gmail.com wrote: Dear Tomas, I was using your git bundler a few days ago, and it worked like a charm. But there is a problem out there, and that is most users of your bundler are people using an unstable internet connection. I downloaded the bundle, and 'git bundle verify' said it was OK, but it wasn't. My only way of knowing that was asking for someone to download it and give me a checksum, and it took a whole day for me. So it would be nice if you could add a chekcsum, md5, sha1 or anything, to the download page, so anyone can check the downloaded bundle easily. I think the real problem is that git bundle verify does not actually verify the contents. Maybe there is another command which can check the contents of a bundle for corruption? A added the git mailing list to CC, maybe someone there knows more. Note for readers on the mailing list: the bundler service Omid is referring to is the one that I host here: http://bundler.caurea.org. -- 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] fix segfault with git log -c --follow
In diff_tree_combined we make a copy of diffopts. In try_to_follow_renames, called via diff_tree_sha1, we free and re-initialize diffopts-pathspec-items. Since we did not make a deep copy of diffopts in diff_tree_combined, the original diffopts does not get the update. By the time we return from diff_tree_combined, rev-diffopt-pathspec-items points to an invalid memory address. We get a segfault next time we try to access that pathspec. Instead, along with the copy of diffopts, make a copy pathspec-items as well. We would also have to make a copy of pathspec-raw to keep it consistent with pathspec-items, but nobody seems to rely on that. Signed-off-by: Clemens Buchacher dri...@aon.at --- I wonder why I get a segfault from this so reliably, since it's not actually a null-pointer dereference. Maybe this is gcc 4.8 doing something different from previous versions? Also, I have absolutely no confidence in my understanding of this code. This is the first solution that came to mind, and could be totally wrong. I just figured a patch is better than no patch. Clemens combine-diff.c | 3 +++ t/t4202-log.sh | 14 ++ 2 files changed, 17 insertions(+) diff --git a/combine-diff.c b/combine-diff.c index 77d7872..8825604 100644 --- a/combine-diff.c +++ b/combine-diff.c @@ -1302,6 +1302,7 @@ void diff_tree_combined(const unsigned char *sha1, int i, num_paths, needsep, show_log_first, num_parent = parents-nr; diffopts = *opt; + diff_tree_setup_paths(diffopts.pathspec.raw, diffopts); diffopts.output_format = DIFF_FORMAT_NO_OUTPUT; DIFF_OPT_SET(diffopts, RECURSIVE); DIFF_OPT_CLR(diffopts, ALLOW_EXTERNAL); @@ -1372,6 +1373,8 @@ void diff_tree_combined(const unsigned char *sha1, paths = paths-next; free(tmp); } + + diff_tree_release_paths(diffopts); } void diff_tree_combined_merge(const struct commit *commit, int dense, diff --git a/t/t4202-log.sh b/t/t4202-log.sh index 9243a97..cb03d28 100755 --- a/t/t4202-log.sh +++ b/t/t4202-log.sh @@ -530,6 +530,20 @@ test_expect_success 'show added path under --follow -M' ' ) ' +test_expect_success 'git log -c --follow' ' + test_create_repo follow-c + ( + cd follow-c + test_commit initial file original + git rm file + test_commit rename file2 original + git reset --hard initial + test_commit modify file foo + git merge -m merge rename + git log -c --follow file2 + ) +' + cat expect \EOF * commit COMMIT_OBJECT_NAME |\ Merge: MERGE_PARENTS -- 1.8.2.3 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
git-send-email doesn't deal with quoted names
Hi,
My commit author name is Jason A. Donenfeld. Because this has a dot,
SMTP handling likes to put it in quotes.
git-send-email has this line:
if (defined $author and $author ne $sender) {
With my name, this always winds up false, because it's comparing
'Jason A. Donenfeld ja...@zx2c4.com' with 'Jason A. Donenfeld
ja...@zx2c4.com'.
So, the logic needs to be fixed somehow.
Thanks,
Jason
--
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: fix french translation
Sorry, I reversed the revisions. This one should be correct. git-gui/po/fr.po | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/git-gui/po/fr.po b/git-gui/po/fr.po index 40441db..0aff186 100644 --- a/git-gui/po/fr.po +++ b/git-gui/po/fr.po @@ -1139,7 +1139,7 @@ msgstr Standard (rapide, semi-redondant, liens durs) #: lib/choose_repository.tcl:514 msgid Full Copy (Slower, Redundant Backup) -msgstr Copy complète (plus lent, sauvegarde redondante) +msgstr Copie complète (plus lent, sauvegarde redondante) #: lib/choose_repository.tcl:520 msgid Shared (Fastest, Not Recommended, No Backup) 2013/5/27 Matthieu Moy matthieu@grenoble-inp.fr: Antoine Pelisse apeli...@gmail.com writes: -msgstr Copie complčte (plus lent, sauvegarde redondante) +msgstr Copy complčte (plus lent, sauvegarde redondante) I still don't get why Copie is replaced by Copy ? Yes, this is clearly wrong. Copie is french, Copy is not. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- 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 v3] credential-osxkeychain: support more protocols
Add protocol imap, imaps, ftp and smtp for credential-osxkeychain.
Signed-off-by: Xidorn Quan quanxunz...@gmail.com
Acked-by: John Szakmeister j...@szakmeister.net
Acked-by: Jeff King p...@peff.net
---
contrib/credential/osxkeychain/git-credential-osxkeychain.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/contrib/credential/osxkeychain/git-credential-osxkeychain.c
b/contrib/credential/osxkeychain/git-credential-osxkeychain.c
index 3940202..bcd3f57 100644
--- a/contrib/credential/osxkeychain/git-credential-osxkeychain.c
+++ b/contrib/credential/osxkeychain/git-credential-osxkeychain.c
@@ -127,10 +127,20 @@ static void read_credential(void)
*v++ = '\0';
if (!strcmp(buf, protocol)) {
- if (!strcmp(v, https))
+ if (!strcmp(v, imap))
+ protocol = kSecProtocolTypeIMAP;
+ else if (!strcmp(v, imaps))
+ protocol = kSecProtocolTypeIMAPS;
+ else if (!strcmp(v, ftp))
+ protocol = kSecProtocolTypeFTP;
+ else if (!strcmp(v, ftps))
+ protocol = kSecProtocolTypeFTPS;
+ else if (!strcmp(v, https))
protocol = kSecProtocolTypeHTTPS;
else if (!strcmp(v, http))
protocol = kSecProtocolTypeHTTP;
+ else if (!strcmp(v, smtp))
+ protocol = kSecProtocolTypeSMTP;
else /* we don't yet handle other protocols */
exit(0);
}
--
1.8.3
--
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
