date:20150408

Samuel Williams space.ship.travel...@gmail.com 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: [PATCH] fix global bash variable leak on __gitcompappend

Márcio Almada marcio.w...@gmail.com 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: [PATCH v7 4/4] t1006: add tests for git cat-file --literally

2015-04-08 Thread Karthik Nayak



On April 9, 2015 2:04:08 AM GMT+05:30, Eric Sunshine sunsh...@sunshineco.com 
wrote:
On Wed, Apr 8, 2015 at 1:42 PM, karthik nayak karthik@gmail.com
wrote:
 On 04/08/2015 02:19 AM, Eric Sunshine wrote:
 On Sat, Apr 4, 2015 at 1:44 AM, Karthik Nayak
karthik@gmail.com
 wrote:
  Signed-off-by: Karthik Nayak karthik@gmail.com
  ---
  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
  /dev/null)
  +
  +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

Re:

2015-04-08 Thread Thomas Braun

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: git-completion.tcsh

2015-04-08 Thread Perry Rajnovic

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 sze...@ira.uka.de wrote:
 
 
 Quoting Perry Rajnovic perry.rajno...@gmail.com:
 
 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 ftab
 $ git add foo/
 $ git add foo/btab
 $ git add foo/bar/
 $ git add foo/bar/stab
 $ git add foo/bar/somefile.c
 
 (works not as expected, git rm)
 $ cd basedir
 $ git rm ftab
 $ git rm foo
 $ git rm foobackspace/btab
 $ 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: [v6 PATCH] daemon: add systemd support

Ramsay Jones ram...@ramsay1.demon.co.uk 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 sh...@churchofgit.com
 ---

 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=gitm=142836529908207w=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 systemd/sd-daemon.h
 +#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)=service]\n
 [--access-hook=path]\n
 [--inetd | [--listen=host_or_ipaddr] [--port=n]\n
 +#ifdef HAVE_SYSTEMD
 +  [--systemd | [--detach] [--user=user 
 [--group=group]]]\n /* exactly 80 characters */
 +#else
[--detach] [--user=user [--group=group]]\n
 +#endif
 [directory...];
  
  /* 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 3/3] clean: improve performance when removing lots of directories

2015-04-08 Thread Eric Sunshine

On Tue, Apr 7, 2015 at 3:55 PM, erik elfström erik.elfst...@gmail.com wrote:
 On Tue, Apr 7, 2015 at 12:10 AM, Eric Sunshine sunsh...@sunshineco.com 
 wrote:
 On Mon, Apr 6, 2015 at 7:48 AM, Erik Elfström erik.elfst...@gmail.com 
 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

[GIT PULL] l10n updates for 2.4.0 round 2

2015-04-08 Thread Jiang Xin

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

2015-04-08 Thread Johan Herland

On Wed, Apr 8, 2015 at 8:40 PM, Phillip Susi ps...@ubuntu.com 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, jo...@herland.net
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

2015-04-08 Thread Rick Olson

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: [PATCH v2 2/5] log: honor log.merges= option

2015-04-08 Thread Koosha Khajehmoogahi



On 04/08/2015 04:28 AM, Junio C Hamano wrote:
 Koosha Khajehmoogahi koo...@posteo.de writes:
 
 On 04/04/2015 10:00 PM, Junio C Hamano wrote:
 Koosha Khajehmoogahi koo...@posteo.de writes:

 From: Junio C Hamano gits...@pobox.com

 [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

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 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 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] [--] [path...]
 'git submodule' [--quiet] foreach [--recursive] command
 'git submodule' [--quiet] sync [--recursive] [--] [path...]
+'git submodule' [--quiet] remote add path name url
+'git submodule' [--quiet] remote rm path name
+'git submodule' [--quiet] remote set-url [--push] path name url
 
 
 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 sm_path remote url`;;
+   add a new remote with the URL specified to the submodule
+   `git submodule remote rm sm_path remote`;;
+   remove a remote with the given name for the specified submodule
+   `git submodule remote show [-v|--verbose] sm_path`;;
+   show configured remotes for the submodule. If `--verbose` is 
specified,
+   also print URLs.
+   `git submodule remote set-url [--push] sm_path remote url`;;
+   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 branch] [-f|--force] [--name 
name] [--reference re
or: $dashless [--quiet] update [--init] [--remote] [-N|--no-fetch] 
[-f|--force] [--checkout|--merge|--rebase] [--reference repository] 
[--recursive] [--] [path...]
or: $dashless [--quiet] summary [--cached|--files] [--summary-limit n] 
[commit] [--] [path...]
or: $dashless [--quiet] foreach [--recursive] command
-   or: $dashless [--quiet] sync [--recursive] [--] [path...]
+   or: $dashless [--quiet] sync [--recursive] [--] [path...]
+   or: $dashless [--quiet] remote add path name url
+   or: $dashless [--quiet] remote rm path name
+   or: $dashless [--quiet] remote show path
+   or: $dashless [--quiet] remote set-url [--push] path name url
 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.
+#

[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

Re: How to send a warning message from git hosting server?

2015-04-08 Thread Tony Finch

Yi, EungJun semtlen...@gmail.com 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.finch  d...@dotat.at  http://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: [RFC/PATCH 1/4] submodules: implement synchronizing of remotes.

On Wed, Apr 8, 2015 at 3:58 AM, Patrick Steinhardt p...@pks.im 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

Re: rev-list pretty format behavior

2015-04-08 Thread Oliver Runge

Heyup, Dr. Gruber.

On 7 April 2015 at 15:53, Michael J Gruber g...@drmicha.warpmail.net 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

[PATCH] gitweb: avoid double / in search form action link

2015-04-08 Thread Tony Finch

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 d...@dotat.at
---
 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) .
  div class=\search\\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: [PATCH] systemd socket activation support

2015-04-08 Thread Erik Faye-Lund

On Thu, Apr 2, 2015 at 8:09 AM, Shawn Landden sh...@churchofgit.com wrote:
 From: Shawn Landden shawnland...@gmail.com

 v1.1: actually test...

 Signed-off-by: Shawn Landden sh...@churchofgit.com
 ---
  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

[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 g...@drmicha.warpmail.net
---

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
 Location /$repo_base_path
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

[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 g...@drmicha.warpmail.net
---

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
 IfModule !mod_mpm_prefork.c
LoadModule mpm_prefork_module modules/mod_mpm_prefork.so
 /IfModule
+IfModule !mod_unixd.c
+   LoadModule unixd_module modules/mod_unixd.so
+/IfModule
 /IfVersion
 
 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

[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