PENDING FUNDS RELEASED.SEE ATTACHMENT

PENDING FUNDS RELEASED.rtf Description: Binary data

Re: Un-paged commit messages in git filter-branch's commit-filter?

Jeff King wrote: > I don't recall offhand whether git-svn does line-wrapping or any other > commit-message munging. Definitely no line-wrapping. Munging is minimal: it respects i18n.commitencoding, adds a trailing newline, and "git-svn-id:" line. -- To unsubscribe from this list:

Re: [PATCH 1/1 v2] pager: move pager-specific setup into the build

Eric Wong writes: > From: Junio C Hamano > > Allowing PAGER_ENV to be set at build-time allows us to move > pager-specific knowledge out of our build. Currently, this > allows us to set a better default for FreeBSD where more(1) > is the same binary as

Re: [PATCH 1/1 v2] pager: move pager-specific setup into the build

Junio C Hamano wrote: > Eric Wong writes: > > Allowing PAGER_ENV to be set at build-time allows us to move > > pager-specific knowledge out of our build. Currently, this > > allows us to set a better default for FreeBSD where more(1) > > is the same binary as

Re: [PATCH 1/1 v2] pager: move pager-specific setup into the build

On Mon, Aug 01, 2016 at 04:03:40PM -0700, Junio C Hamano wrote: > Eric Wong writes: > > > From: Junio C Hamano > > > > Allowing PAGER_ENV to be set at build-time allows us to move > > pager-specific knowledge out of our build. Currently, this > > allows us

Re: Un-paged commit messages in git filter-branch's commit-filter?

On Mon, Aug 01, 2016 at 11:49:09PM +0200, Stefan Tauner wrote: > > For instance, if I do: > > > > git init > > echo content >file > > git add file > > git commit -m "$(perl -e 'print join(" ", 1..100)')" > > > > I get a commit message with one long unwrapped line, which I can view > >

Re: git bisect for reachable commits only

Christian Couder writes: >> I think the "previous issue" was that we can ask the user to ask to >> check one of 'x' or 'y' when given Good and Bad points in a graph like >> this: >> >> x---y---y---o---B >> \ / >> x---G---o >> >>

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

Christian Couder writes: > On Sat, Jul 30, 2016 at 7:24 PM, Christian Couder > wrote: >> >> I will send a diff between this version and the previous one, as a >> reply to this email. > > Here is the diff: The "verbosity" bits, and also

Re: [[PATCH v2] 1/4] patch-ids: stop using a hand-rolled hashmap implementation

Junio C Hamano wrote: > Johannes Schindelin writes: > > > It would be a serious bug if hashmap_entry_init() played games with > > references, given its signature (that this function does not have any > > access to the hashmap structure, only to the

Re: [PATCH] pass constants as first argument to st_mult()

Jeff King writes: >> *1* I have a slight suspicion that this is cultural, i.e. how >> arithmetic is taught in grade schools. When an apple costs 30 yen >> and I have 5 of them, I was taught to multiply 30x5 to arrive at >> 150, not 5x30=150, and I am guessing that is because the

Re: [PATCH 0/1 v2] add PAGER_ENV to build

On Mon, Aug 01, 2016 at 09:49:36PM +, Eric Wong wrote: > Changes from v1: > > * dropped stringify macro in favor for quoting in Makefile > (diff below) > I'm not sure I like this change, and might be inclined to > go in the opposite direction of using the stringify macro > more

Re: [PATCH v9 35/41] apply: make it possible to silently apply

Christian Couder writes: > +enum apply_verbosity { > + verbosity_silent = -1, > + verbosity_normal = 0, > + verbosity_verbose = 1, Drop the trailing comma from the last element in enum definition (comma after the last element in an array is OK). -- To

Re: [PATCH] reset cached ident date before creating objects

On Mon, Aug 01, 2016 at 02:54:47PM -0700, Junio C Hamano wrote: > Jeff King writes: > > > I also didn't go looking for other spots which might want similar > > treatment. Junio mentioned that the sequencer code still uses an > > external commit process, so cherry-pick/revert are

[PATCH 1/1 v2] pager: move pager-specific setup into the build

From: Junio C Hamano Allowing PAGER_ENV to be set at build-time allows us to move pager-specific knowledge out of our build. Currently, this allows us to set a better default for FreeBSD where more(1) is the same binary as less(1). This also prepares us for introducing a

[PATCH 0/1 v2] add PAGER_ENV to build

Changes from v1: * dropped stringify macro in favor for quoting in Makefile (diff below) I'm not sure I like this change, and might be inclined to go in the opposite direction of using the stringify macro more widely to simplify the Makefile; but that is a separate topic. * dropped

Re: [PATCH v2 1/2] format-patch: Add a config option format.from to set the default for --from

Josh Triplett writes: > Subject: Re: [PATCH v2 1/2] format-patch: Add a config option format.from ... At least s/Add/add/; but I would prefer an even shorter format-patch: format.from gives the default for --from > +static char *from; The same "this does not

Re: [PATCH] reset cached ident date before creating objects

Jeff King writes: > I also didn't go looking for other spots which might want similar > treatment. Junio mentioned that the sequencer code still uses an > external commit process, so cherry-pick/revert are OK. git-fast-import > creates a stream of commits, but already deals with

Re: [PATCHv3 0/7] submodule update: allow '.' for branch value

Stefan Beller writes: > This got bigger than expected, but I am happier with the results. > > The meat is found in the last patch. (At least what I am interested in; others > may be more interested in the second patch which could be argued to be a real > bug fix to be merged

Re: git grep -P is multiline for negative lookahead/behind

Michael Giuffrida writes: > Is this expected behavior, and if so, why/where is this documented? I do not think "git grep" was designed to do multi-line anything, with or without lookahead. If you imagine that the implementation attempts its matches line-by-line, does

Re: [PATCH v3 3/3] t3700: add a test_mode_in_index helper function

Ingo Brückl writes: Ingo Brückl writes: > The case statement to check the file mode of a staged file appears > a number of times. > > Simplify the test by utilizing a test_mode_in_index helper function. > > Signed-off-by: Ingo Brückl

Re: Un-paged commit messages in git filter-branch's commit-filter?

On Sun, Jul 31, 2016 at 06:39:35PM +0200, Stefan Tauner wrote: > > There are some output formats that will wrap lines, but by default, > > filter-branch should not be using them (and I could not reproduce the > > issue in a simple test). Can you show us what your commit-filter looks > > like? >

Re: [ANNOUNCE] git-series: track changes to a patch series over time

Josh Triplett wrote: > On Mon, Aug 01, 2016 at 07:55:54AM +, Eric Wong wrote: > > Christian Couder wrote: > > > On Fri, Jul 29, 2016 at 12:10 PM, Richard Ipsum > > > wrote: > > > > On Thu, Jul 28, 2016 at

Re: Recovering Folder from Git Restored Repo

On Mon, Aug 01, 2016 at 04:58:47PM -0400, Dennis Putnam wrote: > I am in a bit of a pickle. I deleted a remote repo that had a folder > that I belatedly realized I need. The deleted repo exists on a backup > which I restored. How do I extract the needed folder from that restored > repo. Not being

Re: [PATCH] pass constants as first argument to st_mult()

Jeff King writes: >> -mx = xcalloc(st_mult(num_create, NUM_CANDIDATE_PER_DST), sizeof(*mx)); >> +mx = xcalloc(st_mult(NUM_CANDIDATE_PER_DST, num_create), sizeof(*mx)); > > I didn't look at all of the calls, but I wonder if it is a natural > pattern to put the constant

Recovering Folder from Git Restored Repo

I am in a bit of a pickle. I deleted a remote repo that had a folder that I belatedly realized I need. The deleted repo exists on a backup which I restored. How do I extract the needed folder from that restored repo. Not being a git expert I'm not sure what to do but I cannot find any recognizable

Re: [PATCH] pass constants as first argument to st_mult()

On Mon, Aug 01, 2016 at 02:00:46PM -0700, Junio C Hamano wrote: > > Since multiplication is > > commutative, it would be correct for st_mult() to just flip the order of > > arguments it feeds to unsigned_mult_overflows(). > > > > That may introduce the same inefficiency in other callsites, but I

Re: [PATCH] t7063: work around FreeBSD's lazy mtime update feature

Duy Nguyen writes: > On Mon, Aug 1, 2016 at 3:37 AM, Torstem Bögershausen wrote: >> the term FREEBSD may be too generic to point out a single feature >> in an OS distributution. >> Following your investigations, it may even be possible that >> other systems

Re: [PATCH] gitweb: escape link body in format_ref_marker

Jakub Narębski writes: > Good catch! > > Acked-by: Jakub Narębski Sigh; the contents may be good but the patch is unusable as-is because of heavy whitespace damage. I'll fix it up. Thanks, both. >> --- >> gitweb/gitweb.perl | 2 +- >> 1 file changed, 1

Re: [PATCH] use strbuf_addstr() for adding constant strings to a strbuf

Jeff King writes: > On Sat, Jul 30, 2016 at 07:36:23PM +0200, René Scharfe wrote: > >> Replace uses of strbuf_addf() for adding strings with more lightweight >> strbuf_addstr() calls. >> >> In http-push.c it becomes easier to see what's going on without having >> to verfiy that

Re: [PATCH v9 33/41] environment: add set_index_file()

Junio C Hamano writes: > Stefan Beller writes: > >> In cache.h we have a NO_THE_INDEX_COMPATIBILITY_MACROS, >> and lots of >> #define foo_bar(..) frob_bar(_index, (..)) >> >> Could you operate on the raw functions that take pointers to _index >> and

Re: [PATCH 1/2] format-patch: Add a config option format.from to set the default for --from

Josh Triplett writes: > +static char *from; > static const char *signature = git_version_string; > static const char *signature_file; > static int config_cover_letter; > @@ -807,6 +808,17 @@ static int git_format_config(const char *var, const char > *value, void *cb) >

Re: [PATCH v9 33/41] environment: add set_index_file()

Stefan Beller writes: > In cache.h we have a NO_THE_INDEX_COMPATIBILITY_MACROS, > and lots of > #define foo_bar(..) frob_bar(_index, (..)) > > Could you operate on the raw functions that take pointers to _index > and point these to a temporary index? Isn't mention of

Re: [PATCH] reset cached ident date before creating objects

On Mon, Aug 01, 2016 at 02:00:47PM -0400, Jeff King wrote: > So at this point I think I'd lean towards programs which have multiple > logical commit operations explicitly saying "I am starting a new > operation". It may be that we end up attaching more to that in the long > run than just

Re: git bisect for reachable commits only

On Mon, Aug 1, 2016 at 9:51 PM, Junio C Hamano wrote: > Christian Couder writes: > >> Yes, and the reason is that all the ancestors of a good commit are >> considered good. >> That's because git bisect supposes that there is only one transition >>

Re: [[PATCH v2] 4/4] rebase: avoid computing unnecessary patch IDs

Johannes Schindelin writes: > Hi Junio, > > On Fri, 29 Jul 2016, Junio C Hamano wrote: > >> Kevin Willford writes: >> >> > static int patch_id_cmp(struct patch_id *a, >> >struct patch_id *b, >> > - void

Re: [[PATCH v2] 1/4] patch-ids: stop using a hand-rolled hashmap implementation

Johannes Schindelin writes: > It would be a serious bug if hashmap_entry_init() played games with > references, given its signature (that this function does not have any > access to the hashmap structure, only to the entry itself): > > void

Re: [PATCH v2 0/2] format-patch: Transition the default to --from to avoid spoofed mails

On Mon, Aug 01, 2016 at 01:47:24PM -0400, Jeff King wrote: > On Sat, Jul 30, 2016 at 12:11:05PM -0700, Josh Triplett wrote: > > > Josh Triplett (2): > > format-patch: Add a config option format.from to set the default for > > --from > > format-patch: Default to --from > > By the way, I

Re: git bisect for reachable commits only

Christian Couder writes: > Yes, and the reason is that all the ancestors of a good commit are > considered good. > That's because git bisect supposes that there is only one transition > from good to bad. > Otherwise we would need a more complex algorithm to find all

Re: [ANNOUNCE] git-series: track changes to a patch series over time

On Mon, Aug 01, 2016 at 09:14:54AM -0600, Stephen Warren wrote: > On 07/29/2016 12:40 AM, Josh Triplett wrote: > > I'd like to announce a project I've been working on for a while: > > > > git-series provides a tool for managing patch series with git, tracking > > the "history of history". git

Re: [PATCH v5 14/16] merge-recursive: offer an option to retain the output in 'obuf'

Johannes Schindelin writes: >> I actually now see how this would work well for "reason 2)". If a >> caller wants to run the function and wants to pretend as if it did >> not run anything when it failed, for example, using this to spool >> all output and error to a

Re: [PATCH v6 05/16] Prepare the builtins for a libified merge_recursive()

Johannes Schindelin writes: > Previously, callers of merge_trees() or merge_recursive() expected that > code to die() with an error message. This used to be okay because we > called those commands from scripts, and had a chance to print out a > message in case the

Re: [PATCH 1/2] pager: move pager-specific setup into the build

On Mon, Aug 1, 2016 at 7:52 PM, Jeff King wrote: > On Mon, Aug 01, 2016 at 07:46:34PM +0200, Duy Nguyen wrote: > >> On Mon, Aug 1, 2016 at 3:05 AM, Eric Wong wrote: >> > From: Junio C Hamano >> > >> > Allowing PAGER_ENV to be set at build-time

Re: [PATCH] reset cached ident date before creating objects

On Mon, Aug 01, 2016 at 10:49:12AM -0700, Junio C Hamano wrote: > Jeff King writes: > > >> So maybe we would have to put reset_ident_date() at the end of the > >> function instead, at least after git_committer_info() is called. > > > > Yes, although "reset and end" still feels a

Re: [RFC] git-format-patch: default to --from to avoid spoofed mails?

Jeff King writes: > I half-agree. Config that causes unpredictable behavior can break > somebody else's script that you are running. If you say "oh, I guess I > shouldn't set that config" and move on with your life, then the config > hasn't really hurt anybody. If you complain to

Re: [PATCH v6 06/16] merge_recursive: abort properly upon errors

Johannes Schindelin writes: > Subject: Re: [PATCH v6 06/16] merge_recursive: abort properly upon errors s/merge_/merge-/; for this one alone. > There are a couple of places where return values never indicated errors > before, as wie simply died instead of returning.

Re: [PATCH v5 16/16] merge-recursive: flush output buffer even when erroring out

Johannes Schindelin writes: >> This is of course a good change, but we need to assume that no >> further output is made from the remainder of the function for the >> change in the next hunk to remove the existing flush to be correct. > ... > But you made me realize

Re: [PATCH 1/2] pack-objects: Teach --use-bitmap-index codepath to respect --local, --honor-pack-keep and --incremental

Kirill Smelkov writes: > Since 6b8fda2d (pack-objects: use bitmaps when packing objects) there > are two codepaths in pack-objects: with & without using bitmap > reachability index. > > However add_object_entry_from_bitmap(), despite its non-bitmapped > counterpart

Re: [PATCH] reset cached ident date before creating objects

On Mon, Aug 01, 2016 at 02:12:34PM -0400, Jeff King wrote: > Before I switched to "reset at the beginning" in my original patch, I > also noticed this issue, but decided the other way: to only reset after > a successful creation. > > I think in most cases it wouldn't matter anyway, because the

Re: [PATCH 1/2] pager: move pager-specific setup into the build

Jeff King writes: > I'm not too worried about spaces here. This is a resurrection of an old > discussion, and in all that time, I think the only realistic suggestions > for built-in values have been pretty tame. > > If this were used to parse arbitrary user-provided runtime

Re: [PATCH v3 10/10] convert: add filter..process option

> On 01 Aug 2016, at 00:19, Jakub Narębski wrote: > > W dniu 30.07.2016 o 01:38, larsxschnei...@gmail.com pisze: > [...] >> +Please note that you cannot use an existing filter..clean >> +or filter..smudge command as filter..process >> +command. > > I think it would be more

Re: [PATCH] reset cached ident date before creating objects

On Mon, Aug 01, 2016 at 10:58:47AM -0700, Junio C Hamano wrote: > diff --git a/commit.c b/commit.c > index b02f3c4..db24013 100644 > --- a/commit.c > +++ b/commit.c > @@ -1543,7 +1543,6 @@ int commit_tree_extended(const char *msg, size_t > msg_len, > } > > /* Person/date

Re: [PATCH 1/2] pager: move pager-specific setup into the build

On Mon, Aug 01, 2016 at 08:01:13PM +0200, Duy Nguyen wrote: > > If you are interested, I suggest you read the thread linked earlier: > > > > https://public-inbox.org/git/52D87A79.6060600%40rawbw.com/T/#u > > > > which discusses this and other issues. But basically, I think you cannot > > really

Re: [PATCH v2 1/2] format-patch: Add a config option format.from to set the default for --from

On Sat, Jul 30, 2016 at 12:11:11PM -0700, Josh Triplett wrote: > +enum from { > + FROM_AUTHOR, > + FROM_USER, > + FROM_VALUE, > +}; > + > +static void set_from(enum from type, const char *value) > +{ > + free(from); > + switch (type) { > + case FROM_AUTHOR: > +

Re: [PATCH 1/2] pager: move pager-specific setup into the build

On Mon, Aug 01, 2016 at 07:46:34PM +0200, Duy Nguyen wrote: > On Mon, Aug 1, 2016 at 3:05 AM, Eric Wong wrote: > > From: Junio C Hamano > > > > Allowing PAGER_ENV to be set at build-time allows us to move > > pager-specific knowledge out of our build.

Re: [PATCH] reset cached ident date before creating objects

Junio C Hamano writes: > Jeff King writes: > >>> So maybe we would have to put reset_ident_date() at the end of the >>> function instead, at least after git_committer_info() is called. >> >> Yes, although "reset and end" still feels a bit weird to me. >> >> I'd

Re: [PATCH 2/2] pager: implement core.pagerEnv in config

On Mon, Aug 01, 2016 at 01:05:57AM +, Eric Wong wrote: > This allows overriding the build-time PAGER_ENV variable > at run-time. > > Inspired by part 1 of an idea from Kyle J. McKay at: > https://public-inbox.org/git/62db6def-8b39-4481-ba06-245bf4523...@gmail.com/ This commit message is

Re: [PATCH 1/2] pager: move pager-specific setup into the build

On Mon, Aug 1, 2016 at 3:05 AM, Eric Wong wrote: > From: Junio C Hamano > > Allowing PAGER_ENV to be set at build-time allows us to move > pager-specific knowledge out of our build. Currently, this > allows us to set a better default for FreeBSD where more(1)

Re: [PATCH v2 0/2] format-patch: Transition the default to --from to avoid spoofed mails

On Sat, Jul 30, 2016 at 12:11:05PM -0700, Josh Triplett wrote: > Josh Triplett (2): > format-patch: Add a config option format.from to set the default for --from > format-patch: Default to --from By the way, I notice that the threading between your patches and cover letter are broken. Since

Re: [PATCH] reset cached ident date before creating objects

Jeff King writes: >> So maybe we would have to put reset_ident_date() at the end of the >> function instead, at least after git_committer_info() is called. > > Yes, although "reset and end" still feels a bit weird to me. > > I'd almost prefer to just have long-running programs

Re: [RFC] git-format-patch: default to --from to avoid spoofed mails?

On Mon, Aug 01, 2016 at 10:35:22AM -0700, Junio C Hamano wrote: > > I do have to admit that after reading through the "format.*" section of > > git-config(1), there is quite a bit that is configurable in it. So > > perhaps we do not need to be as careful about behavior changes as I > > thought. >

Re: [RFC] git-format-patch: default to --from to avoid spoofed mails?

Jeff King writes: > On Fri, Jul 29, 2016 at 09:50:55PM -0700, Josh Triplett wrote: > >> I would propose the following then: >> >> - I'll write a patch adding a config option format.from, along with >> documentation, without changing the default. >> - The release notes for the

Re: [PATCH 1/2] format-patch: Add a config option format.from to set the default for --from

On Sat, Jul 30, 2016 at 11:12:46AM -0700, Josh Triplett wrote: > > These tests follow a different style from the "--from" tests later in > > the script (and your second patch does follow it, and puts its test > > close there). Any reason not to have all of the "from" tests together, > > and using

Re: [PATCH 1/2] pager: move pager-specific setup into the build

On Mon, Aug 01, 2016 at 01:43:03AM +, brian m. carlson wrote: > On Mon, Aug 01, 2016 at 01:05:56AM +, Eric Wong wrote: > > +static void setup_pager_env(struct argv_array *env) > > +{ > > + const char *pager_env = stringify(PAGER_ENV); > > + > > + while (*pager_env) { > > +

Re: git bisect for reachable commits only

On Mon, Aug 1, 2016 at 12:02 PM, Oleg Taranenko wrote: > Guys, > > further investigation shows, git bisect is broken from its core... really. > Let consider 3rd a bit more complicated scenario > > #cd .. > #rm -rf bisect3 > mkdir bisect3 > cd bisect3 > git init > git

Re: [PATCH 3/3] diff-highlight: add support for --graph output.

Brian Henderson writes: > --- > contrib/diff-highlight/diff-highlight | 13 +++-- > 1 file changed, 7 insertions(+), 6 deletions(-) > > diff --git a/contrib/diff-highlight/diff-highlight > b/contrib/diff-highlight/diff-highlight > index ffefc31..ec31356 100755 >

Re: [PATCH] use strbuf_addstr() for adding constant strings to a strbuf

On Sat, Jul 30, 2016 at 07:36:23PM +0200, René Scharfe wrote: > Replace uses of strbuf_addf() for adding strings with more lightweight > strbuf_addstr() calls. > > In http-push.c it becomes easier to see what's going on without having > to verfiy that the definition of PROPFIND_ALL_REQUEST

Re: [PATCH] t7063: work around FreeBSD's lazy mtime update feature

On Mon, Aug 1, 2016 at 3:37 AM, Torstem Bögershausen wrote: > the term FREEBSD may be too generic to point out a single feature > in an OS distributution. > Following your investigations, it may even be possible that > other systems adapt this "feature"? > > How about >

Re: git bisect for reachable commits only

Jakub Narębski writes: > Isn't `--reachable-commits` the same as existing `--ancestry-path` > option to `git log` and friends (I wonder if passing log options to > bisect, that is: `git bisect --ancestry-path ...` would work)? Yes, I somehow missed it, but you are absolutely

Re: [PATCH v9 39/41] apply: change error_routine when silent

On Sat, Jul 30, 2016 at 10:25 AM, Christian Couder wrote: > + /* This is to save some reporting routines */ some? In case of a reroll could you be more specific? Specifically mention that we use these for the muting/when silence is requested. e.g. /* These

Re: [PATCH] pass constants as first argument to st_mult()

On Sat, Jul 30, 2016 at 08:18:31PM +0200, René Scharfe wrote: > The result of st_mult() is the same no matter the order of its > arguments. It invokes the macro unsigned_mult_overflows(), which > divides the second parameter by the first one. Pass constants > first to allow that division to be

Re: [PATCH v9 03/41] builtin/apply: make apply_patch() return -1 or -128 instead of die()ing

On Sat, Jul 30, 2016 at 10:24 AM, Christian Couder wrote: > + * Try to apply a patch. > + * > + * Returns: > + * -128 if a bad error happened (like patch unreadable) > + * -1 if patch did not apply and user cannot deal with it > + * 0 if the patch applied > + *

Re: [PATCH v9 04/41] builtin/apply: read_patch_file() return -1 instead of die()ing

On Sat, Jul 30, 2016 at 10:24 AM, Christian Couder wrote: > -static void read_patch_file(struct strbuf *sb, int fd) > +static int read_patch_file(struct strbuf *sb, int fd) > { > if (strbuf_read(sb, fd, 0) < 0) > - die_errno("git apply: failed

Re: [PATCH v3 7/8] status: update git-status.txt for --porcelain=v2

On 07/30/2016 01:22 PM, Jakub Narębski wrote: W dniu 26.07.2016 o 23:11, Jeff Hostetler pisze: This is a nice change, available because of lack of backward compatibility with v1. The porcelain v2 format branch-related information could be enhanced without risk of breaking parsers, or having

Re: [ANNOUNCE] git-series: track changes to a patch series over time

On 07/29/2016 12:40 AM, Josh Triplett wrote: I'd like to announce a project I've been working on for a while: git-series provides a tool for managing patch series with git, tracking the "history of history". git series tracks changes to the patch series over time, including rebases and other

Re: [PATCH v3 10/10] convert: add filter..process option

> On 31 Jul 2016, at 00:05, Jakub Narębski wrote: > > W dniu 30.07.2016 o 01:38, larsxschnei...@gmail.com pisze: >> From: Lars Schneider >> >> Git's clean/smudge mechanism invokes an external filter process for every >> single blob that is affected

Re: [PATCH v3 03/10] pkt-line: add packet_flush_gentle()

> On 30 Jul 2016, at 14:04, Jakub Narębski wrote: > > W dniu 30.07.2016 o 01:37, larsxschnei...@gmail.com pisze: >> From: Lars Schneider >> >> packet_flush() would die in case of a write error even though for some >> callers >> an error would be

Re: [PATCH v3 05/10] pack-protocol: fix maximum pkt-line size

> On 30 Jul 2016, at 15:58, Jakub Narębski wrote: > > W dniu 30.07.2016 o 01:37, larsxschnei...@gmail.com pisze: >> From: Lars Schneider >> >> According to LARGE_PACKET_MAX in pkt-line.h the maximal lenght of a >> pkt-line packet is 65520 bytes. The

Re: [PATCH v3 04/10] pkt-line: call packet_trace() only if a packet is actually send

> On 30 Jul 2016, at 14:29, Jakub Narębski wrote: > > W dniu 30.07.2016 o 01:37, larsxschnei...@gmail.com pisze: >> From: Lars Schneider >> >> The packet_trace() call is not ideal in format_packet() as we would print > > Style; I think the

Re: [PATCH v3 02/10] pkt-line: add direct_packet_write() and direct_packet_write_data()

> On 30 Jul 2016, at 12:49, Jakub Narębski wrote: > > W dniu 30.07.2016 o 01:37, larsxschnei...@gmail.com pisze: >> From: Lars Schneider >> >> Sometimes pkt-line data is already available in a buffer and it would >> be a waste of resources to write

Re: [PATCH v3 06/10] run-command: add clean_on_exit_handler

> On 30 Jul 2016, at 11:50, Johannes Sixt wrote: > > Am 30.07.2016 um 01:37 schrieb larsxschnei...@gmail.com: >> Some commands might need to perform cleanup tasks on exit. Let's give >> them an interface for doing this. >> >> Signed-off-by: Lars Schneider

[PATCH v6 07/16] merge-recursive: avoid returning a wholesale struct

It is technically allowed, as per C89, for functions' return type to be complete structs (i.e. *not* just pointers to structs). However, it was just an oversight of this developer when converting Python code to C code in 6d297f8 (Status update on merge-recursive in C, 2006-07-08) which introduced

[PATCH v6 15/16] Ensure that the output buffer is released after calling merge_trees()

The recursive merge machinery accumulates its output in an output buffer, to be flushed at the end of merge_recursive(). At this point, we forgot to release the output buffer. When calling merge_trees() (i.e. the non-recursive part of the recursive merge) directly, the output buffer is never

[PATCH v6 12/16] merge-recursive: flush output buffer before printing error messages

The data structure passed to the recursive merge machinery has a feature where the caller can ask for the output to be buffered into a strbuf, by setting the field 'buffer_output'. Previously, we died without flushing, losing accumulated output. With this patch, we show the output first, and

[PATCH v6 06/16] merge_recursive: abort properly upon errors

There are a couple of places where return values never indicated errors before, as wie simply died instead of returning. But now negative return values mean that there was an error and we have to abort the operation. Let's do exactly that. Signed-off-by: Johannes Schindelin

[PATCH v6 08/16] merge-recursive: allow write_tree_from_memory() to error out

It is possible that a tree cannot be written (think: disk full). We will want to give the caller a chance to clean up instead of letting the program die() in such a case. Signed-off-by: Johannes Schindelin --- merge-recursive.c | 4 ++-- 1 file changed, 2

[PATCH v6 16/16] merge-recursive: flush output buffer even when erroring out

Ever since 66a155b (Enable output buffering in merge-recursive., 2007-01-14), we had a problem: When the merge failed in a fatal way, all regular output was swallowed because we called die() and did not get a chance to drain the output buffers. To fix this, several modifications were necessary:

[PATCH v6 11/16] am -3: use merge_recursive() directly again

Last October, we had to change this code to run `git merge-recursive` in a child process: git-am wants to print some helpful advice when the merge failed, but the code in question was not prepared to return, it die()d instead. We are finally at a point when the code *is* prepared to return

[PATCH v6 14/16] merge-recursive: offer an option to retain the output in 'obuf'

Since 66a155b (Enable output buffering in merge-recursive., 2007-01-14), we already accumulate the output in a buffer. The idea was to avoid interfering with the progress output that goes to stderr, which is unbuffered, when we write to stdout, which is buffered. We extend that buffering to allow

[PATCH v6 09/16] merge-recursive: handle return values indicating errors

We are about to libify the recursive merge machinery, where we only die() in case of a bug or memory contention. To that end, we must heed negative return values as indicating errors. This requires our functions to be careful to pass through error conditions in call chains, and for quite a few

[PATCH v6 10/16] merge-recursive: switch to returning errors instead of dying

The recursive merge machinery is supposed to be a library function, i.e. it should return an error when it fails. Originally the functions were part of the builtin "merge-recursive", though, where it was simpler to call die() and be done with error handling. The existing callers were already

[PATCH v6 13/16] merge-recursive: write the commit title in one go

In 66a155b (Enable output buffering in merge-recursive., 2007-01-14), we changed the code such that it prints the output in one go, to avoid interfering with the progress output. Let's make sure that the same holds true when outputting the commit title: previously, we used several printf()

[PATCH v6 03/16] Avoid translating bug messages

While working on the patch series that avoids die()ing in recursive merges, the issue came up that bug reports (i.e. die("BUG: ...") constructs) should never be translated, as the target audience is the Git developer community, not necessarily the current user, and hence a translated message would

[PATCH v6 04/16] merge-recursive: clarify code in was_tracked()

It can be puzzling to see that was_tracked() asks to get an index entry by name, but does not take a negative return value for an answer. The reason we have to do this is that cache_name_pos() only looks for entries in stage 0, even if nobody asked for any stage in particular. Let's rewrite the

[PATCH v6 05/16] Prepare the builtins for a libified merge_recursive()

Previously, callers of merge_trees() or merge_recursive() expected that code to die() with an error message. This used to be okay because we called those commands from scripts, and had a chance to print out a message in case the command failed fatally (read: with exit code 128). As scripting

[PATCH v6 00/16] Use merge_recursive() directly in the builtin am

This is the sixth iteration of the long-awaited re-roll of the attempt to avoid spawning merge-recursive from the builtin am and use merge_recursive() directly instead. The *real* reason for the reroll is that I need a libified recursive merge to accelerate the interactive rebase by teaching the

[PATCH v6 02/16] Report bugs consistently

The vast majority of error messages in Git's source code which report a bug use the convention to prefix the message with "BUG:". As part of cleaning up merge-recursive to stop die()ing except in case of detected bugs, let's just make the remainder of the bug reports consistent with the de facto

[PATCH v6 01/16] t5520: verify that `pull --rebase` shows the helpful advice when failing

It was noticed by Brendan Forster last October that the builtin `git am` regressed on that. Our hot fix reverted to spawning the recursive merge instead of using it as a library function. As we are about to revert that hot fix, after making the recursive merge a true library function (i.e. a

Re: [PATCH v3 01/10] pkt-line: extract set_packet_header()

> On 30 Jul 2016, at 12:30, Jakub Narębski wrote: > > W dniu 30.07.2016 o 01:37, larsxschnei...@gmail.com pisze: >> From: Lars Schneider >> >> set_packet_header() converts an integer to a 4 byte hex string. Make >> this function locally available so

Re: [PATCH 1/2] pager: move pager-specific setup into the build

On Mon, Aug 01, 2016 at 10:57:02AM +0200, Jakub Narębski wrote: > W dniu 01.08.2016 o 09:00, Eric Wong pisze: > > "brian m. carlson" wrote: > >> So it looks like this function splits on spaces but doesn't provide any > >> escaping mechanism. Is there any case in

Re: git bisect for reachable commits only

Guys, further investigation shows, git bisect is broken from its core... really. Let consider 3rd a bit more complicated scenario #cd .. #rm -rf bisect3 mkdir bisect3 cd bisect3 git init git touch coffee git commit -am "create coffee" git branch tee echo sugar >> coffee git commit -am "add

  1   2   >