Re: What's cooking in git.git (Apr 2017, #04; Wed, 19)

Am 25.04.2017 um 08:52 schrieb Junio C Hamano: Johannes Sixt writes: The idea of marking git-gui and gitk histories that none of their commits is checked out: it erases all Git source code from the working directory, and a later bisection step places all code back and it

Re: What's cooking in git.git (Apr 2017, #04; Wed, 19)

Johannes Sixt writes: > The idea of marking git-gui and gitk histories that none of their > commits is checked out: it erases all Git source code from the working > directory, and a later bisection step places all code back and it > requires a full build. Not a big deal with Git,

Re: What's cooking in git.git (Apr 2017, #04; Wed, 19)

Am 25.04.2017 um 04:00 schrieb Christian Couder: On Sat, Apr 22, 2017 at 3:37 PM, Johannes Sixt wrote: Am 21.04.2017 um 14:29 schrieb Christian Couder: First bisect should ask you to test merge bases only if there are "good" commits that are not ancestors of the "bad" commit.

Re: What's cooking in git.git (Apr 2017, #04; Wed, 19)

On Mon, Apr 24, 2017 at 6:34 PM, Philip Oakley wrote: > > Sorry if I'm bikeshedding here, but it does look like adding an alternate > 'bisect' strategy may be useful for this style of integration testing. > > To me, given the multiplicity of independent branches being

Re: What's cooking in git.git (Apr 2017, #04; Wed, 19)

On Sat, Apr 22, 2017 at 3:37 PM, Johannes Sixt wrote: > Am 21.04.2017 um 14:29 schrieb Christian Couder: >> >> First bisect should ask you to test merge bases only if there are >> "good" commits that are not ancestors of the "bad" commit. > > > That's a tangent, but I have never

Re: What's cooking in git.git (Apr 2017, #04; Wed, 19)

Ævar Arnfjörð Bjarmason writes: > Is getting the results of these builds time-critical? If not perhaps > an acceptable solution would be to use a source repo that's > time-delayed, e.g. 24hrs behind on average from Junio's git.git, and > where commits are pushed in at some

Re: What's cooking in git.git (Apr 2017, #04; Wed, 19)

From: "Johannes Schindelin" Hi Hannes, On Sat, 22 Apr 2017, Johannes Sixt wrote: Am 21.04.2017 um 14:29 schrieb Christian Couder: > First bisect should ask you to test merge bases only if there are > "good" commits that are not ancestors of the "bad" commit.

Re: What's cooking in git.git (Apr 2017, #04; Wed, 19)

On Mon, Apr 24, 2017 at 4:19 PM, Johannes Schindelin wrote: > Hi Junio, > > On Sun, 23 Apr 2017, Junio C Hamano wrote: > >> Johannes Schindelin writes: >> >> > Part of the reason is that you push out all of the branches in one go, >> >

Re: What's cooking in git.git (Apr 2017, #04; Wed, 19)

Hi Hannes, On Sat, 22 Apr 2017, Johannes Sixt wrote: > Am 21.04.2017 um 14:29 schrieb Christian Couder: > > First bisect should ask you to test merge bases only if there are > > "good" commits that are not ancestors of the "bad" commit. > > That's a tangent, but I have never understood why this

Re: What's cooking in git.git (Apr 2017, #04; Wed, 19)

Hi Junio, On Sun, 23 Apr 2017, Junio C Hamano wrote: > Johannes Schindelin writes: > > > Part of the reason is that you push out all of the branches in one go, > > typically at the very end of your work day. The idea of Continuous > > Integration is a little

Re: What's cooking in git.git (Apr 2017, #04; Wed, 19)

Hi Christian, On Sat, 22 Apr 2017, Christian Couder wrote: > On Sat, Apr 22, 2017 at 1:48 PM, Johannes Schindelin > wrote: > >> > >> First bisect should ask you to test merge bases only if there are > >> "good" commits that are not ancestors of the "bad" commit. > >

Re: What's cooking in git.git (Apr 2017, #04; Wed, 19)

Johannes Schindelin writes: > Part of the reason is that you push out all of the branches in one go, > typically at the very end of your work day. The idea of Continuous > Integration is a little orthogonal to that style, suggesting to build & > test whenever new

Re: What's cooking in git.git (Apr 2017, #04; Wed, 19)

Hi Dscho, On Sat, Apr 22, 2017 at 1:48 PM, Johannes Schindelin wrote: >> >> First bisect should ask you to test merge bases only if there are >> "good" commits that are not ancestors of the "bad" commit. > > Please note that this is a stateless job. The only "state" I

Re: What's cooking in git.git (Apr 2017, #04; Wed, 19)

Am 21.04.2017 um 14:29 schrieb Christian Couder: First bisect should ask you to test merge bases only if there are "good" commits that are not ancestors of the "bad" commit. That's a tangent, but I have never understood why this needs to be so. Consider this: o--o--o--o--o--o--o--o--B

Re: What's cooking in git.git (Apr 2017, #04; Wed, 19)

Hi Christian, On Fri, 21 Apr 2017, Christian Couder wrote: > On Fri, Apr 21, 2017 at 11:50 AM, Johannes Schindelin > wrote: > > > > (with all associated problems I reported earlier, as you apply some > > patches on top of really ancient commits and bisect wants to

Re: What's cooking in git.git (Apr 2017, #04; Wed, 19)

On Fri, Apr 21, 2017 at 11:50 AM, Johannes Schindelin wrote: > > Since that "let's aggregate everything and only push out the final result > at the end of the day" approach does not really allow the Continuous > Testing to identify problems associated with individual

Re: What's cooking in git.git (Apr 2017, #04; Wed, 19)

Hi Junio, On Thu, 20 Apr 2017, Junio C Hamano wrote: > Lars Schneider writes: > > >> * bw/forking-and-threading (2017-04-19) 11 commits > >> - run-command: block signals between fork and execve > >> - run-command: add note about forking and threading > >> -

Re: What's cooking in git.git (Apr 2017, #04; Wed, 19)

Brandon Williams writes: > On 04/20, Brandon Williams wrote: >> On 04/20, Johannes Schindelin wrote: >> > Hi Lars & Junio, >> > >> > On Thu, 20 Apr 2017, Lars Schneider wrote: >> > >> > > > * bw/forking-and-threading (2017-04-19) 11 commits >> > > > - run-command: block

Re: What's cooking in git.git (Apr 2017, #04; Wed, 19)

On 04/20, Brandon Williams wrote: > On 04/20, Johannes Schindelin wrote: > > Hi Lars & Junio, > > > > On Thu, 20 Apr 2017, Lars Schneider wrote: > > > > > > * bw/forking-and-threading (2017-04-19) 11 commits > > > > - run-command: block signals between fork and execve > > > > - run-command: add

Re: What's cooking in git.git (Apr 2017, #04; Wed, 19)

Lars Schneider writes: >> * bw/forking-and-threading (2017-04-19) 11 commits >> - run-command: block signals between fork and execve >> - run-command: add note about forking and threading >> - run-command: handle dup2 and close errors in child >> - run-command:

Re: What's cooking in git.git (Apr 2017, #04; Wed, 19)

Lars Schneider writes: > Sorry for sending this email multiple times. My mobile email client created > html... Should be fixed now! > >> >> * ls/filter-process-delayed (2017-03-06) 1 commit >> - convert: add "status=delayed" to filter process protocol >> >> What's

Re: What's cooking in git.git (Apr 2017, #04; Wed, 19)

Jeff King writes: >> if (!ret && opts->keep_locked) >> -; >> +; /* --lock wants to keep "locked" file */ >> else >> unlink_or_warn(sb.buf); > > I know this is just a drive-by comment, but given that the "else" is the >

Re: What's cooking in git.git (Apr 2017, #04; Wed, 19)

Duy Nguyen writes: > Looking good. I would add some comment, lest ';' feel lonely. But it's > really personal taste. ... which matches mine. Thanks for the update (which I'll squash in). > > -- 8< -- > diff --git a/builtin/worktree.c b/builtin/worktree.c > index

Re: What's cooking in git.git (Apr 2017, #04; Wed, 19)

On 04/20, Johannes Schindelin wrote: > Hi Lars & Junio, > > On Thu, 20 Apr 2017, Lars Schneider wrote: > > > > * bw/forking-and-threading (2017-04-19) 11 commits > > > - run-command: block signals between fork and execve > > > - run-command: add note about forking and threading > > > -

Re: What's cooking in git.git (Apr 2017, #04; Wed, 19)

On Thu, Apr 20, 2017 at 04:59:21PM +0700, Duy Nguyen wrote: > On Wed, Apr 19, 2017 at 10:37:21PM -0700, Junio C Hamano wrote: > > * nd/worktree-add-lock (2017-04-16) 2 commits > > - SQUASH??? > > - worktree add: add --lock option > > > > Allow to lock a worktree immediately after it's

Re: What's cooking in git.git (Apr 2017, #04; Wed, 19)

Sorry for sending this email multiple times. My mobile email client created html... Should be fixed now! > > * ls/filter-process-delayed (2017-03-06) 1 commit > - convert: add "status=delayed" to filter process protocol > > What's the status of this one??? > cf.

Re: What's cooking in git.git (Apr 2017, #04; Wed, 19)

Hi Lars & Junio, On Thu, 20 Apr 2017, Lars Schneider wrote: > > * bw/forking-and-threading (2017-04-19) 11 commits > > - run-command: block signals between fork and execve > > - run-command: add note about forking and threading > > - run-command: handle dup2 and close errors in child > > -

Re: What's cooking in git.git (Apr 2017, #04; Wed, 19)

On Wed, Apr 19, 2017 at 10:37:21PM -0700, Junio C Hamano wrote: > * nd/worktree-add-lock (2017-04-16) 2 commits > - SQUASH??? > - worktree add: add --lock option > > Allow to lock a worktree immediately after it's created. This helps > prevent a race between "git worktree add; git worktree