* Re: [PATCH v4 1/2] for-each-repo: new command used for multi-repo operations
From: Junio C Hamano @ 2013-01-28 18:51 UTC (permalink / raw)
To: Lars Hjemli; +Cc: Jonathan Nieder, git
In-Reply-To: <CAFXTnz6xBMo42jWdqahYX-bnTBucVmQpFPN29X8tGRd7L=g2wQ@mail.gmail.com>
Lars Hjemli <hjemli@gmail.com> writes:
>> Come to think of it, is there a reason why "for-each-repo" should
>> not be an extention to "submodule foreach"? We can view this as
>> visiting repositories that _could_ be registered as a submodule, in
>> addition to iterating over the registered submodules, no?
>
> Yes, but I see some possible problems with that approach:
> -'git for-each-repo' does not need to be started from within a git worktree
True, but "git submodule foreach --untracked" can be told that it is
OK not (yet) to be in any superproject, no?
> -'git for-each-repo' and 'git submodule foreach' have different
> semantics for --dirty and --clean
That could be a problem. Is there a good reason why they should use
different definitions of dirtyness?
> -'git for-each-repo' is in C because my 'git-all' shell script was
> horribly slow on large directory trees (especially on windows)
Your for-each-repo could be a good basis to build a new builtin
"submodule--foreach" that is a pure helper hidden from the end users
that does both; cmd_foreach() in git-submodule.sh can simply delegate
to it.
> All of these problems are probably solvable, but it would require
> quite some reworking of git-submodule.sh
Of course some work is needed, but we do not have to convert all the
cmd_foo in git-submodule.sh in one step. For the purpose of
unifying for-each-repo and submodule foreach to deliver the
functionality sooner to the end users, we can go the route to add
only the submodule--foreach builtin, out of which we will get
reusable implementation of module_list and other helper functions we
can leverage later to do other cmd_foo functions.
^ permalink raw reply
* [PATCH] remove protocol from gravatar and picon links for clear if Gitweb is being called through a secure server
From: Andrej Andb @ 2013-01-28 19:14 UTC (permalink / raw)
To: git; +Cc: Andrej Andb
---
gitweb/gitweb.perl | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index c6bafe6..1309196 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -2068,7 +2068,7 @@ sub picon_url {
if (!$avatar_cache{$email}) {
my ($user, $domain) = split('@', $email);
$avatar_cache{$email} =
- "http://www.cs.indiana.edu/cgi-pub/kinzler/piconsearch.cgi/" .
+ "//www.cs.indiana.edu/cgi-pub/kinzler/piconsearch.cgi/" .
"$domain/$user/" .
"users+domains+unknown/up/single";
}
@@ -2083,7 +2083,7 @@ sub gravatar_url {
my $email = lc shift;
my $size = shift;
$avatar_cache{$email} ||=
- "http://www.gravatar.com/avatar/" .
+ "//www.gravatar.com/avatar/" .
Digest::MD5::md5_hex($email) . "?s=";
return $avatar_cache{$email} . $size;
}
--
1.8.1.1
^ permalink raw reply related
* [PATCH] fixup! mergetools: simplify how we handle "vim" and "defaults"
From: John Keeping @ 2013-01-28 19:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, David Aguilar
---
Junio, please can you squash this into f9924e5 on jk/mergetool,
providing that David is OK with that?
The original change breaks custom mergetool by making changing the logic
around default functions so that they are now only defined when the tool
file exists in $MERGE_TOOLS_DIR but we need the default implementations
when a custom tool is in use, which by definition means that the file
doesn't exist in $MERGE_TOOLS_DIR.
git-mergetool--lib.sh | 18 +++++++++---------
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/git-mergetool--lib.sh b/git-mergetool--lib.sh
index 1d0fb12..211ffe5 100644
--- a/git-mergetool--lib.sh
+++ b/git-mergetool--lib.sh
@@ -48,15 +48,6 @@ valid_tool () {
setup_tool () {
tool="$1"
- if ! test -f "$MERGE_TOOLS_DIR/$tool"
- then
- # Use a special return code for this case since we want to
- # source "defaults" even when an explicit tool path is
- # configured since the user can use that to override the
- # default path in the scriptlet.
- return 2
- fi
-
# Fallback definitions, to be overriden by tools.
can_merge () {
return 0
@@ -80,6 +71,15 @@ setup_tool () {
echo "$1"
}
+ if ! test -f "$MERGE_TOOLS_DIR/$tool"
+ then
+ # Use a special return code for this case since we want to
+ # source "defaults" even when an explicit tool path is
+ # configured since the user can use that to override the
+ # default path in the scriptlet.
+ return 2
+ fi
+
# Load the redefined functions
. "$MERGE_TOOLS_DIR/$tool"
--
1.8.1.1
^ permalink raw reply related
* Re: [PATCH v2 3/4] mergetool--lib: Add functions for finding available tools
From: John Keeping @ 2013-01-28 19:37 UTC (permalink / raw)
To: David Aguilar; +Cc: Junio C Hamano, git
In-Reply-To: <1359334346-5879-4-git-send-email-davvid@gmail.com>
On Sun, Jan 27, 2013 at 04:52:25PM -0800, David Aguilar wrote:
> Refactor show_tool_help() so that the tool-finding logic is broken out
> into a separate show_tool_names() function.
>
> Signed-off-by: David Aguilar <davvid@gmail.com>
> ---
> filter_tools renamed to show_tool_names() and simplfied
> to use ls -1. show_tool_names() now has a preamble as discussed.
>
> git-mergetool--lib.sh | 68 +++++++++++++++++++++++++++++----------------------
> 1 file changed, 39 insertions(+), 29 deletions(-)
>
> diff --git a/git-mergetool--lib.sh b/git-mergetool--lib.sh
> index db3eb58..fe068f6 100644
> --- a/git-mergetool--lib.sh
> +++ b/git-mergetool--lib.sh
> @@ -2,6 +2,35 @@
> # git-mergetool--lib is a library for common merge tool functions
> MERGE_TOOLS_DIR=$(git --exec-path)/mergetools
>
> +mode_ok () {
> + diff_mode && can_diff ||
> + merge_mode && can_merge
> +}
> +
> +is_available () {
> + merge_tool_path=$(translate_merge_tool_path "$1") &&
> + type "$merge_tool_path" >/dev/null 2>&1
> +}
> +
Can we move show_tool_names() to be above show_tool_help()? It's a
very minor nit but I prefer having related functionality grouped
together.
> +show_tool_names () {
> + condition=${1:-true} per_line_prefix=${2:-} preamble=${3:-}
Would this be better with one value on each line? Also perhaps
per_line_prefix -> line_prefix.
> +
> + ( cd "$MERGE_TOOLS_DIR" && ls -1 * ) |
> + while read toolname
> + do
> + if setup_tool "$toolname" 2>/dev/null &&
> + (eval "$condition" "$toolname")
> + then
> + if test -n "$preamble"
> + then
> + echo "$preamble"
> + preamble=
> + fi
> + printf "%s%s\n" "$per_line_prefix" "$tool"
This needs to be:
printf "$per_line_prefix%s\n" "$tool"
since $per_line_prefix is usually '\t\t' which isn't expanded if we
format it with %s - an alternative would be to change the value passed
in to '$TAB$TAB' with literal tabs.
> + fi
> + done
> +}
> +
> diff_mode() {
> test "$TOOL_MODE" = diff
> }
^ permalink raw reply
* Re: [PATCH v4 1/2] for-each-repo: new command used for multi-repo operations
From: Lars Hjemli @ 2013-01-28 19:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jonathan Nieder, git
In-Reply-To: <7vr4l5w385.fsf@alter.siamese.dyndns.org>
On Mon, Jan 28, 2013 at 7:51 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Lars Hjemli <hjemli@gmail.com> writes:
>
>>> Come to think of it, is there a reason why "for-each-repo" should
>>> not be an extention to "submodule foreach"? We can view this as
>>> visiting repositories that _could_ be registered as a submodule, in
>>> addition to iterating over the registered submodules, no?
>>
>> Yes, but I see some possible problems with that approach:
>> -'git for-each-repo' does not need to be started from within a git worktree
>
> True, but "git submodule foreach --untracked" can be told that it is
> OK not (yet) to be in any superproject, no?
Yes.
>
>> -'git for-each-repo' and 'git submodule foreach' have different
>> semantics for --dirty and --clean
>
> That could be a problem. Is there a good reason why they should use
> different definitions of dirtyness?
I suspected that 'submodule foreach --dirty' might want to compare the
HEAD sha1 in the submodule against the one recorded in the
superproject (similar to what 'git submodule status' does), but such a
check could be triggered by a different flag (e.g. --behind/--ahead or
something similar).
>> -'git for-each-repo' is in C because my 'git-all' shell script was
>> horribly slow on large directory trees (especially on windows)
>
> Your for-each-repo could be a good basis to build a new builtin
> "submodule--foreach" that is a pure helper hidden from the end users
> that does both; cmd_foreach() in git-submodule.sh can simply delegate
> to it.
Ok, I'll rework my patches in this direction. Thanks.
--
larsh
^ permalink raw reply
* Re: [feature request] git add completion should exclude staged content
From: Manlio Perillo @ 2013-01-28 20:13 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Junio C Hamano, wookietreiber, git
In-Reply-To: <5106A5CE.3000800@drmicha.warpmail.net>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Il 28/01/2013 17:22, Michael J Gruber ha scritto:
> [...]
>> The patch will suggest (for git add command), all the files that are
>> candidate to be added to the index file.
>>
>> Please, test it and report any behaviour you think is incorrect.
>
> OK, that seems to work and to be quite helpful.
>
> Minor nit: "git add -u" could use the same fileset as "git commit". But
> I don't know whether completion can act upon the presence of options.
It is possible, but I have not implemented since I was not sure about it
and I wanted to avoid to make the patch more hard to review.
I will work on it after the patch is approved.
> Currently, it also includes untracked files (just like without -u) but
> omits unmodified and ignored ones, which is already quite an improvement.
>
> I won't be able to review the completion code but may contribute a few
> lines to t/t9902-completion.sh, possibly.
>
Ah, I missed this test; thanks.
The proposed patch must update it.
Regards Manlio
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAlEG2+UACgkQscQJ24LbaURstACfdNxuFvaokBSTls20bSQ7jPHA
8I0An3fX6oRKuc2lzAgPVBLjsbjbw91V
=igwr
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [PATCH v4 1/2] for-each-repo: new command used for multi-repo operations
From: Jens Lehmann @ 2013-01-28 20:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Lars Hjemli, Jonathan Nieder, git, Heiko Voigt
In-Reply-To: <7vr4l5w385.fsf@alter.siamese.dyndns.org>
Am 28.01.2013 19:51, schrieb Junio C Hamano:
> Lars Hjemli <hjemli@gmail.com> writes:
>
>>> Come to think of it, is there a reason why "for-each-repo" should
>>> not be an extention to "submodule foreach"? We can view this as
>>> visiting repositories that _could_ be registered as a submodule, in
>>> addition to iterating over the registered submodules, no?
>>
>> Yes, but I see some possible problems with that approach:
>> -'git for-each-repo' does not need to be started from within a git worktree
>
> True, but "git submodule foreach --untracked" can be told that it is
> OK not (yet) to be in any superproject, no?
Hmm, I'm not sure how that would work as it looks for gitlinks
in the index which point to work tree paths.
>> -'git for-each-repo' and 'git submodule foreach' have different
>> semantics for --dirty and --clean
I'm confused, what semantics of --dirty and --clean does current
'git submodule foreach' have? I can't find any sign of it in the
current code ... did I miss something while skimming through this
thread? Or are you talking about status and diff here?
> That could be a problem. Is there a good reason why they should use
> different definitions of dirtyness?
I don't see any (except of course for comparing a gitlink with the
HEAD of the submodule, which is an additional condition that only
applies to submodules). But I think the current for-each-repo
proposal doesn't allow to traverse repos which contain untracked
content (and it would be nice if the user could somehow combine
that with the current --dirty flag to have both in one go).
>> -'git for-each-repo' is in C because my 'git-all' shell script was
>> horribly slow on large directory trees (especially on windows)
>
> Your for-each-repo could be a good basis to build a new builtin
> "submodule--foreach" that is a pure helper hidden from the end users
> that does both; cmd_foreach() in git-submodule.sh can simply delegate
> to it.
I like that approach, because the operations are very similar from
the user's point of view. But please remember that internally they
would work differently, as submodule foreach walks the index and
only descends into those submodules that are populated (and contain
a .git directory or file) while for-each-repo scans the whole work
tree, which makes it a more expensive operation.
>> All of these problems are probably solvable, but it would require
>> quite some reworking of git-submodule.sh
>
> Of course some work is needed, but we do not have to convert all the
> cmd_foo in git-submodule.sh in one step. For the purpose of
> unifying for-each-repo and submodule foreach to deliver the
> functionality sooner to the end users, we can go the route to add
> only the submodule--foreach builtin, out of which we will get
> reusable implementation of module_list and other helper functions we
> can leverage later to do other cmd_foo functions.
I really like that idea!
^ permalink raw reply
* Re: [feature request] git add completion should exclude staged content
From: Manlio Perillo @ 2013-01-28 20:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michael J Gruber, wookietreiber, git
In-Reply-To: <7vd2wpxki1.fsf@alter.siamese.dyndns.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Il 28/01/2013 18:52, Junio C Hamano ha scritto:
> [...]
>
> Thanks both for commenting. I'll find time to read it over again
> and perhaps we can merge it to 'next' and advertise it in the next
> issue of "What's cooking" report to ask for wider testing to move it
> forward.
Thanks.
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).
Regards Manlio
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAlEG3IcACgkQscQJ24LbaUTR/wCfSC/kHxseKAQ9rnK2ba/WwND1
cmsAn2CuHpRs2VjippTwkT5O3ul9cQKb
=5Way
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [PATCH] l10n: de.po: translate 11 new messages
From: Philip Oakley @ 2013-01-28 20:33 UTC (permalink / raw)
To: Ralf Thielow, Thomas Rast; +Cc: jk, stimming, Git List
In-Reply-To: <20130128175514.GA2926@rath-ubuntu>
From: "Ralf Thielow" <ralf.thielow@gmail.com>
Sent: Monday, January 28, 2013 5:55 PM
> On Mon, Jan 28, 2013 at 11:33:09AM +0100, Thomas Rast wrote:
>> Ralf Thielow <ralf.thielow@gmail.com> writes:
>>
>> > #: builtin/reset.c:275
>> > -#, fuzzy, c-format
>> > +#, c-format
>> > msgid "Failed to resolve '%s' as a valid revision."
>> > -msgstr "Konnte '%s' nicht als gültige Referenz auflösen."
>> > +msgstr "Konnte '%s' nicht als gültige Revision auflösen."
>>
>> You don't have "revision" in the glossary[1] yet. Wouldn't it be
>> appropriate to treat it as "commit", and translate as "Version" to
>> avoid
>> introducing yet another term?
>>
>> Or am I missing some subtle distinction between commit and revision?
>>
>
> I don't think there's a distinction.
It was a problem I had http://stackoverflow.com/a/11792712/717355
answered as:
See "SPECIFYING REVISIONS" of git rev-parse:
A revision parameter <rev> typically, but not necessarily, names a
commit object.
It uses what is called an extended SHA1 syntax, [and includes] various
ways to spell object names.
It had me confused for a while.
> Since we've already translated
> "revision" as "Revision" in a couple of other messages, I'll make a
> new "s/Revision/Version" commit on top.
>
>> Since it's only a single nit, feel free to add my ack when you
>> reroll:
>>
>> Acked-by: Thomas Rast <trast@inf.ethz.ch>
>>
>>
>> [1] https://github.com/ralfth/git-po-de/wiki/Glossary
>>
>> --
>> Thomas Rast
>> trast@{inf,student}.ethz.ch
> --
Philip Oakley
^ permalink raw reply
* Re: [PATCH v4 1/2] for-each-repo: new command used for multi-repo operations
From: Junio C Hamano @ 2013-01-28 20:34 UTC (permalink / raw)
To: Jens Lehmann; +Cc: Lars Hjemli, Jonathan Nieder, git, Heiko Voigt
In-Reply-To: <5106DBB7.70007@web.de>
Jens Lehmann <Jens.Lehmann@web.de> writes:
> Am 28.01.2013 19:51, schrieb Junio C Hamano:
>> Lars Hjemli <hjemli@gmail.com> writes:
>>
>>>> Come to think of it, is there a reason why "for-each-repo" should
>>>> not be an extention to "submodule foreach"? We can view this as
>>>> visiting repositories that _could_ be registered as a submodule, in
>>>> addition to iterating over the registered submodules, no?
>>>
>>> Yes, but I see some possible problems with that approach:
>>> -'git for-each-repo' does not need to be started from within a git worktree
>>
>> True, but "git submodule foreach --untracked" can be told that it is
>> OK not (yet) to be in any superproject, no?
>
> Hmm, I'm not sure how that would work as it looks for gitlinks
> in the index which point to work tree paths.
I was imagining that "foreach --untracked" could go something like this:
* If you are inside an existing git repository, read its index to
learn the gitlinks in the directory and its subdirectories.
* Start from the current directory and recursively apply the
procedure in this step:
* Scan the directory and iterate over the ones that has ".git" in
it:
* If it is a gitlinked one, show it, but do not descend into it
unless --recursive is given (e.g. you start from /home/jens,
find /home/jens/proj/ directory that has /home/jens/proj/.git
in it. /home/jens/.git/index knows that it is a submodule of
the top-level superproject. "proj" is handled, and it is up
to the --recursive option if its submodules are handled).
* If it is _not_ a gitlinked one, show it and descend into it
(e.g. /home/jens/ is not a repository or /home/jens/proj is
not a tracked submodule) to apply this procedure recursively.
Of course, without --untracked, we have no need to iterate over the
readdir() return values; instead we just scan the index of the
top-level superproject.
>>> -'git for-each-repo' and 'git submodule foreach' have different
>>> semantics for --dirty and --clean
>
> I'm confused, what semantics of --dirty and --clean does current
> 'git submodule foreach' have? I can't find any sign of it in the
> current code ... did I miss something while skimming through this
> thread? Or are you talking about status and diff here?
I think Lars is hinting that "submodule foreach" could restrict its
operation to a similar --dirty/--clean/--both option he has. Of
course, the command given to foreach can decide to become no-op by
inspecting the submodule itself, so in that sense, --dirty/--clean
can be done without, but I think it would make sense to have it in
"submodule foreach" even without the "--untracked" option.
> But I think the current for-each-repo
> proposal doesn't allow to traverse repos which contain untracked
> content (and it would be nice if the user could somehow combine
> that with the current --dirty flag to have both in one go).
Perhaps. I personally felt it was really strange that submodule
diff and status consider that it is a sin to have untracked and
unignored cruft in the submodule working tree, though.
^ permalink raw reply
* Re: [PATCH v2 3/4] mergetool--lib: Add functions for finding available tools
From: Junio C Hamano @ 2013-01-28 20:36 UTC (permalink / raw)
To: John Keeping; +Cc: David Aguilar, git
In-Reply-To: <20130128193700.GB7498@serenity.lan>
John Keeping <john@keeping.me.uk> writes:
>> + printf "%s%s\n" "$per_line_prefix" "$tool"
>
> This needs to be:
>
> printf "$per_line_prefix%s\n" "$tool"
>
> since $per_line_prefix is usually '\t\t' which isn't expanded if we
> format it with %s - an alternative would be to change the value passed
> in to '$TAB$TAB' with literal tabs.
I would prefer the latter, actually. I do understand the
convenience of being able to write backslash-t, but I do not think
it outweighs the potential risk of mistakingly passing a string with
per-cent in it.
^ permalink raw reply
* [ANNOUNCE] Git v1.8.1.2
From: Junio C Hamano @ 2013-01-28 20:41 UTC (permalink / raw)
To: git; +Cc: Linux Kernel
The latest maintenance release Git v1.8.1.2 is now available at the
usual places. This contains a handful of fixes that will also
appear in the next feature release.
The release tarballs are found at:
http://code.google.com/p/git-core/downloads/list
and their SHA-1 checksums are:
29a2dee568b1f86e9d3d8f9dcc376f24439b6a0c git-1.8.1.2.tar.gz
3df491003d026b8f4b2de378e57b930a98f0a595 git-htmldocs-1.8.1.2.tar.gz
142222a27dfec52256831f2d0e2ee655f75c1077 git-manpages-1.8.1.2.tar.gz
Also the following public repositories all have a copy of the v1.8.1.2
tag and the maint branch that the tag points at:
url = git://repo.or.cz/alt-git.git
url = https://code.google.com/p/git-core/
url = git://git.sourceforge.jp/gitroot/git-core/git.git
url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core
url = https://github.com/gitster/git
Git 1.8.1.2 Release Notes
=========================
Fixes since v1.8.1.1
--------------------
* An element on GIT_CEILING_DIRECTORIES list that does not name the
real path to a directory (i.e. a symbolic link) could have caused
the GIT_DIR discovery logic to escape the ceiling.
* Command line completion for "tcsh" emitted an unwanted space
after completing a single directory name.
* Command line completion leaked an unnecessary error message while
looking for possible matches with paths in <tree-ish>.
* "git archive" did not record uncompressed size in the header when
streaming a zip archive, which confused some implementations of unzip.
* When users spelled "cc:" in lowercase in the fake "header" in the
trailer part, "git send-email" failed to pick up the addresses from
there. As e-mail headers field names are case insensitive, this
script should follow suit and treat "cc:" and "Cc:" the same way.
Also contains various documentation fixes.
----------------------------------------------------------------
Changes since v1.8.1.1 are as follows:
Antoine Pelisse (3):
dir.c: Make git-status --ignored more consistent
git-status: Test --ignored behavior
status: always report ignored tracked directories
Dylan Smith (1):
git-completion.bash: silence "not a valid object" errors
Eric S. Raymond (1):
Remove the suggestion to use parsecvs, which is currently broken.
John Keeping (1):
git-for-each-ref.txt: 'raw' is a supported date format
Jonathan Nieder (1):
contrib/vim: simplify instructions for old vim support
Junio C Hamano (2):
Start preparing for 1.8.1.2
Git 1.8.1.2
Marc Khouzam (1):
Prevent space after directories in tcsh completion
Michael Haggerty (8):
Introduce new static function real_path_internal()
real_path_internal(): add comment explaining use of cwd
Introduce new function real_path_if_valid()
longest_ancestor_length(): use string_list_split()
longest_ancestor_length(): take a string_list argument for prefixes
longest_ancestor_length(): require prefix list entries to be normalized
setup_git_directory_gently_1(): resolve symlinks in ceiling paths
string_list_longest_prefix(): remove function
Nguyễn Thái Ngọc Duy (1):
attr: make it build with DEBUG_ATTR again
Nickolai Zeldovich (1):
git-send-email: treat field names as case-insensitively
Peter Eisentraut (1):
git-commit-tree(1): correct description of defaults
René Scharfe (5):
archive-zip: write uncompressed size into header even with streaming
t0024, t5000: clear variable UNZIP, use GIT_UNZIP instead
t0024, t5000: use test_lazy_prereq for UNZIP
t5000, t5003: move ZIP tests into their own script
t5003: check if unzip supports symlinks
Sebastian Staudt (1):
config.txt: Document help.htmlpath config parameter
^ permalink raw reply
* Re: Bug: file named - on git commit
From: Jonathan Nieder @ 2013-01-28 20:41 UTC (permalink / raw)
To: Thomas Rast; +Cc: Rene Moser, git
In-Reply-To: <87txq11sbk.fsf@pctrast.inf.ethz.ch>
Hi,
Thomas Rast wrote:
> Rene Moser <mail@renemoser.net> writes:
>> Found a little issue in git version 1.7.9.5 if a file named "-", causing
>> "git commit" to read from stdin.
>>
>> (So you must hit ctrl-d or ctrl-c to finish the commit.)
[...]
> This was fixed by Junio around 4682d85 (diff-index.c: "git diff" has no
> need to read blob from the standard input, 2012-06-27), which is
> included starting with v1.7.12 and the v1.7.11.3 maint release. Please
> upgrade.
Should upgrade-averse folks stuck on 1.7.10.y (like Debian 7.0, which
is currently in the release candidate stage) take this fix? Do you
happen to know of any other fixes such people would want?
Thanks,
Jonathan
^ permalink raw reply
* A note from the maintainer
From: Junio C Hamano @ 2013-01-28 20:48 UTC (permalink / raw)
To: git
Welcome to the Git development community.
This message is written by the maintainer and talks about how Git
project is managed, and how you can work with it.
* Mailing list and the community
The development is primarily done on the Git mailing list. Help
requests, feature proposals, bug reports and patches should be sent to
the list address <git@vger.kernel.org>. You don't have to be
subscribed to send messages. The convention on the list is to keep
everybody involved on Cc:, so it is unnecessary to say "Please Cc: me,
I am not subscribed".
Before sending patches, please read Documentation/SubmittingPatches
and Documentation/CodingGuidelines to familiarize yourself with the
project convention.
If you sent a patch and you did not hear any response from anybody for
several days, it could be that your patch was totally uninteresting,
but it also is possible that it was simply lost in the noise. Please
do not hesitate to send a reminder message in such a case. Messages
getting lost in the noise is a sign that people involved don't have
enough mental/time bandwidth to process them right at the moment, and
it often helps to wait until the list traffic becomes calmer before
sending such a reminder.
The list archive is available at a few public sites:
http://news.gmane.org/gmane.comp.version-control.git/
http://marc.theaimsgroup.com/?l=git
http://www.spinics.net/lists/git/
For those who prefer to read it over NNTP (including the maintainer):
nntp://news.gmane.org/gmane.comp.version-control.git
When you point at a message in a mailing list archive, using
gmane is often the easiest to follow by readers, like this:
http://thread.gmane.org/gmane.comp.version-control.git/27/focus=217
as it also allows people who subscribe to the mailing list as gmane
newsgroup to "jump to" the article.
Some members of the development community can sometimes also be found
on the #git IRC channel on Freenode. Its log is available at:
http://colabti.org/irclogger/irclogger_log/git
* Reporting bugs
When you think git does not behave as you expect, please do not stop
your bug report with just "git does not work". "I used git in this
way, but it did not work" is not much better, neither is "I used git
in this way, and X happend, which is broken". It often is that git is
correct to cause X happen in such a case, and it is your expectation
that is broken. People would not know what other result Y you expected
to see instead of X, if you left it unsaid.
Please remember to always state
- what you wanted to achieve;
- what you did (the version of git and the command sequence to reproduce
the behavior);
- what you saw happen (X above);
- what you expected to see (Y above); and
- how the last two are different.
See http://www.chiark.greenend.org.uk/~sgtatham/bugs.html for further
hints.
* Repositories, branches and documentation.
My public git.git repositories are at:
git://git.kernel.org/pub/scm/git/git.git/
git://repo.or.cz/alt-git.git/
https://github.com/git/git/
https://code.google.com/p/git-core/
git://git.sourceforge.jp/gitroot/git-core/git.git/
git://git-core.git.sourceforge.net/gitroot/git-core/git-core/
A few gitweb interfaces are found at:
http://git.kernel.org/?p=git/git.git
http://repo.or.cz/w/alt-git.git
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/
https://code.google.com/p/git-{htmldocs,manpages}.git/
https://github.com/gitster/git-{htmldocs,manpages}.git/
You can browse the HTML manual pages at:
http://git-htmldocs.googlecode.com/git/git.html
There are four branches in git.git repository that track the source tree
of git: "master", "maint", "next", and "pu".
The "master" branch is meant to contain what are very well tested and
ready to be used in a production setting. Every now and then, a
"feature release" is cut from the tip of this branch and they
typically are named with three dotted decimal digits. The last such
release was 1.8.1 done on Dec 31, 2012 (or Jan 1, 2013, depending on
where you were when it happened). You can expect that the tip of the
"master" branch is always more stable than any of the released
versions.
Whenever a feature release is made, "maint" branch is forked off from
"master" at that point. Obvious, safe and urgent fixes after a feature
release are applied to this branch and maintenance releases are cut from
it. The maintenance releases are named with four dotted decimal, named
after the feature release they are updates to; the last such release was
1.8.1.2. New features never go to this branch. This branch is also
merged into "master" to propagate the fixes forward as needed.
A new development does not usually happen on "master". When you send a
series of patches, after review on the mailing list, a separate topic
branch is forked from the tip of "master" and your patches are queued
there, and kept out of "master" while people test it out. The quality of
topic branches are judged primarily by the mailing list discussions.
Topic branches that are in good shape are merged to the "next" branch. In
general, the "next" branch always contains the tip of "master". It might
not be quite rock-solid, but is expected to work more or less without major
breakage. The "next" branch is where new and exciting things take place. A
topic that is in "next" is expected to be polished to perfection before it
is merged to "master".
The "pu" (proposed updates) branch bundles all the remaining topic branches.
The topics on the branch are not complete, well tested, nor well documented
and need further work. When a topic that was in "pu" proves to be in a
testable shape, it is merged to "next".
You can run "git log --first-parent master..pu" to see what topics are
currently in flight. Sometimes, an idea that looked promising turns out
to be not so good and the topic can be dropped from "pu" in such a case.
The two branches "master" and "maint" are never rewound, and "next"
usually will not be either. After a feature release is made from
"master", however, "next" will be rebuilt from the tip of "master"
using the topics that didn't make the cut in the feature release.
Note that being in "next" is not a guarantee to appear in the next
release, nor even in any future release. There were cases that topics
needed reverting a few commits in them before graduating to "master",
or a topic that already was in "next" was reverted from "next" because
fatal flaws were found in it after it was merged.
* Other people's trees, trusted lieutenants and credits.
Documentation/SubmittingPatches outlines to whom your proposed changes
should be sent. As described in contrib/README, I would delegate fixes
and enhancements in contrib/ area to the primary contributors of them.
Although the following are included in git.git repository, they have their
own authoritative repository and maintainers:
- git-gui/ comes from git-gui project, maintained by Pat Thoyts:
git://repo.or.cz/git-gui.git
- gitk-git/ comes from Paul Mackerras's gitk project:
git://ozlabs.org/~paulus/gitk
- po/ comes from the localization coordinator, Jiang Xin:
https://github.com/git-l10n/git-po/
I would like to thank everybody who helped to raise git into the current
shape. Especially I would like to thank the git list regulars whose help
I have relied on and expect to continue relying on heavily:
- Linus Torvalds, Shawn Pearce, Johannes Schindelin, Nicolas Pitre,
René Scharfe, Jeff King, Jonathan Nieder, Johan Herland, Johannes
Sixt, Sverre Rabbelier, Michael J Gruber, Nguyễn Thái Ngọc Duy,
Ævar Arnfjörð Bjarmason and Thomas Rast for helping with general
design and implementation issues and reviews on the mailing list.
- Shawn and Nicolas Pitre for helping with packfile design and
implementation issues.
- Martin Langhoff, Frank Lichtenheld and Ævar Arnfjörð Bjarmason for
cvsserver and cvsimport.
- Paul Mackerras for gitk.
- Eric Wong, David D. Kilzer and Sam Vilain for git-svn.
- Simon Hausmann, Pete Wyckoff and Luke Diamond for git-p4.
- Jakub Narebski, John Hawley, Petr Baudis, Luben Tuikov, Giuseppe
Bilotta for maintaining and enhancing gitweb.
- Ævar Arnfjörð Bjarmason for kicking off the i18n effort, and Jiang
Xin for volunteering to be the l10n coordinator.
- Jens Lehmann, Heiko Voigt and Lars Hjemli for submodule related
Porcelains.
- J. Bruce Fields, Jonathan Nieder, Michael J Gruber and Thomas Rast for
documentation (and countless others for proofreading and fixing).
- Alexandre Julliard for Emacs integration.
- David Aguilar and Charles Bailey for taking good care of git-mergetool
(and Theodore Ts'o for creating it in the first place) and git-difftool.
- Johannes Schindelin, Johannes Sixt, Erik Faye-Lund, Pat Thoyts and others
for their effort to move things forward on the Windows front.
- People on non-Linux platforms for keeping their eyes on portability;
especially, Randal Schwartz, Theodore Ts'o, Jason Riedy, Thomas Glanzmann,
Brandon Casey, Jeff King, Alex Riesen and countless others.
^ permalink raw reply
* Re: Bug: file named - on git commit
From: Junio C Hamano @ 2013-01-28 20:51 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Thomas Rast, Rene Moser, git
In-Reply-To: <20130128204140.GA7759@google.com>
Jonathan Nieder <jrnieder@gmail.com> writes:
> Thomas Rast wrote:
>> Rene Moser <mail@renemoser.net> writes:
>
>>> Found a little issue in git version 1.7.9.5 if a file named "-", causing
>>> "git commit" to read from stdin.
>>>
>>> (So you must hit ctrl-d or ctrl-c to finish the commit.)
> [...]
>> This was fixed by Junio around 4682d85 (diff-index.c: "git diff" has no
>> need to read blob from the standard input, 2012-06-27), which is
>> included starting with v1.7.12 and the v1.7.11.3 maint release. Please
>> upgrade.
>
> Should upgrade-averse folks stuck on 1.7.10.y (like Debian 7.0, which
> is currently in the release candidate stage) take this fix? Do you
> happen to know of any other fixes such people would want?
FYI, the fix referred to in this thread are three-patch series that
forked from 1.7.6.6, so it should be trivial to merge it even to
such an old version.
The topic-branch workflow shines ;-)
^ permalink raw reply
* Re: [PATCH] l10n: de.po: translate 11 new messages
From: Philip Oakley @ 2013-01-28 20:52 UTC (permalink / raw)
To: Ralf Thielow, Joachim Schmitz; +Cc: git, jk, stimming, trast, Thomas Ackermann
In-Reply-To: <20130128181315.GB2926@rath-ubuntu>
From: "Ralf Thielow" <ralf.thielow@gmail.com>
Sent: Monday, January 28, 2013 6:13 PM
> On Mon, Jan 28, 2013 at 05:39:27PM +0100, Joachim Schmitz wrote:
>> Ralf Thielow wrote:
>> >Translate 11 new messages came from git.pot update
>> >in 46bc403 (l10n: Update git.pot (11 new, 7 removed
>> >messages)).
>> >
>> >Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com>
>> >---
>> > po/de.po | 37 ++++++++++++++++++-------------------
>> > 1 file changed, 18 insertions(+), 19 deletions(-)
>> >
>> >diff --git a/po/de.po b/po/de.po
>> >index 3779f4c..ed8330a 100644
>> >--- a/po/de.po
>> >+++ b/po/de.po
>> >@@ -5,7 +5,7 @@
>> > #
>> > msgid ""
>> > msgstr ""
>> >-"Project-Id-Version: git 1.8.1\n"
>> >+"Project-Id-Version: git 1.8.2\n"
Just noticing. Should this be s/git/Git/ to match the
* ta/doc-no-small-caps (2013-01-22) 10 commits
which is cooking?
>>
>> Not "Projekt-Id-Version ..."?
>>
>
> I don't think that we need to translate this.
>
>> > #: builtin/reset.c:33
>> > msgid "mixed"
>> >@@ -7916,9 +7915,9 @@ msgid "reset HEAD but keep local changes"
>> > msgstr "setzt Zweigspitze (HEAD) zurück, behält aber lokale
>> >Änderungen"
>>
>> Not "reset -> setze" and "keep" -> halte (imperativ)?
>> Or is the enlish text wrong and should be "resets" and "keeps"
>>
>
> All translations which describe an option shown by "git <command> -h"
> are (or should be) like this. The reading is like "This option..."
> followed by such a messages. That's at least how it's done. I don't
> think
> it sounds bad.
>
> According to the glossary, the translation here is wrong because
> "reset" is
> not "*zurück* setzen" but "neu setzen". I'll fix this (and perhaps
> other
> messages) on a commit on top.
>
>> Bye, Jojo
Philip Oakley
^ permalink raw reply
* Re: [PATCH] remove protocol from gravatar and picon links for clear if Gitweb is being called through a secure server
From: Jonathan Nieder @ 2013-01-28 20:58 UTC (permalink / raw)
To: Andrej Andb; +Cc: git, Giuseppe Bilotta, Jakub Narebski
In-Reply-To: <1359400490-16449-1-git-send-email-admin@andrej-andb.ru>
(cc-ing some area experts)
Hi Andrej,
Andrej Andb wrote:
> [Subject: remove protocol from gravatar and picon links for clear if
> Gitweb is being called through a secure server]
Sounds good to me. May we have your signoff? (See
Documentation/SubmittingPatches for what this means.)
Thanks,
Jonathan
(patch left unsnipped for reference)
> ---
> gitweb/gitweb.perl | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index c6bafe6..1309196 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -2068,7 +2068,7 @@ sub picon_url {
> if (!$avatar_cache{$email}) {
> my ($user, $domain) = split('@', $email);
> $avatar_cache{$email} =
> - "http://www.cs.indiana.edu/cgi-pub/kinzler/piconsearch.cgi/" .
> + "//www.cs.indiana.edu/cgi-pub/kinzler/piconsearch.cgi/" .
> "$domain/$user/" .
> "users+domains+unknown/up/single";
> }
> @@ -2083,7 +2083,7 @@ sub gravatar_url {
> my $email = lc shift;
> my $size = shift;
> $avatar_cache{$email} ||=
> - "http://www.gravatar.com/avatar/" .
> + "//www.gravatar.com/avatar/" .
> Digest::MD5::md5_hex($email) . "?s=";
> return $avatar_cache{$email} . $size;
> }
^ permalink raw reply
* Re: Bug: file named - on git commit
From: Junio C Hamano @ 2013-01-28 21:01 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Thomas Rast, Rene Moser, git
In-Reply-To: <20130128204140.GA7759@google.com>
Jonathan Nieder <jrnieder@gmail.com> writes:
> Thomas Rast wrote:
>> Rene Moser <mail@renemoser.net> writes:
>
>>> Found a little issue in git version 1.7.9.5 if a file named "-", causing
>>> "git commit" to read from stdin.
>>>
>>> (So you must hit ctrl-d or ctrl-c to finish the commit.)
> [...]
>> This was fixed by Junio around 4682d85 (diff-index.c: "git diff" has no
>> need to read blob from the standard input, 2012-06-27), which is
>> included starting with v1.7.12 and the v1.7.11.3 maint release. Please
>> upgrade.
>
> Should upgrade-averse folks stuck on 1.7.10.y (like Debian 7.0, which
> is currently in the release candidate stage) take this fix? Do you
> happen to know of any other fixes such people would want?
There are files with four dotted decimal numbers in their names in
the Documentation/RelNotes/ directory to help distro maintainers
like you to figure it want.
This is a tangent, but even with a project like git that is managed
with a good use of topic branch workflow, we may want to have a way
to reliably identify the tip of an ancient fix like this. People
may be able to bisect down to 4682d85, and in this particular case,
I happen to know that there wasn't any side-effect breakage
introduced by that commit, but there needs to be an easy way (it
can be expensive to compute) to make sure there is no follow-up fix
to that particular commit.
I can read "git rev-list --parents | grep -C3 $(git rev-parse 4682d85)"
and then figure out what the children commits of that fix are, of
course, but I suspect most people will view it as primitive ;-)
^ permalink raw reply
* Re: [PATCH v2 0/4] Auto-generate mergetool lists
From: John Keeping @ 2013-01-28 21:01 UTC (permalink / raw)
To: David Aguilar; +Cc: Junio C Hamano, git
In-Reply-To: <CAJDDKr75K3RGgU79nrznbpjQMLQGkDs=W8XEofURNsS1X1bvjg@mail.gmail.com>
On Sun, Jan 27, 2013 at 06:41:04PM -0800, David Aguilar wrote:
> John, I didn't completely address your question about keeping
> the sort and prefix in show_tool_help() but I can stop poking at
> it now in case you want to start looking at what it would take
> to get custom tools listed in the --tool-help output.
I've had a quick look and it's quite straightforward to build on top of
this to get an output format like this:
'git mergetool --tool-<tool>' may be set to one of the following:
araxis
gvimdiff
gvimdiff2
vimdiff
vimdiff2
user-defined:
mytool
The following tools are valid, but not currently available:
bc3
codecompare
deltawalker
diffuse
ecmerge
emerge
kdiff3
meld
opendiff
p4merge
tkdiff
tortoisemerge
xxdiff
user-defined:
mybrokentool
Some of the tools listed above only work in a windowed
environment. If run in a terminal-only session, they will fail.
I don't think the suffix form would be too hard either - it just
requires moving an explicit sort into the top-level shot_tool_help
function.
I'm going to hold off doing any more on this until da/mergetool-docs has
graduated to next since I think it will be easier to just build on that
rather than trying to put all the necessary pieces into place now.
John
^ permalink raw reply
* Re: [PATCH v2 0/4] Auto-generate mergetool lists
From: Philip Oakley @ 2013-01-28 21:19 UTC (permalink / raw)
To: David Aguilar; +Cc: Junio C Hamano, git, John Keeping
In-Reply-To: <CAJDDKr4BT_1YnnfJv-YFHOpWhYpuA_5CMRw_hPTiowMr49RLKQ@mail.gmail.com>
From: "David Aguilar" <davvid@gmail.com>
Sent: Monday, January 28, 2013 9:16 AM
> On Mon, Jan 28, 2013 at 12:20 AM, Philip Oakley <philipoakley@iee.org>
> wrote:
>> From: "David Aguilar" <davvid@gmail.com>
>> Sent: Monday, January 28, 2013 12:52 AM
>>
>>> This is round two of this series.
>>> I think this touched on everything brought up in the code review.
>>> 4/4 could use a review as I'm not completely familiar with the
>>> makefile dependencies, though it seems to work correctly.
>>
>>
>> Does this 4/4 have any effect on the Msysgit / Git for Windows
>> documentation
>> which simply refers [IIRC] to HTML documenation made by Junio?
>>
>> That is, how easy is it to create a 'default' set of docs, rather
>> than
>> personalised documenation. Or have I misunderstood how it is working?
>
> It doesn't have any effect on Msysgit. The resulting documentation
> lists all available tools, on all platforms.
>
That's useful to know. I must have misunderstood one of the earlier
messages suggesting it would also list all the users other (non typical)
installed mergetools and hence add them into the documentation.
Philip
^ permalink raw reply
* Re: [PATCH v4 1/2] for-each-repo: new command used for multi-repo operations
From: Jens Lehmann @ 2013-01-28 21:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Lars Hjemli, Jonathan Nieder, git, Heiko Voigt
In-Reply-To: <7vlibdvyh3.fsf@alter.siamese.dyndns.org>
Am 28.01.2013 21:34, schrieb Junio C Hamano:
> Jens Lehmann <Jens.Lehmann@web.de> writes:
>
>> Am 28.01.2013 19:51, schrieb Junio C Hamano:
>>> Lars Hjemli <hjemli@gmail.com> writes:
>>>
>>>>> Come to think of it, is there a reason why "for-each-repo" should
>>>>> not be an extention to "submodule foreach"? We can view this as
>>>>> visiting repositories that _could_ be registered as a submodule, in
>>>>> addition to iterating over the registered submodules, no?
>>>>
>>>> Yes, but I see some possible problems with that approach:
>>>> -'git for-each-repo' does not need to be started from within a git worktree
>>>
>>> True, but "git submodule foreach --untracked" can be told that it is
>>> OK not (yet) to be in any superproject, no?
>>
>> Hmm, I'm not sure how that would work as it looks for gitlinks
>> in the index which point to work tree paths.
>
> I was imagining that "foreach --untracked" could go something like this:
>
> * If you are inside an existing git repository, read its index to
> learn the gitlinks in the directory and its subdirectories.
>
> * Start from the current directory and recursively apply the
> procedure in this step:
>
> * Scan the directory and iterate over the ones that has ".git" in
> it:
>
> * If it is a gitlinked one, show it, but do not descend into it
> unless --recursive is given (e.g. you start from /home/jens,
> find /home/jens/proj/ directory that has /home/jens/proj/.git
> in it. /home/jens/.git/index knows that it is a submodule of
> the top-level superproject. "proj" is handled, and it is up
> to the --recursive option if its submodules are handled).
>
> * If it is _not_ a gitlinked one, show it and descend into it
> (e.g. /home/jens/ is not a repository or /home/jens/proj is
> not a tracked submodule) to apply this procedure recursively.
>
> Of course, without --untracked, we have no need to iterate over the
> readdir() return values; instead we just scan the index of the
> top-level superproject.
Thanks for explaining, that makes tons of sense.
>>>> -'git for-each-repo' and 'git submodule foreach' have different
>>>> semantics for --dirty and --clean
>>
>> I'm confused, what semantics of --dirty and --clean does current
>> 'git submodule foreach' have? I can't find any sign of it in the
>> current code ... did I miss something while skimming through this
>> thread? Or are you talking about status and diff here?
>
> I think Lars is hinting that "submodule foreach" could restrict its
> operation to a similar --dirty/--clean/--both option he has. Of
> course, the command given to foreach can decide to become no-op by
> inspecting the submodule itself, so in that sense, --dirty/--clean
> can be done without, but I think it would make sense to have it in
> "submodule foreach" even without the "--untracked" option.
Nice idea. E.g. that would help submodule users to easily script
a workflow which descends only into modified submodules to create
branches and push them there. Or to remove branches which were
created everywhere only in those submodules that weren't changed.
>> But I think the current for-each-repo
>> proposal doesn't allow to traverse repos which contain untracked
>> content (and it would be nice if the user could somehow combine
>> that with the current --dirty flag to have both in one go).
>
> Perhaps. I personally felt it was really strange that submodule
> diff and status consider that it is a sin to have untracked and
> unignored cruft in the submodule working tree, though.
The VCS we used at work before Git didn't show us any untracked
files, which caused trouble on a regular basis as people were
breaking builds for others because they forgot to check in new
files. That didn't happen with Git anymore, which was very cool.
But the problem reappeared as we started using submodules. Since
I taught status and diff to show that we're happy again. So for
us it was everything but strange ;-)
But for for-each-repo I would rather propose that modifications of
tracked files can optionally and/or solely be used to pick the
repos. Maybe: --dirty=modified, --dirty=untracked and --dirty=both
with --dirty defaulting to modified?
^ permalink raw reply
* Re: [PATCH v2 0/4] Auto-generate mergetool lists
From: Junio C Hamano @ 2013-01-28 21:50 UTC (permalink / raw)
To: John Keeping; +Cc: David Aguilar, git
In-Reply-To: <20130128210136.GC7498@serenity.lan>
John Keeping <john@keeping.me.uk> writes:
> I've had a quick look and it's quite straightforward to build on top of
> this to get an output format like this:
>
> 'git mergetool --tool-<tool>' may be set to one of the following:
> araxis
>...
> vimdiff2
>
> user-defined:
> mytool
>
> The following tools are valid, but not currently available:
> bc3
>...
> xxdiff
>
> user-defined:
> mybrokentool
>
> Some of the tools listed above only work in a windowed
> environment. If run in a terminal-only session, they will fail.
>
> I don't think the suffix form would be too hard either - it just
> requires moving an explicit sort into the top-level shot_tool_help
> function.
I tend to think that one-tool-per-line format like the above looks
nicer.
What are the situations where a valid user-defined tools is
unavailable, by the way?
^ permalink raw reply
* Re: [PATCH] remove protocol from gravatar and picon links for clear if Gitweb is being called through a secure server
From: Junio C Hamano @ 2013-01-28 21:54 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Andrej Andb, git, Giuseppe Bilotta, Jakub Narebski
In-Reply-To: <20130128205834.GC7759@google.com>
Jonathan Nieder <jrnieder@gmail.com> writes:
> (cc-ing some area experts)
> Hi Andrej,
>
> Andrej Andb wrote:
>
>> [Subject: remove protocol from gravatar and picon links for clear if
>> Gitweb is being called through a secure server]
>
> Sounds good to me. May we have your signoff? (See
> Documentation/SubmittingPatches for what this means.)
>
> Thanks,
> Jonathan
> (patch left unsnipped for reference)
>
>> ---
>> gitweb/gitweb.perl | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
>> index c6bafe6..1309196 100755
>> --- a/gitweb/gitweb.perl
>> +++ b/gitweb/gitweb.perl
>> @@ -2068,7 +2068,7 @@ sub picon_url {
>> if (!$avatar_cache{$email}) {
>> my ($user, $domain) = split('@', $email);
>> $avatar_cache{$email} =
>> - "http://www.cs.indiana.edu/cgi-pub/kinzler/piconsearch.cgi/" .
>> + "//www.cs.indiana.edu/cgi-pub/kinzler/piconsearch.cgi/" .
Hrmph. Is that even a valid URL to refer to that external site from
a https://my.site/some/where/ base URL? I wouldn't be surprised if
browsers allowed it, but I do not recall seeing such a use in RFCs.
Intuitively it feels strange that the above lets the site that gave
you the base URL dictate over what scheme sites unrelated to it has
to serve their resources.
^ permalink raw reply
* Re: [PATCH] remove protocol from gravatar and picon links for clear if Gitweb is being called through a secure server
From: Junio C Hamano @ 2013-01-28 21:58 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Andrej Andb, git, Giuseppe Bilotta, Jakub Narebski
In-Reply-To: <7vfw1lug6f.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
>>> - "http://www.cs.indiana.edu/cgi-pub/kinzler/piconsearch.cgi/" .
>>> + "//www.cs.indiana.edu/cgi-pub/kinzler/piconsearch.cgi/" .
>
> Hrmph. Is that even a valid URL to refer to that external site from
> a https://my.site/some/where/ base URL? I wouldn't be surprised if
> browsers allowed it, but I do not recall seeing such a use in RFCs.
ah, nevermind. That's net_path in 1808.
^ permalink raw reply
* Re: [PATCH] remove protocol from gravatar and picon links for clear if Gitweb is being called through a secure server
From: Jonathan Nieder @ 2013-01-28 22:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Andrej Andb, git, Giuseppe Bilotta, Jakub Narebski
In-Reply-To: <7vfw1lug6f.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
>> Andrej Andb wrote:
>>> --- a/gitweb/gitweb.perl
>>> +++ b/gitweb/gitweb.perl
>>> @@ -2068,7 +2068,7 @@ sub picon_url {
>>> if (!$avatar_cache{$email}) {
>>> my ($user, $domain) = split('@', $email);
>>> $avatar_cache{$email} =
>>> - "http://www.cs.indiana.edu/cgi-pub/kinzler/piconsearch.cgi/" .
>>> + "//www.cs.indiana.edu/cgi-pub/kinzler/piconsearch.cgi/" .
[...]
> Intuitively it feels strange that the above lets the site that gave
> you the base URL dictate over what scheme sites unrelated to it has
> to serve their resources.
The main effect is to slightly improve privacy. A man in the middle
can still see the size of avatars and when you fetched them, but at
least this way when you are using HTTPS they do not see the names of
authors of commits you are looking at.
It also avoids a mixed content warning.
On the other hand, it hurts caching by proxies.
Jonathan
^ permalink raw reply
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