On Thu, 13 Dec 2018 at 03:17:21, Junio C Hamano wrote:
> Lukas Fleischer writes:
>
> > The basic idea of the service I imagine is simple:
> >
> > 1. You register a primary email address and specify a password. You
> >receive a verification email to confirm tha
I came up with the idea of creating a global mailmap service earlier
this year and, given a recent discussion on maintaining .mailmap, I
decided to bring it up here. While only marginally related to Git
development, I hope that it is relevant enough to not be considered
spam.
The basic idea of the
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 t
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, cons
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 th
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 val
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
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
Helped-by: Junio C Hamano
Helped-by: Nicolas Pitre
Signed-off-by: Lukas Fleischer
---
Changes since v3:
* The new code always frees the strbu
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 writes:
> > >
> > > > On Mon, Jun 27, 2016 at 08:54:22AM -0700, Junio C Ha
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 changing anything
>
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 switch back to usin
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. */
> >
output is preserved. See 9ac13ec (atomic write for sideband remote
messages, 2006-10-11) for details.
Helped-by: Nicolas Pitre
Signed-off-by: Lukas Fleischer
---
Now using a static strbuf for the output buffer such that the number of
memory allocations is kept to a minimum.
sideb
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
---
Now uses
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 the implementation.
, so let's turn send_sideband() into a void function
instead.
Signed-off-by: Lukas Fleischer
---
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 0a078c3..9504429 100644
case, so let's turn send_client_data() into a void
function instead.
Signed-off-by: Lukas Fleischer
---
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/upload-pack.c
+++ b/u
library function.
Signed-off-by: Lukas Fleischer
---
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
readable than what we have now. Given
the server.
Signed-off-by: Lukas Fleischer
---
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/builtin/receive-pack.c
@@ -1775,
On Thu, 02 Jun 2016 at 21:33:33, Junio C Hamano wrote:
> Lukas Fleischer writes:
>
> > 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 pre
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 display
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 sam
cluding both alternates and refs
outside the namespace) first and transmit them later, omitting any
duplicates.
Suggested-by: Junio C Hamano
Signed-off-by: Lukas Fleischer
---
This is based on pu. I am not sure whether we should also change the
name of show_one_alternate_sha1() in this patch since
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
---
upload-pack.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/upload
Test whether regular and full hideRefs patterns work as expected when
namespaces are used.
Helped-by: Eric Sunshine
Signed-off-by: Lukas Fleischer
---
t/t5509-fetch-push-namespaces.sh | 41
1 file changed, 41 insertions(+)
diff --git a/t/t5509-fetch
unintended
hideRefs settings "have" (suppressing all "have" lines) and
"capabilities^{}" (suppressing the capabilities line).
Signed-off-by: Lukas Fleischer
---
Documentation/config.txt | 3 ++-
builtin/receive-pack.c | 27 +--
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
---
Documentation
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&m=144604694223920
Lukas Fleischer (4):
Document the semantics of hideRefs with namespaces
upload-pack: str
Test whether regular and full hideRefs patterns work as expected when
namespaces are used.
Helped-by: Eric Sunshine
Signed-off-by: Lukas Fleischer
---
t/t5509-fetch-push-namespaces.sh | 41
1 file changed, 41 insertions(+)
diff --git a/t/t5509-fetch
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&m=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
---
Documentation
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
---
upload-pack.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/upload
unintended
hideRefs settings "have" (suppressing all "have" lines) and
"capabilities^{}" (suppressing the capabilities line).
Signed-off-by: Lukas Fleischer
---
Documentation/config.txt | 3 ++-
builtin/receive-pack.c | 27 +--
On Sun, 01 Nov 2015 at 22:13:51, Eric Sunshine wrote:
> On Sun, Nov 1, 2015 at 2:34 PM, Lukas Fleischer wrote:
> > Test whether regular and full hideRefs patterns work as expected when
> > namespaces are used.
> >
> > Signed-off-by: Lukas Fleischer
> > ---
&g
On Sun, 01 Nov 2015 at 21:42:37, Eric Sunshine wrote:
> On Sun, Nov 1, 2015 at 2:34 PM, Lukas Fleischer wrote:
> > In addition to matching stripped refs, one can now add hideRefs patterns
> > that the full (unstripped) ref is matched against. To distinguish
> > between stri
asic tests are added.
[1] http://marc.info/?l=git&m=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
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
---
upload-pack.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/upload
unintended
hideRefs settings "have" (suppressing all "have" lines) and
"capabilities^{}" (suppressing the capabilities line).
Signed-off-by: Lukas Fleischer
---
Documentation/config.txt | 3 ++-
builtin/receive-pack.c | 22 --
refs.c
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
---
Documentation
Test whether regular and full hideRefs patterns work as expected when
namespaces are used.
Signed-off-by: Lukas Fleischer
---
t/t5509-fetch-push-namespaces.sh | 29 +
1 file changed, 29 insertions(+)
diff --git a/t/t5509-fetch-push-namespaces.sh b/t/t5509-fetch-push
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
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 ol
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 writes:
> >
> > > 1. There does not seem to be a way to pass configuration parameters to
> > >git-shell commands. Ri
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 writes:
>
> > Right now, refs with a path outside the current namespace are replaced
> >
ed to hide specific refs outside the current namespace.
Signed-off-by: Lukas Fleischer
---
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 ".have". The other one is
sh
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.
>
Agreed,
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
---
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 similar, they do not shar
On Thu, 09 Jul 2015 at 20:24:08, Sebastian Schuberth wrote:
> Signed-off-by: Sebastian Schuberth
> ---
> 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
> --- a/builtin/c
On Tue, 03 Feb 2015 at 10:17:15, Mike Hommey wrote:
> Symptoms:
> $ git blame HEAD -- foo
> fatal: no such path foo in
>
> 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 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
> > > m
On Mon, 12 Jan 2015 at 23:55:30, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> > Lukas Fleischer 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->
by maintaining a copy of the original string.
Signed-off-by: Lukas Fleischer
---
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 that the
return value of th
this addition reveals that the annotated tag exclusion
is flawed, mark the test expect-failure for now.
Signed-off-by: Lukas Fleischer
---
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 be
merged if you prefer
the maximum length parameter.
Signed-off-by: Lukas Fleischer
---
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 @@ static int
the maximum length parameter.
Signed-off-by: Lukas Fleischer
---
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 @@ static int
. Therefore, the test is marked expect-failure for now.
Signed-off-by: Lukas Fleischer
---
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/t/t5704-bundle.sh
On Tue, Sep 17, 2013 at 10:27:49AM -0700, Junio C Hamano wrote:
> "Burton, Ross" 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 there a reaso
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'
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 statem
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 betw
scripts use a POSIX shell shebang,
replace `echo -n` invocations with printf.
Signed-off-by: Lukas Fleischer
---
contrib/subtree/git-subtree.sh | 2 +-
contrib/subtree/t/t7900-subtree.sh | 8
t/perf/perf-lib.sh | 4 ++--
3 files changed, 7 insertions(+), 7 deletions
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.
> >
On Mon, Jun 03, 2013 at 09:01:45PM +0200, Torsten Bögershausen wrote:
> The new 4015 does not pass under Mac OS:
>
> a) The seq command, does not exits (we can use printf)
> [...]
> diff --git a/t/t4015-diff-whitespace.sh b/t/t4015-diff-whitespace.sh
> index b3c4fcc..f00d20b 100755
> --- a/t/t4015
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 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 i
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
---
attr.c | 2 +-
cache.h | 2 +-
read-cache.c | 5 -
3 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/attr.c b/attr.c
index
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
---
convert.c | 27 ++-
1 file changed, 2 insertions(+), 25
for reusing the function in convert.c later.
Signed-off-by: Lukas Fleischer
---
attr.c | 35 +--
cache.h | 1 +
read-cache.c | 34 ++
3 files changed, 36 insertions(+), 34 deletions(-)
diff --git a/attr.c b/attr.c
index
On Fri, Apr 12, 2013 at 03:40:12PM -0400, Jeff King wrote:
> On Fri, Apr 12, 2013 at 07:26:11PM +0200, Lukas Fleischer wrote:
>
> > 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
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
---
convert.c | 27 ++-
1 file changed, 2 insertions(+), 25 deletions(-)
diff --git a/convert.c b
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
---
attr.c | 2 +-
cache.h | 2 +-
read-cache.c | 5 -
3 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/attr.c b/attr.c
index
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
---
I am not totally
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
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
On Sun, Apr 07, 2013 at 01:53:15PM +0200, Lukas Fleischer wrote:
> While explicitly stating that the commit message in a prerequisite line
> is optional, we required all lines with 40 or more characters to contain
> a space after the object name, bailing out if a line consisted of an
>
to reproduce this behavior.
Signed-off-by: Lukas Fleischer
---
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
---
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 parse_bundle_header(int fd
g:
setup.c: In function ‘get_pathspec’:
setup.c:207: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
---
This removes the only warning that currently occurs when bui
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
---
bundle.c |
These slightly improve the reading flow by making it obvious that a list
follows.
Signed-off-by: Lukas Fleischer
---
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/bundle.c
@@ -183,8
ist before the check to
fix this.
Signed-off-by: Lukas Fleischer
---
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/bundl
86 matches
Mail list logo
