From: Felipe Contreras
If a push fails because the remote-helper died (with
fast-export), the user does not see any error message. We do
correctly die with a failed exit code, as we notice that the
helper has died while reading back the ref status from the
helper. However, we don't print any mess
On Wed, Apr 10, 2013 at 2:15 PM, Jeff King wrote:
> From: Felipe Contreras
>
> If a push fails because the remote-helper died (with
> fast-export), the user does not see any error message. We do
> correctly die with a failed exit code, as we notice that the
> helper has died while reading back th
On Wed, Apr 10, 2013 at 5:15 PM, Jeff King wrote:
> From: Felipe Contreras
>
> If a push fails because the remote-helper died (with
> fast-export), the user does not see any error message. We do
> correctly die with a failed exit code, as we notice that the
> helper has died while reading back th
On Wed, Apr 10, 2013 at 4:15 PM, Jeff King wrote:
> From: Felipe Contreras
>
> If a push fails because the remote-helper died (with
> fast-export), the user does not see any error message. We do
> correctly die with a failed exit code, as we notice that the
> helper has died while reading back th
On Thu, Apr 11, 2013 at 08:22:26AM -0500, Felipe Contreras wrote:
> > We
> > currently do so robustly when the helper uses the "done"
> > feature (and that is what we test). We cannot do so
> > reliably when the helper does not use the "done" feature,
> > but it is not even worth testing; the rig
On Thu, Apr 11, 2013 at 11:18 AM, Jeff King wrote:
> On Thu, Apr 11, 2013 at 08:22:26AM -0500, Felipe Contreras wrote:
>
>> > We
>> > currently do so robustly when the helper uses the "done"
>> > feature (and that is what we test). We cannot do so
>> > reliably when the helper does not use the "d
On Thu, Apr 11, 2013 at 11:49:11AM -0500, Felipe Contreras wrote:
> > I am OK with adding the test for import as a separate patch. What I am
> > not OK with (and this goes for the rest of the commit message, too) is
> > failing to explain any back-story at all for why the change is done in
> > the
On Thu, Apr 11, 2013 at 11:59 AM, Jeff King wrote:
> On Thu, Apr 11, 2013 at 11:49:11AM -0500, Felipe Contreras wrote:
>
>> > I am OK with adding the test for import as a separate patch. What I am
>> > not OK with (and this goes for the rest of the commit message, too) is
>> > failing to explain a
Felipe Contreras writes:
> On Wed, Apr 10, 2013 at 4:15 PM, Jeff King wrote:
>> From: Felipe Contreras
>>
>> If a push fails because the remote-helper died (with
>> fast-export), the user does not see any error message. We do
I agree with you that s/does not see/may not see/ would be more
help
Felipe Contreras writes:
> On Thu, Apr 11, 2013 at 11:59 AM, Jeff King wrote:
>
>> But I give up on you. I find most of your commit messages lacking in
>> details and motivation, making assumptions that the reader is as
>> familiar with the code when reading the commit as you are when you wrote
On Thu, Apr 11, 2013 at 1:44 PM, Junio C Hamano wrote:
> Felipe Contreras writes:
>>> In the long run, it may make more sense to propagate the
>>> error back up to push, so that it can present the usual
>>> status table and give a nicer message. But this is a much
>>> simpler fix that can help i
On Thu, Apr 11, 2013 at 1:49 PM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>> On Thu, Apr 11, 2013 at 11:59 AM, Jeff King wrote:
>>
>>> But I give up on you. I find most of your commit messages lacking in
>>> details and motivation, making assumptions that the reader is as
>>> familiar
Felipe Contreras writes:
> And if you must, you might was well label them with "REMINDER", no,
> wait, that's what "TODO" comments are for, where people can see them,
> and not *forget* them.
Yeah, good point.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a me
On Thu, Apr 11, 2013 at 6:05 PM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>> And if you must, you might was well label them with "REMINDER", no,
>> wait, that's what "TODO" comments are for, where people can see them,
>> and not *forget* them.
>
> Yeah, good point.
Moreover, I think th
On Sat, Apr 13, 2013 at 12:42:29AM -0500, Felipe Contreras wrote:
> To me, the reality is obvious: my patch didn't require such a big
> commit message, the short version was fine, the only reason Jeff King
> insisted on a longer version is because the patch came from me.
Get over yourself. The re
On Sat, Apr 13, 2013 at 1:00 AM, Jeff King wrote:
> On Sat, Apr 13, 2013 at 12:42:29AM -0500, Felipe Contreras wrote:
>
>> To me, the reality is obvious: my patch didn't require such a big
>> commit message, the short version was fine, the only reason Jeff King
>> insisted on a longer version is b
Felipe Contreras writes:
> On Sat, Apr 13, 2013 at 1:00 AM, Jeff King wrote:
>> On Sat, Apr 13, 2013 at 12:42:29AM -0500, Felipe Contreras wrote:
>>
>>> To me, the reality is obvious: my patch didn't require such a big
>>> commit message, the short version was fine, the only reason Jeff King
>>>
On Sun, Apr 14, 2013 at 12:23 AM, Junio C Hamano wrote:
> "Double" may only be showing that we do not have enough trusted
> maintainers; ideally I would like it to have "Triple" or more.
A double or triple review raises *a single* standard higher, but
having more than one standard is never good.
18 matches
Mail list logo
