Re: git-completion.tcsh
Gábor, I updated git to include the macports install with bash completion. under bash it does not exhibit the problem as I described it. To be sure that the completion scripts installed via macports weren’t newer/different (the .bash completion file had a few minor diffs from what I had been using), i reinstalled the tcsh completion using those files, but the same behavior happened. So i’m seeing what you’re seeing, bash completion works fine, it’s likely to be something in the wrapper handling. (updated) environment Darwin 14.3.0 Darwin Kernel Version 14.3.0: Mon Mar 23 11:59:05 PDT 2015; root:xnu-2782.20.48~5/RELEASE_X86_64 x86_64 (OS X 10.10.3) Apple Terminal Version 2.5.3 (343.7) git 2.3.4 (+bash_completion, via MacPorts) tcsh 6.17.00 (Astron) 2009-07-10 (x86_64-apple-darwin) options wide,nls,dl,al,kan,sm,rh,color,filec GNU bash, version 4.3.33(1)-release (x86_64-apple-darwin14.0.0) Thanks! Perry > On Apr 1, 2015, at 20:55, SZEDER Gábor wrote: > > > Quoting Perry Rajnovic : > >> When using the auto-completion included with git for tcsh, several >> commands do directly completion with an additional space appended to >> the end, which defeats the ability to complete to a deeper >> sub-directory. >> >> For example, if I have a git repository including the following: >> basedir/foo/bar/somefile.c >> >> (works as expected, git add) >> $ cd basedir >> $ git add f >> $ git add foo/ >> $ git add foo/b >> $ git add foo/bar/ >> $ git add foo/bar/s >> $ git add foo/bar/somefile.c >> >> (works not as expected, git rm) >> $ cd basedir >> $ git rm f >> $ git rm foo >> $ git rm foo/b >> $ git rm foo/bar >> there’s a trailing space after foo and bar in the above lines, which >> means it’s not possible to initiate completion or immediately start >> typing, i must back-space before continuing. >> >> I’m fairly certain i’ve seen this for other commands as well, but >> i’m not sure to what extent this occurs throughout the commands. >> >> Environment info: >> OS: Darwin 14.1.0 Darwin Kernel Version 14.1.0: Thu Feb 26 19:26:47 >> PST 2015; root:xnu-2782.10.73~1/RELEASE_X86_64 x86_64 (OSX 10.10.2) >> Apple Terminal Version 2.5.1 (343.6) >> git version 2.3.2 (via MacPorts) >> tcsh 6.17.00 (Astron) 2009-07-10 (x86_64-apple-darwin) options >> wide,nls,dl,al,kan,sm,rh,color,filec > > The tcsh completion script is just a wrapper, it relies on the bash > completion script to do the heavy lifting and tunnels its output int > tcsh's completion infrastructure. > Could you try bash completion in your environment first to see, > whether it's a bash completion issue that I can't reproduce or an > issue with the tcsh wrapper? > > Cc'ing Marc, author of the tcsh wrapper. > > > Gábor -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] l10n updates for 2.4.0 round 2
Thanks, all. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] fix global bash variable leak on __gitcompappend
"Márcio Almada" writes:
> ---
> contrib/completion/git-completion.bash | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Nicely found and corrected. Please sign-off your patch and Cc area
experts if you can find them (I'll do that this time for you).
Thanks.
>
> diff --git a/contrib/completion/git-completion.bash
> b/contrib/completion/git-completion.bash
> index 661a829..1620546 100644
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -186,7 +186,7 @@ fi
>
> __gitcompappend ()
> {
> - local i=${#COMPREPLY[@]}
> + local x i=${#COMPREPLY[@]}
> for x in $1; do
> if [[ "$x" == "$3"* ]]; then
> COMPREPLY[i++]="$2$x$4"
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Shallow Push?
Samuel Williams writes: > Is it possible to only push what is required to checkout the latest HEAD? What is the receiving repository expected to have? Does it have everything that is required to checkout the back-then latest HEAD the last time a push was made into it, and you are pushing an update? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [v6 PATCH] daemon: add systemd support
Ramsay Jones writes:
> On 07/04/15 03:03, Shawn Landden wrote:
>> systemd supports git-daemon's existing --inetd mode as well.
>> --systemd allows git-daemon has the advantage of allowing one git-daemon
>> to listen to multiple interfaces as well as the system one(s),
>> and more allow git-daemon to not be spawned on every connection.
>>
>> Signed-off-by: Shawn Landden
>> ---
>
> I have not been following this patch review, but I just happened to
> notice something while skimming the patch as this email floated by ...
>
>> Respond to review by Eric Sunshine here:
>> http://marc.info/?l=git&m=142836529908207&w=2
>>
>
> [snip]
>
>> diff --git a/daemon.c b/daemon.c
>> index 9ee2187..9880858 100644
>> --- a/daemon.c
>> +++ b/daemon.c
>> @@ -1,3 +1,7 @@
>> +#ifdef HAVE_SYSTEMD
>> +# include
>> +#endif
>> +
>> #include "cache.h"
>> #include "pkt-line.h"
>> #include "exec_cmd.h"
>> @@ -28,7 +32,11 @@ static const char daemon_usage[] =
>> " [--(enable|disable|allow-override|forbid-override)=]\n"
>> " [--access-hook=]\n"
>> " [--inetd | [--listen=] [--port=]\n"
>> +#ifdef HAVE_SYSTEMD
>> +" [--systemd | [--detach] [--user=
>> [--group=]]]\n" /* exactly 80 characters */
>> +#else
>> " [--detach] [--user= [--group=]]\n"
>> +#endif
>> " [...]";
>>
>> /* List of acceptable pathname prefixes */
>> @@ -1176,11 +1184,23 @@ static void store_pid(const char *path)
>> }
>>
>> static int serve(struct string_list *listen_addr, int listen_port,
>> -struct credentials *cred)
>> +struct credentials *cred, int systemd_mode)
>> {
>> struct socketlist socklist = { NULL, 0, 0 };
>>
>
> ... this hunk splits a statement in two ...
>
>> -socksetup(listen_addr, listen_port, &socklist);
>> +#ifdef HAVE_SYSTEMD
>> +if (systemd_mode) {
>> +int i, n;
>> +
>> +n = sd_listen_fds(0);
>> +ALLOC_GROW(socklist.list, socklist.nr + n, socklist.alloc);
>> +for (i = 0; i < n; i++)
>> +socklist.list[socklist.nr++] = SD_LISTEN_FDS_START + i;
>> +}
>> +
>> +if (listen_addr->nr > 0 || !systemd_mode)
>> +#endif
>> +socksetup(listen_addr, listen_port, &socklist);
>
> ... here. I have not considered any possible subtlety in the code, but simply
> considering the patch text, I think the following may be easier to read:
>
> #ifdef HAVE_SYSTEMD
> if (systemd_mode) {
> ...
> }
>
> if (listen_addr->nr > 0 || !systemd_mode)
> socksetup(listen_addr, listen_port, &socklist);
> #else
> socksetup(listen_addr, listen_port, &socklist);
> #endif
>
> Or, maybe:
>
> #if !defined(HAVE_SYSTEMD)
> socksetup(listen_addr, listen_port, &socklist);
> #else
> ...
> #endif
>
> Or, ... ;-)
Yes, I'd really prefer to avoid #if/#else#endif in the main
codeflow.
It is vastly prefereable, if you can arrange so, to have a set of
helper functions
#if USE_SYSTEMD
static void enumerate_sockets(struct socklist *slist)
{
... /* do systemd specific enumeration */
}
#else
static void enumerate_sockets(struct socklist *slist)
{
... /* something else */
}
#endif
and then just call that helper from the main codeline.
enumerate_sockets(&socklist);
socksetup(...);
without #ifdef/#else/#endif
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 4/4] t1006: add tests for git cat-file --literally
On April 9, 2015 2:04:08 AM GMT+05:30, Eric Sunshine wrote: >On Wed, Apr 8, 2015 at 1:42 PM, karthik nayak >wrote: >> On 04/08/2015 02:19 AM, Eric Sunshine wrote: >>> On Sat, Apr 4, 2015 at 1:44 AM, Karthik Nayak > >>> wrote: >>> > Signed-off-by: Karthik Nayak >>> > --- >>> > diff --git a/t/t1006-cat-file.sh b/t/t1006-cat-file.sh >>> > index ab36b1e..5b74044 100755 >>> > --- a/t/t1006-cat-file.sh >>> > +++ b/t/t1006-cat-file.sh >>> > @@ -296,4 +308,19 @@ test_expect_success '%(deltabase) reports >packed >>> > delta bases' ' >>> > } >>> > ' >>> > >>> > +bogus_type="bogus" >>> > +bogus_sha1=$(git hash-object -t $bogus_type --literally -w >--stdin >>> > >> > + >>> > +test_expect_success "Type of broken object is correct" ' >>> > + echo $bogus_type >expect && >>> > + git cat-file -t --literally $bogus_sha1 >actual && >>> > + test_cmp expect actual >>> > +' >>> > + >>> > +test_expect_success "Size of broken object is correct" ' >>> > + echo "0" >expect && >>> >>> Zero is such a common fallback value when things go wrong that it >may >>> not be the best choice for this test. Consequently, it might be >better >>> to create the bogus object with non-zero length. Take a look at how >>> 'hello_length' and 'hello_sha1' are computed elsewhere in this >script >>> for inspiration. >> >> The first part of this patch contains tests which make use of >'hello_length' >> adn 'hello_sha1', but I get what you're saying, will look into it. >Thanks. > >Just to be sure we're on the same page, I wasn't suggesting re-using >'hello_size' and 'hello_sha1', but merely to use that as an example of >how to avoid hard-coding the length of your non-zero-length bogus >object. So, something like this, perhaps: > >bogus_content='bogus' >bogus_size=$(strlen "$bogus_content") >bogus_sha1=$(echo_without_newline "$bogus_content" | >git hash-object -t $bogus_type --literally -w --stdin) >... >test_expect_success "Size of broken object is correct" ' >echo $bogus_size >expect && >... Yes, I had done exactly what you suggested here. Thanks -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[ANNOUNCE] tig-2.1.1
Hi, This release fixes a couple of regressions that broke rendering of references in the main view and usage of the stage view. It also adds support for key combos which was originally planed for 2.1 (see contrib/vim.tigrc for an example). Finally, files (or blobs) can now be searched using the new GitHub-inspired file finder (press 'f' to launch it). - Homepage: http://jonas.nitro.dk/tig/ - Manual: http://jonas.nitro.dk/tig/manual.html - Tarballs: http://jonas.nitro.dk/tig/releases/ - Git URL: git://github.com/jonas/tig.git - Gitter: https://gitter.im/jonas/tig - Q&A: http://stackoverflow.com/questions/tagged/tig Release notes - Improvements: - Add support for key combos. (GH #67) - See `contrib/vim.tigrc` for Vim-like keybindings. (GH #273, #351) - Add GitHub inspired file finder to search for and open any file. (GH #342) - Add `search` keymap for navigation file finder search results. Bug fixes: - Fix display of multiple references per commit. (GH #390, #391) - Sync the prompt's cursor position with readline's internal position. (#396) - Keep unstaged changes view open after an staging command. (#399) Change summary -- The diffstat and log summary for changes made in this release. .gitignore | 3 + COPYING | 39 ++-- Makefile | 45 - NEWS.adoc| 16 ++ README.adoc | 2 +- config.make.in | 5 +- configure.ac | 5 + contrib/vim.tigrc| 73 doc/tigrc.5.adoc | 3 +- include/tig/blob.h | 7 +- include/tig/display.h| 2 +- include/tig/keys.h | 10 +- include/tig/main.h | 2 + include/tig/prompt.h | 1 + include/tig/ui.h | 20 ++ src/blob.c | 29 ++- src/display.c| 19 +- src/keys.c | 56 -- src/main.c | 20 ++ src/options.c| 2 +- src/prompt.c | 25 +-- src/refdb.c | 21 ++- src/stage.c | 22 +-- src/status.c | 2 + src/tig.c| 58 -- src/ui.c | 304 +++ test/help/all-keybindings-test | 10 +- test/help/default-test | 14 +- test/main/graph-argument-test| 28 +-- test/main/show-changes-test | 24 +++ test/main/start-on-line-test | 42 ++--- test/main/view-split-test| 18 +- test/regressions/github-390-test | 41 + test/status/file-name-test | 8 +- test/tigrc/compat-error-test | 2 - test/tigrc/parse-test| 4 +- tigrc| 7 + tools/aspell.dict| 12 +- tools/gcov.m4| 94 ++ 39 files changed, 912 insertions(+), 183 deletions(-) Alexander Sulfrian (1): Fix insertion/ordering of refs in refs_by_id map. Andreas Stieger (1): Update FSF address in COPYING Jonas Fonseca (12): Remove Gitweb link in favour of Gitter Integrate coverage reporting for the test suite Experimental support for key combos Fix user-action prompt display regression Add key_to_value helper to extract the ncurses key value Add GitHub inspired file finder to search for and open any file Fix regression test to exec git-tag in background Fix display saving to account for variable length UTF-8 characters When redrawing the readline prompt also update the cursor position Keep unstaged changes view open after an staging command Add search keymap with keys for navigating search results tig-2.1.1 Ramsay Jones (1): Fix segmentation Fault on 32-bit Vivien Didelot (1): contrib: complete Vim-like bindings -- Jonas Fonseca -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL] l10n updates for 2.4.0 round 2
Hi, Junio The following changes since commit 6ae0d972664134b82a6dd164a01e8adbebeaffe3: Git 2.4.0-rc1 (2015-04-02 12:46:06 -0700) are available in the git repository at: git://github.com/git-l10n/git-po tags/l10n-2.4.0-rnd2 for you to fetch changes up to 44cc742a8ca17b9c279be4cc195a93a6ef7a320e: Merge branch 'master' of git://github.com/alexhenrie/git-po (2015-04-09 08:21:39 +0800) git l10n 2.4.0-rnd2 Alex Henrie (2): l10n: ca.po: update translation l10n: ca.po: update translation Alexander Shopov (1): l10n: Updated Bulgarian translation of git (2305t,0f,0u) Dimitriy Ryazantcev (3): l10n: ru: added Russian translation l10n: ru: updated Russian translation l10n: ru: updated Russian translation Jean-Noel Avila (2): l10n: fr.po v2.4.0-rc0 round 1 l10n: fr.po v2.4.0 round 2 Jiang Xin (10): Merge branch 'russian-l10n' of https://github.com/DJm00n/git-po-ru l10n: git.pot: v2.4.0 round 1 (99 new, 92 removed) Merge branch 'maint' Merge branch 'fr-v2.4.0-rc0' of git://github.com/jnavila/git l10n: zh_CN: translations for git v2.4.0-rc0 Merge branch 'master' of git://github.com/git-l10n/git-po l10n: git.pot: v2.4.0 round 2 (1 update) l10n: zh_CN: for git v2.4.0 l10n round 2 l10n: TEAMS: Change repository URL of zh_CN Merge branch 'master' of git://github.com/alexhenrie/git-po Matthias Rüster (1): l10n: de.po: translate 'symbolic link' as 'symbolische Verknüpfung' Michael J Gruber (1): l10n: de.po: fix negation for commit -a with paths Peter Krefting (2): l10n: sv.po: Update Swedish translation (2305t0f0u) l10n: sv.po: Update Swedish translation (2305t0f0u) Phillip Sz (1): l10n: de.po: add space before ellipsis Ralf Thielow (3): l10n: de.po: fix messages with abbreviated hashs l10n: de.po: translate 99 new messages l10n: de.po: translate one message Trần Ngọc Quân (2): l10n: vi.po: Updated Vietnamese translation l10n: vi.po(2305t): Updated 1 new string po/TEAMS| 7 +- po/bg.po| 2892 po/ca.po| 1877 ++- po/de.po| 1895 ++- po/fr.po| 1880 ++- po/git.pot | 1659 - po/ru.po| 10633 ++ po/sv.po| 1850 +- po/vi.po| 1897 ++- po/zh_CN.po | 2212 ++-- 10 files changed, 18704 insertions(+), 8098 deletions(-) create mode 100644 po/ru.po -- Jiang Xin -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Notes do not follow rebase
On Wed, Apr 8, 2015 at 8:40 PM, Phillip Susi wrote: > After doing a rebase -i to fix up some older commits, I noticed that > notes I had associated with commits failed to follow the commit across > the rebase, so the notes are now orphaned and will be pruned. > Shouldn't notes be copied to the new commit during an ammend/rebase? It depends. Which notes do you want copied? (i.e. from which notes ref?) Please have a look at the notes.rewriteRef config option (documented in the git-config and git-notes manual pages) ...Johan -- Johan Herland, www.herland.net -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[ANNOUNCE] Git LFS v0.5.0 - Large File Storage
Hi, Today we're releasing Git Large File Storage (LFS), an open source extension that replaces large files with text pointers, while pushing the contents to a Git LFS server. https://git-lfs.github.com It's similar to Git Media, with a few notable exceptions: * It talks to a Git LFS API. No need to configure different backends on the client. * HTTPS and SSH authentication is supported. * It's distributed as a static binary for Linux, Mac, and Windows, no compilation or runtime needed. The full source is provided with an MIT license, so you can also build it yourself with Go. - Homepage: https://git-lfs.github.com - Download: https://github.com/github/git-lfs/releases/tag/v0.5.0 - Git URL: https://github.com/github/git-lfs - API Spec: https://github.com/github/git-lfs/blob/master/docs/api.md - Reference Server: https://github.com/github/lfs-test-server - Git Media: https://github.com/alebedev/git-media -- Rick Olson -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re:
Am 08.04.2015 um 22:44 schrieb Mamta Upadhyay: > Hi git team, (CC'ing msysgit as this is the git for windows list) Hi Mamta, > I tried to research everywhere on a issue I am facing and emailing you > as the last resource. This is critical for me and I needed your help. > > I am trying to run the latest git 1.9.5 installer on windows. When I > run strings on libneon-25.dll it shows this: > > ./libneon-25.dll:OpenSSL 1.0.1h 5 Jun 2014 > > But when I load this dll in dependency walker, it picks up > msys-openssl 1.0.1m and has no trace of openssl-1.0.1h. My questions > to you: > > 1. Is libneon-25.dll statically linked with openssl-1.0.1h? > 2. If not, where is the reference to 1.0.1h coming from? I would be suprised if we link openssl statically into libneon. I guess libneon just reports against which openssl version it was *built*. > I am asked to rebuild git with libneon-25.dll linked against > openssl-1.0.1m. But I am having a feeling that this is not needed, > since libneon is already picking the latest openssl version. Can you > please confirm? You can download the development enviroment for git for windows here [1]. After installation, checkout the msys branch and then you can try to recomplile libneon using /src/subversion/release.sh. [1]: https://github.com/msysgit/msysgit/releases/download/Git-1.9.5-preview20150319/msysGit-netinstall-1.9.5-preview20150319.exe Hope that helps Thomas -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] clean: improve performance when removing lots of directories
On Tue, Apr 7, 2015 at 3:55 PM, erik elfström wrote:
> On Tue, Apr 7, 2015 at 12:10 AM, Eric Sunshine
> wrote:
>> On Mon, Apr 6, 2015 at 7:48 AM, Erik Elfström
>> wrote:
>>> diff --git a/builtin/clean.c b/builtin/clean.c
>>> index 98c103f..e951bd9 100644
>>> --- a/builtin/clean.c
>>> +++ b/builtin/clean.c
>>> +static int is_git_repository(struct strbuf *path)
>>> +{
>>> + int ret = 0;
>>> + if (is_git_directory(path->buf))
>>> + ret = 1;
>>> + else {
>>> + int orig_path_len = path->len;
>>> + if (path->buf[orig_path_len - 1] != '/')
>>
>> Minor: I don't know how others feel about it, but I always find it a
>> bit disturbing to see a potential negative array access without a
>> safety check that orig_path_len is not 0, either directly in the
>> conditional or as a documenting assert().
>
> I think I would prefer to accept empty input and return false rather
> than assert. What to you think about:
>
> static int is_git_repository(struct strbuf *path)
> {
> int ret = 0;
> size_t orig_path_len = path->len;
> if (orig_path_len == 0)
> ret = 0;
My concern in raising the issue is that someone reviewing the patch or
reading the code later won't necessarily know whether you took the
potential negative array access into account and dismissed it as
"can't happen", or if you overlooked the possibility altogether. Had
there been an explicit check in the code (either assert() or other
special handling such as returning 'false'), a comment in the code, or
mention in the commit message, then it would have been clear that you
took the case into consideration, and I wouldn't have worried about
it.
As for the this proposed version of is_git_repository(), I don't have
strong feelings, and can formulate arguments either way. If it doesn't
make sense for is_git_repository() ever to be called with empty input,
then assert() may be the better choice for documenting that fact.
However, if you foresee some need for allowing empty input, or if you
audited the functionality and found that it can already be called with
empty input, then returning 'false' makes sense. Use your best
judgment.
> else if (is_git_directory(path->buf))
> ret = 1;
> else {
> if (path->buf[orig_path_len - 1] != '/')
> strbuf_addch(path, '/');
> strbuf_addstr(path, ".git");
> if (is_git_directory(path->buf))
> ret = 1;
> strbuf_setlen(path, orig_path_len);
> }
>
> return ret;
> }
>
>
> Also I borrowed this pattern from remove_dirs and it has the same
> problem. Should I add something like this as a separate commit?
>
> diff --git a/builtin/clean.c b/builtin/clean.c
> index ccffd8a..88850e3 100644
> --- a/builtin/clean.c
> +++ b/builtin/clean.c
> @@ -201,6 +202,7 @@ static int remove_dirs(struct strbuf *path, const
> char *prefix, int force_flag,
> return res;
> }
>
> + assert(original_len > 0 && "expects non-empty path");
> if (path->buf[original_len - 1] != '/')
> strbuf_addch(path, '/');
I personally wouldn't mind such a patch. (I'm not sure that the string
within the assert() adds much value, and it's a not-much-used idiom
within the Git source.)
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[no subject]
Hi git team, I tried to research everywhere on a issue I am facing and emailing you as the last resource. This is critical for me and I needed your help. I am trying to run the latest git 1.9.5 installer on windows. When I run strings on libneon-25.dll it shows this: ./libneon-25.dll:OpenSSL 1.0.1h 5 Jun 2014 But when I load this dll in dependency walker, it picks up msys-openssl 1.0.1m and has no trace of openssl-1.0.1h. My questions to you: 1. Is libneon-25.dll statically linked with openssl-1.0.1h? 2. If not, where is the reference to 1.0.1h coming from? I am asked to rebuild git with libneon-25.dll linked against openssl-1.0.1m. But I am having a feeling that this is not needed, since libneon is already picking the latest openssl version. Can you please confirm? Thanks, Mamta -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 4/4] t1006: add tests for git cat-file --literally
On Wed, Apr 8, 2015 at 1:42 PM, karthik nayak wrote: > On 04/08/2015 02:19 AM, Eric Sunshine wrote: >> On Sat, Apr 4, 2015 at 1:44 AM, Karthik Nayak >> wrote: >> > Signed-off-by: Karthik Nayak >> > --- >> > diff --git a/t/t1006-cat-file.sh b/t/t1006-cat-file.sh >> > index ab36b1e..5b74044 100755 >> > --- a/t/t1006-cat-file.sh >> > +++ b/t/t1006-cat-file.sh >> > @@ -296,4 +308,19 @@ test_expect_success '%(deltabase) reports packed >> > delta bases' ' >> > } >> > ' >> > >> > +bogus_type="bogus" >> > +bogus_sha1=$(git hash-object -t $bogus_type --literally -w --stdin >> > > > + >> > +test_expect_success "Type of broken object is correct" ' >> > + echo $bogus_type >expect && >> > + git cat-file -t --literally $bogus_sha1 >actual && >> > + test_cmp expect actual >> > +' >> > + >> > +test_expect_success "Size of broken object is correct" ' >> > + echo "0" >expect && >> >> Zero is such a common fallback value when things go wrong that it may >> not be the best choice for this test. Consequently, it might be better >> to create the bogus object with non-zero length. Take a look at how >> 'hello_length' and 'hello_sha1' are computed elsewhere in this script >> for inspiration. > > The first part of this patch contains tests which make use of 'hello_length' > adn 'hello_sha1', but I get what you're saying, will look into it. Thanks. Just to be sure we're on the same page, I wasn't suggesting re-using 'hello_size' and 'hello_sha1', but merely to use that as an example of how to avoid hard-coding the length of your non-zero-length bogus object. So, something like this, perhaps: bogus_content='bogus' bogus_size=$(strlen "$bogus_content") bogus_sha1=$(echo_without_newline "$bogus_content" | git hash-object -t $bogus_type --literally -w --stdin) ... test_expect_success "Size of broken object is correct" ' echo $bogus_size >expect && ... -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [WIP/RFH/PATCH 3/3] t/lib-git-svn: adjust config to apache 2.4
Michael J Gruber wrote: > The current config is tailored to apache 2.2. Apache 2.4 fails to start > with it. > > Adjust the config to apache 2.4. > > Signed-off-by: Michael J Gruber > --- 1/3 and 2/3 tested fine on Debian stable (wheezy). You can add my Tested-by to 1/3 and my S-o-b to 2/3. ...but not this one. > Notes: > This is WIP and RFH. Apache does not start without mpm, and the lock > mechanism has changed. It will run with these changes, but svn fails to > connect. > > Again, I'm wondering who is running these tests at all, but also: > Why do we leverage lib-httpd so little from lib-git-svn? I'm only testing on Apache 2.2 (from Debian stable (wheezy)). I doubt anybody here, myself included, likes dealing with SVN, and would rather ignore the tests than try to fix them. lib-git-svn predates lib-httpd, and it isn't very interesting work to port and cleanup. > +LoadModule mpm_prefork_module $SVN_HTTPD_MODULE_PATH/mod_mpm_prefork.so I think you need an IfModule guard around this? I have no mod_mpm_prefork.so file with the apache2-mpm-prefork (2.2.22-13+deb7u4) package on Debian wheezy. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [v7 PATCH] daemon: add systemd support
On Wed, Apr 8, 2015 at 3:14 PM, Shawn Landden wrote: > [v7 PATCH] daemon: add systemd support > > git-daemon's --systemd mode allows git-daemon to be connect-activated > on one or more addresses or ports. Unlike --inetd[1], git-daemon is > not spawned for every connection. > > [1]which systemd is compatible with using its Accept=yes mode > > Signed-off-by: Shawn Landden > --- > Repond to Eric Sunshine's review of v6 > More documentation. Does this v7 differ from the v7 which you sent yesterday[1]? [1]: http://git.661346.n2.nabble.com/v7-PATCH-daemon-add-systemd-support-td7628519.html > diff --git a/Documentation/git-daemon.txt b/Documentation/git-daemon.txt > index a69b361..0eab51b 100644 > --- a/Documentation/git-daemon.txt > +++ b/Documentation/git-daemon.txt > @@ -19,7 +19,8 @@ SYNOPSIS > [--access-hook=] [--[no-]informative-errors] > [--inetd | > [--listen=] [--port=] > - [--user= [--group=]]] > + [--systemd | > + [--user= [--group=]]] > [...] > > DESCRIPTION > @@ -81,8 +82,8 @@ OPTIONS > > --inetd:: > Have the server run as an inetd service. Implies --syslog. > - Incompatible with --detach, --port, --listen, --user and --group > - options. > + Incompatible with --systemd, --detach, --port, --listen, --user and > + --group options. > > --listen=:: > Listen on a specific IP address or hostname. IP addresses can > @@ -146,8 +147,8 @@ OPTIONS > the option are given to `getpwnam(3)` and `getgrnam(3)` > and numeric IDs are not supported. > + > -Giving these options is an error when used with `--inetd`; use > -the facility of inet daemon to achieve the same before spawning > +Giving these options is an error when used with `--inetd` or `--systemd`; use > +the facility of systemd or the inet daemon to achieve the same before > spawning > 'git daemon' if needed. > + > Like many programs that switch user id, the daemon does not reset > @@ -180,6 +181,16 @@ Git configuration files in that directory are readable > by ``. > errors are not enabled, all errors report "access denied" to the > client. The default is --no-informative-errors. > > +--systemd:: > + For running git-daemon under systemd(1) which will pass > + an open connection. This is similar to --inetd, except > + that more than one address/port can be listened to at once > + both through systemd and through --listen/--port, and git-daemon > + doesn't get invoked for every connection, but only the first. > + For more details see systemd.socket(5). Incompatible with > + --inetd, --detach, --user and --group options. > + Works with the session manager (systemd --user) too. > + > --access-hook=:: > Every time a client connects, first run an external command > specified by the with service name (e.g. "upload-pack"), > @@ -305,6 +316,34 @@ selectively enable/disable services per repository:: > uploadarch = true > > > +systemd configuration example:: > +Example systemd configuration files, typically placed in > `/etc/systemd/system` > +or `$HOME/.config/systemd/user`. > ++ > +`git-daemon.socket` > ++ > + > +[Unit] > +Description=Git Daemon socket > + > +[Socket] > +ListenStream=9418 > + > +[Install] > +WantedBy=sockets.target > + > ++ > +`git-daemon.service` > ++ > + > +[Unit] > +Description=Git Daemon > + > +[Service] > +ExecStart=/usr/lib/git-core/git-daemon --systemd --reuseaddr > --base-path=/var/lib /var/lib/git > +User=git-daemon > +StandardError=null > + > > ENVIRONMENT > --- > diff --git a/Makefile b/Makefile > index 5f3987f..415ac21 100644 > --- a/Makefile > +++ b/Makefile > @@ -42,6 +42,9 @@ all:: > # Define NO_EXPAT if you do not have expat installed. git-http-push is > # not built, and you cannot push using http:// and https:// transports > (dumb). > # > +# Define NO_SYSTEMD to prevent systemd socket activation support from being > +# built into git-daemon. > +# > # Define EXPATDIR=/foo/bar if your expat header and library files are in > # /foo/bar/include and /foo/bar/lib directories. > # > @@ -995,6 +998,13 @@ ifeq ($(uname_S),Darwin) > PTHREAD_LIBS = > endif > > +ifndef NO_SYSTEMD > + ifeq ($(shell echo "\#include " | $(CC) -E - -o > /dev/null 2>/dev/null && echo y),y) > + BASIC_CFLAGS += -DHAVE_SYSTEMD > + EXTLIBS += -lsystemd > + endif > +endif > + > ifndef CC_LD_DYNPATH > ifdef NO_R_TO_GCC_LINKER > # Some gcc does not accept and pass -R to the linker to > specify > diff --git a
[v7 PATCH] daemon: add systemd support
git-daemon's --systemd mode allows git-daemon to be connect-activated on one or more addresses or ports. Unlike --inetd[1], git-daemon is not spawned for every connection. [1]which systemd is compatible with using its Accept=yes mode Signed-off-by: Shawn Landden --- Repond to Eric Sunshine's review of v6 More documentation. Documentation/git-daemon.txt | 49 +++- Makefile | 10 + daemon.c | 46 +++-- 3 files changed, 94 insertions(+), 11 deletions(-) diff --git a/Documentation/git-daemon.txt b/Documentation/git-daemon.txt index a69b361..0eab51b 100644 --- a/Documentation/git-daemon.txt +++ b/Documentation/git-daemon.txt @@ -19,7 +19,8 @@ SYNOPSIS [--access-hook=] [--[no-]informative-errors] [--inetd | [--listen=] [--port=] - [--user= [--group=]]] + [--systemd | + [--user= [--group=]]] [...] DESCRIPTION @@ -81,8 +82,8 @@ OPTIONS --inetd:: Have the server run as an inetd service. Implies --syslog. - Incompatible with --detach, --port, --listen, --user and --group - options. + Incompatible with --systemd, --detach, --port, --listen, --user and + --group options. --listen=:: Listen on a specific IP address or hostname. IP addresses can @@ -146,8 +147,8 @@ OPTIONS the option are given to `getpwnam(3)` and `getgrnam(3)` and numeric IDs are not supported. + -Giving these options is an error when used with `--inetd`; use -the facility of inet daemon to achieve the same before spawning +Giving these options is an error when used with `--inetd` or `--systemd`; use +the facility of systemd or the inet daemon to achieve the same before spawning 'git daemon' if needed. + Like many programs that switch user id, the daemon does not reset @@ -180,6 +181,16 @@ Git configuration files in that directory are readable by ``. errors are not enabled, all errors report "access denied" to the client. The default is --no-informative-errors. +--systemd:: + For running git-daemon under systemd(1) which will pass + an open connection. This is similar to --inetd, except + that more than one address/port can be listened to at once + both through systemd and through --listen/--port, and git-daemon + doesn't get invoked for every connection, but only the first. + For more details see systemd.socket(5). Incompatible with + --inetd, --detach, --user and --group options. + Works with the session manager (systemd --user) too. + --access-hook=:: Every time a client connects, first run an external command specified by the with service name (e.g. "upload-pack"), @@ -305,6 +316,34 @@ selectively enable/disable services per repository:: uploadarch = true +systemd configuration example:: +Example systemd configuration files, typically placed in `/etc/systemd/system` +or `$HOME/.config/systemd/user`. ++ +`git-daemon.socket` ++ + +[Unit] +Description=Git Daemon socket + +[Socket] +ListenStream=9418 + +[Install] +WantedBy=sockets.target + ++ +`git-daemon.service` ++ + +[Unit] +Description=Git Daemon + +[Service] +ExecStart=/usr/lib/git-core/git-daemon --systemd --reuseaddr --base-path=/var/lib /var/lib/git +User=git-daemon +StandardError=null + ENVIRONMENT --- diff --git a/Makefile b/Makefile index 5f3987f..415ac21 100644 --- a/Makefile +++ b/Makefile @@ -42,6 +42,9 @@ all:: # Define NO_EXPAT if you do not have expat installed. git-http-push is # not built, and you cannot push using http:// and https:// transports (dumb). # +# Define NO_SYSTEMD to prevent systemd socket activation support from being +# built into git-daemon. +# # Define EXPATDIR=/foo/bar if your expat header and library files are in # /foo/bar/include and /foo/bar/lib directories. # @@ -995,6 +998,13 @@ ifeq ($(uname_S),Darwin) PTHREAD_LIBS = endif +ifndef NO_SYSTEMD + ifeq ($(shell echo "\#include " | $(CC) -E - -o /dev/null 2>/dev/null && echo y),y) + BASIC_CFLAGS += -DHAVE_SYSTEMD + EXTLIBS += -lsystemd + endif +endif + ifndef CC_LD_DYNPATH ifdef NO_R_TO_GCC_LINKER # Some gcc does not accept and pass -R to the linker to specify diff --git a/daemon.c b/daemon.c index 9ee2187..9880858 100644 --- a/daemon.c +++ b/daemon.c @@ -1,3 +1,7 @@ +#ifdef HAVE_SYSTEMD +# include +#endif + #include "cache.h" #include "pkt-line.h" #include "exec_cmd.h" @@ -28,7 +32,11 @@ static const char daemon_
Notes do not follow rebase
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 After doing a rebase -i to fix up some older commits, I noticed that notes I had associated with commits failed to follow the commit across the rebase, so the notes are now orphaned and will be pruned. Shouldn't notes be copied to the new commit during an ammend/rebase? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) iQEcBAEBAgAGBQJVJXY7AAoJENRVrw2cjl5RUe8IAI0tGUeBUAef4xIIU/UfV5eQ VAdkUfYXCHnkjqukS/iBusyNM3PssabHmRFc+AdKGPPmbsv9JGKpj5G9hwf6Bdh+ RNDPMTlt/Ii90eu+v3uXwFHNUNf0b6kv7Tw63L0bFxGsFzu55DBm48LT/DJ9T05x Yqz5hbisKAhiVfAep2ib32f8gvC6p47CBmKVY4ii/PpOIzX/clZOQEgSPxvuHcSR cVcMGdljG+n8UqEOkkX5im0cW7pOUUht5GXWRGnBjXjtKTG64zxZnBPsPcqVJtxT q/lloKerUktJH3bJbUDU6iefBBzukQyy6tF37nbZH68bwTBlrh8CGL1BT2Eviqs= =WyFy -END PGP SIGNATURE- -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 4/4] t1006: add tests for git cat-file --literally
On 04/08/2015 02:19 AM, Eric Sunshine wrote: On Sat, Apr 4, 2015 at 1:44 AM, Karthik Nayak wrote: > Signed-off-by: Karthik Nayak > --- > diff --git a/t/t1006-cat-file.sh b/t/t1006-cat-file.sh > index ab36b1e..5b74044 100755 > --- a/t/t1006-cat-file.sh > +++ b/t/t1006-cat-file.sh > @@ -47,6 +47,18 @@ $content" > test_cmp expect actual > ' > > +test_expect_success "Type of $type is correct using --literally" ' > + echo $type >expect && > + git cat-file -t --literally $sha1 >actual && > + test_cmp expect actual > +' > + > +test_expect_success "Size of $type is correct using --literally" ' > + echo $size >expect && > + git cat-file -s --literally $sha1 >actual && > + test_cmp expect actual > +' > + > test -z "$content" || > test_expect_success "Content of $type is correct" ' > maybe_remove_timestamp "$content" $no_ts >expect && > @@ -296,4 +308,19 @@ test_expect_success '%(deltabase) reports packed delta bases' ' > } > ' > > +bogus_type="bogus" > +bogus_sha1=$(git hash-object -t $bogus_type --literally -w --stdin + > +test_expect_success "Type of broken object is correct" ' > + echo $bogus_type >expect && > + git cat-file -t --literally $bogus_sha1 >actual && > + test_cmp expect actual > +' > + > +test_expect_success "Size of broken object is correct" ' > + echo "0" >expect && Zero is such a common fallback value when things go wrong that it may not be the best choice for this test. Consequently, it might be better to create the bogus object with non-zero length. Take a look at how 'hello_length' and 'hello_sha1' are computed elsewhere in this script for inspiration. The first part of this patch contains tests which make use of 'hello_length' adn 'hello_sha1', but I get what you're saying, will look into it. Thanks. > + git cat-file -s --literally $bogus_sha1 >actual && > + test_cmp expect actual > +' > + > test_done > -- > 2.4.0.rc1.249.g9f2ee54 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: rev-list pretty format behavior
Heyup, Dr. Gruber. On 7 April 2015 at 15:53, Michael J Gruber wrote: > I'm wondering what the difference is - or should be - between "git log" > and "git rev-list" with (completely) user specified output. That > question goes both ways: > > - Why do we need "rev-list" to have completely flexible output when we > have "log" with such flexibility? > > - Why do we even have pretty formats for "rev-list"? > > I'm thinking of rev-list as a raw (plumbing) revision lister much like > cat-file is the inspection tool for the objects, and log as the human > facing output with appropriate defaults (resp. show). > > Note that "rev-list -v" isn't even documented afaics. I can't answer your questions, because I don't have a very deep understanding of either command, but according to the "log" docu, formating really belongs to "rev-list" and "log" only adds the diff-* features: -- The command takes options applicable to the git rev-list command to control what is shown and how, and options applicable to the git diff-* commands to control how the changes each commit introduces are shown. -- I also feel that perhaps "pretty" is a bit of a misnomer and naturally is associated with "human readable", but the formating is vital for any raw output that scripts can process. Oliver -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 1/4] submodules: implement synchronizing of remotes.
On Wed, Apr 8, 2015 at 3:58 AM, Patrick Steinhardt wrote: > Previously it was not possible to specify custom remotes for > submodules. This feature has now been implemented and can be I am not going to say whether it makes sense to add this feature or not, but I'll just react to "Previously". Let's stop saying "Previously we couldn't do X, now we can". Instead, let's consistently say "We don't do X. Being able to do X is a good thing for such and such reasons. Make us capable of doing X by doing this and that." Some people even say "Currently we cannot do X. Teach us to do so", which is equally bad but that is primarily because some people say "Previously" and they feel the need to clarify which reality they are talking about. Once we stop saying "Previously", they will stop saying "Currently", and the world would be a better place ;-). Thanks. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3] Make httpd tests run
This series grew from an attempt at enlarging my personal test run coverage on a standard Fedora 21 64bit box. Aka chain-lint fall-out. With 1/3, I get all httpd tests to run (when port is set, of course). 2/3 and 3/3 are an attempt at getting git-svn over http tests to run. 2/3 is certainly correct but not sufficient. 3/3 gets httpd to run but svn does not connect. This is WIP and RFH, and maybe requires rewriting lib-git-svn to use a config which depends on the apache version (like lib-hhtpd does), or to leverage lib-httpd. Michael J Gruber (3): t/lib-httpd: load mod_unixd t/lib-git-svn: check same httpd module dirs as lib-httpd t/lib-git-svn: adjust config to apache 2.4 t/lib-git-svn.sh| 7 +-- t/lib-httpd/apache.conf | 3 +++ 2 files changed, 8 insertions(+), 2 deletions(-) -- 2.4.0.rc1.221.gf7021fb -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] t/lib-git-svn: check same httpd module dirs as lib-httpd
Currently, lib-git-svn checks a proper subset of the paths that
lib-httpd checks for apache modules.
Make it check the same set so that apache is run by one when it is run
by the other (provide ports have been set).
Signed-off-by: Michael J Gruber
---
Notes:
Again, I'm wondering how many are running these tests.
They would not run on a 64bit system with redhat type fs layout.
t/lib-git-svn.sh | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/t/lib-git-svn.sh b/t/lib-git-svn.sh
index b0ec12f..2a0ef07 100644
--- a/t/lib-git-svn.sh
+++ b/t/lib-git-svn.sh
@@ -87,8 +87,10 @@ prepare_httpd () {
fi
for d in \
"$SVN_HTTPD_MODULE_PATH" \
- /usr/lib/apache2/modules \
/usr/libexec/apache2 \
+ /usr/lib/apache2/modules \
+ /usr/lib64/httpd/modules \
+ /usr/lib/httpd/modules \
; do
if test -d "$d"
then
--
2.4.0.rc1.221.gf7021fb
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] t/lib-httpd: load mod_unixd
With the current config, apache 2.4.10 will not be started and the httpd tests will not run. Enable mod_unixd to make the httpd tests run. Signed-off-by: Michael J Gruber --- Notes: Basically, this is required since the switch from 2.2 to 2.4. I'm wondering whether noone is running these tests, or other distros (than Fedora) use different default configs. t/lib-httpd/apache.conf | 3 +++ 1 file changed, 3 insertions(+) diff --git a/t/lib-httpd/apache.conf b/t/lib-httpd/apache.conf index 0b81a00..7b8e21c 100644 --- a/t/lib-httpd/apache.conf +++ b/t/lib-httpd/apache.conf @@ -64,6 +64,9 @@ LockFile accept.lock LoadModule mpm_prefork_module modules/mod_mpm_prefork.so + + LoadModule unixd_module modules/mod_unixd.so + PassEnv GIT_VALGRIND -- 2.4.0.rc1.221.gf7021fb -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[WIP/RFH/PATCH 3/3] t/lib-git-svn: adjust config to apache 2.4
The current config is tailored to apache 2.2. Apache 2.4 fails to start with it. Adjust the config to apache 2.4. Signed-off-by: Michael J Gruber --- Notes: This is WIP and RFH. Apache does not start without mpm, and the lock mechanism has changed. It will run with these changes, but svn fails to connect. Again, I'm wondering who is running these tests at all, but also: Why do we leverage lib-httpd so little from lib-git-svn? t/lib-git-svn.sh | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/t/lib-git-svn.sh b/t/lib-git-svn.sh index 2a0ef07..b0ca893 100644 --- a/t/lib-git-svn.sh +++ b/t/lib-git-svn.sh @@ -117,10 +117,11 @@ ServerName "git svn test" ServerRoot "$GIT_DIR" DocumentRoot "$GIT_DIR" PidFile "$GIT_DIR/httpd.pid" -LockFile logs/accept.lock +Mutex default Listen 127.0.0.1:$SVN_HTTPD_PORT LoadModule dav_module $SVN_HTTPD_MODULE_PATH/mod_dav.so LoadModule dav_svn_module $SVN_HTTPD_MODULE_PATH/mod_dav_svn.so +LoadModule mpm_prefork_module $SVN_HTTPD_MODULE_PATH/mod_mpm_prefork.so DAV svn SVNPath "$rawsvnrepo" -- 2.4.0.rc1.221.gf7021fb -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] systemd socket activation support
On Thu, Apr 2, 2015 at 8:09 AM, Shawn Landden wrote: > From: Shawn Landden > > v1.1: actually test... > > Signed-off-by: Shawn Landden > --- > daemon.c | 35 +++--- > git-daemon.service | 7 +++ > git-daemon.socket | 9 > sd-daemon.c| 132 > + > sd-daemon.h| 91 > 5 files changed, 268 insertions(+), 6 deletions(-) > create mode 100644 git-daemon.service > create mode 100644 git-daemon.socket > create mode 100644 sd-daemon.c > create mode 100644 sd-daemon.h > > diff --git a/daemon.c b/daemon.c > index 9ee2187..4677058 100644 > --- a/daemon.c > +++ b/daemon.c > @@ -5,6 +5,8 @@ > #include "strbuf.h" > #include "string-list.h" > > +#include "sd-daemon.c" > + You meant "sd-daemon.h", no? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] gitweb: avoid double / in search form action link
The in-project search form needs to duplicate some of the logic of
the href() subroutine, because the parameters need to be encoded
in the form rather than in the URL. However it failed to correctly
append the project PATH_INFO in cases when there is a trailing slash
on gitweb's self-referential URL, and failed to correctly follow
PATH_INFO escaping rules.
This change makes the form action URL consistent with the URL
generated by href().
Signed-off-by: Tony Finch
---
gitweb/gitweb.perl | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index a02f3e4..05acd73 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -4129,10 +4129,14 @@ sub print_search_form {
} else {
$search_hash = "HEAD";
}
+ # We can't use href() here because we need to encode the
+ # URL parameters into the form, not into the action link.
my $action = $my_uri;
my $use_pathinfo = gitweb_check_feature('pathinfo');
if ($use_pathinfo) {
- $action .= "/".esc_url($project);
+ # See notes about doubled / in href()
+ $action =~ s,/$,,;
+ $action .= "/".esc_path_info($project);
}
print $cgi->start_form(-method => "get", -action => $action) .
"\n" .
--
2.2.1.68.g56d9796
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: gitk won't show notes?
Phillip Susi venit, vidit, dixit 07.04.2015 19:08: > On 4/7/2015 10:13 AM, Michael J Gruber wrote: >> Seriously: gitk knows F5 and Shift-F5 for refresh, and I think the >> latter is the thorougher refreshment. > > Neither one makes newly added notes show up. The only way seems to be > to close and restart gitk. Looks like a bug. > > Apparently, gitk rereads the refs but not commits it has read already - and the commit reading includes the notes lookup. Unfortunately, my wish-fu is lacking. But I'll cc the master. Paulus: None of updatecommits, reloadcommits and rereadrefs seem to reread the notes of a commit that has been displayed already if the notes have changed (but the other refs have not). Michael -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC/PATCH 3/4] submodules: update docs to reflect remotes.
---
Documentation/git-submodule.txt | 23 +++
1 file changed, 23 insertions(+)
diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index 2c25916..a49a2ad 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -21,6 +21,9 @@ SYNOPSIS
[commit] [--] [...]
'git submodule' [--quiet] foreach [--recursive]
'git submodule' [--quiet] sync [--recursive] [--] [...]
+'git submodule' [--quiet] remote add
+'git submodule' [--quiet] remote rm
+'git submodule' [--quiet] remote set-url [--push] "
DESCRIPTION
@@ -233,6 +236,22 @@ As an example, +git submodule foreach \'echo $path
{backtick}git
rev-parse HEAD{backtick}'+ will show the path and currently checked out
commit for each submodule.
+remote::
+ Modify a submodule's remote configuration. The command has subcommands
that
+ mirror the commands of `git remote`. The change will be reflected inside
+ of the .gitmodules file the submodule is specified in. Changes will be
+ synchronized with the submodule by running `git submodule sync`.
++
+ `git submodule remote add `;;
+ add a new remote with the URL specified to the submodule
+ `git submodule remote rm `;;
+ remove a remote with the given name for the specified submodule
+ `git submodule remote show [-v|--verbose] `;;
+ show configured remotes for the submodule. If `--verbose` is
specified,
+ also print URLs.
+ `git submodule remote set-url [--push] `;;
+ set the (push) URL for the given remote name and submodule.
+
sync::
Synchronizes submodules' remote URL configuration setting
to the value specified in .gitmodules. It will only affect those
@@ -240,6 +259,10 @@ sync::
case when they are initialized or freshly added). This is useful when
submodule URLs change upstream and you need to update your local
repositories accordingly.
+
+ Also synchronizes all remotes that have been configured in .gitmodules.
+ Missing remotes will be added to the submodule while existing ones will
be
+ updated according to the configured fetch or push URLs.
+
"git submodule sync" synchronizes all submodules while
"git submodule sync \-- A" synchronizes submodule "A" only.
--
2.3.5
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC/PATCH 2/4] submodules: implement remote commands.
Add commands to modify a submodule's remote configuration. There
are commands to add and remove submodule remotes as well as to
modify the URL of a submodule remote.
---
git-submodule.sh | 225 ++-
1 file changed, 223 insertions(+), 2 deletions(-)
diff --git a/git-submodule.sh b/git-submodule.sh
index 599a847..6904f29 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -12,7 +12,11 @@ USAGE="[--quiet] add [-b ] [-f|--force] [--name
] [--reference ]
[--recursive] [--] [...]
or: $dashless [--quiet] summary [--cached|--files] [--summary-limit ]
[commit] [--] [...]
or: $dashless [--quiet] foreach [--recursive]
- or: $dashless [--quiet] sync [--recursive] [--] [...]"
+ or: $dashless [--quiet] sync [--recursive] [--] [...]
+ or: $dashless [--quiet] remote add
+ or: $dashless [--quiet] remote rm
+ or: $dashless [--quiet] remote show
+ or: $dashless [--quiet] remote set-url [--push] "
OPTIONS_SPEC=
SUBDIRECTORY_OK=Yes
. git-sh-setup
@@ -1270,6 +1274,223 @@ cmd_status()
}
#
+# Modify remote configuration in .gitmodules
+#
+cmd_remote()
+{
+ while test $# -ne 0
+ do
+ case "$1" in
+ -q|--quiet)
+ GIT_QUIET=1
+ shift
+ ;;
+ add|rm|show)
+ subcommand=$1
+ shift
+ ;;
+ set-url)
+ subcommand=set_url
+ shift
+ ;;
+ *)
+ break;;
+ esac
+ done
+
+ if test -z "$subcommand"
+ then
+ usage
+ fi
+
+ "cmd_remote_$subcommand" "$@"
+}
+
+#
+# Show remote configuration for a gitmodule
+#
+cmd_remote_show()
+{
+ while test $# -ne 0
+ do
+ case "$1" in
+ -v|--verbose)
+ verbose=1
+ shift
+ ;;
+ *)
+ sm_path="$1"
+ shift
+ break;;
+ esac
+ done
+
+ if test $# -ne 0
+ then
+ usage
+ fi
+
+ if test -z "$sm_path"
+ then
+ die "$(gettext "No submodule path specified")"
+ fi
+
+ sm_name=$(module_name "$sm_path") || exit
+
+ cd_to_toplevel
+
+ git config -f .gitmodules --get-regexp
"submodule-remote\.$sm_name\..*\.url" 2>/dev/null |
+ while read key url
+ do
+ remote=$(echo "$key" | sed
"s/submodule-remote\.$sm_name\.\(.*\)\.url/\1/")
+ section="submodule-remote.$sm_name.$remote"
+
+ if test -z "$verbose"
+ then
+ echo "$remote"
+ else
+ url=$(git config -f .gitmodules "$section.url"
2>/dev/null)
+ pushurl=$(git config -f .gitmodules "$section.pushurl"
2>/dev/null)
+
+ if test -z "$pushurl"
+ then
+ pushurl="$url"
+ fi
+
+ echo -e "$remote\t$url (fetch)"
+ echo -e "$remote\t$pushurl (push)"
+ fi
+ done
+}
+
+#
+# Add remote configuration to .gitmodules
+# This adds a new remote with the key
+# submodule-remote.$name.$remote.url set to the specified value
+# to .gitmodules.
+#
+cmd_remote_add()
+{
+ if test $# -ne 3
+ then
+ usage
+ fi
+
+ sm_path="$1"
+ remote_name="$2"
+ remote_url="$3"
+
+ sm_name=$(module_name "$sm_path") || exit
+ displaypath=$(relative_path "$sm_path")
+ key="submodule-remote.$sm_name.$remote_name.url"
+
+ if test -z "$remote_name"
+ then
+ die "$(eval_gettext "Empty remote name not allowed")"
+ fi
+
+ cd_to_toplevel
+
+ if git config -f .gitmodules "$key" >/dev/null 2>/dev/null
+ then
+ die "$(eval_gettext "Remote '\$remote_name' for submodule
'\$sm_name' already present")"
+ fi
+
+ if git config -f .gitmodules
"submodule-remote.$sm_name.$remote_name.url" "$remote_url"
+ then
+ say "$(eval_gettext "Remote '\$remote_name' added for path
'\$displaypath'")"
+ else
+ die "$(eval_gettext "Remote '\$remote_name' could not be added
for path '\$displaypath'")"
+ fi
+}
+
+#
+# Remove remote configuration from .gitmodules
+# This removes the remote for the specified submodule and remote
+# name.
+#
+cmd_remote_rm()
+{
+ if test $# -ne 2
+ then
+ usage
+ fi
+
+ sm_path="$1"
+ remote_na
[RFC/PATCH 1/4] submodules: implement synchronizing of remotes.
Previously it was not possible to specify custom remotes for submodules. This feature has now been implemented and can be accessed by setting the keys 'submodule-remote.$name.$remote.url' and 'submodule-remote.$name.$remote.push-url', respectively. When issuing a `git submodule sync` we will test if submodules have one or more remotes specified and if so those will be either added if nonexistent or their URLs will be adjusted to match the specified URLs. --- git-submodule.sh | 27 +++ 1 file changed, 27 insertions(+) diff --git a/git-submodule.sh b/git-submodule.sh index 36797c3..599a847 100755 --- a/git-submodule.sh +++ b/git-submodule.sh @@ -1268,6 +1268,7 @@ cmd_status() fi done } + # # Sync remote urls for submodules # This makes the value for remote.$remote.url match the value @@ -1347,6 +1348,32 @@ cmd_sync() ) fi fi + + git config -f .gitmodules --get-regexp "submodule-remote\.$name\..*\.url" 2>/dev/null | + while read key url + do + remote=$(echo "$key" | sed "s/submodule-remote\.$name\.\(.*\)\.url/\1/") + pushurl=$(git config -f .gitmodules --get "submodule-remote.$name.$remote.pushurl") + + ( + cd "$sm_path" + + if ! git remote | grep "^$remote$" >/dev/null 2>/dev/null + then + say "$(eval_gettext "Adding remote '$remote' for submodule '$prefix$sm_path'")" + git remote add "$remote" "$url" + else + say "$(eval_gettext "Setting URL for remote '$remote' in submodule '$prefix$sm_path'")" + git remote set-url "$remote" "$url" + fi + + if test ! -z "$pushurl" + then + say "$(eval_gettext "Setting push URL for remote '$remote' in submodule '$prefix$sm_path'")" + git remote set-url --push "$remote" "$pushurl" + fi + ) + done done } -- 2.3.5 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC/PATCH 4/4] submodules: add bash completion for remotes.
---
contrib/completion/git-completion.bash | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index fbe5972..9d52bf0 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -2411,7 +2411,7 @@ _git_submodule ()
{
__git_has_doubledash && return
- local subcommands="add status init deinit update summary foreach sync"
+ local subcommands="add status init deinit update summary foreach sync
remote"
if [ -z "$(__git_find_on_cmdline "$subcommands")" ]; then
case "$cur" in
--*)
--
2.3.5
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC/PATCH 0/4] submodule remotes
The following patch series implements a new feature on top of the
submodule command that allows for configuring multiple remotes for
a given submodule. Next to new subcommands `git submodule remote
(add|rm|set-url|show)` that allow to show and modify remotes for
a given submodule, `git remote sync` has been extended to apply
settings to the repositories.
The commands are implemented in such a way that they write the
remote configuration into .gitmodules according to the following
example:
[submodule-remote "submodule-name.remote-name"]
url = http://example.com/remote.git
pushurl = g...@example.com:remote.git
where "submodule-name" is the submodule's name and "remote-name"
is the name of the remote when it will be synchronized into the
submodule repository. The section-name is definitly up for
discussion and I don't really know if there might be issues with
the format "submodule-name.remote-name", but as far as I know
there is no possibility of having sub-subsections inside config
files.
There are some issues that I am currently aware of:
- If we specify a remote "origin" for a submodule, `git
submodule sync` will happily overwrite
submodule.${submodule-name}.url. We certainly don't want to
drop the old way of specifying a single URL but I am not
sure what to do when a new "origin" has been specified.
Perhaps a warning or user confirmation would suffice?
- If the user specifies his own remotes and afterwards syncs
the submodule's remotes, his settings will be overwritten.
Maybe remotes should only be synced when a switch is
specified (e.g. `git submodule sync --remotes` or `git
submodule remotes sync`)?
This patch series is not intended to be included as-is as there
are no tests yet and the implementation has not been tested that
much. It should only evaluate if there is any interest and
hopefully spark some discussion as to if this feature is
something that is regarded as useful to others.
iveqy in IRC told me that there has been a discussion on
something similar, I wasn't able to find that though.
Regards
Patrick
Patrick Steinhardt (4):
submodules: implement synchronizing of remotes.
submodules: implement remote commands.
submodules: update docs to reflect remotes.
submodules: add bash completion for remotes.
Documentation/git-submodule.txt| 23 +++
contrib/completion/git-completion.bash | 2 +-
git-submodule.sh | 252 -
3 files changed, 274 insertions(+), 3 deletions(-)
--
2.3.5
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How to send a warning message from git hosting server?
Yi, EungJun wrote: > > I want a way to response a remote message when a client send any kind > of request. Is it possible? Yes, though you need a wrapper around git. Recent versions of gitolite have a "motd" message of the day feature. http://gitolite.com/gitolite/list-non-core.html#triggers Tony. -- f.anthony.n.finchhttp://dotat.at/ Fisher: Northwest backing southwest 4 or 5, occasionally 6 at first. Slight or moderate. Fog patches. Moderate or good, occasionally very poor. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/5] log: honor log.merges= option
On 04/08/2015 04:28 AM, Junio C Hamano wrote: > Koosha Khajehmoogahi writes: > >> On 04/04/2015 10:00 PM, Junio C Hamano wrote: >>> Koosha Khajehmoogahi writes: >>> From: Junio C Hamano [kk: wrote commit message] >>> >>> Ehh, what exactly did you write ;-)? >>> >>> I think the most important thing that needs to be explained by the >>> log message for this change is that the variable is honored only by >>> log and it needs to explain why other Porcelain commands in the same >>> "log" family, like "whatchanged", should ignore the variable. >>> >> So, what would be the reason? > > It is strange that you have to ask me to give you the reason why you > chose it that way, isn't it? AFAIK, the only other command that supports --merges and --no-merges options is rev-list. This new feature aims to make a default behavior for the commands that have these options. The command-line option is supported by the two commands. However, the config var is only used by git-log and rev-list ignores it. I didn't exclude rev-list for any particular reason. If we need, I could also handle it in rev-list. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
