[PATCH 1/1] doc: Mention info/attributes in gitrepository-layout

Signed-off-by: Steffen Prohaska --- Documentation/gitrepository-layout.txt | 4 1 file changed, 4 insertions(+) diff --git a/Documentation/gitrepository-layout.txt b/Documentation/gitrepository-layout.txt index adf9554ad2..c60bcad44a 100644 --- a/Documentation/gitrepository-layout.txt

git-sha-x: idea for stronger cryptographic verification while keeping SHA1 content addresses

8f2db17dbc9eb46b59b5f7b7a7e05eab7df0ef89dec65 author Steffen Prohaska 1488122961 +0100 committer Steffen Prohaska 1488123452 +0100 gpgsig ... ``` GPG signatures would automatically cover the supplementary hashes. Verification code paths would have to be added to compute the hashes from the content t

[PATCH] subtree: fix AsciiDoc list item continuation

List items must be continued with '+' (see [asciidoc]). [asciidoc] AsciiDoc user guide 17.7. List Item Continuation <http://www.methods.co.nz/asciidoc/userguide.html#X15> Signed-off-by: Steffen Prohaska --- contrib/subtree/git-subtree.txt | 194 ++-

[PATCH] sha1_file: don't convert off_t to size_t too early to avoid potential die()

, index_stream_convert_blob() is able to handle a large file if a filter is configured that returns a small result. Signed-off-by: Steffen Prohaska --- This patch should be applied on top of sp/stream-clean-filter. index_stream() might internally also be able to handle large files to some extent. But it

How to update index stat info without reading file content?

Hi, Is there a way to update the stat information recorded in the index without reading the file content from disk? Starting from a clean working copy with a committed `file`, I'd like touch file git file to bring the index into essentially the same state as touch file git s

[PATCH] Documentation: use single-parameter --cacheinfo in example

The single-parameter form is described as the preferred way. Separate arguments are only supported for backward compatibility. Update the example to the recommended form. Signed-off-by: Steffen Prohaska --- Documentation/git-update-index.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion

Re: [PATCH v6 5/6] Change copy_fd() to not close input fd

On Aug 26, 2014, at 8:29 PM, Jeff King wrote: > On Tue, Aug 26, 2014 at 05:23:24PM +0200, Steffen Prohaska wrote: > >> The caller opened the fd, so it should be responsible for closing it. >> >> Signed-off-by: Steffen Prohaska >> --- >> copy.c | 5 +-

Re: [PATCH v6 2/6] Add git_env_ulong() to parse environment variable

On Aug 27, 2014, at 4:47 PM, Junio C Hamano wrote: > Jeff King writes: > >> On Tue, Aug 26, 2014 at 02:54:11PM -0700, Junio C Hamano wrote: >> >>> A worse position is to have git_env_bool() that says "empty is >>> false" and add a new git_env_ulong() that says "empty is unset". >>> >>> We sh

[PATCH v6 0/6] Stream fd to clean filter; GIT_MMAP_LIMIT, GIT_ALLOC_LIMIT with git_env_ulong()

Changes since v5: - Introduce and use git_env_ulong(). - Change copy_fd() to not close input fd, which simplified changes to convert. - More detailed explanation why filter must be marked "required" in commit message of 6/6. - Style fixes. Steffen Prohaska (6): convert: drop

[PATCH v6 3/6] Change GIT_ALLOC_LIMIT check to use git_env_ulong()

direct practical impact, because we use GIT_ALLOC_LIMIT to test small sizes. The cast of size in the call to die() is changed to uintmax_t to match the format string PRIuMAX. Signed-off-by: Steffen Prohaska --- t/t1050-large.sh | 2 +- wrapper.c| 15 --- 2 files changed, 9

[PATCH v6 6/6] convert: stream from fd to required clean filter to reduce used address space

actually has been modified on its way from the file system to the object store. Signed-off-by: Steffen Prohaska --- convert.c | 55 +-- convert.h | 5 + sha1_file.c | 27 - t/t0021

[PATCH v6 4/6] Introduce GIT_MMAP_LIMIT to allow testing expected mmap size

more large blob test cases Signed-off-by: Steffen Prohaska --- sha1_file.c | 18 +- 1 file changed, 17 insertions(+), 1 deletion(-) diff --git a/sha1_file.c b/sha1_file.c index 00c07f2..d9b5157 100644 --- a/sha1_file.c +++ b/sha1_file.c @@ -663,10 +663,26 @@ void

[PATCH v6 2/6] Add git_env_ulong() to parse environment variable

The new function will be used to parse GIT_MMAP_LIMIT and GIT_ALLOC_LIMIT. Signed-off-by: Steffen Prohaska --- cache.h | 1 + config.c | 11 +++ 2 files changed, 12 insertions(+) diff --git a/cache.h b/cache.h index fcb511d..b820b6a 100644 --- a/cache.h +++ b/cache.h @@ -1318,6

[PATCH v6 5/6] Change copy_fd() to not close input fd

The caller opened the fd, so it should be responsible for closing it. Signed-off-by: Steffen Prohaska --- copy.c | 5 + lockfile.c | 3 +++ 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/copy.c b/copy.c index a7f58fd..d0a1d82 100644 --- a/copy.c +++ b/copy.c @@ -10,7

[PATCH v6 1/6] convert: drop arguments other than 'path' from would_convert_to_git()

It is only the path that matters in the decision whether to filter or not. Clarify this by making path the single argument of would_convert_to_git(). Signed-off-by: Steffen Prohaska --- convert.h | 5 ++--- sha1_file.c | 2 +- 2 files changed, 3 insertions(+), 4 deletions(-) diff --git a

Re: [PATCH v5 4/4] convert: Stream from fd to required clean filter instead of mmap

On Aug 25, 2014, at 2:43 PM, Jeff King wrote: > On Sun, Aug 24, 2014 at 06:07:46PM +0200, Steffen Prohaska wrote: > >> The data is streamed to the filter process anyway. Better avoid mapping >> the file if possible. This is especially useful if a clean filter >> reduc

Re: [PATCH v5 2/4] Change GIT_ALLOC_LIMIT check to use git_parse_ulong()

On Aug 25, 2014, at 1:38 PM, Jeff King wrote: > On Sun, Aug 24, 2014 at 06:07:44PM +0200, Steffen Prohaska wrote: > >> diff --git a/wrapper.c b/wrapper.c >> index bc1bfb8..69d1c9b 100644 >> --- a/wrapper.c >> +++ b/wrapper.c >> @@ -11,14 +11,18 @@ static voi

[PATCH v5 3/4] Introduce GIT_MMAP_LIMIT to allow testing expected mmap size

more large blob test cases Signed-off-by: Steffen Prohaska --- sha1_file.c | 21 - 1 file changed, 20 insertions(+), 1 deletion(-) diff --git a/sha1_file.c b/sha1_file.c index 00c07f2..3204f66 100644 --- a/sha1_file.c +++ b/sha1_file.c @@ -663,10 +663,29 @@ void

[PATCH v5 0/4] Stream fd to clean filter; GIT_MMAP_LIMIT, GIT_ALLOC_LIMIT with git_parse_ulong()

Changes since v4: use git_parse_ulong() to parse env vars. Steffen Prohaska (4): convert: Refactor would_convert_to_git() to single arg 'path' Change GIT_ALLOC_LIMIT check to use git_parse_ulong() Introduce GIT_MMAP_LIMIT to allow testing expected mmap size convert: Stream

[PATCH v5 2/4] Change GIT_ALLOC_LIMIT check to use git_parse_ulong()

direct practical impact, because we use GIT_ALLOC_LIMIT to test small sizes. The cast of size in the call to die() is changed to uintmax_t to match the format string PRIuMAX. Signed-off-by: Steffen Prohaska --- t/t1050-large.sh | 2 +- wrapper.c| 16 ++-- 2 files cha

[PATCH v5 1/4] convert: Refactor would_convert_to_git() to single arg 'path'

It is only the path that matters in the decision whether to filter or not. Clarify this by making path the single argument of would_convert_to_git(). Signed-off-by: Steffen Prohaska --- convert.h | 5 ++--- sha1_file.c | 2 +- 2 files changed, 3 insertions(+), 4 deletions(-) diff --git a

[PATCH v5 4/4] convert: Stream from fd to required clean filter instead of mmap

verify that the data actually has been modified on its way from the file system to the object store. Signed-off-by: Steffen Prohaska --- convert.c | 60 +-- convert.h | 5 + sha1_file.c | 27

Re: [PATCH v3 2/3] Introduce GIT_MMAP_LIMIT to allow testing expected mmap size

On Aug 22, 2014, at 6:31 PM, Junio C Hamano wrote: > Steffen Prohaska writes: > >>>> + if (limit == -1) { >>>> + const char *env = getenv("GIT_MMAP_LIMIT"); >>>> + limit = env ? atoi(env) * 1024 : 0; >> >> ..

[PATCH v4 4/4] convert: Stream from fd to required clean filter instead of mmap

verify that the data actually has been modified on its way from the file system to the object store. Signed-off-by: Steffen Prohaska --- convert.c | 60 +-- convert.h | 5 + sha1_file.c | 27

[PATCH v4 0/4] Stream fd to clean filter, GIT_MMAP_LIMIT, GIT_ALLOC_LIMIT

Only changes since PATCH v3: Use ssize_t to store limits. Steffen Prohaska (4): convert: Refactor would_convert_to_git() to single arg 'path' Introduce GIT_MMAP_LIMIT to allow testing expected mmap size Change GIT_ALLOC_LIMIT check to use ssize_t for consistency convert: Stream

[PATCH v4 2/4] Introduce GIT_MMAP_LIMIT to allow testing expected mmap size

blob test cases Signed-off-by: Steffen Prohaska --- sha1_file.c | 17 - 1 file changed, 16 insertions(+), 1 deletion(-) diff --git a/sha1_file.c b/sha1_file.c index 00c07f2..603673b 100644 --- a/sha1_file.c +++ b/sha1_file.c @@ -663,10 +663,25 @@ void release_pack_memory

[PATCH v4 1/4] convert: Refactor would_convert_to_git() to single arg 'path'

It is only the path that matters in the decision whether to filter or not. Clarify this by making path the single argument of would_convert_to_git(). Signed-off-by: Steffen Prohaska --- convert.h | 5 ++--- sha1_file.c | 2 +- 2 files changed, 3 insertions(+), 4 deletions(-) diff --git a

[PATCH v4 3/4] Change GIT_ALLOC_LIMIT check to use ssize_t for consistency

ormat string PRIuMAX. Signed-off-by: Steffen Prohaska --- wrapper.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/wrapper.c b/wrapper.c index bc1bfb8..e91f6e9 100644 --- a/wrapper.c +++ b/wrapper.c @@ -11,14 +11,14 @@ static void (*try_to_free_routine)(size_t

Re: [PATCH v3 2/3] Introduce GIT_MMAP_LIMIT to allow testing expected mmap size

On Aug 22, 2014, at 12:26 AM, Junio C Hamano wrote: > Steffen Prohaska writes: > >> Similar to testing expectations about malloc with GIT_ALLOC_LIMIT (see >> commit d41489), it can be useful to test expectations about mmap. >> >> This introduces a new environm

[PATCH v3 3/3] convert: Stream from fd to required clean filter instead of mmap

verify that the data actually has been modified on its way from the file system to the object store. Signed-off-by: Steffen Prohaska --- convert.c | 60 +-- convert.h | 5 + sha1_file.c | 27

[PATCH v3 0/3] Stream fd to clean filter, GIT_MMAP_LIMIT

I revised the testing approach as discussed. Patch 2/3 adds GIT_MMAP_LIMIT, which allows testing of memory expectations together with GIT_ALLOC_LIMIT. The rest is unchanged compared to v2. Steffen Prohaska (3): convert: Refactor would_convert_to_git() to single arg 'path'

[PATCH v3 2/3] Introduce GIT_MMAP_LIMIT to allow testing expected mmap size

blob test cases Signed-off-by: Steffen Prohaska --- sha1_file.c | 17 - 1 file changed, 16 insertions(+), 1 deletion(-) diff --git a/sha1_file.c b/sha1_file.c index 00c07f2..88d64c0 100644 --- a/sha1_file.c +++ b/sha1_file.c @@ -663,10 +663,25 @@ void release_pack_memory

[PATCH v3 1/3] convert: Refactor would_convert_to_git() to single arg 'path'

It is only the path that matters in the decision whether to filter or not. Clarify this by making path the single argument of would_convert_to_git(). Signed-off-by: Steffen Prohaska --- convert.h | 5 ++--- sha1_file.c | 2 +- 2 files changed, 3 insertions(+), 4 deletions(-) diff --git a

Re: [PATCH v2 2/2] convert: Stream from fd to required clean filter instead of mmap

On Aug 19, 2014, at 9:53 AM, Jeff King wrote: >>> For files >2GB on a 32-bit system (e.g. msysgit), filtering with the >>> previous code always failed. Now it works. I created the patch to >>> change git from 'fundamentally doesn't handle this' to 'works as >>> expected'. >> >> I deal with si

Re: [PATCH v2 2/2] convert: Stream from fd to required clean filter instead of mmap

On Aug 17, 2014, at 9:27 AM, Jeff King wrote: > On Sat, Aug 16, 2014 at 06:26:08PM +0200, Steffen Prohaska wrote: > >>> Is the 15MB limit supposed to be imposed somewhere or is it just a guide >>> of how much memory we expect Git to use in this scenario? >> >&

Re: [PATCH v2 2/2] convert: Stream from fd to required clean filter instead of mmap

On Aug 16, 2014, at 7:00 PM, Andreas Schwab wrote: > Steffen Prohaska writes: > >> The test should confirm that the the file that is added is not mmapped to >> memory. > > RSS doesn't tell you that. You can mmap a big file without RSS getting > bigger. All

Re: [PATCH v2 2/2] convert: Stream from fd to required clean filter instead of mmap

On Aug 16, 2014, at 12:27 PM, John Keeping wrote: >> +test_expect_success HAVE_MAX_MEM_USAGE \ >> +'filtering large input to small output should use little memory' ' >> +git config filter.devnull.clean "cat >/dev/null" && >> +git config filter.devnull.required true && >> +for i in $(

[PATCH v2 1/2] convert: Refactor would_convert_to_git() to single arg 'path'

It is only the path that matters in the decision whether to filter or not. Clarify this by making path the single argument of would_convert_to_git(). Signed-off-by: Steffen Prohaska --- convert.h | 5 ++--- sha1_file.c | 2 +- 2 files changed, 3 insertions(+), 4 deletions(-) diff --git a

[PATCH v2 0/2] Stream fd to clean filter

The main difference to the previous version is that I've split off the refactoring into a separate commit. The rest is polishing the style. Steffen Prohaska (2): convert: Refactor would_convert_to_git() to single arg 'path' convert: Stream from fd to required clean filter

[PATCH v2 2/2] convert: Stream from fd to required clean filter instead of mmap

/usr/bin/time. An alternative would have been tcsh, which could be used to print memory information as follows: tcsh -c 'set time=(0 "%M"); ' Although the logic could perhaps be simplified with tcsh, I chose to use 'time' to avoid a dependency on tcsh. S

Re: [PATCH] convert: Stream from fd to required clean filter instead of mmap

On Aug 6, 2014, at 6:22 AM, Steffen Prohaska wrote: > On Aug 4, 2014, at 9:03 PM, Junio C Hamano wrote: > >>> + return apply_filter(path, 0, 0, -1, 0, ca.drv->clean); >> >> What's the significance of "-1" here? Does somebody in the >> ca

Re: [PATCH] convert: Stream from fd to required clean filter instead of mmap

I'll address the comments about style in a revised patch. On Aug 4, 2014, at 9:03 PM, Junio C Hamano wrote: >> +return apply_filter(path, 0, 0, -1, 0, ca.drv->clean); > > What's the significance of "-1" here? Does somebody in the > callchain from apply_filter() check if fd < 0 and act dif

[PATCH] convert: Stream from fd to required clean filter instead of mmap

/usr/bin/time. An alternative would have been tcsh, which could be used to print memory information as follows: tcsh -c 'set time=(0 "%M"); ' Although the logic could perhaps be simplified with tcsh, I chose to use 'time' to avoid a dependency on tcsh. S

[PATCH v2] completion: Handle '!f() { ... }; f' and "!sh -c '...'" aliases

ow trigger commit completion. Shell function declarations now work with or without space before the parens, i.e. '!f() ...' and '!f () ...' both work. [1] https://git.wiki.kernel.org/index.php/Aliases Signed-off-by: Steffen Prohaska --- contrib/completion/git-compl

Re: [PATCH v2] completion: Handle '!f() { ... }; f' aliases

On Jun 10, 2014, at 7:27 AM, Junio C Hamano wrote: > Steffen Prohaska writes: > > I tend to prefer writing it like so instead: > >sh -c '...' - > > so that I won't clobber "f" (or any other name). I wonder if you > can help users of

[PATCH v2] completion: Handle '!f() { ... }; f' aliases

s now skipped, so that it can be used as a workaround to declare the desired completion style. For example, the alias '!f() { : git commit ; if ... ' now triggers commit completion. [1] https://git.wiki.kernel.org/index.php/Aliases Signed-off-by: Steffen Prohaska --- I changed the te

[PATCH] completion: Handle '!f() { ... }; f' aliases

s now skipped, so that it can be used as a workaround to declare the desired completion style. For example, the alias '!f() { : git commit ; if ... ' now triggers commit completion. [1] https://git.wiki.kernel.org/index.php/Aliases Signed-off-by: Steffen Prohaska --- contrib/co

Re: [ANNOUNCE] Git v1.8.4.1

Hello Jonathan, On Sep 27, 2013, at 8:52 PM, Jonathan Nieder wrote: > The latest maintenance release Git v1.8.4.1 is now available. I can't find the following three minor doc fixes http://article.gmane.org/gmane.comp.version-control.git/235234 http://article.gmane.org/gmane.comp.version-co

[PATCH] git-prune-packed.txt: Fix reference to GIT_OBJECT_DIRECTORY

git-prune-packed operates on GIT_OBJECT_DIRECTORY. See 'environment.c', git_object_dir = getenv(DB_ENVIRONMENT); and cache.h, #define DB_ENVIRONMENT "GIT_OBJECT_DIRECTORY" Signed-off-by: Steffen Prohaska --- Documentation/git-prune-packed.txt | 2 +- 1 file

[PATCH] git.txt: Fix asciidoc syntax of --*-pathspecs

Labeled lists require a double colon. Signed-off-by: Steffen Prohaska --- Documentation/git.txt | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Documentation/git.txt b/Documentation/git.txt index 5d68d33..4c2757e 100644 --- a/Documentation/git.txt +++ b/Documentation

[PATCH v5 1/2] xread, xwrite: Limit size of IO, fixing IO of 2GB and more on Mac OS X

on Mac OS X/XNU Signed-off-by: Steffen Prohaska --- t/t0021-conversion.sh | 14 ++ wrapper.c | 12 2 files changed, 26 insertions(+) diff --git a/t/t0021-conversion.sh b/t/t0021-conversion.sh index e50f0f7..b92e6cb 100755 --- a/t/t0021-conversion.sh +++

[PATCH v5 2/2] Revert "compate/clipped-write.c: large write(2) fails on Mac OS X/XNU"

The previous commit introduced a size limit on IO chunks on all platforms. The compat clipped_write() is not needed anymore. This reverts commit 6c642a878688adf46b226903858b53e2d31ac5c3. Signed-off-by: Steffen Prohaska --- Makefile | 8 compat/clipped-write.c | 13

[PATCH v6 0/2] Fix IO >= 2GB on Mac, fixed typo

Fixed typo in comment. Steffen Prohaska (2): xread, xwrite: Limit size of IO, fixing IO of 2GB and more on Mac OS X Revert "compate/clipped-write.c: large write(2) fails on Mac OS X/XNU" Makefile | 8 compat/clipped-write.c | 13 - config

[PATCH v5 0/2] Fix IO of >=2GB on Mac OS X by limiting IO chunks

This is the revised patch taking the considerations about IO chunk size into account. The series deletes more than it adds and fixes a bug. Nice. Steffen Prohaska (2): xread, xwrite: Limit size of IO, fixing IO of 2GB and more on Mac OS X Revert "compate/clipped-write.c: large wr

[PATCH v5 1/2] xread, xwrite: Limit size of IO, fixing IO of 2GB and more on Mac OS X

on Mac OS X/XNU Signed-off-by: Steffen Prohaska --- t/t0021-conversion.sh | 14 ++ wrapper.c | 12 2 files changed, 26 insertions(+) diff --git a/t/t0021-conversion.sh b/t/t0021-conversion.sh index e50f0f7..b92e6cb 100755 --- a/t/t0021-conversion.sh +++

[PATCH v5 2/2] Revert "compate/clipped-write.c: large write(2) fails on Mac OS X/XNU"

The previous commit introduced a size limit on IO chunks on all platforms. The compat clipped_write() is not needed anymore. This reverts commit 6c642a878688adf46b226903858b53e2d31ac5c3. Signed-off-by: Steffen Prohaska --- Makefile | 8 compat/clipped-write.c | 13

Re: [PATCH v4] compat: Fix read() of 2GB and more on Mac OS X

On Aug 19, 2013, at 6:04 PM, Linus Torvalds wrote: > I hate your patch for other reasons, though: > >> The problem for read() is addressed in a similar way by introducing >> a wrapper function in compat that always reads less than 2GB. > > Why do you do that? We already _have_ wrapper functio

[PATCH v4] compat: Fix read() of 2GB and more on Mac OS X

compate/clipped-write.c: large write(2) fails on Mac OS X/XNU Signed-off-by: Steffen Prohaska --- Makefile | 10 +- builtin/var.c| 10 +- compat/{clipped-write.c => clipped-io.c} | 11 ++-

Re: [PATCH v2] compat: Fix read() of 2GB and more on Mac OS X

On Aug 19, 2013, at 10:20 AM, Johannes Sixt wrote: > Am 19.08.2013 08:38, schrieb Steffen Prohaska: >> +test_expect_success EXPENSIVE 'filter large file' ' >> +git config filter.largefile.smudge cat && >> +git config filter.largefile.clean ca

[PATCH v3] compat: Fix read() of 2GB and more on Mac OS X

5c3 compate/clipped-write.c: large write(2) fails on Mac OS X/XNU Signed-off-by: Steffen Prohaska --- Makefile | 8 builtin/var.c | 1 + compat/clipped-read.c | 13 + config.mak.uname | 1 + git-compat-util.h | 5 + streaming.

Re: [PATCH v2] compat: Fix read() of 2GB and more on Mac OS X

On Aug 19, 2013, at 9:54 AM, John Keeping wrote: > You've created compat/clipped-read.c, but... > >> Makefile | 8 >> builtin/var.c | 1 + >> config.mak.uname | 1 + >> git-compat-util.h | 5 + >> streaming.c | 1 + >> t/t0021-conversion.sh |

[PATCH v2] compat: Fix read() of 2GB and more on Mac OS X

5c3 compate/clipped-write.c: large write(2) fails on Mac OS X/XNU Signed-off-by: Steffen Prohaska --- Makefile | 8 builtin/var.c | 1 + config.mak.uname | 1 + git-compat-util.h | 5 + streaming.c | 1 + t/t0021-conversion.sh | 14

[PATCH] xread(): Fix read error when filtering >= 2GB on Mac OS X

acefully handle partial reads. Slicing large reads into 2GB pieces should not hurt practical performance. Signed-off-by: Steffen Prohaska --- t/t0021-conversion.sh | 9 + wrapper.c | 8 2 files changed, 17 insertions(+) diff --git a/t/t0021-conversion.sh b/t/t0021-conv

[PATCH 1/2] shortlog: Fix wrapping lines of wraplen (was broken since recent off-by-one fix)

strbuf_add_wrapped_text() never returned a value of wraplen. [1] 14e1a4e1ff70aff36db3f5d2a8b806efd0134d50 utf8: fix off-by-one wrapping of text Signed-off-by: Steffen Prohaska --- builtin/shortlog.c | 5 ++--- t/t4201-shortlog.sh | 24 2 files changed, 26 insertions(+), 3

[PATCH 0/2] Re: [PATCH] shortlog: Fix wrapping lines of wraplen

On Dec 9, 2012, at 10:36 AM, Junio C Hamano wrote: > Steffen Prohaska writes: > > > A recent commit [1] fixed a off-by-one wrapping error. As > > a side-effect, add_wrapped_shortlog_msg() needs to be changed to always > > append a newline. > > Could you clarify

[PATCH 2/2] strbuf_add_wrapped*(): Remove unused return value

Since shortlog isn't using the return value anymore (see previous commit), the functions can be changed to void. Signed-off-by: Steffen Prohaska --- utf8.c | 13 ++--- utf8.h | 4 ++-- 2 files changed, 8 insertions(+), 9 deletions(-) diff --git a/utf8.c b/utf8.c index 5c61bbe..a4

[PATCH] shortlog: Fix wrapping lines of wraplen (was broken since recent off-by-one fix)

A recent commit [1] fixed a off-by-one wrapping error. As a side-effect, add_wrapped_shortlog_msg() needs to be changed to always append a newline. [1] 14e1a4e1ff70aff36db3f5d2a8b806efd0134d50 utf8: fix off-by-one wrapping of text Signed-off-by: Steffen Prohaska --- builtin/shortlog.c

RE: Who is the 'git' vendor?

Thanks Andreas & Jeff. Your advice is much appreciated. Cheers, Thor -Original Message- From: Jeff King [mailto:p...@peff.net] Sent: Thursday, 25 October 2012 7:10 PM To: PROHASKA, Thor Cc: Andreas Ericsson; 'git@vger.kernel.org'; 'Thor Home (tho...@hotkey.net.au)'

Who is the 'git' vendor?

Freedom Conservancy'. Can you please advise me if this is correct? If not, who should the vendor be identified as? Regards, Thor Thor Prohaska Test Coordinator - Desktop Anywhere Enterprise Engineering BT, 3/300 Queen St, Brisbane Desk Phone: 07 3362 1809 Mobile: 0419 344 806 _

Re: Is anyone working on a next-gen Git protocol?

On Oct 8, 2012, at 6:27 PM, Junio C Hamano wrote: > Once we go into "want/have" phase, I do not think there is a need > for fundamental change in the protocol (by this, I am not counting a > change to send "have"s sparsely and possibly backtracking to bisect > history, etc. as "fundamental"). I'v

Re: [PATCH] git-web--browse: Fix open HTML help pages from iTerm

On Sep 27, 2012, at 9:11 PM, Junio C Hamano wrote: > Steffen Prohaska writes: > >> iTerm is an alternative to the default terminal emulation program on Mac >> OS X. git-web--browse wasn't aware of iTerm and failed to open HTML >> help pages when used in a s

[PATCH] git-web--browse: Fix open HTML help pages from iTerm

off-by: Steffen Prohaska --- git-web--browse.sh | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/git-web--browse.sh b/git-web--browse.sh index 1e82726..95ecf65 100755 --- a/git-web--browse.sh +++ b/git-web--browse.sh @@ -120,7 +120,8 @@ if test -z "$browse