Re: [PATCH v2] format-patch --signature-file file

[Jeff King]

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

[Alexey Shumkin]

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

[Jeff King]

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

[Matthieu Moy]

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

[Eric Sunshine]

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

[Matthieu Moy]

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

[Jeremiah Mahler]

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

[Jeremiah Mahler]

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

[Jeff King]

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

[Erik Faye-Lund]

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

[Jens Lindström]

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

[Jens Lindström]

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 ||

[Elia Pinto]

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 ||

[Elia Pinto]

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 ||

[Elia Pinto]

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 ||

[Elia Pinto]

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

[Elia Pinto]

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 ||

[Elia Pinto]

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 ||

[Elia Pinto]

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 ||

[Elia Pinto]

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 ||

[Elia Pinto]

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 ||

[Elia Pinto]

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 ||

[Elia Pinto]

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 ||

[Elia Pinto]

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 ||

[Elia Pinto]

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 ||

[Elia Pinto]

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 ||

[Elia Pinto]

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 ||

[Elia Pinto]

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 ||

[Elia Pinto]

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 ||

[Elia Pinto]

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 ||

[Elia Pinto]

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

[Ramsay Jones]

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 ||

[Matthieu Moy]

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

[Matthieu Moy]

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

[Alexey Shumkin]

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

[Alexey Shumkin]

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

[Michael S. Tsirkin]

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 ||

[Johannes Sixt]

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

[Alexey Shumkin]

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

[Michael Haggerty]

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

[Ramsay Jones]

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

[Ramsay Jones]

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

[Junio C Hamano]

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

[Junio C Hamano]

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

[Johan Herland]

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

[Stewart, Louis (IS)]

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

[Alexey Shumkin]

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

[Arup Rakshit]

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

[Ramsay Jones]

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

[Stewart, Louis (IS)]

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

[Marius Storm-Olsen]

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

[Arup Rakshit]

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

[Jason Pyeron]

 -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

[Marius Storm-Olsen]

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

[Marius Storm-Olsen]

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

[Junio C Hamano]

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

[Junio C Hamano]

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

[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.


--
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

[Junio C Hamano]

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

[Junio C Hamano]

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

[Junio C Hamano]

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

[Junio C Hamano]

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

[Junio C Hamano]

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 ||

[Junio C Hamano]

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

[Junio C Hamano]

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

[Stewart, Louis (IS)]

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

[Arup Rakshit]

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

[Jonathan Nieder]

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

[Junio C Hamano]

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

[Jeff King]

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

[Thomas Braun]

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

[Marius Storm-Olsen]

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

[Junio C Hamano]

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

[Junio C Hamano]

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

[Arup Rakshit]

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

[Marius Storm-Olsen]

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

[Junio C Hamano]

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]

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

[Junio C Hamano]

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

[Konstantin Khomoutov]

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

[Karsten Blees]

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

[Karsten Blees]

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

[Karsten Blees]

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

[Karsten Blees]

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

[Stepan Kasal]

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

[Junio C Hamano]

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

[Junio C Hamano]

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

[Jonathan Nieder]

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]

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

[Ronnie Sahlberg]

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

[Jonathan Nieder]

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

[Felipe Contreras]

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

[Ronnie Sahlberg]

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

[Felipe Contreras]

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

[Junio C Hamano]

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

[Felipe Contreras]

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

[Ramsay Jones]

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

[Junio C Hamano]

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

[Junio C Hamano]

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

[Felipe Contreras]

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