Felipe Contreras writes:
> David Kastrup wrote:
>> Shouting "your God is an imaginary shithead" every time you see Mark
>
> There's no point in discussing with an unconstructive person as you.
So go to a constructive person you call your friend and show him one of
your calm rational mails and as
David Kastrup wrote:
> Shouting "your God is an imaginary shithead" every time you see Mark
There's no point in discussing with an unconstructive person as you.
I've made my point, you are just talking nonsense.
Every rational person on this list knows that if I wanted to, I could be
much more of
David Kastrup writes:
>>> I'm not entirely convinced of that: there is something akin to drop-dead
>>> gorgeous code: code that is so well done that it would not matter with
>>> regard to its maintenance whether or not its author dropped dead because
>>> it's both done well as well as documented
Junio C Hamano writes:
> David Kastrup writes:
>
>> Philippe Vaucher writes:
>>
>>> Thanks for the explanation. I think it underlines well the A)
>>> technical issues (quality commits) and the B) social issues (ability
>>> to communicate in a friendly way & respond constructively), which we
>>>
David Kastrup writes:
> Philippe Vaucher writes:
>
>> Thanks for the explanation. I think it underlines well the A)
>> technical issues (quality commits) and the B) social issues (ability
>> to communicate in a friendly way & respond constructively), which we
>> discovered are both *essential* f
Felipe Contreras writes:
> David Kastrup wrote:
>> Felipe Contreras writes:
>>
>> > Philippe Vaucher wrote:
>>
>> [...]
>>
>> >> > Do you feel Felipe is in control of what you label bad behavior? Do you
>> >> > feel you are in control over how you react to his behavior?
>> >>
>> >> I feel t
David Kastrup wrote:
> Felipe Contreras writes:
>
> > Philippe Vaucher wrote:
>
> [...]
>
> >> > Do you feel Felipe is in control of what you label bad behavior? Do you
> >> > feel you are in control over how you react to his behavior?
> >>
> >> I feel that Felipe cannot control this (or deci
Felipe Contreras writes:
> Philippe Vaucher wrote:
[...]
>> > Do you feel Felipe is in control of what you label bad behavior? Do you
>> > feel you are in control over how you react to his behavior?
>>
>> I feel that Felipe cannot control this (or decided not to),
>
> I am pretty much in cont
Philippe Vaucher wrote:
> >> I'm sorry that my words aren't clear enough for you to infer the point
> >> I'm trying to make. Let's try something simpler: what I was saying is
> >> that bad behavior will get you into trouble when contributing (and
> >> thus it's important to behave nicely), where Fe
>> I'm sorry that my words aren't clear enough for you to infer the point
>> I'm trying to make. Let's try something simpler: what I was saying is
>> that bad behavior will get you into trouble when contributing (and
>> thus it's important to behave nicely), where Felipe usualy says bad
>> behavior
Philippe Vaucher writes:
> I'm sorry that my words aren't clear enough for you to infer the point
> I'm trying to make. Let's try something simpler: what I was saying is
> that bad behavior will get you into trouble when contributing (and
> thus it's important to behave nicely), where Felipe usua
>> My point was more that it's very hard to produce high quality commits
>> without social interaction with others explaining what you missed,
>> stuffs you overlooked, etc.
>
> You are overgeneralizing. You are assuming that it's easier for
> everybody to interact with humans rather than the Tao
Philippe Vaucher writes:
>> Basically you have to write in a manner "if a seedy stranger gave me
>> that code on a street corner, I would have no problem checking it
>> in". In practice, the shortcuts offering themselves through civil
>> behavior and mutual trust get a lot more work done.
>
> My
> Basically you have to write in a manner "if a seedy stranger gave me
> that code on a street corner, I would have no problem checking it in".
> In practice, the shortcuts offering themselves through civil behavior
> and mutual trust get a lot more work done.
My point was more that it's very hard
Philippe Vaucher writes:
>>> Thanks for the explanation. I think it underlines well the A)
>>> technical issues (quality commits) and the B) social issues (ability
>>> to communicate in a friendly way & respond constructively), which we
>>> discovered are both *essential* for contributing to git.
>> Thanks for the explanation. I think it underlines well the A)
>> technical issues (quality commits) and the B) social issues (ability
>> to communicate in a friendly way & respond constructively), which we
>> discovered are both *essential* for contributing to git.
>
> I'm not entirely convinced
Philippe Vaucher writes:
> Thanks for the explanation. I think it underlines well the A)
> technical issues (quality commits) and the B) social issues (ability
> to communicate in a friendly way & respond constructively), which we
> discovered are both *essential* for contributing to git.
I'm no
>>> It is *way* beyond the quality of any other tool in 'contrib/' and even
>>> some tools in the core, like 'git-request-pull' (which has known bugs),
>>> and probably even 'git-pt'.
>>
>> Junio, can you comment on this? I understand this probably doesn't
>> really affect the issue at hand, but it
Junio C Hamano wrote:
> Felipe Contreras writes:
>
> > Junio C Hamano wrote:
> > ...
> >> I was originally led to believe that its code quality was good
> >> enough, and that was why I merged the bottom three patches of the
> >> series even down to 'next' in the first place. But after seeing the
Felipe Contreras writes:
> Junio C Hamano wrote:
> ...
>> I was originally led to believe that its code quality was good
>> enough, and that was why I merged the bottom three patches of the
>> series even down to 'next' in the first place. But after seeing the
>> "Of course" response that led to
Junio C Hamano wrote:
> Philippe Vaucher writes:
>
> >> It is *way* beyond the quality of any other tool in 'contrib/' and even
> >> some tools in the core, like 'git-request-pull' (which has known bugs),
> >> and probably even 'git-pt'.
> >
> > Junio, can you comment on this? I understand this p
Philippe Vaucher writes:
>> It is *way* beyond the quality of any other tool in 'contrib/' and even
>> some tools in the core, like 'git-request-pull' (which has known bugs),
>> and probably even 'git-pt'.
>
> Junio, can you comment on this? I understand this probably doesn't
> really affect the
Nevermind, it'd be more efficient to cover this in the other main
thread started by Felipe. You can answer my questions there instead as
it'll likely benefit a wider audience.
Philippe
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kern
> I addressed every issue reported constructively, every bug report was
> fixed, every patch reviewed and usually improved by me. I made sure
> users of older versions wouldn't be affected negatively when the marks
> file was upgraded, and I even setup automatic tests for different
> versions Bazaa
Junio C Hamano wrote:
> Felipe Contreras writes:
>
> > Junio C Hamano wrote:
> >> Felipe Contreras writes:
> >>
> >> > I already said this multiple times, but let me be clear once more:
> >> >
> >> > MASTER HAS A REGRESSION (for all versions of Mercurial).
> >>
> >> As you said, that is not a
Felipe Contreras writes:
> Junio C Hamano wrote:
>> Felipe Contreras writes:
>>
>> > I already said this multiple times, but let me be clear once more:
>> >
>> > MASTER HAS A REGRESSION (for all versions of Mercurial).
>>
>> As you said, that is not a regression, isn't it? It is an old
>> bre
Felipe Contreras wrote:
> Junio C Hamano wrote:
> > I do not see a strong reason to move it out of contrib, either.
>
> Really? So why did you say this?[2]
>
> > > Either way, I think if things go well, remote-hg will prove it's
> > > worth and move out of contrib and into git's core.
> >
> > T
Junio C Hamano wrote:
> Felipe Contreras writes:
>
> > I already said this multiple times, but let me be clear once more:
> >
> > MASTER HAS A REGRESSION (for all versions of Mercurial).
>
> As you said, that is not a regression, isn't it? It is an old
> breakage that existed even before 1.9 (w
Felipe Contreras writes:
> I already said this multiple times, but let me be clear once more:
>
> MASTER HAS A REGRESSION (for all versions of Mercurial).
As you said, that is not a regression, isn't it? It is an old
breakage that existed even before 1.9 (was it 1.8.3 or something?)
>> If you
Junio C Hamano wrote:
> > I don't want to do anything for a "contrib" tool.
> >
> > It's already broken in v2.0 anyway.
>
> Yes, this is not even an old regression.
Yes it is. It has nothing to do with with Mercurial v3.0, that's a
separate issue. We've been doing a workaround since v1.8.3, and
Felipe Contreras writes:
> Junio C Hamano wrote:
>> In other words, I knew that you are capable enough to track down a
>> bug in the code you wrote recently that made it violate the
>> expectation you defined in your own tests.
>
> Wrong. The code in question was not recent, it was introdued in 1
James Denholm wrote:
> Felipe, I would ask, suggest, beg, implore you to calm down.
I am calmed down. I waited a day before replying to make sure of that.
> It's generally not a good plan to alienate the maintainer of a
> project, regardless of the correctness or incorrectness of one's
> argument
Junio C Hamano wrote:
> In other words, I knew that you are capable enough to track down a
> bug in the code you wrote recently that made it violate the
> expectation you defined in your own tests.
Wrong. The code in question was not recent, it was introdued in 1.8.3,
more than one year ago.
And
Felipe Contreras writes:
>> There may be some other changes that this series depends on that I
>> may have missed that caused this breakage. Can you take a look?
>
> I'm such a bad maintainer and I don't take constructive criticism well
> why would you expect me to take a look?
Because this was
Junio C Hamano wrote:
> Junio C Hamano writes:
>
> > Felipe Contreras writes:
> >
> >> Here's a bunch of tests more, and a fixes for Mercurial v3.0.
> >
> > I think the discussion with John Keeping hints that we shouldn't be
> > rushing fc/remote-helpers-hg-bzr-graduation and this does not appea
Felipe, I would ask, suggest, beg, implore you to calm down. It's
generally not a good plan to alienate the maintainer of a project,
regardless of the correctness or incorrectness of one's arguments, but I
fear that's only what you will achieve at the moment.
--
Regards,
James Denholm.
--
To unsub
Junio C Hamano wrote:
> Felipe Contreras writes:
>
> > And you are still conveniently avoiding the question:
> >
> > Based on what reasoning?
>
> Go re-read what was already said in the thread.
I already read it, and I already responded.
> I still think remote-hg and remote-bzr can and will fl
Junio C Hamano writes:
> Felipe Contreras writes:
>
>> Here's a bunch of tests more, and a fixes for Mercurial v3.0.
>
> I think the discussion with John Keeping hints that we shouldn't be
> rushing fc/remote-helpers-hg-bzr-graduation and this does not appear
> to assume the presense of that ser
Felipe Contreras writes:
> And you are still conveniently avoiding the question:
>
> Based on what reasoning?
Go re-read what was already said in the thread. I still think
remote-hg and remote-bzr can and will flourish on their own merit,
and unbundling will be better for the end users for the
Junio C Hamano wrote:
> Felipe Contreras writes:
> > Really? Based on what reasoning? I have proven his reasoning to be
> > basically wrong.
>
> Perhaps s/proven/convinced myself only/; you didn't prove it to me
> and I doubt you proved it to John.
And you are still conveniently avoiding the que
Felipe Contreras writes:
> Junio C Hamano wrote:
>> Felipe Contreras writes:
>>
>> > Here's a bunch of tests more, and a fixes for Mercurial v3.0.
>>
>> I think the discussion with John Keeping hints that we shouldn't be
>> rushing fc/remote-helpers-hg-bzr-graduation
>
> Really? Based on what
Junio C Hamano wrote:
> Felipe Contreras writes:
>
> > Here's a bunch of tests more, and a fixes for Mercurial v3.0.
>
> I think the discussion with John Keeping hints that we shouldn't be
> rushing fc/remote-helpers-hg-bzr-graduation
Really? Based on what reasoning? I have proven his reasoning
Felipe Contreras writes:
> Here's a bunch of tests more, and a fixes for Mercurial v3.0.
I think the discussion with John Keeping hints that we shouldn't be
rushing fc/remote-helpers-hg-bzr-graduation and this does not appear
to assume the presense of that series, which is good in order to
make
Here's a bunch of tests more, and a fixes for Mercurial v3.0.
Felipe Contreras (4):
remote-hg: add more tests
t: remote-hg: add file operation tests
t: remote-hg: trivial cleanups and fixes
remote-hg: add support for hg v3.0
contrib/remote-helpers/git-remote-hg | 6 +-
contrib/remote-
44 matches
Mail list logo
