Re: Sending informational messages from upload-pack

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

Sending informational messages from upload-pack

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

Re: [PATCH 11/12] receive-pack: treat namespace .have lines like alternates

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,

Re: tools for easily "uncommitting" parts of a patch I just commited?

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

Re: [PATCH 4/4] core.abbrev: raise the default abbreviation to 12 hexdigits

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

Re: [PATCH v4] Refactor recv_sideband()

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

[PATCH v4] Refactor recv_sideband()

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-

Re: [PATCH v2] Refactor recv_sideband()

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

Re: [PATCH v2] Refactor recv_sideband()

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

Re: [PATCH v2] Refactor recv_sideband()

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

Re: [PATCH v3] Refactor recv_sideband()

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. */ > >

[PATCH v3] Refactor recv_sideband()

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

Re: [PATCH v2] Refactor recv_sideband()

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

Re: [PATCH v2] Refactor recv_sideband()

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

[PATCH v2] Refactor recv_sideband()

, 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

Re: [PATCH] Refactor recv_sideband()

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

[PATCH 1/2] Make send_sideband() return void

, 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

[PATCH 2/2] Make send_client_data() return void

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/

[PATCH] Refactor recv_sideband()

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

[PATCH] receive-pack: send auto-gc output over sideband 2

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

Re: Mark remote `gc --auto` error messages

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

Mark remote `gc --auto` error messages

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

Re: [PATCH] receive-pack: avoid sending duplicate "have" lines

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

[PATCH] receive-pack: avoid sending duplicate "have" lines

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

[PATCH v3 2/4] upload-pack: strip refs before calling ref_is_hidden()

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

[PATCH v3 4/4] t5509: add basic tests for hideRefs

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

[PATCH v3 3/4] Add support for matching full refs in hideRefs

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

[PATCH v3 0/4] Improve hideRefs when used with namespaces

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

[PATCH v3 1/4] Document the semantics of hideRefs with namespaces

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

[PATCH v2 0/4] Improve hideRefs when used with namespaces

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):

[PATCH v2 1/4] Document the semantics of hideRefs with namespaces

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

[PATCH v2 2/4] upload-pack: strip refs before calling ref_is_hidden()

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

[PATCH v2 3/4] Add support for matching full refs in hideRefs

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

[PATCH v2 4/4] t5509: add basic tests for hideRefs

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

Re: [PATCH] Allow hideRefs to match refs outside the namespace

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

[PATCH 3/4] Add support for matching full refs in hideRefs

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 -

[PATCH 1/4] Document the semantics of hideRefs with namespaces

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

[PATCH 4/4] t5509: add basic tests for hideRefs

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

[PATCH 2/4] upload-pack: strip refs before calling ref_is_hidden()

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

[PATCH 0/4] Improve hideRefs when used with namespaces

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

Re: [PATCH 4/4] t5509: add basic tests for hideRefs

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

Re: [PATCH 3/4] Add support for matching full refs in hideRefs

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

Re: [PATCH] Allow hideRefs to match refs outside the namespace

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

Re: [PATCH/RFC] receive-pack: allow for hiding refs outside the namespace

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 > > >

Re: [PATCH] Allow hideRefs to match refs outside the namespace

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

Re: [PATCH/RFC] receive-pack: allow for hiding refs outside the namespace

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. >

[PATCH] Allow hideRefs to match refs outside the namespace

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 "

Re: [PATCH/RFC] receive-pack: allow for hiding refs outside the namespace

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

[PATCH/RFC] receive-pack: allow for hiding refs outside the namespace

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

Re: [PATCH v4] clone: simplify string handling in guess_dir_name()

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

Re: use-after-free leads to git-blame writing garbage in error message

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

Re: [PATCH] blame.c: fix garbled error message

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

Re: [PATCH] blame.c: fix garbled error message

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

[PATCH] blame.c: fix garbled error message

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

[PATCH 2/2] bundle: Fix exclusion of annotated tags

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

[PATCH 1/2] t5704: Complement annotated tag exclusion test

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

[PATCH 2/2] bundle: Fix exclusion of annotated tags

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

[PATCH 1/2] t5704: Fix the test that checks for excluded tags

. 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

Re: Bisect needing to be at repo top-level?

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

Re: Issue with compiling git 1.8.4 under uclibc with gcc 4.6.3

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

Re: Issue with compiling git 1.8.4 under uclibc with gcc 4.6.3

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 ')'

Re: [PATCH] config: do not use C function names as struct members

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

[PATCH] Avoid using `echo -n` anywhere

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

Re: --follow is ignored when used with --reverse

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]:

Re: [PATCH] Fix grammar in the 1.8.3 release notes.

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.

Re: What's cooking in git.git (Apr 2013, #05; Mon, 15)

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]

Re: [PATCH v2 1/3] Add public function read_blob_data_from_index_path()

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

[PATCH v2 3/3] convert.c: Remove duplicate code

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

[PATCH v2 1/3] Add public function read_blob_data_from_index_path()

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

[PATCH v2 2/3] Add size parameter to read_blob_data_from_index_path()

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

[PATCH 0/3] Remove ~25 lines of duplicate code

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

[PATCH 1/3] Make read_index_data() public

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

[PATCH 3/3] convert.c: Remove duplicate code

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

[PATCH 2/3] Add size parameter to read_index_data()

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

Re: [PATCH 1/2] bundle: Accept prerequisites without commit messages

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

[PATCH 2/2] t5704: Test prerequisites with empty commit messages

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

[PATCH 1/2] bundle: Accept prerequisites without commit messages

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

[PATCH] setup.c: Remove duplicate code from prefix_pathspec()

: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

[PATCH v2] bundle: Add colons to list headings in verify

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

[PATCH 2/2] bundle: Add colons to list headings in verify

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

[PATCH 1/2] bundle: Fix verify output if history is complete

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