John Keeping :
> > Ah. OK, that is yet another bug inherited from 2.x - the code doesn't
> > match the documented (and correct) behavior. Please send me a patch
> > against the cvsps repo, I'll merge it.
>
> Should now be in your inbox.
Received, merged, tested, and cvsps-3.10 has shipped.
>
On Mon, Jan 21, 2013 at 07:43:40AM -0500, Eric S. Raymond wrote:
> John Keeping :
>> I also disagree that cvsps outputs commits *newer* than T since it will
>> also output commits *at* T, which is what I changed with the patch in my
>> previous message.
>
> Ah. OK, that is yet another bug inherit
John Keeping :
> I also disagree that cvsps outputs commits *newer* than T since it will
> also output commits *at* T, which is what I changed with the patch in my
> previous message.
Ah. OK, that is yet another bug inherited from 2.x - the code doesn't
match the documented (and correct) behavior
On Mon, Jan 21, 2013 at 06:28:53AM -0500, Eric S. Raymond wrote:
> John Keeping :
>> But this is nothing more than a sticking plaster that happens to do
>> enough in this particular case
>
> I'm beginning to think that's the best outcome we ever get in this
> problem domain...
I don't think we ca
John Keeping :
> But this is nothing more than a sticking plaster that happens to do
> enough in this particular case
I'm beginning to think that's the best outcome we ever get in this
problem domain...
>- if the Git repository happened to be on
> a different branch, the start
On Sun, Jan 20, 2013 at 06:20:08PM -0500, Eric S. Raymond wrote:
> John Keeping :
>> I don't think there is any way to solve this without giving cvsps more
>> information, probably the last commit time for all git branches, but
>> perhaps I'm missing a fast-import feature that can help solve this
>
Junio C Hamano writes:
> If you want to abandon cvsps2 users, that is perfectly fine by me.
> As long as cvsps3 and cvsimport-3 combo works, Git before this
> series will have a _working_ cvsimport as far as I am concerned.
The above obviously is "Git _after_ this series".
Git before this serie
"Eric S. Raymond" writes:
> Jonathan Nieder :
>> Junio proposed a transition strategy, but I don't think it's fair to
>> say he has chosen it without discussion or is imposing it on you.
>
> I have said everything I could about the bad effects of encouraging
> people to continue to use cvsps-2.x,
Eric S. Raymond wrote:
> I have said everything I could about the bad effects of encouraging
> people to continue to use cvsps-2.x, it didn't budge Junio an
> inch, and I'm tired of fighting about it.
What I think you misunderstood is that Junio is not the person you
would have needed to convince
Jonathan Nieder :
> Junio proposed a transition strategy, but I don't think it's fair to
> say he has chosen it without discussion or is imposing it on you.
I have said everything I could about the bad effects of encouraging
people to continue to use cvsps-2.x, it didn't budge Junio an
inch, and I
Junio C Hamano writes:
> ..., so I do not think it is a big loss to rely on the same
> assumptions and choose b. from our point of view.
Of course the last sentence is a typo: "choose c." is what I meant.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message
Jonathan Nieder writes:
> Eric S. Raymond wrote:
>
>> You get to integrate this. I think the transition strategy Junio
>> has chosen is seriously mistaken, leading to unnecessary grief for users
>> who will be fooled into thinking it's OK to still use cvsps-2.x.
>
> So our choices are:
>
> a. s
Eric S. Raymond wrote:
> You get to integrate this. I think the transition strategy Junio
> has chosen is seriously mistaken, leading to unnecessary grief for users
> who will be fooled into thinking it's OK to still use cvsps-2.
Ah, I missed a detail on first reading. I think there has been a
Eric S. Raymond wrote:
> You get to integrate this. I think the transition strategy Junio
> has chosen is seriously mistaken, leading to unnecessary grief for users
> who will be fooled into thinking it's OK to still use cvsps-2.x.
So our choices are:
a. support current users, offend ESR, don'
John Keeping :
> I don't think there is any way to solve this without giving cvsps more
> information, probably the last commit time for all git branches, but
> perhaps I'm missing a fast-import feature that can help solve this
> problem.
Yes, you are. The magic incantation is
from refs/head
I've now spent some time looking at git-cvsimport-3.py from
jc/cvsimport-upgrade and made some progress in making it pass more of
the Git test suite (my work in progress is at [1]).
However, I think there is a fundamental problem with the way it handles
incremental imports and I'm hoping someone w
16 matches
Mail list logo
