[PATCH v2] utf8.c: fix strbuf_utf8_replace() consuming data beyond input string

The main loop in strbuf_utf8_replace() could summed up as: while ('src' is still valid) { 1) advance 'src' to copy ANSI escape sequences 2) advance 'src' to copy/replace visible characters } The problem is after #1, 'src' may have reached the end of the string (so 'src' points to NUL)

Re: [PATCH] git-gui: make gc warning threshold match 'git gc --auto'

Karsten Blees writes: >The number of loose objects at which git-gui shows a gc warning has >historically been hardcoded to ~2000, or ~200 on Windows. The warning can >only be disabled completely via gui.gcwarning=false. > >Especially on Windows, the hardcoded threshold is so ridiculously low that

Re: [PATCH] git-gui: Make git-gui lib dir configurable at runtime

David Turner writes: >On Mon, 2014-07-21 at 14:06 -0700, Junio C Hamano wrote: >> David Turner writes: >> >> > Introduce the GIT_GUI_LIB_DIR environment variable, to tell git-gui >> > where to look for TCL libs. This allows a git-gui which has been >> > built with a prefix of /foo to be run ou

[PATCH 2/2] clone.c: don't leak memory in cmd_clone

Free the refspec. Found by scan.coverity.com (Id: 1127806) Signed-off-by: Stefan Beller --- builtin/clone.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/builtin/clone.c b/builtin/clone.c index bbd169c..dd4092b 100644 --- a/builtin/clone.c +++ b/builtin/clone.c @@ -1004,5 +1004,7 @@ int

[PATCH 1/2] remote.c: don't leak the base branch name in format_tracking_info

Found by scan.coverity.com (Id: 1127809) Signed-off-by: Stefan Beller --- remote.c | 1 + 1 file changed, 1 insertion(+) diff --git a/remote.c b/remote.c index 3d6c86a..2c1458f 100644 --- a/remote.c +++ b/remote.c @@ -1983,6 +1983,7 @@ int format_tracking_info(struct branch *branch, struct str

[PATCH] Fixing unclear messages

Signed-off-by: Alexander Shopov --- builtin/clean.c | 2 +- builtin/commit.c | 2 +- builtin/index-pack.c | 4 ++-- builtin/log.c| 4 ++-- builtin/merge.c | 5 +++-- builtin/remote.c | 2 +- builtin/tag.c| 2 +- git-bisect.sh| 2 +- merge-recursive.c|

Fixing WTF porcelain messages in Git

Hello everyone, I have just finished the Bulgarian translation of git. Doing this allowed me to identify about 90 places where the original messages can be improved - for consistency, spaces/tabs, abbreviations etc. 12 of these places however are really WTF messages - they do not explain properly

[PATCH] Fixning WTF porcelain messages

Some user-facing porcelain messages in Git are hard to understand and hard to translate. They confuse users winthout providing proper information and course of action. Here is the list of these messages (starting with "-") and my suggestions (starting with "+"). The patch follows in the next letter

Re: [PATCH 1/2] remote.c: don't leak the base branch name in format_tracking_info

On 10.08.2014 15:57, Stefan Beller wrote: > Found by scan.coverity.com (Id: 1127809) > > Signed-off-by: Stefan Beller > --- > remote.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/remote.c b/remote.c > index 3d6c86a..2c1458f 100644 > --- a/remote.c > +++ b/remote.c > @@ -1983,6 +198

Re: Unify subcommand structure; introduce double dashes for all subcommands?

On 23.07.2014 19:52, Junio C Hamano wrote: > Stefan Beller writes: > >> A git command is generally setup as: >> git [] [] ... >> >> The subcommands vary wildly by the nature of the command. However all >> subcommands >> could at least follow one style. The commands bundle, notes, stash and

Re: [PATCH v8 0/8] Rewrite `git_config()` using config-set API

Ramsay Jones writes: > On 08/08/14 15:07, Tanay Abhra wrote: > ... >> (cc to Ramsay) >> >> The discussion in both threads (v8 and v9), boils down to this, >> is the `key_value_info` struct really required to be declared public or >> should be >> just an implementation detail. I will give you th

Re: Unify subcommand structure; introduce double dashes for all subcommands?

Stefan Beller writes: > On 23.07.2014 19:52, Junio C Hamano wrote: > >> Sounds familiar. E.g. here is a similar thread about a year ago. >> >> http://thread.gmane.org/gmane.comp.version-control.git/231376/focus=231478 >> >> Further discussions to make the plan more concrete is very much >> w

Re: [PATCH 1/2] remote.c: don't leak the base branch name in format_tracking_info

On Sun, Aug 10, 2014 at 05:14:33PM +0200, Stefan Beller wrote: > On 10.08.2014 15:57, Stefan Beller wrote: > > Found by scan.coverity.com (Id: 1127809) > > > > Signed-off-by: Stefan Beller > > --- > > remote.c | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/remote.c b/remote.c >

Re: [PATCH] Fixing unclear messages

On Sun, Aug 10, 2014 at 06:13:27PM +0300, Alexander Shopov wrote: > Signed-off-by: Alexander Shopov It would probably make sense to put the discussion from your cover letter into the commit message. > diff --git a/builtin/index-pack.c b/builtin/index-pack.c > index 5568a5b..d9c5911 100644 > ---

[PATCH] remote.c: don't leak the base branch name in format_tracking_info

Found by scan.coverity.com (Id: 1127809) Signed-off-by: Stefan Beller --- remote.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/remote.c b/remote.c index 3d6c86a..894db09 100644 --- a/remote.c +++ b/remote.c @@ -1920,7 +1920,7 @@ int stat_tracking_info(struct branch

Re: [PATCH] Update hard-coded header dependencies

On Fri, Aug 08, 2014 at 02:58:26PM -0700, Jonathan Nieder wrote: > Maybe it's worth switching to plain > > LIB_H += $(wildcard *.h) > > ? People using ancient compilers that never change headers wouldn't > be hurt, people using modern compilers that do change headers also > wouldn't be hu

Re: Unify subcommand structure; introduce double dashes for all subcommands?

On 10.08.2014 20:13, Junio C Hamano wrote: > Stefan Beller writes: > >> On 23.07.2014 19:52, Junio C Hamano wrote: >> >>> Sounds familiar. E.g. here is a similar thread about a year ago. >>> >>> http://thread.gmane.org/gmane.comp.version-control.git/231376/focus=231478 >>> >>> Further discussi

Re: [PATCH] checkpatch: Add test for commit id formatting style in commit log

Hi Joe, On Thu, Jul 3, 2014 at 12:00 AM, Joe Perches wrote: > Commit logs have various forms of commit id references. > > Try to standardize on a 12 character long lower case > commit id along with a description of parentheses and > the quoted subject line > > ie: commit 0123456789ab ("commit des

Re: [PATCH] checkpatch: Add test for commit id formatting style in commit log

On Sun, 10 Aug 2014 14:28:01 -0700 Joe Perches wrote: > > On Thu, Jul 3, 2014 at 12:00 AM, Joe Perches wrote: > > > Commit logs have various forms of commit id references. > > > > > > Try to standardize on a 12 character long lower case > > > commit id along with a description of parentheses and

[PATCH 1/2] blame.c: Add translation to warning about failed revision walk

blame belonging to the group of ancillaryinterrogators and not to plumbinginterrogators should have localized error messages? Signed-off-by: Stefan Beller --- builtin/blame.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/builtin/blame.c b/builtin/blame.c index 17d30d0..ca4b

[PATCH 2/2] prepare_revision_walk: Check for return value in all places

Even the documentation tells us: You should check if it returns any error (non-zero return code) and if it does not, you can start using get_revision() to do the iteration. In preparation for this commit, I grepped all occurrences of prepare_revision_walk and added error me

Re: [PATCH] checkpatch: Add test for commit id formatting style in commit log

On Sun, 2014-08-10 at 23:08 +0200, Geert Uytterhoeven wrote: > Hi Joe, Hi Geert. > On Thu, Jul 3, 2014 at 12:00 AM, Joe Perches wrote: > > Commit logs have various forms of commit id references. > > > > Try to standardize on a 12 character long lower case > > commit id along with a description o

Re: [PATCH] checkpatch: Add test for commit id formatting style in commit log

On Sun, 2014-08-10 at 14:35 -0700, Andrew Morton wrote: > On Sun, 10 Aug 2014 14:28:01 -0700 Joe Perches wrote: > > > On Thu, Jul 3, 2014 at 12:00 AM, Joe Perches wrote: > > > > Commit logs have various forms of commit id references. > > > > > > > > Try to standardize on a 12 character long lower

Re: Tackling Git Limitations with Singular Large Line-seperated Plaintext files

On 30 June 2014 14:56, Jakub Narębski wrote: > Linus Torvalds wrote: > > .. even there, there's another issue. With enough memory, the diff > > itself should be fairly reasonable to do, but we do not have any > > sane *format* for diffing those kinds of things. > > > > The regular textual diff is

Re: [PATCH 1/2] remote.c: don't leak the base branch name in format_tracking_info

Stefan Beller writes: > On 10.08.2014 15:57, Stefan Beller wrote: >> Found by scan.coverity.com (Id: 1127809) >> >> Signed-off-by: Stefan Beller >> --- >> remote.c | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/remote.c b/remote.c >> index 3d6c86a..2c1458f 100644 >> --- a/remote.

Re: [PATCH] Update hard-coded header dependencies

Jonathan Nieder writes: > The fall-back rules used when compilers don't support the -MMD switch > to generate makefile rules based on #includes have been out of date > since v1.7.12.1~22^2~8 (move git_version_string into version.c, > 2012-06-02). > > Checked with 'make CHECK_HEADER_DEPENDENCIES=y

Re: [PATCH] Update hard-coded header dependencies

Junio C Hamano writes: > Jonathan Nieder writes: > >> ? People using ancient compilers that never change headers wouldn't >> be hurt, people using modern compilers that do change headers also >> wouldn't be hurt, and we could stop pretending to maintain an >> up-to-date list. > > I agree that i

Re: [PATCH] Fixing unclear messages

Alexander Shopov writes: > diff --git a/builtin/clean.c b/builtin/clean.c > index 1032563..9f38068 100644 > --- a/builtin/clean.c > +++ b/builtin/clean.c > @@ -514,7 +514,7 @@ static int parse_choice(struct menu_stuff *menu_stuff, > if (top <= 0 || bottom <= 0 || top > menu_stuff->n

Sharing merge conflict resolution between multiple developers

Hi List, At $dayjob we maintain internal forks of the a number of upstream repositories. Unsurprisingly updating these forks can be extremely problematic, especially when it's only one person doing the merge. Fortunately most of us are in the same physical location so it is possible to drag in so