On Sat, May 9, 2015 at 1:17 PM, Sébastien Guimmara
wrote:
> command-list.txt contains a [common] block that should be ignored
> by the Documentation checker cmd-list.perl.
>
> Filter out this block before the actual processing of the command list.
>
> Signed-off-by: Sébastien Guimmara
> ---
> dif
In contrast to apache 2.2, apache 2.4 does not load mod_unixd in its
default configuration (because there are choices). Thus, with the
current config, apache 2.4.10 will not be started and the httpd tests
will not run on distros with default apache config (RedHat type).
Enable mod_unixd to make th
The current config is tailored to apache 2.2. Apache 2.4 fails to start
with it.
Adjust the config to apache 2.4. [still incomplete]
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 th
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 (provided ports have been set and there are no other
configuration issues).
Signed-off-by: Michael J Gruber
---
v2 updates the commit messages as per the dicsussion after v1 and adds a
clean-up.
1/4, 2/4 are ready to go as discussed (commit messages updated).
3/4 is a new independent cleanup noted while being there.
4/4 is the old 3/3 and still WIP. Please hold back.
Michael J Gruber (4):
t/lib-httpd: lo
This is a re-roll of [1]. This patch series improves the handling of
conflicts between references like "refs/foo" and "refs/foo/bar" that
are not allowed to co-exist. It also changes some functions in this
area to record their error messages in a "struct strbuf *err" argument
rather than sometimes
So it used to be that when upstream rebased, you'd get an error when you
tried to pull again and have to fix things up with some git reset or
rebase hackery. Trying to demo this today I found that the pull
*worked*, using an automatic recursive merge.
Am I crazy in thinking this used to error
In git 2.3.7 I could run the following command and see progress in the
terminal, despite the redirection of stdout and stderr:
git clone https://github.com/oconnor663/dotfiles --progress 2>&1 | cat
As of 2.4, that command no longer shows progress. When I bisect, the
responsible commit is 2879
David Turner writes:
> I'll send something like this when I re-roll:
>
> Follow symlinks inside the repository when requesting objects with
> extended SHA-1 expressions of the form tree-ish:path-in-tree. Instead of
> providing output about the link itself, provide output about the
> linked-to obj
On Mon, May 11, 2015 at 07:04:20PM -0700, Junio C Hamano wrote:
> Mike Hommey writes:
>
> > So, the reason this is happening is that 2879bc3 moved sending the
> > progress helper option earlier, and for clone, it's early enough that
> > transport_set_verbosity happens afterwards. Since
> > transp
10 matches
Mail list logo
