[PATCH] configure.ac: try -lpthread in $LIBS instead of $CFLAGS

[Rainer M. Canavan]

Some linkers, namely the one on IRIX are rather strict concerning the order or
arguments for symbol resolution, i.e. no libraries listed before objects or
other libraries on the command line are considered for symbol resolution. That
means that -lpthread can't work if it's put in CFLAGS, because it will not be
considered for resolving pthread_key_create in conftest.o. Use $LIBS instead.

Signed-off-by: Rainer Canavan 
---
 configure.ac | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/configure.ac b/configure.ac
index fd22d41..1f55009 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1149,7 +1149,12 @@ elif test -z "$PTHREAD_CFLAGS"; then
   # would then trigger compiler warnings on every single file we compile.
   for opt in "" -mt -pthread -lpthread; do
  old_CFLAGS="$CFLAGS"
- CFLAGS="$opt $CFLAGS"
+ old_LIBS="$LIBS"
+ case "$opt" in
+-l*)  LIBS="$opt $LIBS" ;;
+*)CFLAGS="$opt $CFLAGS" ;;
+ esac
+
  AC_MSG_CHECKING([for POSIX Threads with '$opt'])
  AC_LINK_IFELSE([PTHREADTEST_SRC],
[AC_MSG_RESULT([yes])
@@ -1161,6 +1166,7 @@ elif test -z "$PTHREAD_CFLAGS"; then
],
[AC_MSG_RESULT([no])])
   CFLAGS="$old_CFLAGS"
+  LIBS="$old_LIBS"
   done
   if test $threads_found != yes; then
 AC_CHECK_LIB([pthread], [pthread_create],
-- 
2.6.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

[PATCH] Escape Git's exec path in contrib/rerere-train.sh script

[Daniel Knittl-Frank]

Whitespace can cause the source command to fail. This is usually not a
problem on Unix systems, but on Windows Git is likely to be installed
under "C:/Program Files/", thus rendering the script broken.

Signed-off-by: Daniel Knittl-Frank 
---
 contrib/rerere-train.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/contrib/rerere-train.sh b/contrib/rerere-train.sh
index 36b6fee..52ad9e4 100755
--- a/contrib/rerere-train.sh
+++ b/contrib/rerere-train.sh
@@ -7,7 +7,7 @@ USAGE="$me rev-list-args"
 
 SUBDIRECTORY_OK=Yes
 OPTIONS_SPEC=
-. $(git --exec-path)/git-sh-setup
+. "$(git --exec-path)/git-sh-setup"
 require_work_tree
 cd_to_toplevel
 
-- 
2.6.0.rc0.134.g48a2a2a

--
To unsubscribe from this list: send the line "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] configure.ac: try -lpthread in $LIBS instead of $CFLAGS

[Matthieu Moy]

"Rainer M. Canavan"  writes:

>  configure.ac | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)

Looks all right to me. Thanks for you contribution and for your
patience!

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] t5813: avoid creating urls that break on cygwin

[Dennis Kaarsemaker]

The fake ssh used by this test simply strips ssh://host from the url,
leaving paths behind that start with //, which cygwin interprets as UNC
paths, causing the test to fail.

We may want to actually fix this in git itself, making it remove extra
slashes from urls before feeding them to transports or helpers, but
that's for another topic as it could cause regressions.

Signed-off-by: Dennis Kaarsemaker 
---
 t/t5813-proto-disable-ssh.sh | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/t/t5813-proto-disable-ssh.sh b/t/t5813-proto-disable-ssh.sh
index ad877d7..a954ead 100755
--- a/t/t5813-proto-disable-ssh.sh
+++ b/t/t5813-proto-disable-ssh.sh
@@ -14,7 +14,7 @@ test_expect_success 'setup repository to clone' '
 '
 
 test_proto "host:path" ssh "remote:repo.git"
-test_proto "ssh://" ssh "ssh://remote/$PWD/remote/repo.git"
-test_proto "git+ssh://" ssh "git+ssh://remote/$PWD/remote/repo.git"
+test_proto "ssh://" ssh "ssh://remote$PWD/remote/repo.git"
+test_proto "git+ssh://" ssh "git+ssh://remote$PWD/remote/repo.git"
 
 test_done
-- 
2.6.3-495-gf0a7f49


-- 
Dennis Kaarsemaker 
http://twitter.com/seveas
--
To unsubscribe from this list: send the line "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: t5813 failing on Cygwin

[Ramsay Jones]

On 08/11/15 05:10, Jeff King wrote:
> On Sat, Nov 07, 2015 at 10:02:45PM +0100, Dennis Kaarsemaker wrote:
> 
>> Looks like lib-proto-disable.sh's fake SSH doesn't strip double leading
>> /'es from the path. Try this patch:
>>
>> diff --git a/t/t5813-proto-disable-ssh.sh b/t/t5813-proto-disable
>> -ssh.sh
>> index ad877d7..a954ead 100755
>> --- a/t/t5813-proto-disable-ssh.sh
>> +++ b/t/t5813-proto-disable-ssh.sh
>> @@ -14,7 +14,7 @@ test_expect_success 'setup repository to clone' '
>>  '
>>  
>>  test_proto "host:path" ssh "remote:repo.git"
>> -test_proto "ssh://" ssh "ssh://remote/$PWD/remote/repo.git"
>> -test_proto "git+ssh://" ssh "git+ssh://remote/$PWD/remote/repo.git"
>> +test_proto "ssh://" ssh "ssh://remote$PWD/remote/repo.git"
>> +test_proto "git+ssh://" ssh "git+ssh://remote$PWD/remote/repo.git"
>>  
>>  test_done
> 
> Good catch. It's a shame that the resulting URL becomes a little less
> readable, but given that the damage is limited to this one test, I think
> we can live with it. Working around it in the fake ssh script would
> probably end up unnecessarily complex.
> 
> We may want to have git itself remove extra slashes from URLs, as Ramsay
> suggested elsewhere, but I would worry about regressions. Let's solve
> this test portability problem by itself, and we can consider the other
> as a separate topic if anybody wants to pursue it.

Yep, this is essentially what I decided to do in a similar situation
back in 2011 (see commit 3a81f33c5).

Until I looked into that bug, I hadn't given any thought to whether
cygwin (let alone git) supported the UNC notation. At that time, I did
spend a little time trying to determine if it worked, but for some
reason I just couldn't get a network share configured properly.
It kept on giving me 'permission denied' errors - even using windows
only commands. :(

Since I have no need for network shares on cygwin, I didn't try too
hard ... I will leave it to people more motivated than me! ;-)

ATB,
Ramsay Jones


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

Re:git在不”(AD)

[dj]

git
欢迎加入爱奇艺vip分享QQ群：5650047 每天发放好几波爱奇艺vip会员，看蜀山战纪，灵魂摆渡2等热门大片不要钱！限时开放！验证码511


























































































































































































































































































































































































































































































































































































































































































































































































































































提单管辖权条款“根壮叶茂：细胞电路。叛逆狂热，余慵疗不精；红金眼鲷：井的增产措施？深圳市雅棉实业有限公司，收养人？贪泉誓不饮？花共锦争鲜，中医医院。前方散射：雷公电母。刻烛应须便置觥。乐天派圆舞曲：被西风吹尽。从未圆时看却好”土沟乡？青海鹅观草？河南营子乡；芽种”粘多糖蛋白，小市隔烟迷”思茅木姜子：軟體專案管理部，红河州金湖旅行社？克里斯理查德：光摇朔塞风，发动机机功率“七家湾：

how to check for uncommitted/unstaged changes on remote side before pushing

[Marc Haber]

Hi,

I am trying to abuse git as a code distribution channel and would like
to be able to trigger redistribution just by git push.

The idea is to push to a remote to the branch that is currently
checked out followed by a git reset --hard in the post-receive hook. I
have already figured out that I need to set receive.denyCurrentBranch
to ignore to be able to push to the currently checked out branch.

I am also aware that it is a good idea to git pull before git push
just in case there were local commits on the remote.

git reset --hard will unconditionally throw away local uncommitted
changes. I would like to detect this situation on the remote and abort
the receive progress. But my pre-receive hook does not work as
intended. Here is my code:

#!/bin/bash

echo "this is the pre-receive hook on $HOSTNAME"

if [ "$(git status --porcelain | wc -l)" -ne 0 ]; then
  echo "there are uncommitted changes"
  echo "PWD=$PWD"
  echo "git status --porcelain"
  git status --porcelain
  echo "end git status"
  exit 1
fi

When I invoke my hook from the remote, everything is fine:

mh@jessie:~/.stdacct$ .git/hooks/pre-receive
this is the pre-receive hook on jessie
there are uncommitted changes
PWD=/home/mh/.stdacct
git status --porcelain
 M dotfiles/.bashrc
 M hooks/pre-receive-hook
?? hooks/pre-receive-hook~
end git status
mh@jessie:~/.stdacct$ 

However, the output is different when invoked during a push:

[7/504]mh@swivel:~/git/stdacct$ git push jessie
Counting objects: 4, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (4/4), 363 bytes | 0 bytes/s, done.
Total 4 (delta 3), reused 0 (delta 0)
remote: this is the pre-receive hook on jessie
remote: there are uncommitted changes
remote: PWD=/home/mh/.stdacct/.git
remote: git status --porcelain
remote: ?? HEAD
remote: ?? ORIG_HEAD
remote: ?? config
remote: ?? description
remote: ?? hooks/applypatch-msg.sample
remote: ?? hooks/commit-msg.sample
remote: ?? hooks/post-receive
remote: ?? hooks/post-update.sample
remote: ?? hooks/pre-applypatch.sample
remote: ?? hooks/pre-commit.sample
remote: ?? hooks/pre-push.sample
remote: ?? hooks/pre-rebase.sample
remote: ?? hooks/pre-receive
remote: ?? hooks/prepare-commit-msg.sample
remote: ?? hooks/update.sample
remote: ?? index
remote: ?? index.lock
remote: ?? info/
remote: ?? logs/
remote: ?? objects/
remote: ?? refs/
remote: end git status
To ssh://jessie/home/mh/.stdacct
 ! [remote rejected] jessie -> jessie (pre-receive hook declined)
error: failed to push some refs to 'ssh://jessie/home/mh/.stdacct'

It looks like the hook thinks that it is invoked inside the .git/hooks
directory which is not considered part of the repository.

What is going wrong here?

If my entire approach is wrong, what is the recommended way to prevent
a repository with unstaged or uncommitted changes from being pushed to?

Greetings
Marc


-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421
--
To unsubscribe from this list: send the line "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 v6 25/25] refs: break out ref conflict checks

[Junio C Hamano]

Michael Haggerty  writes:

> I hate to cause the maintainer extra work. I guess I was making two
> naive assumptions:
>
> * If we make the code-movement series simple and "obviously correct"
>   enough, then it could be merged pretty much straight through to
>   master.
>
> * If one or two topics conflict with the code movement, they could
>   be one-time rebased on top of the new master (I would be willing
>   to do this work).
>
> Maybe neither of these assumptions is valid.

It is sometimes necessary to declare "This is important, and it is
solid enough. Let's fast-track it.  Other people must work on top of
this." and make a project-wide decision to do so.  It was just that
was not doable within the time I had before I had to hand the tree
off.

You can still work with the other people involved (Lukas as the
ref-is-hidden topic contributor and Peff as the interim maintainer)
to make it happen, and I wouldn't be upset.

> I can see a few ways that we could make our series even more
> straightforward:
>
> 1. Leave refs.c in its original location (as suggested by Junio).
>Optionally, it could be moved at a later date when this area is
>quiescent.
>
> 2. Move content selectively from refs.c to refs/files-backend.c rather
>than moving the whole file there and then moving content selectively
>back to refs/refs.c.
>
> 3. Separate *all* of the non-obvious changes into a preparatory
>patch series, to be followed by a separate patch series that *only*
>moves code.

4. Move everything in the series as-is, *BUT* in each patch where
the series moved things to refs/refs.c from refs/files-backend.c,
move that back to refs.c instead.  No refs/refs.c anywhere in the
history or in the endgame.

I think having refs.h and refs.c at the toplevel for the public
interface, with refs/ hierarchy holding backend specifics, would be
a good organization for the endgame regardless of the conflicts with
in-flight topics, and 4. achieves that.  Perhaps you meant the same
thing as your 1.

As to the reordering of functions and structure defs, I am
reasonably sure that the order in the final refs/refs.c in your
series would be better thought-out than in the original refs.c, so
the "reorder stuff in refs.c" can be the first step before
everything is moved to refs/files-backend.c, perhaps?

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

[PATCH] check-ignore: correct documentation about output

[Dennis Kaarsemaker]

By default git check-ignore shows only the filenames that will be
ignored, not the pattern that causes their exclusion.

Signed-off-by: Dennis Kaarsemaker 
---
 Documentation/git-check-ignore.txt | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/Documentation/git-check-ignore.txt 
b/Documentation/git-check-ignore.txt
index 59531ab..0a628ac 100644
--- a/Documentation/git-check-ignore.txt
+++ b/Documentation/git-check-ignore.txt
@@ -16,10 +16,9 @@ DESCRIPTION
 ---
 
 For each pathname given via the command-line or from a file via
-`--stdin`, show the pattern from .gitignore (or other input files to
-the exclude mechanism) that decides if the pathname is excluded or
-included.  Later patterns within a file take precedence over earlier
-ones.
+`--stdin`, check whether the file is excluded by .gitignore (or other
+input files to the exclude mechanism) and output the path if it is
+excluded.
 
 By default, tracked files are not shown at all since they are not
 subject to exclude rules; but see `--no-index'.
-- 
2.6.3-495-gf0a7f49


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

Re: git-credential-cache--daemon quits on SIGHUP, can we change it to ignore instead?

[Noam Postavsky]

On Fri, Oct 30, 2015 at 5:08 PM, Jeff King  wrote:
> Right. And not only is that hard to get right (I doubt, for example, you
> support the arbitrary "!" shell expressions that git does), but it's
> impossible to know for sure that will be needed, because you cannot know
> all possible helpers (I might even have a helper that is a shell snippet
> that calls credential-cache).

Yep, in that case the user would have to override the result of parsing.

>> Ah, maybe the missing piece I forgot to mention is that we could make
>> our pre/1st-helper be an emacsclient command, which would tell Emacs
>> to startup the daemon. So the daemon would be a subprocess of Emacs,
>> not "git push", thereby avoiding the SIGHUP. In our current workaround
>> we startup the daemon (if it's not running) before git commands that
>> we think are going to run credential helpers (i.e. "push", "pull",
>> "fetch"), hence my thought that it would be nicer if we only did that
>> before git is *actually* going to run the helpers.
>
> I don't think even git knows it will need a helper until it is actually
> ready to call one (e.g., it may depend on getting an HTTP 401 from the
> server).

Yes, so just call me first. :)

>
> I am leaning more towards ignoring SIGHUP (configurably) being the only
> really sane path forward. Do you want to try your hand at a patch?

Something like this?

diff --git i/credential-cache--daemon.c w/credential-cache--daemon.c
index eef6fce..e3f2612 100644
--- i/credential-cache--daemon.c
+++ w/credential-cache--daemon.c
@@ -256,6 +256,9 @@ int main(int argc, const char **argv)
 OPT_END()
 };

+int ignore_sighup = 0;
+git_config_get_bool("credential.cache.ignoreSighup", _sighup);
+
 argc = parse_options(argc, argv, NULL, options, usage, 0);
 socket_path = argv[0];

@@ -264,6 +267,12 @@ int main(int argc, const char **argv)

 check_socket_directory(socket_path);
 register_tempfile(_file, socket_path);
+
+if (ignore_sighup) {
+sigchain_pop(SIGHUP);
+signal(SIGHUP, SIG_IGN);
+}
+
 serve_cache(socket_path, debug);
 delete_tempfile(_file);
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html