This resurrects the series started by Michael in April 2015 at:
https://public-inbox.org/git/cover.1428505184.git@drmicha.warpmail.net/T/
But only keeps only his first patch. PATCH 2/2 reuses the
work Clemens introduced in t/lib-httpd.sh back in 2008 to
enable mod_dav_svn.
The following c
This allows us to use common test infrastructure and parallelize
the tests. For now, GIT_SVN_TEST_HTTPD=true needs to be set to
enable the SVN HTTP tests because we reuse the same test cases
for both file:// and http:// SVN repositories. SVN_HTTPD_PORT
is no longer honored.
Tested under Apache 2
From: Michael J Gruber
Some of the tests "say" how to stop the svn tests from running, some do
not.
The test suite is directed at people reading t/README where we keep all
information about running the test suite (partly, with options etc.).
Remove said "say" occurences.
Signed-off-by: Michael
W dniu 2016-07-22 o 17:49, larsxschnei...@gmail.com pisze:
> From: Lars Schneider
Nb. this line is only needed if you want author name and/or date
different from the email sender, or if you have sender line misconfigured
(e.g. lacking the human readable name).
>
> Git's clean/smudge mechanism i
Hi Lars,
On 23/07/16 00:19, Ramsay Jones wrote:
>
>
> On 22/07/16 16:49, larsxschnei...@gmail.com wrote:
>> From: Lars Schneider
>>
>> Git's clean/smudge mechanism invokes an external filter process for every
>> single blob that is affected by a filter. If Git filters a lot of blobs
>> then th
On Fri, Jul 22, 2016 at 3:21 PM, Junio C Hamano wrote:
> Subject: [PATCH] grep: further simplify setting the pattern type
>
> When c5c31d33 (grep: move pattern-type bits support to top-level
> grep.[ch], 2012-10-03) introduced grep_commit_pattern_type() helper
> function, the intention was to allo
On 22/07/16 16:49, larsxschnei...@gmail.com wrote:
> From: Lars Schneider
>
> Git's clean/smudge mechanism invokes an external filter process for every
> single blob that is affected by a filter. If Git filters a lot of blobs
> then the startup time of the external filter processes can become a
Users have mistakenly copied "From " lines into commit messages
in the past, and will certainly make the same mistakes in the
future. Since not everyone uses mboxrd, yet, we should at least
prevent miss-split mails by always escaping "From " lines based
on the check used by mailsplit.
mailsplit w
Philip Oakley writes:
> +Special '{caret}' Shorthand Notations
> +~~
> +Two other shorthands exist, particularly useful for merge commits, is
> +for naming a set that is formed by a commit and its parent commits.
As these are not all that "special", how ab
On 07/22/2016 05:49 PM, larsxschnei...@gmail.com wrote:
From: Lars Schneider
Git's clean/smudge mechanism invokes an external filter process for every
single blob that is affected by a filter. If Git filters a lot of blobs
then the startup time of the external filter processes can become a
si
Hi,
Any thoughts on the following?
Mike
On Mon, Jul 04, 2016 at 08:44:39AM +0900, Mike Hommey wrote:
> The are many ways in which fast-import ends up calling gfi_unpack_entry,
> and fery few work-arounds. I've patched fast-import for it to be smarter
> in corner cases, allowing some additional w
larsxschnei...@gmail.com writes:
> The first two patches are cleanup patches which are not really necessary
> for the feature.
These two looked trivially good.
I think I can agree with what 3/3 wants to do in principle, but
* "protocol" is not quite the right word. The current way to
inter
Junio C Hamano wrote:
> Eric Wong writes:
> > I'm hoping "cd /" in the test will always succeed;
> > but I suppose non-*nix systems might fail, here.
>
> How about digging a few levels of directory hierarchy, exporting
> GIT_CEILING_DIRECTORIES so that we won't find any repository and
> goin
Jeff King writes:
> But even that is a lesser breakage than taking away grep.extendedRegexp
> entirely. Taking it away breaks anybody who uses it; tweaking (2) only
> breaks people who set both config variables. But why would anyone do
> that?
OK. Now we have an evidence that we have thought th
On Fri, Jul 22, 2016 at 1:28 PM, Stefan Beller wrote:
> In the transport protocol we use NAK to signal the non existence of a
> common base, so fix the documentation.
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
Mo
In the transport protocol we use NAK to signal the non existence of a
common base, so fix the documentation. This helps readers of the document,
as they don't have to wonder about the difference between NAK and NACK.
As NACK is used in git archive and upload-archive, this is easy to get
wrong.
Sig
> We tend to avoid catting a single file only to pipe the result into a
> different command
You got it. Here's a new patch:
>From 432c0054a28a6c91b9fc1d9b53714061cb3d903c Mon Sep 17 00:00:00 2001
From: Parker Moore
Date: Wed, 20 Jul 2016 18:33:28 -0600
Subject: [PATCH] contrib/persistent-https:
On Fri, Jul 22, 2016 at 12:51:00PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> >> This comes from b22520a3 (grep: allow -E and -n to be turned on by
> >> default via configuration, 2011-03-30) back when we didn't have a
> >> more generic grep.patternType configuration mechanism in v1.7.
On Fri, Jul 22, 2016 at 12:52 PM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> The approach to tests is different though. I like yours better than mine,
>> as it doesn't add more tests, but strengthens existing tests.
>
> So... are you retracting
> http://thread.gmane.org/gmane.comp.version
Stefan Beller writes:
>> I expect I'd queue these two instead, after seeing Acks from Stefan.
>>
>> Thanks.
>
> Sure. Please take these 2 patches instead of mine.
OK, I've already queued yours but I haven't started today's
integration cycle yet (I first pick up new topics and updates and
review
The "reflog selector" format changes based on a series of
heuristics, and that applies equally to both stock "log -g"
output, as well as "--format=%gd". The documentation for
"%gd" doesn't cover this. Let's mention the multiple formats
and refer the user back to the "-g" section for the complete
ru
The actual shortening rules aren't that interesting and
probably not worth getting into (I gloss over them here as
"shortened for human readability"). But the fact that %gD
shows whatever you gave on the command line is subtle and
worth mentioning. Since most people will feed a shortened
refname in
Stefan Beller writes:
> The approach to tests is different though. I like yours better than mine,
> as it doesn't add more tests, but strengthens existing tests.
So... are you retracting
http://thread.gmane.org/gmane.comp.version-control.git/25 and
instead giving an Ack to these two?
--
To
We already have "--date=raw", which is a Unix epoch
timestamp plus a contextual timezone (either the author's or
the local). But one may not care about the timezone and just
want the epoch timestamp by itself. It's not hard to parse
the two apart, but if you are using a pretty-print format,
you may
The "raw" format shows a Unix epoch timestamp, but with a
timezone tacked on. The timestamp is not _in_ that zone, but
it is extra information about the time (by default, the zone
the author was in).
The documentation claims that "raw-local" does not work. It
does, but the end result is rather sub
We document that asking for HEAD@{now} will switch the
output to show HEAD@{timestamp}, but not that specifying
`--date` has a similar effect, or that it can be overridden
with HEAD@{0}. Let's do so.
These rules come from 794151e (reflog-walk: always make
HEAD@{0} show indexed selectors, 2012-05-0
When "log -g" shows "HEAD@{1}", "HEAD@{2}", etc, calling
that "commit@{Nth}" is not really accurate. The "HEAD" part
is really the refname. By saying "commit", a reader may
misunderstand that to mean something related to the specific
commit we are showing, not the ref whose reflog we are
traversing
This is a repost of the patches in:
http://thread.gmane.org/gmane.comp.version-control.git/299201/focus=299236
since I don't think they got picked up at all.
The contents are the same, but with one extra patch (the 4th) that was
posted mid-discussion.
The only other review comment is that pat
Jeff King writes:
>> This comes from b22520a3 (grep: allow -E and -n to be turned on by
>> default via configuration, 2011-03-30) back when we didn't have a
>> more generic grep.patternType configuration mechanism in v1.7.5
>> days, and it probably need to be deprecated to maintain our sanity.
>>
On Fri, Jul 22, 2016 at 12:39 PM, Junio C Hamano wrote:
> Johannes Sixt writes:
>
>> 'git submodule--helper update-clone' has logic to retry failed clones
>> a second time. For this purpose, there is a list of submodules to clone,
>> and a second list that is filled with the submodules to retry.
Johannes Sixt writes:
> 'git submodule--helper update-clone' has logic to retry failed clones
> a second time. For this purpose, there is a list of submodules to clone,
> and a second list that is filled with the submodules to retry. Within
> these lists, the submodules are identified by an index
Johannes Sixt wrote:
> The previous commit introduced the first use of ENOTSOCK. This macro is
> not available on Windows. Define it as WSAENOTSOCK because that is the
> corresponding error value reported by the Windows versions of socket
> functions.
Thanks. I thought compat/poll/poll.c alread
On Fri, Jul 22, 2016 at 12:15 PM, Johannes Sixt wrote:
> 'git submodule--helper update-clone' has logic to retry failed clones
> a second time. For this purpose, there is a list of submodules to clone,
> and a second list that is filled with the submodules to retry. Within
> these lists, the submo
Jeff King writes:
> So I think we actually _can_ think of would_convert_to_git() as
> basically free. Or as free as other efficient-lookup functions we call
> like cache_name_pos().
OK.
> The thought "does this tree reuse even speed things up enough to justify
> its complexity" definitely cross
Johannes Schindelin writes:
> Hi Hannes,
>
> On Thu, 21 Jul 2016, Johannes Sixt wrote:
>
>> The previous commit introduced the first use of ENOTSOCK. This macro is
>> not available on Windows. Define it as WSAENOTSOCK because that is the
>> corresponding error value reported by the Windows versio
On Fri, Jul 22, 2016 at 12:21:31PM -0700, Junio C Hamano wrote:
> One thing that I noticed is that there is this strange field
> in grep_opt called .extended_regexp_option; it only is set from the
> boolean configuration grep.extendedregexp and worse yet it takes
> precedence over the command line
On Fri, Jul 22, 2016 at 12:14 PM, Johannes Sixt wrote:
> git-submodule--helper is invoked as the upstream of a pipe in several
> places. Usually, the failure of a program in this position is not
> detected by the shell. For this reason, the code inserts a token in the
> output stream when git-subm
Jeff King writes:
> I gave a very cursory look when I wrote the other email, and your
> alternative solution is what looked like the most elegant fix to me.
>
> I suspect this bug has been there quite a while, so no rush. :)
Here is what I am going to queue.
One thing that I noticed is that the
'git submodule--helper update-clone' has logic to retry failed clones
a second time. For this purpose, there is a list of submodules to clone,
and a second list that is filled with the submodules to retry. Within
these lists, the submodules are identified by an index as if both lists
were just appe
git-submodule--helper is invoked as the upstream of a pipe in several
places. Usually, the failure of a program in this position is not
detected by the shell. For this reason, the code inserts a token in the
output stream when git-submodule--helper fails that is detected
downstream, where the shell
On Fri, Jul 22, 2016 at 10:44:08AM -0700, Junio C Hamano wrote:
> > diff --git a/diff.c b/diff.c
> > index 7d03419..b43d3dd 100644
> > --- a/diff.c
> > +++ b/diff.c
> > @@ -2683,6 +2683,13 @@ static int reuse_worktree_file(const char *name,
> > const unsigned char *sha1, int
> > if (!FAST_WOR
Parker Moore writes:
> diff --git a/contrib/persistent-https/Makefile
> b/contrib/persistent-https/Makefile
> index 92baa3be..8248269 100644
> --- a/contrib/persistent-https/Makefile
> +++ b/contrib/persistent-https/Makefile
> @@ -12,7 +12,7 @@
> # See the License for the specific language gover
Parker Moore writes:
> From: Parker Moore
>
> This fixes contrib/persistent-https builds for Go v1.7+ and is
> compatible with Go v1.0+.
Thanks, applied.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info a
Jeff King writes:
> Subject: diff: do not reuse worktree files that need "clean" conversion
>
> When accessing a blob for a diff, we may try to reuse file
> contents in the working tree, under the theory that it is
> faster to mmap those file contents than it would be to
> extract the content fro
On Fri, Jul 22, 2016 at 7:25 PM, Stefan Beller wrote:
> On Fri, Jul 22, 2016 at 10:09 AM, Duy Nguyen wrote:
>>
>> I just quickly glanced through the rest of this mail because, as a
>> submodule ignorant, it's just mumbo jumbo to me. But what I see here
>> is, there may be problems if we choose to
On Fri, Jul 22, 2016 at 9:55 AM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> From a users POV there are:
>> * non existent submodules (no gitlink recorded, no config set,
>> no repo in place)
>> * not initialized submodules (gitlink is recorded, no config set,
>> and an empty repo is p
On Fri, Jul 22, 2016 at 10:09 AM, Duy Nguyen wrote:
>
> I just quickly glanced through the rest of this mail because, as a
> submodule ignorant, it's just mumbo jumbo to me. But what I see here
> is, there may be problems if we choose to share some submodule info,
> but I haven't seen any good thi
Matthieu Moy writes:
> We already suggest 'git rebase --abort' during a conflicted rebase.
> Similarly, suggest 'git merge --abort' during conflict resolution on
> 'git merge'.
>
> Signed-off-by: Matthieu Moy
> ---
It wasn't immediately obvious without the context that the changed
code will tri
On 22 July 2016 at 01:11, Johannes Schindelin
wrote:
> I know it feels good to get frustration off of your chest by ranting. I am
> very sympathetic to that. Please note, however, that it puts the people
> who are ready to help you immediately into a defensive corner. Probably
> unintentional?
S
On Thu, Jul 21, 2016 at 12:04 AM, Stefan Beller wrote:
>> diff --git a/submodule.c b/submodule.c
>> index abc2ac2..b912871 100644
>> --- a/submodule.c
>> +++ b/submodule.c
>> @@ -1128,7 +1128,9 @@ void connect_work_tree_and_git_dir(const char
>> *work_tree, const char *git_dir)
>> {
>> s
Eric Wong writes:
> Checking the version of the installed SVN libraries should not
> require a git repository at all. This matches the behavior of
> "git --version".
>
> Add a test for "git svn help" for the same behavior while we're
> at it, too.
>
> Signed-off-by: Eric Wong
> ---
> I'm hopi
On Thu, Jul 21, 2016 at 1:22 AM, Stefan Beller wrote:
> On Wed, Jul 20, 2016 at 10:24 AM, Nguyễn Thái Ngọc Duy
> wrote:
>> Signed-off-by: Nguyễn Thái Ngọc Duy
>> ---
>> Documentation/git-worktree.txt | 8
>> git-submodule.sh | 8
>> 2 files changed, 12 insertions
Jeff Hostetler writes:
>>> + case DIFF_STATUS_DELETED:
>>> + d->porcelain_v2.mode_index = p->one->mode;
>>> + hashcpy(d->porcelain_v2.sha1_index, p->one->sha1);
>>> + break;
>>> +
>>> + case DIFF_STATUS_COPIED:
>>> + case DIFF_STATUS_MODIFIED:
>>> + case DIFF
Stefan Beller writes:
> From a users POV there are:
> * non existent submodules (no gitlink recorded, no config set,
> no repo in place)
> * not initialized submodules (gitlink is recorded, no config set,
> and an empty repo is put in the working tree as a place holder).
This is no different
On Fri, Jul 22, 2016 at 12:29:45PM -0400, Jeff King wrote:
> If you have whitespace errors in lines you've introduced, it
> can be convenient to be able to jump directly to them for
> fixing. You can't quite use "git jump diff" for this,
> because though it passes arbitrary options to "git diff",
Signed-off-by: Jeff King
---
contrib/git-jump/README | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/contrib/git-jump/README b/contrib/git-jump/README
index 1cebc32..202b499 100644
--- a/contrib/git-jump/README
+++ b/contrib/git-jump/README
@@ -83,7 +83,7 @@ complete list of f
If you have whitespace errors in lines you've introduced, it
can be convenient to be able to jump directly to them for
fixing. You can't quite use "git jump diff" for this,
because though it passes arbitrary options to "git diff", it
expects to see an actual unified diff in the output.
Whereas "g
The hunk-header regex looks for "\+\d+" to find the
post-image line numbers, but it skips the pre-image line
numbers with a simple ".*". That means we may greedily eat
the post-image numbers and match a "\+\d" further on, in the
funcname text.
For example, commit 6b9c38e has this hunk header:
d
Here are a few quick fixes and features for git-jump. The first is a bug
I noticed and fixed recently. And that reminded me of the second one,
which I'd been carrying in my local copy for a long time.
[1/3]: contrib/git-jump: fix greedy regex when matching hunks
[2/3]: contrib/git-jump: add wh
Jeff King writes:
> I don't think we do. Going back to the original discussion:
>
> http://thread.gmane.org/gmane.comp.version-control.git/136141/focus=136774
>
> it was mostly just "hey, this would fail really confusingly if we ever
> did, so let's make it safe".
>
> The second strbuf_grow() i
On Fri, Jul 22, 2016 at 12:32 AM, Jens Lehmann wrote:
> Am 21.07.2016 um 01:22 schrieb Stefan Beller:
>>
>> So maybe we want to drop that series and first talk about a migration plan
>> from
>> the current state to a world where we have the existence depending not
>> on the url
>> parameter, but a
Johannes Schindelin writes:
> Hi Junio,
>
> On Mon, 18 Jul 2016, Junio C Hamano wrote:
>
>> "brian m. carlson" writes:
>>
>> > I will say that the pack format will likely require some changes,
>> > because it assumes ... The reason is that we can't have an
>> > unambiguous parse of the current
Pranit Bauva writes:
> The current branch contains 30-40 % of the work. I am going to send 3
> more functions check_and_set_terms(), bisect_next_check() and
> bisect_terms() positively by today. After that the work will be around
> 50-60% complete. After that bisect_start() (I have ported this bu
From: Lars Schneider
Git's clean/smudge mechanism invokes an external filter process for every
single blob that is affected by a filter. If Git filters a lot of blobs
then the startup time of the external filter processes can become a
significant part of the overall Git execution time.
This patc
From: Lars Schneider
Use `test_config` to set the config, check that files are empty with
`test_must_be_empty`, compare files with `test_cmp`, and remove spaces
after ">".
Signed-off-by: Lars Schneider
---
t/t0021-conversion.sh | 62 +--
1 file c
From: Lars Schneider
Git filter with spaces (e.g. `filter.sh foo`) are hard to read in
error messages. Quote them to improve the readability.
Signed-off-by: Lars Schneider
---
convert.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/convert.c b/convert.c
index
From: Lars Schneider
Hi,
Git's clean/smudge mechanism invokes an external filter process for every
single blob that is affected by a filter. If Git filters a lot of blobs
then the startup time of the external filter processes can become a
significant part of the overall Git execution time. This
On Thu, Jul 21, 2016 at 05:37:40PM -0400, Jeff King wrote:
> The next three are to show the final diffstat after the commit
> completes. It looks like the "should we reuse the worktree file?"
> optimization in diff_populate_filespec() does not take into account
> whether we will have to convert th
Hey Torsten,
On Fri, Jul 22, 2016 at 7:59 AM, Torsten Bögershausen wrote:
>
>
> On 07/20/2016 11:47 PM, Pranit Bauva wrote:
>>
>> Reimplement the `get_terms` and `bisect_terms` shell function in C and
>> add `bisect-terms` subcommand to `git bisect--helper` to call it from
>> git-bisect.sh .
>>
>
In 66a155b (Enable output buffering in merge-recursive., 2007-01-14), we
changed the code such that it prints the output in one go, to avoid
interfering with the progress output.
Let's make sure that the same holds true when outputting the commit
title: previously, we used several printf() stateme
Ever since 66a155b (Enable output buffering in merge-recursive.,
2007-01-14), we had a problem: When the merge failed in a fatal way, all
regular output was swallowed because we called die() and did not get a
chance to drain the output buffers.
To fix this, several modifications were necessary:
-
Since 66a155b (Enable output buffering in merge-recursive., 2007-01-14),
we already accumulate the output in a buffer. The idea was to avoid
interfering with the progress output that goes to stderr, which is
unbuffered, when we write to stdout, which is buffered.
We extend that buffering to allow
Last October, we had to change this code to run `git merge-recursive`
in a child process: git-am wants to print some helpful advice when the
merge failed, but the code in question was not prepared to return, it
die()d instead.
We are finally at a point when the code *is* prepared to return errors,
The data structure passed to the recursive merge machinery has a feature
where the caller can ask for the output to be buffered into a strbuf, by
setting the field 'buffer_output'.
Previously, we simply swallowed the buffered output when showing error
messages. With this patch, we show the output
The recursive merge machinery accumulates its output in an output
buffer, to be flushed at the end of merge_recursive(). At this point,
we forgot to release the output buffer.
When calling merge_trees() (i.e. the non-recursive part of the recursive
merge) directly, the output buffer is never flush
It can be puzzling to see that was_tracked() asks to get an index entry
by name, but does not take a negative return value for an answer.
The reason we have to do this is that cache_name_pos() only looks for
entries in stage 0, even if nobody asked for any stage in particular.
Let's rewrite the l
The vast majority of error messages in Git's source code which report a
bug use the convention to prefix the message with "BUG:".
As part of cleaning up merge-recursive to stop die()ing except in case of
detected bugs, let's just make the remainder of the bug reports consistent
with the de facto r
The recursive merge machinery is supposed to be a library function, i.e.
it should return an error when it fails. Originally the functions were
part of the builtin "merge-recursive", though, where it was simpler to
call die() and be done with error handling.
The existing callers were already prepa
We are about to libify the recursive merge machinery, where we only
die() in case of a bug or memory contention. To that end, we must heed
negative return values as indicating errors.
This requires our functions to be careful to pass through error
conditions in call chains, and for quite a few fun
There are a couple of places where return values indicating errors
are ignored. Let's teach them manners.
Signed-off-by: Johannes Schindelin
---
merge-recursive.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/merge-recursive.c b/merge-recursive.c
index dc3182b..2
While working on the patch series that avoids die()ing in recursive
merges, the issue came up that bug reports (i.e. die("BUG: ...")
constructs) should never be translated, as the target audience is the
Git developer community, not necessarily the current user, and hence
a translated message would
It was noticed by Brendan Forster last October that the builtin `git am`
regressed on that. Our hot fix reverted to spawning the recursive merge
instead of using it as a library function.
As we are about to revert that hot fix, after making the recursive merge a
true library function (i.e. a funct
It is technically allowed, as per C89, for functions' return type to
be complete structs (i.e. *not* just pointers to structs).
However, it was just an oversight of this developer when converting
Python code to C code in 6d297f8 (Status update on merge-recursive in
C, 2006-07-08) which introduced
It is possible that a tree cannot be written (think: disk full). We
will want to give the caller a chance to clean up instead of letting
the program die() in such a case.
Signed-off-by: Johannes Schindelin
---
merge-recursive.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --gi
Previously, callers of merge_trees() or merge_recursive() expected that
code to die() with an error message. This used to be okay because we
called those commands from scripts, and had a chance to print out a
message in case the command failed fatally (read: with exit code 128).
As scripting incur
This is the fourth iteration of the long-awaited re-roll of the attempt to
avoid spawning merge-recursive from the builtin am and use merge_recursive()
directly instead.
The *real* reason for the reroll is that I need a libified recursive
merge to accelerate the interactive rebase by teaching the
Good Day,
I am Miss Evelyn Kouassi. I will like to invest in your country. I
have a Mutual business proposal which will benefit both of us. I will
like to seek your consent first.
This project involves a huge specific amount which I can't mention
here for security reasons. If you feel you can handl
Hi Hannes,
On Thu, 21 Jul 2016, Johannes Sixt wrote:
> The previous commit introduced the first use of ENOTSOCK. This macro is
> not available on Windows. Define it as WSAENOTSOCK because that is the
> corresponding error value reported by the Windows versions of socket
> functions.
Thanks for c
Hi Brett,
On Thu, 21 Jul 2016, Brett Cundal wrote:
> [re-sending as plain-text so the list software doesn't reject as
> spam... what decade is this?]
I know it feels good to get frustration off of your chest by ranting. I am
very sympathetic to that. Please note, however, that it puts the people
Am 21.07.2016 um 01:22 schrieb Stefan Beller:
So maybe we want to drop that series and first talk about a migration plan from
the current state to a world where we have the existence depending not
on the url
parameter, but a boolean variable submodule...
Depending on a submodule would be ignored
90 matches
Mail list logo
