* 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: [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: "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
* [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: [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
* 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: 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: [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
* 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] 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
* [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
* [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
* 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
* Re: [BUG] incorrect search result returned when using git log with a future date parameter
From: Junio C Hamano @ 2013-01-30 19:57 UTC (permalink / raw)
To: Caspar Zhang; +Cc: git, Gris Ge
In-Reply-To: <51090466.9070105@casparzhang.com>
Caspar Zhang <caspar@casparzhang.com> writes:
> .... A date parsing function should parse _all dates with
> correctly format_, despite if it's an old date, or the date in the
> future.
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.
Patches welcome, as long as the fix does not make things worse for
cases other than you observed.
Thanks.
^ permalink raw reply
* [PATCH 3/3] mergetool--lib: list user configured tools in '--tool-help'
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 | 41 ++++++++++++++++++++++++++++++++++++++++-
1 file changed, 40 insertions(+), 1 deletion(-)
diff --git a/git-mergetool--lib.sh b/git-mergetool--lib.sh
index b44a2c8..e338be5 100644
--- a/git-mergetool--lib.sh
+++ b/git-mergetool--lib.sh
@@ -20,9 +20,24 @@ is_available () {
type "$merge_tool_path" >/dev/null 2>&1
}
+list_config_tools () {
+ section=$1
+ line_prefix=${2:-}
+
+ git config --get-regexp $section'\..*\.cmd' |
+ while read -r key value
+ do
+ toolname=${key#$section.}
+ toolname=${toolname%.cmd}
+
+ printf "%s%s\n" "$line_prefix" "$toolname"
+ done
+}
+
show_tool_names () {
condition=${1:-true} per_line_prefix=${2:-} preamble=${3:-}
not_found_msg=${4:-}
+ extra_content=${5:-}
shown_any=
( cd "$MERGE_TOOLS_DIR" && ls ) | {
@@ -41,6 +56,19 @@ show_tool_names () {
fi
done
+ if test -n "$extra_content"
+ then
+ if test -n "$preamble"
+ then
+ # Note: no '\n' here since we don't want a
+ # blank line if there is no initial content.
+ printf "%s" "$preamble"
+ preamble=
+ fi
+ shown_any=yes
+ printf "\n%s\n" "$extra_content"
+ fi
+
if test -n "$preamble" && test -n "$not_found_msg"
then
printf "%s\n" "$not_found_msg"
@@ -255,9 +283,20 @@ show_tool_help () {
any_shown=no
cmd_name=${TOOL_MODE}tool
+ config_tools=$({
+ diff_mode && list_config_tools difftool "$tab$tab"
+ list_config_tools mergetool "$tab$tab"
+ } | sort)
+ extra_content=
+ if test -n "$config_tools"
+ then
+ extra_content="${tab}user-defined:${LF}$config_tools"
+ 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." &&
+ "No suitable tool for 'git $cmd_name --tool=<tool>' found." \
+ "$extra_content" &&
any_shown=yes
show_tool_names 'mode_ok && ! is_available' "$tab$tab" \
--
1.8.1.1
^ permalink raw reply related
* [PATCH 1/3] fixup! mergetool--lib: add functions for finding available 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 | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
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"
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
--
1.8.1.1
^ permalink raw reply related
* [PATCH] git_remote_helpers: remove GIT-PYTHON-VERSION upon "clean"
From: Junio C Hamano @ 2013-01-30 19:30 UTC (permalink / raw)
To: git; +Cc: John Keeping
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>
---
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 related
* Re: What's cooking in git.git (Jan 2013, #11; Wed, 30)
From: John Keeping @ 2013-01-30 19:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Brandon Casey
In-Reply-To: <7v4nhylbus.fsf@alter.siamese.dyndns.org>
On Wed, Jan 30, 2013 at 11:17:15AM -0800, Junio C Hamano wrote:
> Let's do something like this on top of the topic.
This looks good to me.
> INSTALL | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/INSTALL b/INSTALL
> index b96e16d..2dc3b61 100644
> --- a/INSTALL
> +++ b/INSTALL
> @@ -131,8 +131,9 @@ Issues of note:
> use English. Under autoconf the configure script will do this
> automatically if it can't find libintl on the system.
>
> - - Python version 2.4 or later is needed to use the git-p4
> - interface to Perforce.
> + - Python version 2.4 or later (but not 3.x, which is not
> + supported by Perforce) is needed to use the git-p4 interface
> + to Perforce.
>
> - Some platform specific issues are dealt with Makefile rules,
> but depending on your specific installation, you may not
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2013, #11; Wed, 30)
From: Junio C Hamano @ 2013-01-30 19:17 UTC (permalink / raw)
To: John Keeping; +Cc: git, Brandon Casey
In-Reply-To: <20130130190759.GJ1342@serenity.lan>
John Keeping <john@keeping.me.uk> writes:
> On Wed, Jan 30, 2013 at 10:33:10AM -0800, Junio C Hamano wrote:
>> [Discarded]
>>
>> * jk/update-install-for-p4 (2013-01-20) 1 commit
>> . INSTALL: git-p4 doesn't support Python 3
>>
>> Made obsolete by bc/git-p4-for-python-2.4 topic.
>
> I disagree with this - that branch doesn't change INSTALL to list "not
> Python 3" in the supported versions.
>
> Brandon, would you mind doing s/2.4 or later/2.4 - 2.7/ on your branch?
Thanks for being a careful reader.
Let's do something like this on top of the topic.
INSTALL | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/INSTALL b/INSTALL
index b96e16d..2dc3b61 100644
--- a/INSTALL
+++ b/INSTALL
@@ -131,8 +131,9 @@ Issues of note:
use English. Under autoconf the configure script will do this
automatically if it can't find libintl on the system.
- - Python version 2.4 or later is needed to use the git-p4
- interface to Perforce.
+ - Python version 2.4 or later (but not 3.x, which is not
+ supported by Perforce) is needed to use the git-p4 interface
+ to Perforce.
- Some platform specific issues are dealt with Makefile rules,
but depending on your specific installation, you may not
^ permalink raw reply related
* Re: What's cooking in git.git (Jan 2013, #11; Wed, 30)
From: John Keeping @ 2013-01-30 19:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Brandon Casey
In-Reply-To: <7vd2wmldw9.fsf@alter.siamese.dyndns.org>
On Wed, Jan 30, 2013 at 10:33:10AM -0800, Junio C Hamano wrote:
> [Discarded]
>
> * jk/update-install-for-p4 (2013-01-20) 1 commit
> . INSTALL: git-p4 doesn't support Python 3
>
> Made obsolete by bc/git-p4-for-python-2.4 topic.
I disagree with this - that branch doesn't change INSTALL to list "not
Python 3" in the supported versions.
Brandon, would you mind doing s/2.4 or later/2.4 - 2.7/ on your branch?
John
^ permalink raw reply
* [BUG] `git branch --contains ID name` creates branch "name"
From: Peter Wu @ 2013-01-30 18:57 UTC (permalink / raw)
To: git
Hi,
I was trying to check whether a certain branch contained a commit and ran:
git branch --contains ddc150f7a33ae0c9cb16eaac3641abc00f56316f master
This resulted in:
fatal: A branch named 'master' already exists.
When "name" does not exist, this command creates a branch. I expect this
command to search the mentioned branch, not trying to create it. The manual
page of git-branch(1) does not mention such special behavior either.
Git version 1.8.1.2
Regards,
Peter
^ permalink raw reply
* RE: [feature request] git add completion should exclude staged content
From: Marc Khouzam @ 2013-01-30 18:55 UTC (permalink / raw)
To: 'Manlio Perillo'
Cc: 'Junio C Hamano', 'Michael J Gruber',
'wookietreiber', 'git@vger.kernel.org'
In-Reply-To: <51096543.9050100@gmail.com>
> -----Original Message-----
> From: git-owner@vger.kernel.org
> [mailto:git-owner@vger.kernel.org] On Behalf Of Manlio Perillo
> Sent: Wednesday, January 30, 2013 1:24 PM
> To: Marc Khouzam
> Cc: 'Junio C Hamano'; 'Michael J Gruber'; 'wookietreiber';
> 'git@vger.kernel.org'
> Subject: Re: [feature request] git add completion should
> exclude staged content
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Il 30/01/2013 15:06, Marc Khouzam ha scritto:
> > [...]
> >> I will try to update the patch, with your latest suggestions (avoid
> >> tricky POSIX shell syntax, and CDPATH issue - if I remember
> >> correctly),
> >> and with an update for the t/t9902-completion.sh test (that I
> >> completely
> >> missed).
> >
> > Hi Manlio,
> >
>
> Hi.
>
> > I'm trying to update git-completion.tcsh to work properly with
> > your nice new completion feature. But I'm having trouble with
> > the missing '/' at the end of directories.
> >
> > 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.
Thanks!
> > I also noticed the following comment:
> >
> > # XXX if we append a slash to directory names when using
> > # `compopt -o filenames`, Bash will append another slash.
> > # This is pretty stupid, and this the reason why we have to
> > # define a compatible version for this function.
> >
> > So I gather you would rather add a '/' all the time to deal
> > with older bash version transparently. This would be great
> > for tcsh also. I'm trying to figure out
> > when bash mis-behaves when you add the '/' all the time?
> > When I try it (I have bash 4.1.5(1)-release) I didn't run
> > into the double slash problem you mention in the comment.
> >
>
> I'm using the same version: 4.1.5(1), on Debian stable.
>
> > I'm hoping we can straighten this out and have
> > git-completion.bash add the '/' all the time.
> >
> > Could you explain when the problem happens?
> >
>
> 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. So if you typed
git add contri<tab>
you will properly get
git add contrib/
That is the case I was looking at.
I understand why you cannot put that second slash in the code now.
Thanks
>
>
> > Thanks
> >
>
>
> Thanks to you
>
> Manlio
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAlEJZUMACgkQscQJ24LbaUQUGACgkMG/bZrJKBzlZ8toEQwmggQX
> m9kAn2ATJbSp87kOkoCCc00eHmh71r3y
> =D9iu
> -----END PGP SIGNATURE-----
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* [PATCH v3 8/8] WIP: receive.allowupdatestohidden
From: Junio C Hamano @ 2013-01-30 18:45 UTC (permalink / raw)
To: git; +Cc: Jeff King, Shawn Pearce
In-Reply-To: <1359571542-19852-1-git-send-email-gitster@pobox.com>
This does not work yet, and for a good reason. As the side that
pushes to a hidden ref never sees that the ref already exists, a
request to update such a ref will come in the form of "please
_create_ this ref and point it at this object", which will not pass
the compare-and-swap based anti-race safety at the receiving end.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Documentation/config.txt | 6 ++++++
builtin/receive-pack.c | 9 ++++++++-
t/t5516-fetch-push.sh | 24 ++++++++++++++++++++++++
3 files changed, 38 insertions(+), 1 deletion(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 2dce021..8f13fc0 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1849,6 +1849,12 @@ receive.updateserverinfo::
If set to true, git-receive-pack will run git-update-server-info
after receiving data from git-push and updating refs.
+receive.allowupdatestohidden::
+ When `transfer.hiderefs` is in effect, allow `receive-pack`
+ to accept a push request that asks to update or delete a
+ hidden ref (by default, such a request is rejected).
+ see also `transfer.hiderefs`.
+
remote.<name>.url::
The URL of a remote repository. See linkgit:git-fetch[1] or
linkgit:git-push[1].
diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c
index a8248d9..88500e7 100644
--- a/builtin/receive-pack.c
+++ b/builtin/receive-pack.c
@@ -41,6 +41,7 @@ static int auto_gc = 1;
static const char *head_name;
static void *head_name_to_free;
static int sent_capabilities;
+static int allow_updates_to_hidden;
static enum deny_action parse_deny_action(const char *var, const char *value)
{
@@ -119,6 +120,11 @@ static int receive_pack_config(const char *var, const char *value, void *cb)
return 0;
}
+ if (strcmp(var, "receive.allowupdatestohidden") == 0) {
+ allow_updates_to_hidden = git_config_bool(var, value);
+ return 0;
+ }
+
return git_default_config(var, value, cb);
}
@@ -726,7 +732,8 @@ static void execute_commands(struct command *commands, const char *unpacker_erro
0, &cmd))
set_connectivity_errors(commands);
- reject_updates_to_hidden(commands);
+ if (!allow_updates_to_hidden)
+ reject_updates_to_hidden(commands);
if (run_receive_hook(commands, pre_receive_hook, 0)) {
for (cmd = commands; cmd; cmd = cmd->next) {
diff --git a/t/t5516-fetch-push.sh b/t/t5516-fetch-push.sh
index 522056f..4c8aef9 100755
--- a/t/t5516-fetch-push.sh
+++ b/t/t5516-fetch-push.sh
@@ -1095,4 +1095,28 @@ test_expect_success 'push to update a hidden ref' '
check_push_result $the_first_commit hidden/three
'
+test_expect_failure 'allow push to update a hidden ref' '
+ mk_test heads/master hidden/one hidden/two hidden/three &&
+ (
+ cd testrepo &&
+ git config transfer.hiderefs refs/hidden &&
+ git config receive.allowupdatestohidden yes
+ ) &&
+
+ # push to unhidden ref succeeds normally
+ git push testrepo master:refs/heads/master &&
+ check_push_result $the_commit heads/master &&
+
+ # push to update a hidden ref should succeed
+ git push testrepo master:refs/hidden/one &&
+ check_push_result $the_commit heads/master &&
+
+ # push to delete a hidden ref should succeed
+ git push testrepo :refs/hidden/two &&
+ (
+ cd testrepo &&
+ test_must_fail git show-ref -q refs/hidden/one
+ )
+'
+
test_done
--
1.8.1.2.589.ga9b91ac
^ permalink raw reply related
* [PATCH v3 7/8] fetch: fetch objects by their exact SHA-1 object names
From: Junio C Hamano @ 2013-01-30 18:45 UTC (permalink / raw)
To: git; +Cc: Jeff King, Shawn Pearce
In-Reply-To: <1359571542-19852-1-git-send-email-gitster@pobox.com>
Teach "git fetch" to accept an exact SHA-1 object name the user may
obtain out of band on the LHS of a pathspec, and send it on a "want"
message when the server side advertises the allow-tip-sha1-in-want
capability.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
fetch-pack.c | 22 +++++++++++++++++++++-
remote.c | 12 +++++++++++-
remote.h | 1 +
t/t5516-fetch-push.sh | 34 ++++++++++++++++++++++++++++++++++
4 files changed, 67 insertions(+), 2 deletions(-)
diff --git a/fetch-pack.c b/fetch-pack.c
index 915c0b7..70db646 100644
--- a/fetch-pack.c
+++ b/fetch-pack.c
@@ -36,7 +36,7 @@ static int marked;
#define MAX_IN_VAIN 256
static struct commit_list *rev_list;
-static int non_common_revs, multi_ack, use_sideband;
+static int non_common_revs, multi_ack, use_sideband, allow_tip_sha1_in_want;
static void rev_list_push(struct commit *commit, int mark)
{
@@ -563,6 +563,21 @@ static void filter_refs(struct fetch_pack_args *args,
}
}
+ /* Append unmatched requests to the list */
+ if (allow_tip_sha1_in_want) {
+ for (i = 0; i < nr_sought; i++) {
+ ref = sought[i];
+ if (ref->matched)
+ continue;
+ if (get_sha1_hex(ref->name, ref->old_sha1))
+ continue;
+
+ ref->matched = 1;
+ *newtail = ref;
+ ref->next = NULL;
+ newtail = &ref->next;
+ }
+ }
*refs = newlist;
}
@@ -803,6 +818,11 @@ static struct ref *do_fetch_pack(struct fetch_pack_args *args,
fprintf(stderr, "Server supports side-band\n");
use_sideband = 1;
}
+ if (server_supports("allow-tip-sha1-in-want")) {
+ if (args->verbose)
+ fprintf(stderr, "Server supports allow-tip-sha1-in-want\n");
+ allow_tip_sha1_in_want = 1;
+ }
if (!server_supports("thin-pack"))
args->use_thin_pack = 0;
if (!server_supports("no-progress"))
diff --git a/remote.c b/remote.c
index 1b7828d..1118d05 100644
--- a/remote.c
+++ b/remote.c
@@ -15,6 +15,7 @@ static struct refspec s_tag_refspec = {
0,
1,
0,
+ 0,
"refs/tags/*",
"refs/tags/*"
};
@@ -565,9 +566,13 @@ static struct refspec *parse_refspec_internal(int nr_refspec, const char **refsp
flags = REFNAME_ALLOW_ONELEVEL | (is_glob ? REFNAME_REFSPEC_PATTERN : 0);
if (fetch) {
+ unsigned char unused[40];
+
/* LHS */
if (!*rs[i].src)
; /* empty is ok; it means "HEAD" */
+ else if (llen == 40 && !get_sha1_hex(rs[i].src, unused))
+ rs[i].exact_sha1 = 1; /* ok */
else if (!check_refname_format(rs[i].src, flags))
; /* valid looking ref is ok */
else
@@ -1495,7 +1500,12 @@ int get_fetch_map(const struct ref *remote_refs,
} else {
const char *name = refspec->src[0] ? refspec->src : "HEAD";
- ref_map = get_remote_ref(remote_refs, name);
+ if (refspec->exact_sha1) {
+ ref_map = alloc_ref(name);
+ get_sha1_hex(name, ref_map->old_sha1);
+ } else {
+ ref_map = get_remote_ref(remote_refs, name);
+ }
if (!missing_ok && !ref_map)
die("Couldn't find remote ref %s", name);
if (ref_map) {
diff --git a/remote.h b/remote.h
index 251d8fd..f7b08f1 100644
--- a/remote.h
+++ b/remote.h
@@ -62,6 +62,7 @@ struct refspec {
unsigned force : 1;
unsigned pattern : 1;
unsigned matching : 1;
+ unsigned exact_sha1 : 1;
char *src;
char *dst;
diff --git a/t/t5516-fetch-push.sh b/t/t5516-fetch-push.sh
index 852efb6..522056f 100755
--- a/t/t5516-fetch-push.sh
+++ b/t/t5516-fetch-push.sh
@@ -1037,6 +1037,40 @@ test_expect_success 'push --prune refspec' '
! check_push_result $the_first_commit tmp/foo tmp/bar
'
+test_expect_success 'fetch exact SHA1' '
+ mk_test heads/master hidden/one &&
+ git push testrepo master:refs/hidden/one &&
+ (
+ cd testrepo &&
+ git config transfer.hiderefs refs/hidden
+ ) &&
+ check_push_result $the_commit hidden/one &&
+
+ mk_child child &&
+ (
+ cd child &&
+
+ # make sure $the_commit does not exist here
+ git repack -a -d &&
+ git prune &&
+ test_must_fail git cat-file -t $the_commit &&
+
+ # fetching the hidden object should fail by default
+ test_must_fail git fetch -v ../testrepo $the_commit:refs/heads/copy &&
+ test_must_fail git rev-parse --verify refs/heads/copy &&
+
+ # the server side can allow it to succeed
+ (
+ cd ../testrepo &&
+ git config uploadpack.allowtipsha1inwant true
+ ) &&
+
+ git fetch -v ../testrepo $the_commit:refs/heads/copy &&
+ result=$(git rev-parse --verify refs/heads/copy) &&
+ test "$the_commit" = "$result"
+ )
+'
+
test_expect_success 'push to update a hidden ref' '
mk_test heads/master hidden/one hidden/two hidden/three &&
(
--
1.8.1.2.589.ga9b91ac
^ permalink raw reply related
* [PATCH v3 6/8] upload-pack: optionally allow fetching from the tips of hidden refs
From: Junio C Hamano @ 2013-01-30 18:45 UTC (permalink / raw)
To: git; +Cc: Jeff King, Shawn Pearce
In-Reply-To: <1359571542-19852-1-git-send-email-gitster@pobox.com>
With uploadpack.allowtipsha1inwant configuration option set, future
versions of "git fetch" that allow an exact object name (likely to
have been obtained out of band) on the LHS of the fetch refspec can
make a request with a "want" line that names an object that may not
have been advertised due to transfer.hiderefs configuration.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Documentation/config.txt | 8 +++++++-
upload-pack.c | 25 +++++++++++++++++++------
2 files changed, 26 insertions(+), 7 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index f57c802..2dce021 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -2066,13 +2066,19 @@ transfer.hiderefs::
and is hidden from `git ls-remote`, `git fetch`, `git push :`,
etc. An attempt to update or delete a hidden ref by `git push`
is rejected, and an attempt to fetch a hidden ref by `git fetch`
- will fail.
+ will fail. See also `uploadpack.allowtipsha1inwant`.
transfer.unpackLimit::
When `fetch.unpackLimit` or `receive.unpackLimit` are
not set, the value of this variable is used instead.
The default value is 100.
+uploadpack.allowtipsha1inwant::
+ When `transfer.hiderefs` is in effect, allow `upload-pack`
+ to accept a fetch request that asks for an object at the tip
+ of a hidden ref (by default, such a request is rejected).
+ see also `transfer.hiderefs`.
+
url.<base>.insteadOf::
Any URL that starts with this value will be rewritten to
start, instead, with <base>. In cases where some site serves a
diff --git a/upload-pack.c b/upload-pack.c
index 6b10843..37977e2 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -26,6 +26,7 @@ static const char upload_pack_usage[] = "git upload-pack [--strict] [--timeout=<
#define SHALLOW (1u << 16)
#define NOT_SHALLOW (1u << 17)
#define CLIENT_SHALLOW (1u << 18)
+#define HIDDEN_REF (1u << 19)
static unsigned long oldest_have;
@@ -33,6 +34,7 @@ static int multi_ack;
static int no_done;
static int use_thin_pack, use_ofs_delta, use_include_tag;
static int no_progress, daemon_mode;
+static int allow_tip_sha1_in_want;
static int shallow_nr;
static struct object_array have_obj;
static struct object_array want_obj;
@@ -487,6 +489,12 @@ static int get_common_commits(void)
}
}
+static int is_our_ref(struct object *o)
+{
+ return o->flags &
+ ((allow_tip_sha1_in_want ? HIDDEN_REF : 0) | OUR_REF);
+}
+
static void check_non_tip(void)
{
static const char *argv[] = {
@@ -523,7 +531,7 @@ static void check_non_tip(void)
o = get_indexed_object(--i);
if (!o)
continue;
- if (!(o->flags & OUR_REF))
+ if (!is_our_ref(o))
continue;
memcpy(namebuf + 1, sha1_to_hex(o->sha1), 40);
if (write_in_full(cmd.in, namebuf, 42) < 0)
@@ -532,7 +540,7 @@ static void check_non_tip(void)
namebuf[40] = '\n';
for (i = 0; i < want_obj.nr; i++) {
o = want_obj.objects[i].item;
- if (o->flags & OUR_REF)
+ if (is_our_ref(o))
continue;
memcpy(namebuf, sha1_to_hex(o->sha1), 40);
if (write_in_full(cmd.in, namebuf, 41) < 0)
@@ -566,7 +574,7 @@ error:
/* Pick one of them (we know there at least is one) */
for (i = 0; i < want_obj.nr; i++) {
o = want_obj.objects[i].item;
- if (!(o->flags & OUR_REF))
+ if (!is_our_ref(o))
die("git upload-pack: not our ref %s",
sha1_to_hex(o->sha1));
}
@@ -646,7 +654,7 @@ static void receive_needs(void)
sha1_to_hex(sha1_buf));
if (!(o->flags & WANTED)) {
o->flags |= WANTED;
- if (!(o->flags & OUR_REF))
+ if (!is_our_ref(o))
has_non_tip = 1;
add_object_array(o, NULL, &want_obj);
}
@@ -725,8 +733,10 @@ static int mark_our_ref(const char *refname, const unsigned char *sha1, int flag
{
struct object *o = lookup_unknown_object(sha1);
- if (ref_is_hidden(refname))
+ if (ref_is_hidden(refname)) {
+ o->flags |= HIDDEN_REF;
return 1;
+ }
if (!o)
die("git upload-pack: cannot find object %s:", sha1_to_hex(sha1));
o->flags |= OUR_REF;
@@ -745,9 +755,10 @@ static int send_ref(const char *refname, const unsigned char *sha1, int flag, vo
return 0;
if (capabilities)
- packet_write(1, "%s %s%c%s%s agent=%s\n",
+ packet_write(1, "%s %s%c%s%s%s agent=%s\n",
sha1_to_hex(sha1), refname_nons,
0, capabilities,
+ allow_tip_sha1_in_want ? " allow-tip-sha1-in-want" : "",
stateless_rpc ? " no-done" : "",
git_user_agent_sanitized());
else
@@ -781,6 +792,8 @@ static void upload_pack(void)
static int upload_pack_config(const char *var, const char *value, void *unused)
{
+ if (!strcmp("uploadpack.allowtipsha1inwant", var))
+ allow_tip_sha1_in_want = git_config_bool(var, value);
return parse_hide_refs_config(var, value, unused);
}
--
1.8.1.2.589.ga9b91ac
^ 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