Re: [PATCH] add a script to diff rendered documentation

On Mon, Aug 06, 2018 at 09:39:55AM -0400, Jeff King wrote: > 3. Default to number of CPUs, which is what a lot of other threading > in Git does. Unfortunately getting that from the shell is > non-trivial. I'm OK with $(grep -c ^processor /proc/cpuinfo), but > people on non-Linux p

Re: [PATCH] add a script to diff rendered documentation

On Sun, Aug 05, 2018 at 08:49:31PM +, brian m. carlson wrote: > > +parallel=8 > > I'm not sure -j8 is a great default. There are still a lot of > two-core/four-thread machines out there, such as my laptop (from 2016). > Maybe we should default this to 1 unless -j is provided, like make does.

Re: [PATCH 4/4] line-log: convert an assertion to a full BUG() call

Hi Eric, On Sun, 5 Aug 2018, Eric Sunshine wrote: > On Sat, Aug 4, 2018 at 6:18 PM Johannes Schindelin via GitGitGadget > wrote: > > The assertion in question really indicates a bug, when triggered, so we > > might just as well use the sanctioned method to report it. > > > > Signed-off-by: Johan

Re: [PATCH 1/1] t/test-lib: make `test_dir_is_empty` more robust

On Sun, Aug 05, 2018 at 04:52:31PM -0400, Jeff King wrote: > On Sun, Aug 05, 2018 at 01:23:05AM -0400, Eric Sunshine wrote: > > > A simpler approach, without the portability concerns of -A, would be > > to remove the "." and ".." lines from the top of the listing: > > > > ls -f1 "$1" | sed '

Re: [PATCH 2/4] line-log: adjust start/end of ranges individually

Hi Eric, On Sun, 5 Aug 2018, Eric Sunshine wrote: > On Sat, Aug 4, 2018 at 6:18 PM Johannes Schindelin via GitGitGadget > wrote: > > When traversing commits and adjusting the ranges, things can get really > > tricky. For example, when the line range of interest encloses several > > hunks of a co

Re: [RFC PATCH v2 06/12] submodule--helper: add a '--stage' option to the 'config' sub command

On Fri, 03 Aug 2018 09:24:14 -0700 Junio C Hamano wrote: > Antonio Ospite writes: > > > The rationale behind the change is to close the circle started with 04 > > and 05 and stop referring to .gitmodules explicitly by file path in git > > commands. The change is not strictly needed for the seri

Re: [PATCH 1/4] line-log: demonstrate a bug with nearly-overlapping ranges

Hi Jonathan, On Sat, 4 Aug 2018, Jonathan Nieder wrote: > Johannes Schindelin wrote: > > > Currently, this test case throws an assertion: > > > > Assertion failed! > > > > Program: git.exe > > File: line-log.c, Line 71 > > > > Signed-off-by: Johannes Schindelin > > --- > > t/t4211-

Re: [PATCH v2 0/2] Make git rebase work with --rebase-merges and --exec

Team, On Mon, 6 Aug 2018, Johannes Schindelin via GitGitGadget wrote: > It was reported via IRC that the exec lines are inserted in the wrong spots > when using --rebase-merges. > > The reason is that we used a simple, incorrect implementation that happened > to work as long as the generated tod

[PATCH v2 2/2] rebase --exec: make it work with --rebase-merges

From: Johannes Schindelin The idea of `--exec` is to append an `exec` call after each `pick`. Since the introduction of fixup!/squash! commits, this idea was extended to apply to "pick, possibly followed by a fixup/squash chain", i.e. an exec would not be inserted between a `pick` and any of its

[PATCH v2 1/2] t3430: demonstrate what -r, --autosquash & --exec should do

From: Johannes Schindelin The --exec option's implementation is not really well-prepared for --rebase-merges. Demonstrate this. Signed-off-by: Johannes Schindelin --- t/t3430-rebase-merges.sh | 17 + 1 file changed, 17 insertions(+) diff --git a/t/t3430-rebase-merges.sh b/t/t3

[PATCH v2 0/2] Make git rebase work with --rebase-merges and --exec

It was reported via IRC that the exec lines are inserted in the wrong spots when using --rebase-merges. The reason is that we used a simple, incorrect implementation that happened to work as long as the generated todo list only contains pick, fixup and squash commands. Which is not the case with-

Re: [PATCH 2/2] rebase --exec: make it work with --rebase-merges

Hi Junio, On Fri, 3 Aug 2018, Junio C Hamano wrote: > "Johannes Schindelin via GitGitGadget" > writes: > > > diff --git a/sequencer.c b/sequencer.c > > index 31038472f..dda5cdbba 100644 > > --- a/sequencer.c > > +++ b/sequencer.c > > @@ -4244,10 +4244,9 @@ int sequencer_add_exec_commands(const

Re: [PATCH 2/2] rebase --exec: make it work with --rebase-merges

Hi Junio, On Fri, 3 Aug 2018, Junio C Hamano wrote: > "Johannes Schindelin via GitGitGadget" > writes: > > > + /* > > +* Insert after every pick. Here, fixup/squash chains > > +* are considered part of the pick, so we insert the commands *after* > > +* those chains if there are a

Re: [PATCH 2/2] rebase --exec: make it work with --rebase-merges

Hi Junio, On Fri, 3 Aug 2018, Junio C Hamano wrote: > "Johannes Schindelin via GitGitGadget" > writes: > > > From: Johannes Schindelin > > > > The idea of `--exec` is to append an `exec` call after each `pick`. > > > > Since the introduction of fixup!/squash! commits, this idea was extended >

Re: [PATCH v2] t4150: fix broken test for am --scissors

Hi, I've taken a look at the original test, and it is pretty broken. My deepest apologies for this mess. On Sun, Aug 5, 2018 at 2:10 AM, Andrei Rybak wrote: > Tests for "git am --[no-]scissors" [1] work in the following way: > > 1. Create files with commit messages > 2. Use these files to crea

Re: [RFC PATCH 3/5] pack-objects: add delta-islands support

On Sun, Aug 5, 2018 at 7:40 PM, Christian Couder wrote: > On Tue, Jul 24, 2018 at 7:11 PM, Junio C Hamano wrote: > This is the new documentation: > > -> Refs are grouped into islands based on their "names", and two regexes > -> that produce the same name are considered to be in the same > -> isl

Re: concurrent access to multiple local git repos is error prone

To add something to the previous message, I have strong evidence that the problem occurs when *different* repos are accessed concurrency, not the same repo, as bizarre as that may be. -alex On Mon, Aug 6, 2018 at 12:36 AM, Alexander Mills wrote: > Hi Johnathan, > > Yeah this concurrency problem

Re: concurrent access to multiple local git repos is error prone

Hi Johnathan, Yeah this concurrency problem is real. Not only does it happen with `git status` the same thing happens with `git rev-parse --show-toplevel`. What happens is that I get no stdout when repos are accessed concurrently (and no stderr). If I limit concurrency to 1, the problem goes away.

<    1   2