[PATCH 3/5] git-rebase--interactive: fix English grammar

Signed-off-by: Alex Henrie --- git-rebase--interactive.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh index 7e558b0..6fd6d4e 100644 --- a/git-rebase--interactive.sh +++

[PATCH 5/5] unpack-trees: do not capitalize "working"

In English, only proper nouns are capitalized. Signed-off-by: Alex Henrie --- unpack-trees.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/unpack-trees.c b/unpack-trees.c index 11c37fb..c87a90a 100644 --- a/unpack-trees.c +++ b/unpack-trees.c @@

[PATCH 4/5] git-merge-octopus: do not capitalize "octopus"

In English, only proper nouns are capitalized. Signed-off-by: Alex Henrie --- git-merge-octopus.sh | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/git-merge-octopus.sh b/git-merge-octopus.sh index 308eafd..bcf0d92 100755 --- a/git-merge-octopus.sh

[PATCH 2/5] cat-file: put spaces around pipes in usage string

This makes the style a little more consistent with other usage strings, and will resolve a warning at https://www.softcatala.org/recursos/quality/git.html Signed-off-by: Alex Henrie --- builtin/cat-file.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH 1/5] am: put spaces around pipe in usage string

This makes the style a little more consistent with other usage strings, and will resolve a warning at https://www.softcatala.org/recursos/quality/git.html Signed-off-by: Alex Henrie --- builtin/am.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

Re: [PATCH] connect: tighten check for unexpected early hang up (Re: [PATCH v3 2/2] connect: advertized capability is not a ref)

Jonathan Nieder wrote: > Subject: connect: tighten check for unexpected early hang up [...] > @@ -131,7 +131,7 @@ struct ref **get_remote_heads(int in, char *src_buf, > size_t src_len, > PACKET_READ_GENTLE_ON_EOF | >

Re: [PATCH] connect: tighten check for unexpected early hang up (Re: [PATCH v3 2/2] connect: advertized capability is not a ref)

Jonathan Nieder wrote: > Change-Id: I3cec2c160eb6c6f3efdce7dab38a4c78592f6c7f Gah --- sorry about that. Please remove this line if applying (or I'll be happy to resend without it after review). Jonathan

[PATCH] connect: tighten check for unexpected early hang up (Re: [PATCH v3 2/2] connect: advertized capability is not a ref)

(+cc: Heiko) Jonathan Nieder wrote: > 'die_initial_contact' uses got_at_least_one_head to determine whether > it was on the first line but code paths added later that use > 'continue' don't populate it properly (see b06dcd7d, 40c155ff, and > 1a7141ff). We could do > > int first_line = 1; >

Re: [PATCH v3 2/2] connect: advertized capability is not a ref

Jonathan Tan wrote: > Git advertises the same capabilities^{} ref in its ref advertisement for push > but since it never remembered to do so for fetch, the client forgot to handle > this case. Handle it. The comment in the previous review was that this doesn't describe the history correctly. It

Re: "fatal error in commit_refs" from pushing to github

On Thu, Sep 08, 2016 at 07:49:12AM +0700, Duy Nguyen wrote: > I got the message in the subject when pushing to github today. Yes I > know it's github, not git. But according to stackoveflow [1] it's a > local problem. Which makes me think, if we know exactly what this is > (or at least roughly

[PATCH] Move format-patch base commit and prerequisites before email signature

Any text below the "-- " for the email signature gets treated as part of the signature, and many mail clients will trim it from the quoted text for a reply. Move it above the signature, so people can reply to it more easily. Add tests for the exact format of the email signature, and add tests to

Re: [PATCH 2/3] diff_flush_patch_id: stop returning error result

On 07/09/16 23:04, Jeff King wrote: > All of our errors come from diff_get_patch_id(), which has > exactly three error conditions. The first is an internal > assertion, which should be a die("BUG") in the first place. > > The other two are caused by an inability to two diff blobs,

"fatal error in commit_refs" from pushing to github

I got the message in the subject when pushing to github today. Yes I know it's github, not git. But according to stackoveflow [1] it's a local problem. Which makes me think, if we know exactly what this is (or at least roughly the problem area), maybe we could improve git to catch it locally in

[PATCH v3 1/2] tests: move test_lazy_prereq JGIT to test-lib.sh

This enables JGIT to be used as a prereq in invocations of test_expect_success (and other functions) in other test scripts. Signed-off-by: Jonathan Tan --- t/t5310-pack-bitmaps.sh | 4 t/test-lib.sh | 4 2 files changed, 4 insertions(+), 4

[PATCH v3 2/2] connect: advertized capability is not a ref

When cloning an empty repository served by standard git, "git clone" produces the following reassuring message: $ git clone git://localhost/tmp/empty Cloning into 'empty'... warning: You appear to have cloned an empty repository. Checking connectivity... done.

[PATCH v3 0/2] handle empty spec-compliant remote repos correctly

Updated, taking into account review comments. This patch set uses warnings (instead of errors using "die") to indicate protocol errors that we can recover from. There is a discussion on a sibling thread about whether such protocol errors should be errors ("die") instead - I can change it if

[PATCH 1/2] diff: omit found pointer from emit_callback

We keep the actual data in the diff options, which are just as accessible. Remove the pointer stored in struct emit_callback for readability. Signed-off-by: Stefan Beller --- diff.c | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/diff.c b/diff.c index

[PATCH 2/2] diff: remove dead code

When `len < 1`, len has to be 0 or negative, emit_line will then remove the first character and by then `len` would be negative. As this doesn't happen, it is safe to assume it is dead code. This continues to simplify the code, which was started in b8d9c1a66b (2009-09-03, diff.c: the

[PATCH 3/3] diff: remove dead code

When `len < 1`, len has to be 0 or negative, emit_line will then remove the first character and by then `len` would be negative. As this doesn't happen, it is safe to assume it is dead code. This continues to simplify the code, which was started in b8d9c1a66b (2009-09-03, diff.c: the

[PATCH 2/3] diff: omit found pointer from emit_callback

We keep the actual data in the diff options, which are just as accessible. Remove the pointer stored in struct emit_callback for readability. Signed-off-by: Stefan Beller --- diff.c | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/diff.c b/diff.c index

[PATCH 1/3] diff.c: use diff_options directly

The value of `ecbdata->opt` is accessible via the short variable `o` already, so let's use that instead. Signed-off-by: Stefan Beller --- diff.c | 21 ++--- 1 file changed, 10 insertions(+), 11 deletions(-) diff --git a/diff.c b/diff.c index 534c12e..4a6501c

[PATCH 0/3] preparatory diff improvements for moved color detection

Motivated by the feedback on the "[PATCHv4] diff.c: emit moved lines with a different color"[1], I started refactoring the fn_out_consume function in diff.c. This lead to a huge amount of tiny patches so far, but nothing to present as an end result. These patches are preparatory for this effort

Re: [PATCH v3 0/8] Better heuristics make prettier diffs

Michael Haggerty writes: > * Add test t4059 as part of this commit, not as part of its > successor. Which needs to be moved to somewhere else, as another topics that has already been in 'next' uses t4059. I'd move it temporarily to t4061 with a separate SQUASH??? at

Re: [PATCH v2 00/20] object_id part 5

"brian m. carlson" writes: > On Wed, Sep 07, 2016 at 01:12:09PM -0700, Junio C Hamano wrote: >> It is a bit unfortunate that this conflicts somewhat in builtin/cat-file.c >> and heavily with builtin/apply.c with other topics in flight. >> >> Let me see how bad the

Re: [PATCH v2 2/2] connect: advertized capability is not a ref

Jonathan Nieder writes: > Given that there aren't any servers that are going to produce this > kind of bad input anyway, I prefer a die(). That would certainly put bigger pressure on the folks who write buggy stuff in the future. If we know that nobody produces such output,

Re: [RFC/PATCH v2 0/3] patch-id for merges

On Wed, Sep 07, 2016 at 06:01:01PM -0400, Jeff King wrote: > Here's a re-roll of the series I posted at: > > > http://public-inbox.org/git/20160907075346.z6wtmqnfc6bsu...@sigill.intra.peff.net/ > > Basically, it drops the time for "format-patch --cherry-pick" on a > particular case from 3

Re: [PATCH 3/3] patch-ids: use commit sha1 as patch-id for merge commits

On Wed, Sep 07, 2016 at 03:28:10PM -0700, Jacob Keller wrote: > On Wed, Sep 7, 2016 at 3:04 PM, Jeff King wrote: > > The patch-ids code which powers "log --cherry-pick" doesn't > > look at whether each commit is a merge or not. It just feeds > > the commit's first parent to the

Re: [PATCH 3/3] patch-ids: use commit sha1 as patch-id for merge commits

On Wed, Sep 7, 2016 at 3:04 PM, Jeff King wrote: > The patch-ids code which powers "log --cherry-pick" doesn't > look at whether each commit is a merge or not. It just feeds > the commit's first parent to the diff, and ignores any > additional parents. > The subject here is

Re: [PATCH v2 00/20] object_id part 5

On Wed, Sep 07, 2016 at 01:12:09PM -0700, Junio C Hamano wrote: > It is a bit unfortunate that this conflicts somewhat in builtin/cat-file.c > and heavily with builtin/apply.c with other topics in flight. > > Let me see how bad the conflict resolution is and report back later. If it ends up

Re: [PATCH 2/2] patch-ids: skip merge commits

On Wed, Sep 07, 2016 at 02:46:53PM -0400, Jeff King wrote: > > With this change, commit_patch_id() will return 0 for merge commits > > (indicating success) but it will not have touched the sha1! Which means it > > may very well have all kinds of crap in the sha1 that may, or may not, > > match

Re: [PATCH 1/3] patch-ids: turn off rename detection

On Wed, Sep 7, 2016 at 3:02 PM, Jeff King wrote: > The patch-id code may be running inside another porcelain > like "git log" or "git format-patch", and therefore may have > set diff_detect_rename_default, either via the diff-ui > config, or by default since 5404c11 (diff: activate

[PATCH 3/3] patch-ids: use commit sha1 as patch-id for merge commits

The patch-ids code which powers "log --cherry-pick" doesn't look at whether each commit is a merge or not. It just feeds the commit's first parent to the diff, and ignores any additional parents. In theory, this might be useful if you wanted to find equivalence between, say, a merge commit and a

[PATCH 2/3] diff_flush_patch_id: stop returning error result

All of our errors come from diff_get_patch_id(), which has exactly three error conditions. The first is an internal assertion, which should be a die("BUG") in the first place. The other two are caused by an inability to two diff blobs, which is an indication of a serious problem (probably

[PATCH 1/3] patch-ids: turn off rename detection

The patch-id code may be running inside another porcelain like "git log" or "git format-patch", and therefore may have set diff_detect_rename_default, either via the diff-ui config, or by default since 5404c11 (diff: activate diff.renames by default, 2016-02-25). This is the case even if a command

[RFC/PATCH v2 0/3] patch-id for merges

Here's a re-roll of the series I posted at: http://public-inbox.org/git/20160907075346.z6wtmqnfc6bsu...@sigill.intra.peff.net/ Basically, it drops the time for "format-patch --cherry-pick" on a particular case from 3 minutes down to 3 seconds, by avoiding diffs on merge commits. Compared to

Re: [PATCH v3 0/8] Better heuristics make prettier diffs

On Wed, Sep 7, 2016 at 11:11 AM, Junio C Hamano wrote: > Michael Haggerty writes: > >> * In "blame: honor the diff heuristic options and config": >> >> * In v2, I suggested making `blame` honor all diff-related options. >> Junio explained why this

Re: [PATCHv3] diff.c: emit moved lines with a different color

On Wed, Sep 7, 2016 at 11:02 AM, Stefan Beller wrote: > On Wed, Sep 7, 2016 at 10:54 AM, Junio C Hamano wrote: >> Stefan Beller writes: >> >>> as we do not want to see dashes ('moved-old'), I think I'l go with >>> "movedfrom" and

Re: [PATCH v2 2/2] connect: advertized capability is not a ref

Junio C Hamano wrote: > Jonathan Tan writes: >> diff --git a/connect.c b/connect.c >> index 722dc3f..0c2221e 100644 >> --- a/connect.c >> +++ b/connect.c >> @@ -165,6 +165,9 @@ struct ref **get_remote_heads(int in, char *src_buf, >> size_t src_len, >>

Re: [PATCH v2 00/20] object_id part 5

"brian m. carlson" writes: > This is the fifth in a series of series to convert from unsigned char [20] to > struct object_id. > > This series converts many of the files in the builtin directory to use struct > object_id. This gets us almost to the point where we

Re: segfault in http.c when https URL is mistyped

On Wed, Sep 07, 2016 at 04:06:42PM -0400, Jeff King wrote: > +test_expect_success 'remote-http complains cleanly about malformed urls' ' > + # do not actually issue "list" or other commands, as we do not > + # want to rely on what curl would actually do with such a broken > + # URL.

Re: segfault in http.c when https URL is mistyped

On Wed, Sep 07, 2016 at 03:44:04PM +0200, Lars Wendler wrote: > we at Gentoo got a bug report [1] about git-remote-https segfaulting > when the URL has been mistyped. > This seems to only be triggered when git was compiled with curl > support: > > git clone

Re: [PATCH] t6026-merge-attr: wait for process to release trash directory

Jeff King writes: > I agree that the sleep could be made longer, to make the test less racy. > However, the racy failure mode is that it might pass while testing > nothing (i.e., the sleep ends anyway before the hook returns), so I > don't think it's a high priority. I do not

Re: [PATCH 3/4] t5550-http-fetch-dumb.sh: use the GIT_TRACE_CURL environment var

Junio C Hamano writes: > Elia Pinto writes: > + cp expect expect.$$ && + cp actual actual.$$ && + cp output output.$$ && >>> >>> What are these three cp's about? They don't seem to be related to the >>> stated changes.

Re: [PATCH v14 00/41] libify apply and use lib in am, part 2

Christian Couder writes: > In patch 29/41 I added some comments in apply.h above the definition > of APPLY_OPT_INACCURATE_EOF and APPLY_OPT_RECOUNT, as suggested by > Stefan. This is the only change compared to v13. OK. > - Patches 33/41 to 37/41 were in v10, v12

Re: [PATCH 5/5] pack-objects: walk tag chains for --include-tag

On Wed, Sep 07, 2016 at 11:49:28AM -0700, Junio C Hamano wrote: > Jeff King writes: > > > As explained further in the commit message, "fetch" is robust to this, > > because it does a real connectivity check and follow-on fetch before > > writing anything it thinks it got via

Re: [PATCH v2 00/38] Virtualization of the refs API

Michael Haggerty writes: > This is v2 of the patch series to virtualize the references API > (though earlier patch series similar in spirit were submitted by > Ronnie Sahlberg and David Turner). Thanks to Junio, Eric, and Ramsay > for their comments about v1 [1]. > > Nobody

Re: [PATCH] t6026-merge-attr: wait for process to release trash directory

On Wed, Sep 07, 2016 at 11:39:57AM -0700, Junio C Hamano wrote: > > Can we do some signaling with fifos to tell the hook when it is safe to > > exit? Then we would just need to `wait` for its parent process. > > Is fifo safe on Windows, though? No clue. We seem to use mkfifo unconditionally in

Re: [PATCH v2] rebase -i: improve advice on bad instruction lines

Dennis Kaarsemaker writes: > There are quite a few patch series in flight these days around > interactive rebase. Have you checked for conflicts with those? IIRC, Ralf's fix would need to be ported to C version, and when it happens, it won't just be a mere conflict but

Re: [PATCHv4] diff.c: emit moved lines with a different color

Ramsay Jones writes: >> +static int diff_line_moved_entry_cmp(const struct diff_line_moved_entry *a, >> + const struct diff_line_moved_entry *b, >> + const void *unused) >> +{ >> +return

Re: [RFC/PATCH 0/2] more patch-id speedups

On Wed, Sep 07, 2016 at 03:06:36PM +0200, Johannes Schindelin wrote: > > This is marked as "RFC" because I don't feel entirely confident that I'm > > not missing some clever need for these options. But in both cases my gut > > feeling is that they are simply unintended effects that nobody ever >

Re: [PATCH 5/5] pack-objects: walk tag chains for --include-tag

Jeff King writes: > As explained further in the commit message, "fetch" is robust to this, > because it does a real connectivity check and follow-on fetch before > writing anything it thinks it got via include-tag. So perhaps one could > argue that pack-objects is correct;

Re: [PATCH 2/2] patch-ids: skip merge commits

On Wed, Sep 07, 2016 at 02:52:04PM +0200, Johannes Schindelin wrote: > > diff --git a/patch-ids.c b/patch-ids.c > > index 77e4663..b1f8514 100644 > > --- a/patch-ids.c > > +++ b/patch-ids.c > > @@ -7,10 +7,12 @@ > > int commit_patch_id(struct commit *commit, struct diff_options *options, > >

Re: [PATCH] t6026-merge-attr: wait for process to release trash directory

Jeff King writes: > On Mon, Sep 05, 2016 at 09:03:48PM +0200, Johannes Sixt wrote: > >> The process spawned in the hook uses the test's trash directory as CWD. >> As long as it is alive, the directory cannot be removed on Windows. >> Although the test succeeds, the 'test_done'

Re: [PATCH] t9903: fix broken && chain

Johannes Sixt writes: > We might wonder why our && chain check does not catch this case: > The && chain check uses a strange exit code with the expectation that > the second or later part of a broken && chain would not exit with this > particular code. > > This expectation does

Re: [PATCH 2/3] diff_populate_filespec: NUL-terminate buffers

Jeff King writes: > What happens to those poor souls on systems without REG_STARTEND? Do > they get to keep segfaulting? > > I think the solution is to push them into setting NO_REGEX. So looking > at this versus a "regexecn", it seems: > > - this lets people keep using their

Re: [PATCH 3/4] t5550-http-fetch-dumb.sh: use the GIT_TRACE_CURL environment var

Elia Pinto writes: >>> + cp expect expect.$$ && >>> + cp actual actual.$$ && >>> + cp output output.$$ && >> >> What are these three cp's about? They don't seem to be related to the >> stated changes. Are they leftover debugging gunk? > Yes, i am very

Re: [PATCH v1 2/2] read-cache: make sure file handles are not inherited by child processes

Eric Wong writes: > We probably should be using O_NOATIME for all O_RDONLY cases > to get the last bit of performance out (especially since > non-modern-Linux systems probably still lack relatime). No, please do not go there. The user can read from a file in a working tree

Re: [PATCH v1 1/2] sha1_file: open window into packfiles with CLOEXEC

Lars Schneider wrote: > > On 06 Sep 2016, at 13:38, Johannes Schindelin > > wrote: > > On Mon, 5 Sep 2016, Eric Wong wrote: > >> larsxschnei...@gmail.com wrote: > >>> -int git_open_noatime(const char *name) > >>> +int

Re: [PATCH v3 0/8] Better heuristics make prettier diffs

Michael Haggerty writes: > * In "blame: honor the diff heuristic options and config": > > * In v2, I suggested making `blame` honor all diff-related options. > Junio explained why this was a bad idea. So this version only > makes `blame` honor `--indent-heuristic`

Re: [PATCH v1 2/2] read-cache: make sure file handles are not inherited by child processes

Lars Schneider wrote: > > On 06 Sep 2016, at 23:06, Eric Wong wrote: > > larsxschnei...@gmail.com wrote: > >> static int ce_compare_data(const struct cache_entry *ce, struct stat *st) > >> { > >>int match = -1; > >> - int fd = open(ce->name,

Re: [PATCHv3] diff.c: emit moved lines with a different color

On Wed, Sep 7, 2016 at 10:54 AM, Junio C Hamano wrote: > Stefan Beller writes: > >> as we do not want to see dashes ('moved-old'), I think I'l go with >> "movedfrom" and "movedto". > > OK. They would be color.diff.movedFrom and color.diff.movedTo in > the

Re: [PATCH v2 7/7] blame: actually use the diff opts parsed from the command line

Michael Haggerty writes: > The reason that I would prefer to change `blame` as part of this patch > series is that I think it would be disconcerting for `git diff` and `git > blame` to use different heuristics when computing diffs. It would make > their output inconsistent.

Re: [PATCHv3] diff.c: emit moved lines with a different color

Stefan Beller writes: > as we do not want to see dashes ('moved-old'), I think I'l go with > "movedfrom" and "movedto". OK. They would be color.diff.movedFrom and color.diff.movedTo in the doc, and "movedfrom" and "movedto" in the code (as the caller already downcased them

Re: [PATCH] stash: allow ref of a stash by index

Øystein Walle writes: > diff --git a/git-stash.sh b/git-stash.sh > index 826af18..b026288 100755 > --- a/git-stash.sh > +++ b/git-stash.sh > @@ -384,7 +384,7 @@ parse_flags_and_rev() > i_tree= > u_tree= > > -REV=$(git rev-parse --no-flags --symbolic --sq "$@") ||

Re: [PATCH] compat: move strdup(3) replacement to its own file

René Scharfe writes: > Well, OK. I think the missing point is that the original nedmalloc > doesn't come with strdup() and doesn't need it. Only _users_ of > nedmalloc need it. Marius added it in nedmalloc.c, but strdup.c is a > better place for it. Thanks. I'll add these

Re: [PATCH v2 6/6] git-gui: Update Japanese information

"Satoshi Yasushima" writes: > There seems to be a cause in the following taboo. > Sure, PATCH 3/6 is little too great. > http://vger.kernel.org/majordomo-info.html#taboo > >Taboo things to be done when discussing at VGER lists > : (abbr.) > > * Message size exceeding

Re: [PATCH v2 2/2] connect: advertized capability is not a ref

Jonathan Tan writes: > diff --git a/connect.c b/connect.c > index 722dc3f..0c2221e 100644 > --- a/connect.c > +++ b/connect.c > @@ -165,6 +165,9 @@ struct ref **get_remote_heads(int in, char *src_buf, > size_t src_len, > continue; >

Re: [PATCH v2] rebase -i: improve advice on bad instruction lines

2016-09-07 11:28 GMT+02:00 Dennis Kaarsemaker : > Hi Ralf, > > There are quite a few patch series in flight these days around > interactive rebase. Have you checked for conflicts with those? > Thanks. I did not check against 'pu' when I created this patch but I'm able to

Re: [PATCH v2 2/2] connect: advertized capability is not a ref

Jonathan Tan writes: > Git advertises the same capabilities^{} ref in its ref advertisement for push > but since it never remembered to do so for fetch, the client forgot to handle > this case. Handle it. > ... > In this aspect, JGit is compliant with the specification

Re: Bug? ran into a "fatal" using interactive rebase

2016-09-07 17:19 GMT+02:00 Johannes Schindelin : > > So, something like this should help (if you are interested in seeing this > patch included, please run with it, as I am running short on time): > > -- snipsnap -- > diff --git a/wt-status.c b/wt-status.c > index

Re: format-patch base-commit: moving to above the patch?

On Wed, Sep 07, 2016 at 09:06:31AM -0700, Junio C Hamano wrote: > Josh Triplett writes: > > > Currently, format-patch puts base-commit and prerequisite-patch-id > > information below the patch, and below the email signature. Most mail > > clients automatically trim

Re: [PATCH v2 1/2] tests: move test_lazy_prereq JGIT to test-lib.sh

Jonathan Tan writes: > This enables JGIT to be used as a prereq in invocations of > test_expect_success (and other functions) in other test scripts. > > Signed-off-by: Jonathan Tan > --- > t/t5310-pack-bitmaps.sh | 4 > t/test-lib.sh

Re: [PATCH] xdiff: remove unneeded declarations

Stefan Beller writes: > Signed-off-by: Stefan Beller > --- > xdiff/xemit.c | 9 - > 1 file changed, 9 deletions(-) > > diff --git a/xdiff/xemit.c b/xdiff/xemit.c > index 49aa16f..b52b4b9 100644 > --- a/xdiff/xemit.c > +++ b/xdiff/xemit.c > @@

Re: A note from the maintainer

Jakub Narębski writes: > W dniu 03.09.2016 o 04:17, Junio C Hamano pisze: > >> Please remember to always state >> >> - what you wanted to achieve; >> >> - what you did (the version of git and the command sequence to reproduce >>the behavior); > > I wonder if it be worth

Re: format-patch base-commit: moving to above the patch?

Josh Triplett writes: > Currently, format-patch puts base-commit and prerequisite-patch-id > information below the patch, and below the email signature. Most mail > clients automatically trim everything below the signature marker as > unimportant when quoting a mail for a

Re: [PATCH 5/5] versioncmp: cope with common leading parts in versionsort.prereleaseSuffix

Quoting SZEDER Gábor : Version sort with prerelease reordering sometimes puts tagnames in the wrong order, when the common part of two compared tagnames ends with the leading character(s) of one or more configured prerelease suffixes. $ git config --get-all

[PATCH 3/5] t7004-tag: add version sort tests to show prerelease reordering issues

Version sort with prerelease reordering sometimes puts tagnames in the wrong order, when the common part of two compared tagnames ends with the leading character(s) of one or more configured prerelease suffixes. Add tests that demonstrate these issues. The unrelated '--format should list tags as

Re: Bug? ran into a "fatal" using interactive rebase

Hi Ralf, On Tue, 6 Sep 2016, Ralf Thielow wrote: > today I accidentally triggered a "fatal" using interactive rebase. > > If you edit the instruction sheet after 'rebase -i' and add an unknown > command, Git stops because it doesn't know the command. > That's fine, however, now we are in a

[PATCH 5/5] versioncmp: cope with common leading parts in versionsort.prereleaseSuffix

Version sort with prerelease reordering sometimes puts tagnames in the wrong order, when the common part of two compared tagnames ends with the leading character(s) of one or more configured prerelease suffixes. $ git config --get-all versionsort.prereleaseSuffix -beta $ git tag -l

[PATCH 4/5] versioncmp: pass full tagnames to swap_prereleases()

The swap_prereleases() helper function is responsible for finding configured prerelease suffixes in a pair of tagnames to be compared, but this function currently only gets to see only the parts of those two tagnames starting at the first different character. To fix some issues related to

[PATCH 2/5] t7004-tag: use test_config helper

... instead of setting and then manually unsetting configuration variables, on one occasion even outside the test_expect_success block. Signed-off-by: SZEDER Gábor --- t/t7004-tag.sh | 23 ++- 1 file changed, 10 insertions(+), 13 deletions(-) diff --git

[PATCH 1/5] t7004-tag: delete unnecessary tags with test_when_finished

The '--force is moot with a non-existing tag name' test creates two new tags, which are then deleted right after the test is finished, outside the test_expect_success block, allowing 'git tag -d's output to pollute the test output. Use test_when_finished to delete those tags. Signed-off-by:

[PATCH 0/5] Fix version sort prerelease reordering bug

(Sorry for double post, forgot to Cc: the mailing list...) This series fixes a bug, where version sort with prerelease reordering puts tagnames in the wrong order, when the common part of two compared tagnames ends with the leading character(s) of one or more configured prerelease suffixes. More

[PATCH 12/13] i18n: show-branch: mark error messages for translation

Lowercase some messages first word to match style of the others. Signed-off-by: Vasco Almeida --- builtin/show-branch.c | 18 +- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/builtin/show-branch.c b/builtin/show-branch.c index

[PATCH 11/13] i18n: receive-pack: mark messages for translation

Mark messages refuse_unconfigured_deny_msg and refuse_unconfigured_deny_delete_current_msg for translation. Signed-off-by: Vasco Almeida --- builtin/receive-pack.c | 58 ++ 1 file changed, 25 insertions(+), 33 deletions(-)

[PATCH 10/13] notes: lowercase first word of error messages

Follow the usual case style. Update one test to reflect these changes. Signed-off-by: Vasco Almeida --- builtin/notes.c | 64 t/t3320-notes-merge-worktrees.sh | 2 +- 2 files changed, 33 insertions(+), 33

[PATCH 08/13] i18n: merge-recursive: mark verbose message for translation

Signed-off-by: Vasco Almeida --- builtin/merge-recursive.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/builtin/merge-recursive.c b/builtin/merge-recursive.c index 0bc88a7..1c21802 100644 --- a/builtin/merge-recursive.c +++

[PATCH 07/13] i18n: merge-recursive: mark error messages for translation

Lowercase first word of such error messages following the usual style. Signed-off-by: Vasco Almeida --- builtin/merge-recursive.c | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/builtin/merge-recursive.c b/builtin/merge-recursive.c index

[PATCH 06/13] i18n: config: mark error message for translation

Signed-off-by: Vasco Almeida --- builtin/config.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/builtin/config.c b/builtin/config.c index 6cbf733..05843a0 100644 --- a/builtin/config.c +++ b/builtin/config.c @@ -622,8 +622,8 @@ int cmd_config(int

[PATCH 09/13] i18n: notes: mark error messages for translation

Signed-off-by: Vasco Almeida --- builtin/notes.c | 18 +- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/builtin/notes.c b/builtin/notes.c index f848b89..abacae2 100644 --- a/builtin/notes.c +++ b/builtin/notes.c @@ -340,7 +340,7 @@ static

[PATCH 05/13] i18n: branch: mark option description for translation

Signed-off-by: Vasco Almeida --- builtin/branch.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/builtin/branch.c b/builtin/branch.c index 7df0543..d5d93a8 100644 --- a/builtin/branch.c +++ b/builtin/branch.c @@ -657,7 +657,7 @@ int cmd_branch(int

[PATCH 04/13] i18n: blame: mark error messages for translation

Mark error messages for translation passed to die() function. Change "Cannot" to lowercase following the usual style. Reflect changes to test by using test_i18ngrep. Signed-off-by: Vasco Almeida --- builtin/blame.c | 12 ++--

[PATCH 13/13] i18n: update-index: mark warnings for translation

Signed-off-by: Vasco Almeida --- builtin/update-index.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/builtin/update-index.c b/builtin/update-index.c index ba04b19..7a17ce1 100644 --- a/builtin/update-index.c +++ b/builtin/update-index.c

[PATCH 13/13] i18n: update-index: mark warning for translation

Signed-off-by: Vasco Almeida --- builtin/update-index.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/builtin/update-index.c b/builtin/update-index.c index ba04b19..7a17ce1 100644 --- a/builtin/update-index.c +++ b/builtin/update-index.c

[PATCH 03/13] i18n: apply: mark info messages for translation

Mark messages for translation printed to stderr. Signed-off-by: Vasco Almeida --- builtin/apply.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/builtin/apply.c b/builtin/apply.c index ef2c084..43ab7c5 100644 --- a/builtin/apply.c +++

[PATCH 01/13] i18n: apply: mark plural string for translation

Mark plural string for translation using Q_(). Signed-off-by: Vasco Almeida --- builtin/apply.c | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/builtin/apply.c b/builtin/apply.c index 1a488f9..ef03c74 100644 --- a/builtin/apply.c +++

[PATCH 02/13] i18n: apply: mark error messages for translation

Mark error messages for translation passed to error() and die() functions. Signed-off-by: Vasco Almeida --- builtin/apply.c | 46 +++--- 1 file changed, 23 insertions(+), 23 deletions(-) diff --git a/builtin/apply.c

segfault in http.c when https URL is mistyped

Hi, we at Gentoo got a bug report [1] about git-remote-https segfaulting when the URL has been mistyped. This seems to only be triggered when git was compiled with curl support: git clone https::/some.example-site.net/test.git Observe the "https::/" instead of "https://;. As soon as you run

Re: [PATCH v1 2/2] read-cache: make sure file handles are not inherited by child processes

> On 06 Sep 2016, at 23:06, Eric Wong wrote: > > larsxschnei...@gmail.com wrote: >> static int ce_compare_data(const struct cache_entry *ce, struct stat *st) >> { >> int match = -1; >> -int fd = open(ce->name, O_RDONLY); >> +int fd = open(ce->name, O_RDONLY |

Re: [PATCH v1 1/2] sha1_file: open window into packfiles with CLOEXEC

> On 06 Sep 2016, at 13:38, Johannes Schindelin > wrote: > > Hi Eric & Lars, > > On Mon, 5 Sep 2016, Eric Wong wrote: > >> larsxschnei...@gmail.com wrote: >>> All processes that the Git main process spawns inherit the open file >>> descriptors of the main process.

  1   2   >