Re: [PATCH v2] format-patch --signature-file file
On Mon, May 19, 2014 at 10:46:21PM -0700, Jeremiah Mahler wrote: Avoiding that is easy with an indirection, no? Something like this at the top: static const char *the_default_signature = git_version_string; static const char *signature = the_default_signature; and comparing to see if signature points at the same address as the_default_signature would give you what you want, I think. I like your suggestion for a default signature variable. Unfortunately, C doesn't like it as much. static const char *the_default_signature = git_version_string; static const char *signature = the_default_signature; // ERROR // initializer element is not constant You could do: #define DEFAULT_SIGNATURE git_version_string static const char *signature = DEFAULT_SIGNATURE; ... if (signature == DEFAULT_SIGNATURE) ... but maybe that is getting a little unwieldy, considering the scope of the original 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: [PATCH v3 2/5] t4041, t4205, t6006, t7102: Don't hardcode tested encoding value
On Tue, May 20, 2014 at 01:49:31AM +, brian m. carlson wrote: On Mon, May 19, 2014 at 07:28:17PM +0400, Alexey Shumkin wrote: The tested encoding is always available in a variable. Use it instead of hardcoding. Also, to be in line with other tests use ISO8859-1 (uppercase) rather then iso8895-1. You wrote iso8895 when I think you meant iso8859. Oops! Yes, you're right, I've meant iso8859. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 -- Alexey Shumkin E-mail: alex.crez...@gmail.com ICQ: 118001447 Jabber (GoogleTalk): alex.crez...@gmail.com Skype: crezoff -- 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: format-patch crashes with a huge patchset
On Mon, May 19, 2014 at 10:35:56PM +0300, Michael S. Tsirkin wrote: I tried to fump the whole history of qemu with format-patch. It crashes both with v2.0.0-rc2-21-g6087111 and with git 1.8.3.1: ~/opt/libexec/git-core/git-format-patch --follow -o patches/all e63c3dc74bfb90e4522d075d0d5a7600c5145745.. You can't use --follow without specifying a single pathspec. Running git log --follow notices and blocks this, but format-patch doesn't (and segfaults later when the follow code assumes there is a pathspec). I think we need: -- 8 -- Subject: move --follow needs one pathspec rule to diff_setup_done Because of the way --follow is implemented, we must have exactly one pathspec. git log enforces this restriction, but other users of the revision traversal code do not. For example, git format-patch --follow will segfault during try_to_follow_renames, as we have no pathspecs at all. We can push this check down into diff_setup_done, which is probably a better place anyway. It is the diff code that introduces this restriction, so other parts of the code should not need to care themselves. Reported-by: Michael S. Tsirkin m...@redhat.com Signed-off-by: Jeff King p...@peff.net --- I didn't include a test, as I don't think the current behavior is what we want in the long run. That is, it would be nice if eventually --follow learned to be more flexible. Any test for this would necessarily be looking for the opposite of that behavior. But maybe it's worth it to just have in the meantime, and anyone who works on --follow can rip out the test. builtin/log.c | 8 ++-- diff.c| 3 +++ 2 files changed, 5 insertions(+), 6 deletions(-) diff --git a/builtin/log.c b/builtin/log.c index 39e8836..3b6a6bb 100644 --- a/builtin/log.c +++ b/builtin/log.c @@ -158,13 +158,9 @@ static void cmd_log_init_finish(int argc, const char **argv, const char *prefix, if (rev-show_notes) init_display_notes(rev-notes_opt); - if (rev-diffopt.pickaxe || rev-diffopt.filter) + if (rev-diffopt.pickaxe || rev-diffopt.filter || + DIFF_OPT_TST(rev-diffopt, FOLLOW_RENAMES)) rev-always_show_header = 0; - if (DIFF_OPT_TST(rev-diffopt, FOLLOW_RENAMES)) { - rev-always_show_header = 0; - if (rev-diffopt.pathspec.nr != 1) - usage(git logs can only follow renames on one pathname at a time); - } if (source) rev-show_source = 1; diff --git a/diff.c b/diff.c index f72769a..68bb8c5 100644 --- a/diff.c +++ b/diff.c @@ -3325,6 +3325,9 @@ void diff_setup_done(struct diff_options *options) } options-diff_path_counter = 0; + + if (DIFF_OPT_TST(options, FOLLOW_RENAMES) options-pathspec.nr != 1) + die(_(--follow requires exactly one pathspec)); } static int opt_arg(const char *arg, int arg_short, const char *arg_long, int *val) -- 2.0.0.rc1.436.g03cb729 -- 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] rebase -i: test Nothing to do case with autostash
Signed-off-by: Matthieu Moy matthieu@imag.fr --- Ram's patch lacks a test. Here it is. Fails without Ram's patch, and passes with it. Can be squashed into Ram's patch. t/t3420-rebase-autostash.sh | 17 + 1 file changed, 17 insertions(+) diff --git a/t/t3420-rebase-autostash.sh b/t/t3420-rebase-autostash.sh index 90eb264..c2e9a4c 100755 --- a/t/t3420-rebase-autostash.sh +++ b/t/t3420-rebase-autostash.sh @@ -167,4 +167,21 @@ testrebase .git/rebase-apply testrebase --merge .git/rebase-merge testrebase --interactive .git/rebase-merge +test_expect_success 'Abort rebase with --autostash' ' + git log + echo new-content file0 + ( + write_script abort-editor.sh -\EOF + echo $1 + EOF + GIT_EDITOR=\$(pwd)/abort-editor.sh\ + export GIT_EDITOR + test_must_fail git rebase -i --autostash HEAD^ + rm -f abort-editor.sh + ) + git status + echo new-content expected + test_cmp expected file0 +' + test_done -- 2.0.0.rc3.499.gd6dc9ad -- 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] rebase -i: test Nothing to do case with autostash
On Tue, May 20, 2014 at 2:55 AM, Matthieu Moy matthieu@imag.fr wrote: Signed-off-by: Matthieu Moy matthieu@imag.fr --- Ram's patch lacks a test. Here it is. Fails without Ram's patch, and passes with it. Can be squashed into Ram's patch. t/t3420-rebase-autostash.sh | 17 + 1 file changed, 17 insertions(+) diff --git a/t/t3420-rebase-autostash.sh b/t/t3420-rebase-autostash.sh index 90eb264..c2e9a4c 100755 --- a/t/t3420-rebase-autostash.sh +++ b/t/t3420-rebase-autostash.sh @@ -167,4 +167,21 @@ testrebase .git/rebase-apply testrebase --merge .git/rebase-merge testrebase --interactive .git/rebase-merge +test_expect_success 'Abort rebase with --autostash' ' + git log + echo new-content file0 + ( + write_script abort-editor.sh -\EOF + echo $1 + EOF + GIT_EDITOR=\$(pwd)/abort-editor.sh\ + export GIT_EDITOR Simpler (replace above two lines): test_set_editor $(pwd)/abort-editor.sh + test_must_fail git rebase -i --autostash HEAD^ + rm -f abort-editor.sh + ) + git status + echo new-content expected + test_cmp expected file0 +' + test_done -- 2.0.0.rc3.499.gd6dc9ad -- 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] rebase -i: test Nothing to do case with autostash
Signed-off-by: Matthieu Moy matthieu@imag.fr --- Eric Sunshine sunsh...@sunshineco.com writes: Simpler (replace above two lines): test_set_editor $(pwd)/abort-editor.sh Indeed. And I had debug statements left. Hopefully, this after-coffee-v2 will be clear enough and correct ;-). t/t3420-rebase-autostash.sh | 15 +++ 1 file changed, 15 insertions(+) diff --git a/t/t3420-rebase-autostash.sh b/t/t3420-rebase-autostash.sh index 90eb264..ff1e2dc 100755 --- a/t/t3420-rebase-autostash.sh +++ b/t/t3420-rebase-autostash.sh @@ -167,4 +167,19 @@ testrebase .git/rebase-apply testrebase --merge .git/rebase-merge testrebase --interactive .git/rebase-merge +test_expect_success 'abort rebase -i with --autostash' ' + test_when_finished git reset --hard + echo uncommited-content file0 + ( + write_script abort-editor.sh -\EOF + echo $1 + EOF + test_set_editor $(pwd)/abort-editor.sh + test_must_fail git rebase -i --autostash HEAD^ + rm -f abort-editor.sh + ) + echo uncommited-content expected + test_cmp expected file0 +' + test_done -- 2.0.0.rc3.499.gd6dc9ad -- 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 v5] format-patch --signature-file file
Added option that allows a signature file to be used with format-patch so that signatures with newlines and other special characters can be easily included. $ git format-patch --signature-file ~/.signature -1 The config variable format.signaturefile is also provided so that it can be added by default. $ git config format.signaturefile ~/.signature $ git format-patch -1 Signed-off-by: Jeremiah Mahler jmmah...@gmail.com --- Documentation/config.txt | 4 Documentation/git-format-patch.txt | 4 builtin/log.c | 19 ++- t/t4014-format-patch.sh| 32 4 files changed, 58 insertions(+), 1 deletion(-) diff --git a/Documentation/config.txt b/Documentation/config.txt index 1932e9b..140ed77 100644 --- a/Documentation/config.txt +++ b/Documentation/config.txt @@ -1114,6 +1114,10 @@ format.signature:: Set this variable to the empty string () to suppress signature generation. +format.signaturefile:: + Works just like format.signature except the contents of the + file specified by this variable will be used as the signature. + format.suffix:: The default for format-patch is to output files with the suffix `.patch`. Use this variable to change that suffix (make sure to diff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt index 5c0a4ab..c0fd470 100644 --- a/Documentation/git-format-patch.txt +++ b/Documentation/git-format-patch.txt @@ -14,6 +14,7 @@ SYNOPSIS [(--attach|--inline)[=boundary] | --no-attach] [-s | --signoff] [--signature=signature | --no-signature] + [--signature-file=file] [-n | --numbered | -N | --no-numbered] [--start-number n] [--numbered-files] [--in-reply-to=Message-Id] [--suffix=.sfx] @@ -233,6 +234,9 @@ configuration options in linkgit:git-notes[1] to use this workflow). signature option is omitted the signature defaults to the Git version number. +--signature-file=file:: + Works just like --signature except the signature is read from a file. + --suffix=.sfx:: Instead of using `.patch` as the suffix for generated filenames, use specified suffix. A common alternative is diff --git a/builtin/log.c b/builtin/log.c index 39e8836..7ebe302 100644 --- a/builtin/log.c +++ b/builtin/log.c @@ -672,7 +672,9 @@ static void add_header(const char *value) #define THREAD_DEEP 2 static int thread; static int do_signoff; -static const char *signature = git_version_string; +#define DEFAULT_SIGNATURE git_version_string +static const char *signature = DEFAULT_SIGNATURE; +static const char *signature_file; static int config_cover_letter; enum { @@ -742,6 +744,8 @@ static int git_format_config(const char *var, const char *value, void *cb) } if (!strcmp(var, format.signature)) return git_config_string(signature, var, value); + if (!strcmp(var, format.signaturefile)) + return git_config_pathname(signature_file, var, value); if (!strcmp(var, format.coverletter)) { if (value !strcasecmp(value, auto)) { config_cover_letter = COVER_AUTO; @@ -1230,6 +1234,8 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix) PARSE_OPT_OPTARG, thread_callback }, OPT_STRING(0, signature, signature, N_(signature), N_(add a signature)), + OPT_FILENAME(0, signature-file, signature_file, + N_(add a signature from a file)), OPT__QUIET(quiet, N_(don't print the patch filenames)), OPT_END() }; @@ -1447,6 +1453,17 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix) cover_letter = (config_cover_letter == COVER_ON); } + if (signature_file) { + if (signature signature != DEFAULT_SIGNATURE) + die(_(cannot specify both signature and signature-file)); + + struct strbuf buf = STRBUF_INIT; + + if (strbuf_read_file(buf, signature_file, 128) 0) + die_errno(_(unable to read signature file '%s'), signature_file); + signature = strbuf_detach(buf, NULL); + } + if (in_reply_to || thread || cover_letter) rev.ref_message_ids = xcalloc(1, sizeof(struct string_list)); if (in_reply_to) { diff --git a/t/t4014-format-patch.sh b/t/t4014-format-patch.sh index 9c80633..74f0aec 100755 --- a/t/t4014-format-patch.sh +++ b/t/t4014-format-patch.sh @@ -762,6 +762,38 @@ test_expect_success 'format-patch --signature= suppresses signatures' ' ! grep ^-- \$ output ' +cat expect -\EOF + +Test User test.em...@kernel.org
[PATCH v5] format-patch --signature-file file
v5 of patch to add format-patch --signature-file file option. This revision includes more suggestions from Jeff King and Junio C Hamano: - Use git_config_pathname instead of git_config_string for ~ expansion. - Eliminated head/tail --lines which is not POSIX compliant. Replaced with sed equivalents. - Used test_config instead of git config which also handles unsetting. - Use a DEFAULT_SIGNATURE variable to better describe its purpose instead of git_version_string which could be confusing. Jeremiah Mahler (1): format-patch --signature-file file Documentation/config.txt | 4 Documentation/git-format-patch.txt | 4 builtin/log.c | 19 ++- t/t4014-format-patch.sh| 32 4 files changed, 58 insertions(+), 1 deletion(-) -- Jeremiah Mahler jmmah...@gmail.com http://github.com/jmahler -- 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 v5] format-patch --signature-file file
On Tue, May 20, 2014 at 01:00:06AM -0700, Jeremiah Mahler wrote: Added option that allows a signature file to be used with format-patch so that signatures with newlines and other special characters can be easily included. $ git format-patch --signature-file ~/.signature -1 The config variable format.signaturefile is also provided so that it can be added by default. $ git config format.signaturefile ~/.signature $ git format-patch -1 Signed-off-by: Jeremiah Mahler jmmah...@gmail.com Thanks for keeping at it. This looks good, but I have one question: +test_expect_success 'format-patch --signature-file=file' ' + git format-patch --stdout --signature-file=expect -1 output + check_patch output + sed -n -e /^-- $/,\$p output | sed -e 1 d | sed -e \$d | sed -e \$d output2 + test_cmp expect output2 +' Here we drop two final lines from the email output. But if I just use vanilla git and try this, I get nothing: $ git format-patch -1 --stdout | sed -n -e /^-- $/,\$p | sed -e 1 d | sed -e \$d | sed -e \$d Removing the second dropped line works: $ git format-patch -1 --stdout | sed -n -e /^-- $/,\$p | sed -e 1 d | sed -e \$d 2.0.0.rc1.436.g03cb729 I guess the signature code is adding its own newline, so that the default signature (or --signature=foo) works. But it adds it unconditionally, which is probably not what we want for signatures read from a file. Do we maybe want something like this right before your patch? -- 8 -- Subject: format-patch: make newline after signature conditional When we print an email signature, we print the divider -- \n, then the signature string, then two newlines. Traditionally the signature is a one-liner (and the default is just the git version), so the extra newline makes sense. But one could easily specify a longer, multi-line signature, like: git format-patch --signature=' this is my long signature it has multiple lines ' ... We should notice that it already has its own trailing newline, and suppress one of ours. Signed-off-by: Jeff King p...@peff.net --- In the example above, there's also a newline before the signature starts. Should we suppress the first one, too? Also, I'm not clear on the purpose of the extra trailing line in the first place. Emails now end with ( added to show blanks): -- 2.0.0-rc3... Is there are a reason for that final blank line? builtin/log.c | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/builtin/log.c b/builtin/log.c index 39e8836..5acc048 100644 --- a/builtin/log.c +++ b/builtin/log.c @@ -844,8 +844,13 @@ static void gen_message_id(struct rev_info *info, char *base) static void print_signature(void) { - if (signature *signature) - printf(-- \n%s\n\n, signature); + if (!signature || !*signature) + return; + + printf(-- \n%s, signature); + if (signature[strlen(signature)-1] != '\n') + putchar('\n'); + putchar('\n'); } static void add_branch_description(struct strbuf *buf, const char *branch_name) -- 2.0.0.rc1.436.g03cb729 -- 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: [msysGit] Re: [PATCH/RFC] send-pack.c: Allow to disable side-band-64k
On Tue, May 20, 2014 at 10:46 AM, Thomas Braun thomas.br...@byte-physics.de wrote: Am 19.05.2014 22:29, schrieb Erik Faye-Lund: [...] Would we need to wrap both ends, shouldn't wrapping only reading be good enough to prevent deadlocking? compat/poll/poll.c already contains a function called IsSocketHandle that is able to tell if a HANDLE points to a socket or not. This very quick attempt did not work out :( diff --git a/compat/mingw.c b/compat/mingw.c index 0335958..ec1d81f 100644 --- a/compat/mingw.c +++ b/compat/mingw.c @@ -370,6 +370,65 @@ int mingw_open (const char *filename, int oflags, ...) return fd; } +#define is_console_handle(h) (((long) (h) 3) == 3) + +static int is_socket_handle(HANDLE h) +{ +WSANETWORKEVENTS ev; + +if (is_console_handle(h)) +return 0; + +/* + * Under Wine, it seems that getsockopt returns 0 for pipes too. + * WSAEnumNetworkEvents instead distinguishes the two correctly. + */ +ev.lNetworkEvents = 0xDEADBEEF; +WSAEnumNetworkEvents((SOCKET) h, NULL, ev); +return ev.lNetworkEvents != 0xDEADBEEF; +} + +#undef read +ssize_t mingw_read(int fd, void *buf, size_t count) +{ +int ret; +HANDLE fh = (HANDLE)_get_osfhandle(fd); + +if (fh == INVALID_HANDLE_VALUE) { +errno = EBADF; +return -1; +} + +if (!is_socket_handle(fh)) +return read(fd, buf, count); + +ret = recv((SOCKET)fh, buf, count, 0); +if (ret 0) +errno = WSAGetLastError(); +return ret; +} + +#undef write +ssize_t mingw_write(int fd, const void *buf, size_t count) +{ +int ret; +HANDLE fh = (HANDLE)_get_osfhandle(fd); + +if (fh == INVALID_HANDLE_VALUE) { +errno = EBADF; +return -1; +} + +if (!is_socket_handle(fh)) +return write(fd, buf, count); + +return send((SOCKET)fh, buf, count, 0); +if (ret 0) +errno = WSAGetLastError(); +return ret; +} + + static BOOL WINAPI ctrl_ignore(DWORD type) { return TRUE; diff --git a/compat/mingw.h b/compat/mingw.h index 08b83fe..1690098 100644 --- a/compat/mingw.h +++ b/compat/mingw.h @@ -177,6 +177,12 @@ int mingw_rmdir(const char *path); int mingw_open (const char *filename, int oflags, ...); #define open mingw_open +ssize_t mingw_read(int fd, void *buf, size_t count); +#define read mingw_read + +ssize_t mingw_write(int fd, const void *buf, size_t count); +#define write mingw_write + int mingw_fgetc(FILE *stream); #define fgetc mingw_fgetc According to [1] you also have to pass WSA_FLAG_OVERLAPPED to avoid the deadlock. With that change I don't get a hang anymore but a read error with errno 10054 aka WSAECONNRESET. [1]: https://groups.google.com/forum/#!msg/msysgit/at8D7J-h7mw/PM9w-d41cDYJ Yeah, sorry, I noticed this right after sending and tested with that as well. My results were the same :/ -- 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] remote: defer repacking packed-refs when deleting refs
When 'git remote rm' or 'git remote prune' were used in a repository with many refs, and needed to delete many refs, a lot of time was spent deleting those refs since for each deleted ref, repack_without_refs() was called to rewrite packed-refs without just that deleted ref. To avoid this, defer the repacking until after all refs have been deleted (by delete_ref()), and then call repack_without_refs() once to repack without all the deleted refs. Signed-off-by: Jens Lindström j...@opera.com --- This patch changes behavior when the operation is aborted in the middle, so that loose refs and ref logs might have been deleted, but not the corresponding entries in packed-refs, since packed-refs is now only updated at the end. This is a bit unfortunate, and may resurrect an obsolete packed-refs entry by deleting the loose ref that had overridden it. Mitigating factors would be that this only affects remote tracking branches that we were about to delete anyway, and that in the case of 'git remote prune' were apparently not actually matching a ref in the remote. Also, it is a lot harder to interrupt the operation in the middle when it takes a few seconds compared to when it takes many minutes to complete. :-) builtin/remote.c | 19 --- refs.c | 15 +-- refs.h | 3 +++ 3 files changed, 28 insertions(+), 9 deletions(-) diff --git a/builtin/remote.c b/builtin/remote.c index b3ab4cf..ce60a30 100644 --- a/builtin/remote.c +++ b/builtin/remote.c @@ -749,15 +749,18 @@ static int mv(int argc, const char **argv) static int remove_branches(struct string_list *branches) { + const char **branch_names = xmalloc(branches-nr * sizeof(*branch_names)); int i, result = 0; for (i = 0; i branches-nr; i++) { struct string_list_item *item = branches-items + i; - const char *refname = item-string; + const char *refname = branch_names[i] = item-string; unsigned char *sha1 = item-util; - if (delete_ref(refname, sha1, 0)) + if (delete_ref(refname, sha1, REF_DEFERREPACK)) result |= error(_(Could not remove branch %s), refname); } + result |= repack_without_refs(branch_names, branches-nr); + free(branch_names); return result; } @@ -1303,6 +1306,7 @@ static int prune_remote(const char *remote, int dry_run) { int result = 0, i; struct ref_states states; + const char **delete_refs; const char *dangling_msg = dry_run ? _( %s will become dangling!) : _( %s has become dangling!); @@ -1316,13 +1320,16 @@ static int prune_remote(const char *remote, int dry_run) states.remote-url_nr ? states.remote-url[0] : _((no URL))); + delete_refs = xmalloc(states.stale.nr * sizeof(*delete_refs)); } for (i = 0; i states.stale.nr; i++) { const char *refname = states.stale.items[i].util; + delete_refs[i] = refname; + if (!dry_run) - result |= delete_ref(refname, NULL, 0); + result |= delete_ref(refname, NULL, REF_DEFERREPACK); if (dry_run) printf_ln(_( * [would prune] %s), @@ -1333,6 +1340,12 @@ static int prune_remote(const char *remote, int dry_run) warn_dangling_symref(stdout, dangling_msg, refname); } + if (states.stale.nr) { + if (!dry_run) + result |= repack_without_refs(delete_refs, states.stale.nr); + free(delete_refs); + } + free_remote_ref_states(states); return result; } diff --git a/refs.c b/refs.c index 28d5eca..3b62aca 100644 --- a/refs.c +++ b/refs.c @@ -2431,7 +2431,7 @@ static int curate_packed_ref_fn(struct ref_entry *entry, void *cb_data) return 0; } -static int repack_without_refs(const char **refnames, int n) +int repack_without_refs(const char **refnames, int n) { struct ref_dir *packed; struct string_list refs_to_delete = STRING_LIST_INIT_DUP; @@ -2507,11 +2507,14 @@ int delete_ref(const char *refname, const unsigned char *sha1, int delopt) return 1; ret |= delete_ref_loose(lock, flag); - /* removing the loose one could have resurrected an earlier -* packed one. Also, if it was not loose we need to repack -* without it. -*/ - ret |= repack_without_ref(lock-ref_name); + if (!(delopt REF_DEFERREPACK)) + { + /* removing the loose one could have resurrected an earlier +* packed one. Also, if it was not loose we need to repack +* without it. +*/ + ret |= repack_without_ref(lock-ref_name); + } unlink_or_warn(git_path(logs/%s,
[PATCH 2/2] remote prune: optimize dangling symref check/warning
When 'git remote prune' was used to delete many refs in a repository with many refs, a lot of time was spent checking for (now) dangling symbolic refs pointing to the deleted ref, since warn_dangling_symref() was once per deleted ref to check all other refs in the repository. Avoid this using the new warn_dangling_symrefs() function which makes one pass over all refs and checks for all the deleted refs in one go, after they have all been deleted. Signed-off-by: Jens Lindström j...@opera.com --- builtin/remote.c | 6 +- refs.c | 19 ++- refs.h | 1 + 3 files changed, 24 insertions(+), 2 deletions(-) diff --git a/builtin/remote.c b/builtin/remote.c index ce60a30..5e4a8dd 100644 --- a/builtin/remote.c +++ b/builtin/remote.c @@ -1306,6 +1306,7 @@ static int prune_remote(const char *remote, int dry_run) { int result = 0, i; struct ref_states states; + struct string_list delete_refs_list = STRING_LIST_INIT_NODUP; const char **delete_refs; const char *dangling_msg = dry_run ? _( %s will become dangling!) @@ -1327,6 +1328,7 @@ static int prune_remote(const char *remote, int dry_run) const char *refname = states.stale.items[i].util; delete_refs[i] = refname; + string_list_insert(delete_refs_list, refname); if (!dry_run) result |= delete_ref(refname, NULL, REF_DEFERREPACK); @@ -1337,9 +1339,11 @@ static int prune_remote(const char *remote, int dry_run) else printf_ln(_( * [pruned] %s), abbrev_ref(refname, refs/remotes/)); - warn_dangling_symref(stdout, dangling_msg, refname); } + warn_dangling_symrefs(stdout, dangling_msg, delete_refs_list); + string_list_clear(delete_refs_list, 0); + if (states.stale.nr) { if (!dry_run) result |= repack_without_refs(delete_refs, states.stale.nr); diff --git a/refs.c b/refs.c index 3b62aca..fdd8b74 100644 --- a/refs.c +++ b/refs.c @@ -1611,6 +1611,7 @@ int peel_ref(const char *refname, unsigned char *sha1) struct warn_if_dangling_data { FILE *fp; const char *refname; + const struct string_list *refnames; const char *msg_fmt; }; @@ -1625,8 +1626,12 @@ static int warn_if_dangling_symref(const char *refname, const unsigned char *sha return 0; resolves_to = resolve_ref_unsafe(refname, junk, 0, NULL); - if (!resolves_to || strcmp(resolves_to, d-refname)) + if (!resolves_to + || (d-refname + ? strcmp(resolves_to, d-refname) + : !string_list_has_string(d-refnames, resolves_to))) { return 0; + } fprintf(d-fp, d-msg_fmt, refname); fputc('\n', d-fp); @@ -1639,6 +1644,18 @@ void warn_dangling_symref(FILE *fp, const char *msg_fmt, const char *refname) data.fp = fp; data.refname = refname; + data.refnames = NULL; + data.msg_fmt = msg_fmt; + for_each_rawref(warn_if_dangling_symref, data); +} + +void warn_dangling_symrefs(FILE *fp, const char *msg_fmt, const struct string_list *refnames) +{ + struct warn_if_dangling_data data; + + data.fp = fp; + data.refname = NULL; + data.refnames = refnames; data.msg_fmt = msg_fmt; for_each_rawref(warn_if_dangling_symref, data); } diff --git a/refs.h b/refs.h index 0db5584..cd4710d 100644 --- a/refs.h +++ b/refs.h @@ -89,7 +89,7 @@ static inline const char *has_glob_specials(const char *pattern) extern int for_each_rawref(each_ref_fn, void *); extern void warn_dangling_symref(FILE *fp, const char *msg_fmt, const char *refname); +extern void warn_dangling_symrefs(FILE *fp, const char *msg_fmt, const struct string_list* refnames); /* * Lock the packed-refs file for writing. Flags is passed to -- 1.9.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 09/19] git-rebase--interactive.sh: convert test -a/-o to and ||
The interaction with unary operators and operator precedence for and || are better known than -a and -o, and for that reason we prefer them. Replace all existing instances of -a and -o to save readers from the burden of thinking about such things. Signed-off-by: Elia Pinto gitter.spi...@gmail.com --- git-rebase--interactive.sh |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh index 6ec9d3c..797571f 100644 --- a/git-rebase--interactive.sh +++ b/git-rebase--interactive.sh @@ -1013,7 +1013,7 @@ then git rev-list $revisions | while read rev do - if test -f $rewritten/$rev -a $(sane_grep $rev $state_dir/not-cherry-picks) = + if test -f $rewritten/$rev test $(sane_grep $rev $state_dir/not-cherry-picks) = then # Use -f2 because if rev-list is telling us this commit is # not worthwhile, we don't want to track its multiple heads, -- 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
[PATCH 07/19] git-bisect.sh: convert test -a/-o to and ||
The interaction with unary operators and operator precedence for and || are better known than -a and -o, and for that reason we prefer them. Replace all existing instances of -a and -o to save readers from the burden of thinking about such things. Signed-off-by: Elia Pinto gitter.spi...@gmail.com --- git-bisect.sh |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/git-bisect.sh b/git-bisect.sh index af4d04c..1e0d602 100755 --- a/git-bisect.sh +++ b/git-bisect.sh @@ -408,7 +408,7 @@ bisect_replay () { bisect_reset while read git bisect command rev do - test $git $bisect = git bisect -o $git = git-bisect || continue + test $git $bisect = git bisect || test $git = git-bisect || continue if test $git = git-bisect then rev=$command -- 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
[PATCH 06/19] contrib/examples/git-resolve.sh: convert test -a/-o to and ||
The interaction with unary operators and operator precedence for and || are better known than -a and -o, and for that reason we prefer them. Replace all existing instances of -a and -o to save readers from the burden of thinking about such things. Signed-off-by: Elia Pinto gitter.spi...@gmail.com --- contrib/examples/git-resolve.sh |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/contrib/examples/git-resolve.sh b/contrib/examples/git-resolve.sh index 48d0fc9..70fdc27 100755 --- a/contrib/examples/git-resolve.sh +++ b/contrib/examples/git-resolve.sh @@ -76,7 +76,7 @@ case $common in 2/dev/null || continue # Count the paths that are unmerged. cnt=$(GIT_INDEX_FILE=$G git ls-files --unmerged | wc -l) - if test $best_cnt -le 0 -o $cnt -le $best_cnt + if test $best_cnt -le 0 || test $cnt -le $best_cnt then best=$c best_cnt=$cnt -- 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
[PATCH 02/19] contrib/examples/git-clone.sh: convert test -a/-o to and ||
The interaction with unary operators and operator precedence for and || are better known than -a and -o, and for that reason we prefer them. Replace all existing instances of -a and -o to save readers from the burden of thinking about such things. Signed-off-by: Elia Pinto gitter.spi...@gmail.com --- contrib/examples/git-clone.sh |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/contrib/examples/git-clone.sh b/contrib/examples/git-clone.sh index b4c9376..08cf246 100755 --- a/contrib/examples/git-clone.sh +++ b/contrib/examples/git-clone.sh @@ -516,7 +516,7 @@ then case $no_checkout in '') - test z$quiet = z -a z$no_progress = z v=-v || v= + test z$quiet = z test z$no_progress = z v=-v || v= git read-tree -m -u $v HEAD HEAD esac fi -- 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
[PATCH 00/19] convert test -a/-o to and || patch series
These patch series convert test -a/-o to and ||. This is the second version. Changes: - Modified commit comment based on Jonathan Nieder suggestions (was don't use the -a or -o option with the test command) - Modified patch on git-submodule.sh based on Jonathan Nieder suggestions Elia Pinto (19): check_bindir: convert test -a/-o to and || contrib/examples/git-clone.sh: convert test -a/-o to and || contrib/examples/git-commit.sh: convert test -a/-o to and || contrib/examples/git-merge.sh: convert test -a/-o to and || contrib/examples/git-repack.sh: convert test -a/-o to and || contrib/examples/git-resolve.sh: convert test -a/-o to and || git-bisect.sh: convert test -a/-o to and || git-mergetool.sh: convert test -a/-o to and || git-rebase--interactive.sh: convert test -a/-o to and || git-submodule.sh: convert test -a/-o to and || t/t0025-crlf-auto.sh: convert test -a/-o to and || t/t0026-eol-config.sh: convert test -a/-o to and || t/t4102-apply-rename.sh: convert test -a/-o to and || t/t5000-tar-tree.sh: convert test -a/-o to and || t/t5403-post-checkout-hook.sh: convert test -a/-o to and || t/t5537-fetch-shallow.sh: convert test -a/-o to and || t/t5538-push-shallow.sh: convert test -a/-o to and || t/t9814-git-p4-rename.sh: convert test -a/-o to and || t/test-lib-functions.sh: convert test -a/-o to and || check_bindir|2 +- contrib/examples/git-clone.sh |2 +- contrib/examples/git-commit.sh |4 ++-- contrib/examples/git-merge.sh |4 ++-- contrib/examples/git-repack.sh |4 ++-- contrib/examples/git-resolve.sh |2 +- git-bisect.sh |2 +- git-mergetool.sh|4 ++-- git-rebase--interactive.sh |2 +- git-submodule.sh| 29 + t/t0025-crlf-auto.sh|6 +++--- t/t0026-eol-config.sh |8 t/t4102-apply-rename.sh |2 +- t/t5000-tar-tree.sh |2 +- t/t5403-post-checkout-hook.sh |8 t/t5537-fetch-shallow.sh|2 +- t/t5538-push-shallow.sh |2 +- t/t9814-git-p4-rename.sh|4 ++-- t/test-lib-functions.sh |4 ++-- 19 files changed, 49 insertions(+), 44 deletions(-) -- 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
[PATCH 04/19] contrib/examples/git-merge.sh: convert test -a/-o to and ||
The interaction with unary operators and operator precedence for and || are better known than -a and -o, and for that reason we prefer them. Replace all existing instances of -a and -o to save readers from the burden of thinking about such things. Signed-off-by: Elia Pinto gitter.spi...@gmail.com --- contrib/examples/git-merge.sh |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/contrib/examples/git-merge.sh b/contrib/examples/git-merge.sh index 7e40f40..52f2aaf 100755 --- a/contrib/examples/git-merge.sh +++ b/contrib/examples/git-merge.sh @@ -161,7 +161,7 @@ merge_name () { return fi fi - if test $remote = FETCH_HEAD -a -r $GIT_DIR/FETCH_HEAD + if test $remote = FETCH_HEAD test -r $GIT_DIR/FETCH_HEAD then sed -e 's/ not-for-merge / /' -e 1q \ $GIT_DIR/FETCH_HEAD @@ -527,7 +527,7 @@ do git diff-files --name-only git ls-files --unmerged } | wc -l` - if test $best_cnt -le 0 -o $cnt -le $best_cnt + if test $best_cnt -le 0 || test $cnt -le $best_cnt then best_strategy=$strategy best_cnt=$cnt -- 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
[PATCH 13/19] t/t4102-apply-rename.sh: convert test -a/-o to and ||
The interaction with unary operators and operator precedence for and || are better known than -a and -o, and for that reason we prefer them. Replace all existing instances of -a and -o to save readers from the burden of thinking about such things. Signed-off-by: Elia Pinto gitter.spi...@gmail.com --- t/t4102-apply-rename.sh |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/t/t4102-apply-rename.sh b/t/t4102-apply-rename.sh index 49e2d6c..fae3059 100755 --- a/t/t4102-apply-rename.sh +++ b/t/t4102-apply-rename.sh @@ -52,6 +52,6 @@ EOF test_expect_success 'apply copy' \ 'git apply --index --stat --summary --apply test-patch - test $(cat bar) = This is bar -a $(cat foo) = This is foo' + test $(cat bar) = This is bar test $(cat foo) = This is foo' test_done -- 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
[PATCH 10/19] git-submodule.sh: convert test -a/-o to and ||
The interaction with unary operators and operator precedence for and || are better known than -a and -o, and for that reason we prefer them. Replace all existing instances of -a and -o to save readers from the burden of thinking about such things. Signed-off-by: Elia Pinto gitter.spi...@gmail.com --- git-submodule.sh | 29 + 1 file changed, 17 insertions(+), 12 deletions(-) diff --git a/git-submodule.sh b/git-submodule.sh index b55d83a..4b57b96 100755 --- a/git-submodule.sh +++ b/git-submodule.sh @@ -396,7 +396,7 @@ cmd_add() sed -e 's|/$||' -e 's|:*/*\.git$||' -e 's|.*[/:]||g') fi - if test -z $repo -o -z $sm_path; then + if test -z $repo || test -z $sm_path; then usage fi @@ -453,7 +453,7 @@ Use -f if you really want to add it. 2 # perhaps the path exists and is already a git repo, else clone it if test -e $sm_path then - if test -d $sm_path/.git -o -f $sm_path/.git + if test -d $sm_path/.git || test -f $sm_path/.git then eval_gettextln Adding existing repo at '\$sm_path' to the index else @@ -835,7 +835,7 @@ Maybe you want to use 'update --init'?) continue fi - if ! test -d $sm_path/.git -o -f $sm_path/.git + if ! test -d $sm_path/.git || test -f $sm_path/.git then module_clone $sm_path $name $url $reference $depth || exit cloned_modules=$cloned_modules;$name @@ -860,11 +860,11 @@ Maybe you want to use 'update --init'?) die $(eval_gettext Unable to find current ${remote_name}/${branch} revision in submodule path '\$sm_path') fi - if test $subsha1 != $sha1 -o -n $force + if test $subsha1 != $sha1 || test -n $force then subforce=$force # If we don't already have a -f flag and the submodule has never been checked out - if test -z $subsha1 -a -z $force + if test -z $subsha1 || test -z $force then subforce=-f fi @@ -1034,7 +1034,7 @@ cmd_summary() { then head=$rev test $# = 0 || shift - elif test -z $1 -o $1 = HEAD + elif test -z $1 || test $1 = HEAD then # before the first commit: compare with an empty tree head=$(git hash-object -w -t tree --stdin /dev/null) @@ -1059,13 +1059,18 @@ cmd_summary() { while read mod_src mod_dst sha1_src sha1_dst status sm_path do # Always show modules deleted or type-changed (blob-module) - test $status = D -o $status = T echo $sm_path continue + { + test $status = D || + test $status = T + } + echo $sm_path +continue # Respect the ignore setting for --for-status. if test -n $for_status then name=$(module_name $sm_path) ignore_config=$(get_submodule_config $name ignore none) - test $status != A -a $ignore_config = all continue + test $status != A test $ignore_config = all continue fi # Also show added or modified modules which are checked out GIT_DIR=$sm_path/.git git-rev-parse --git-dir /dev/null 21 @@ -1125,7 +1130,7 @@ cmd_summary() { *) errmsg= total_commits=$( - if test $mod_src = 16 -a $mod_dst = 16 + if test $mod_src = 16 test $mod_dst = 16 then range=$sha1_src...$sha1_dst elif test $mod_src = 16 @@ -1162,7 +1167,7 @@ cmd_summary() { # i.e. deleted or changed to blob test $mod_dst = 16 echo $errmsg else - if test $mod_src = 16 -a $mod_dst = 16 + if test $mod_src = 16 test $mod_dst = 16 then limit= test $summary_limit -gt 0 limit=-$summary_limit @@ -1233,7 +1238,7 @@ cmd_status() say U$sha1 $displaypath continue fi - if test -z $url || ! test -d $sm_path/.git -o -f $sm_path/.git + if
[PATCH 17/19] t/t5538-push-shallow.sh: convert test -a/-o to and ||
The interaction with unary operators and operator precedence for and || are better known than -a and -o, and for that reason we prefer them. Replace all existing instances of -a and -o to save readers from the burden of thinking about such things. Signed-off-by: Elia Pinto gitter.spi...@gmail.com --- t/t5538-push-shallow.sh |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/t/t5538-push-shallow.sh b/t/t5538-push-shallow.sh index 8e54ac5..63d9ca9 100755 --- a/t/t5538-push-shallow.sh +++ b/t/t5538-push-shallow.sh @@ -121,7 +121,7 @@ EOF ) ' -if test -n $NO_CURL -o -z $GIT_TEST_HTTPD; then +if test -n $NO_CURL || test -z $GIT_TEST_HTTPD; then say 'skipping remaining tests, git built without http support' test_done fi -- 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
[PATCH 05/19] contrib/examples/git-repack.sh: convert test -a/-o to and ||
The interaction with unary operators and operator precedence for and || are better known than -a and -o, and for that reason we prefer them. Replace all existing instances of -a and -o to save readers from the burden of thinking about such things. Signed-off-by: Elia Pinto gitter.spi...@gmail.com --- contrib/examples/git-repack.sh |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/contrib/examples/git-repack.sh b/contrib/examples/git-repack.sh index f312405..96e3fed 100755 --- a/contrib/examples/git-repack.sh +++ b/contrib/examples/git-repack.sh @@ -76,8 +76,8 @@ case ,$all_into_one, in existing=$existing $e fi done - if test -n $existing -a -n $unpack_unreachable -a \ - -n $remove_redundant + if test -n $existing test -n $unpack_unreachable \ + test -n $remove_redundant then # This may have arbitrary user arguments, so we # have to protect it against whitespace splitting -- 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
[PATCH 19/19] t/test-lib-functions.sh: convert test -a/-o to and ||
The interaction with unary operators and operator precedence for and || are better known than -a and -o, and for that reason we prefer them. Replace all existing instances of -a and -o to save readers from the burden of thinking about such things. Signed-off-by: Elia Pinto gitter.spi...@gmail.com --- t/test-lib-functions.sh |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/t/test-lib-functions.sh b/t/test-lib-functions.sh index 158e10a..0681003 100644 --- a/t/test-lib-functions.sh +++ b/t/test-lib-functions.sh @@ -542,7 +542,7 @@ test_must_fail () { if test $exit_code = 0; then echo 2 test_must_fail: command succeeded: $* return 1 - elif test $exit_code -gt 129 -a $exit_code -le 192; then + elif test $exit_code -gt 129 test $exit_code -le 192; then echo 2 test_must_fail: died by signal: $* return 1 elif test $exit_code = 127; then @@ -569,7 +569,7 @@ test_must_fail () { test_might_fail () { $@ exit_code=$? - if test $exit_code -gt 129 -a $exit_code -le 192; then + if test $exit_code -gt 129 test $exit_code -le 192; then echo 2 test_might_fail: died by signal: $* return 1 elif test $exit_code = 127; then -- 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
[PATCH 12/19] t/t0026-eol-config.sh: convert test -a/-o to and ||
The interaction with unary operators and operator precedence for and || are better known than -a and -o, and for that reason we prefer them. Replace all existing instances of -a and -o to save readers from the burden of thinking about such things. Signed-off-by: Elia Pinto gitter.spi...@gmail.com --- t/t0026-eol-config.sh |8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/t/t0026-eol-config.sh b/t/t0026-eol-config.sh index fe0164b..961ee32 100755 --- a/t/t0026-eol-config.sh +++ b/t/t0026-eol-config.sh @@ -36,7 +36,7 @@ test_expect_success 'eol=lf puts LFs in normalized file' ' ! has_cr two onediff=`git diff one` twodiff=`git diff two` - test -z $onediff -a -z $twodiff + test -z $onediff test -z $twodiff ' test_expect_success 'eol=crlf puts CRLFs in normalized file' ' @@ -49,7 +49,7 @@ test_expect_success 'eol=crlf puts CRLFs in normalized file' ' ! has_cr two onediff=`git diff one` twodiff=`git diff two` - test -z $onediff -a -z $twodiff + test -z $onediff test -z $twodiff ' test_expect_success 'autocrlf=true overrides eol=lf' ' @@ -63,7 +63,7 @@ test_expect_success 'autocrlf=true overrides eol=lf' ' has_cr two onediff=`git diff one` twodiff=`git diff two` - test -z $onediff -a -z $twodiff + test -z $onediff test -z $twodiff ' test_expect_success 'autocrlf=true overrides unset eol' ' @@ -77,7 +77,7 @@ test_expect_success 'autocrlf=true overrides unset eol' ' has_cr two onediff=`git diff one` twodiff=`git diff two` - test -z $onediff -a -z $twodiff + test -z $onediff test -z $twodiff ' test_done -- 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
[PATCH 14/19] t/t5000-tar-tree.sh: convert test -a/-o to and ||
The interaction with unary operators and operator precedence for and || are better known than -a and -o, and for that reason we prefer them. Replace all existing instances of -a and -o to save readers from the burden of thinking about such things. Signed-off-by: Elia Pinto gitter.spi...@gmail.com --- t/t5000-tar-tree.sh |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/t/t5000-tar-tree.sh b/t/t5000-tar-tree.sh index 1cf0a4e..4b57cbd 100755 --- a/t/t5000-tar-tree.sh +++ b/t/t5000-tar-tree.sh @@ -72,7 +72,7 @@ check_tar() { for header in *.paxheader do data=${header%.paxheader}.data - if test -h $data -o -e $data + if test -h $data || test -e $data then path=$(get_pax_header $header path) if test -n $path -- 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
[PATCH 18/19] t/t9814-git-p4-rename.sh: convert test -a/-o to and ||
The interaction with unary operators and operator precedence for and || are better known than -a and -o, and for that reason we prefer them. Replace all existing instances of -a and -o to save readers from the burden of thinking about such things. Signed-off-by: Elia Pinto gitter.spi...@gmail.com --- t/t9814-git-p4-rename.sh |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/t/t9814-git-p4-rename.sh b/t/t9814-git-p4-rename.sh index be802e0..1fc1f5f 100755 --- a/t/t9814-git-p4-rename.sh +++ b/t/t9814-git-p4-rename.sh @@ -177,7 +177,7 @@ test_expect_success 'detect copies' ' level=$(git diff-tree -r -C --find-copies-harder HEAD | sed 1d | cut -f1 | cut -d -f5 | sed s/C0*//) test -n $level test $level -gt 0 test $level -lt 98 src=$(git diff-tree -r -C --find-copies-harder HEAD | sed 1d | cut -f2) - test $src = file10 -o $src = file11 + test $src = file10 || test $src = file11 git config git-p4.detectCopies $(($level + 2)) git p4 submit p4 filelog //depot/file12 @@ -191,7 +191,7 @@ test_expect_success 'detect copies' ' level=$(git diff-tree -r -C --find-copies-harder HEAD | sed 1d | cut -f1 | cut -d -f5 | sed s/C0*//) test -n $level test $level -gt 2 test $level -lt 100 src=$(git diff-tree -r -C --find-copies-harder HEAD | sed 1d | cut -f2) - test $src = file10 -o $src = file11 -o $src = file12 + test $src = file10 || test $src = file11 || test $src = file12 git config git-p4.detectCopies $(($level - 2)) git p4 submit p4 filelog //depot/file13 -- 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
[PATCH 08/19] git-mergetool.sh: convert test -a/-o to and ||
The interaction with unary operators and operator precedence for and || are better known than -a and -o, and for that reason we prefer them. Replace all existing instances of -a and -o to save readers from the burden of thinking about such things. Signed-off-by: Elia Pinto gitter.spi...@gmail.com --- git-mergetool.sh |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/git-mergetool.sh b/git-mergetool.sh index 332528f..88e853f 100755 --- a/git-mergetool.sh +++ b/git-mergetool.sh @@ -205,7 +205,7 @@ checkout_staged_file () { $(git checkout-index --temp --stage=$1 $2 2/dev/null) \ : '\([^ ]*\)') - if test $? -eq 0 -a -n $tmpfile + if test $? -eq 0 test -n $tmpfile then mv -- $(git rev-parse --show-cdup)$tmpfile $3 else @@ -256,7 +256,7 @@ merge_file () { checkout_staged_file 2 $MERGED $LOCAL checkout_staged_file 3 $MERGED $REMOTE - if test -z $local_mode -o -z $remote_mode + if test -z $local_mode || test -z $remote_mode then echo Deleted merge conflict for '$MERGED': describe_file $local_mode local $LOCAL -- 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
[PATCH 03/19] contrib/examples/git-commit.sh: convert test -a/-o to and ||
The interaction with unary operators and operator precedence for and || are better known than -a and -o, and for that reason we prefer them. Replace all existing instances of -a and -o to save readers from the burden of thinking about such things. Signed-off-by: Elia Pinto gitter.spi...@gmail.com --- contrib/examples/git-commit.sh |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/contrib/examples/git-commit.sh b/contrib/examples/git-commit.sh index 5cafe2e..934505b 100755 --- a/contrib/examples/git-commit.sh +++ b/contrib/examples/git-commit.sh @@ -51,7 +51,7 @@ run_status () { export GIT_INDEX_FILE fi - if test $status_only = t -o $use_status_color = t; then + if test $status_only = t || test $use_status_color = t; then color= else color=--nocolor @@ -296,7 +296,7 @@ t,,,[1-9]*) die No paths with -i does not make sense. ;; esac -if test ! -z $templatefile -a -z $log_given +if test ! -z $templatefile test -z $log_given then if test ! -f $templatefile then -- 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
[PATCH 15/19] t/t5403-post-checkout-hook.sh: convert test -a/-o to and ||
The interaction with unary operators and operator precedence for and || are better known than -a and -o, and for that reason we prefer them. Replace all existing instances of -a and -o to save readers from the burden of thinking about such things. Signed-off-by: Elia Pinto gitter.spi...@gmail.com --- t/t5403-post-checkout-hook.sh |8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/t/t5403-post-checkout-hook.sh b/t/t5403-post-checkout-hook.sh index 1753ef2..fc898c9 100755 --- a/t/t5403-post-checkout-hook.sh +++ b/t/t5403-post-checkout-hook.sh @@ -39,7 +39,7 @@ test_expect_success 'post-checkout receives the right arguments with HEAD unchan old=$(awk {print \$1} clone1/.git/post-checkout.args) new=$(awk {print \$2} clone1/.git/post-checkout.args) flag=$(awk {print \$3} clone1/.git/post-checkout.args) - test $old = $new -a $flag = 1 + test $old = $new test $flag = 1 ' test_expect_success 'post-checkout runs as expected ' ' @@ -52,7 +52,7 @@ test_expect_success 'post-checkout args are correct with git checkout -b ' ' old=$(awk {print \$1} clone1/.git/post-checkout.args) new=$(awk {print \$2} clone1/.git/post-checkout.args) flag=$(awk {print \$3} clone1/.git/post-checkout.args) - test $old = $new -a $flag = 1 + test $old = $new test $flag = 1 ' test_expect_success 'post-checkout receives the right args with HEAD changed ' ' @@ -60,7 +60,7 @@ test_expect_success 'post-checkout receives the right args with HEAD changed ' ' old=$(awk {print \$1} clone2/.git/post-checkout.args) new=$(awk {print \$2} clone2/.git/post-checkout.args) flag=$(awk {print \$3} clone2/.git/post-checkout.args) - test $old != $new -a $flag = 1 + test $old != $new test $flag = 1 ' test_expect_success 'post-checkout receives the right args when not switching branches ' ' @@ -68,7 +68,7 @@ test_expect_success 'post-checkout receives the right args when not switching br old=$(awk {print \$1} clone2/.git/post-checkout.args) new=$(awk {print \$2} clone2/.git/post-checkout.args) flag=$(awk {print \$3} clone2/.git/post-checkout.args) - test $old = $new -a $flag = 0 + test $old = $new test $flag = 0 ' if test $(git config --bool core.filemode) = true; then -- 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
[PATCH 11/19] t/t0025-crlf-auto.sh: convert test -a/-o to and ||
The interaction with unary operators and operator precedence for and || are better known than -a and -o, and for that reason we prefer them. Replace all existing instances of -a and -o to save readers from the burden of thinking about such things. Signed-off-by: Elia Pinto gitter.spi...@gmail.com --- t/t0025-crlf-auto.sh |6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/t/t0025-crlf-auto.sh b/t/t0025-crlf-auto.sh index f5f67a6..a13fc56 100755 --- a/t/t0025-crlf-auto.sh +++ b/t/t0025-crlf-auto.sh @@ -36,7 +36,7 @@ test_expect_success 'default settings cause no changes' ' onediff=`git diff one` twodiff=`git diff two` threediff=`git diff three` - test -z $onediff -a -z $twodiff -a -z $threediff + test -z $onediff test -z $twodiff test -z $threediff ' test_expect_success 'crlf=true causes a CRLF file to be normalized' ' @@ -111,7 +111,7 @@ test_expect_success 'autocrlf=true does not normalize CRLF files' ' onediff=`git diff one` twodiff=`git diff two` threediff=`git diff three` - test -z $onediff -a -z $twodiff -a -z $threediff + test -z $onediff test -z $twodiff test -z $threediff ' test_expect_success 'text=auto, autocrlf=true _does_ normalize CRLF files' ' @@ -126,7 +126,7 @@ test_expect_success 'text=auto, autocrlf=true _does_ normalize CRLF files' ' onediff=`git diff one` twodiff=`git diff two` threediff=`git diff three` - test -z $onediff -a -n $twodiff -a -z $threediff + test -z $onediff test -n $twodiff test -z $threediff ' test_expect_success 'text=auto, autocrlf=true does not normalize binary files' ' -- 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
[PATCH 16/19] t/t5537-fetch-shallow.sh: convert test -a/-o to and ||
The interaction with unary operators and operator precedence for and || are better known than -a and -o, and for that reason we prefer them. Replace all existing instances of -a and -o to save readers from the burden of thinking about such things. Signed-off-by: Elia Pinto gitter.spi...@gmail.com --- t/t5537-fetch-shallow.sh |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/t/t5537-fetch-shallow.sh b/t/t5537-fetch-shallow.sh index be951a4..2c75730 100755 --- a/t/t5537-fetch-shallow.sh +++ b/t/t5537-fetch-shallow.sh @@ -173,7 +173,7 @@ EOF ) ' -if test -n $NO_CURL -o -z $GIT_TEST_HTTPD; then +if test -n $NO_CURL || test -z $GIT_TEST_HTTPD; then say 'skipping remaining tests, git built without http support' test_done fi -- 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
[PATCH] t6006-*.sh: Fix truncation tests
Signed-off-by: Ramsay Jones ram...@ramsay1.demon.co.uk --- Hi Alexey, If you need to re-roll your 'as/pretty-truncate' branch, could you please squash the relevant parts of this patch into the corresponding patches of your patch series. (ie this is a patch against the head of the current pu branch ...). Without this patch I get: $ ./t6006-rev-list-format.sh ok 1 - setup ok 2 - format percent ok 3 - format hash ok 4 - format tree ok 5 - format parents ok 6 - format author ok 7 - format committer ok 8 - format encoding ok 9 - format subject ./t6006-rev-list-format.sh: 152: ./t6006-rev-list-format.sh: Syntax error: ( unexpected FATAL: Unexpected exit with code 2 $ (if you have bash as /bin/sh you get different but related errors). The additional quoting suppresses the 'command redirection' errors, etc... Thanks. ATB Ramsay Jones t/t6006-rev-list-format.sh | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/t/t6006-rev-list-format.sh b/t/t6006-rev-list-format.sh index 9bc089b..e1dec3e 100755 --- a/t/t6006-rev-list-format.sh +++ b/t/t6006-rev-list-format.sh @@ -149,7 +149,7 @@ commit $head1 $added EOF -test_format subject-truncated %($truncate_count,trunc)%s EOF +test_format subject-truncated %\\($truncate_count,trunc\)%s EOF commit $head2 changed (ge${changed_utf8_part}ndert).. commit $head1 @@ -256,7 +256,7 @@ commit $head1 $added_iso88591 EOF -test_format complex-subject-trunc %($truncate_count,trunc)%s EOF +test_format complex-subject-trunc %\\($truncate_count,trunc\)%s EOF commit $head3 Test printing of c.. commit $head2 @@ -265,7 +265,7 @@ commit $head1 added (hinzugef${added_utf8_part_iso88591}gt.. EOF -test_format complex-subject-mtrunc %($truncate_count,mtrunc)%s EOF +test_format complex-subject-mtrunc %\\($truncate_count,mtrunc\)%s EOF commit $head3 Test prin..ex bodies commit $head2 @@ -274,7 +274,7 @@ commit $head1 added (hi..f${added_utf8_part_iso88591}gt) foo EOF -test_format complex-subject-ltrunc %($truncate_count,ltrunc)%s EOF +test_format complex-subject-ltrunc %\\($truncate_count,ltrunc\)%s EOF commit $head3 .. of complex bodies commit $head2 @@ -311,7 +311,7 @@ commit $head1 $added EOF -test_format complex-subject-commitencoding-unset-trunc %($truncate_count,trunc)%s EOF +test_format complex-subject-commitencoding-unset-trunc %\\($truncate_count,trunc\)%s EOF commit $head3 Test printing of c.. commit $head2 @@ -320,7 +320,7 @@ commit $head1 added (hinzugef${added_utf8_part}gt.. EOF -test_format complex-subject-commitencoding-unset-mtrunc %($truncate_count,mtrunc)%s EOF +test_format complex-subject-commitencoding-unset-mtrunc %\\($truncate_count,mtrunc\)%s EOF commit $head3 Test prin..ex bodies commit $head2 @@ -329,7 +329,7 @@ commit $head1 added (hi..f${added_utf8_part}gt) foo EOF -test_format complex-subject-commitencoding-unset-ltrunc %($truncate_count,ltrunc)%s EOF +test_format complex-subject-commitencoding-unset-ltrunc %\\($truncate_count,ltrunc\)%s EOF commit $head3 .. of complex bodies commit $head2 -- 1.9.0 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 10/19] git-submodule.sh: convert test -a/-o to and ||
Elia Pinto gitter.spi...@gmail.com writes: - test $status = D -o $status = T echo $sm_path continue + { + test $status = D || + test $status = T + } + echo $sm_path + continue We usually write the at the end of the line, hence that would be echo $sm_path continue (shouldn't block the patch, but you may change if you need to resend) -- 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: [PATCH 00/19] convert test -a/-o to and || patch series
Elia Pinto gitter.spi...@gmail.com writes: Elia Pinto (19): I went through the series (not very thoroughly) and it sounds good to me. -- 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: [PATCH] t6006-*.sh: Fix truncation tests
On Tue, May 20, 2014 at 02:54:20PM +0100, Ramsay Jones wrote: Signed-off-by: Ramsay Jones ram...@ramsay1.demon.co.uk --- Hi Alexey, If you need to re-roll your 'as/pretty-truncate' branch, could you please squash the relevant parts of this patch into the corresponding patches of your patch series. (ie this is a patch against the head of the current pu branch ...). Without this patch I get: $ ./t6006-rev-list-format.sh ok 1 - setup ok 2 - format percent ok 3 - format hash ok 4 - format tree ok 5 - format parents ok 6 - format author ok 7 - format committer ok 8 - format encoding ok 9 - format subject ./t6006-rev-list-format.sh: 152: ./t6006-rev-list-format.sh: Syntax error: ( unexpected FATAL: Unexpected exit with code 2 $ Ooops, my fault. (if you have bash as /bin/sh you get different but related errors). The additional quoting suppresses the 'command redirection' errors, etc... It's strange but I do have Bash as /bin/sh and unfortunately I have no this error AFAIU, Junio already applied my patches (existance of a branch as/pretty-truncate tells us that). So, we can only send other patches that fix errors brought with former patches. You can send, too. Thanks. ATB Ramsay Jones t/t6006-rev-list-format.sh | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/t/t6006-rev-list-format.sh b/t/t6006-rev-list-format.sh index 9bc089b..e1dec3e 100755 --- a/t/t6006-rev-list-format.sh +++ b/t/t6006-rev-list-format.sh @@ -149,7 +149,7 @@ commit $head1 $added EOF -test_format subject-truncated %($truncate_count,trunc)%s EOF +test_format subject-truncated %\\($truncate_count,trunc\)%s EOF commit $head2 changed (ge${changed_utf8_part}ndert).. commit $head1 @@ -256,7 +256,7 @@ commit $head1 $added_iso88591 EOF -test_format complex-subject-trunc %($truncate_count,trunc)%s EOF +test_format complex-subject-trunc %\\($truncate_count,trunc\)%s EOF commit $head3 Test printing of c.. commit $head2 @@ -265,7 +265,7 @@ commit $head1 added (hinzugef${added_utf8_part_iso88591}gt.. EOF -test_format complex-subject-mtrunc %($truncate_count,mtrunc)%s EOF +test_format complex-subject-mtrunc %\\($truncate_count,mtrunc\)%s EOF commit $head3 Test prin..ex bodies commit $head2 @@ -274,7 +274,7 @@ commit $head1 added (hi..f${added_utf8_part_iso88591}gt) foo EOF -test_format complex-subject-ltrunc %($truncate_count,ltrunc)%s EOF +test_format complex-subject-ltrunc %\\($truncate_count,ltrunc\)%s EOF commit $head3 .. of complex bodies commit $head2 @@ -311,7 +311,7 @@ commit $head1 $added EOF -test_format complex-subject-commitencoding-unset-trunc %($truncate_count,trunc)%s EOF +test_format complex-subject-commitencoding-unset-trunc %\\($truncate_count,trunc\)%s EOF commit $head3 Test printing of c.. commit $head2 @@ -320,7 +320,7 @@ commit $head1 added (hinzugef${added_utf8_part}gt.. EOF -test_format complex-subject-commitencoding-unset-mtrunc %($truncate_count,mtrunc)%s EOF +test_format complex-subject-commitencoding-unset-mtrunc %\\($truncate_count,mtrunc\)%s EOF commit $head3 Test prin..ex bodies commit $head2 @@ -329,7 +329,7 @@ commit $head1 added (hi..f${added_utf8_part}gt) foo EOF -test_format complex-subject-commitencoding-unset-ltrunc %($truncate_count,ltrunc)%s EOF +test_format complex-subject-commitencoding-unset-ltrunc %\\($truncate_count,ltrunc\)%s EOF commit $head3 .. of complex bodies commit $head2 -- 1.9.0 -- Alexey Shumkin E-mail: alex.crez...@gmail.com ICQ: 118001447 Jabber (GoogleTalk): alex.crez...@gmail.com Skype: crezoff -- 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] t6006-*.sh: Fix truncation tests
On Tue, May 20, 2014 at 06:19:36PM +0400, Alexey Shumkin wrote: On Tue, May 20, 2014 at 02:54:20PM +0100, Ramsay Jones wrote: Signed-off-by: Ramsay Jones ram...@ramsay1.demon.co.uk --- Hi Alexey, If you need to re-roll your 'as/pretty-truncate' branch, could you please squash the relevant parts of this patch into the corresponding patches of your patch series. (ie this is a patch against the head of the current pu branch ...). Without this patch I get: $ ./t6006-rev-list-format.sh ok 1 - setup ok 2 - format percent ok 3 - format hash ok 4 - format tree ok 5 - format parents ok 6 - format author ok 7 - format committer ok 8 - format encoding ok 9 - format subject ./t6006-rev-list-format.sh: 152: ./t6006-rev-list-format.sh: Syntax error: ( unexpected FATAL: Unexpected exit with code 2 $ Ooops, my fault. (if you have bash as /bin/sh you get different but related errors). The additional quoting suppresses the 'command redirection' errors, etc... It's strange but I do have Bash as /bin/sh and unfortunately I have no this error AFAIU, Junio already applied my patches (existance of a branch as/pretty-truncate tells us that). So, we can only send other patches that fix errors brought with former patches. You can send, too. Thanks. ATB Ramsay Jones t/t6006-rev-list-format.sh | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/t/t6006-rev-list-format.sh b/t/t6006-rev-list-format.sh index 9bc089b..e1dec3e 100755 --- a/t/t6006-rev-list-format.sh +++ b/t/t6006-rev-list-format.sh @@ -149,7 +149,7 @@ commit $head1 $added EOF -test_format subject-truncated %($truncate_count,trunc)%s EOF +test_format subject-truncated %\\($truncate_count,trunc\)%s EOF BTW, I would quoted that values rather than escaped -- 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 3/4] rebase: test ack
On Mon, May 19, 2014 at 02:34:26PM -0700, Junio C Hamano wrote: Michael S. Tsirkin m...@redhat.com writes: test ack! handling Signed-off-by: Michael S. Tsirkin m...@redhat.com Will queue with this squashed in. 4/4 seems to have some style issues as well, but I didn't look very closely. Thanks. Just to clarify I can post v2 of 4/4 without reposting 1-3 since they are queued? t/t3415-rebase-autosquash.sh | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/t/t3415-rebase-autosquash.sh b/t/t3415-rebase-autosquash.sh index 9d7db13..dcdba6f 100755 --- a/t/t3415-rebase-autosquash.sh +++ b/t/t3415-rebase-autosquash.sh @@ -75,18 +75,18 @@ test_expect_success 'auto squash (option)' ' ' test_expect_success 'auto ack' ' - ack=Acked-by: xyz - msg=$(test_write_lines ack! first commit $ack) + ack=Acked-by: xyz + msg=$(test_write_lines ack! first commit $ack) git reset --hard base git commit --allow-empty -m $msg -- git tag ack test_tick git rebase --autosquash -i HEAD^^^ git log --oneline actual - git show -s first-commit | grep -v ^commit expected-msg - echo $ack expected-msg - git show -s HEAD^ | grep -v ^commit actual-msg - diff actual-msg expected-msg + git show -s first-commit | grep -v ^commit expected-msg + echo $ack expected-msg + git show -s HEAD^ | grep -v ^commit actual-msg + test_cmp actual-msg expected-msg ' test_expect_success 'auto squash (config)' ' -- 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 10/19] git-submodule.sh: convert test -a/-o to and ||
Am 5/20/2014 15:50, schrieb Elia Pinto: # If we don't already have a -f flag and the submodule has never been checked out - if test -z $subsha1 -a -z $force + if test -z $subsha1 || test -z $force Should not be ||, but ! while read mod_src mod_dst sha1_src sha1_dst status sm_path do # Always show modules deleted or type-changed (blob-module) - test $status = D -o $status = T echo $sm_path continue + { + test $status = D || + test $status = T + } + echo $sm_path + continue As Matthieu noted, this is incorrect. It's not just a style violation, it's a syntax error. Why did your test runs not hickup on that? In this case you could even leave the original code structure without changing the meaning: test $status = D || test $status = T echo $sm_path continue But a better idiom is case $status in [DT]) printf '%s\n' $sm_path continue esac @@ -1233,7 +1238,7 @@ cmd_status() say U$sha1 $displaypath continue fi - if test -z $url || ! test -d $sm_path/.git -o -f $sm_path/.git + if test -z $url || ! test -d $sm_path/.git || test -f $sm_path/.git Wrong grouping. This could be more correct (I didn't test): if test -z $url || { ! test -d $sm_path/.git ! test -f $sm_path/.git } -- 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] t6006 (rev-list-format): quote format strings to avoid error on some shells
Added in 0a144b3 (t4205, t6006: add failing tests for the case when i18n.logOutputEncoding is set, 2014-05-19) tests give no error (somehow) with Bash as /bin/sh but fail for some other shells. Quote format strings to avoid errors. Signed-off-by: Alexey Shumkin alex.crez...@gmail.com Suggested-by: Ramsay Jones ram...@ramsay1.demon.co.uk --- t/t6006-rev-list-format.sh | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/t/t6006-rev-list-format.sh b/t/t6006-rev-list-format.sh index c6e9a73..19434ad 100755 --- a/t/t6006-rev-list-format.sh +++ b/t/t6006-rev-list-format.sh @@ -149,7 +149,7 @@ commit $head1 $added EOF -test_format subject-truncated %($truncate_count,trunc)%s EOF +test_format subject-truncated %($truncate_count,trunc)%s EOF commit $head2 changed (ge${changed_utf8_part}ndert).. commit $head1 @@ -259,7 +259,7 @@ commit $head1 $added_iso88591 EOF -test_format complex-subject-trunc %($truncate_count,trunc)%s EOF +test_format complex-subject-trunc %($truncate_count,trunc)%s EOF commit $head3 Test printing of c.. commit $head2 @@ -268,7 +268,7 @@ commit $head1 added (hinzugef${added_utf8_part_iso88591}gt.. EOF -test_format complex-subject-mtrunc %($truncate_count,mtrunc)%s EOF +test_format complex-subject-mtrunc %($truncate_count,mtrunc)%s EOF commit $head3 Test prin..ex bodies commit $head2 @@ -277,7 +277,7 @@ commit $head1 added (hi..f${added_utf8_part_iso88591}gt) foo EOF -test_format complex-subject-ltrunc %($truncate_count,ltrunc)%s EOF +test_format complex-subject-ltrunc %($truncate_count,ltrunc)%s EOF commit $head3 .. of complex bodies commit $head2 @@ -314,7 +314,7 @@ commit $head1 $added EOF -test_format complex-subject-commitencoding-unset-trunc %($truncate_count,trunc)%s EOF +test_format complex-subject-commitencoding-unset-trunc %($truncate_count,trunc)%s EOF commit $head3 Test printing of c.. commit $head2 @@ -323,7 +323,7 @@ commit $head1 added (hinzugef${added_utf8_part}gt.. EOF -test_format complex-subject-commitencoding-unset-mtrunc %($truncate_count,mtrunc)%s EOF +test_format complex-subject-commitencoding-unset-mtrunc %($truncate_count,mtrunc)%s EOF commit $head3 Test prin..ex bodies commit $head2 @@ -332,7 +332,7 @@ commit $head1 added (hi..f${added_utf8_part}gt) foo EOF -test_format complex-subject-commitencoding-unset-ltrunc %($truncate_count,ltrunc)%s EOF +test_format complex-subject-commitencoding-unset-ltrunc %($truncate_count,ltrunc)%s EOF commit $head3 .. of complex bodies commit $head2 -- 1.9.2-17 -- 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] remote-helpers: point at their upstream repositories
On 05/19/2014 11:31 PM, Junio C Hamano wrote: Felipe Contreras felipe.contre...@gmail.com writes: Junio C Hamano wrote: After looking at the reverse-depends list of packages, my faith is strengthened in that the Git ecosystem is truly maturing and useful third-party plug-ins will be picked up by distro packagers. Where is git-imerge packaged? I didn't see it on the archive the said Ubuntu box slurps from, but I did not check all the other distros. Michael, do you know what distro folks are doing with imerge? For the purpose of this thread, I do not follow distros, and I do not know is a perfectly acceptable answer, but it would be very relevant if your answer is I suggested these distros to include it, but so far they have been uncooperative and I haven't had much success. I haven't heard of any Linux distros that have git-imerge packages. I just searched the package archives for Debian, Fedora, Gentoo, and Arch without finding it. OTOH I haven't suggested it to any package maintainers nor done much to promote it after the initial flurry of publicity after GitMerge 2013 (blog posts, talk, and interview on GitMinutes). Oh yeah, there's also this animated GIF here [1] :-) Michael [1] https://github.com/blog/1691-michael-haggerty-is-a-githubber -- Michael Haggerty mhag...@alum.mit.edu http://softwareswirl.blogspot.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] t6006-*.sh: Fix truncation tests
On 20/05/14 15:19, Alexey Shumkin wrote: On Tue, May 20, 2014 at 02:54:20PM +0100, Ramsay Jones wrote: Signed-off-by: Ramsay Jones ram...@ramsay1.demon.co.uk --- Hi Alexey, If you need to re-roll your 'as/pretty-truncate' branch, could you please squash the relevant parts of this patch into the corresponding patches of your patch series. (ie this is a patch against the head of the current pu branch ...). Without this patch I get: $ ./t6006-rev-list-format.sh ok 1 - setup ok 2 - format percent ok 3 - format hash ok 4 - format tree ok 5 - format parents ok 6 - format author ok 7 - format committer ok 8 - format encoding ok 9 - format subject ./t6006-rev-list-format.sh: 152: ./t6006-rev-list-format.sh: Syntax error: ( unexpected FATAL: Unexpected exit with code 2 $ Ooops, my fault. (if you have bash as /bin/sh you get different but related errors). The additional quoting suppresses the 'command redirection' errors, etc... It's strange but I do have Bash as /bin/sh and unfortunately I have no this error Hmm, I see this: $ bash t6006-rev-list-format.sh -i ok 1 - setup ok 2 - format percent ok 3 - format hash ok 4 - format tree ok 5 - format parents ok 6 - format author ok 7 - format committer ok 8 - format encoding ok 9 - format subject t6006-rev-list-format.sh: line 152: 20,trunc: command not found not ok 10 - format subject-truncated # # git rev-list --pretty=format:'%/dev/fd/63%s' master output.subject-truncated # test_cmp expect.subject-truncated output.subject-truncated # $ (Since I'm on Linux Mint, my /bin/sh is dash, which produces the output in my previous mail). ATB, Ramsay Jones -- 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] t6006 (rev-list-format): quote format strings to avoid error on some shells
On 20/05/14 15:48, Alexey Shumkin wrote: Added in 0a144b3 (t4205, t6006: add failing tests for the case when i18n.logOutputEncoding is set, 2014-05-19) tests give no error (somehow) with Bash as /bin/sh but fail for some other shells. Quote format strings to avoid errors. Signed-off-by: Alexey Shumkin alex.crez...@gmail.com Suggested-by: Ramsay Jones ram...@ramsay1.demon.co.uk --- t/t6006-rev-list-format.sh | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/t/t6006-rev-list-format.sh b/t/t6006-rev-list-format.sh index c6e9a73..19434ad 100755 --- a/t/t6006-rev-list-format.sh +++ b/t/t6006-rev-list-format.sh @@ -149,7 +149,7 @@ commit $head1 $added EOF -test_format subject-truncated %($truncate_count,trunc)%s EOF +test_format subject-truncated %($truncate_count,trunc)%s EOF commit $head2 changed (ge${changed_utf8_part}ndert).. commit $head1 @@ -259,7 +259,7 @@ commit $head1 $added_iso88591 EOF -test_format complex-subject-trunc %($truncate_count,trunc)%s EOF +test_format complex-subject-trunc %($truncate_count,trunc)%s EOF commit $head3 Test printing of c.. commit $head2 @@ -268,7 +268,7 @@ commit $head1 added (hinzugef${added_utf8_part_iso88591}gt.. EOF -test_format complex-subject-mtrunc %($truncate_count,mtrunc)%s EOF +test_format complex-subject-mtrunc %($truncate_count,mtrunc)%s EOF commit $head3 Test prin..ex bodies commit $head2 @@ -277,7 +277,7 @@ commit $head1 added (hi..f${added_utf8_part_iso88591}gt) foo EOF -test_format complex-subject-ltrunc %($truncate_count,ltrunc)%s EOF +test_format complex-subject-ltrunc %($truncate_count,ltrunc)%s EOF commit $head3 .. of complex bodies commit $head2 @@ -314,7 +314,7 @@ commit $head1 $added EOF -test_format complex-subject-commitencoding-unset-trunc %($truncate_count,trunc)%s EOF +test_format complex-subject-commitencoding-unset-trunc %($truncate_count,trunc)%s EOF commit $head3 Test printing of c.. commit $head2 @@ -323,7 +323,7 @@ commit $head1 added (hinzugef${added_utf8_part}gt.. EOF -test_format complex-subject-commitencoding-unset-mtrunc %($truncate_count,mtrunc)%s EOF +test_format complex-subject-commitencoding-unset-mtrunc %($truncate_count,mtrunc)%s EOF commit $head3 Test prin..ex bodies commit $head2 @@ -332,7 +332,7 @@ commit $head1 added (hi..f${added_utf8_part}gt) foo EOF -test_format complex-subject-commitencoding-unset-ltrunc %($truncate_count,ltrunc)%s EOF +test_format complex-subject-commitencoding-unset-ltrunc %($truncate_count,ltrunc)%s EOF commit $head3 .. of complex bodies commit $head2 Yep, actually using string quotes works just as well! :-P Thanks! ATB, Ramsay Jones -- 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] format-patch --signature-file file
Jeff King p...@peff.net writes: You could do: #define DEFAULT_SIGNATURE git_version_string static const char *signature = DEFAULT_SIGNATURE; ... if (signature == DEFAULT_SIGNATURE) ... but maybe that is getting a little unwieldy, considering the scope of the original problem. I agree. It is an invitation for doing something like #define DEFAULT_SIGNATURE -- \nfoo bar\n which defeats the purpose. I have an unrelated and larger design level suggestion, but it may be better for me to refrain from sending it during the -rc freeze. -- 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 3/4] rebase: test ack
Michael S. Tsirkin m...@redhat.com writes: Just to clarify I can post v2 of 4/4 without reposting 1-3 since they are queued? If you need to update anything queued only on 'pu' but not yet in 'next', it is customary to resend the whole for everybody to see (what is already in 'next' should only be built upon incrementally and not updated with replacement patches), while noting which ones are the same as before. Christian Couder has been doing it nicely in his recent rerolls (if the series were not in 'next', that is). Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] remote-helpers: point at their upstream repositories
On Tue, May 20, 2014 at 4:55 PM, Michael Haggerty mhag...@alum.mit.edu wrote: On 05/19/2014 11:31 PM, Junio C Hamano wrote: Felipe Contreras felipe.contre...@gmail.com writes: Where is git-imerge packaged? I didn't see it on the archive the said Ubuntu box slurps from, but I did not check all the other distros. Michael, do you know what distro folks are doing with imerge? For the purpose of this thread, I do not follow distros, and I do not know is a perfectly acceptable answer, but it would be very relevant if your answer is I suggested these distros to include it, but so far they have been uncooperative and I haven't had much success. I haven't heard of any Linux distros that have git-imerge packages. I just searched the package archives for Debian, Fedora, Gentoo, and Arch without finding it. FWIW; someone has made an AUR package (a user-contributed Arch package recipe) for git-imerge: https://aur.archlinux.org/packages/git-imerge-git/ ...Johan -- Johan Herland, jo...@herland.net www.herland.net -- 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 and large files
Can GIT handle versioning of large 20+ GB files in a directory? Lou Stewart AOCWS Software Configuration Management 757-269-2388 -- 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] t6006-*.sh: Fix truncation tests
On Tue, May 20, 2014 at 04:01:22PM +0100, Ramsay Jones wrote: On 20/05/14 15:19, Alexey Shumkin wrote: On Tue, May 20, 2014 at 02:54:20PM +0100, Ramsay Jones wrote: Signed-off-by: Ramsay Jones ram...@ramsay1.demon.co.uk --- Hi Alexey, If you need to re-roll your 'as/pretty-truncate' branch, could you please squash the relevant parts of this patch into the corresponding patches of your patch series. (ie this is a patch against the head of the current pu branch ...). Without this patch I get: $ ./t6006-rev-list-format.sh ok 1 - setup ok 2 - format percent ok 3 - format hash ok 4 - format tree ok 5 - format parents ok 6 - format author ok 7 - format committer ok 8 - format encoding ok 9 - format subject ./t6006-rev-list-format.sh: 152: ./t6006-rev-list-format.sh: Syntax error: ( unexpected FATAL: Unexpected exit with code 2 $ Ooops, my fault. (if you have bash as /bin/sh you get different but related errors). The additional quoting suppresses the 'command redirection' errors, etc... It's strange but I do have Bash as /bin/sh and unfortunately I have no this error Hmm, I see this: $ bash t6006-rev-list-format.sh -i AFAIK, this is not running Bash as /bin/sh :) Maybe I'm wrong but Bash as /bin/sh is: $ ls -l /bin/sh lrwxrwxrwx 1 root root 4 May 12 18:35 /bin/sh - bash But it does not matter here much, you've noticed my foolish mistake :) ok 1 - setup ok 2 - format percent ok 3 - format hash ok 4 - format tree ok 5 - format parents ok 6 - format author ok 7 - format committer ok 8 - format encoding ok 9 - format subject t6006-rev-list-format.sh: line 152: 20,trunc: command not found not ok 10 - format subject-truncated # # git rev-list --pretty=format:'%/dev/fd/63%s' master output.subject-truncated # test_cmp expect.subject-truncated output.subject-truncated # $ (Since I'm on Linux Mint, my /bin/sh is dash, which produces the output in my previous mail). ATB, Ramsay Jones -- 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
untracked file deleted from the master branch, when checked out to it from a local branch
I was following some tutorial (http://gitref.org/branching/#merge) - and doing it in my console : Arup-iMac:arup_git shreyas$ git status # On branch master nothing to commit, working directory clean Arup-iMac:arup_git shreyas$ touch test.rb Arup-iMac:arup_git shreyas$ ls git_1.txttest.rb Arup-iMac:arup_git shreyas$ cat test.rb Arup-iMac:arup_git shreyas$ vi test.rb Arup-iMac:arup_git shreyas$ cat test.rb class Foo def self.bar 12 end end Foo.bar ***HERE I switched to a NEW Branch Arup-iMac:arup_git shreyas$ git checkout -b change_class Switched to a new branch 'change_class' Arup-iMac:arup_git shreyas$ ls git_1.txttest.rb Arup-iMac:arup_git shreyas$ vi test.rb Arup-iMac:arup_git shreyas$ head -1 test.rb class Fooo Arup-iMac:arup_git shreyas$ head -2 test.rb class Fooo def self.bar Arup-iMac:arup_git shreyas$ git commit -am 'changed the class name' # On branch change_class # Untracked files: # (use git add file... to include in what will be committed) # #test.rb nothing added to commit but untracked files present (use git add to track) Arup-iMac:arup_git shreyas$ git add test.rb Arup-iMac:arup_git shreyas$ git commit -am 'changed the class name' [change_class 2d40033] changed the class name 1 file changed, 7 insertions(+) create mode 100644 test.rb Arup-iMac:arup_git shreyas$ cat test.rb class Fooo def self.bar 12 end end Fooo.bar Arup-iMac:arup_git shreyas$ git checkout master Switched to branch 'master' Arup-iMac:arup_git shreyas$ git mv test.rb ruby.rb fatal: bad source, source=test.rb, destination=ruby.rb Arup-iMac:arup_git shreyas$ git mv -h usage: git mv [options] source... destination -v, --verbose be verbose -n, --dry-run dry run -f, --force force move/rename even if target exists -kskip move/rename errors |--| FROM MASTER BRACH WHY THE FILE test.rb DELETED?*** Arup-iMac:arup_git shreyas$ ls git_1.txt Arup-iMac:arup_git shreyas$ -- === Regards, Arup Rakshit -- 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] t6006-*.sh: Fix truncation tests
On 20/05/14 17:02, Alexey Shumkin wrote: On Tue, May 20, 2014 at 04:01:22PM +0100, Ramsay Jones wrote: On 20/05/14 15:19, Alexey Shumkin wrote: On Tue, May 20, 2014 at 02:54:20PM +0100, Ramsay Jones wrote: Signed-off-by: Ramsay Jones ram...@ramsay1.demon.co.uk --- Hi Alexey, If you need to re-roll your 'as/pretty-truncate' branch, could you please squash the relevant parts of this patch into the corresponding patches of your patch series. (ie this is a patch against the head of the current pu branch ...). Without this patch I get: $ ./t6006-rev-list-format.sh ok 1 - setup ok 2 - format percent ok 3 - format hash ok 4 - format tree ok 5 - format parents ok 6 - format author ok 7 - format committer ok 8 - format encoding ok 9 - format subject ./t6006-rev-list-format.sh: 152: ./t6006-rev-list-format.sh: Syntax error: ( unexpected FATAL: Unexpected exit with code 2 $ Ooops, my fault. (if you have bash as /bin/sh you get different but related errors). The additional quoting suppresses the 'command redirection' errors, etc... It's strange but I do have Bash as /bin/sh and unfortunately I have no this error Hmm, I see this: $ bash t6006-rev-list-format.sh -i AFAIK, this is not running Bash as /bin/sh :) Maybe I'm wrong but Bash as /bin/sh is: $ ls -l /bin/sh lrwxrwxrwx 1 root root 4 May 12 18:35 /bin/sh - bash Ah yes, I keep forgetting that bash behaves differently when invoked as 'sh'. (i.e. it enters 'posix mode' in this case). Indeed, this is (roughly) equivalent to: $ bash --posix t6006-rev-list-format.sh ok 1 - setup ok 2 - format percent ok 3 - format hash ... ok 52 - oneline with empty message ok 53 - single-character name is parsed correctly # passed all 53 test(s) 1..53 $ ... which works. Thanks again. ATB Ramsay Jones -- 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: EXT :Re: GIT and large files
The files in question would be in directory containing many files some small other huge (example: text files, docs,and jpgs are Mbs, but executables and ova images are GBs, etc). Lou From: Gary Fixler [mailto:gfix...@gmail.com] Sent: Tuesday, May 20, 2014 12:09 PM To: Stewart, Louis (IS) Cc: git@vger.kernel.org Subject: EXT :Re: GIT and large files Technically yes, but from a practical standpoint, not really. Facebook recently revealed that they have a 54GB git repo[1], but I doubt it has 20+GB files in it. I've put 18GB of photos into a git repo, but everything about the process was fairly painful, and I don't plan to do it again. Are your files non-mergeable binaries (e.g. videos)? The biggest problem here is with branching and merging. Conflict resolution with non-mergeable assets ends up an us-vs-them fight, and I don't understand all of the particulars of that. From git's standpoint it's simple - you just have to choose one or the other. From a workflow standpoint, you end up causing trouble if two people have changed an asset, and both people consider their change important. Centralized systems get around this problem with locks. Git could do this, and I've thought about it quite a bit. I work in games - we have code, but also a lot of binaries, that I'd like to keep in sync with the code. For awhile I considered suggesting some ideas to this group, but I'm pretty sure the locking issue makes it a non-starter. The basic idea - skipping locking for the moment - would be to allow setting git attributes by file type, file size threshold, folder, etc., to allow git to know that some files are considered bigfiles. These could be placed into the objects folder, but I'd actually prefer they go into a .git/bigfile folder. They'd still be saved as contents under their hash, but a normal git transfer wouldn't send them. They'd be in the tree as 'big' or 'bigfile' (instead of 'blob', 'tree', or 'commit' (for submodules)). Git would warn you on push that there were bigfiles to send, and you could add, say, --with-big to also send them, or send them later with, say, `git push --big`. They'd simply be zipped up and sent over, without any packfile fanciness. When you clone, you wouldn't get the bigfiles, unless you specified --with-big, and it would warn you that there are also bigfiles, and tell you what command to run to get also get them (`git fetch --big`, perhaps). Git status would always let you know if you were missing bigfiles. I think hopping around between commits would follow the same strategy, you'd always have to, e.g. `git checkout foo --with-big`, or `git checkout foo` and then `git update big` (or whatever - I'm not married to any of these names). Resolving conflicts on merge would simply have to be up to you. It would be documented clearly that you're entering weird territory, and that your team has to deal with bigfiles somehow, perhaps with some suggested strategies (Pass the conch?). I could imagine some strategies for this. Maybe bigfiles require connecting to a blessed repo to grab the right to make a commit on it. That has many problems, of course, and now I can feel everyone reading this shifting uneasily in their seats :) -g [1] https://twitter.com/feross/status/459259593630433280 On Tue, May 20, 2014 at 8:37 AM, Stewart, Louis (IS) louis.stew...@ngc.com wrote: Can GIT handle versioning of large 20+ GB files in a directory? Lou Stewart AOCWS Software Configuration Management 757-269-2388 -- 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 N�r��yb�X��ǧv�^�){.n�+ا���ܨ}���Ơz�j:+v���zZ+��+zf���h���~i���z��w���?��)ߢf
Re: untracked file deleted from the master branch, when checked out to it from a local branch
On 5/20/2014 10:38 AM, Arup Rakshit wrote: I was following some tutorial (http://gitref.org/branching/#merge) - and doing it in my console : Arup-iMac:arup_git shreyas$ git status # On branch master nothing to commit, working directory clean Arup-iMac:arup_git shreyas$ touch test.rb Arup-iMac:arup_git shreyas$ ls git_1.txttest.rb Arup-iMac:arup_git shreyas$ cat test.rb Arup-iMac:arup_git shreyas$ vi test.rb Arup-iMac:arup_git shreyas$ cat test.rb class Foo def self.bar 12 end end Foo.bar ***HERE I switched to a NEW Branch ... FROM MASTER BRACH WHY THE FILE test.rb DELETED?*** Arup-iMac:arup_git shreyas$ ls git_1.txt Because you never committed the original file to the master branch before you created and switched to the change_class branch. You're missing git add test.rb git commit -m initial version of test.rb before you switch branches the first time. -- .marius -- 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: untracked file deleted from the master branch, when checked out to it from a local branch
On Tuesday, May 20, 2014 11:56:57 AM you wrote: On 5/20/2014 10:38 AM, Arup Rakshit wrote: I was following some tutorial (http://gitref.org/branching/#merge) - and doing it in my console : Because you never committed the original file to the master branch before you created and switched to the change_class branch. You're missing git add test.rb git commit -m initial version of test.rb before you switch branches the first time. Hum, But when I create a new branch from master, then it came to the new branch, but deleted from the master. Shouldn't it also not come to the new local branch also. That's how I expected. -- === Regards, Arup Rakshit -- 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 and large files
-Original Message- From: Stewart, Louis (IS) Sent: Tuesday, May 20, 2014 11:38 Can GIT handle versioning of large 20+ GB files in a directory? Are you asking 20 files of a GB each or files 20GB each? A what and why may help with the underlying questions. v/r, Jason Pyeron -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100- - +1 (443) 269-1555 x333Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00. -- 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: untracked file deleted from the master branch, when checked out to it from a local branch
On 5/20/2014 11:03 AM, Arup Rakshit wrote: On Tuesday, May 20, 2014 11:56:57 AM you wrote: On 5/20/2014 10:38 AM, Arup Rakshit wrote: I was following some tutorial (http://gitref.org/branching/#merge) - and doing it in my console : Because you never committed the original file to the master branch before you created and switched to the change_class branch. You're missing git add test.rb git commit -m initial version of test.rb before you switch branches the first time. Hum, But when I create a new branch from master, then it came to the new branch, but deleted from the master. Shouldn't it also not come to the new local branch also. That's how I expected. It never came to the new branch, as it was never version controlled, it was an untracked file left behind when you switched branches. Once you added it to the new branch, change_class, it became a version controlled file, and since you moved to a branch without that file (the pristine clean master branch), git removed it. (your version history says that change_class contains test.rb and master does not.) -- .marius -- 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 and large files
On 5/20/2014 10:37 AM, Stewart, Louis (IS) wrote: Can GIT handle versioning of large 20+ GB files in a directory? Maybe you're looking for git-annex? https://git-annex.branchable.com/ -- .marius -- 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] t6006-*.sh: Fix truncation tests
Alexey Shumkin alex.crez...@gmail.com writes: AFAIU, Junio already applied my patches (existance of a branch as/pretty-truncate tells us that). So, we can only send other patches that fix errors brought with former patches. No, NO, NO The existence of a branch merely means that I saw the patches, and that I thought that the series was not completely useless. In other words, it indicates that I wanted to make sure that I won't forget about the topic, and it was worth my time to create the branch and apply there for that purpose. Please do not read anything more than that. Presense of a topic branch by itself does not say that I _read_ the patches or I thought they did not need reroll. When such a branch is merged to 'next', that means I read the patches myself, or I saw somebody whose judgement I and others in the community trust read them and gave a positive response or an Ack, and that I decided that the topic is in a good enough shape to be worked on further with incremental updates. You are talking about the latter state, but as/pretty-truncate is in the former state. -- 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 and large files
Stewart, Louis (IS) louis.stew...@ngc.com writes: Can GIT handle versioning of large 20+ GB files in a directory? I think you can git add such files, push/fetch histories that contains such files over the wire, and git checkout such files, but naturally reading, processing and writing 20+GB would take some time. In order to run operations that need to see the changes, e.g. git log -p, a real content-level merge, etc., you would also need sufficient memory because we do things in-core. -- 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: EXT :Re: GIT and large files
Thanks for the reply. I just read the intro to GIT and I am concerned about the part that it will copy the whole repository to the developers work area. They really just need the one directory and files under that one directory. The history has TBs of data. Lou -Original Message- From: Junio C Hamano [mailto:gits...@pobox.com] Sent: Tuesday, May 20, 2014 1:18 PM To: Stewart, Louis (IS) Cc: git@vger.kernel.org Subject: EXT :Re: GIT and large files Stewart, Louis (IS) louis.stew...@ngc.com writes: Can GIT handle versioning of large 20+ GB files in a directory? I think you can git add such files, push/fetch histories that contains such files over the wire, and git checkout such files, but naturally reading, processing and writing 20+GB would take some time. In order to run operations that need to see the changes, e.g. git log -p, a real content-level merge, etc., you would also need sufficient memory because we do things in-core. -- 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] Documentation/technical/api-hashmap: Remove source highlighting
Anders Kaseorg ande...@mit.edu writes: How bad does the documentation look with the patch applied (I know how bad it looks without source-highlight installed)? If it is not too bad, then it sounds like a sensible solution to drop the highlight markup unconditionally like the patch that started this thread does, taking the common denominator approach. You seem to agree, and I do not object, either. Original version with syntax-highlight installed (pretty): http://web.mit.edu/andersk/Public/api-hashmap/old-highlight.html Original version with syntax-highlight missing (corrupted): http://web.mit.edu/andersk/Public/api-hashmap/old-no-highlight.html Patched version (boring but readable): http://web.mit.edu/andersk/Public/api-hashmap/patched.html Thanks. I've queued the patch for v2.0 and the comparison between the first and the third clearly shows that it is the right thing to do ;-). -- 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: bug: autostash is lost after aborted rebase
Matthieu Moy matthieu@grenoble-inp.fr writes: [ Cc-ing Ramkumar ] Karen Etheridge et...@cpan.org writes: scenario: - edit some tracked files; do not add them to the index - git config rebase.autostash true - git rebase -i HEAD~3 (an autostash will be created) - delete the entire buffer and save/exit the editor - this will abort the rebase poof, the autostash is gone (it is not reapplied) -- it must be explicitly applied again via the SHA that was printed earlier. Indeed. Confirmed, even with pu (I thought I remembered seeing a fix on the list, but I must have mixed up with something else). Thanks. I see Ram's patch to address this on the list. Will pick it up and queue for post-release, as this is a fairly old breakage dating as far back as v1.8.4, if I am not mistaken. -- 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: format-patch crashes with a huge patchset
Jeff King p...@peff.net writes: On Mon, May 19, 2014 at 10:35:56PM +0300, Michael S. Tsirkin wrote: I tried to fump the whole history of qemu with format-patch. It crashes both with v2.0.0-rc2-21-g6087111 and with git 1.8.3.1: ~/opt/libexec/git-core/git-format-patch --follow -o patches/all e63c3dc74bfb90e4522d075d0d5a7600c5145745.. You can't use --follow without specifying a single pathspec. Running git log --follow notices and blocks this, but format-patch doesn't (and segfaults later when the follow code assumes there is a pathspec). I think we need: Looks sensible. Intrestingly enough, this dates all the way back to the original 750f7b66 (Finally implement git log --follow, 2007-06-19). Re-reading the log message of that commit was amusing for other reasons, by the way (the most interesting part comes after One thing to look out for: and especially Put another way:). -- 8 -- Subject: move --follow needs one pathspec rule to diff_setup_done Because of the way --follow is implemented, we must have exactly one pathspec. git log enforces this restriction, but other users of the revision traversal code do not. For example, git format-patch --follow will segfault during try_to_follow_renames, as we have no pathspecs at all. We can push this check down into diff_setup_done, which is probably a better place anyway. It is the diff code that introduces this restriction, so other parts of the code should not need to care themselves. Reported-by: Michael S. Tsirkin m...@redhat.com Signed-off-by: Jeff King p...@peff.net --- I didn't include a test, as I don't think the current behavior is what we want in the long run. That is, it would be nice if eventually --follow learned to be more flexible. Any test for this would necessarily be looking for the opposite of that behavior. But maybe it's worth it to just have in the meantime, and anyone who works on --follow can rip out the test. builtin/log.c | 8 ++-- diff.c| 3 +++ 2 files changed, 5 insertions(+), 6 deletions(-) diff --git a/builtin/log.c b/builtin/log.c index 39e8836..3b6a6bb 100644 --- a/builtin/log.c +++ b/builtin/log.c @@ -158,13 +158,9 @@ static void cmd_log_init_finish(int argc, const char **argv, const char *prefix, if (rev-show_notes) init_display_notes(rev-notes_opt); - if (rev-diffopt.pickaxe || rev-diffopt.filter) + if (rev-diffopt.pickaxe || rev-diffopt.filter || + DIFF_OPT_TST(rev-diffopt, FOLLOW_RENAMES)) rev-always_show_header = 0; - if (DIFF_OPT_TST(rev-diffopt, FOLLOW_RENAMES)) { - rev-always_show_header = 0; - if (rev-diffopt.pathspec.nr != 1) - usage(git logs can only follow renames on one pathname at a time); - } if (source) rev-show_source = 1; diff --git a/diff.c b/diff.c index f72769a..68bb8c5 100644 --- a/diff.c +++ b/diff.c @@ -3325,6 +3325,9 @@ void diff_setup_done(struct diff_options *options) } options-diff_path_counter = 0; + + if (DIFF_OPT_TST(options, FOLLOW_RENAMES) options-pathspec.nr != 1) + die(_(--follow requires exactly one pathspec)); } static int opt_arg(const char *arg, int arg_short, const char *arg_long, int *val) -- 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 v5] format-patch --signature-file file
Jeff King p...@peff.net writes: But one could easily specify a longer, multi-line signature, like: git format-patch --signature=' this is my long signature it has multiple lines ' ... We should notice that it already has its own trailing newline, and suppress one of ours. Signed-off-by: Jeff King p...@peff.net --- In the example above, there's also a newline before the signature starts. Should we suppress the first one, too? Also, I'm not clear on the purpose of the extra trailing line in the first place. Emails now end with ( added to show blanks): -- 2.0.0-rc3... Is there are a reason for that final blank line? I actually think these supress extra LFs trying to be overly smart and inviting unnecessary surprises. Unlike log messages people type (in which we do squash runs of blank lines and other prettifying), mail-signature string is not something people keep typing, and it would be better to keep it simple and consistent, i.e. we can declare that the users who use non-default mail-signature can and should learn to: --signature='this is the first line of my long sig with a blank line and then it ends here' and be done with it, I think. The trailing blank after the mail-signature is a different issue. I think it is safe to remove it and I also think the result may look better, but at the same time, it is very close to the if we were writing format-patch today, then we would... category, I would say. builtin/log.c | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/builtin/log.c b/builtin/log.c index 39e8836..5acc048 100644 --- a/builtin/log.c +++ b/builtin/log.c @@ -844,8 +844,13 @@ static void gen_message_id(struct rev_info *info, char *base) static void print_signature(void) { - if (signature *signature) - printf(-- \n%s\n\n, signature); + if (!signature || !*signature) + return; + + printf(-- \n%s, signature); + if (signature[strlen(signature)-1] != '\n') + putchar('\n'); + putchar('\n'); } static void add_branch_description(struct strbuf *buf, const char *branch_name) -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/19] convert test -a/-o to and || patch series
Elia Pinto gitter.spi...@gmail.com writes: These patch series convert test -a/-o to and ||. This is the second version. Perhaps slightly off-topic, but has the remainder of the previous $(...) series been perfected and ready to apply? -- 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 01/19] check_bindir: convert test -a/-o to and ||
Elia Pinto gitter.spi...@gmail.com writes: The interaction with unary operators and operator precedence for and || are better known than -a and -o, and for that reason we prefer them. Replace all existing instances of -a and -o to save readers from the burden of thinking about such things. Signed-off-by: Elia Pinto gitter.spi...@gmail.com --- Thanks. As I already said, I think better known is much less of an issue than that -a/-o is more error prone, and that is the reason why we may want to do this rewrite. I do not know offhand how busy the tree would be when we can apply these patches post-release without them getting rebased, but the zero-th step before this series may want to be a patch like this. Documentation/CodingGuidelines | 13 + 1 file changed, 13 insertions(+) diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines index ef67b53..7864c5b 100644 --- a/Documentation/CodingGuidelines +++ b/Documentation/CodingGuidelines @@ -106,6 +106,19 @@ For shell scripts specifically (not exhaustive): interface translatable. See Marking strings for translation in po/README. + - We do not write our test command with -a and -o and use + or || to concatenate multiple test commands instead, because + the use of -a/-o is often error-prone. E.g. + + test -n $x -a $a = $b + + is buggy and breaks when $x is =, but + + test -n $x test $a = $b + + does not have such a problem. + + For C programs: - We use tabs to indent, and interpret tabs as taking up to -- 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: EXT :Re: GIT and large files
Stewart, Louis (IS) louis.stew...@ngc.com writes: Thanks for the reply. I just read the intro to GIT and I am concerned about the part that it will copy the whole repository to the developers work area. They really just need the one directory and files under that one directory. The history has TBs of data. Then you will spend time reading, processing and writing TBs of data when you clone, unless your developers do something to limit the history they fetch, e.g. by shallowly cloning. Lou -Original Message- From: Junio C Hamano [mailto:gits...@pobox.com] Sent: Tuesday, May 20, 2014 1:18 PM To: Stewart, Louis (IS) Cc: git@vger.kernel.org Subject: EXT :Re: GIT and large files Stewart, Louis (IS) louis.stew...@ngc.com writes: Can GIT handle versioning of large 20+ GB files in a directory? I think you can git add such files, push/fetch histories that contains such files over the wire, and git checkout such files, but naturally reading, processing and writing 20+GB would take some time. In order to run operations that need to see the changes, e.g. git log -p, a real content-level merge, etc., you would also need sufficient memory because we do things in-core. -- 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: EXT :Re: GIT and large files
From you response then there is a method to only obtain the Project, Directory and Files (which could hold 80 GBs of data) and not the rest of the Repository that contained the full overall Projects? -Original Message- From: Junio C Hamano [mailto:gits...@pobox.com] Sent: Tuesday, May 20, 2014 2:15 PM To: Stewart, Louis (IS) Cc: git@vger.kernel.org Subject: Re: EXT :Re: GIT and large files Stewart, Louis (IS) louis.stew...@ngc.com writes: Thanks for the reply. I just read the intro to GIT and I am concerned about the part that it will copy the whole repository to the developers work area. They really just need the one directory and files under that one directory. The history has TBs of data. Then you will spend time reading, processing and writing TBs of data when you clone, unless your developers do something to limit the history they fetch, e.g. by shallowly cloning. Lou -Original Message- From: Junio C Hamano [mailto:gits...@pobox.com] Sent: Tuesday, May 20, 2014 1:18 PM To: Stewart, Louis (IS) Cc: git@vger.kernel.org Subject: EXT :Re: GIT and large files Stewart, Louis (IS) louis.stew...@ngc.com writes: Can GIT handle versioning of large 20+ GB files in a directory? I think you can git add such files, push/fetch histories that contains such files over the wire, and git checkout such files, but naturally reading, processing and writing 20+GB would take some time. In order to run operations that need to see the changes, e.g. git log -p, a real content-level merge, etc., you would also need sufficient memory because we do things in-core. -- 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: untracked file deleted from the master branch, when checked out to it from a local branch
On Tuesday, May 20, 2014 12:06:49 PM you wrote: It never came to the new branch, as it was never version controlled, it was an untracked file left behind when you switched branches. Once you added it to the new branch, change_class, it became a version controlled file, This is still didn't get it. If an untracked file didn't come in the new branch, how would I able to add it to stage ? I am not getting this part. You are right, but I am not able to understand this one, my bad! :( -- === Regards, Arup Rakshit -- 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 00/19] convert test -a/-o to and || patch series
Hi, Elia Pinto wrote: These patch series convert test -a/-o to and ||. Should this come with a new check in t/check-non-portable-shell.pl so we don't regress in the future? Elia Pinto (19): [...] check_bindir|2 +- contrib/examples/git-clone.sh |2 +- contrib/examples/git-commit.sh |4 ++-- contrib/examples/git-merge.sh |4 ++-- contrib/examples/git-repack.sh |4 ++-- contrib/examples/git-resolve.sh |2 +- git-bisect.sh |2 +- git-mergetool.sh|4 ++-- git-rebase--interactive.sh |2 +- git-submodule.sh| 29 + t/t0025-crlf-auto.sh|6 +++--- t/t0026-eol-config.sh |8 t/t4102-apply-rename.sh |2 +- t/t5000-tar-tree.sh |2 +- t/t5403-post-checkout-hook.sh |8 t/t5537-fetch-shallow.sh|2 +- t/t5538-push-shallow.sh |2 +- t/t9814-git-p4-rename.sh|4 ++-- t/test-lib-functions.sh |4 ++-- 19 files changed, 49 insertions(+), 44 deletions(-) I still think one patch per file is too many patches for this. It would be easier to read with, e.g., whichever ones were most complex as separate patches and the rest (the easy ones) as a single patch. Thanks, Jonathan -- 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: untracked file deleted from the master branch, when checked out to it from a local branch
Arup Rakshit arupraks...@rocketmail.com writes: On Tuesday, May 20, 2014 12:06:49 PM you wrote: It never came to the new branch, as it was never version controlled, it was an untracked file left behind when you switched branches. Once you added it to the new branch, change_class, it became a version controlled file, This is still didn't get it. If an untracked file didn't come in the new branch, how would I able to add it to stage ? I am not getting this part. You are right, but I am not able to understand this one, my bad! :( Untracked files and modifications to files in your working directory do not belong to your current branch. This is to allow you, after starting to work on one branch then realizing that the changes and additions you are making do not belong there, to switch to a more appropriate branch at that point without losing your work so far, taking these changes and additions with you to the branch you want to commit your changes to. -- 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 v5] format-patch --signature-file file
On Tue, May 20, 2014 at 10:53:11AM -0700, Junio C Hamano wrote: I actually think these supress extra LFs trying to be overly smart and inviting unnecessary surprises. Unlike log messages people type (in which we do squash runs of blank lines and other prettifying), mail-signature string is not something people keep typing, and it would be better to keep it simple and consistent, i.e. we can declare that the users who use non-default mail-signature can and should learn to: --signature='this is the first line of my long sig with a blank line and then it ends here' and be done with it, I think. If it were just --signature, I'd agree. After all, nobody is even complaining. But this is also in preparation for --signature-file. Should the user create a file without a trailing newline? We can special-case --signature-file to strip the final newline from the read file, but it seems friendlier to handle it at the printing stage (and then we handle the unlikely but possible --signature as above for free). I don't think it would adversely impact any real-world case, because somebody would have to: 1. already be including an extra trailing newline 2. really _want_ three newlines at the end The trailing blank after the mail-signature is a different issue. I think it is safe to remove it and I also think the result may look better, but at the same time, it is very close to the if we were writing format-patch today, then we would... category, I would say. Yeah. I think it is probably extraneous and would not hurt to remove. But it may not be worth worrying about (it's really the _two_ lines caused by the unconditional newline above that bugs 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
Re: EXT :Re: GIT and large files
Am Dienstag, den 20.05.2014, 17:24 + schrieb Stewart, Louis (IS): Thanks for the reply. I just read the intro to GIT and I am concerned about the part that it will copy the whole repository to the developers work area. They really just need the one directory and files under that one directory. The history has TBs of data. Lou -Original Message- From: Junio C Hamano [mailto:gits...@pobox.com] Sent: Tuesday, May 20, 2014 1:18 PM To: Stewart, Louis (IS) Cc: git@vger.kernel.org Subject: EXT :Re: GIT and large files Stewart, Louis (IS) louis.stew...@ngc.com writes: Can GIT handle versioning of large 20+ GB files in a directory? I think you can git add such files, push/fetch histories that contains such files over the wire, and git checkout such files, but naturally reading, processing and writing 20+GB would take some time. In order to run operations that need to see the changes, e.g. git log -p, a real content-level merge, etc., you would also need sufficient memory because we do things in-core. Preventing that a clone fetches the whole history can be done with the --depth option of git clone. The question is what do you want to do with these 20G files? Just store them in the repo and *very* occasionally change them? For that you need a 64bit compiled version of git with enough ram. 32G does the trick here. Everything with git 1.9.1. Doing some tests on my machine with a normal harddisc gives (sorry for LC_ALL != C): $time git add file.dat; time git commit -m add file; time git status real16m17.913s user13m3.965s sys 0m22.461s [master 15fa953] add file 1 file changed, 0 insertions(+), 0 deletions(-) create mode 100644 file.dat real15m36.666s user13m26.962s sys 0m16.185s # Auf Branch master nichts zu committen, Arbeitsverzeichnis unverändert real11m58.936s user11m50.300s sys 0m5.468s $ls -lh -rw-r--r-- 1 thomas thomas 20G Mai 20 19:01 file.dat So this works but aint fast. Playing some tricks with --assume-unchanged helps here: $git update-index --assume-unchanged file.dat $time git status # Auf Branch master nichts zu committen, Arbeitsverzeichnis unverändert real0m0.003s user0m0.000s sys 0m0.000s This trick is only save if you *know* that file.dat does not change. And btw I also set $cat .gitattributes *.dat -delta as delta compresssion should be skipped in any case. Pushing and pulling these files to and from a server needs some tweaking on the server side, otherwise the occasional git gc might kill the box. Btw. I happily have files with 1.5GB in my git repositories and also change them. And also work with git for windows. So in this region of file sizes things work quite well. -- 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: untracked file deleted from the master branch, when checked out to it from a local branch
On 5/20/2014 12:20 PM, Arup Rakshit wrote: On Tuesday, May 20, 2014 12:06:49 PM you wrote: It never came to the new branch, as it was never version controlled, it was an untracked file left behind when you switched branches. Once you added it to the new branch, change_class, it became a version controlled file, This is still didn't get it. If an untracked file didn't come in the new branch, how would I able to add it to stage ? I am not getting this part. You are right, but I am not able to understand this one, my bad! :( Ok, step by step: You've created test.rd, that was never added to the git repo. (You never committed it to the master branch.) ***HERE I switched to a NEW Branch Arup-iMac:arup_git shreyas$ git checkout -b change_class Switched to a new branch 'change_class' Arup-iMac:arup_git shreyas$ ls git_1.txt test.rb test.rd is untracked, so still there. Git doesn't touch untracked files. Arup-iMac:arup_git shreyas$ vi test.rb Arup-iMac:arup_git shreyas$ head -1 test.rb class Fooo Arup-iMac:arup_git shreyas$ head -2 test.rb class Fooo def self.bar You modified it Arup-iMac:arup_git shreyas$ git commit -am 'changed the class name' # On branch change_class # Untracked files: # (use git add file... to include in what will be committed) # #test.rb nothing added to commit but untracked files present (use git add to track) You did nothing here.. Arup-iMac:arup_git shreyas$ git add test.rb Arup-iMac:arup_git shreyas$ git commit -am 'changed the class name' [change_class 2d40033] changed the class name 1 file changed, 7 insertions(+) create mode 100644 test.rb Your previously untracked file has now been checked in. It's no longer untracked, so now Git cares. Arup-iMac:arup_git shreyas$ cat test.rb class Fooo def self.bar 12 end end Fooo.bar Arup-iMac:arup_git shreyas$ git checkout master Switched to branch 'master' You switched back to master branch, which contains no test.rb (as it's clean and has never been committed to), so therefore Git removes the file, since the now tracked test.rb shouldn't be on the master branch. -- .marius -- 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] rebase -i: test Nothing to do case with autostash
Matthieu Moy matthieu@imag.fr writes: Signed-off-by: Matthieu Moy matthieu@imag.fr --- Eric Sunshine sunsh...@sunshineco.com writes: Simpler (replace above two lines): test_set_editor $(pwd)/abort-editor.sh Indeed. And I had debug statements left. Hopefully, this after-coffee-v2 will be clear enough and correct ;-). Thanks, will queue on top of Ram's fix. -- 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-prompt.sh: don't assume the shell expands the value of PS1
Richard Hansen rhan...@bbn.com writes: Not all shells subject the prompt string to parameter expansion. Test whether the shell will expand the value of PS1, and use the result to control whether raw ref names are included directly in PS1. This fixes a regression introduced in commit 8976500 (git-prompt.sh: don't put unsanitized branch names in $PS1): zsh does not expand PS1 by default, but that commit assumed it did. The bug resulted in prompts containing the literal string '${__git_ps1_branch_name}' instead of the actual branch name. Reported-by: Caleb Thompson ca...@calebthompson.io Signed-off-by: Richard Hansen rhan...@bbn.com --- Thanks, applied. To prevent a regression like this from happening again, I plan on adding new zsh test cases and expanding the bash test cases (to test the behavior with 'shopt -u promptvars'). I'd like the zsh tests to cover the same stuff as the bash tests. These are the steps I am considering: 1. delete the last test case in t9903 (prompt - zsh color pc mode) 2. add two new functions to t/lib-bash.sh: ps1_expansion_enable () { shopt -s promptvars; } ps1_expansion_disable () { shopt -u promptvars; } 3. loop over the relevant test cases twice: once after calling ps1_expansion_enable and once after calling ps1_expansion_disable (with appropriate adjustments to the expected output) 4. move the test cases in t9903 to a separate library file and source it from t9903-bash-prompt.sh 5. create two new files: * t/lib-zsh.sh (same as t/lib-bash.sh but tweaked for zsh) * t/t9904-zsh-prompt.sh (same as t/t9903-bash-prompt.sh but tweaked for zsh) Does this approach sound reasonable? Sounds like a plan, especially if step 4 does a reasonable job of factoring out as much common stuff as possible. -- 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: untracked file deleted from the master branch, when checked out to it from a local branch
On Tuesday, May 20, 2014 11:24:11 AM you wrote: Arup Rakshit arupraks...@rocketmail.com writes: Untracked files and modifications to files in your working directory do not belong to your current branch. This is to allow you, after starting to work on one branch then realizing that the changes and additions you are making do not belong there, to switch to a more appropriate branch at that point without losing your work so far, taking these changes and additions with you to the branch you want to commit your changes to. Now, It makes sense. I gave it another try and this time I walk from back to front. Now you can see, that I have created, a new file called *file.txt*, in the *master branch*. Now I went to a new branch and made some changes there in the newly created file. This time I didn't add it or commit too. I just came back to *master branch*. Now if I do *ls*, can see the file is present in the *master* branch. arup@linux-wzza:~/Git_tutorial ls test.txt arup@linux-wzza:~/Git_tutorial echo hello file.txt arup@linux-wzza:~/Git_tutorial ls file.txt test.txt arup@linux-wzza:~/Git_tutorial git status # On branch master # Untracked files: # (use git add file... to include in what will be committed) # # file.txt nothing added to commit but untracked files present (use git add to track) arup@linux-wzza:~/Git_tutorial cat file.txt hello arup@linux-wzza:~/Git_tutorial git checkout -b file_branch Switched to a new branch 'file_branch' arup@linux-wzza:~/Git_tutorial cat file.txt hello arup@linux-wzza:~/Git_tutorial echo hello World file.txt arup@linux-wzza:~/Git_tutorial cat file.txt hello World arup@linux-wzza:~/Git_tutorial git status # On branch file_branch # Untracked files: # (use git add file... to include in what will be committed) # # file.txt nothing added to commit but untracked files present (use git add to track) arup@linux-wzza:~/Git_tutorial git checkout master Switched to branch 'master' arup@linux-wzza:~/Git_tutorial ls file.txt test.txt arup@linux-wzza:~/Git_tutorial cat file.txt hello World arup@linux-wzza:~/Git_tutorial -- === Regards, Arup Rakshit -- 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: untracked file deleted from the master branch, when checked out to it from a local branch
On 5/20/2014 12:40 PM, Arup Rakshit wrote: On Tuesday, May 20, 2014 11:24:11 AM you wrote: Arup Rakshit arupraks...@rocketmail.com writes: Untracked files and modifications to files in your working directory do not belong to your current branch. This is to allow you, after starting to work on one branch then realizing that the changes and additions you are making do not belong there, to switch to a more appropriate branch at that point without losing your work so far, taking these changes and additions with you to the branch you want to commit your changes to. Now, It makes sense. I gave it another try and this time I walk from back to front. Now you can see, that I have created, a new file called *file.txt*, in the *master branch*. NO, you didn't. arup@linux-wzza:~/Git_tutorial git status # On branch master # Untracked files: # (use git add file... to include in what will be committed) # # file.txt See that file.txt is listed under Untracked files? Git sees the file, but since you haven't added it with git add, it's untracked and Git doesn't care about it. It lists it with the status command, so you will see that it's not yet tracked. -- .marius -- 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 v5] format-patch --signature-file file
Jeff King p...@peff.net writes: If it were just --signature, I'd agree. After all, nobody is even complaining. But this is also in preparation for --signature-file. Should the user create a file without a trailing newline? Ahh, I missed that part. I am fine with processing it with stripspace(). By the way, at some point we may want to move that helper function to strbuf.c, but that is a separate issue. -- 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 01/19] check_bindir: convert test -a/-o to and ||
Junio C Hamano gits...@pobox.com writes: As I already said, I think better known is much less of an issue than that -a/-o is more error prone, and that is the reason why we may want to do this rewrite. I do not know offhand how busy the tree would be when we can apply these patches post-release without them getting rebased, but the zero-th step before this series may want to be a patch like this. ... and this time with a proposed log message. -- 8 -- Subject: [PATCH] CodingGuidelines: avoid test cond -a/-o cond The construct is error-prone; test being built-in in most modern shells, the reason to avoid test cond test cond spawning one extra process by using a single test cond -a cond no longer exists. Signed-off-by: Junio C Hamano gits...@pobox.com --- Documentation/CodingGuidelines | 13 + 1 file changed, 13 insertions(+) diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines index 3d08671..4d90c77 100644 --- a/Documentation/CodingGuidelines +++ b/Documentation/CodingGuidelines @@ -151,6 +151,19 @@ For shell scripts specifically (not exhaustive): interface translatable. See Marking strings for translation in po/README. + - We do not write our test command with -a and -o and use + or || to concatenate multiple test commands instead, because + the use of -a/-o is often error-prone. E.g. + + test -n $x -a $a = $b + + is buggy and breaks when $x is =, but + + test -n $x test $a = $b + + does not have such a problem. + + For C programs: - We use tabs to indent, and interpret tabs as taking up to -- 2.0.0-rc3-438-g36dae77 -- 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] Windows: Allow using UNC path for git repository
Stepan Kasal ka...@ucw.cz writes: From: Cezary Zawadka czawa...@gmail.com Date: Tue, 13 Jul 2010 16:17:43 +0200 [efl: moved MinGW-specific part to compat/] [jes: fixed compilation on non-Windows] Eric Sunshine fixed mingw_offset_1st_component() to return consistently foo for UNC //machine/share/foo, cf http://groups.google.com/group/msysgit/browse_thread/thread/c0af578549b5dda0 Author: Eric Sunshine sunsh...@sunshineco.com Signed-off-by: Cezary Zawadka czawa...@gmail.com Signed-off-by: Eric Sunshine sunsh...@sunshineco.com Signed-off-by: Erik Faye-Lund kusmab...@gmail.com Signed-off-by: Johannes Schindelin johannes.schinde...@gmx.de Signed-off-by: Stepan Kasal ka...@ucw.cz --- Hello, this is another patch that lived in msysGit for years, at least from Jul 13, 2010. It was there in two parts, first sketch by Cezary and a fix from Eric Sunshine, but I decided to submit the combined version. Let me note that this patch should not affect any non-Windows platform. The chnage of offset_1st_component() to a simple macro is ok, because has_dos_drive_prefix() is 0 there. As I do not think anybody takes the address of the function, I agree it should be a no-op for non-Windows platform. It would be nice if somebody in the S-o-b chain can double-check that the combined version is sane. I didn't read the mingw.c part carefully enough for me to say returning 0 upon error is sane with confidence, for example. Thanks. Regards, Stepan cache.h | 1 - compat/mingw.c| 24 compat/mingw.h| 2 ++ git-compat-util.h | 4 path.c| 7 --- 5 files changed, 30 insertions(+), 8 deletions(-) diff --git a/cache.h b/cache.h index ebe9a40..0961fb5 100644 --- a/cache.h +++ b/cache.h @@ -781,7 +781,6 @@ int normalize_path_copy(char *dst, const char *src); int longest_ancestor_length(const char *path, struct string_list *prefixes); char *strip_path_suffix(const char *path, const char *suffix); int daemon_avoid_alias(const char *path); -int offset_1st_component(const char *path); /* object replacement */ #define LOOKUP_REPLACE_OBJECT 1 diff --git a/compat/mingw.c b/compat/mingw.c index e9892f8..a0e13bc 100644 --- a/compat/mingw.c +++ b/compat/mingw.c @@ -1823,3 +1823,27 @@ pid_t waitpid(pid_t pid, int *status, int options) errno = EINVAL; return -1; } + +int mingw_offset_1st_component(const char *path) +{ + int offset = 0; + if (has_dos_drive_prefix(path)) + offset = 2; + + /* unc paths */ + else if (is_dir_sep(path[0]) is_dir_sep(path[1])) { + + /* skip server name */ + char *pos = strpbrk(path + 2, \\/); + if (!pos) + return 0; /* Error: malformed unc path */ + + do { + pos++; + } while (*pos !is_dir_sep(*pos)); + + offset = pos - path; + } + + return offset + is_dir_sep(path[offset]); +} diff --git a/compat/mingw.h b/compat/mingw.h index e033e72..3eaf822 100644 --- a/compat/mingw.h +++ b/compat/mingw.h @@ -339,6 +339,8 @@ static inline char *mingw_find_last_dir_sep(const char *path) return ret; } #define find_last_dir_sep mingw_find_last_dir_sep +int mingw_offset_1st_component(const char *path); +#define offset_1st_component mingw_offset_1st_component #define PATH_SEP ';' #define PRIuMAX I64u #define PRId64 I64d diff --git a/git-compat-util.h b/git-compat-util.h index d493a8c..ec41cfb 100644 --- a/git-compat-util.h +++ b/git-compat-util.h @@ -270,6 +270,10 @@ extern char *gitbasename(char *); #define has_dos_drive_prefix(path) 0 #endif +#ifndef offset_1st_component +#define offset_1st_component(path) (is_dir_sep((path)[0])) +#endif + #ifndef is_dir_sep #define is_dir_sep(c) ((c) == '/') #endif diff --git a/path.c b/path.c index f9c5062..bc804a3 100644 --- a/path.c +++ b/path.c @@ -823,10 +823,3 @@ int daemon_avoid_alias(const char *p) } } } - -int offset_1st_component(const char *path) -{ - if (has_dos_drive_prefix(path)) - return 2 + is_dir_sep(path[2]); - return is_dir_sep(path[0]); -} -- 1.9.2.msysgit.0.490.ga07b726 -- -- 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: EXT :Re: GIT and large files
On Tue, 20 May 2014 18:18:08 + Stewart, Louis (IS) louis.stew...@ngc.com wrote: From you response then there is a method to only obtain the Project, Directory and Files (which could hold 80 GBs of data) and not the rest of the Repository that contained the full overall Projects? Please google the phrase Git shallow cloning. I would also recommend to read up on git-annex [1]. You might also consider using Subversion as it seems you do not need most benefits Git has over it and want certain benefits Subversion has over Git: * You don't need a distributed VCS (as you don't want each developer to have a full clone). * You only need a single slice of the repository history at any given revision on a developer's machine, and this is *almost* what Subversion does: it will keep the so-called base (or pristine) versions of files comprising the revision you will check out, plus the checked out files theirselves. So, twice the space of the files comprising a revision. * Subversion allows you to check out only a single folder out of the entire revision. * IIRC, subversion supports locks, when a developer might tell the server they're editing a file, and this will prevent other devs from locking the same file. This might be used to serialize editions of huge and/or unmergeable files. Git can't do that (without non-standard tools deployed on the side or a centralized meeting point repository). My point is that while Git is fantastic for managing source code projects and project of similar types with regard to their contents, it seems your requirements are mainly not suitable for the use case Git is best tailored for. Your apparent lack of familiarity with Git might as well bite you later should you pick it right now. At least please consider reading a book or some other introduction-level material on Git to get the feeling of typical workflows used with it. 1. https://git-annex.branchable.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
[RFC/PATCH v4 0/3] add performance tracing facility
This is the POSIX port of the patches I typically use to track down msysgit performance issues (thus v4, the latest windows-only version is here [1]). Sebastian and Dscho thought this might be useful in core git, so here it is. [1] https://github.com/msysgit/git/pull/46 Karsten Blees (3): add high resolution timer function to debug performance issues add trace_performance facility to debug performance issues add command performance tracing to debug scripted commands Makefile | 7 +++ cache.h | 20 config.mak.uname | 1 + git.c| 2 + trace.c | 144 +++ 5 files changed, 174 insertions(+) -- 1.9.2.msysgit.0.493.g47a82c3 -- 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
[RFC/PATCH v4 2/3] add trace_performance facility to debug performance issues
Add trace_performance and trace_performance_since macros that print file name, line number, time and an optional printf-formatted text to the file specified in environment variable GIT_TRACE_PERFORMANCE. Unless enabled via GIT_TRACE_PERFORMANCE, these macros have no noticeable impact on performance, so that test code may be shipped in release builds. MSVC: variadic macros (__VA_ARGS__) require VC++ 2005 or newer. Simple use case (measure one code section): uint64_t start = getnanotime(); /* code section to measure */ trace_performance_since(start, foobar); Medium use case (measure consecutive code sections): uint64_t start = getnanotime(); /* first code section to measure */ start = trace_performance_since(start, first foobar); /* second code section to measure */ trace_performance_since(start, second foobar); Complex use case (measure repetitive code sections): uint64_t t = 0; for (;;) { /* ignore */ t -= getnanotime(); /* code section to measure */ t += getnanotime(); /* ignore */ } trace_performance(t, frotz); Signed-off-by: Karsten Blees bl...@dcon.de --- cache.h | 18 ++ trace.c | 40 2 files changed, 58 insertions(+) diff --git a/cache.h b/cache.h index 48fc616..cb856d9 100644 --- a/cache.h +++ b/cache.h @@ -1363,6 +1363,24 @@ __attribute__((format (printf, 2, 3))) extern void trace_printf_key(const char *key, const char *fmt, ...); extern void trace_strbuf(const char *key, const struct strbuf *buf); extern uint64_t getnanotime(void); +__attribute__((format (printf, 4, 5))) +extern uint64_t trace_performance_file_line(const char *file, int lineno, + uint64_t nanos, const char *fmt, ...); + +/* + * Prints specified time (in nanoseconds) if GIT_TRACE_PERFORMANCE is enabled. + * Returns current time in nanoseconds. + */ +#define trace_performance(nanos, ...) \ + trace_performance_file_line(__FILE__, __LINE__, nanos, __VA_ARGS__) + +/* + * Prints time since 'start' if GIT_TRACE_PERFORMANCE is enabled. + * Returns current time in nanoseconds. + */ +#define trace_performance_since(start, ...) \ + trace_performance_file_line(__FILE__, __LINE__, \ + getnanotime() - (start), __VA_ARGS__) void packet_trace_identity(const char *prog); diff --git a/trace.c b/trace.c index 3d72084..1b1903b 100644 --- a/trace.c +++ b/trace.c @@ -269,3 +269,43 @@ inline uint64_t getnanotime(void) return now; } } + +static const char *GIT_TRACE_PERFORMANCE = GIT_TRACE_PERFORMANCE; + +static inline int trace_want_performance(void) +{ + static int enabled = -1; + if (enabled 0) + enabled = trace_want(GIT_TRACE_PERFORMANCE); + return enabled; +} + +/* + * Prints performance data if environment variable GIT_TRACE_PERFORMANCE is + * set, otherwise a NOOP. Returns the current time in nanoseconds. + */ +__attribute__((format (printf, 4, 5))) +uint64_t trace_performance_file_line(const char *file, int lineno, +uint64_t nanos, const char *fmt, ...) +{ + struct strbuf buf = STRBUF_INIT; + va_list args; + + if (!trace_want_performance()) + return 0; + + strbuf_addf(buf, performance: at %s:%i, time: %.9f s, file, lineno, + (double) nanos / 10); + + if (fmt *fmt) { + strbuf_addstr(buf, : ); + va_start(args, fmt); + strbuf_vaddf(buf, fmt, args); + va_end(args); + } + strbuf_addch(buf, '\n'); + + trace_strbuf(GIT_TRACE_PERFORMANCE, buf); + strbuf_release(buf); + return getnanotime(); +} -- 1.9.2.msysgit.0.493.g47a82c3 -- 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
[RFC/PATCH v4 1/3] add high resolution timer function to debug performance issues
Add a getnanotime() function that returns nanoseconds since 01/01/1970 as unsigned 64-bit integer (i.e. overflows in july 2554). This is easier to work with than e.g. struct timeval or struct timespec. The implementation uses gettimeofday() by default; supports high precision time sources on the following platforms: * Linux: using clock_gettime(CLOCK_MONOTONIC) * Windows: using QueryPerformanceCounter() Todo: * enable clock_gettime() on more platforms * implement Mac OSX version using mach_absolute_time Signed-off-by: Karsten Blees bl...@dcon.de --- Makefile | 7 + cache.h | 1 + config.mak.uname | 1 + trace.c | 82 4 files changed, 91 insertions(+) diff --git a/Makefile b/Makefile index a53f3a8..3c05f8c 100644 --- a/Makefile +++ b/Makefile @@ -341,6 +341,8 @@ all:: # # Define GMTIME_UNRELIABLE_ERRORS if your gmtime() function does not # return NULL when it receives a bogus time_t. +# +# Define HAVE_CLOCK_GETTIME if your platform has clock_gettime in librt. GIT-VERSION-FILE: FORCE @$(SHELL_PATH) ./GIT-VERSION-GEN @@ -1497,6 +1499,11 @@ ifdef GMTIME_UNRELIABLE_ERRORS BASIC_CFLAGS += -DGMTIME_UNRELIABLE_ERRORS endif +ifdef HAVE_CLOCK_GETTIME + BASIC_CFLAGS += -DHAVE_CLOCK_GETTIME + EXTLIBS += -lrt +endif + ifeq ($(TCLTK_PATH),) NO_TCLTK = NoThanks endif diff --git a/cache.h b/cache.h index 107ac61..48fc616 100644 --- a/cache.h +++ b/cache.h @@ -1362,6 +1362,7 @@ extern int trace_want(const char *key); __attribute__((format (printf, 2, 3))) extern void trace_printf_key(const char *key, const char *fmt, ...); extern void trace_strbuf(const char *key, const struct strbuf *buf); +extern uint64_t getnanotime(void); void packet_trace_identity(const char *prog); diff --git a/config.mak.uname b/config.mak.uname index 23a8803..5e3b1dd 100644 --- a/config.mak.uname +++ b/config.mak.uname @@ -33,6 +33,7 @@ ifeq ($(uname_S),Linux) HAVE_PATHS_H = YesPlease LIBC_CONTAINS_LIBINTL = YesPlease HAVE_DEV_TTY = YesPlease + HAVE_CLOCK_GETTIME = YesPlease endif ifeq ($(uname_S),GNU/kFreeBSD) NO_STRLCPY = YesPlease diff --git a/trace.c b/trace.c index 08180a9..3d72084 100644 --- a/trace.c +++ b/trace.c @@ -187,3 +187,85 @@ int trace_want(const char *key) return 0; return 1; } + +#ifdef HAVE_CLOCK_GETTIME + +static inline uint64_t highres_nanos(void) +{ + struct timespec ts; + if (clock_gettime(CLOCK_MONOTONIC, ts)) + return 0; + return (uint64_t) ts.tv_sec * 10 + ts.tv_nsec; +} + +#elif defined (GIT_WINDOWS_NATIVE) + +static inline uint64_t highres_nanos(void) +{ + static uint64_t high_ns, scaled_low_ns; + static int scale; + LARGE_INTEGER cnt; + + if (!scale) { + if (!QueryPerformanceFrequency(cnt)) + return 0; + + /* high_ns = number of ns per cnt.HighPart */ + high_ns = (10LL 32) / (uint64_t) cnt.QuadPart; + + /* +* Number of ns per cnt.LowPart is 10^9 / frequency (or +* high_ns 32). For maximum precision, we scale this factor +* so that it just fits within 32 bit (i.e. won't overflow if +* multiplied with cnt.LowPart). +*/ + scaled_low_ns = high_ns; + scale = 32; + while (scaled_low_ns = 0x1LL) { + scaled_low_ns = 1; + scale--; + } + } + + /* if QPF worked on initialization, we expect QPC to work as well */ + QueryPerformanceCounter(cnt); + + return (high_ns * cnt.HighPart) + + ((scaled_low_ns * cnt.LowPart) scale); +} + +#else +# define highres_nanos() 0 +#endif + +static inline uint64_t gettimeofday_nanos(void) +{ + struct timeval tv; + gettimeofday(tv, NULL); + return (uint64_t) tv.tv_sec * 10 + tv.tv_usec * 1000; +} + +/* + * Returns nanoseconds since the epoch (01/01/1970), for performance tracing + * (i.e. favoring high precision over wall clock time accuracy). + */ +inline uint64_t getnanotime(void) +{ + static uint64_t offset; + if (offset 1) { + /* initialization succeeded, return offset + high res time */ + return offset + highres_nanos(); + } else if (offset == 1) { + /* initialization failed, fall back to gettimeofday */ + return gettimeofday_nanos(); + } else { + /* initialize offset if high resolution timer works */ + uint64_t now = gettimeofday_nanos(); + uint64_t highres = highres_nanos(); + if (highres) + offset = now - highres; + else + offset = 1; + return now; + } +} --
[RFC/PATCH v4 3/3] add command performance tracing to debug scripted commands
Add performance tracing to identify which git commands are called and how long they execute. This is particularly useful to debug performance issues of scripted commands. Usage example: GIT_TRACE_PERFORMANCE=~/git-trace.log git stash list Creates a log file like this: performance: at trace.c:319, time: 0.000303280 s: git command: 'git' 'rev-parse' '--git-dir' performance: at trace.c:319, time: 0.000334409 s: git command: 'git' 'rev-parse' '--is-inside-work-tree' performance: at trace.c:319, time: 0.000215243 s: git command: 'git' 'rev-parse' '--show-toplevel' performance: at trace.c:319, time: 0.000410639 s: git command: 'git' 'config' '--get-colorbool' 'color.interactive' performance: at trace.c:319, time: 0.000394077 s: git command: 'git' 'config' '--get-color' 'color.interactive.help' 'red bold' performance: at trace.c:319, time: 0.000280701 s: git command: 'git' 'config' '--get-color' '' 'reset' performance: at trace.c:319, time: 0.000908185 s: git command: 'git' 'rev-parse' '--verify' 'refs/stash' performance: at trace.c:319, time: 0.028827774 s: git command: 'git' 'stash' 'list' Signed-off-by: Karsten Blees bl...@dcon.de --- cache.h | 1 + git.c | 2 ++ trace.c | 22 ++ 3 files changed, 25 insertions(+) diff --git a/cache.h b/cache.h index cb856d9..289e8fd 100644 --- a/cache.h +++ b/cache.h @@ -1366,6 +1366,7 @@ extern uint64_t getnanotime(void); __attribute__((format (printf, 4, 5))) extern uint64_t trace_performance_file_line(const char *file, int lineno, uint64_t nanos, const char *fmt, ...); +extern void trace_command_performance(const char **argv); /* * Prints specified time (in nanoseconds) if GIT_TRACE_PERFORMANCE is enabled. diff --git a/git.c b/git.c index 9efd1a3..2ea65b1 100644 --- a/git.c +++ b/git.c @@ -568,6 +568,8 @@ int main(int argc, char **av) git_setup_gettext(); + trace_command_performance(argv); + /* * git- is the same as git , but we obviously: * diff --git a/trace.c b/trace.c index 1b1903b..9edcb59 100644 --- a/trace.c +++ b/trace.c @@ -309,3 +309,25 @@ uint64_t trace_performance_file_line(const char *file, int lineno, strbuf_release(buf); return getnanotime(); } + +static uint64_t command_start_time; +static struct strbuf command_line = STRBUF_INIT; + +static void print_command_performance_atexit(void) +{ + trace_performance_since(command_start_time, git command:%s, + command_line.buf); +} + +void trace_command_performance(const char **argv) +{ + if (!trace_want_performance()) + return; + + if (!command_start_time) + atexit(print_command_performance_atexit); + + strbuf_reset(command_line); + sq_quote_argv(command_line, argv, 0); + command_start_time = getnanotime(); +} -- 1.9.2.msysgit.0.493.g47a82c3 -- 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] Windows: Allow using UNC path for git repository
Hello, On Tue, May 20, 2014 at 11:57:56AM -0700, Junio C Hamano wrote: It would be nice if somebody in the S-o-b chain can double-check that the combined version is sane. [...] Combined was an unfortunate word. There was a pair of successive commits in msysgit all the time. I just decided to submit them squashed together. I haven't changed the code, just created a new commit message. That said, reviewing the function is always useful, of course. Stepan -- 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] remote: defer repacking packed-refs when deleting refs
Jens Lindström j...@opera.com writes: When 'git remote rm' or 'git remote prune' were used in a repository with many refs, and needed to delete many refs, a lot of time was spent deleting those refs since for each deleted ref, repack_without_refs() was called to rewrite packed-refs without just that deleted ref. To avoid this, defer the repacking until after all refs have been deleted (by delete_ref()), and then call repack_without_refs() once to repack without all the deleted refs. Signed-off-by: Jens Lindström j...@opera.com --- This patch changes behavior when the operation is aborted in the middle, so that loose refs and ref logs might have been deleted, but not the corresponding entries in packed-refs, since packed-refs is now only updated at the end. Also this makes it a bit more dangerous for processes accessing the repository while pruning is in progress by exposing stale refs that may be pointing at objects that are no longer present in the object store in the packed-refs file for a longer period (git fsck may fail, for example). As long as we accept that removing a remote or pruning one are kinds of maintenance operations and nobody else should be peeking into the repository during maintenance period, it may be alright, but aborting the operation in the middle will essentially leave the repository in a corrupted state---the abort corrupts is a downside with or without this change and is not a new problem. A bit safer way to organize might be to first create a list of the refs to be removed in-core, update packed-refs without these refs to be removed, and then finally remove the loose ones, but I haven't thought things through. -- 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] Windows: Allow using UNC path for git repository
Stepan Kasal ka...@ucw.cz writes: Hello, On Tue, May 20, 2014 at 11:57:56AM -0700, Junio C Hamano wrote: It would be nice if somebody in the S-o-b chain can double-check that the combined version is sane. [...] Combined was an unfortunate word. There was a pair of successive commits in msysgit all the time. I just decided to submit them squashed together. I haven't changed the code, just created a new commit message. That said, reviewing the function is always useful, of course. I did mis-read your message. As the patch shows the current state that exists in msysgit that people are happy about, the function has already been reviewed by stakeholders, and I would be happy to apply it. Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 25/44] receive-pack.c: use a reference transaction for updating the refs
Ronnie Sahlberg wrote: Wrap all the ref updates inside a transaction to make the update atomic. Interesting. [...] --- a/builtin/receive-pack.c +++ b/builtin/receive-pack.c @@ -46,6 +46,8 @@ static void *head_name_to_free; static int sent_capabilities; static int shallow_update; static const char *alt_shallow_file; +static struct strbuf err = STRBUF_INIT; I think it would be cleaner for err to be local. It isn't used for communication between functions. [...] @@ -580,15 +581,9 @@ static const char *update(struct command *cmd, struct shallow_info *si) update_shallow_ref(cmd, si)) return shallow error; - lock = lock_any_ref_for_update(namespaced_name, old_sha1, -0, NULL); - if (!lock) { - rp_error(failed to lock %s, name); - return failed to lock; - } - if (write_ref_sha1(lock, new_sha1, push)) { - return failed to write; /* error() already called */ - } + if (ref_transaction_update(transaction, namespaced_name, +new_sha1, old_sha1, 0, 1, err)) + return failed to update; The original used rp_error to send an error message immediately via sideband. This drops that --- intended? The old error string shown on the push status line was was failed to lock or failed to write which makes it clear that the cause is contention or database problems or filesystem problems, respectively. After this change it would say failed to update which is about as clear as failed. Would it be safe to send err.buf as-is over the wire, or does it contain information or formatting that wouldn't be suitable for the client? (I haven't thought this through completely yet.) Is there some easy way to distinguish between failure to lock and failure to write? Or is there some one-size-fits-all error for this case? When the transaction fails, we need to make sure that all ref updates emit 'ng' and not 'ok' in receive-pack.c::report (see the example at the end of Documentation/technical/pack-protocol.txt for what this means). What error string should they use? Is there some way to make it clear to the user which ref was the culprit? What should happen when checks outside the ref transaction system cause a ref update to fail? I'm thinking of * per-ref 'update' hook (see githooks(5)) * fast-forward check * ref creation/deletion checks * attempt to push to the currently checked out branch I think the natural thing to do would be to put each ref update in its own transaction to start so the semantics do not change right away. If there are obvious answers to all these questions, then a separate patch could combine all these into a single transaction; or if there are no obvious answers, we could make the single-transaction-per-push semantics optional (using a configuration variable or protocol capability or something) to make it possible to experiment. Hope that helps, Jonathan -- 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] remote: defer repacking packed-refs when deleting refs
Junio C Hamano gits...@pobox.com writes: A bit safer way to organize might be to first create a list of the refs to be removed in-core, update packed-refs without these refs to be removed, and then finally remove the loose ones, but I haven't thought things through. Perhaps a removal of remote can go in this order to be resistant against an abort-in-the-middle. * update packed-refs without the refs that came from the remote. - when interrupted before the new temporary file is renamed to the final, it would be a no-op. - when interrupted after the rename, only some refs that came from the remote may disappear. * remove the loose refs that came from the remote. * finally, remove the configuration related to the remote. This order would let you interrupt remote rm without leaving the repository in a broken state. Before the final state, it may appear that you have some but not all remote-tracking refs from the remote in your repository, but you would not have any ref that point at an obsolete object. Running remote rm again, once it finishes, will give you the desired result. A longer-term goal might be to have ref-transaction infrastructure clever enough to coalesce the repack-without-these-refs requests into one automatically without forcing the callers you are fixing care about these things, though. And such a transaction semantics may have to also cover the updating of configuration files. -- 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 v8 25/44] receive-pack.c: use a reference transaction for updating the refs
On Tue, May 20, 2014 at 12:42 PM, Jonathan Nieder jrnie...@gmail.com wrote: Ronnie Sahlberg wrote: Wrap all the ref updates inside a transaction to make the update atomic. Interesting. [...] --- a/builtin/receive-pack.c +++ b/builtin/receive-pack.c @@ -46,6 +46,8 @@ static void *head_name_to_free; static int sent_capabilities; static int shallow_update; static const char *alt_shallow_file; +static struct strbuf err = STRBUF_INIT; I think it would be cleaner for err to be local. It isn't used for communication between functions. Done. [...] @@ -580,15 +581,9 @@ static const char *update(struct command *cmd, struct shallow_info *si) update_shallow_ref(cmd, si)) return shallow error; - lock = lock_any_ref_for_update(namespaced_name, old_sha1, -0, NULL); - if (!lock) { - rp_error(failed to lock %s, name); - return failed to lock; - } - if (write_ref_sha1(lock, new_sha1, push)) { - return failed to write; /* error() already called */ - } + if (ref_transaction_update(transaction, namespaced_name, +new_sha1, old_sha1, 0, 1, err)) + return failed to update; The original used rp_error to send an error message immediately via sideband. This drops that --- intended? Oops. I misread it as a normal error() The old error string shown on the push status line was was failed to lock or failed to write which makes it clear that the cause is contention or database problems or filesystem problems, respectively. After this change it would say failed to update which is about as clear as failed. I changed it to return xstrdup(err.buf) which should be as detailed as we can get. Would it be safe to send err.buf as-is over the wire, or does it contain information or formatting that wouldn't be suitable for the client? (I haven't thought this through completely yet.) Is there some easy way to distinguish between failure to lock and failure to write? Or is there some one-size-fits-all error for this case? I think err.buf is what we want. When the transaction fails, we need to make sure that all ref updates emit 'ng' and not 'ok' in receive-pack.c::report (see the example at the end of Documentation/technical/pack-protocol.txt for what this means). What error string should they use? Is there some way to make it clear to the user which ref was the culprit? What should happen when checks outside the ref transaction system cause a ref update to fail? I'm thinking of * per-ref 'update' hook (see githooks(5)) * fast-forward check * ref creation/deletion checks * attempt to push to the currently checked out branch I think the natural thing to do would be to put each ref update in its own transaction to start so the semantics do not change right away. If there are obvious answers to all these questions, then a separate patch could combine all these into a single transaction; or if there are no obvious answers, we could make the single-transaction-per-push semantics optional (using a configuration variable or protocol capability or something) to make it possible to experiment. I changed it to use one transaction per ref for now. Please see the update ref-transactions branch. Thanks! -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 26/44] fast-import.c: use a ref transaction when dumping tags
Ronnie Sahlberg wrote: [Subject: fast-import.c: use a ref transaction when dumping tags] This seems like an odd thing to do: either it would make sense to have a single transaction for all imported refs so all fail or succeed together, or there would be separate transactions for each ref. That said, I don't mind, particularly if it's a step on the way to using a single transaction for everything being dumped. [...] --- a/fast-import.c +++ b/fast-import.c @@ -1736,15 +1736,22 @@ static void dump_tags(void) { static const char *msg = fast-import; struct tag *t; - struct ref_lock *lock; char ref_name[PATH_MAX]; + struct strbuf err = STRBUF_INIT; + struct ref_transaction *transaction; + transaction = ref_transaction_begin(); for (t = first_tag; t; t = t-next_tag) { - sprintf(ref_name, tags/%s, t-name); + sprintf(ref_name, refs/tags/%s, t-name); Can this overflow the buffer? - lock = lock_ref_sha1(ref_name, NULL); - if (!lock || write_ref_sha1(lock, t-sha1, msg) 0) - failure |= error(Unable to update %s, ref_name); + + if (ref_transaction_update(transaction, ref_name, t-sha1, +NULL, 0, 0, err)) { + failure |= 1; + break; + } } + if (failure || ref_transaction_commit(transaction, msg, err)) + failure |= error(Unable to update %s, err.buf); This 'if (failure || ...) failure |=' idiom seems strange. Is err.buf always set if failure is nonzero? Elsewhere failure is 0 or -1 but this introduces the possibility for it to be temporarily 1. dump_branches could have caused failure to be -1 before dump_tags is called. I think the intent is if (ref_transaction_update(...)) { failure |= error(...); goto out; } } if (ref_transaction_commit(...)) failure |= error(...); out: ref_transaction_free(transaction); ... Thanks, Jonathan -- 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] remote-helpers: point at their upstream repositories
Junio C Hamano wrote: Felipe Contreras felipe.contre...@gmail.com writes: Junio C Hamano wrote: 2. add warning that is given every time the scripts are run and give the same instruction as in README. 3. (optional) cripple the script to make them always fail after showing the same warning as above. This is what I want, and I already sent the patches for; the scripts will be stubs. At this point you would have effectively removed the code, which what I want. 4. Keep README and retire everything else. After you've removed the code, I don't care what you do, but I'd say you should remove the stubs after a long period of time. Let's try this in a different way, as I sense there is a misunderstanding somewhere about your wish. that does not refer to remove them at v2.0 (unconditional). It refers to If Felipe really wants for the removal for v2.0, I would respect that. And I saw you said you did not want to disrupt v2.0. If the options I listed all meant removal at v2.0, then I would understand your complaints, but that is not the case, so I am not sure what to make of that. It is a weird choice of semantics then. You said you would respect my wish, but your proposals did not follow my wish. I understand you do not want to disrupt v2.0. My assumption of that not disrupting v2.0 has been there still are git-remote-{hg,bzr} that work just like what they had in v1.9.x, perhaps with some enhancements and regressions you added in the meantime, and I understood Peff's comment If Felipe wants the removal to mean that kind of disruption, i.e. there is no git-remote-{hg,bzr} that work., which would be either step 3 or 4. But your After you've removed the code comment above makes me wonder that perhaps your definition of not disrupting was different from ours (which is not good or bad, just different) and you consider that step 3. is removal but not distupting v2.0? If that is what you want in v2.0, then please say so, and I already said I am fine with that. No, I already said I do not want the code removed from v2.0, that's why I sent patches that simply added a warning, and I specifically said those were for 2.0. However, after seeing this commit: 10e1fee (Revert Merge branch 'fc/transport-helper-sync-error-fix') Which is: 1) Inaccurate 2) A lie (*you* broke 2.0, not me) 3) A disservice to users I therefore change my wish for you to remove all the remote helpers code and a replace them with stubs (the patches I originally sent for post-2.0). It was a mistake from me to believe you would do the sensible thing for 2.0. So to make it clear, I now request that you do: 1) Remove all the code. Since my patches were removed from the list, here's an updated patch that applies on top of 'master' https://github.com/felipec/git/commits/up/remote/remove 2) Reapply d508e4a (Merge branch 'fc/transport-helper-sync-error-fix') Since the code in question is no longer part of v2.0, a possible regression that you aren't even sure of cannot be the rationale to revert this code. Your commit 10e1fee (Revert Merge branch 'fc/transport-helper-sync-error-fix') actively hurts the out-of-tree tools, so I'll consider a failure to re-revert a hostile action. 3) Update the release notes to mention these tools have been removed Additionally, you might want to: 4) Re-add the following release note: * git push via transport-helper interface (e.g. remote-hg) has been updated to allow forced ref updates in a way similar to the natively supported transports I don't know why you removed it in the first place. Clearly you pay no attention at all to these interfaces. I expect you to do at the very least 1) and 2). -- 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
Re: [PATCH v8 26/44] fast-import.c: use a ref transaction when dumping tags
On Tue, May 20, 2014 at 1:38 PM, Jonathan Nieder jrnie...@gmail.com wrote: Ronnie Sahlberg wrote: [Subject: fast-import.c: use a ref transaction when dumping tags] This seems like an odd thing to do: either it would make sense to have a single transaction for all imported refs so all fail or succeed together, or there would be separate transactions for each ref. That said, I don't mind, particularly if it's a step on the way to using a single transaction for everything being dumped. For now they are two transactions but I will merge them into a single one later. [...] --- a/fast-import.c +++ b/fast-import.c @@ -1736,15 +1736,22 @@ static void dump_tags(void) { static const char *msg = fast-import; struct tag *t; - struct ref_lock *lock; char ref_name[PATH_MAX]; + struct strbuf err = STRBUF_INIT; + struct ref_transaction *transaction; + transaction = ref_transaction_begin(); for (t = first_tag; t; t = t-next_tag) { - sprintf(ref_name, tags/%s, t-name); + sprintf(ref_name, refs/tags/%s, t-name); Can this overflow the buffer? Changed to snprint. (We probably should do this everywhere.) - lock = lock_ref_sha1(ref_name, NULL); - if (!lock || write_ref_sha1(lock, t-sha1, msg) 0) - failure |= error(Unable to update %s, ref_name); + + if (ref_transaction_update(transaction, ref_name, t-sha1, +NULL, 0, 0, err)) { + failure |= 1; + break; + } } + if (failure || ref_transaction_commit(transaction, msg, err)) + failure |= error(Unable to update %s, err.buf); This 'if (failure || ...) failure |=' idiom seems strange. Is err.buf always set if failure is nonzero? Elsewhere failure is 0 or -1 but this introduces the possibility for it to be temporarily 1. dump_branches could have caused failure to be -1 before dump_tags is called. I think the intent is if (ref_transaction_update(...)) { failure |= error(...); goto out; } } if (ref_transaction_commit(...)) failure |= error(...); out: ref_transaction_free(transaction); ... Actually, since the recent change to make _commit fail if the transaction has an error, what we want is something like this : ... if (ref_transaction_update(transaction, ref_name, t-sha1, NULL, 0, 0, err)) break; } if (ref_transaction_commit(transaction, msg, err)) failure |= error(%s, err.buf); ... Please see updated ref-transactions branch. Thanks. Thanks, Jonathan -- 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] remote-helpers: point at their upstream repositories
Junio C Hamano wrote: Felipe Contreras felipe.contre...@gmail.com writes: Junio C Hamano wrote: After looking at the reverse-depends list of packages, my faith is strengthened in that the Git ecosystem is truly maturing and useful third-party plug-ins will be picked up by distro packagers. Where is git-imerge packaged? I didn't see it on the archive the said Ubuntu box slurps from, but I did not check all the other distros. I will help you: it's not packaged anywhere. Do you want to bet? Nah, you don't *ever* want to accept you were wrong, even you clearly where. ... This is what's going to happen: there won't be an official git-hg package for *years*, if there is ever one. That is my prediction based on all the available evidence, I am willing to stand by it and accept I was wrong if it proves otherwise. Are you willing to stand by your own decisions? If I understand correctly, you have made and you do maintain some packages and as an insider, you do not have to wait for an outsider to step up to make remote-{hg,bzr} packages yourself. No, you do not understand how packaging works. ArchLinux's AUR[1] is a community-driven repository, anybody can package anything and put it there. That doesn't mean people can simply do `pacman -S git-remote-hg`, far from it. It's a placeholder for *outsiders*, not official package maintainers. I am an outsider in ArchLinux. You may already have done so for your own use and told other people about them, and others may have chosen to wait for you to push them to distros instead of championing these tools by packaging them themselves. You clearly haven't tried to package anything for any distro. You can't just champion packages for a distribution. You have to go through an arduous process before becoming an official packager. When you have such an influence on the outcome either way of your choice, I do not see much value in such a bet. If I champion these packages I would be making you win the bet. Why would I do that? But I actually think that we package what we want to use is a good thing for programs whose primary audience is the software developer types. The packagers are part of their audiences [*1*]. Because of that, even if remote-{hg,bzr} do not get packaged for a long time, I doubt that it tells us what you are stipulating. The only thing we can infer would be that these programs did not interest the software developer types to motivate them enough, and we wouldn't know why they found the programs uninteresting. It may be because those who have history in Hg prefer to interact with remote Git repositories by pushing into and fetching from them using Hg tools than using Git tools. It would not indicate useful tools fall through the cracks if it were the case, would it? Or it might mean that the people that would otherwise do that packaging instead simply copy the single file needed manually. Indeed I saw bzr-git that came from the Bazaar land packaged on the box I mentioned, and its description sounded like it is meant to work in such a way that allows Bazaar commits to be pushed to Git repositories using a bzr tool. By the way, I also saw git-mediawiki packaged from contrib/ in our tree. I found it not very credible to say contrib/ is treated as a single ball of wax without much value by packagers, and we need to move the helpers up to core in order for them to be used more widely after seeing that. You are misconstruing what I said. I said *most* distributions treat contrib as a ball of wax. And I said there were a few *exceptions* on this ball of wax, like completions. remote-helpers are not part of these exceptions (with the exception of git-bzr). *1* I saw you called them wolves at least twice recently---where does such a distrust come from? It's a jungle out there, and it's every out-of-tree tool by itself. Most of the tools on the contrib/ area would not survive if you throw them to those wolves, and you know it. [1] https://wiki.archlinux.org/index.php/Arch_User_Repository -- 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
Re: [PATCH] remote-helpers: point at their upstream repositories
Felipe Contreras felipe.contre...@gmail.com writes: Let's try this in a different way, as I sense there is a misunderstanding somewhere about your wish. ... No, I already said I do not want the code removed from v2.0, that's why I sent patches that simply added a warning, and I specifically said those were for 2.0. Yeah, I think there are mails crossing. I sent that different way way before I read your already said happened. So to make it clear, I now request that you do: 1) Remove all the code. Since my patches were removed from the list, here's an updated patch that applies on top of 'master' https://github.com/felipec/git/commits/up/remote/remove I'll do that, but just one thing to make sure---do you want the helper to exit with status 0? 4) Re-add the following release note: * git push via transport-helper interface (e.g. remote-hg) has been updated to allow forced ref updates in a way similar to the natively supported transports I am not sure if this one is consistent with 1), as remote-hg will no longer be with the release. -- 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: [ANNOUNCE] git reintegrate v0.3; manager of integration branches
Junio C Hamano wrote: Felipe Contreras felipe.contre...@gmail.com writes: ... Which will generate the integration instructions for you: % git reintegrate --cat base master merge jl/submodule-mv Moving a regular file in a repository with a .gitmodules file was producing a warning 'Could not find section in .gitmodules where path=filename'. merge ap/remote-hg-unquote-cquote It also has support for evil merges, so it should be perfectly usable for git.git maintenance. Yeah, it sounds like it is almost there. I think the infrastructure to maintain What's cooking could be updated to use these comments after merge instructions if I wanted to. I build two branches on top of 'master', one is called 'jch' and has a marker line somewhere that says '### match next' that is turned into an empty commit, and 'pu' that is built on top of the tip of 'jch'. The marker line is used to apply only an earlier part of the instruction stream to build 'jch' on top of 'master' on top of 'next' (i.e. base master in the above example will not be applied to hard-reset 'next' to match master) and stop there, and is meant to be a way to sanity check 'next' (which is made by repeated incremental merges on top of 'master' without rewinding) by comparing the ### match next commit between 'master' and 'jch' (which is made afresh from 'master' by taking only the necessary topics). They must match or I caught a possible mismerge on 'next'. I presume that the workflow can be mimicked by having another branch 'match-next' and building it on top of 'master', and then building 'jch' on top of it, and then building 'pu' on top of it. Then you should be able to play 'match-next' instruction on top of 'next' (provided that there is a way to tell it to replay on HEAD and ignore base and have merge instruction become a no-op when the branch has already been merged) Or have an option to specify a dynamic instruction sheet, so you can cat the instructions of 'match-next' and replace the base. However, I don't see the point of re-applying the branches for 'next' if you already know that 'next' and 'match-next' are the same. I would have two branches: 1) 'match-next' (or 'integration-next') that has the instructions to build 'next' on top of 'master', and 2) 'pu', which has the instructions to build 'pu' on top of 'next'. -- 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/RFC] t0000-*.sh: Fix the GIT_SKIP_TESTS sub-tests
Signed-off-by: Ramsay Jones ram...@ramsay1.demon.co.uk --- The test suite has been failing for me on the pu branch for a while now. I finally found a few minutes to take a look. This failure is specific to the dash shell (/bin/sh) on my system (ie it may well affect other shells, but I haven't tested them all ... :). This does not affect bash (or bash as /bin/sh aka bash --posix). The GIT_SKIP_TESTS, 13-15, all fail with verbose output similar to: $ ./t-basic.sh -i -v ... --- expect2014-05-20 20:55:54.138342361 + +++ out 2014-05-20 20:55:54.134342341 + @@ -1,5 +1,5 @@ ok 1 - passing test #1 -ok 2 # skip passing test #2 (GIT_SKIP_TESTS) +ok 2 - passing test #2 ok 3 - passing test #3 # passed all 3 test(s) 1..3 not ok 13 - GIT_SKIP_TESTS # # GIT_SKIP_TESTS='git.2' run_sub_test_lib_test git-skip-tests-basic 'GIT_SKIP_TESTS' -\EOF # for i in 1 2 3 # do # test_expect_success passing test #$i 'true' # done # test_done # EOF # check_sub_test_lib_test git-skip-tests-basic -\EOF # ok 1 - passing test #1 # ok 2 # skip passing test #2 (GIT_SKIP_TESTS) # ok 3 - passing test #3 # # passed all 3 test(s) # 1..3 # EOF # $ ... which looks like the sub-test does not see the GIT_SKIP_TESTS variable at all. Indeed, if I put the entire test in a sub-shell and replace the use of that variable on the run_sub_test_lib_test invocation with a separate explicit assignment and export, then the tests start working. (ie if I do the opposite of some other recent commits!) This patch is an RFC, because I take a different approach to the above solution, only because the diff is much smaller and easier to read! Is it a better solution? ATB, Ramsay Jones t/t-basic.sh | 15 +-- 1 file changed, 9 insertions(+), 6 deletions(-) diff --git a/t/t-basic.sh b/t/t-basic.sh index 8345c8a..373ad8f 100755 --- a/t/t-basic.sh +++ b/t/t-basic.sh @@ -296,8 +296,9 @@ test_expect_success 'test --verbose-only' ' ' test_expect_success 'GIT_SKIP_TESTS' - GIT_SKIP_TESTS='git.2' \ - run_sub_test_lib_test git-skip-tests-basic \ + GIT_SKIP_TESTS='git.2' export GIT_SKIP_TESTS + test_when_finished sane_unset GIT_SKIP_TESTS + run_sub_test_lib_test git-skip-tests-basic \ 'GIT_SKIP_TESTS' -\\EOF for i in 1 2 3 do @@ -315,8 +316,9 @@ test_expect_success 'GIT_SKIP_TESTS' test_expect_success 'GIT_SKIP_TESTS several tests' - GIT_SKIP_TESTS='git.2 git.5' \ - run_sub_test_lib_test git-skip-tests-several \ + GIT_SKIP_TESTS='git.2 git.5' export GIT_SKIP_TESTS + test_when_finished sane_unset GIT_SKIP_TESTS + run_sub_test_lib_test git-skip-tests-several \ 'GIT_SKIP_TESTS several tests' -\\EOF for i in 1 2 3 4 5 6 do @@ -337,8 +339,9 @@ test_expect_success 'GIT_SKIP_TESTS several tests' test_expect_success 'GIT_SKIP_TESTS sh pattern' - GIT_SKIP_TESTS='git.[2-5]' \ - run_sub_test_lib_test git-skip-tests-sh-pattern \ + GIT_SKIP_TESTS='git.[2-5]' export GIT_SKIP_TESTS + test_when_finished sane_unset GIT_SKIP_TESTS + run_sub_test_lib_test git-skip-tests-sh-pattern \ 'GIT_SKIP_TESTS sh pattern' -\\EOF for i in 1 2 3 4 5 6 do -- 1.9.0 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] git reintegrate v0.3; manager of integration branches
Felipe Contreras felipe.contre...@gmail.com writes: Or have an option to specify a dynamic instruction sheet, so you can cat the instructions of 'match-next' and replace the base. However, I don't see the point of re-applying the branches for 'next' if you already know that 'next' and 'match-next' are the same. The output from Reintegrate script (in 'todo') only lists the names of topic branches (or something like xx/topic~4 when the topic is not fully merged yet), and a topic branch may acquire a follow-up change (or two) on top (there is a machinery to see if xx/topic~4 is still valid in such a case and update the offset as needed). Rebuilding 'jch' on top of 'master' with the same insn sheet will then merge the updated topic branch in its entirety, and the new commits on the topic branch somehow needs to go to 'next' for the match next on 'jch' and 'next' to be in sync (in addition, updated 'master' must be merged to 'next', but that goes without saying). In other words, I already know that 'next' and match next are not the same, that they must become the same, and there needs a way to make them so. And that is done by re-running the insn sheet for 'jch' up to the match next mark, merging the topic that are not fully merged to 'next' while ignoring the ones that already are fully 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
Re: [PATCH/RFC] t0000-*.sh: Fix the GIT_SKIP_TESTS sub-tests
Ramsay Jones ram...@ramsay1.demon.co.uk writes: This patch is an RFC, because I take a different approach to the above solution, only because the diff is much smaller and easier to read! Is it a better solution? ATB, Ramsay Jones t/t-basic.sh | 15 +-- 1 file changed, 9 insertions(+), 6 deletions(-) diff --git a/t/t-basic.sh b/t/t-basic.sh index 8345c8a..373ad8f 100755 --- a/t/t-basic.sh +++ b/t/t-basic.sh @@ -296,8 +296,9 @@ test_expect_success 'test --verbose-only' ' ' test_expect_success 'GIT_SKIP_TESTS' - GIT_SKIP_TESTS='git.2' \ - run_sub_test_lib_test git-skip-tests-basic \ + GIT_SKIP_TESTS='git.2' export GIT_SKIP_TESTS + test_when_finished sane_unset GIT_SKIP_TESTS + run_sub_test_lib_test git-skip-tests-basic \ 'GIT_SKIP_TESTS' -\\EOF The original is clearly wrong if run_sub_test_lib_test is a shell function. I thought we hunted those down and killed them already, but apparently we didn't. I think exporting the variable and then clearing it in test-when-finished is fine, and doing the export and run in a subshell so that you do not have to clear is also fine. for i in 1 2 3 do @@ -315,8 +316,9 @@ test_expect_success 'GIT_SKIP_TESTS' test_expect_success 'GIT_SKIP_TESTS several tests' - GIT_SKIP_TESTS='git.2 git.5' \ - run_sub_test_lib_test git-skip-tests-several \ + GIT_SKIP_TESTS='git.2 git.5' export GIT_SKIP_TESTS + test_when_finished sane_unset GIT_SKIP_TESTS + run_sub_test_lib_test git-skip-tests-several \ 'GIT_SKIP_TESTS several tests' -\\EOF for i in 1 2 3 4 5 6 do @@ -337,8 +339,9 @@ test_expect_success 'GIT_SKIP_TESTS several tests' test_expect_success 'GIT_SKIP_TESTS sh pattern' - GIT_SKIP_TESTS='git.[2-5]' \ - run_sub_test_lib_test git-skip-tests-sh-pattern \ + GIT_SKIP_TESTS='git.[2-5]' export GIT_SKIP_TESTS + test_when_finished sane_unset GIT_SKIP_TESTS + run_sub_test_lib_test git-skip-tests-sh-pattern \ 'GIT_SKIP_TESTS sh pattern' -\\EOF for i in 1 2 3 4 5 6 do -- 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] remote-helpers: point at their upstream repositories
Junio C Hamano wrote: Felipe Contreras felipe.contre...@gmail.com writes: Let's try this in a different way, as I sense there is a misunderstanding somewhere about your wish. ... No, I already said I do not want the code removed from v2.0, that's why I sent patches that simply added a warning, and I specifically said those were for 2.0. Yeah, I think there are mails crossing. I sent that different way way before I read your already said happened. So to make it clear, I now request that you do: 1) Remove all the code. Since my patches were removed from the list, here's an updated patch that applies on top of 'master' https://github.com/felipec/git/commits/up/remote/remove I'll do that, but just one thing to make sure---do you want the helper to exit with status 0? It doesn't matter; if the remote helper doesn't respond to the commands transport-helper exits with 128. 4) Re-add the following release note: * git push via transport-helper interface (e.g. remote-hg) has been updated to allow forced ref updates in a way similar to the natively supported transports I am not sure if this one is consistent with 1), as remote-hg will no longer be with the release. Remove '(e.g. remote-hg)', the rest still applies. -- 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