* [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
* Re: [PATCH v2 0/4] Auto-generate mergetool lists
From: John Keeping @ 2013-01-28 22:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: David Aguilar, git
In-Reply-To: <7vk3qxugdg.fsf@alter.siamese.dyndns.org>
On Mon, Jan 28, 2013 at 01:50:19PM -0800, Junio C Hamano wrote:
> What are the situations where a valid user-defined tools is
> unavailable, by the way?
The same as a built-in tool: the command isn't available.
Currently I'm extracting the command word using:
cmd=$(eval -- "set -- $(git config mergetool.$tool.cmd); echo \"$1\"")
(it's slightly more complicated due to handling difftool.$tool.cmd as
well, but that's essentially it). Then it just uses the same "type
$cmd" test as for built-in tools.
I don't know if there's a better way to extract the first word, but
that's the best I've come up with so far.
John
^ 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 22:29 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Andrej Andb, git, Giuseppe Bilotta, Jakub Narebski
In-Reply-To: <20130128221026.GE7759@google.com>
Jonathan Nieder <jrnieder@gmail.com> writes:
> 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.
I am sure mixed content warning was the primary motivation of the
patch. Do we know these external sites actually server what we want
over https://?
^ permalink raw reply
* Re: [PATCH] remove protocol from gravatar and picon links for clear if Gitweb is being called through a secure server
From: Андрей Баранов @ 2013-01-28 22:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jonathan Nieder, git, Giuseppe Bilotta, Jakub Narebski
In-Reply-To: <7v7gmxuekl.fsf@alter.siamese.dyndns.org>
Or maybe option like:
/etc/gitweb.conf:
$feature{'ssl'}{'default'} = ['allways']; ['auto']; ['none'];
but it's hard for me :) i don't know perl
2013/1/29 Junio C Hamano <gitster@pobox.com>:
> Jonathan Nieder <jrnieder@gmail.com> writes:
>
>> 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.
>
> I am sure mixed content warning was the primary motivation of the
> patch. Do we know these external sites actually server what we want
> over https://?
>
^ 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:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Andrej Andb, git, Giuseppe Bilotta, Jakub Narebski
In-Reply-To: <7v7gmxuekl.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> I am sure mixed content warning was the primary motivation of the
> patch.
Sure, but that's not enough motivation for me to like it. ;-)
The privacy aspect is enough to motivate it for me.
> Do we know these external sites actually server what we want
> over https://?
Yep. cs.indiana.edu/cgi-pub/kinzler/piconsearch.cgi and
www.gravatar.com/avatar both support https and return the expected
responses for queries over https.
^ 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 23:08 UTC (permalink / raw)
To: Андрей Баранов
Cc: Jonathan Nieder, git, Giuseppe Bilotta, Jakub Narebski
In-Reply-To: <CAJjU7bQtgaV1XBeeGnuwtz8m3bDtmRYxQE-QasWkoGHNb_NPjQ@mail.gmail.com>
Андрей Баранов <admin@andrej-andb.ru> writes:
> Or maybe option like:
> /etc/gitweb.conf:
> $feature{'ssl'}{'default'} = ['allways']; ['auto']; ['none'];
>
> but it's hard for me :) i don't know perl
The effect is the same and your original patch is shorter and
cleaner to see what is going on; as far as the patch text is
concerned, the original one is just fine.
Except that we wanted a bit more stuff before "---" line. How about
something like this?
Subject: [PATCH] gitweb: refer to picon/gravatar images over the same scheme
The images from picon and gravatar are always used over
http://, and browsers give mixed contents warning when
gitweb is served over https://.
Just drop the scheme: part from the URL, so that these
external sites are accessed over https:// in such a case.
Signed-off-by: Your Name <your@addre.ss>
---
gitweb/gitweb.perl | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
...
^ permalink raw reply
* [PATCH] The images from picon and gravatar are always used over http://, and browsers give mixed contents warning when gitweb is served over https://.
From: Andrej E Baranov @ 2013-01-28 23:41 UTC (permalink / raw)
To: git; +Cc: gitster, jrnieder, giuseppe.bilotta, jnareb, Andrej E Baranov
Just drop the scheme: part from the URL, so that these
external sites are accessed over https:// in such a case.
Signed-off-by: Andrej E Baranov <admin@andrej-andb.ru>
---
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
* Re: [PATCH] remove protocol from gravatar and picon links for clear if Gitweb is being called through a secure server
From: Андрей Баранов @ 2013-01-28 23:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jonathan Nieder, git, Giuseppe Bilotta, Jakub Narebski
In-Reply-To: <7v38xkvrbc.fsf@alter.siamese.dyndns.org>
re sended. Very big thanks for example :D
2013/1/29 Junio C Hamano <gitster@pobox.com>:
> Андрей Баранов <admin@andrej-andb.ru> writes:
>
>> Or maybe option like:
>> /etc/gitweb.conf:
>> $feature{'ssl'}{'default'} = ['allways']; ['auto']; ['none'];
>>
>> but it's hard for me :) i don't know perl
>
> The effect is the same and your original patch is shorter and
> cleaner to see what is going on; as far as the patch text is
> concerned, the original one is just fine.
>
> Except that we wanted a bit more stuff before "---" line. How about
> something like this?
>
> Subject: [PATCH] gitweb: refer to picon/gravatar images over the same scheme
>
> The images from picon and gravatar are always used over
> http://, and browsers give mixed contents warning when
> gitweb is served over https://.
>
> Just drop the scheme: part from the URL, so that these
> external sites are accessed over https:// in such a case.
>
> Signed-off-by: Your Name <your@addre.ss>
> ---
> gitweb/gitweb.perl | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> ...
>
^ permalink raw reply
* [PATCH v2 0/3] transfer.hiderefs
From: Junio C Hamano @ 2013-01-29 0:13 UTC (permalink / raw)
To: git
So this is the second round, unifying the handling of "hidden refs"
a hosting site administrator may want to handle differently from
normal refs available to upload-pack and receive-pack. Big thanks
to Peff for making me realize that what is shown to "git push"
should match what is shown to "git fetch/clone".
The configuration variable has been changed to "transfer.hiderefs"
in this round. I picked refs.[ch] as the shared location to place
the machinery that deals with this configuration, but I am not proud
of the choice---there may be a more suitable place.
The third patch is new; it prevents a hidden ref to be deleted or
updated via "git push" to ensure that its contents are controlled
only from the server side using some side channel (e.g. pull-request
UI on the Web).
There is no "git fetch $there $exact_sha1_obtained_out_of_band"
yet; that must come next, together with a mechanism to control the
availability of it on the server side.
For those who missed it, the first round starts at
http://thread.gmane.org/gmane.comp.version-control.git/213951
Junio C Hamano (3):
upload-pack: share more code
upload-pack: allow hiding ref hiearchies
receive-pack: reject an attempt to update/delete a hidden ref
Documentation/config.txt | 9 +++++++++
builtin/receive-pack.c | 24 +++++++++++++++++++++++
refs.c | 41 +++++++++++++++++++++++++++++++++++++++
refs.h | 3 +++
t/t5512-ls-remote.sh | 9 +++++++++
t/t5516-fetch-push.sh | 24 +++++++++++++++++++++++
upload-pack.c | 50 ++++++++++++++++++++++++++++++++----------------
7 files changed, 144 insertions(+), 16 deletions(-)
--
1.8.1.2.548.g0e4986f
^ permalink raw reply
* [PATCH v2 1/3] upload-pack: share more code
From: Junio C Hamano @ 2013-01-29 0:13 UTC (permalink / raw)
To: git
In-Reply-To: <1359418412-26602-1-git-send-email-gitster@pobox.com>
We mark the objects pointed at our refs with "OUR_REF" flag in two
functions (mark_our_ref() and send_ref()), but we can just use the
former as a helper for the latter.
Update the way mark_our_ref() prepares in-core object to use
lookup_unknown_object() to delay reading the actual object data,
just like we did in 435c833 (upload-pack: use peel_ref for ref
advertisements, 2012-10-04).
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
upload-pack.c | 31 ++++++++++++++-----------------
1 file changed, 14 insertions(+), 17 deletions(-)
diff --git a/upload-pack.c b/upload-pack.c
index 95d8313..3dd220d 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -722,15 +722,28 @@ static void receive_needs(void)
free(shallows.objects);
}
+static int mark_our_ref(const char *refname, const unsigned char *sha1, int flag, void *cb_data)
+{
+ struct object *o = lookup_unknown_object(sha1);
+ if (!o)
+ die("git upload-pack: cannot find object %s:", sha1_to_hex(sha1));
+ if (!(o->flags & OUR_REF)) {
+ o->flags |= OUR_REF;
+ nr_our_refs++;
+ }
+ return 0;
+}
+
static int send_ref(const char *refname, const unsigned char *sha1, int flag, void *cb_data)
{
static const char *capabilities = "multi_ack thin-pack side-band"
" side-band-64k ofs-delta shallow no-progress"
" include-tag multi_ack_detailed";
- struct object *o = lookup_unknown_object(sha1);
const char *refname_nons = strip_namespace(refname);
unsigned char peeled[20];
+ mark_our_ref(refname, sha1, flag, cb_data);
+
if (capabilities)
packet_write(1, "%s %s%c%s%s agent=%s\n",
sha1_to_hex(sha1), refname_nons,
@@ -740,27 +753,11 @@ static int send_ref(const char *refname, const unsigned char *sha1, int flag, vo
else
packet_write(1, "%s %s\n", sha1_to_hex(sha1), refname_nons);
capabilities = NULL;
- if (!(o->flags & OUR_REF)) {
- o->flags |= OUR_REF;
- nr_our_refs++;
- }
if (!peel_ref(refname, peeled))
packet_write(1, "%s %s^{}\n", sha1_to_hex(peeled), refname_nons);
return 0;
}
-static int mark_our_ref(const char *refname, const unsigned char *sha1, int flag, void *cb_data)
-{
- struct object *o = parse_object(sha1);
- if (!o)
- die("git upload-pack: cannot find object %s:", sha1_to_hex(sha1));
- if (!(o->flags & OUR_REF)) {
- o->flags |= OUR_REF;
- nr_our_refs++;
- }
- return 0;
-}
-
static void upload_pack(void)
{
if (advertise_refs || !stateless_rpc) {
--
1.8.1.2.548.g0e4986f
^ permalink raw reply related
* [PATCH v2 2/3] upload-pack: allow hiding ref hiearchies
From: Junio C Hamano @ 2013-01-29 0:13 UTC (permalink / raw)
To: git
In-Reply-To: <1359418412-26602-1-git-send-email-gitster@pobox.com>
Teach upload-pack to omit some refs from the initial advertisement
by introducing the uploadPack.hiderefs multivalued configuration
variable. Any ref that is under the hierarchies listed on the value
of this variable is excluded from responses to "ls-remote", "fetch"
or "clone" requests. One typical use case may be
[uploadPack]
hiderefs = refs/changes
Note that the underlying protocol still allows a request to fetch
objects at the tip of any ref, including the hidden ones, but on the
client side (e.g. fetch-pack), the requests are checked against the
ls-remote response, so it cannot ask for refs/changes/14/432432, or
for the object name (which is what eventually goes over the wire on
"want" line) the user may obtain out of band (e.g. Gerrit dashboard).
A new capability "allow-tip-sha1-in-want" is returned by upload-pack
to signal updated clients that it may be OK to ask for objects that
were not advertised.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Documentation/config.txt | 8 ++++++++
builtin/receive-pack.c | 8 ++++++++
refs.c | 41 +++++++++++++++++++++++++++++++++++++++++
refs.h | 3 +++
t/t5512-ls-remote.sh | 9 +++++++++
upload-pack.c | 25 +++++++++++++++++++++++--
6 files changed, 92 insertions(+), 2 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index ef45c99..8e2853e 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -2057,6 +2057,14 @@ transfer.fsckObjects::
not set, the value of this variable is used instead.
Defaults to false.
+transfer.hiderefs::
+ String(s) `upload-pack` and `receive-pack` use to decide
+ which refs to omit from their initial advertisement. Use
+ more than one transfer.hiderefs configuration variables to
+ specify multiple prefix strings. A ref that has one of these
+ strings as its prefix is excluded, and is hidden from
+ `git clone --mirror` and `git push :`.
+
transfer.unpackLimit::
When `fetch.unpackLimit` or `receive.unpackLimit` are
not set, the value of this variable is used instead.
diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c
index ff781fe..5ed40be 100644
--- a/builtin/receive-pack.c
+++ b/builtin/receive-pack.c
@@ -59,6 +59,11 @@ static enum deny_action parse_deny_action(const char *var, const char *value)
static int receive_pack_config(const char *var, const char *value, void *cb)
{
+ int status = parse_hide_refs_config(var, value, cb);
+
+ if (status)
+ return status;
+
if (strcmp(var, "receive.denydeletes") == 0) {
deny_deletes = git_config_bool(var, value);
return 0;
@@ -119,6 +124,9 @@ static int receive_pack_config(const char *var, const char *value, void *cb)
static void show_ref(const char *path, const unsigned char *sha1)
{
+ if (ref_is_hidden(path))
+ return;
+
if (sent_capabilities)
packet_write(1, "%s %s\n", sha1_to_hex(sha1), path);
else
diff --git a/refs.c b/refs.c
index 541fec2..e3574ca 100644
--- a/refs.c
+++ b/refs.c
@@ -3,6 +3,7 @@
#include "object.h"
#include "tag.h"
#include "dir.h"
+#include "string-list.h"
/*
* Make sure "ref" is something reasonable to have under ".git/refs/";
@@ -2556,3 +2557,43 @@ char *shorten_unambiguous_ref(const char *refname, int strict)
free(short_name);
return xstrdup(refname);
}
+
+static struct string_list *hide_refs;
+
+int parse_hide_refs_config(const char *var, const char *value, void *unused)
+{
+ if (!strcmp("transfer.hiderefs", var)) {
+ char *ref;
+ int len;
+
+ if (!value)
+ return config_error_nonbool(var);
+ ref = xstrdup(value);
+ len = strlen(ref);
+ while (len && ref[len - 1] == '/')
+ ref[--len] = '\0';
+ if (!hide_refs) {
+ hide_refs = xcalloc(1, sizeof(*hide_refs));
+ hide_refs->strdup_strings = 1;
+ }
+ string_list_append(hide_refs, ref);
+ }
+ return 0;
+}
+
+int ref_is_hidden(const char *refname)
+{
+ struct string_list_item *item;
+
+ if (!hide_refs)
+ return 0;
+ for_each_string_list_item(item, hide_refs) {
+ int len;
+ if (prefixcmp(refname, item->string))
+ continue;
+ len = strlen(item->string);
+ if (!refname[len] || refname[len] == '/')
+ return 1;
+ }
+ return 0;
+}
diff --git a/refs.h b/refs.h
index d6c2fe2..50b233f 100644
--- a/refs.h
+++ b/refs.h
@@ -147,4 +147,7 @@ int update_ref(const char *action, const char *refname,
const unsigned char *sha1, const unsigned char *oldval,
int flags, enum action_on_err onerr);
+extern int parse_hide_refs_config(const char *var, const char *value, void *);
+extern int ref_is_hidden(const char *);
+
#endif /* REFS_H */
diff --git a/t/t5512-ls-remote.sh b/t/t5512-ls-remote.sh
index d16e5d3..d0702ed 100755
--- a/t/t5512-ls-remote.sh
+++ b/t/t5512-ls-remote.sh
@@ -126,4 +126,13 @@ test_expect_success 'Report match with --exit-code' '
test_cmp expect actual
'
+test_expect_success 'Hide some refs' '
+ test_config transfer.hiderefs refs/tags &&
+ git ls-remote . >actual &&
+ test_unconfig transfer.hiderefs &&
+ git ls-remote . |
+ sed -e "/ refs\/tags\//d" >expect &&
+ test_cmp expect actual
+'
+
test_done
diff --git a/upload-pack.c b/upload-pack.c
index 3dd220d..31ce954 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -12,6 +12,7 @@
#include "run-command.h"
#include "sigchain.h"
#include "version.h"
+#include "string-list.h"
static const char upload_pack_usage[] = "git upload-pack [--strict] [--timeout=<n>] <dir>";
@@ -28,10 +29,12 @@ static const char upload_pack_usage[] = "git upload-pack [--strict] [--timeout=<
static unsigned long oldest_have;
-static int multi_ack, nr_our_refs;
+static int multi_ack;
+static int nr_our_refs; /* This counts both advertised and unadvertised */
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;
@@ -743,11 +746,14 @@ static int send_ref(const char *refname, const unsigned char *sha1, int flag, vo
unsigned char peeled[20];
mark_our_ref(refname, sha1, flag, cb_data);
+ if (ref_is_hidden(refname))
+ 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
@@ -758,11 +764,20 @@ static int send_ref(const char *refname, const unsigned char *sha1, int flag, vo
return 0;
}
+static int check_hidden_ref(const char *refname, const unsigned char *sha1, int flag, void *cb_data)
+{
+ if (!ref_is_hidden(refname))
+ return 0;
+ allow_tip_sha1_in_want = 1;
+ return 1; /* terminate iteration over refs early */
+}
+
static void upload_pack(void)
{
if (advertise_refs || !stateless_rpc) {
reset_timeout();
head_ref_namespaced(send_ref, NULL);
+ for_each_namespaced_ref(check_hidden_ref, NULL);
for_each_namespaced_ref(send_ref, NULL);
packet_flush(1);
} else {
@@ -779,6 +794,11 @@ static void upload_pack(void)
}
}
+static int upload_pack_config(const char *var, const char *value, void *unused)
+{
+ return parse_hide_refs_config(var, value, unused);
+}
+
int main(int argc, char **argv)
{
char *dir;
@@ -830,6 +850,7 @@ int main(int argc, char **argv)
die("'%s' does not appear to be a git repository", dir);
if (is_repository_shallow())
die("attempt to fetch/clone from a shallow repository");
+ git_config(upload_pack_config, NULL);
if (getenv("GIT_DEBUG_SEND_PACK"))
debug_fd = atoi(getenv("GIT_DEBUG_SEND_PACK"));
upload_pack();
--
1.8.1.2.548.g0e4986f
^ permalink raw reply related
* [PATCH v2 3/3] receive-pack: reject an attempt to update/delete a hidden ref
From: Junio C Hamano @ 2013-01-29 0:13 UTC (permalink / raw)
To: git
In-Reply-To: <1359418412-26602-1-git-send-email-gitster@pobox.com>
An attempt to update or delete a ref that is hidden from "git push"
is rejected. With this the server side can implement refs that are
only available for its own use, e.g. refs/pull/11/head used to hold
an incoming pull request at GitHub.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Documentation/config.txt | 3 ++-
builtin/receive-pack.c | 16 ++++++++++++++++
t/t5516-fetch-push.sh | 24 ++++++++++++++++++++++++
3 files changed, 42 insertions(+), 1 deletion(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 8e2853e..b7b407b 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -2063,7 +2063,8 @@ transfer.hiderefs::
more than one transfer.hiderefs configuration variables to
specify multiple prefix strings. A ref that has one of these
strings as its prefix is excluded, and is hidden from
- `git clone --mirror` and `git push :`.
+ `git clone --mirror` and `git push :`. An attempt to update
+ or delete a hidden ref by `git push` is rejected.
transfer.unpackLimit::
When `fetch.unpackLimit` or `receive.unpackLimit` are
diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c
index 5ed40be..a8248d9 100644
--- a/builtin/receive-pack.c
+++ b/builtin/receive-pack.c
@@ -696,6 +696,20 @@ static int iterate_receive_command_list(void *cb_data, unsigned char sha1[20])
return -1; /* end of list */
}
+static void reject_updates_to_hidden(struct command *commands)
+{
+ struct command *cmd;
+
+ for (cmd = commands; cmd; cmd = cmd->next) {
+ if (cmd->error_string || !ref_is_hidden(cmd->ref_name))
+ continue;
+ if (is_null_sha1(cmd->new_sha1))
+ cmd->error_string = "deny deleting a hidden ref";
+ else
+ cmd->error_string = "deny updating a hidden ref";
+ }
+}
+
static void execute_commands(struct command *commands, const char *unpacker_error)
{
struct command *cmd;
@@ -712,6 +726,8 @@ static void execute_commands(struct command *commands, const char *unpacker_erro
0, &cmd))
set_connectivity_errors(commands);
+ reject_updates_to_hidden(commands);
+
if (run_receive_hook(commands, pre_receive_hook, 0)) {
for (cmd = commands; cmd; cmd = cmd->next) {
if (!cmd->error_string)
diff --git a/t/t5516-fetch-push.sh b/t/t5516-fetch-push.sh
index 6009372..8e8287a 100755
--- a/t/t5516-fetch-push.sh
+++ b/t/t5516-fetch-push.sh
@@ -1037,4 +1037,28 @@ test_expect_success 'push --prune refspec' '
! check_push_result $the_first_commit tmp/foo tmp/bar
'
+test_expect_success 'push to update a hidden ref' '
+ mk_test heads/master hidden/one hidden/two hidden/three &&
+ (
+ cd testrepo &&
+ git config transfer.hiderefs refs/hidden
+ ) &&
+
+ # 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 fail
+ test_must_fail git push testrepo master:refs/hidden/one &&
+ check_push_result $the_first_commit hidden/one &&
+
+ # push to delete a hidden ref should fail
+ test_must_fail git push testrepo master:refs/hidden/two &&
+ check_push_result $the_first_commit hidden/two &&
+
+ # idempotent push to update a hidden ref should fail
+ test_must_fail git push testrepo $the_first_commit:refs/hidden/three &&
+ check_push_result $the_first_commit hidden/three
+'
+
test_done
--
1.8.1.2.548.g0e4986f
^ 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