[PATCH] git-submodules.sh: fix '/././' path normalization

[Patrick Steinhardt]

When we add a new submodule the path of the submodule is being normalized. We
fail to normalize multiple adjacent '/./', though. Thus 'path/to/././submodule'
will become 'path/to/./submodule' where it should be 'path/to/submodule'
instead.

Signed-off-by: Patrick Steinhardt p...@pks.im
---
 git-submodule.sh   |  2 +-
 t/t7400-submodule-basic.sh | 17 +
 2 files changed, 18 insertions(+), 1 deletion(-)

diff --git a/git-submodule.sh b/git-submodule.sh
index 9245abf..36797c3 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -423,7 +423,7 @@ cmd_add()
sed -e '
s|//*|/|g
s|^\(\./\)*||
-   s|/\./|/|g
+   s|/\(\./\)*|/|g
:start
s|\([^/]*\)/\.\./||
tstart
diff --git a/t/t7400-submodule-basic.sh b/t/t7400-submodule-basic.sh
index 7c88245..5811a98 100755
--- a/t/t7400-submodule-basic.sh
+++ b/t/t7400-submodule-basic.sh
@@ -171,6 +171,23 @@ test_expect_success 'submodule add with ./ in path' '
test_cmp empty untracked
 '
 
+test_expect_success 'submodule add with /././ in path' '
+   echo refs/heads/master expect 
+   empty 
+
+   (
+   cd addtest 
+   git submodule add $submodurl dotslashdotsubmod/././frotz/./ 
+   git submodule init
+   ) 
+
+   rm -f heads head untracked 
+   inspect addtest/dotslashdotsubmod/frotz ../../.. 
+   test_cmp expect heads 
+   test_cmp expect head 
+   test_cmp empty untracked
+'
+
 test_expect_success 'submodule add with // in path' '
echo refs/heads/master expect 
empty 
-- 
2.2.2


--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

bug report: build issue with git 2.2.2 using uclibc toolchain

[Lance Fredrickson]

I've been keeping up-to-date versions of git built for an embedded 
mipsel architecture device running on uclibc.

2.2.1 and previous versions build fine, but 2.2.2 stops with an error.

The toolchain is an OpenWRT variant (entware) using gcc 4.6.4 and uclibc 
0.9.32, available at the following.

http://entware.wl500g.info/sources/

Here is the output of the build error.

CC builtin/grep.o
builtin/get-tar-commit-id.c: In function 'cmd_get_tar_commit_id':
builtin/get-tar-commit-id.c:31:12: error: dereferencing pointer to 
incomplete type

--
To unsubscribe from this list: send the line 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] Makefile: Handle broken curl version number in version check

[Tom G. Christensen]

On 30/01/15 15:50, Andreas Schwab wrote:

Tom G. Christensen t...@statsbiblioteket.dk writes:


diff --git a/Makefile b/Makefile
index c44eb3a..69a2ce3 100644
--- a/Makefile
+++ b/Makefile
@@ -1035,13 +1035,13 @@ else
REMOTE_CURL_NAMES = $(REMOTE_CURL_PRIMARY) $(REMOTE_CURL_ALIASES)
PROGRAM_OBJS += http-fetch.o
PROGRAMS += $(REMOTE_CURL_NAMES)
-   curl_check := $(shell (echo 070908; curl-config --vernum) 2/dev/null | 
sort -r | sed -ne 2p)
+   curl_check := $(shell (echo 070908; curl-config --vernum | sed -e 
'/^70[B-C]/ s/^7/07/') 2/dev/null | sort -r | sed -ne 2p)


How about 's/^.$/0/' ?



I have no preference so whatever is the most likely to be accepted and 
does the job is fine with me.


-tgc
--
To unsubscribe from this list: send the line 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] Makefile: Handle broken curl version number in version check

[Kyle J. McKay]

On Jan 30, 2015, at 06:50, Andreas Schwab wrote:


Tom G. Christensen t...@statsbiblioteket.dk writes:


diff --git a/Makefile b/Makefile
index c44eb3a..69a2ce3 100644
--- a/Makefile
+++ b/Makefile
@@ -1035,13 +1035,13 @@ else
REMOTE_CURL_NAMES = $(REMOTE_CURL_PRIMARY) $(REMOTE_CURL_ALIASES)
PROGRAM_OBJS += http-fetch.o
PROGRAMS += $(REMOTE_CURL_NAMES)
-	curl_check := $(shell (echo 070908; curl-config --vernum) 2/dev/ 
null | sort -r | sed -ne 2p)
+	curl_check := $(shell (echo 070908; curl-config --vernum | sed -e  
'/^70[B-C]/ s/^7/07/') 2/dev/null | sort -r | sed -ne 2p)


How about 's/^.$/0/' ?


Much nicer.  But that '$' will have to be escaped from make so it will  
need to be 's/^.$$/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: bug report: build issue with git 2.2.2 using uclibc toolchain

[Lance Fredrickson]

Sorry, file this one away under user error. I had an issue with my build 
environment.

cheers!

On 1/30/2015 8:55 AM, Lance Fredrickson wrote:
I've been keeping up-to-date versions of git built for an embedded 
mipsel architecture device running on uclibc.

2.2.1 and previous versions build fine, but 2.2.2 stops with an error.

The toolchain is an OpenWRT variant (entware) using gcc 4.6.4 and 
uclibc 0.9.32, available at the following.

http://entware.wl500g.info/sources/

Here is the output of the build error.

CC builtin/grep.o
builtin/get-tar-commit-id.c: In function 'cmd_get_tar_commit_id':
builtin/get-tar-commit-id.c:31:12: error: dereferencing pointer to 
incomplete type


--
To unsubscribe from this list: send the line 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 v9 0/1] http: Add Accept-Language header if possible

[Yi, EungJun]

I'm very glad to hear that. Thanks to all reviewers!

On Thu, Jan 29, 2015 at 3:19 PM, Junio C Hamano gits...@pobox.com wrote:
 Thanks; queued.  Let's run with this and try to make it graduate
 early next cycle.
--
To unsubscribe from this list: send the line 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 report: build issue with git 2.2.2 using uclibc toolchain

[Jeff King]

On Fri, Jan 30, 2015 at 08:55:20AM -0700, Lance Fredrickson wrote:

 I've been keeping up-to-date versions of git built for an embedded mipsel
 architecture device running on uclibc.
 2.2.1 and previous versions build fine, but 2.2.2 stops with an error.
 
 The toolchain is an OpenWRT variant (entware) using gcc 4.6.4 and uclibc
 0.9.32, available at the following.
 http://entware.wl500g.info/sources/
 
 Here is the output of the build error.
 
 CC builtin/grep.o
 builtin/get-tar-commit-id.c: In function 'cmd_get_tar_commit_id':
 builtin/get-tar-commit-id.c:31:12: error: dereferencing pointer to
 incomplete type

That seems odd. The line in question is:

  if (header-typeflag[0] != 'g')

the header variable is defined above as:

  struct ustar_header *header = (struct ustar_header *)buffer;

and struct ustar_header is defined in tar.h, which is included
above.

uclibc ships its own tar.h. Ours should take precedence (because we use
), but perhaps there is something funny going on in the build
settings. I can't find any interesting changes in v2.2.1..v2.2.2,
though.

Can you double-check that v2.2.1 still builds, and if so try to use git
bisect start v2.2.2 v2.2.1 to find the responsible commit?

-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] Makefile: Handle broken curl version number in version check

[Junio C Hamano]

Tom G. Christensen t...@statsbiblioteket.dk writes:

 diff --git a/Makefile b/Makefile
 index c44eb3a..69a2ce3 100644
 --- a/Makefile
 +++ b/Makefile
 @@ -1035,13 +1035,13 @@ else
   REMOTE_CURL_NAMES = $(REMOTE_CURL_PRIMARY) $(REMOTE_CURL_ALIASES)
   PROGRAM_OBJS += http-fetch.o
   PROGRAMS += $(REMOTE_CURL_NAMES)
 - curl_check := $(shell (echo 070908; curl-config --vernum) 2/dev/null | 
 sort -r | sed -ne 2p)
 + curl_check := $(shell (echo 070908; curl-config --vernum | sed -e 
 '/^70[B-C]/ s/^7/07/') 2/dev/null | sort -r | sed -ne 2p)
   ifeq $(curl_check) 070908
   ifndef NO_EXPAT
   PROGRAM_OBJS += http-push.o
   endif
   endif
 - curl_check := $(shell (echo 072200; curl-config --vernum) 2/dev/null | 
 sort -r | sed -ne 2p)
 + curl_check := $(shell (echo 072200; curl-config --vernum | sed -e 
 '/^70[B-C]/ s/^7/07/') 2/dev/null | sort -r | sed -ne 2p)
   ifeq $(curl_check) 072200
   USE_CURL_FOR_IMAP_SEND = YesPlease
   endif

Thanks, will apply but with sed part tweaked to '/^70[BC]/s/^/0/'
instead.

The existing tests that copied and pasted are bad enough.  Can we
consolidate them into some helper or a shorter idiom that lets us
more easily ask Do we have cURL version X or higher?
--
To unsubscribe from this list: send the line 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] apply: refuse touching a file beyond symlink

[Junio C Hamano]

Jeff King p...@peff.net writes:

 Ah, OK. Yeah, doing it progressively can only be accurate if our
 name-checks follow the same order as applying, because we are checking
 against a particular state.

 But could we instead pull this check to just before the write-out time?
 That is, to let any horrible thing happen in-core, as long as what we
 write out to the index and the filesystem is sane?

That would make me feel dirty.

I noticed one thing.  The PATH_TO_BE_DELETED/PATH_WAS_DELETED crud
kicks in -only- during the actual application phase, and all patches
that remove paths from the end result should have been appropriately
marked in fn_table[] by the call to prepare_fn_table() at the
beginning of check_patch_list() as PATH_TO_BE_DELETED.

But it was wrong to call previous_patch() in my fix.  The function
is the cause of evil I see in the let's support concatenated patch,
making the later patch depend on the result of earlier ones and
deliberately ignores PATH_TO_BE_DELETED patches.  We would need to
do the early part of previous_patch() without the filtering.

This is a preparatory step to clean-up the mess I have in mind.  It
does not mean to change the semantics (applied to the codebase with
or without the changes we have been discussing); it only makes it
always return the previous patch to the callers and makes them
responsible to see if the previous was to-be-deleted or was-deleted.

With that change, I think my symlink fix plus the check the deleted
one with old_name, too change has a better chance to do the moral
equivalent of your two-phase thing.  Essentially, First see what
will be deleted in the input as a whole has already been done by
the prepare_fn_table() thing.

 builtin/apply.c | 34 --
 1 file changed, 12 insertions(+), 22 deletions(-)

diff --git a/builtin/apply.c b/builtin/apply.c
index 41b7236..a064017 100644
--- a/builtin/apply.c
+++ b/builtin/apply.c
@@ -3097,25 +3097,12 @@ static int checkout_target(struct cache_entry *ce, 
struct stat *st)
return 0;
 }
 
-static struct patch *previous_patch(struct patch *patch, int *gone)
+static struct patch *previous_patch(struct patch *patch)
 {
-   struct patch *previous;
-
-   *gone = 0;
if (patch-is_copy || patch-is_rename)
return NULL; /* git patches do not depend on the order */
 
-   previous = in_fn_table(patch-old_name);
-   if (!previous)
-   return NULL;
-
-   if (to_be_deleted(previous))
-   return NULL; /* the deletion hasn't happened yet */
-
-   if (was_deleted(previous))
-   *gone = 1;
-
-   return previous;
+   return in_fn_table(patch-old_name);
 }
 
 static int verify_index_match(const struct cache_entry *ce, struct stat *st)
@@ -3170,11 +3157,11 @@ static int load_preimage(struct image *image,
struct patch *previous;
int status;
 
-   previous = previous_patch(patch, status);
-   if (status)
+   previous = previous_patch(patch);
+   if (was_deleted(previous))
return error(_(path %s has been renamed/deleted),
 patch-old_name);
-   if (previous) {
+   if (previous  !to_be_deleted(previous)) {
/* We have a patched copy in memory; use that. */
strbuf_add(buf, previous-result, previous-resultsize);
} else {
@@ -3384,18 +3371,18 @@ static int check_preimage(struct patch *patch, struct 
cache_entry **ce, struct s
 {
const char *old_name = patch-old_name;
struct patch *previous = NULL;
-   int stat_ret = 0, status;
+   int stat_ret = 0;
unsigned st_mode = 0;
 
if (!old_name)
return 0;
 
assert(patch-is_new = 0);
-   previous = previous_patch(patch, status);
+   previous = previous_patch(patch);
 
-   if (status)
+   if (was_deleted(previous))
return error(_(path %s has been renamed/deleted), old_name);
-   if (previous) {
+   if (previous  !to_be_deleted(previous)) {
st_mode = previous-new_mode;
} else if (!cached) {
stat_ret = lstat(old_name, st);
@@ -3403,6 +3390,9 @@ static int check_preimage(struct patch *patch, struct 
cache_entry **ce, struct s
return error(_(%s: %s), old_name, strerror(errno));
}
 
+   if (to_be_deleted(previous))
+   previous = NULL;
+
if (check_index  !previous) {
int pos = cache_name_pos(old_name, strlen(old_name));
if (pos  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] apply: refuse touching a file beyond symlink

[Junio C Hamano]

Jeff King p...@peff.net writes:

 I had the impression that we did not apply in any arbitrary order that
 could work, but rather that we did deletions first followed by
 additions. But I am fairly ignorant of the apply code.

No, you are thinking about the write-out of the finished result,
which may have to turn existing directory to a file or vice versa on
the filesystem, but that happens _after_ we decide what to turn into
what else, completely in-core.

And the decision to determine what the input _means_ should not
depend on the order of patches in the input.
--
To unsubscribe from this list: send the line 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] apply: refuse touching a file beyond symlink

[Jeff King]

On Fri, Jan 30, 2015 at 12:20:02PM -0800, Junio C Hamano wrote:

 Jeff King p...@peff.net writes:
 
  I had the impression that we did not apply in any arbitrary order that
  could work, but rather that we did deletions first followed by
  additions. But I am fairly ignorant of the apply code.
 
 No, you are thinking about the write-out of the finished result,
 which may have to turn existing directory to a file or vice versa on
 the filesystem, but that happens _after_ we decide what to turn into
 what else, completely in-core.
 
 And the decision to determine what the input _means_ should not
 depend on the order of patches in the input.

Ah, OK. Yeah, doing it progressively can only be accurate if our
name-checks follow the same order as applying, because we are checking
against a particular state.

But could we instead pull this check to just before the write-out time?
That is, to let any horrible thing happen in-core, as long as what we
write out to the index and the filesystem is sane?

-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] apply: refuse touching a file beyond symlink

[Junio C Hamano]

Jeff King p...@peff.net writes:

 But could we instead pull this check to just before the write-out time?
 That is, to let any horrible thing happen in-core, as long as what we
 write out to the index and the filesystem is sane?

The check in-core is somewhat tricky, because we would need to (1)
catch a patch that creates a symlink and also a file as if that new
symlink is a directory and (2) allow a patch that removes a symlink
and also a file in a new directory at the location removed symlink
used to occupy.

For (1) we need to see if there is a patch in the entire input that
creates a symbolic link and reject the input.  For (2) we need to
see if there is a patch that removes the symbolic link.  (1) cannot
be caught with the approach based on fn_table[], which is inherently
meant to help incremental application, that is oblivious to a path
that will materialize after applying a later patch in the input.

Let me think about it a bit more.  The fix probably needs to abandon
depending on fn_table[] stuff, if we want to do in the sanity check
the input and compute the final state all in-core route.


--
To unsubscribe from this list: send the line 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] t9001: use older Getopt::Long boolean prefix '--no' rather than '--no-'

[brian m. carlson]

On Fri, Jan 30, 2015 at 07:24:45AM +0100, Tom G. Christensen wrote:

The '--no-xmailer' option is a Getopt::Long boolean option. The
'--no-' prefix (as in --no-xmailer) for boolean options is not
supported in Getopt::Long version 2.32 which was released with Perl 5.8.0.
This version only supports '--no' as in '--noxmailer'.  More recent
versions of Getopt::Long, such as version 2.34, support either prefix. So
use the older form in the tests.

See also:

d2559f734bba7fe5257720356a92f3b7a5b0d37c
907a0b1e04ea31cb368e9422df93d8ebb0187914
84eeb687de7a6c7c42af3fb51b176e0f412a979e
3fee1fe87144360a1913eab86af9ad136c810076

Signed-off-by: Tom G. Christensen t...@statsbiblioteket.dk
---
t/t9001-send-email.sh | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh
index af6a3e8..30df6ae 100755
--- a/t/t9001-send-email.sh
+++ b/t/t9001-send-email.sh
@@ -1580,20 +1580,20 @@ do_xmailer_test () {

test_expect_success $PREREQ '--[no-]xmailer without any configuration' '
do_xmailer_test 1 --xmailer 
-   do_xmailer_test 0 --no-xmailer
+   do_xmailer_test 0 --noxmailer


I don't think this is an adequate fix.  The documented option is 
--no-xmailer.  If your version of Getopt::Long is not capable of that, 
then the program doesn't work as documented, and the test is correctly 
failing.  --noxmailer is not documented at all, so it's not something we 
should be testing.


We should probably require a certain version of Getopt::Long or 
explicitly handle this in the parsing code itself.  I think the former 
is a better choice, since no security-supported OS still ships with such 
a positively ancient version.

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


signature.asc
Description: Digital signature

[git-gui] bug report: Open existing repository dialog fails on submodules

[Rémi Rampin]

Hi,

This bug report concerns git-gui. Apologies if this is not the right
mailing-list.

By submodule I mean a repository for which .git is not a regular Git
directory, but rather a gitdir: ... file.
While running git gui from such a directory will work fine, trying
to open it from the choose_repository window will fail with Not a Git
repository. This is because of the simplistic implementation of proc
_is_git in lib/choose_repository.tcl.

I suggest fixing that function, or using Git directly to perform that
check, for instance checking git rev-parse --show-toplevel. I'd
attempt a patch but my tcl-fu is weak.

Best
-- 
Rémi Rampin
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/1] apply: reject input that touches outside $cwd

[Jeff King]

On Thu, Jan 29, 2015 at 03:48:14PM -0800, Junio C Hamano wrote:

 By default, a patch that affects outside the working area is
 rejected as a mistake; Git itself never creates such a patch
 unless the user bends backwards and specifies nonstandard
 prefix to git diff and friends.
 
 When `git apply` is used without either `--index` or `--cached`
 option as a better GNU patch, the user can pass `--allow-uplevel`
 option to override this safety check.  This cannot be used to escape
 outside the working tree when using `--index` or `--cached` to apply
 the patch to the index.

It looks like your new --allow-uplevel goes to verify_path(). So this
isn't just about .., but it will also protect against applying a patch
inside .git. Which seems like a good thing to me, but I wonder if the
option name is a little misleading. It is really about applying the same
checks we do for index paths to the non-index mode of git apply.

  * Meant to apply on top of the previous one, but these two are
about separate and orthogonal issues.

I agree they are orthogonal in concept, though I doubt the symlink tests
here would pass without the previous one (since verify_path does not
know or care about crossing symlink boundaries).

-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] apply: refuse touching a file beyond symlink

[Junio C Hamano]

Jeff King p...@peff.net writes:

 +if (!patch-is_delete  path_is_beyond_symlink(patch-new_name))
 +return error(_(affected file '%s' is beyond a symbolic link),
 + patch-new_name);

 Why does this not kick in when deleting a file? If it is not OK to
 add across a symlink, why is it OK to delete?

Hmph, adding

if (patch-is_delete  path_is_beyond_symlink(patch-old_name))
return error(_(deleted file '%s' is beyond a symlink),
patch-old_name);

seems to break t4114.11, which wants to apply this patch to a tree
that does not have a symbolic link but a directory at 'foo/'.

diff --git a/foo b/foo
new file mode 12
index 000..ba0e162
--- /dev/null
+++ b/foo
@@ -0,0 +1 @@
+bar
\ No newline at end of file
diff --git a/foo/baz b/foo/baz
deleted file mode 100644
index 682c76b..000
--- a/foo/baz
+++ /dev/null
@@ -1 +0,0 @@
-if only I knew
--
To unsubscribe from this list: send the line 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] apply: refuse touching a file beyond symlink

[Junio C Hamano]

Jeff King p...@peff.net writes:

 On Thu, Jan 29, 2015 at 12:45:22PM -0800, Junio C Hamano wrote:

 +if (!patch-is_delete  path_is_beyond_symlink(patch-new_name))
 +return error(_(affected file '%s' is beyond a symbolic link),
 + patch-new_name);

 Why does this not kick in when deleting a file?

Half-written logic, forgotten to be revisited (i.e. ok, anything
that is not delete we can check new_name, so do that first, later
we'd deal with deletion patch and I think the way to do so is by
checking old_name, but let's make sure this case works first).

Thanks for catching.
--
To unsubscribe from this list: send the line 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] apply: refuse touching a file beyond symlink

[Junio C Hamano]

Jeff King p...@peff.net writes:

 Hrm. That only works in the current code because we apply the deletion
 in the directory (and then clean up the now-empty directory) first. So I
 think you would need to check the paths progressively as you apply them,
 since those other parts of the diff haven't happened yet.

Just to make sure that I am not hallucinating, I added this one:

diff --git a/t/t4114-apply-typechange.sh b/t/t4114-apply-typechange.sh
index ebadbc3..83ddf62 100755
--- a/t/t4114-apply-typechange.sh
+++ b/t/t4114-apply-typechange.sh
@@ -119,4 +119,12 @@ test_expect_success 'directory becomes symlink' '
 test_debug 'cat patch'
 
 
+test_expect_success 'directory becomes symlink' '
+   git checkout -f foo-becomes-a-directory 
+   printf %s\n foo/baz foo order 
+   git diff-tree -Oorder -p HEAD foo-symlinked-to-bar patch 
+   git apply --index patch
+   '
+test_debug 'cat patch'
+
 test_done

It is a copy of the original, only forcing the patches in the input
in the opposite order.

Having said that and also having read your two-phase internal
application change, I think that two-phase thing is probably a good
way to go (we may even want to ignore previous_patch() stuff, as
its was_deleted() and tobe_deleted() are all about force the
application of a later patch to depend on the result of application
of an earlier patch).

--
To unsubscribe from this list: send the line 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] apply: refuse touching a file beyond symlink

[Jeff King]

On Thu, Jan 29, 2015 at 12:45:22PM -0800, Junio C Hamano wrote:

 +static int path_is_beyond_symlink(const char *name_)
 +{
 + struct strbuf name = STRBUF_INIT;
 +
 + strbuf_addstr(name, name_);
 + do {
 + struct patch *previous;
 +
 + while (--name.len  name.buf[name.len] != '/')
 + ; /* scan backwards */
 + if (!name.len)
 + break;

I imagine it is impossible here for name_ to be initially empty, but
it would make the backwards-scan loop go quite badly. Worth a comment or
an assert()?

 + name.buf[name.len] = '\0';
 + previous = in_fn_table(name.buf);
 + if (previous) {
 + if (!was_deleted(previous) 
 + !to_be_deleted(previous) 
 + previous-new_mode 
 + S_ISLNK(previous-new_mode))
 + goto symlink_found;
 + } else if (check_index) {
 + int pos = cache_name_pos(name.buf, name.len);
 + if (0 = pos 
 + S_ISLNK(active_cache[pos]-ce_mode))
 + goto symlink_found;
 + } else {
 + struct stat st;
 + if (!lstat(name.buf, st)  S_ISLNK(st.st_mode))
 + goto symlink_found;
 + }
 + } while (1);
 +
 + strbuf_release(name);
 + return 0;
 +symlink_found:
 + strbuf_release(name);
 + return 1;

Style nit, but might this be easier to follow the logic without the
gotos, by putting the setup and cleanup in a wrapper function and
returning directly from the main logic?

  static int path_is_beyond_symlink(const char *name)
  {
struct strbuf buf = STRBUF_INIT;
int ret;

strbuf_addstr(buf, name);
ret = path_is_beyond_symlink_1(name);
strbuf_release(buf);

return ret;
  }

I can live with it either way, though.

 + if (!patch-is_delete  path_is_beyond_symlink(patch-new_name))
 + return error(_(affected file '%s' is beyond a symbolic link),
 +  patch-new_name);

Why does this not kick in when deleting a file? If it is not OK to
add across a symlink, why is it OK to delete? IOW, why should this test
fail:

diff --git a/t/t4122-apply-symlink-inside.sh b/t/t4122-apply-symlink-inside.sh
index 0a8de4a..f03b604 100755
--- a/t/t4122-apply-symlink-inside.sh
+++ b/t/t4122-apply-symlink-inside.sh
@@ -64,6 +64,7 @@ test_expect_success SYMLINKS 'do not follow symbolic link 
(setup)' '
arch/x86_64/dir/file 
git add arch/x86_64/dir/file 
git diff HEAD add_file.patch 
+   git diff -R HEAD del_file.patch 
git reset --hard 
rm -fr arch/x86_64/dir 
 
@@ -111,7 +112,11 @@ test_expect_success SYMLINKS 'do not follow symbolic link 
(existing)' '
 
test_must_fail git apply --cached add_file.patch 2error-ct-file 
test_i18ngrep beyond a symbolic link error-ct-file 
-   test_must_fail git ls-files --error-unmatch arch/i386/dir
+   test_must_fail git ls-files --error-unmatch arch/i386/dir 
+
+   arch/i386/dir/file 
+   test_must_fail git apply del_file.patch 
+   test_path_is_file arch/i386/dir/file
 '
 
 test_done

 + test ! -e arch/x86_64/dir 
 + test ! -e arch/i386/dir/file 

Minor nit: use test_path_is_missing here (and elsewhere in the added
tests).

-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 2/1] apply: reject input that touches outside $cwd

[Junio C Hamano]

Jeff King p...@peff.net writes:

 It looks like your new --allow-uplevel goes to verify_path(). So this
 isn't just about .., but it will also protect against applying a patch
 inside .git. Which seems like a good thing to me, but I wonder if the
 option name is a little misleading.

True; not just misleading but is incorrect, I would say.
Suggestions?

 I agree they are orthogonal in concept, though I doubt the symlink tests
 here would pass without the previous one...

It won't; do not apply across symlinks is unconditional, and the
new codepath introduced by this patch, which is conditional to the
user option, shouldn't have to worry about them.

--
To unsubscribe from this list: send the line 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] apply: refuse touching a file beyond symlink

[Jeff King]

On Fri, Jan 30, 2015 at 11:48:14AM -0800, Junio C Hamano wrote:

 Jeff King p...@peff.net writes:
 
  +  if (!patch-is_delete  path_is_beyond_symlink(patch-new_name))
  +  return error(_(affected file '%s' is beyond a symbolic link),
  +   patch-new_name);
 
  Why does this not kick in when deleting a file? If it is not OK to
  add across a symlink, why is it OK to delete?
 
 Hmph, adding
 
   if (patch-is_delete  path_is_beyond_symlink(patch-old_name))
   return error(_(deleted file '%s' is beyond a symlink),
   patch-old_name);
 
 seems to break t4114.11, which wants to apply this patch to a tree
 that does not have a symbolic link but a directory at 'foo/'.
 
 diff --git a/foo b/foo
 new file mode 12
 index 000..ba0e162
 --- /dev/null
 +++ b/foo
 @@ -0,0 +1 @@
 +bar
 \ No newline at end of file
 diff --git a/foo/baz b/foo/baz
 deleted file mode 100644
 index 682c76b..000
 --- a/foo/baz
 +++ /dev/null
 @@ -1 +0,0 @@
 -if only I knew

Hrm. That only works in the current code because we apply the deletion
in the directory (and then clean up the now-empty directory) first. So I
think you would need to check the paths progressively as you apply them,
since those other parts of the diff haven't happened yet.

If we take deletion as one phase and addition as another, I think you
could get away with:

diff --git a/builtin/apply.c b/builtin/apply.c
index f5491cd..12c9d8e 100644
--- a/builtin/apply.c
+++ b/builtin/apply.c
@@ -3549,7 +3549,7 @@ static int check_to_create(const char *new_name, int 
ok_if_exists)
return 0;
 }
 
-static int path_is_beyond_symlink(const char *name_)
+static int path_is_beyond_symlink(const char *name_, int check_table)
 {
struct strbuf name = STRBUF_INIT;
 
@@ -3562,7 +3562,8 @@ static int path_is_beyond_symlink(const char *name_)
if (!name.len)
break;
name.buf[name.len] = '\0';
-   previous = in_fn_table(name.buf);
+
+   previous = check_table ? in_fn_table(name.buf) : NULL;
if (previous) {
if (!was_deleted(previous) 
!to_be_deleted(previous) 
@@ -3676,9 +3677,12 @@ static int check_patch(struct patch *patch)
}
}
 
-   if (!patch-is_delete  path_is_beyond_symlink(patch-new_name))
+   if (!patch-is_delete  path_is_beyond_symlink(patch-new_name, 1))
return error(_(affected file '%s' is beyond a symbolic link),
 patch-new_name);
+   if (patch-is_delete  path_is_beyond_symlink(patch-old_name, 0))
+   return error(_(affected file '%s' is beyond a symbolic link),
+patch-old_name);
 
if (apply_data(patch, st, ce)  0)
return error(_(%s: patch does not apply), name);


but I suspect we could construct a case that depends more closely on the
order of application. E.g., a patch that does:

  1. add foo as a symlink
  2. add file foo/bar

is definitely wrong. But is:

  1. add file foo/bar
  2. add foo as a symlink

does not technically fall afoul of the symlink rules. It is a _bogus_
patch, of course, because the second part will get a D/F conflict. I am
not sure if there are any legitimate patches that could run into this
ordering problem, but even without it, it smells a bit funny to complain
for the wrong reason.

Looking at the code, though, it seems like we should be doing these
checks progressively as we add entries to the fn_table. So that is doing
the right thing. It is only the deletion re-ordering that trips us up.
Can we reorder all deletions before all additions before calling
check_patch on each?

-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] apply: refuse touching a file beyond symlink

[Jeff King]

On Fri, Jan 30, 2015 at 12:11:30PM -0800, Junio C Hamano wrote:

 I am not sure how to fix this, without completely ripping out the
 misguided We should be able to concatenate outputs from multiple
 invocations of 'git diff' into a single file and apply the result
 with a single invocation of 'git apply' change I grudgingly
 accepted long time ago (7a07841c (git-apply: handle a patch that
 touches the same path more than once better, 2008-06-27).
 
 git diff output is designed each patch to apply independently to
 the preimage to produce the postimage, and that allows patches to
 two files can be swapped via -Oorderfile mechanism, and also X was
 created by copying from Y and Y is modified in place will result in
 X with the contents of Y in the preimage (i.e. before the in-place
 modification of Y in the same patch) regardless of the order of X
 and Y in the git diff output.  The above input used by t4114.11
 expects to remove 'foo/baz' (leaving an empty directory foo as an
 result but we do not track directories so it can be nuked to make
 room if other patch in the same input wants to put something else,
 either a regular file or a symbolic link, there) and create a blob
 at 'foo', and such an input should apply regardless of the order of
 patches in it.
 
 The in_fn_table[] stuff broke that design completely.

I had the impression that we did not apply in any arbitrary order that
could work, but rather that we did deletions first followed by
additions. But I am fairly ignorant of the apply code.

If that assumption is correct, then I think we could just follow the
same phases that the actual application does. Here's a hacky version
below. Probably the check of phase versus is_delete needs to be better
(and ideally the logic would be factored out of write_one_result so they
always match).

diff --git a/builtin/apply.c b/builtin/apply.c
index f5491cd..85364b8 100644
--- a/builtin/apply.c
+++ b/builtin/apply.c
@@ -3593,7 +3593,7 @@ symlink_found:
  * Check and apply the patch in-core; leave the result in patch-result
  * for the caller to write it out to the final destination.
  */
-static int check_patch(struct patch *patch)
+static int check_patch(struct patch *patch, int phase)
 {
struct stat st;
const char *old_name = patch-old_name;
@@ -3604,6 +3604,9 @@ static int check_patch(struct patch *patch)
int ok_if_exists;
int status;
 
+   if (!phase != patch-is_delete)
+   return 0;
+
patch-rejected = 1; /* we will drop this after we succeed */
 
status = check_preimage(patch, ce, st);
@@ -3679,6 +3682,9 @@ static int check_patch(struct patch *patch)
if (!patch-is_delete  path_is_beyond_symlink(patch-new_name))
return error(_(affected file '%s' is beyond a symbolic link),
 patch-new_name);
+   if (patch-is_delete  path_is_beyond_symlink(patch-old_name))
+   return error(_(affected file '%s' is beyond a symbolic link),
+patch-old_name);
 
if (apply_data(patch, st, ce)  0)
return error(_(%s: patch does not apply), name);
@@ -3686,7 +3692,7 @@ static int check_patch(struct patch *patch)
return 0;
 }
 
-static int check_patch_list(struct patch *patch)
+static int check_patch_list_1(struct patch *patch, int phase)
 {
int err = 0;
 
@@ -3695,12 +3701,22 @@ static int check_patch_list(struct patch *patch)
if (apply_verbosely)
say_patch_name(stderr,
   _(Checking patch %s...), patch);
-   err |= check_patch(patch);
+   err |= check_patch(patch, phase);
patch = patch-next;
}
return err;
 }
 
+static int check_patch_list(struct patch *patch)
+{
+   int err = 0;
+   int phase;
+
+   for (phase = 0; phase  2; phase++)
+   err |= check_patch_list_1(patch, phase);
+   return err;
+}
+
 /* This function tries to read the sha1 from the current index */
 static int get_current_sha1(const char *path, unsigned char *sha1)
 {
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/1] apply: reject input that touches outside $cwd

[Jeff King]

On Fri, Jan 30, 2015 at 11:07:34AM -0800, Junio C Hamano wrote:

 Jeff King p...@peff.net writes:
 
  It looks like your new --allow-uplevel goes to verify_path(). So this
  isn't just about .., but it will also protect against applying a patch
  inside .git. Which seems like a good thing to me, but I wonder if the
  option name is a little misleading.
 
 True; not just misleading but is incorrect, I would say.
 Suggestions?

I think just --verify-paths (and --no-verify-paths, since the former
would be the default) might be fine. That leaves the definition of
verify vague, but I think that's OK. It used to mean no '..' and no
'.git', and now it has been widened to include no weird
filesystem-specific variants of .git.

If you wanted to avoid the negative being the commonly used option,
maybe --unsafe-paths (or --allow-unsafe-paths if you like verbs).

-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] apply: refuse touching a file beyond symlink

[Junio C Hamano]

Junio C Hamano gits...@pobox.com writes:

 Jeff King p...@peff.net writes:

 +   if (!patch-is_delete  path_is_beyond_symlink(patch-new_name))
 +   return error(_(affected file '%s' is beyond a symbolic link),
 +patch-new_name);

 Why does this not kick in when deleting a file? If it is not OK to
 add across a symlink, why is it OK to delete?

 Hmph, adding

   if (patch-is_delete  path_is_beyond_symlink(patch-old_name))
   return error(_(deleted file '%s' is beyond a symlink),
   patch-old_name);

 seems to break t4114.11, which wants to apply this patch to a tree
 that does not have a symbolic link but a directory at 'foo/'.

 diff --git a/foo b/foo
 new file mode 12
 index 000..ba0e162
 --- /dev/null
 +++ b/foo
 @@ -0,0 +1 @@
 +bar
 \ No newline at end of file
 diff --git a/foo/baz b/foo/baz
 deleted file mode 100644
 index 682c76b..000
 --- a/foo/baz
 +++ /dev/null
 @@ -1 +0,0 @@
 -if only I knew


I am not sure how to fix this, without completely ripping out the
misguided We should be able to concatenate outputs from multiple
invocations of 'git diff' into a single file and apply the result
with a single invocation of 'git apply' change I grudgingly
accepted long time ago (7a07841c (git-apply: handle a patch that
touches the same path more than once better, 2008-06-27).

git diff output is designed each patch to apply independently to
the preimage to produce the postimage, and that allows patches to
two files can be swapped via -Oorderfile mechanism, and also X was
created by copying from Y and Y is modified in place will result in
X with the contents of Y in the preimage (i.e. before the in-place
modification of Y in the same patch) regardless of the order of X
and Y in the git diff output.  The above input used by t4114.11
expects to remove 'foo/baz' (leaving an empty directory foo as an
result but we do not track directories so it can be nuked to make
room if other patch in the same input wants to put something else,
either a regular file or a symbolic link, there) and create a blob
at 'foo', and such an input should apply regardless of the order of
patches in it.

The in_fn_table[] stuff broke that design completely.

--
To unsubscribe from this list: send the line 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] apply: refuse touching a file beyond symlink

[Jeff King]

On Fri, Jan 30, 2015 at 11:42:49AM -0800, Junio C Hamano wrote:

 Jeff King p...@peff.net writes:
 
  On Thu, Jan 29, 2015 at 12:45:22PM -0800, Junio C Hamano wrote:
 
  +  if (!patch-is_delete  path_is_beyond_symlink(patch-new_name))
  +  return error(_(affected file '%s' is beyond a symbolic link),
  +   patch-new_name);
 
  Why does this not kick in when deleting a file?
 
 Half-written logic, forgotten to be revisited (i.e. ok, anything
 that is not delete we can check new_name, so do that first, later
 we'd deal with deletion patch and I think the way to do so is by
 checking old_name, but let's make sure this case works first).

OK, I was worried I was missing something clever. :)

I agree that checking patch-old_name should work in that case.

-Peff
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] t9001: use older Getopt::Long boolean prefix '--no' rather than '--no-'

[Kyle J. McKay]

On Jan 30, 2015, at 15:05, brian m. carlson wrote:
 On Fri, Jan 30, 2015 at 07:24:45AM +0100, Tom G. Christensen wrote:
 The '--no-xmailer' option is a Getopt::Long boolean option. The
 '--no-' prefix (as in --no-xmailer) for boolean options is not
 supported in Getopt::Long version 2.32 which was released with Perl  
 5.8.0.
 This version only supports '--no' as in '--noxmailer'.  More recent
 versions of Getopt::Long, such as version 2.34, support either  
 prefix. So
 use the older form in the tests.

 See also:

 d2559f734bba7fe5257720356a92f3b7a5b0d37c
 907a0b1e04ea31cb368e9422df93d8ebb0187914
 84eeb687de7a6c7c42af3fb51b176e0f412a979e
 3fee1fe87144360a1913eab86af9ad136c810076

 Signed-off-by: Tom G. Christensen t...@statsbiblioteket.dk
 ---
 t/t9001-send-email.sh | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

 diff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh
 index af6a3e8..30df6ae 100755
 --- a/t/t9001-send-email.sh
 +++ b/t/t9001-send-email.sh
 @@ -1580,20 +1580,20 @@ do_xmailer_test () {

 test_expect_success $PREREQ '--[no-]xmailer without any  
 configuration' '
  do_xmailer_test 1 --xmailer 
 -do_xmailer_test 0 --no-xmailer
 +do_xmailer_test 0 --noxmailer

 I don't think this is an adequate fix.  The documented option is -- 
 no-xmailer.  If your version of Getopt::Long is not capable of that,  
 then the program doesn't work as documented, and the test is  
 correctly failing.  --noxmailer is not documented at all, so it's  
 not something we should be testing.

It is not alone.  From the git-send-email help these are all boolean  
options:

 git send-email

   Composing:
 --[no-]xmailer
 --[no-]annotate

   Automating:
 --[no-]cc-cover
 --[no-]to-cover
 --[no-]signed-off-by-cc
 --[no-]suppress-from
 --[no-]chain-reply-to
 --[no-]thread

   Administering:
 --[no-]validate
 --[no-]format-patch


Anything done to fix --no-xmailer should be applied for all the other  
--no-... options as well.

 We should probably require a certain version of Getopt::Long or  
 explicitly handle this in the parsing code itself.  I think the  
 former is a better choice, since no security-supported OS still  
 ships with such a positively ancient version.

I don't really like that second option because all the .perl files have:

 use 5.008;

So either that needs to change or the code should properly deal with  
the version of Getopt::Long that comes with 5.8.0.

Since it's really not very difficult or invasive to add support for  
the no- variants, here's a patch to do so:

-- 8 --
Subject: [PATCH] git-send-email.perl: support no- prefix with older GetOptions

Only Perl version 5.8.0 or later is required, but that comes with
an older Getopt::Long (2.32) that does not support the 'no-'
prefix.  Support for that was added in Getopt::Long version 2.33.

Since the help only mentions the 'no-' prefix and not the 'no'
prefix, add explicit support for the 'no-' prefix when running
with older GetOptions versions.

Reported-by: Tom G. Christensen t...@statsbiblioteket.dk
Signed-off-by: Kyle J. McKay mack...@gmail.com
---
 git-send-email.perl | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/git-send-email.perl b/git-send-email.perl
index 3092ab35..a18a7959 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -299,6 +299,7 @@ my $rc = GetOptions(h = \$help,
bcc=s = \@bcclist,
no-bcc = \$no_bcc,
chain-reply-to! = \$chain_reply_to,
+   no-chain-reply-to = sub {$chain_reply_to = 0},
smtp-server=s = \$smtp_server,
smtp-server-option=s = \@smtp_server_options,
smtp-server-port=s = \$smtp_server_port,
@@ -311,25 +312,34 @@ my $rc = GetOptions(h = \$help,
smtp-domain:s = \$smtp_domain,
identity=s = \$identity,
annotate! = \$annotate,
+   no-annotate = sub {$annotate = 0},
compose = \$compose,
quiet = \$quiet,
cc-cmd=s = \$cc_cmd,
suppress-from! = \$suppress_from,
+   no-suppress-from = sub {$suppress_from = 0},
suppress-cc=s = \@suppress_cc,
signed-off-cc|signed-off-by-cc! = \$signed_off_by_cc,
+   no-signed-off-cc|no-signed-off-by-cc = sub 
{$signed_off_by_cc = 0},
cc-cover|cc-cover! = \$cover_cc,
+   no-cc-cover = sub {$cover_cc = 0},
to-cover|to-cover! = \$cover_to,
+   no-to-cover = sub {$cover_to = 0},
confirm=s = \$confirm,
dry-run = \$dry_run,
envelope-sender=s = \$envelope_sender,
thread! = \$thread,
+   no-thread = sub {$thread = 0},
validate! = \$validate,
+   

Re: [PATCH] Makefile: Handle broken curl version number in version check

[Andreas Schwab]

Tom G. Christensen t...@statsbiblioteket.dk writes:

 diff --git a/Makefile b/Makefile
 index c44eb3a..69a2ce3 100644
 --- a/Makefile
 +++ b/Makefile
 @@ -1035,13 +1035,13 @@ else
   REMOTE_CURL_NAMES = $(REMOTE_CURL_PRIMARY) $(REMOTE_CURL_ALIASES)
   PROGRAM_OBJS += http-fetch.o
   PROGRAMS += $(REMOTE_CURL_NAMES)
 - curl_check := $(shell (echo 070908; curl-config --vernum) 2/dev/null | 
 sort -r | sed -ne 2p)
 + curl_check := $(shell (echo 070908; curl-config --vernum | sed -e 
 '/^70[B-C]/ s/^7/07/') 2/dev/null | sort -r | sed -ne 2p)

How about 's/^.$/0/' ?

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
And now for something completely different.
--
To unsubscribe from this list: send the line 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: implement a stable 'Last updated' in Documentation

[Jeff King]

On Fri, Jan 30, 2015 at 11:05:36AM +0100, Michael J Gruber wrote:

 It's a shame one can't simply replace the [footer-text] template which
 asciidoc insists on.
 
 It turns out asciidoc 8.6.9-3 and later will habe a knob to turn:
 
 https://github.com/asciidoc/asciidoc/pull/9
 
 I'll try and get my hands on it to see whether we can simply use that.
 I'm wondering though which is more useful - the version of the tree the
 doc is processed from, or the version of the last commit changing the
 corresponding doc source file. The first one changes even when the doc
 source is unchanged (but is stable between reruns, of course).

I have 8.6.9-3 installed (it is part of Debian testing/unstable now),
and confirmed that:

diff --git a/Documentation/asciidoc.conf b/Documentation/asciidoc.conf
index 2c16c53..10c777e 100644
--- a/Documentation/asciidoc.conf
+++ b/Documentation/asciidoc.conf
@@ -21,6 +21,7 @@ tilde=#126;
 apostrophe=#39;
 backtick=#96;
 litdd=#45;#45;
+footer-style=none
 
 ifdef::backend-docbook[]
 [linkgit-inlinemacro]

drops the last-updated footer.

But note that this only affects the generated HTML. The manpages still
get the date in their footer. But this isn't an asciidoc-ism at all;
it's added by docbook when converting the xml to roff. I'm sure there is
a way to tweak that, too, but looking at docbook gives me nightmares.

-Peff
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] Makefile: Handle broken curl version number in version check

[Tom G. Christensen]

curl 7.11.0 through 7.12.2 when built from their official release
archives will present a 5 digit version number instead of the documented
6 digits which breaks the version check in the Makefile.
Correct these broken version numbers on the fly when extracting them to
ensure the comparison works correctly.

Signed-off-by: Tom G. Christensen t...@statsbiblioteket.dk
---

This was discoved while building on RHEL4 which has curl 7.12.1.
The makefile check for curl = 7.34.0 failed and enabled
USE_CURL_FOR_IMAP_SEND.

# curl-config --vernum
70C01
# { echo 072200; curl-config --vernum 2/dev/null ; } | sort -r | sed -ne 2p
072200
#

I checked the curl release tarballs and this problem seems to exist for
curl 7.11.0 (0x70B00) through 7.12.2 (0x70C02). In both 7.10.7 (0x070a07)
and 7.12.3 (0x070c03) the version is correctly set using 6 hex digits as
documented.
I tried to verify this using the official curl repo on github but it does
not seem to record this discrepancy and shows the correct 6 digit version
numbers for the affected releases.

 Makefile | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Makefile b/Makefile
index c44eb3a..69a2ce3 100644
--- a/Makefile
+++ b/Makefile
@@ -1035,13 +1035,13 @@ else
REMOTE_CURL_NAMES = $(REMOTE_CURL_PRIMARY) $(REMOTE_CURL_ALIASES)
PROGRAM_OBJS += http-fetch.o
PROGRAMS += $(REMOTE_CURL_NAMES)
-   curl_check := $(shell (echo 070908; curl-config --vernum) 2/dev/null | 
sort -r | sed -ne 2p)
+   curl_check := $(shell (echo 070908; curl-config --vernum | sed -e 
'/^70[B-C]/ s/^7/07/') 2/dev/null | sort -r | sed -ne 2p)
ifeq $(curl_check) 070908
ifndef NO_EXPAT
PROGRAM_OBJS += http-push.o
endif
endif
-   curl_check := $(shell (echo 072200; curl-config --vernum) 2/dev/null | 
sort -r | sed -ne 2p)
+   curl_check := $(shell (echo 072200; curl-config --vernum | sed -e 
'/^70[B-C]/ s/^7/07/') 2/dev/null | sort -r | sed -ne 2p)
ifeq $(curl_check) 072200
USE_CURL_FOR_IMAP_SEND = YesPlease
endif
-- 
2.2.2

--
To unsubscribe from this list: send the line 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: Testsuite regression with perl 5.8.0 [Re: [ANNOUNCE] Git v2.3.0-rc2]

[Tom G. Christensen]

On 29/01/15 16:52, Jeff King wrote:

Both this and the curl-version issue you reported seem to have simple
solutions that you've already worked out and tested. Would you like to
express them in the form of patches so they can be applied? :)



Patches have been posted as requested.

-tgc
--
To unsubscribe from this list: send the line 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] apply: refuse touching a file beyond symlink

[Christian Couder]

On Thu, Jan 29, 2015 at 9:45 PM, Junio C Hamano gits...@pobox.com wrote:

 Instead, for any patch in the input that leaves a path (i.e. a non
 deletion) in the result, we check all leading paths against interim
 result and then either the index or the working tree.  The interim
 results of applying patches are kept track of by fn_table logic for
 us already, so use it to fiture out if existing a symbolic link will

s/fiture/figure/
s/existing a symbolic link/an existing symbolic link/

 cause problems, if a new symbolic link that will cause problems will
 appear, etc.
--
To unsubscribe from this list: send the line 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: implement a stable 'Last updated' in Documentation

[Michael J Gruber]

Junio C Hamano schrieb am 29.01.2015 um 07:18:
 Olaf Hering o...@aepfle.de writes:
 
 On Tue, Jan 27, Junio C Hamano wrote:

 What file timestamp should be used for them? Likely ../version?

 I tend to think the Last updated timestamp taken from the
 filesystem timestamp is a bad practice inherited by these tools from
 the days back when nobody used any revision control systems.

 I'm not sure. The bug is that such 'Last updated' line exists at all in
 the default output. Noone asked for it, noone really needs it. And it
 makes it impossible to get reproducible builds.
 
 Amen to that ;-)
 

It's a shame one can't simply replace the [footer-text] template which
asciidoc insists on.

It turns out asciidoc 8.6.9-3 and later will habe a knob to turn:

https://github.com/asciidoc/asciidoc/pull/9

I'll try and get my hands on it to see whether we can simply use that.
I'm wondering though which is more useful - the version of the tree the
doc is processed from, or the version of the last commit changing the
corresponding doc source file. The first one changes even when the doc
source is unchanged (but is stable between reruns, of course).

Michael
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html