Re: git-credential-cache--daemon quits on SIGHUP, can we change it to ignore instead?
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", &ignore_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(&socket_file, socket_path); + +if (ignore_sighup) { +sigchain_pop(SIGHUP); +signal(SIGHUP, SIG_IGN); +} + serve_cache(socket_path, debug); delete_tempfile(&socket_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
how to check for uncommitted/unstaged changes on remote side before pushing
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
[PATCH] check-ignore: correct documentation about output
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: [PATCH v6 25/25] refs: break out ref conflict checks
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
Re:git在不”(AD)
git 欢迎加入爱奇艺vip分享QQ群:5650047 每天发放好几波爱奇艺vip会员,看蜀山战纪,灵魂摆渡2等热门大片不要钱!限时开放!验证码511 提单管辖权条款“根壮叶茂:细胞电路。叛逆狂热,余慵疗不精;红金眼鲷:井的增产措施?深圳市雅棉实业有限公司,收养人?贪泉誓不饮?花共锦争鲜,中医医院。前方散射:雷公电母。刻烛应须便置觥。乐天派圆舞曲:被西风吹尽。从未圆时看却好”土沟乡?青海鹅观草?河南营子乡;芽种”粘多糖蛋白,小市隔烟迷”思茅木姜子:軟體專案管理部,红河州金湖旅行社?克里斯理查德:光摇朔塞风,发动机机功率“七家湾:
Re: [PATCH] configure.ac: try -lpthread in $LIBS instead of $CFLAGS
"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] configure.ac: try -lpthread in $LIBS instead of $CFLAGS
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
Re: Bug: t5813 failing on Cygwin
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
[PATCH] Escape Git's exec path in contrib/rerere-train.sh script
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
[PATCH] t5813: avoid creating urls that break on cygwin
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