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

Christian Couder wrote: > On Fri, Jul 29, 2016 at 12:10 PM, Richard Ipsum > wrote: > > On Thu, Jul 28, 2016 at 11:40:55PM -0700, Josh Triplett wrote: > > [snip] > >> > >> I'd welcome any feedback, whether on the interface and workflow,

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

"brian m. carlson" wrote: > On Mon, Aug 01, 2016 at 01:05:56AM +, Eric Wong wrote: > > + while (*cp && *cp == ' ') > > + cp++; > > So it looks like this function splits on spaces but doesn't provide any > escaping mechanism. Is there

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

[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

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

[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

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

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 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 v2] 4/4] rebase: avoid computing unnecessary patch IDs

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 *keydata) > > + struct diff_options *opt) > > { > >

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

W dniu 01.08.2016 o 09:00, Eric Wong pisze: > "brian m. carlson" wrote: >> On Mon, Aug 01, 2016 at 01:05:56AM +, Eric Wong wrote: >>> + while (*cp && *cp == ' ') >>> + cp++; >> >> So it looks like this function splits on spaces but

Re: git cherry-pick conflict error message is deceptive when cherry-picking multiple commits

Hi Stephen, On Wed, 27 Jul 2016, Stephen Morton wrote: > On Wed, Jul 27, 2016 at 11:03 AM, Johannes Schindelin > wrote: > > > > On Wed, 27 Jul 2016, Stephen Morton wrote: > > > >> diff --git a/sequencer.c b/sequencer.c > >> index cdfac82..ce06876 100644 > >> ---

[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

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

[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

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

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

Hi Junio, On Wed, 27 Jul 2016, Junio C Hamano wrote: > Junio C Hamano writes: > > > I am not yet sure if it makes sense to mix both the regular output > > and an error into the same buffer for the callers to process (your > > "reason 1)" above), and this looks like a wrong

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

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

Hi Junio, first of all: Kevin & I are colleagues and I helped prepare this patch series. I had the idea to have a two-level patch ID to help e.g. when an alternate object store is hosted on a (slow) network drive. On Fri, 29 Jul 2016, Junio C Hamano wrote: > Kevin Willford

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

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 11:40:55PM -0700, Josh Triplett wrote: > > > [snip] > > >>

Re: [[PATCH v2] 0/4] Use header data patch ids for rebase to avoid loading file content

Hi Junio, On Fri, 29 Jul 2016, Junio C Hamano wrote: > Kevin Willford writes: > > > This patch series is to remove the hand rolled hashmap in the patch_ids > > and use the hashmap.h implementation. It also introduces the idea of having > > a header only patch id so that

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

Hi Junio, On Wed, 27 Jul 2016, Junio C Hamano wrote: > Johannes Schindelin writes: > > > diff --git a/merge-recursive.c b/merge-recursive.c > > index 311cfa4..a16b150 100644 > > --- a/merge-recursive.c > > +++ b/merge-recursive.c > > @@ -2078,6 +2078,8 @@ int

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

Hi Junio, On Wed, 27 Jul 2016, Junio C Hamano wrote: > Johannes Schindelin writes: > > > diff --git a/merge-recursive.c b/merge-recursive.c > > index a16b150..66e93e0 100644 > > --- a/merge-recursive.c > > +++ b/merge-recursive.c > > @@ -2069,6 +2069,7 @@ int

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

On Mon, Aug 01, 2016 at 01:59:29AM -0700, Josh Triplett wrote: > On Mon, Aug 01, 2016 at 07:55:54AM +, Eric Wong wrote: [snip] > > > > I'm not convinced another format/standard is needed besides the > > email workflow we already use for git and kernel development. > > Not all projects use a

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

Hi Junio, On Wed, 27 Jul 2016, Junio C Hamano wrote: > Johannes Schindelin writes: > > > 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

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

Hi Junio, On Wed, 27 Jul 2016, Junio C Hamano wrote: > Johannes Schindelin writes: > > > diff --git a/merge-recursive.h b/merge-recursive.h > > index d415724..340704c 100644 > > --- a/merge-recursive.h > > +++ b/merge-recursive.h > > @@ -13,7 +13,7 @@ struct

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

git grep -P is multiline for negative lookahead/behind

Negative lookahead/lookbehind with `git grep -P` considers the surrounding lines of an otherwise positive match. This differs from `grep -P` behavior. It does not repro for *positive* lookahead/lookbehind. Example: $ echo -e 'Bar\nBar Baz\nBat' > test.txt && git add test.txt $ git grep -P

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

Hi Junio, On Wed, 27 Jul 2016, Junio C Hamano wrote: > Johannes Schindelin writes: > > > Let's make sure that the same holds true when outputting the commit > > title: previously, we used several printf() statements to stdout and > > speculated that stdout's buffer

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

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

  1   2   >