Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'. The ones marked with '.' do not appear in any of
the integration branches, but I am still holding onto them.
An early preview for the upcoming
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 loc
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
> > - run-co
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.
posted v3 here:
https://public
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 created.
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
> > > - run-comman
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 5ebdcce793..bc75676bf3 100644
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
> only thing that doe
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 the status of this one???
>>
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: eliminate calls to error handling f
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 n
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 signals between fork and
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
> >> - run-command: handle dup2 and close er
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 topic branches, I
> have anoth
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 test all
> > merge bases first)
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
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 have is the
> branch name.
>
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 changes come into the integration
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.
> >
> > Please note that this is
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 orthogonal to that style, suggesting
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
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,
>> > typically at the very end of your work day. The idea of Conti
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.
That's a tangent, but I have neve
Æ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 configurable trickle.
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 understood why thi
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 brought
> together, it should
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.
That's a tang
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, but there are mu
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
requires a full build.
29 matches
Mail list logo