* Re: [feature request] git add completion should exclude staged content
From: Manlio Perillo @ 2013-01-30 19:58 UTC (permalink / raw)
To: Marc Khouzam
Cc: 'Junio C Hamano', 'Michael J Gruber',
'wookietreiber', 'git@vger.kernel.org'
In-Reply-To: <E59706EF8DB1D147B15BECA3322E4BDC097E39@eusaamb103.ericsson.se>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Il 30/01/2013 19:55, Marc Khouzam ha scritto:
> [...]
>>>> The new logic in git-completion.bash tells bash that 'filenames'
>>>> completion is ongoing so bash will add a '/' after directories.
>>>> Sadly, tcsh won't do that, so it would be simpler if
>>>> git-completion.bash added the '/' itself. I looked at the
>>>> git-completion.bash script changes and I noticed that for
>>>> bash version < 4, you have to add the '/' yourself.
>
> The compatible version is not only required for Bash; you can
> use it for
> other shells.
>
> Try to redefine the __git_index_file_list_filter function to use the
> version that adds a slash to directory names.
>
>> I hadn't thought of that!
>> Although I would prefer not to have special cases like that,
>> it does work well.
The zsh compatible code does something like this; this is the reason I
tried to do the same thing, in order to keep coding consistent.
> [...]
>
> Bash 4.1.5(1) always adds an additional slash for directories.
> I have tested it right now: change the filter function to use the
> compatible version:
>
> __git_index_file_list_filter ()
> {
> # Default to Bash >= 4.x
> __git_index_file_list_filter_compat
> }
>
>
> Then running `git add <TAB>` inside the git repository, I get
> this file
> completion list:
>
> $ git add <TAB>
> contrib//
>
>> Ok, I see. The double-slash is visible in the completion list
>> but it does not appear on the command-line when bash automatically
>> adds it.
Right; that's why I wrote in the comment that Bash behaviour "seems" stupid.
But probably that comment should be remove or changed for the final
version of the patch; I'll leave that to a Bash expert.
> [...]
Regards Manlio
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAlEJe0kACgkQscQJ24LbaUScGgCeMDDdprJMgnYtFzqnFQamhfvU
BikAniMkwbOEVkkomOd9G0m3KY44f/9O
=c8rC
-----END PGP SIGNATURE-----
^ permalink raw reply
* [PATCH 0/3] mergetool: add user configured commands to '--tool-help'
From: John Keeping @ 2013-01-30 19:55 UTC (permalink / raw)
To: git; +Cc: David Aguilar, Junio C Hamano
The first couple of these are fixups to da/mergetool-docs. I think the
first one's obvious, but the second one should possible be changed into
an incremental patch on top. I did it this way for now since that patch
is basically my comments in [1] in patch form.
The final patch adds tools from git-config to the '--tool-help' output.
[1] http://article.gmane.org/gmane.comp.version-control.git/214964
John Keeping (3):
fixup! mergetool--lib: add functions for finding available tools
fixup! doc: generate a list of valid merge tools
mergetool--lib: list user configured tools in '--tool-help'
git-mergetool--lib.sh | 82 +++++++++++++++++++++++++++++++++++++++------------
1 file changed, 63 insertions(+), 19 deletions(-)
--
1.8.1.1
^ permalink raw reply
* [PATCH 2/3] fixup! doc: generate a list of valid merge tools
From: John Keeping @ 2013-01-30 19:55 UTC (permalink / raw)
To: git; +Cc: David Aguilar, Junio C Hamano
In-Reply-To: <cover.1359575447.git.john@keeping.me.uk>
Signed-off-by: John Keeping <john@keeping.me.uk>
---
git-mergetool--lib.sh | 40 ++++++++++++++++++++++------------------
1 file changed, 22 insertions(+), 18 deletions(-)
diff --git a/git-mergetool--lib.sh b/git-mergetool--lib.sh
index b6ed2fa..b44a2c8 100644
--- a/git-mergetool--lib.sh
+++ b/git-mergetool--lib.sh
@@ -22,6 +22,7 @@ is_available () {
show_tool_names () {
condition=${1:-true} per_line_prefix=${2:-} preamble=${3:-}
+ not_found_msg=${4:-}
shown_any=
( cd "$MERGE_TOOLS_DIR" && ls ) | {
@@ -32,13 +33,19 @@ show_tool_names () {
then
if test -n "$preamble"
then
- echo "$preamble"
+ printf "%s\n" "$preamble"
preamble=
fi
shown_any=yes
printf "%s%s\n" "$per_line_prefix" "$toolname"
fi
done
+
+ if test -n "$preamble" && test -n "$not_found_msg"
+ then
+ printf "%s\n" "$not_found_msg"
+ fi
+
test -n "$shown_any"
}
}
@@ -242,30 +249,27 @@ list_merge_tool_candidates () {
show_tool_help () {
tool_opt="'git ${TOOL_MODE}tool --tool-<tool>'"
- tab=' ' av_shown= unav_shown=
+ tab=' '
+ LF='
+'
+ any_shown=no
cmd_name=${TOOL_MODE}tool
- if show_tool_names 'mode_ok && is_available' "$tab$tab" \
- "$tool_opt may be set to one of the following:"
- then
- av_shown=yes
- else
- echo "No suitable tool for 'git $cmd_name --tool=<tool>' found."
- av_shown=no
- fi
+ show_tool_names 'mode_ok && is_available' "$tab$tab" \
+ "$tool_opt may be set to one of the following:" \
+ "No suitable tool for 'git $cmd_name --tool=<tool>' found." &&
+ any_shown=yes
- if show_tool_names 'mode_ok && ! is_available' "$tab$tab" \
- "The following tools are valid, but not currently available:"
- then
- unav_shown=yes
- fi
+ show_tool_names 'mode_ok && ! is_available' "$tab$tab" \
+ "${LF}The following tools are valid, but not currently available:" &&
+ any_shown=yes
- case ",$av_shown,$unav_shown," in
- *,yes,*)
+ if test "$any_shown" = yes
+ then
echo
echo "Some of the tools listed above only work in a windowed"
echo "environment. If run in a terminal-only session, they will fail."
- esac
+ fi
exit 0
}
--
1.8.1.1
^ permalink raw reply related
* Re: [PATCH] git_remote_helpers: remove GIT-PYTHON-VERSION upon "clean"
From: John Keeping @ 2013-01-30 20:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vzjzqjwot.fsf@alter.siamese.dyndns.org>
On Wed, Jan 30, 2013 at 11:30:10AM -0800, Junio C Hamano wrote:
> fadf8c7 (git_remote_helpers: force rebuild if python version changes, 2013-01-20)
> started using a marker file to keep track of the version of Python interpreter
> used for the last build, but forgot to remove it when asked to "make clean".
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Looks obviously correct to me. Sorry for missing this at the time.
FWIW:
Reviewed-by: John Keeping <john@keeping.me.uk>
> ---
> git_remote_helpers/Makefile | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/git_remote_helpers/Makefile b/git_remote_helpers/Makefile
> index 0d2ae74..3d12232 100644
> --- a/git_remote_helpers/Makefile
> +++ b/git_remote_helpers/Makefile
> @@ -42,4 +42,4 @@ instlibdir: $(pysetupfile)
>
> clean:
> $(QUIET)$(PYTHON_PATH) $(pysetupfile) $(QUIETSETUP) clean -a
> - $(RM) *.pyo *.pyc
> + $(RM) *.pyo *.pyc GIT-PYTHON-VERSION
^ permalink raw reply
* git-remote-helpers.txt: should it be gitremote-helpers.txt?
From: John Keeping @ 2013-01-30 20:11 UTC (permalink / raw)
To: git
Max Horn's email today prompted me to try reading the git-remote-helpers
man page, so I tried:
$ git help remote-helpers
No manual entry for gitremote-helpers
But "man git-remote-helpers" does work.
It turns out that "builtin/help.c" maps its argument to a page by
prepending "git-" if given the name of a Git command and "git"
otherwise.
Does this mean that "git-remote-helpers.txt" should lose the first
hyphen or is help.c not being clever enough in some way?
John
^ permalink raw reply
* Re: [PATCH 1/3] fixup! mergetool--lib: add functions for finding available tools
From: Junio C Hamano @ 2013-01-30 20:23 UTC (permalink / raw)
To: John Keeping; +Cc: git, David Aguilar
In-Reply-To: <2c7dec096455e6e43d2e9aa28668f69a26f3d5f9.1359575447.git.john@keeping.me.uk>
John Keeping <john@keeping.me.uk> writes:
> Signed-off-by: John Keeping <john@keeping.me.uk>
> ---
> git-mergetool--lib.sh | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
Thanks.
> diff --git a/git-mergetool--lib.sh b/git-mergetool--lib.sh
> index 25631cd..b6ed2fa 100644
> --- a/git-mergetool--lib.sh
> +++ b/git-mergetool--lib.sh
> @@ -34,9 +34,9 @@ show_tool_names () {
> then
> echo "$preamble"
> preamble=
> - shown_any=yes
> fi
> - printf "%s%s\n" "$per_line_prefix" "$tool"
> + shown_any=yes
> + printf "%s%s\n" "$per_line_prefix" "$toolname"
Thanks for spotting s/tool/toolname/; does the change to shown_any
matter, though?
> fi
> done
> test -n "$shown_any"
> @@ -244,6 +244,7 @@ show_tool_help () {
>
> tab=' ' av_shown= unav_shown=
>
> + cmd_name=${TOOL_MODE}tool
> if show_tool_names 'mode_ok && is_available' "$tab$tab" \
> "$tool_opt may be set to one of the following:"
> then
^ permalink raw reply
* Re: git-remote-helpers.txt: should it be gitremote-helpers.txt?
From: Junio C Hamano @ 2013-01-30 20:28 UTC (permalink / raw)
To: John Keeping; +Cc: git
In-Reply-To: <20130130201102.GM1342@serenity.lan>
John Keeping <john@keeping.me.uk> writes:
> Max Horn's email today prompted me to try reading the git-remote-helpers
> man page, so I tried:
>
> $ git help remote-helpers
> No manual entry for gitremote-helpers
>
> But "man git-remote-helpers" does work.
>
> It turns out that "builtin/help.c" maps its argument to a page by
> prepending "git-" if given the name of a Git command and "git"
> otherwise.
>
> Does this mean that "git-remote-helpers.txt" should lose the first
> hyphen or is help.c not being clever enough in some way?
I think it is the former. "git help tutorial" works exactly the
same way.
^ permalink raw reply
* Re: [RFC/PATCH v2] CodingGuidelines: add Python coding guidelines
From: John Keeping @ 2013-01-30 20:31 UTC (permalink / raw)
To: Michael Haggerty; +Cc: git
In-Reply-To: <5108F056.9040406@alum.mit.edu>
On Wed, Jan 30, 2013 at 11:05:10AM +0100, Michael Haggerty wrote:
> Nit: s/it is supported/it has been supported/
Thanks, I'll fix in the re-roll.
> I think this would be a good Python policy.
>
> I would hate to junk up all Python code with things like
>
> ' '.encode('ascii')
>
> though, so maybe we should establish a small Python library of
> compatibility utilities (like a small "six"). It could contain b().
>
> Another handy utility function could be
>
> def check_python_version(minimum_v2=0x02060000,
> minimum_v3=0x03010000)
>
> which checks our default Python requirements by default, but is
> overrideable by specific scripts if they know that they can deal with
> older Python versions.
>
> But I haven't had time to think of where to put such a library, how to
> install it, etc.
If we want to go that route, I think restructuring the
"git_remote_helpers" directory and re-using its infrastructure for
installing the "Git Python modules" would be the way to go. The
directory structure would become something like this:
git/
`-- python/
|-- Makefile # existing file pulled out of git_remote_helpers
|-- < some new utility library >
|-- git_remote_helpers
| |-- __init__.py
| |-- git
| | |-- __init__.py
| | |-- exporter.py
| | |-- git.py
| | |-- importer.py
| | |-- non_local.py
| | `-- repo.py
| `-- util.py
|-- setup.cfg # existing file pulled out of git_remote_helpers
`-- setup.py # existing file pulled out of git_remote_helpers
It looks like the GitPython project[1] as already taken the "git" module
name, so perhaps we should use "git_core" if we do introduce a new
module.
[1] http://pypi.python.org/pypi/GitPython
John
^ permalink raw reply
* Re: [PATCH 1/3] fixup! mergetool--lib: add functions for finding available tools
From: John Keeping @ 2013-01-30 20:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, David Aguilar
In-Reply-To: <7vk3quju7t.fsf@alter.siamese.dyndns.org>
On Wed, Jan 30, 2013 at 12:23:34PM -0800, Junio C Hamano wrote:
> > diff --git a/git-mergetool--lib.sh b/git-mergetool--lib.sh
> > index 25631cd..b6ed2fa 100644
> > --- a/git-mergetool--lib.sh
> > +++ b/git-mergetool--lib.sh
> > @@ -34,9 +34,9 @@ show_tool_names () {
> > then
> > echo "$preamble"
> > preamble=
> > - shown_any=yes
> > fi
> > - printf "%s%s\n" "$per_line_prefix" "$tool"
> > + shown_any=yes
> > + printf "%s%s\n" "$per_line_prefix" "$toolname"
>
> Thanks for spotting s/tool/toolname/; does the change to shown_any
> matter, though?
Not really since we don't call it with an empty "$preamble" but if
something ever did then this ensures that shown_any is set correctly.
The $tool -> $toolname doesn't really matter either since setup_tool
sets it as a global variable, but I'd rather not rely on that.
> > fi
> > done
> > test -n "$shown_any"
> > @@ -244,6 +244,7 @@ show_tool_help () {
> >
> > tab=' ' av_shown= unav_shown=
> >
> > + cmd_name=${TOOL_MODE}tool
> > if show_tool_names 'mode_ok && is_available' "$tab$tab" \
> > "$tool_opt may be set to one of the following:"
> > then
^ permalink raw reply
* [PATCH v3] CodingGuidelines: add Python coding guidelines
From: John Keeping @ 2013-01-30 20:47 UTC (permalink / raw)
To: git; +Cc: Michael Haggerty, Junio C Hamano
These are kept short by simply deferring to PEP-8. Most of the Python
code in Git is already very close to this style (some things in contrib/
are not).
Rationale for version suggestions:
- Amongst the noise in [1], there isn't any disagreement about using
2.6 as a base (see also [2]), although Brandon Casey recently added
support for 2.4 and 2.5 to git-p4 [3].
- Restricting ourselves to 2.6+ makes aiming for Python 3 compatibility
significantly easier [4].
- Advocating Python 3 support in all scripts is currently unrealistic
because:
- 'p4 -G' provides output in a format that is very hard to use with
Python 3 (and its documentation claims Python 3 is unsupported).
- Mercurial does not support Python 3.
- Bazaar does not support Python 3.
- But we should try to make new scripts compatible with Python 3
because all new Python development is happening on version 3 and the
Python community will eventually stop supporting Python 2 [5].
- Python 3.1 is required to support the 'surrogateescape' error handler
for encoding/decodng filenames to/from Unicode strings and Python 3.0
is not longer supported.
[1] http://thread.gmane.org/gmane.comp.version-control.git/210329
[2] http://article.gmane.org/gmane.comp.version-control.git/210429
[3] http://thread.gmane.org/gmane.comp.version-control.git/214579
[4] http://docs.python.org/3.3/howto/pyporting.html#try-to-support-python-2-6-and-newer-only
[5] http://www.python.org/dev/peps/pep-0404/
---
Changes since v2:
- Tone down discussion of the byte string prefix.
- Change "is supported since" to "has been supported since".
Documentation/CodingGuidelines | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines
index 69f7e9b..432c6cd 100644
--- a/Documentation/CodingGuidelines
+++ b/Documentation/CodingGuidelines
@@ -179,6 +179,20 @@ For C programs:
- Use Git's gettext wrappers to make the user interface
translatable. See "Marking strings for translation" in po/README.
+For Python scripts:
+
+ - We follow PEP-8 (http://www.python.org/dev/peps/pep-0008/).
+
+ - As a minimum, we aim to be compatible with Python 2.6 and 2.7.
+
+ - Where required libraries do not restrict us to Python 2, we try to
+ also be compatible with Python 3.1 and later.
+
+ - When you must differentiate between Unicode literals and byte string
+ literals, it is OK to use the 'b' prefix. Even though the Python
+ documentation for version 2.6 does not mention this prefix, it has
+ been supported since version 2.6.0.
+
Writing Documentation:
Every user-visible change should be reflected in the documentation.
--
1.8.1.2.633.gbba9ccc
^ permalink raw reply related
* Re: "sha1 information is lacking or useless" when rebasing with a submodule pointer conflict
From: Heiko Voigt @ 2013-01-30 21:56 UTC (permalink / raw)
To: Michael Sims; +Cc: git, Jens Lehmann
In-Reply-To: <CAFyOhY8YAO4zx6jKQxrEW=-Vbo-TTjU6wJ7UgNVEjA7B2dasng@mail.gmail.com>
Hi,
On Wed, Jan 30, 2013 at 12:43:31PM -0600, Michael Sims wrote:
> I'm seeing what might be a bug that was introduced in git 1.7.12 (also
> observed in 1.8.1.2). If not a bug, it's a changed behavior from
> previous versions that I don't understand.
>
> Here's the scenario:
> * I have a remote repo containing a pointer to a submodule.
> * Developer A and Developer B clone this repo, and both make a commit
> to first the submodule, and then the parent repo, changing some files
> and also the submodule pointer at the same time.
> * Developer A pushes his changes to both the submodule and the parent
> module to the shared remote
> * Developer B either does a "git pull --rebase" or a "git fetch && git
> rebase origin/master"
Thanks for the detailed bug report and the demo script. I can reproduce
the behavior here and will have a look into it. The submodule should be
marked as conflict.
Cheers Heiko
^ permalink raw reply
* Re: [BUG] incorrect search result returned when using git log with a future date parameter
From: Jonathan Nieder @ 2013-01-30 22:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Caspar Zhang, git, Gris Ge
In-Reply-To: <7vsj5ijvei.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> When it is fed 2013-02-12, it is ambiguous and "approxidate" can and
> should use whatever heuristics (including rejection of future) to
> guess what the user wanted, but 2013-02-13 cannot be interpreted in
> any other way, so we should parse it as such.
FWIW, if you said 02/12/2013, I'd agree, but I've never seen someone
using 2013-02-12 to mean December 2.
So that suggests another possible tweak on top. :)
Thanks,
Jonathan
^ permalink raw reply
* Re: [BUG] incorrect search result returned when using git log with a future date parameter
From: Junio C Hamano @ 2013-01-30 22:22 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Caspar Zhang, git, Gris Ge
In-Reply-To: <20130130221544.GA15680@google.com>
Jonathan Nieder <jrnieder@gmail.com> writes:
>> When it is fed 2013-02-12, it is ambiguous and "approxidate" can and
>> should use whatever heuristics (including rejection of future) to
>> guess what the user wanted, but 2013-02-13 cannot be interpreted in
>> any other way, so we should parse it as such.
>
> FWIW, if you said 02/12/2013, I'd agree, but I've never seen someone
> using 2013-02-12 to mean December 2.
>
> So that suggests another possible tweak on top. :)
I think in the original context that triggered the "be more friendly
to Europeans" discussion long time ago, some correlations between
the delimiting characters (i.e. 'xxxx-xx-xx' vs 'xxxx.xx.xx' vs
'xxxx/xx/xx') and month-day ordering convention. I do not recall if
we actually added that as a signal when disambiguating, though.
^ permalink raw reply
* Re: Re: "sha1 information is lacking or useless" when rebasing with a submodule pointer conflict
From: Heiko Voigt @ 2013-01-30 22:49 UTC (permalink / raw)
To: Michael Sims; +Cc: git, Jens Lehmann, Junio C Hamano, Martin von Zweigbergk
In-Reply-To: <20130130215615.GA1053@book.hvoigt.net>
Hi,
On Wed, Jan 30, 2013 at 10:56:15PM +0100, Heiko Voigt wrote:
> On Wed, Jan 30, 2013 at 12:43:31PM -0600, Michael Sims wrote:
> > I'm seeing what might be a bug that was introduced in git 1.7.12 (also
> > observed in 1.8.1.2). If not a bug, it's a changed behavior from
> > previous versions that I don't understand.
> >
> > Here's the scenario:
> > * I have a remote repo containing a pointer to a submodule.
> > * Developer A and Developer B clone this repo, and both make a commit
> > to first the submodule, and then the parent repo, changing some files
> > and also the submodule pointer at the same time.
> > * Developer A pushes his changes to both the submodule and the parent
> > module to the shared remote
> > * Developer B either does a "git pull --rebase" or a "git fetch && git
> > rebase origin/master"
>
> Thanks for the detailed bug report and the demo script. I can reproduce
> the behavior here and will have a look into it. The submodule should be
> marked as conflict.
Bisect identified the following commit:
commit a230949409f4a650c6a1a9a5879e2a8b993ba695 (HEAD)
Author: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>
Date: Tue Jun 26 07:51:56 2012 -0700
am --rebasing: get patch body from commit, not from mailbox
Rebasing a commit that contains a diff in the commit message results
in a failure with output such as
First, rewinding head to replay your work on top of it...
Applying: My cool patch.
fatal: sha1 information is lacking or useless
(app/controllers/settings_controller.rb).
Repository lacks necessary blobs to fall back on 3-way merge.
Cannot fall back to three-way merge.
Patch failed at 0001 My cool patch.
The reason is that 'git rebase' without -p/-i/-m internally calls 'git
format-patch' and pipes the output to 'git am --rebasing', which has
no way of knowing what is a real patch and what is a commit message
that contains a patch.
Make 'git am' while in --rebasing mode get the patch body from the
commit object instead of extracting it from the mailbox.
Patch by Junio, test case and commit log message by Martin.
Reported-by: anikey <arty.anikey@gmail.com>
Helped-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Maybe Martin or Junio immediately see whats going wrong here? I would
need to further dig into the git-am code to find out how to fix it.
Cheers Heiko
^ permalink raw reply
* Re: Anybody know a website with up-to-date git documentation?
From: Sitaram Chamarty @ 2013-01-30 23:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Max Horn, John Keeping, git, Scott Chacon
In-Reply-To: <7vlibalhcv.fsf@alter.siamese.dyndns.org>
On Wed, Jan 30, 2013 at 09:18:24AM -0800, Junio C Hamano wrote:
> Max Horn <max@quendi.de> writes:
>
> [administrivia: please wrap lines to a reasonable width]
Curiously, gmail's web interface appears to have started doing
this only recently. I've noticed it when trying to respond to
others too.
> > On 30.01.2013, at 16:59, Sitaram Chamarty wrote:
> >
> >> I'm curious... what's wrong with 'git checkout html' from the git repo
> >> and just browsing them using a web browser?
> >
> > Hm, do you mean "make html", perhaps? At least I couldn't figure
> > out what "git checkout html" should do, but out of curiosity gave
> > it a try and got an error...
>
> Perhaps some information from "A note from the maintainer" (posted
> to this list from time to time) is lacking. Some excerpts:
>
> You can browse the HTML manual pages at:
>
> http://git-htmldocs.googlecode.com/git/git.html
>
> Preformatted documentation from the tip of the "master" branch can be
> found in:
>
> git://git.kernel.org/pub/scm/git/git-{htmldocs,manpages}.git/
> git://repo.or.cz/git-{htmldocs,manpages}.git/
> ...
>
>
> Armed with that knowledge, I think Sitaram may have something like
> this:
>
> [remote "htmldocs"]
> url = git://git.kernel.org/pub/scm/git/git-htmldocs.git/
> fetch = +refs/heads/master:refs/heads/html
>
> and does
>
> git fetch htmldocs
> git checkout html
Hmm; I don't recall ever doing that. But I just realised that
my "html" branch is stuck at 1.7.7:
$ git branch -v -v | grep html
html 8fb66e5 [origin/html] Autogenerated HTML docs for v1.7.7-138-g7f41b6
Is it possible that upto that point, the main git.git repo did
carry this branch also? I have 3 remotes:
$ git remote -v
gc https://code.google.com/p/git-core (fetch)
gc https://code.google.com/p/git-core (push)
ghgit git://github.com/git/git.git (fetch)
ghgit git://github.com/git/git.git (push)
origin git://git.kernel.org/pub/scm/git/git.git (fetch)
origin git://git.kernel.org/pub/scm/git/git.git (push)
and all 3 of them carry this branch:
$ git branch -a -v -v | grep html
html 8fb66e5 [origin/html] Autogenerated HTML docs for v1.7.7-138-g7f41b6
remotes/gc/html 8fb66e5 Autogenerated HTML docs for v1.7.7-138-g7f41b6
remotes/ghgit/html 8fb66e5 Autogenerated HTML docs for v1.7.7-138-g7f41b6
remotes/origin/html 8fb66e5 Autogenerated HTML docs for v1.7.7-138-g7f41b6
Even if I had, at one point, added a remote specifically for
html, I am sure it could not have created those refs!
So I tried a prune:
$ git remote update --prune
Fetching origin
x [deleted] (none) -> origin/html
x [deleted] (none) -> origin/man
Fetching ghgit
x [deleted] (none) -> ghgit/html
x [deleted] (none) -> ghgit/man
Fetching gc
x [deleted] (none) -> gc/html
x [deleted] (none) -> gc/man
and now I'm on par with the rest of you ;-)
> You can, too, of course ;-)
You can do even more! If you don't find a suitable website for
this, it's trivial to host it yourself. You can host it on your
intranet, if you have one.
^ permalink raw reply
* Re: "sha1 information is lacking or useless" when rebasing with a submodule pointer conflict
From: Junio C Hamano @ 2013-01-30 23:39 UTC (permalink / raw)
To: Heiko Voigt; +Cc: Michael Sims, git, Jens Lehmann, Martin von Zweigbergk
In-Reply-To: <20130130224904.GB1053@book.hvoigt.net>
Heiko Voigt <hvoigt@hvoigt.net> writes:
> Maybe Martin or Junio immediately see whats going wrong here? I would
> need to further dig into the git-am code to find out how to fix it.
"am -3" has never worked on a patch that describes changes to any
non-blobs; the underlyihng "apply --fake-ancestor" is not prepared
to see anything other than blobs.
^ permalink raw reply
* Re: [PATCH] The images from picon and gravatar are always used over http://, and browsers give mixed contents warning when gitweb is served over https://.
From: Jonathan Nieder @ 2013-01-31 1:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Bryan Turner, git, Andrej E Baranov
In-Reply-To: <7va9rrq1o3.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Jonathan Nieder <jrnieder@gmail.com> writes:
>> Odd. "https://www.gravatar.com/" also seems to work. I've put in a
>> technical support query to find out what the Gravatar admins prefer.
>
> Thanks; will hold onto Andrej's patch until we hear what the story
> is.
Good news: a kind person from Automattic answered that
www.gravatar.com should work fine over SSL, both now and in the
future, and promised to add updating documentation to their todo list.
Thanks for your help and patience.
Jonathan
^ permalink raw reply
* Segmentation fault with latest git (070c57df)
From: Jongman Heo @ 2013-01-31 1:35 UTC (permalink / raw)
To: git
Hi all,
Looks like following commit causes a segmentation fault in my machine (when running git pull or git fetch);
commit 8dd5afc926acb9829ebf56e9b78826a5242cd638
Author: Junio C Hamano <gitster@pobox.com>
Date: Mon Jan 7 12:24:55 2013 -0800
string-list: allow case-insensitive string list
In my case, list->cmp (at get_entry_index() function) has an invalid address, obviously not an address of string comparision function, instead it points to 1.
Regards,
Jongman Heo.
^ permalink raw reply
* [PATCH 0/3] GPG running out of pipes fixes
From: Stephen Boyd @ 2013-01-31 2:01 UTC (permalink / raw)
To: git
While running --show-signatures on the linux kernel I noticed that after
a while git failed with an error message indicating it had run out of
file descriptors. The first patch fixes this problem, and the next
two are randmom bits since I was in the area.
Stephen Boyd (3):
gpg: Close stderr once finished with it in verify_signed_buffer()
run-command: Be more informative about what failed
gpg: Allow translation of more error messages
gpg-interface.c | 8 +++++---
run-command.c | 8 ++++++--
2 files changed, 11 insertions(+), 5 deletions(-)
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply
* [PATCH 1/3] gpg: Close stderr once finished with it in verify_signed_buffer()
From: Stephen Boyd @ 2013-01-31 2:01 UTC (permalink / raw)
To: git
In-Reply-To: <1359597666-10108-1-git-send-email-sboyd@codeaurora.org>
Failing to close the stderr pipe in verify_signed_buffer() causes
git to run out of file descriptors if there are many calls to
verify_signed_buffer(). An easy way to trigger this is to run
git log --show-signature --merges | grep "key"
on the linux kernel git repo. Eventually it will fail with
error: cannot create pipe for gpg: Too many open files
error: could not run gpg.
Close the stderr pipe so that this can't happen.
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
---
gpg-interface.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/gpg-interface.c b/gpg-interface.c
index 0863c61..2c0bed3 100644
--- a/gpg-interface.c
+++ b/gpg-interface.c
@@ -133,6 +133,8 @@ int verify_signed_buffer(const char *payload, size_t payload_size,
if (gpg_output)
strbuf_read(gpg_output, gpg.err, 0);
ret = finish_command(&gpg);
+ if (gpg_output)
+ close(gpg.err);
unlink_or_warn(path);
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply related
* [PATCH 3/3] gpg: Allow translation of more error messages
From: Stephen Boyd @ 2013-01-31 2:01 UTC (permalink / raw)
To: git
In-Reply-To: <1359597666-10108-1-git-send-email-sboyd@codeaurora.org>
Mark these strings for translation so that error messages are
printed in the user's language of choice.
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
---
gpg-interface.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/gpg-interface.c b/gpg-interface.c
index 2c0bed3..474c037 100644
--- a/gpg-interface.c
+++ b/gpg-interface.c
@@ -109,10 +109,10 @@ int verify_signed_buffer(const char *payload, size_t payload_size,
args_gpg[0] = gpg_program;
fd = git_mkstemp(path, PATH_MAX, ".git_vtag_tmpXXXXXX");
if (fd < 0)
- return error("could not create temporary file '%s': %s",
+ return error(_("could not create temporary file '%s': %s"),
path, strerror(errno));
if (write_in_full(fd, signature, signature_size) < 0)
- return error("failed writing detached signature to '%s': %s",
+ return error(_("failed writing detached signature to '%s': %s"),
path, strerror(errno));
close(fd);
@@ -124,7 +124,7 @@ int verify_signed_buffer(const char *payload, size_t payload_size,
args_gpg[2] = path;
if (start_command(&gpg)) {
unlink(path);
- return error("could not run gpg.");
+ return error(_("could not run gpg."));
}
write_in_full(gpg.in, payload, payload_size);
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply related
* [PATCH 2/3] run-command: Be more informative about what failed
From: Stephen Boyd @ 2013-01-31 2:01 UTC (permalink / raw)
To: git
In-Reply-To: <1359597666-10108-1-git-send-email-sboyd@codeaurora.org>
While debugging an error with verify_signed_buffer() the error
messages from run-command weren't very useful:
error: cannot create pipe for gpg: Too many open files
error: could not run gpg.
because they didn't indicate *which* pipe couldn't be created.
Print which pipe failed to be created in the error message so we
can more easily debug similar problems in the future.
For example, the above error now prints:
error: cannot create stderr pipe for gpg: Too many open files
error: could not run gpg.
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
---
run-command.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/run-command.c b/run-command.c
index 12d4ddb..016dd05 100644
--- a/run-command.c
+++ b/run-command.c
@@ -274,6 +274,7 @@ int start_command(struct child_process *cmd)
int need_in, need_out, need_err;
int fdin[2], fdout[2], fderr[2];
int failed_errno = failed_errno;
+ char *str;
/*
* In case of errors we must keep the promise to close FDs
@@ -286,6 +287,7 @@ int start_command(struct child_process *cmd)
failed_errno = errno;
if (cmd->out > 0)
close(cmd->out);
+ str = "stdin";
goto fail_pipe;
}
cmd->in = fdin[1];
@@ -301,6 +303,7 @@ int start_command(struct child_process *cmd)
close_pair(fdin);
else if (cmd->in)
close(cmd->in);
+ str = "stdout";
goto fail_pipe;
}
cmd->out = fdout[0];
@@ -318,9 +321,10 @@ int start_command(struct child_process *cmd)
close_pair(fdout);
else if (cmd->out)
close(cmd->out);
+ str = "stderr";
fail_pipe:
- error("cannot create pipe for %s: %s",
- cmd->argv[0], strerror(failed_errno));
+ error("cannot create %s pipe for %s: %s",
+ str, cmd->argv[0], strerror(failed_errno));
errno = failed_errno;
return -1;
}
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply related
* [PATCH 0/1] Introduce new build variables INSTALL_MODE_EXECUTABLE and INSTALL_MODE_DATA.
From: TJ @ 2013-01-31 2:08 UTC (permalink / raw)
To: git
During a build/install cycle of the current HEAD whilst attempting to identify the cause of a bug in
git version 1.8.0.3 whilst doing:
GIT_CURL_VERBOSE=1 git clone -v https://git01.codeplex.com/typescript
* GnuTLS recv error (-9): A TLS packet with unexpected length was received.
* Closing connection #0
error: RPC failed; result=56, HTTP code = 200
I hit a local install failure whilst installing to the prefix /usr/local/ where the $(INSTALL)
command reported a Permission Denied error.
This was due to the $(INSTALL) modes being 755/644 but the file-system modes being 775/664.
In this case ownership and permissions are:
$ ls -ald /usr/local
drwxrwxr-x 13 root adm 4096 Sep 26 04:16 /usr/local
Users belonging to the 'adm' group have permission to install local packages.
The fix I've implemented is to convert the hard-coded 755/644 modes to variables which can
be over-ridden on the make command-line if necessary.
^ permalink raw reply
* [PATCH 1/1] Introduce new build variables INSTALL_MODE_EXECUTABLE and INSTALL_MODE_DATA.
From: TJ @ 2013-01-31 2:08 UTC (permalink / raw)
To: git
Installation would fail if the target location had anything other than 755/644
file permissions. Therefore replace the hard-coded modes for each $(INSTALL)
with variables.
Default values are 755/644 but can be over-ridden on the make command line
e.g. "make INSTALL_MODE_EXECUTABLE=755 INSTALL_MODE_DATA=644 install".
Signed-off-by: TJ <git@iam.tj>
---
Documentation/Makefile | 20 ++++++++++----------
Makefile | 17 +++++++++++------
contrib/emacs/Makefile | 2 +-
contrib/subtree/Makefile | 4 ++--
git-gui/Makefile | 12 ++++++------
gitk-git/Makefile | 6 +++---
gitweb/Makefile | 8 ++++----
templates/Makefile | 2 +-
8 files changed, 38 insertions(+), 33 deletions(-)
diff --git a/Documentation/Makefile b/Documentation/Makefile
index 971977b..913928c 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -190,16 +190,16 @@ pdf: user-manual.pdf
install: install-man
install-man: man
- $(INSTALL) -d -m 755 $(DESTDIR)$(man1dir)
- $(INSTALL) -d -m 755 $(DESTDIR)$(man5dir)
- $(INSTALL) -d -m 755 $(DESTDIR)$(man7dir)
- $(INSTALL) -m 644 $(DOC_MAN1) $(DESTDIR)$(man1dir)
- $(INSTALL) -m 644 $(DOC_MAN5) $(DESTDIR)$(man5dir)
- $(INSTALL) -m 644 $(DOC_MAN7) $(DESTDIR)$(man7dir)
+ $(INSTALL) -d -m $(INSTALL_MODE_EXECUTABLE) $(DESTDIR)$(man1dir)
+ $(INSTALL) -d -m $(INSTALL_MODE_EXECUTABLE) $(DESTDIR)$(man5dir)
+ $(INSTALL) -d -m $(INSTALL_MODE_EXECUTABLE) $(DESTDIR)$(man7dir)
+ $(INSTALL) -m $(INSTALL_MODE_DATA) $(DOC_MAN1) $(DESTDIR)$(man1dir)
+ $(INSTALL) -m $(INSTALL_MODE_DATA) $(DOC_MAN5) $(DESTDIR)$(man5dir)
+ $(INSTALL) -m $(INSTALL_MODE_DATA) $(DOC_MAN7) $(DESTDIR)$(man7dir)
install-info: info
- $(INSTALL) -d -m 755 $(DESTDIR)$(infodir)
- $(INSTALL) -m 644 git.info gitman.info $(DESTDIR)$(infodir)
+ $(INSTALL) -d -m $(INSTALL_MODE_EXECUTABLE) $(DESTDIR)$(infodir)
+ $(INSTALL) -m $(INSTALL_MODE_DATA) git.info gitman.info $(DESTDIR)$(infodir)
if test -r $(DESTDIR)$(infodir)/dir; then \
$(INSTALL_INFO) --info-dir=$(DESTDIR)$(infodir) git.info ;\
$(INSTALL_INFO) --info-dir=$(DESTDIR)$(infodir) gitman.info ;\
@@ -208,8 +208,8 @@ install-info: info
fi
install-pdf: pdf
- $(INSTALL) -d -m 755 $(DESTDIR)$(pdfdir)
- $(INSTALL) -m 644 user-manual.pdf $(DESTDIR)$(pdfdir)
+ $(INSTALL) -d -m $(INSTALL_MODE_EXECUTABLE) $(DESTDIR)$(pdfdir)
+ $(INSTALL) -m $(INSTALL_MODE_DATA) user-manual.pdf $(DESTDIR)$(pdfdir)
install-html: html
'$(SHELL_PATH_SQ)' ./install-webdoc.sh $(DESTDIR)$(htmldir)
diff --git a/Makefile b/Makefile
index 731b6a8..7a59202 100644
--- a/Makefile
+++ b/Makefile
@@ -354,6 +354,11 @@ ALL_CFLAGS = $(CPPFLAGS) $(CFLAGS)
ALL_LDFLAGS = $(LDFLAGS)
STRIP ?= strip
+# default installation file modes. Can be overridden from the 'make' command-line.
+# E.g. For allowing group write: "make INSTALL_MODE_EXECUTABLE=775 install"
+INSTALL_MODE_EXECUTABLE = 755
+INSTALL_MODE_DATA = 644
+
# Among the variables below, these:
# gitexecdir
# template_dir
@@ -2257,16 +2262,16 @@ mergetools_instdir_SQ = $(subst ','\'',$(mergetools_instdir))
install_bindir_programs := $(patsubst %,%$X,$(BINDIR_PROGRAMS_NEED_X)) $(BINDIR_PROGRAMS_NO_X)
install: all
- $(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(bindir_SQ)'
- $(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(gitexec_instdir_SQ)'
+ $(INSTALL) -d -m $(INSTALL_MODE_EXECUTABLE) '$(DESTDIR_SQ)$(bindir_SQ)'
+ $(INSTALL) -d -m $(INSTALL_MODE_EXECUTABLE) '$(DESTDIR_SQ)$(gitexec_instdir_SQ)'
$(INSTALL) $(ALL_PROGRAMS) '$(DESTDIR_SQ)$(gitexec_instdir_SQ)'
- $(INSTALL) -m 644 $(SCRIPT_LIB) '$(DESTDIR_SQ)$(gitexec_instdir_SQ)'
+ $(INSTALL) -m $(INSTALL_MODE_DATA) $(SCRIPT_LIB) '$(DESTDIR_SQ)$(gitexec_instdir_SQ)'
$(INSTALL) $(install_bindir_programs) '$(DESTDIR_SQ)$(bindir_SQ)'
$(MAKE) -C templates DESTDIR='$(DESTDIR_SQ)' install
- $(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(mergetools_instdir_SQ)'
- $(INSTALL) -m 644 mergetools/* '$(DESTDIR_SQ)$(mergetools_instdir_SQ)'
+ $(INSTALL) -d -m $(INSTALL_MODE_EXECUTABLE) '$(DESTDIR_SQ)$(mergetools_instdir_SQ)'
+ $(INSTALL) -m $(INSTALL_MODE_DATA) mergetools/* '$(DESTDIR_SQ)$(mergetools_instdir_SQ)'
ifndef NO_GETTEXT
- $(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(localedir_SQ)'
+ $(INSTALL) -d -m $(INSTALL_MODE_EXECUTABLE) '$(DESTDIR_SQ)$(localedir_SQ)'
(cd po/build/locale && $(TAR) cf - .) | \
(cd '$(DESTDIR_SQ)$(localedir_SQ)' && umask 022 && $(TAR) xof -)
endif
diff --git a/contrib/emacs/Makefile b/contrib/emacs/Makefile
index 24d9312..a405744 100644
--- a/contrib/emacs/Makefile
+++ b/contrib/emacs/Makefile
@@ -4,7 +4,7 @@ EMACS = emacs
ELC = git.elc git-blame.elc
INSTALL ?= install
-INSTALL_ELC = $(INSTALL) -m 644
+INSTALL_ELC = $(INSTALL) -m $(INSTALL_MODE_DATA)
prefix ?= $(HOME)
emacsdir = $(prefix)/share/emacs/site-lisp
RM ?= rm -f
diff --git a/contrib/subtree/Makefile b/contrib/subtree/Makefile
index 05cdd5c..40d8d2f 100644
--- a/contrib/subtree/Makefile
+++ b/contrib/subtree/Makefile
@@ -30,12 +30,12 @@ $(GIT_SUBTREE): $(GIT_SUBTREE_SH)
doc: $(GIT_SUBTREE_DOC)
install: $(GIT_SUBTREE)
- $(INSTALL) -m 755 $(GIT_SUBTREE) $(libexecdir)
+ $(INSTALL) -m $(INSTALL_MODE_EXECUTABLE) $(GIT_SUBTREE) $(libexecdir)
install-doc: install-man
install-man: $(GIT_SUBTREE_DOC)
- $(INSTALL) -m 644 $^ $(man1dir)
+ $(INSTALL) -m $(INSTALL_MODE_DATA) $^ $(man1dir)
$(GIT_SUBTREE_DOC): $(GIT_SUBTREE_XML)
xmlto -m $(MANPAGE_NORMAL_XSL) man $^
diff --git a/git-gui/Makefile b/git-gui/Makefile
index e22ba5c..472a10c 100644
--- a/git-gui/Makefile
+++ b/git-gui/Makefile
@@ -48,11 +48,11 @@ endif
RM_RF ?= rm -rf
RMDIR ?= rmdir
-INSTALL_D0 = $(INSTALL) -d -m 755 # space is required here
+INSTALL_D0 = $(INSTALL) -d -m $(INSTALL_MODE_EXECUTABLE) # space is required here
INSTALL_D1 =
-INSTALL_R0 = $(INSTALL) -m 644 # space is required here
+INSTALL_R0 = $(INSTALL) -m $(INSTALL_MODE_DATA) # space is required here
INSTALL_R1 =
-INSTALL_X0 = $(INSTALL) -m 755 # space is required here
+INSTALL_X0 = $(INSTALL) -m $(INSTALL_MODE_EXECUTABLE) # space is required here
INSTALL_X1 =
INSTALL_A0 = find # space is required here
INSTALL_A1 = | cpio -pud
@@ -76,11 +76,11 @@ ifndef V
QUIET_2DEVNULL = 2>/dev/null
INSTALL_D0 = dir=
- INSTALL_D1 = && echo ' ' DEST $$dir && $(INSTALL) -d -m 755 "$$dir"
+ INSTALL_D1 = && echo ' ' DEST $$dir && $(INSTALL) -d -m $(INSTALL_MODE_EXECUTABLE) "$$dir"
INSTALL_R0 = src=
- INSTALL_R1 = && echo ' ' INSTALL 644 `basename $$src` && $(INSTALL) -m 644 $$src
+ INSTALL_R1 = && echo ' ' INSTALL $(INSTALL_MODE_DATA) `basename $$src` && $(INSTALL) -m $(INSTALL_MODE_DATA) $$src
INSTALL_X0 = src=
- INSTALL_X1 = && echo ' ' INSTALL 755 `basename $$src` && $(INSTALL) -m 755 $$src
+ INSTALL_X1 = && echo ' ' INSTALL $(INSTALL_MODE_EXECUTABLE) `basename $$src` && $(INSTALL) -m $(INSTALL_MODE_EXECUTABLE) $$src
INSTALL_A0 = src=
INSTALL_A1 = && echo ' ' INSTALL ' ' `basename "$$src"` && find "$$src" | cpio -pud
diff --git a/gitk-git/Makefile b/gitk-git/Makefile
index e1b6045..bc18cce 100644
--- a/gitk-git/Makefile
+++ b/gitk-git/Makefile
@@ -40,9 +40,9 @@ endif
all:: gitk-wish $(ALL_MSGFILES)
install:: all
- $(INSTALL) -m 755 gitk-wish '$(DESTDIR_SQ)$(bindir_SQ)'/gitk
- $(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(msgsdir_SQ)'
- $(foreach p,$(ALL_MSGFILES), $(INSTALL) -m 644 $p '$(DESTDIR_SQ)$(msgsdir_SQ)' &&) true
+ $(INSTALL) -m $(INSTALL_MODE_EXECUTABLE) gitk-wish '$(DESTDIR_SQ)$(bindir_SQ)'/gitk
+ $(INSTALL) -d -m $(INSTALL_MODE_EXECUTABLE) '$(DESTDIR_SQ)$(msgsdir_SQ)'
+ $(foreach p,$(ALL_MSGFILES), $(INSTALL) -m $(INSTALL_MODE_DATA) $p '$(DESTDIR_SQ)$(msgsdir_SQ)' &&) true
uninstall::
$(foreach p,$(ALL_MSGFILES), $(RM) '$(DESTDIR_SQ)$(msgsdir_SQ)'/$(notdir $p) &&) true
diff --git a/gitweb/Makefile b/gitweb/Makefile
index cd194d0..7d760b0 100644
--- a/gitweb/Makefile
+++ b/gitweb/Makefile
@@ -179,10 +179,10 @@ test-installed:
### Installation rules
install: all
- $(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(gitwebdir_SQ)'
- $(INSTALL) -m 755 $(GITWEB_PROGRAMS) '$(DESTDIR_SQ)$(gitwebdir_SQ)'
- $(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(gitwebstaticdir_SQ)'
- $(INSTALL) -m 644 $(GITWEB_FILES) '$(DESTDIR_SQ)$(gitwebstaticdir_SQ)'
+ $(INSTALL) -d -m $(INSTALL_MODE_EXECUTABLE) '$(DESTDIR_SQ)$(gitwebdir_SQ)'
+ $(INSTALL) -m $(INSTALL_MODE_EXECUTABLE) $(GITWEB_PROGRAMS) '$(DESTDIR_SQ)$(gitwebdir_SQ)'
+ $(INSTALL) -d -m $(INSTALL_MODE_EXECUTABLE) '$(DESTDIR_SQ)$(gitwebstaticdir_SQ)'
+ $(INSTALL) -m $(INSTALL_MODE_DATA) $(GITWEB_FILES) '$(DESTDIR_SQ)$(gitwebstaticdir_SQ)'
### Cleaning rules
diff --git a/templates/Makefile b/templates/Makefile
index d22a71a..3e7c7d2 100644
--- a/templates/Makefile
+++ b/templates/Makefile
@@ -61,6 +61,6 @@ clean:
$(RM) -r blt boilerplates.made
install: all
- $(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(template_instdir_SQ)'
+ $(INSTALL) -d -m $(INSTALL_MODE_EXECUTABLE) '$(DESTDIR_SQ)$(template_instdir_SQ)'
(cd blt && $(TAR) cf - .) | \
(cd '$(DESTDIR_SQ)$(template_instdir_SQ)' && umask 022 && $(TAR) xof -)
--
1.8.1.2.432.g070c57d.dirty
^ permalink raw reply related
* Re: [PATCH 1/3] gpg: Close stderr once finished with it in verify_signed_buffer()
From: Jeff King @ 2013-01-31 5:50 UTC (permalink / raw)
To: Stephen Boyd; +Cc: git
In-Reply-To: <1359597666-10108-2-git-send-email-sboyd@codeaurora.org>
On Wed, Jan 30, 2013 at 06:01:04PM -0800, Stephen Boyd wrote:
> Failing to close the stderr pipe in verify_signed_buffer() causes
> git to run out of file descriptors if there are many calls to
> verify_signed_buffer(). An easy way to trigger this is to run
>
> git log --show-signature --merges | grep "key"
>
> on the linux kernel git repo. Eventually it will fail with
>
> error: cannot create pipe for gpg: Too many open files
> error: could not run gpg.
>
> Close the stderr pipe so that this can't happen.
I was able to easily reproduce the bug and verify your fix here.
> diff --git a/gpg-interface.c b/gpg-interface.c
> index 0863c61..2c0bed3 100644
> --- a/gpg-interface.c
> +++ b/gpg-interface.c
> @@ -133,6 +133,8 @@ int verify_signed_buffer(const char *payload, size_t payload_size,
> if (gpg_output)
> strbuf_read(gpg_output, gpg.err, 0);
> ret = finish_command(&gpg);
> + if (gpg_output)
> + close(gpg.err);
The strbuf_read above will read to EOF, so it should be equivalent (and
IMHO slightly more readable) to do:
diff --git a/gpg-interface.c b/gpg-interface.c
index 0863c61..5f142f6 100644
--- a/gpg-interface.c
+++ b/gpg-interface.c
@@ -130,8 +130,10 @@ int verify_signed_buffer(const char *payload, size_t payload_size,
write_in_full(gpg.in, payload, payload_size);
close(gpg.in);
- if (gpg_output)
+ if (gpg_output) {
strbuf_read(gpg_output, gpg.err, 0);
+ close(gpg.err);
+ }
ret = finish_command(&gpg);
unlink_or_warn(path);
But that is a minor nit; either way, the patch looks good to me.
-Peff
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox