On Mon, 20 Feb 2017 at 20:21:03, Jeff King wrote:
> On Mon, Feb 20, 2017 at 07:38:02PM +0100, Lukas Fleischer wrote:
>
> > It would be handy to be able to show a message to the user when
> > cloning/fetching from a repository (e.g. to show a warning if a
> > repository is
Hi,
It would be handy to be able to show a message to the user when
cloning/fetching from a repository (e.g. to show a warning if a
repository is deprecated). This should technically already be possible
using the current pack protocol and sidebands. However, to my knowledge,
there is no easy way
On Wed, 25 Jan 2017 at 20:51:17, Junio C Hamano wrote:
> [...]
> > diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c
> > index 8f8762e4a..c55e2f993 100644
> > --- a/builtin/receive-pack.c
> > +++ b/builtin/receive-pack.c
> > @@ -251,8 +251,9 @@ static void show_ref(const char *path,
On Thu, 20 Oct 2016 at 19:27:58, Jacob Keller wrote:
> [...]
> I still think we're misunderstanding. I want git commit to complain
> *only* under the following circumstance:
>
> I run "git add -p" and put a partial change into the index in .
> There are still other parts which were not added to
On Thu, 29 Sep 2016 at 04:44:00, SZEDER Gábor wrote:
> I for one raise my hand in protest...
>
> "few extra bytes" is not the only downside, and it's not at all about
> how many characters are copy-and-pasted. In my opinion it's much more
> important that this change wastes 5 columns worth of
On Wed, 29 Jun 2016 at 18:40:16, Junio C Hamano wrote:
> Lukas, can you see what is in 'pu' after I push out today's
> integration result in several hours and tell us if you like the
> result of the SQUASH??? change?
Looks good to me. Thank you both for working on this. Note that you
should amend
r per line,
such that the atomicity of the output is preserved. See 9ac13ec (atomic
write for sideband remote messages, 2006-10-11) for details.
Helped-by: Jeff King <p...@peff.net>
Helped-by: Junio C Hamano <gits...@pobox.com>
Helped-by: Nicolas Pitre <n...@fluxnic.net>
Signed-off-
On Mon, 27 Jun 2016 at 22:47:59, Nicolas Pitre wrote:
> On Mon, 27 Jun 2016, Lukas Fleischer wrote:
>
> > On Mon, 27 Jun 2016 at 19:50:13, Junio C Hamano wrote:
> > > Jeff King <p...@peff.net> writes:
> > >
> > > > On Mon, Jun 27
On Mon, 27 Jun 2016 at 19:50:13, Junio C Hamano wrote:
> Jeff King writes:
>
> > On Mon, Jun 27, 2016 at 08:54:22AM -0700, Junio C Hamano wrote:
> >
> >> It's just you used xwrite() there that introduced a different issue.
> >> Wouldn't replacing it with fwrite(stderr) without
On Fri, 24 Jun 2016 at 20:32:28, Junio C Hamano wrote:
> On Fri, Jun 24, 2016 at 11:14 AM, Jeff King wrote:
> >
> > I do wonder about the ANSI_SUFFIX thing, though.
>
> compat/winansi.c seems to have a provision for 'K' (and obviously 'm'
> for colors).
So we probably want to
On Thu, 23 Jun 2016 at 00:47:39, Nicolas Pitre wrote:
> On Wed, 22 Jun 2016, Nicolas Pitre wrote:
> [...]
> > if (*b) {
> > xwrite(STDERR_FILENO, outbuf.buf, outbuf.len);
> > /* Incomplete line, skip the next prefix. */
> >
the
output is preserved. See 9ac13ec (atomic write for sideband remote
messages, 2006-10-11) for details.
Helped-by: Nicolas Pitre <n...@fluxnic.net>
Signed-off-by: Lukas Fleischer <lfleisc...@lfos.de>
---
Now using a static strbuf for the output buffer such that the number of
memory allocation
On Wed, 15 Jun 2016 at 09:14:54, Lukas Fleischer wrote:
> What we could do is reintroduce the local prefix variable I had in v1
> and use that to store whether a prefix needs to be prepended or not. If
> we do that and if we are fine with strbuf memory being (potentially)
> allo
On Tue, 14 Jun 2016 at 23:00:38, Lukas Fleischer wrote:
> Improve the readability of recv_sideband() significantly by replacing
> fragile buffer manipulations with string buffers and more sophisticated
> format strings. Note that each line is printed using a single write()
> sysc
, see 9ac13ec (atomic write for sideband remote messages,
2006-10-11) for details.
Also, reorganize the overall control flow, remove some superfluous
variables and replace a custom implementation of strpbrk() with a call
to the standard C library function.
Signed-off-by: Lukas Fleischer <lfle
On Tue, 14 Jun 2016 at 20:11:12, Junio C Hamano wrote:
> Nicolas Pitre writes:
>
> > It is not buffered as it writes to stderr. And some C libs do separate
> > calls to write() for every string format specifier. So "%s%s%c" may end
> > up calling write() 3 times depending on
, so let's turn send_sideband() into a void function
instead.
Signed-off-by: Lukas Fleischer <lfleisc...@lfos.de>
---
sideband.c| 4 +---
sideband.h| 2 +-
upload-pack.c | 6 --
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/sideband.c b/sideband.c
index 0
case, so let's turn send_client_data() into a void
function instead.
Signed-off-by: Lukas Fleischer <lfleisc...@lfos.de>
---
upload-pack.c | 15 +--
1 file changed, 5 insertions(+), 10 deletions(-)
diff --git a/upload-pack.c b/upload-pack.c
index cab71b1..432d585 100644
--- a/
library function.
Signed-off-by: Lukas Fleischer <lfleisc...@lfos.de>
---
I had a really hard time reading and understanding this function when I
came up with my last patch. What I ended up with is almost a complete
rewrite of recv_sideband() and I find the end result to be much more
readabl
the server.
Signed-off-by: Lukas Fleischer <lfleisc...@lfos.de>
---
builtin/receive-pack.c | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c
index a744437..15c323a 100644
--- a/builtin/receive-pack.c
+++ b/builti
On Thu, 02 Jun 2016 at 21:33:33, Junio C Hamano wrote:
> Lukas Fleischer <lfleisc...@lfos.de> writes:
>
> > When running `git push`, it might occur that error messages are
> > transferred from the server to the client. While most messages (those
> > explicitly se
When running `git push`, it might occur that error messages are
transferred from the server to the client. While most messages (those
explicitly sent on sideband 2) are prefixed with "remote:", it seems
that error messages printed during the automatic householding performed
by git-gc(1) are
On Sat, 07 Nov 2015 at 00:38:00, Junio C Hamano wrote:
> [...]
> I suspect that many of these that turn into ".have"s point the same
> object as those sit at the tip of our refs (e.g. tags in alternates
> we borrow from, which are the folks of the same project that copy
> the same tags from the
cluding both alternates and refs
outside the namespace) first and transmit them later, omitting any
duplicates.
Suggested-by: Junio C Hamano <gits...@pobox.com>
Signed-off-by: Lukas Fleischer <lfleisc...@lfos.de>
---
This is based on pu. I am not sure whether we should also change the
n
Make hideRefs handling in upload-pack consistent with the behavior
described in the documentation by stripping refs before comparing them
with prefixes in hideRefs.
Signed-off-by: Lukas Fleischer <lfleisc...@lfos.de>
---
upload-pack.c | 6 +++---
1 file changed, 3 insertions(+), 3 del
Test whether regular and full hideRefs patterns work as expected when
namespaces are used.
Helped-by: Eric Sunshine <sunsh...@sunshineco.com>
Signed-off-by: Lukas Fleischer <lfleisc...@lfos.de>
---
t/t5509-fetch-push-namespaces.sh | 41
1 file
and unintended
hideRefs settings "have" (suppressing all "have" lines) and
"capabilities^{}" (suppressing the capabilities line).
Signed-off-by: Lukas Fleischer <lfleisc...@lfos.de>
---
Documentation/config.txt | 3 ++-
builtin/receive-pack.c | 27
asic tests are added.
Changes since v2:
* Reword the additions to the documentation as suggested by Junio.
* Fix the return value in show_ref_cb().
[1] http://marc.info/?l=git=144604694223920
Lukas Fleischer (4):
Document the semantics of hideRefs with namespaces
upload-pack: strip refs befo
Right now, there is no clear definition of how transfer.hideRefs should
behave when a namespace is set. Explain that hideRefs prefixes match
stripped names in that case. This is how hideRefs patterns are currently
handled in receive-pack.
Signed-off-by: Lukas Fleischer <lfleisc...@lfos
asic tests are added.
Changes since v1:
* Improvements in the code for denying pushing hidden refs.
* Simplification of the tests as suggested by Eric.
* New tests for the code for denying pushing hidden refs.
* Comments.
[1] http://marc.info/?l=git=144604694223920
Lukas Fleischer (4):
Right now, there is no clear definition of how transfer.hideRefs should
behave when a namespace is set. Explain that hideRefs prefixes match
stripped names in that case. This is how hideRefs patterns are currently
handled in receive-pack.
Signed-off-by: Lukas Fleischer <lfleisc...@lfos
Make hideRefs handling in upload-pack consistent with the behavior
described in the documentation by stripping refs before comparing them
with prefixes in hideRefs.
Signed-off-by: Lukas Fleischer <lfleisc...@lfos.de>
---
upload-pack.c | 6 +++---
1 file changed, 3 insertions(+), 3 del
and unintended
hideRefs settings "have" (suppressing all "have" lines) and
"capabilities^{}" (suppressing the capabilities line).
Signed-off-by: Lukas Fleischer <lfleisc...@lfos.de>
---
Documentation/config.txt | 3 ++-
builtin/receive-pack.c | 27
Test whether regular and full hideRefs patterns work as expected when
namespaces are used.
Helped-by: Eric Sunshine <sunsh...@sunshineco.com>
Signed-off-by: Lukas Fleischer <lfleisc...@lfos.de>
---
t/t5509-fetch-push-namespaces.sh | 41
1 file
On Sun, 01 Nov 2015 at 00:40:39, Lukas Fleischer wrote:
> On Sat, 31 Oct 2015 at 18:31:23, Junio C Hamano wrote:
> > [...]
> > You earlier (re)discovered a good approach to introduce a new
> > feature without breaking settings of existing users when we
> > discussed a
and unintended
hideRefs settings "have" (suppressing all "have" lines) and
"capabilities^{}" (suppressing the capabilities line).
Signed-off-by: Lukas Fleischer <lfleisc...@lfos.de>
---
Documentation/config.txt | 3 ++-
builtin/receive-pack.c | 22 -
Right now, there is no clear definition of how transfer.hideRefs should
behave when a namespace is set. Explain that hideRefs prefixes match
stripped names in that case. This is how hideRefs patterns are currently
handled in receive-pack.
Signed-off-by: Lukas Fleischer <lfleisc...@lfos
Test whether regular and full hideRefs patterns work as expected when
namespaces are used.
Signed-off-by: Lukas Fleischer <lfleisc...@lfos.de>
---
t/t5509-fetch-push-namespaces.sh | 29 +
1 file changed, 29 insertions(+)
diff --git a/t/t5509-fetch-push-namespa
Make hideRefs handling in upload-pack consistent with the behavior
described in the documentation by stripping refs before comparing them
with prefixes in hideRefs.
Signed-off-by: Lukas Fleischer <lfleisc...@lfos.de>
---
upload-pack.c | 6 +++---
1 file changed, 3 insertions(+), 3 del
asic tests are added.
[1] http://marc.info/?l=git=144604694223920
Lukas Fleischer (4):
Document the semantics of hideRefs with namespaces
upload-pack: strip refs before calling ref_is_hidden()
Add support for matching full refs in hideRefs
t5509: add basic tests for hideRefs
Doc
On Sun, 01 Nov 2015 at 22:13:51, Eric Sunshine wrote:
> On Sun, Nov 1, 2015 at 2:34 PM, Lukas Fleischer <lfleisc...@lfos.de> wrote:
> > Test whether regular and full hideRefs patterns work as expected when
> > namespaces are used.
> >
> > Signed-off-by: Lu
On Sun, 01 Nov 2015 at 21:42:37, Eric Sunshine wrote:
> On Sun, Nov 1, 2015 at 2:34 PM, Lukas Fleischer <lfleisc...@lfos.de> wrote:
> > In addition to matching stripped refs, one can now add hideRefs patterns
> > that the full (unstripped) ref is matched against. To di
I wrote this email on Thursday but it seems like it did not make it
through the mailing list. Resubmitting...
On Wed, 28 Oct 2015 at 17:21:59, Junio C Hamano wrote:
> Lukas Fleischer <lfleisc...@lfos.de> writes:
>
> > Right now, refs with a path outside the current name
On Fri, 30 Oct 2015 at 22:46:19, Jeff King wrote:
> On Fri, Oct 30, 2015 at 02:31:28PM -0700, Junio C Hamano wrote:
>
> > Lukas Fleischer <lfleisc...@lfos.de> writes:
> >
> > > 1. There does not seem to be a way to pass configuration parameters to
> > >
On Sat, 31 Oct 2015 at 18:31:23, Junio C Hamano wrote:
> [...]
> You earlier (re)discovered a good approach to introduce a new
> feature without breaking settings of existing users when we
> discussed a "whitelist". Since setting the configuration to an
> empty string did not do anything in the
On Tue, 27 Oct 2015 at 19:18:26, Junio C Hamano wrote:
> [...]
> When I asked 'Is transfer.hiderefs insufficient?', I wasn't
> expecting it to be usable out of box. It was a suggestion to build
> on top of it, instead of adding a parallel support for something
> specific to namespaces.
>
ed to hide specific refs outside the current namespace.
Signed-off-by: Lukas Fleischer <lfleisc...@lfos.de>
---
The other show_ref() call sites are in show_one_alternate_sha1() and in
write_head_info(). The call site in show_one_alternate_sha1() is for
alternates and passes "
On Tue, 27 Oct 2015 at 06:59:11, Lukas Fleischer wrote:
> [...]
> On second thought, it might be possible to overwrite the value of
> transfer.hiderefs using the -c command line option. If we combine that
> with the negative patterns supported by hiderefs, we might get a
> solutio
determine whether refs outside the current namespace should be
advertised or not.
Signed-off-by: Lukas Fleischer <lfleisc...@lfos.de>
---
We are using Git namespaces to store a huge number of (virtual)
repositories inside a shared repository. While the blobs in the virtual
repositories are fairly
On Thu, 09 Jul 2015 at 20:24:08, Sebastian Schuberth wrote:
Signed-off-by: Sebastian Schuberth sschube...@gmail.com
---
builtin/clone.c | 17 +
1 file changed, 5 insertions(+), 12 deletions(-)
diff --git a/builtin/clone.c b/builtin/clone.c
index 00535d0..ebcb849 100644
On Tue, 03 Feb 2015 at 10:17:15, Mike Hommey wrote:
Symptoms:
$ git blame HEAD -- foo
fatal: no such path foo in random garbage
Expected output:
$ git blame HEAD -- foo
fatal: no such path foo in HEAD
Bisect says this was introduced in 1da1e07c835e900337714cfad6c32a8dc0b36ac3
On Tue, 13 Jan 2015 at 02:54:27, Jeff King wrote:
On Mon, Jan 12, 2015 at 04:11:06PM -0800, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
As an aside, I have often been tempted to have xstrdup silently
propagate a NULL. It would have been the right thing to do here, but
On Mon, 12 Jan 2015 at 23:55:30, Junio C Hamano wrote:
Junio C Hamano gits...@pobox.com writes:
Lukas Fleischer g...@cryptocrack.de writes:
The helper functions prepare_final() and prepare_initial() return a
pointer to a string that is a member of an object in the revs-pending
array
this by maintaining a copy of the original string.
Signed-off-by: Lukas Fleischer g...@cryptocrack.de
---
The bug manifests when running `git blame HEAD^ -- nonexistent.file`.
Note that I could have reduced code churn a little by moving the
xstrdup() invocations to the call sites. However, I think
for with the maximum length parameter.
Signed-off-by: Lukas Fleischer g...@cryptocrack.de
---
bundle.c | 4 ++--
t/t5704-bundle.sh | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/bundle.c b/bundle.c
index 71a21a6..b708906 100644
--- a/bundle.c
+++ b/bundle.c
@@ -221,8 +221,8
this addition reveals that the annotated tag exclusion
is flawed, mark the test expect-failure for now.
Signed-off-by: Lukas Fleischer g...@cryptocrack.de
---
I decided that it is still worthwhile to have this in a separate patch.
Feel free to squash 1/2 and 2/2 or let me know that they should
for with the maximum length parameter.
Signed-off-by: Lukas Fleischer g...@cryptocrack.de
---
bundle.c | 4 ++--
t/t5704-bundle.sh | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/bundle.c b/bundle.c
index 71a21a6..b708906 100644
--- a/bundle.c
+++ b/bundle.c
@@ -221,8 +221,8
. Therefore, the test is marked expect-failure for now.
Signed-off-by: Lukas Fleischer g...@cryptocrack.de
---
t/t5704-bundle.sh | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/t/t5704-bundle.sh b/t/t5704-bundle.sh
index a45c316..2f063ea 100755
--- a/t/t5704-bundle.sh
+++ b
On Tue, Sep 17, 2013 at 10:27:49AM -0700, Junio C Hamano wrote:
Burton, Ross ross.bur...@intel.com writes:
Why does git-bisect need to be ran from the top level of the working
tree? It sources git-sh-setup.sh which sets GIT_DIR, which
git-bisect.sh then appears to consistently use. Is
On Mon, Aug 26, 2013 at 02:10:43PM -0600, Lance wrote:
Up until the latest release, I've been able to compile git for a
uclibc based embedded linux. The toolchain I use is from entware,
which is based off of the openwrt toolchain.
https://code.google.com/p/wl500g-repo/
Somewhere between git
On Mon, Aug 26, 2013 at 02:29:12PM -0600, Lance wrote:
[...]
CC config.o
config.c: In function 'get_next_char':
config.c:220:14: error: expected identifier before '(' token
config.c:220:14: error: expected statement before ')' token
config.c:220:14: error: expected statement before ')'
On Mon, Aug 26, 2013 at 05:57:18PM -0400, Jeff King wrote:
On Mon, Aug 26, 2013 at 04:59:01PM -0400, Jeff King wrote:
Hmm. I wonder if fgetc is a macro in uclibc? Just grepping their
stdio.h, it looks like that is a possibility.
I think they are probably wrong to do so (but I'd have to
scripts use a POSIX shell shebang,
replace `echo -n` invocations with printf.
Signed-off-by: Lukas Fleischer g...@cryptocrack.de
---
contrib/subtree/git-subtree.sh | 2 +-
contrib/subtree/t/t7900-subtree.sh | 8
t/perf/perf-lib.sh | 4 ++--
3 files changed, 7
On Tue, Jul 02, 2013 at 10:19:36AM +0100, John Keeping wrote:
On Fri, May 24, 2013 at 01:23:24AM +0200, Alois Mahdal wrote:
Hello!
This [has been reported][1] to this list about half a year ago
but with no response so I'm not even sure if it's been
acknowledged as bug.
[1]:
On Tue, Apr 30, 2013 at 10:28:21AM -0400, Marc Branchaud wrote:
On 13-04-29 05:15 PM, Junio C Hamano wrote:
Marc Branchaud marcn...@xiplink.com writes:
This started out as an attempt to make the backward compatibility notes
more parsable, but then I just kept going...
Thanks.
On Mon, Apr 15, 2013 at 01:28:53PM -0700, Junio C Hamano wrote:
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
[...]
--
[New Topics]
On Sat, Apr 13, 2013 at 10:49:36PM -0700, Junio C Hamano wrote:
Thanks. I'll queue with the following API fix-up on this, with
obvious adjustments necessary for the later ones.
* read_blob_data_from_index() is descriptive enough. If you read a
blob from the index, you would ask for it
has_cr_in_index() is an almost 1:1 copy of
read_blob_data_from_index_path() with some additions. Invoke
read_blob_data_from_index_path() instead of using copy-pasted code.
Signed-off-by: Lukas Fleischer g...@cryptocrack.de
---
convert.c | 27 ++-
1 file changed, 2
for reusing the function in convert.c later.
Signed-off-by: Lukas Fleischer g...@cryptocrack.de
---
attr.c | 35 +--
cache.h | 1 +
read-cache.c | 34 ++
3 files changed, 36 insertions(+), 34 deletions(-)
diff --git
This allows for optionally getting the size of the returned data and
will be used in a follow-up patch.
Signed-off-by: Lukas Fleischer g...@cryptocrack.de
---
attr.c | 2 +-
cache.h | 2 +-
read-cache.c | 5 -
3 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/attr.c b
Merge read_index_data() and has_cr_in_index() which are almost 1:1
copies of each other.
Lukas Fleischer (3):
Make read_index_data() public
Add size parameter to read_index_data()
convert.c: Remove duplicate code
attr.c | 35 +--
cache.h | 1
This allows for reusing the function in convert.c later.
Also, move it from attr.c to read-cache.c and add a use_index parameter
to specify a custom index_state since we are no longer enable to access
the static use_index variable from attr.c.
Signed-off-by: Lukas Fleischer g...@cryptocrack.de
has_cr_in_index() is an almost 1:1 copy of read_index_data() with some
additions. Invoke read_index_data() instead of using copy-pasted code.
Signed-off-by: Lukas Fleischer g...@cryptocrack.de
---
convert.c | 27 ++-
1 file changed, 2 insertions(+), 25 deletions(-)
diff
This allows for optionally getting the size of the returned data and
will be used in a follow-up patch.
Signed-off-by: Lukas Fleischer g...@cryptocrack.de
---
attr.c | 2 +-
cache.h | 2 +-
read-cache.c | 5 -
3 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/attr.c b
On Sun, Apr 07, 2013 at 09:06:10PM -0400, Jeff King wrote:
On Sun, Apr 07, 2013 at 10:21:33AM -0700, Junio C Hamano wrote:
As to the order of comparison to match the order on the number line,
e.g. write 0 something or negative 0 to let readers more
easily visualize in what relation on
to reproduce this behavior.
Signed-off-by: Lukas Fleischer g...@cryptocrack.de
---
t/t5704-bundle.sh | 10 ++
1 file changed, 10 insertions(+)
diff --git a/t/t5704-bundle.sh b/t/t5704-bundle.sh
index 9e43731..a45c316 100755
--- a/t/t5704-bundle.sh
+++ b/t/t5704-bundle.sh
@@ -58,4 +58,14
characters to contain the separating space.
Signed-off-by: Lukas Fleischer g...@cryptocrack.de
---
bundle.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/bundle.c b/bundle.c
index 505e07e..4b0e5cd 100644
--- a/bundle.c
+++ b/bundle.c
@@ -57,7 +57,7 @@ static int
:8: warning: ‘nextat’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
setup.c:205:15: note: ‘nextat’ was declared here
Signed-off-by: Lukas Fleischer g...@cryptocrack.de
---
This removes the only warning that currently occurs when building the
next branch.
Junio: Feel free
These slightly improve the reading flow by making it obvious that a list
follows.
Also, make the wording of both headings consistent by changing contains
%d ref(s) to contains this ref/contains these %d refs.
Signed-off-by: Lukas Fleischer g...@cryptocrack.de
---
bundle.c | 8
1 file
These slightly improve the reading flow by making it obvious that a list
follows.
Signed-off-by: Lukas Fleischer g...@cryptocrack.de
---
bundle.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/bundle.c b/bundle.c
index 65db53b..8cd8b4f 100644
--- a/bundle.c
+++ b
the check to
fix this.
Signed-off-by: Lukas Fleischer g...@cryptocrack.de
---
I am not sure whether we should add a test case for such a simple bug.
If you think we should, just let me know and I will add one.
bundle.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/bundle.c b
81 matches
Mail list logo