Re: [PATCH v5] mru: Replace mru.[ch] with list.h implementation

[Eric Wong]

Gargi Sharma  wrote:
>  7 files changed, 15 insertions(+), 86 deletions(-)

Thanks! I like the code reduction and increased use of list.h

Were you able to finish running the test suite?  I wasn't :<

> -void mru_clear(struct mru *head)
> -{
> - struct list_head *pos;
> - struct list_head *tmp;
> -
> - list_for_each_safe(pos, tmp, >list) {
> - free(list_entry(pos, struct mru, list));
> - }
> - INIT_LIST_HEAD(>list);
> -}

OK, the free() calls are no longer necessary...



> --- a/packfile.c
> +++ b/packfile.c
> @@ -859,9 +859,8 @@ static void prepare_packed_git_mru(void)
>  {
>   struct packed_git *p;
>  
> - mru_clear(_git_mru);

But the removed mru_clear needs to be replaced with:

+   INIT_LIST_HEAD(_git_mru);

Otherwise, t3050 never finishes for me.

>   for (p = packed_git; p; p = p->next)
> - mru_append(_git_mru, p);
> + list_add_tail(>mru, _git_mru);
>  }

Everything else looks good to me, I'm still waiting for the test
suite to run but I don't expect further problems.

Re: [PATCH v3 1/3] read-cache: fix reading the shared index for other repos

[Junio C Hamano]

Thomas Gummerer  writes:

> On 01/19, Junio C Hamano wrote:
>> Thomas Gummerer  writes:
>> 
>> > read_cache_from() defaults to using the gitdir of the_repository.  As it
>> > is mostly a convenience macro, having to pass get_git_dir() for every
>> > call seems overkill, and if necessary users can have more control by
>> > using read_index_from().
>> 
>> This was a bit painful change, given that some changes in flight do
>> add new callsites to read_index_from() and they got the function
>> changed under their feet.
>
> Sorry about that.  Is there any way to make such a change less painful
> in the future?

One way is to do for read_index_from() what you did for the existing
users of read_cache_from().  Introduce a _new_ helper that will not
be known for any existing topics in flight, and use that to make the
existing API a thin wrapper around it.

I _think_ I got it right with evil merge, so unless this fix needs
to be delayed for extended period of time for whatever reason while
any more new callers of the function appears (which is unlikely), we
should be OK ;-)

Thanks.

[ANNOUNCE] Git v2.16.1

[Junio C Hamano]

The latest maintenance release Git v2.16.1 is now available at
the usual places.

This is solely to fix a brown-paper bag bug that broke "git clone"
on case insensitive filesystems of certain projects.

The tarballs are found at:

https://www.kernel.org/pub/software/scm/git/

The following public repositories all have a copy of the 'v2.16.1'
tag and the 'maint' branch that the tag points at:

  url = https://kernel.googlesource.com/pub/scm/git/git
  url = git://repo.or.cz/alt-git.git
  url = https://github.com/gitster/git



Git v2.16.1 Release Notes
=

Fixes since v2.16
-

 * "git clone" segfaulted when cloning a project that happens to
   track two paths that differ only in case on a case insensitive
   filesystem.

Does not contain any other documentation updates or code clean-ups.



Changes since v2.16.0 are as follows:

Eric Sunshine (1):
  t5601-clone: test case-conflicting files on case-insensitive filesystem

Junio C Hamano (1):
  Git 2.16.1

brian m. carlson (1):
  repository: pre-initialize hash algo pointer

Re: git svn clone - Malformed network data: The XML response contains invalid XML: Malformed XML: no element found at /usr/share/perl5/vendor_perl/5.26/Git/SVN/Ra.pm line 312

[Eric Wong]

Jason Pyeron  wrote:
> 
> I am asuming that this is an issue caused by codeplex's svn
> from tfs implementation. Does anyone here have any insight?

Seems like it, even using svn(1) fails (see below)

> r27599 = 9e769d8327767a155d7b96b7cc28579cf0ed4c93 (refs/remotes/git-svn)
> Malformed network data: The XML response contains invalid XML: Malformed XML: 
> no element found at /usr/share/perl5/vendor_perl/5.26/Git/SVN/Ra.pm line 312.

OK, so lets find out what the next commit is after r27599:

  svn log -v -r 27599:HEAD https://smtp4dev.svn.codeplex.com/svn

  # which tells me r27864

  svn diff -r 27599:27864 https://smtp4dev.svn.codeplex.com/svn
  # which tells me:
  svn: E130003: The XML response contains invalid XML

strace only shows encrypted data, so maybe there's a flag or
debug option you can enable in SVN itself to see what was in the
bad XML or maybe contact the admin to see if it can be fixed.

[PATCH] Fix comma splices

[felipe]

>From b18bd6babc2d6a6f79177acfa2416bb5bf2b153f Mon Sep 17 00:00:00 2001
From: Felipe Gasper 
Date: Sun, 21 Jan 2018 23:01:47 -0500
Subject: [PATCH] Fix comma splices in remote.c

Signed-off-by: Felipe Gasper 
---
 remote.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/remote.c b/remote.c
index 4e93753e1..e8ba808c5 100644
--- a/remote.c
+++ b/remote.c
@@ -2123,9 +2123,9 @@ int format_tracking_info(struct branch *branch, struct 
strbuf *sb)
_("  (use \"git push\" to publish your local 
commits)\n"));
} else if (!ours) {
strbuf_addf(sb,
-   Q_("Your branch is behind '%s' by %d commit, "
+   Q_("Your branch is behind '%s' by %d commit "
   "and can be fast-forwarded.\n",
-  "Your branch is behind '%s' by %d commits, "
+  "Your branch is behind '%s' by %d commits "
   "and can be fast-forwarded.\n",
   theirs),
base, theirs);
@@ -2134,11 +2134,11 @@ int format_tracking_info(struct branch *branch, struct 
strbuf *sb)
_("  (use \"git pull\" to update your local 
branch)\n"));
} else {
strbuf_addf(sb,
-   Q_("Your branch and '%s' have diverged,\n"
-  "and have %d and %d different commit each, "
+   Q_("Your branch and '%s' have diverged.\n"
+  "They have %d and %d different commit each, "
   "respectively.\n",
-  "Your branch and '%s' have diverged,\n"
-  "and have %d and %d different commits each, "
+  "Your branch and '%s' have diverged.\n"
+  "They have %d and %d different commits each, "
   "respectively.\n",
   ours + theirs),
base, ours, theirs);
-- 
2.15.1

Re: cygwin git and golang: how @{u} is handled

[John Cheng]

Hi Phillip,

Thanks for pointing me to the github issue. I've added my comments to
it. For my particular issue, it was resolved by setting
"CYGWIN=noglob" as an environment variable. Hopefully it resolves
Robert's problem as well.



On Sun, Jan 21, 2018 at 3:43 PM, Philip Oakley  wrote:
> From: "John Cheng" 
>
>> I am experiencing a strange behavior and I'm not certain if it is a
>> problem with golang or the cygwin version of git.
>>
>> Steps to reproduce:
>> Use golang's os/exec library to execute
>> exec.Command(os.Args[1],"log","@{u}") // where os.Args[1] is either
>> cygwin git or Windows git
>>
>> Expected result:
>> commit 09357db3a29909c3498143b0d06989e00f5e2442
>> Author: John Cheng 
>> Date:   Sun Jan 14 10:57:01 2018 -0800
>> ...
>>
>> Actual result:
>> Suppose that cygwin git is specified, the result becomes:
>> exit status 128 fatal: ambiguous argument '@u': unknown revision or
>> path not in the working tree.
>>
>> Version:
>> git version 2.15.1.windows.2
>> git version 2.15.1
>>
>> I'm not certain if this is a git problem, as I could not reproduce
>> this problem using python to script cygwin git.
>>
>> A list of scenarios I've tested are
>> 1. golang + cygwin git = "exit code 128"
>> 2. golang + windows git = "exit code 0"
>> 3. python + cygwin git = "exit code 0"
>> 4. python + windows git = "exit code 0"
>>
>> I've tried to write a simple program to echo the command line
>> parameters passed by go into the process it executes - and it appears
>> that go itself does not change "@{u}" into "@u". I'm a bit stuck at
>> point to figure out which may be the cause: golang or git. I figured
>> I'd start here.
>>
> There is a similar problem a user is experiencing on Git-for-Windows, that
> we/the user haven't got to the bottom of, but it appears to have a similar
> form where the braces appear to be is some form parsed twice (though thats
> still a guess / hypothesis).
>
> "Aliases in git are stripping curly-brackets (#1220)"
> https://github.com/git-for-windows/git/issues/1220#issuecomment-340341336
>
>
>
> Philip
>



-- 
---
John L Cheng

[PATCH] sequencer: mark a file local symbol as static

[Ramsay Jones]

Signed-off-by: Ramsay Jones 
---

Hi Phillip,

If you need to re-roll your 'pw/sequencer-in-process-commit' branch, could
you please squash this into the relevant patch (commit da96adcf5a,
"sequencer: run 'prepare-commit-msg' hook", 2018-01-19).

Thanks.

ATB,
Ramsay Jones

 sequencer.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sequencer.c b/sequencer.c
index 79579ba11..5bfdc4044 100644
--- a/sequencer.c
+++ b/sequencer.c
@@ -893,7 +893,7 @@ void commit_post_rewrite(const struct commit *old_head,
run_rewrite_hook(_head->object.oid, new_head);
 }
 
-int run_prepare_commit_msg_hook(struct strbuf *msg, const char *commit)
+static int run_prepare_commit_msg_hook(struct strbuf *msg, const char *commit)
 {
struct argv_array hook_env = ARGV_ARRAY_INIT;
int ret;
-- 
2.16.0

Reply

[Robert Worton]

-- 
I was wondering if you got my previous Email to you regarding my proposal?

best regards
Email:robertwort...@outlook.com

Re: cygwin git and golang: how @{u} is handled

[Philip Oakley]

From: "John Cheng" 

I am experiencing a strange behavior and I'm not certain if it is a
problem with golang or the cygwin version of git.

Steps to reproduce:
Use golang's os/exec library to execute
exec.Command(os.Args[1],"log","@{u}") // where os.Args[1] is either
cygwin git or Windows git

Expected result:
commit 09357db3a29909c3498143b0d06989e00f5e2442
Author: John Cheng 
Date:   Sun Jan 14 10:57:01 2018 -0800
...

Actual result:
Suppose that cygwin git is specified, the result becomes:
exit status 128 fatal: ambiguous argument '@u': unknown revision or
path not in the working tree.

Version:
git version 2.15.1.windows.2
git version 2.15.1

I'm not certain if this is a git problem, as I could not reproduce
this problem using python to script cygwin git.

A list of scenarios I've tested are
1. golang + cygwin git = "exit code 128"
2. golang + windows git = "exit code 0"
3. python + cygwin git = "exit code 0"
4. python + windows git = "exit code 0"

I've tried to write a simple program to echo the command line
parameters passed by go into the process it executes - and it appears
that go itself does not change "@{u}" into "@u". I'm a bit stuck at
point to figure out which may be the cause: golang or git. I figured
I'd start here.

There is a similar problem a user is experiencing on Git-for-Windows, that 
we/the user haven't got to the bottom of, but it appears to have a similar 
form where the braces appear to be is some form parsed twice (though thats 
still a guess / hypothesis).


"Aliases in git are stripping curly-brackets (#1220)" 
https://github.com/git-for-windows/git/issues/1220#issuecomment-340341336




Philip

[PATCH v4 2/4] Define config options required for the HPE NonStop NSX and NSE platforms

[randall . s . becker]

From: "Randall S. Becker" 

Upgrade old options in config.mak.uname to currently supported
NonStop operating system versions (J06.21 and L17.xx).

Signed-off-by: Randall S. Becker 
---
 config.mak.uname | 29 +
 1 file changed, 21 insertions(+), 8 deletions(-)

diff --git a/config.mak.uname b/config.mak.uname
index 685a80d13..d9f8d57e3 100644
--- a/config.mak.uname
+++ b/config.mak.uname
@@ -428,27 +428,37 @@ ifeq ($(uname_S),NONSTOP_KERNEL)
# INLINE='' would just replace one set of warnings with another and
# still not compile in c89 mode, due to non-const array initializations.
CC = cc -c99
+   # Build down-rev compatible objects that don't use our new getopt_long.
+   ifeq ($(uname_R).$(uname_V),J06.21)
+   CC += -WRVU=J06.20
+   endif
+   ifeq ($(uname_R).$(uname_V),L17.02)
+   CC += -WRVU=L16.05
+   endif
# Disable all optimization, seems to result in bad code, with -O or -O2
# or even -O1 (default), /usr/local/libexec/git-core/git-pack-objects
# abends on "git push". Needs more investigation.
-   CFLAGS = -g -O0
+   CFLAGS = -g -O0 -Winline
# We'd want it to be here.
prefix = /usr/local
# Our's are in ${prefix}/bin (perl might also be in /usr/bin/perl).
-   PERL_PATH = ${prefix}/bin/perl
-   PYTHON_PATH = ${prefix}/bin/python
-
+   PERL_PATH = /usr/bin/perl
+   PYTHON_PATH = /usr/bin/python
+   RM = /bin/rm -f
# As detected by './configure'.
# Missdetected, hence commented out, see below.
#NO_CURL = YesPlease
# Added manually, see above.
NEEDS_SSL_WITH_CURL = YesPlease
+   NEEDS_CRYPTO_WITH_SSL = YesPlease
+   HAVE_DEV_TTY = YesPlease
HAVE_LIBCHARSET_H = YesPlease
HAVE_STRINGS_H = YesPlease
NEEDS_LIBICONV = YesPlease
NEEDS_LIBINTL_BEFORE_LIBICONV = YesPlease
NO_SYS_SELECT_H = UnfortunatelyYes
NO_D_TYPE_IN_DIRENT = YesPlease
+   NO_GETTEXT = YesPlease
NO_HSTRERROR = YesPlease
NO_STRCASESTR = YesPlease
NO_MEMMEM = YesPlease
@@ -458,8 +468,13 @@ ifeq ($(uname_S),NONSTOP_KERNEL)
NO_MKDTEMP = YesPlease
# Currently libiconv-1.9.1.
OLD_ICONV = UnfortunatelyYes
-   NO_REGEX = YesPlease
+   NO_REGEX=NeedsStartEnd
NO_PTHREADS = UnfortunatelyYes
+   ifdef NO_PTHREADS
+   else # WIP, use Posix User Threads
+   PTHREAD_CFLAGS = -D_PUT_MODEL_ -I/usr/include
+   PTHREAD_LIBS = -lput
+   endif
 
# Not detected (nor checked for) by './configure'.
# We don't have SA_RESTART on NonStop, unfortunalety.
@@ -477,9 +492,7 @@ ifeq ($(uname_S),NONSTOP_KERNEL)
# RFE 10-120912-4693 submitted to HP NonStop development.
NO_SETITIMER = UnfortunatelyYes
SANE_TOOL_PATH = /usr/coreutils/bin:/usr/local/bin
-   SHELL_PATH = /usr/local/bin/bash
-   # as of H06.25/J06.14, we might better use this
-   #SHELL_PATH = /usr/coreutils/bin/bash
+   SHELL_PATH = /usr/coreutils/bin/bash
 endif
 ifneq (,$(findstring MINGW,$(uname_S)))
pathsep = ;
-- 
2.16.0.31.gf1a482c

[PATCH v4 3/4] Bring NonStop platform definitions up to date in git-compat-util.h

[randall . s . becker]

From: "Randall S. Becker" 

Add correct FLOSS (NonStop platform emulation) definitions into
git-compat-util.h to allow correct emulation of non-platform
behaviour. Also added NSIG definition that is not explicitly
supplied in signal.h on platform.

Signed-off-by: Randall S. Becker 
---
 git-compat-util.h | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/git-compat-util.h b/git-compat-util.h
index 68b2ad531..fb3ef0dcf 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -378,6 +378,21 @@ static inline char *git_find_last_dir_sep(const char *path)
 #define find_last_dir_sep git_find_last_dir_sep
 #endif
 
+#ifdef __TANDEM
+#if !defined(_THREAD_SUPPORT_FUNCTIONS) && !defined(_PUT_MODEL_)
+/* #include  */
+/* #include  */
+#endif
+#include 
+#include 
+#if ! defined NSIG
+/* NonStop NSE and NSX do not provide NSIG. SIGGUARDIAN(99) is the highest
+   known, by detective work using kill -l as a list is all signals
+   instead of signal.h where it should be. */
+# define NSIG 100
+#endif
+#endif
+
 #if defined(__HP_cc) && (__HP_cc >= 61000)
 #define NORETURN __attribute__((noreturn))
 #define NORETURN_PTR
-- 
2.16.0.31.gf1a482c

[PATCH v4 0/4] Force pipes to flush immediately on NonStop platform

[randall . s . becker]

From: "Randall S. Becker" 

Call setbuf(stream,NULL) to force pipe flushes not enabled by
default on the NonStop platform in wrapper.c. This may be extended
in future to a configure option.

Signed-off-by: Randall S. Becker 
---
 wrapper.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/wrapper.c b/wrapper.c
index d20356a77..5b05a9162 100644
--- a/wrapper.c
+++ b/wrapper.c
@@ -403,6 +403,9 @@ FILE *xfdopen(int fd, const char *mode)
FILE *stream = fdopen(fd, mode);
if (stream == NULL)
die_errno("Out of memory? fdopen failed");
+#ifdef __TANDEM
+   setbuf(stream,NULL);
+#endif
return stream;
 }
 
-- 
2.16.0.31.gf1a482c

[PATCH v4 4/4] Add intptr_t and uintptr_t to regcomp.c for NonStop platform.

[randall . s . becker]

From: "Randall S. Becker" 

Fix missing intptr_t on NonStop in compat/regex/regcomp.c wrapped
using the __TANDEM guard define. This is done because
git-compat-util.h cannot be cleanly included into this file
without additional compile errors.

Signed-off-by: Randall S. Becker 
---
 compat/regex/regcomp.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/compat/regex/regcomp.c b/compat/regex/regcomp.c
index 51cd60baa..8bb4c966d 100644
--- a/compat/regex/regcomp.c
+++ b/compat/regex/regcomp.c
@@ -17,6 +17,14 @@
License along with the GNU C Library; if not, see
.  */
 
+#if defined __TANDEM
+/* This is currently duplicated from git-compat-utils.h */
+#ifdef NO_INTPTR_T
+typedef long intptr_t;
+typedef unsigned long uintptr_t;
+#endif
+#endif
+
 static reg_errcode_t re_compile_internal (regex_t *preg, const char * pattern,
  size_t length, reg_syntax_t syntax);
 static void re_compile_fastmap_iter (regex_t *bufp,
-- 
2.16.0.31.gf1a482c

[PATCH v4 1/4] Add tar extract install options override in installation processing.

[randall . s . becker]

From: "Randall S. Becker" 

Introduced TAR_EXTRACT_OPTIONS as a configuration option to change
the options of tar processing during extract. The default value is "o"
which synthesizes xof, by default.

Signed-off-by: Randall S. Becker 
---
 Makefile | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index 1a9b23b67..78ee431b7 100644
--- a/Makefile
+++ b/Makefile
@@ -429,6 +429,10 @@ all::
 # running the test scripts (e.g., bash has better support for "set -x"
 # tracing).
 #
+# Define TAR_EXTRACT_OPTIONS if you want to change the default behaviour
+# from xvf to something else during installation. The option only includes
+# "o" as xf are required.
+#
 # When cross-compiling, define HOST_CPU as the canonical name of the CPU on
 # which the built Git will run (for instance "x86_64").
 
@@ -452,6 +456,7 @@ LDFLAGS =
 ALL_CFLAGS = $(CPPFLAGS) $(CFLAGS)
 ALL_LDFLAGS = $(LDFLAGS)
 STRIP ?= strip
+TAR_EXTRACT_OPTIONS = o
 
 # Create as necessary, replace existing, make ranlib unneeded.
 ARFLAGS = rcs
@@ -2569,7 +2574,7 @@ install: all
 ifndef NO_GETTEXT
$(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(localedir_SQ)'
(cd po/build/locale && $(TAR) cf - .) | \
-   (cd '$(DESTDIR_SQ)$(localedir_SQ)' && umask 022 && $(TAR) xof -)
+   (cd '$(DESTDIR_SQ)$(localedir_SQ)' && umask 022 && $(TAR) 
x$(TAR_EXTRACT_OPTIONS)f -)
 endif
 ifndef NO_PERL
$(MAKE) -C perl prefix='$(prefix_SQ)' DESTDIR='$(DESTDIR_SQ)' install
-- 
2.16.0.31.gf1a482c

[PATCH v5] mru: Replace mru.[ch] with list.h implementation

[Gargi Sharma]

Replace the custom calls to mru.[ch] with calls to list.h. This patch is
the final step in removing the mru API completely and inlining the logic.
This patch leads to significant code reduction and the mru API hence, is
not a useful abstraction anymore.

Signed-off-by: Gargi Sharma 
---
The commit has been built on top of ot/mru-on-list branch.

Changes in v5:
- Remove list_move_to_front() as it is redundant.
Changes in v4:
- Fixing minor style issues.
Changes in v3:
- Make the commit message more descriptive.
- Remove braces after if statement.
Changes in v2:
- Add a move to front function to the list API.
- Remove memory leak.
- Remove redundant remove operations on the list.

A future improvement could be removing/changing the
type of nect pointer or dropping it entirely. See discussion
here:
https://public-inbox.org/git/caoci2dgyqr4jff5oby2buyhnjeaapqkf8tbojn2w0b18eo+...@mail.gmail.com/
---
 Makefile   |  1 -
 builtin/pack-objects.c |  9 -
 cache.h|  8 
 mru.c  | 27 ---
 mru.h  | 40 
 packfile.c | 15 +++
 sha1_file.c|  1 -
 7 files changed, 15 insertions(+), 86 deletions(-)
 delete mode 100644 mru.c
 delete mode 100644 mru.h

diff --git a/Makefile b/Makefile
index ed4ca43..4a79ec5 100644
--- a/Makefile
+++ b/Makefile
@@ -814,7 +814,6 @@ LIB_OBJS += merge.o
 LIB_OBJS += merge-blobs.o
 LIB_OBJS += merge-recursive.o
 LIB_OBJS += mergesort.o
-LIB_OBJS += mru.o
 LIB_OBJS += name-hash.o
 LIB_OBJS += notes.o
 LIB_OBJS += notes-cache.o
diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c
index ba81234..6a0b8e8 100644
--- a/builtin/pack-objects.c
+++ b/builtin/pack-objects.c
@@ -24,7 +24,7 @@
 #include "reachable.h"
 #include "sha1-array.h"
 #include "argv-array.h"
-#include "mru.h"
+#include "list.h"
 #include "packfile.h"
 
 static const char *pack_usage[] = {
@@ -1012,9 +1012,8 @@ static int want_object_in_pack(const unsigned char *sha1,
return want;
}
 
-   list_for_each(pos, _git_mru.list) {
-   struct mru *entry = list_entry(pos, struct mru, list);
-   struct packed_git *p = entry->item;
+   list_for_each(pos, _git_mru) {
+   struct packed_git *p = list_entry(pos, struct packed_git, mru);
off_t offset;
 
if (p == *found_pack)
@@ -1031,7 +1030,7 @@ static int want_object_in_pack(const unsigned char *sha1,
}
want = want_found_object(exclude, p);
if (!exclude && want > 0)
-   mru_mark(_git_mru, entry);
+   list_move(>mru, _git_mru);
if (want != -1)
return want;
}
diff --git a/cache.h b/cache.h
index 49b083e..cc09e3b 100644
--- a/cache.h
+++ b/cache.h
@@ -4,7 +4,7 @@
 #include "git-compat-util.h"
 #include "strbuf.h"
 #include "hashmap.h"
-#include "mru.h"
+#include "list.h"
 #include "advice.h"
 #include "gettext.h"
 #include "convert.h"
@@ -1566,6 +1566,7 @@ struct pack_window {
 
 extern struct packed_git {
struct packed_git *next;
+   struct list_head mru;
struct pack_window *windows;
off_t pack_size;
const void *index_data;
@@ -1587,10 +1588,9 @@ extern struct packed_git {
 } *packed_git;
 
 /*
- * A most-recently-used ordered version of the packed_git list, which can
- * be iterated instead of packed_git (and marked via mru_mark).
+ * A most-recently-used ordered version of the packed_git list.
  */
-extern struct mru packed_git_mru;
+extern struct list_head packed_git_mru;
 
 struct pack_entry {
off_t offset;
diff --git a/mru.c b/mru.c
deleted file mode 100644
index 8f3f34c..000
--- a/mru.c
+++ /dev/null
@@ -1,27 +0,0 @@
-#include "cache.h"
-#include "mru.h"
-
-void mru_append(struct mru *head, void *item)
-{
-   struct mru *cur = xmalloc(sizeof(*cur));
-   cur->item = item;
-   list_add_tail(>list, >list);
-}
-
-void mru_mark(struct mru *head, struct mru *entry)
-{
-   /* To mark means to put at the front of the list. */
-   list_del(>list);
-   list_add(>list, >list);
-}
-
-void mru_clear(struct mru *head)
-{
-   struct list_head *pos;
-   struct list_head *tmp;
-
-   list_for_each_safe(pos, tmp, >list) {
-   free(list_entry(pos, struct mru, list));
-   }
-   INIT_LIST_HEAD(>list);
-}
diff --git a/mru.h b/mru.h
deleted file mode 100644
index 80a589e..000
--- a/mru.h
+++ /dev/null
@@ -1,40 +0,0 @@
-#ifndef MRU_H
-#define MRU_H
-
-#include "list.h"
-
-/**
- * A simple most-recently-used cache, backed by a doubly-linked list.
- *
- * Usage is roughly:
- *
- *   // Create a list.  Zero-initialization is required.
- *   static struct mru 

Re: [PATCH v3] mru: Replace mru.[ch] with list.h implementation

[Gargi Sharma]

On Sun, Jan 21, 2018 at 4:38 AM, René Scharfe  wrote:
>
> Am 20.01.2018 um 23:24 schrieb Gargi Sharma:
> > On Sat, Jan 20, 2018 at 1:02 AM, Eric Wong  wrote:
> >> Gargi Sharma  wrote:
> >>> --- a/list.h
> >>> +++ b/list.h
> >>> @@ -93,6 +93,13 @@ static inline void list_move(struct list_head *elem, 
> >>> struct list_head *head)
> >>>list_add(elem, head);
> >>>   }
> >>>
> >>> +/* Move to the front of the list. */
> >>> +static inline void list_move_to_front(struct list_head *elem, struct 
> >>> list_head *head)
> >>> +{
> >>> + list_del(elem);
> >>> + list_add(elem, head);
> >>> +}
> >>> +
> >>
> >> Since we already have list_move and it does the same thing,
> >> I don't think we need a new function, here.
> >>
> >> Hackers coming from other projects (glibc/urcu/Linux kernel)
> >> might appreciate having fewer differences from what they're used
> >> to.
> >
> > I think the idea behind this function was that it is already being used in 
> > two
> > places in the code and might be used in other places in the future. I agree
> > with your stance, but a list_move_to_front is pretty self explanatory and 
> > not
> > too different, so it should be alright.
>
> Not sure I understand the point about the function being already used as
> an argument for adding it, but if there is already one which has the
> exact sane behavior (list_move() in this case) then that should be used
> instead of adding a duplicate.

Thanks for bringing this to my attention, René. I can use list_move()
to do the exact
same thing as list_move_to_front(). Will send another version.

Thanks,
Gargi
>
> René
>

Re: [PATCH] enable core.fsyncObjectFiles by default

[Chris Mason]

On 01/18/2018 11:27 AM, Christoph Hellwig wrote:

[adding Chris to the Cc list - this is about the awful ext3 data=ordered
behavior of syncing the whole file system data and metadata on each
fsync]

On Wed, Jan 17, 2018 at 03:57:53PM -0800, Linus Torvalds wrote:

On Wed, Jan 17, 2018 at 3:52 PM, Theodore Ts'o  wrote:


Well, let's be fair; this is something *ext3* got wrong, and it was
the default file system back them.


I'm pretty sure reiserfs and btrfs did too..


I'm pretty sure btrfs never did, and reiserfs at least looks like
it currently doesn't but I'd have to dig into history to check if
it ever did.



Christoph has this right, btrfs only fsyncs the one file that you've 
asked for, and unrelated data/metadata won't be included.


We've seen big fsync stalls on ext4 caused by data=ordered, so it's 
still possible to trigger on ext4, but much better than ext3.


I do share Ted's concern about the perf impact of the fsyncs on tons of 
loose files, but the defaults should be safety first.


-chris

Proposal

[Ms Melisa Mehmet]

-- 
Hello 

i want to invest in your region i have some funds under my management
please let me know if we can work together on this investment plan.

Regards 
Melisa Mehmet

Re: [PATCH] t: add clone test for files differing only in case

[brian m. carlson]

On Sun, Jan 21, 2018 at 03:07:28AM -0500, Eric Sunshine wrote:
> On Sun, Jan 21, 2018 at 02:46:15AM -0500, Eric Sunshine wrote:
> > Yep. In pretty much any other test script, this would work (it was
> > developed in a stand-alone script), but t5601 (which nukes .git as its
> > first action) isn't the most friendly place.
> 
> Here's a re-roll which fixes that problem (and has a slightly
> re-written commit message.

Yes, this looks good.  I did indeed intend to forge your From line on
the message and actually test that it was fixed, but only tested it on
the vfat partition, not my ext4 partition, where, of course, I got
distracted by the various other failures.  Sigh.

Thanks for fixing this up.
-- 
brian m. carlson / brian with sandals: Houston, Texas, US
https://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: https://keybase.io/bk2204


signature.asc
Description: PGP signature

Proposal

[Ms Melisa Mehmet]

-- 
Hello 

i want to invest in your region i have some funds under my management
please let me know if we can work together on this investment plan.

Regards 
Melisa Mehmet

Re: cygwin git and golang: how @{u} is handled

[Ævar Arnfjörð Bjarmason]

On Sun, Jan 21 2018, John Cheng jotted:

> Actual result:
> Suppose that cygwin git is specified, the result becomes:
> exit status 128 fatal: ambiguous argument '@u': unknown revision or
> path not in the working tree.

Given that:

$ git log @{x}
fatal: ambiguous argument '@{x}': unknown revision or path not in the 
working tree.

Spews the output back at you as @{x} not @x the problem must be in
whatever is passing the argument to git, whether that's go or some other
wrapper.

Try putting a "git" first in your $PATH which is nothing but:

#!/bin/sh
echo "args: $@"
exit 1

And seeing what you get.

Re: [PATCH] t: add clone test for files differing only in case

[Eric Sunshine]

On Sun, Jan 21, 2018 at 6:50 AM, Duy Nguyen  wrote:
> On Sun, Jan 21, 2018 at 3:33 AM, brian m. carlson
>> +test_expect_success 'clone on case-insensitive fs' '
>
> We have CASE_INSENSITIVE_FS prereq. Should we use it here? I know it
> does not harm running this test on case-sensitive filesystem, but the
> prereq could be useful for grepping.

I'd rather not hide it behind the CASE_INSENSITIVE_FS[1] prerequisite
since the test potentially could catch some sort of future regression
even on case-sensitive filesystems.

[1]: Todd Zullinger suggested the same:
https://public-inbox.org/git/CAPig+cSRN1zHc=zso1y_aq_eo+sbsd0cq5iz9hyz3ruk_e-...@mail.gmail.com/

cygwin git and golang: how @{u} is handled

[John Cheng]

I am experiencing a strange behavior and I'm not certain if it is a
problem with golang or the cygwin version of git.

Steps to reproduce:
Use golang's os/exec library to execute
exec.Command(os.Args[1],"log","@{u}") // where os.Args[1] is either
cygwin git or Windows git

Expected result:
commit 09357db3a29909c3498143b0d06989e00f5e2442
Author: John Cheng 
Date:   Sun Jan 14 10:57:01 2018 -0800
...

Actual result:
Suppose that cygwin git is specified, the result becomes:
exit status 128 fatal: ambiguous argument '@u': unknown revision or
path not in the working tree.

Version:
git version 2.15.1.windows.2
git version 2.15.1

I'm not certain if this is a git problem, as I could not reproduce
this problem using python to script cygwin git.

A list of scenarios I've tested are
1. golang + cygwin git = "exit code 128"
2. golang + windows git = "exit code 0"
3. python + cygwin git = "exit code 0"
4. python + windows git = "exit code 0"

I've tried to write a simple program to echo the command line
parameters passed by go into the process it executes - and it appears
that go itself does not change "@{u}" into "@u". I'm a bit stuck at
point to figure out which may be the cause: golang or git. I figured
I'd start here.





-- 
---
John L Cheng

Re: [PATCH 00/11] Some fixes and bunch of object_id conversions

[Patryk Obara]

On 20 January 2018 at 21:58, brian m. carlson
 wrote:

> When I've made changes to the sha1_file functions, I've traditionally
> moved them away from using "sha1_file" to "object_file" to ensure that
> we make it a bit more obvious that they handle object_id structs and
> aren't limited to SHA-1.  For consistency, it might be nice to make that
> change.

I will address this in V2 and add several more conversions, that
are sufficient to make git hash-object -w work with sha-256 (which I will
send as separate RFC thread).

I started converting functions needed for cat-file, but number of places,
that still needs to be touched up grew quite rapidly, so it'll take some
time :).

-- 
| ← Ceci n'est pas une pipe
Patryk Obara

Re: [PATCH 11/11] sha1_file: convert write_sha1_file to object_id

[Patryk Obara]

On 20 January 2018 at 21:44, brian m. carlson
 wrote:
> On Thu, Jan 18, 2018 at 03:51:03PM +0100, Patryk Obara wrote:
>> diff --git a/sha1_file.c b/sha1_file.c
>> index 88b960316c..b7baf69041 100644
>> --- a/sha1_file.c
>> +++ b/sha1_file.c
>> @@ -1420,8 +1420,8 @@ void *read_object_with_reference(const unsigned char 
>> *sha1,
>>  }
>>
>>  static void write_sha1_file_prepare(const void *buf, unsigned long len,
>> -const char *type, unsigned char *sha1,
>> -char *hdr, int *hdrlen)
>> + const char *type, struct object_id *oid,
>> + char *hdr, int *hdrlen)
>
> It looks like the indentation has changed here.  Was that intentional?

Yes. After every commit, I am running clang-format on lines, that I
touch to verify formatting and
decide if I want to include formatting fixes or not. In this case,
function parameters were
aligned using spaces only (which is arguably hard to see in the mail)
- now they are aligned to first
parameter (at least in my editor and in gitk :)).

-- 
| ← Ceci n'est pas une pipe
Patryk Obara

Proposal

[Ms Melisa Mehmet]

-- 
Hello 

i want to invest in your region i have some funds under my management
please let me know if we can work together on this investment plan.

Regards 
Melisa Mehmet

Re: [PATCH v4 5/6] convert: add 'working-tree-encoding' attribute

[Simon Ruderich]

On Sat, Jan 20, 2018 at 04:24:17PM +0100, lars.schnei...@autodesk.com wrote:
> +static struct encoding *git_path_check_encoding(struct attr_check_item 
> *check)
> +{
> + const char *value = check->value;
> + struct encoding *enc;
> +
> + if (ATTR_TRUE(value) || ATTR_FALSE(value) || ATTR_UNSET(value) ||
> + !strlen(value))
> + return NULL;
> +
> + for (enc = encoding; enc; enc = enc->next)
> + if (!strcasecmp(value, enc->name))
> + return enc;
> +
> + /* Don't encode to the default encoding */
> + if (!strcasecmp(value, default_encoding))
> + return NULL;
> +
> + enc = xcalloc(1, sizeof(struct convert_driver));

I think this should be "sizeof(struct encoding)" but I prefer
"sizeof(*enc)" which prevents these kind of mistakes.

> + enc->name = xstrdup_toupper(value);  /* aways use upper case names! */

"aways" -> "always" and I think the comment should say why
uppercase is important.

> +test_expect_success 'ensure UTF-8 is stored in Git' '
> + git cat-file -p :test.utf16 >test.utf16.git &&
> + test_cmp_bin test.utf8.raw test.utf16.git &&
> + rm test.utf8.raw test.utf16.git
> +'
> +
> +test_expect_success 're-encode to UTF-16 on checkout' '
> + rm test.utf16 &&
> + git checkout test.utf16 &&
> + test_cmp_bin test.utf16.raw test.utf16 &&
> +
> + # cleanup
> + rm test.utf16.raw

Micro-nit: For consistency with the previous test, remove the
empty line and comment (or just keep the files generated from the
"setup test repo" phase and don't explicitly delete them)?

Regards
Simon
-- 
+ privacy is necessary
+ using gnupg http://gnupg.org
+ public key id: 0x92FEFDB7E44C32F9

git svn clone - Malformed network data: The XML response contains invalid XML: Malformed XML: no element found at /usr/share/perl5/vendor_perl/5.26/Git/SVN/Ra.pm line 312

[Jason Pyeron]

I am asuming that this is an issue caused by codeplex's svn from tfs 
implementation. Does anyone here have any insight?

$ git --version
git version 2.15.0

$ git svn clone https://smtp4dev.svn.codeplex.com/svn smtp4dev
Initialized empty Git repository in 
/cygdrive/c/Users/Public/Desktop/projects/smtp4dev/.git/
r20111 = 443d627cdfeeb240162b9f089ab50c6f058a1260 (refs/remotes/git-svn)
A   trunk/smtp4dev/smtp4dev.csproj
A   trunk/smtp4dev/Resources/Icon2.ico
A   trunk/smtp4dev/Resources/Icon1.ico
A   trunk/smtp4dev/RegistrySettings.cs
A   trunk/smtp4dev/Properties/Settings.settings
A   trunk/smtp4dev/Properties/Settings.Designer.cs
A   trunk/smtp4dev/Properties/Resources.resx
A   trunk/smtp4dev/Properties/Resources.Designer.cs
A   trunk/smtp4dev/Properties/AssemblyInfo.cs
A   trunk/smtp4dev/Program.cs
A   trunk/smtp4dev/OptionsForm.resx
A   trunk/smtp4dev/OptionsForm.Designer.cs
A   trunk/smtp4dev/OptionsForm.cs
A   
trunk/smtp4dev/obj/Debug/TempPE/Properties.Resources.Designer.cs.dll
A   trunk/smtp4dev/obj/Debug/smtp4dev.Properties.Resources.resources
A   trunk/smtp4dev/obj/Debug/smtp4dev.pdb
A   trunk/smtp4dev/obj/Debug/smtp4dev.OptionsForm.resources
A   trunk/smtp4dev/obj/Debug/smtp4dev.MainForm.resources
A   trunk/smtp4dev/obj/Debug/smtp4dev.exe
A   trunk/smtp4dev/obj/Debug/smtp4dev.csproj.GenerateResource.Cache
A   trunk/smtp4dev/obj/Debug/smtp4dev.csproj.FileListAbsolute.txt
A   trunk/smtp4dev/obj/Debug/ResolveAssemblyReference.cache
A   trunk/smtp4dev/MainForm.resx
A   trunk/smtp4dev/MainForm.Designer.cs
A   trunk/smtp4dev/MainForm.cs
A   trunk/smtp4dev/lib/log4net.dll
A   trunk/smtp4dev/lib/cses.smtp.server.xml
A   trunk/smtp4dev/lib/cses.smtp.server.dll
A   trunk/smtp4dev/Email.cs
A   trunk/smtp4dev/bin/Debug/smtp4dev.vshost.exe
A   trunk/smtp4dev/bin/Debug/smtp4dev.vshost.exe.manifest
A   trunk/smtp4dev/bin/Debug/smtp4dev.vshost.exe.config
A   trunk/smtp4dev/bin/Debug/smtp4dev.pdb
A   trunk/smtp4dev/bin/Debug/smtp4dev.exe
A   trunk/smtp4dev/bin/Debug/smtp4dev.exe.config
A   trunk/smtp4dev/bin/Debug/log4net.dll
A   trunk/smtp4dev/bin/Debug/cses.smtp.server.xml
A   trunk/smtp4dev/bin/Debug/cses.smtp.server.dll
A   trunk/smtp4dev/app.config
A   trunk/smtp4dev.suo
A   trunk/smtp4dev.sln
A   trunk/smtp4dev.4.5.resharper.user
A   trunk/Setup/Setup.vdproj
A   trunk/Setup/Debug/smtp4dev-1.0.0.0.zip
A   trunk/Setup/Debug/Setup.msi
A   trunk/Setup/Debug/setup.exe
A   trunk/Setup/Debug/LICENSE
A   trunk/Setup/Debug/LICENSE.log4net
A   trunk/Setup/Debug/LICENSE.cses-smtp-server
A   trunk/LICENSE
A   trunk/LICENSE.rtf
A   trunk/LICENSE.log4net
A   trunk/LICENSE.cses-smtp-server
A   trunk/_ReSharper.smtp4dev/Xaml/CacheProvider.dat
A   trunk/_ReSharper.smtp4dev/WordIndex.New/6/61e28584.dat
A   trunk/_ReSharper.smtp4dev/WordIndex.New/.version
A   trunk/_ReSharper.smtp4dev/WebsiteFileReferences/.version
A   trunk/_ReSharper.smtp4dev/TodoCache/9/3ace61b9.dat
A   trunk/_ReSharper.smtp4dev/TodoCache/.version
A   trunk/_ReSharper.smtp4dev/ProjectModel/ProjectModel.dat
A   trunk/_ReSharper.smtp4dev/CachesImage.bin
W: +empty_dir: trunk/Setup/Release
W: +empty_dir: trunk/smtp4dev/obj/Debug/Refactor
r20114 = 569cc523b14d6346f3198f37b27fccb8cb572ab1 (refs/remotes/git-svn)
... It chugs along then ...
W: -empty_dir: trunk/Rnwood.Smtp4dev/Behaviour.cs
W: -empty_dir: trunk/Rnwood.SmtpServer/SmtpRequest.cs
r27599 = 9e769d8327767a155d7b96b7cc28579cf0ed4c93 (refs/remotes/git-svn)
Malformed network data: The XML response contains invalid XML: Malformed XML: 
no element found at /usr/share/perl5/vendor_perl/5.26/Git/SVN/Ra.pm line 312.


I have tried to fiddle with --log-window-size but nothing seemed to work. 
(https://stackoverflow.com/questions/38071052/getting-error-while-migrating-code-from-svn-to-git-repository-malformed-network)


-Jason

--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-   -
- Jason Pyeron  PD Inc. http://www.pdinc.us -
- Principal Consultant  10 West 24th Street #100-
- +1 (443) 269-1555 x333Baltimore, Maryland 21218   -
-   -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Re: [PATCH] worktree: teach "add" to check out existing branches

[Robert P. J. Day]

On Sun, 21 Jan 2018, Thomas Gummerer wrote:

> Currently 'git worktree add ' creates a new branch named after the
> basename of the path by default.  If a branch with that name already
> exists, the command refuses to do anything, unless the '--force' option
> is given.
>
> However we can do a little better than that, and check the branch out if
> it is not checked out anywhere else.  This will help users who just want
> to check an existing branch out into a new worktree, and save a few
> keystrokes.
>
> As the current behaviour is to simply 'die()' when a brach with the name
   ^

Grattis

[Ana Lia Gamboa Valverde]

Grattis du har vunnit € 650,000.00 i Euro Millions / Google Promo 
månadsdragningar hölls den 1 januari 2018. Kontakta vår agent 
Email: janosiklubos...@gmail.com

1. Fullständigt namn:
2. Adress:
3. Kön:
4. Ålder:
5. Yrke:
6. Telefon:

Robert Avtandiltayn
Online-koordinator

[PATCH] worktree: teach "add" to check out existing branches

[Thomas Gummerer]

Currently 'git worktree add ' creates a new branch named after the
basename of the path by default.  If a branch with that name already
exists, the command refuses to do anything, unless the '--force' option
is given.

However we can do a little better than that, and check the branch out if
it is not checked out anywhere else.  This will help users who just want
to check an existing branch out into a new worktree, and save a few
keystrokes.

As the current behaviour is to simply 'die()' when a brach with the name
of the basename of the path already exists, there are no backwards
compatibility worries here.

We will still 'die()' if the branch is checked out in another worktree,
unless the --force flag is passed.

Signed-off-by: Thomas Gummerer 
---

This is a follow-up to
https://public-inbox.org/git/20171118181345.GC32324@hank/, where this
was first suggested, but I didn't want to do it as part of that
series.  Now I finally got around to implementing it.

 Documentation/git-worktree.txt |  9 +++--
 builtin/worktree.c | 22 +++---
 t/t2025-worktree-add.sh| 15 ---
 3 files changed, 34 insertions(+), 12 deletions(-)

diff --git a/Documentation/git-worktree.txt b/Documentation/git-worktree.txt
index 41585f535d..98731b71a7 100644
--- a/Documentation/git-worktree.txt
+++ b/Documentation/git-worktree.txt
@@ -61,8 +61,13 @@ $ git worktree add --track -b   
/
 
 +
 If `` is omitted and neither `-b` nor `-B` nor `--detach` used,
-then, as a convenience, a new branch based at HEAD is created automatically,
-as if `-b $(basename )` was specified.
+then, as a convenience, a worktree with a branch named after
+`$(basename )` (call it ``) is created.  If ``
+doesn't exist, a new branch based on HEAD is automatically created as
+if `-b ` was given.  If `` exists in the repository,
+it will be checked out in the new worktree, if it's not checked out
+anywhere else, otherwise the command will refuse to create the
+worktree.
 
 list::
 
diff --git a/builtin/worktree.c b/builtin/worktree.c
index 7cef5b120b..148a864bb9 100644
--- a/builtin/worktree.c
+++ b/builtin/worktree.c
@@ -411,13 +411,21 @@ static int add(int ac, const char **av, const char 
*prefix)
if (ac < 2 && !opts.new_branch && !opts.detach) {
int n;
const char *s = worktree_basename(path, );
-   opts.new_branch = xstrndup(s, n);
-   if (guess_remote) {
-   struct object_id oid;
-   const char *remote =
-   unique_tracking_name(opts.new_branch, );
-   if (remote)
-   branch = remote;
+   const char *branchname = xstrndup(s, n);
+   struct strbuf ref = STRBUF_INIT;
+   if (!strbuf_check_branch_ref(, branchname) &&
+   ref_exists(ref.buf)) {
+   branch = branchname;
+   opts.checkout = 1;
+   } else {
+   opts.new_branch = branchname;
+   if (guess_remote) {
+   struct object_id oid;
+   const char *remote =
+   unique_tracking_name(opts.new_branch, 
);
+   if (remote)
+   branch = remote;
+   }
}
}
 
diff --git a/t/t2025-worktree-add.sh b/t/t2025-worktree-add.sh
index 2b95944973..721b0e4c26 100755
--- a/t/t2025-worktree-add.sh
+++ b/t/t2025-worktree-add.sh
@@ -198,13 +198,22 @@ test_expect_success '"add" with  omitted' '
test_cmp_rev HEAD bat
 '
 
-test_expect_success '"add" auto-vivify does not clobber existing branch' '
+test_expect_success '"add" auto-vivify checks out existing branch' '
test_commit c1 &&
test_commit c2 &&
git branch precious HEAD~1 &&
-   test_must_fail git worktree add precious &&
+   git worktree add precious &&
test_cmp_rev HEAD~1 precious &&
-   test_path_is_missing precious
+   (
+   cd precious &&
+   test_cmp_rev precious HEAD
+   )
+'
+
+test_expect_success '"add" auto-vivify fails with checked out branch' '
+   git checkout -b test-branch &&
+   test_must_fail git worktree add test-branch &&
+   test_path_is_missing test-branch
 '
 
 test_expect_success '"add" no auto-vivify with --detach and  omitted' '
-- 
2.16.0.312.g896df04e46

Re: [PATCH] dir.c: print correct errno when opendir() fails

[Duy Nguyen]

On Sat, Jan 20, 2018 at 4:09 AM, Junio C Hamano  wrote:
> Nguyễn Thái Ngọc Duy   writes:
>
>> The call invalidate_directory() between opendir() and warning_errno() in
>> theory could make some system calls and change errno. Prevent that by
>> warning immediately after opendir().
>>
>> Signed-off-by: Nguyễn Thái Ngọc Duy 
>> ---
>>  This is on top of nd/fix-untracked-cache-invalidation which is now on
>>  'next'. Sorry I waited too long to send the replacement and it's now
>>  too late.
>
> Well, we'll see a rewind of 'next' soonish anyway, so you can just
> tell me to tentatively kick it back to 'pu' to be replaced with a
> reroll if you prefer.

Please kick it back to 'pu'.
-- 
Duy

Re: [PATCH] t: add clone test for files differing only in case

[Duy Nguyen]

On Sun, Jan 21, 2018 at 3:33 AM, brian m. carlson
 wrote:
> We recently introduced a regression in cloning repositories onto
> case-insensitive file systems where the repository contains multiple
> files differing only in case.  In such a case, we would segfault.  This
> segfault has already been fixed (repository: pre-initialize hash algo
> pointer), but it's not the first time similar problems have arisen.
> Introduce a test to catch this case and ensure the behavior does not
> regress.
>
> Signed-off-by: Eric Sunshine 
> Signed-off-by: brian m. carlson 
> ---
>  t/t5601-clone.sh | 13 +
>  1 file changed, 13 insertions(+)
>
> I've verified that the test does fail without the patch on a vfat file
> system.  However, many other tests also fail on a vfat file system on
> Linux, so unfortunately that doesn't look like a viable testing strategy
> going forward.

vfat is not very UNIXy. I suspect we need a bunch of tweaks that
cygwin/mingw uses to make the test suite pass. There are other
case-insensitive filesystems on linux though. JFS (with "mkfs.jfs -O"
to make it case-insensitive) seems to pass the test suite and crash
git without your fix so it's a good candidate if someone wants to test
this behavior on linux in future. HFS+ fails some unicode test in
t0050 and I didn't check further.

> +test_expect_success 'clone on case-insensitive fs' '

We have CASE_INSENSITIVE_FS prereq. Should we use it here? I know it
does not harm running this test on case-sensitive filesystem, but the
prereq could be useful for grepping.

> +   o=$(git hash-object -w --stdin  +   t=$(printf "100644 X\0${o}100644 x\0${o}" |
> +   git hash-object -w -t tree --stdin) &&
> +   c=$(git commit-tree -m bogus $t) &&
> +   git update-ref refs/heads/bogus $c &&
> +   git clone -b bogus . bogus
> +'
> +
>  test_done
-- 
Duy

payable through bank transfer or ATM Card.

[Free Lotto]

Congratulation!!! Dear Email User,


We wish to notify you that your email address was automatically
generated and selected during Network Online Program GLOBAL EMAIL
RAFFLE AWARDS (G E R A) yearly International Online Promotions draw
held in New York.
You have therefore been approved to claim a Star Prize of $1,
000.000.00 One Million US Dollars in cash credited to Reference No:
3249756/2018. The award money is payable through bank transfer or ATM
Card.
To claim your winning prize contacts your appointed claim agent in
your region because your email shows you are from Africa or Asia.  Rev
Paul Peter
 Email :  raffleemailaw...@mail2world.com

Yours sincerely,


Congratulations'' once again from all our Staff and thank you for
being part of our Web Online Promotions Program

Re: [PATCH v2 09/12] fetch: don't redundantly NULL something calloc() gave us

[Ævar Arnfjörð Bjarmason]

On Sun, Jan 21 2018, Ævar Arnfjörð Bjarmason jotted:

> 2007-09-10), where wasn't any reason to do this back then either, it's

s/where wasn't/where there wasn't/

> The initial motivation for this change was to make a subsequent change
> which'll also modify the refs variable smaller, since it won't have to
> copy this redundant "NULL the last + 1 item" pattern.

Which, FWIW is not happening later in this series anymore, so this is
just a "cleanup while I'm at it" patch at this point. Will note that in
a v3 commit message pending more comments.

Re: git merge-tree: bug report and some feature requests

[Ævar Arnfjörð Bjarmason]

On Sun, Jan 21 2018, Josh Bleecher Snyder jotted:

> 3. Feature suggestion
>
> There's no direct indication of whether any given file's merge
> succeeded. Currently I sniff for merge conflicts by looking for
> "+<<< .our", which feels like an ugly kludge. Could we provide an
> explicit indicator? (And maybe also one for binary vs text
> processing?)
>
> Note that binary file merge conflicts don't generate patches with
> three-way merge markers but instead say "warning: Cannot merge binary
> files: binary (.our vs. .their)". Looking for this case even further
> complicates the output parser.

I thought I had a way to do this, but looking back in my logs I find
that I was just using:

git merge-tree $(git merge-base A B) A B | grep -e '^\+==='; echo $?

I.e. a variation of what you're doing, which as you note won't work for
binary files.

Re: [PATCH] t: add clone test for files differing only in case

[Eric Sunshine]

On Sun, Jan 21, 2018 at 02:46:15AM -0500, Eric Sunshine wrote:
> On Sun, Jan 21, 2018 at 2:33 AM, Junio C Hamano  wrote:
> > "brian m. carlson"  writes:
> >> +test_expect_success 'clone on case-insensitive fs' '
> >> + o=$(git hash-object -w --stdin  >> + t=$(printf "100644 X\0${o}100644 x\0${o}" |
> >> + git hash-object -w -t tree --stdin) &&
> >> + c=$(git commit-tree -m bogus $t) &&
> >> + git update-ref refs/heads/bogus $c &&
> >> + git clone -b bogus . bogus
> >> +'
> >
> > Hmm, I seem to be seeing a failure from this thing:
> > fatal: repository '.' does not exist
> > even on a case sensitive platform.
> 
> Yep. In pretty much any other test script, this would work (it was
> developed in a stand-alone script), but t5601 (which nukes .git as its
> first action) isn't the most friendly place.

Here's a re-roll which fixes that problem (and has a slightly
re-written commit message.

--- >8 ---
From: Eric Sunshine 
Subject: [PATCH] t5601-clone: test case-conflicting files on case-insensitive
 filesystem

A recently introduced regression caused a segfault at clone time on
case-insensitive filesystems when filenames differing only in case are
present. This bug has already been fixed (repository: pre-initialize
hash algo pointer, 2018-01-18), but it's not the first time similar
problems have arisen. Therefore, introduce a test to catch this case and
protect against future regressions.

Signed-off-by: Eric Sunshine 
Signed-off-by: brian m. carlson 
Signed-off-by: Eric Sunshine 
---
 t/t5601-clone.sh | 17 +
 1 file changed, 17 insertions(+)

diff --git a/t/t5601-clone.sh b/t/t5601-clone.sh
index 0f895478f0..2d1490f631 100755
--- a/t/t5601-clone.sh
+++ b/t/t5601-clone.sh
@@ -611,4 +611,21 @@ test_expect_success 'GIT_TRACE_PACKFILE produces a usable 
pack' '
git -C replay.git index-pack -v --stdin