Hi Peff,
On Wed, 31 Oct 2012, Jeff King wrote:
> I really like some of the directions the series is taking, and as the
> maintainer, I'd like to pick it up.
Code-wise, I agree.
> But there is a big question mark for me still about how it relates to
> the work in msysgit, especially:
>
> - What advantages does this implementation have over the one in
> msysgit (i.e., new features that the other one does not have)?
Disclaimer: I do not know the details (as I said, I have higher priorities
elsewhere since the remote-hg I need for everyday work continues to do its
job, and the patch series bringing Python to msysGit is more pressing,
and I will enjoy its review much more, too).
The biggest advantage seems to me that it was started later than msysGit's
remote-hg and as such could potentially exploit recent improvements in
git.git.
> - What disadvantages? If this implementation goes into git.git,
> the msysgit one is likely to wane in popularity. What will we be
> losing by doing so? If the answer is not "nothing", how hard would
> it be to port over the missing bits?
The biggest advantage msysGit's series has is that it had a fix for a
fundamental flaw in fast-export. Fast-export was intended to work
incrementally, so the incantation "git branch blub master && git
fast-export ^master blub" is expected to update the ref "blub" properly.
I just tested this with junio/next and it seems this issue is still
unfixed: instead of
reset refs/heads/blub
from e7510461b7db54b181d07acced0ed3b1ada072c8
I get
reset refs/heads/blub
from :0
when running "git fast-export ^master blub".
Having said that, we have no problem to throw away the fix that was
rejected by Junio (who wanted something much more general which I refused
to implement both due to lack of time and lack of need -- think YAGNI) and
rebase our stuff on top of whatever goes into git.git's next (or master,
we are still deciding in the msysGit project whether we should stop
tracking next).
Another thing that I really like about remote-hg as it is in msysGit is
that it was designed with extensibility in mind. It should not be too hard
to support other fast-import/export based backends using that
infrastructure. I am particularly interested in bzr myself, but there is
no day-job related project I could use as an excuse to give that project
a higher priority that the other things I am doing at the moment.
> - The msysgit one got held up by fixes needed for fast-export. Why
> aren't those a problem for this implementation? If we are using a
> different strategy that avoids the issue, what are the limitations (if
> any) of that strategy?
Junio wanted a more general solution, adding infrastructure to the
rev-list engine that I did not need -- and did not see the need for,
either -- and given the amount of time I had invested in a working
remote-hg and given that I needed it desperately for my day-job project, I
decided to just put it into msysGit and give up my hopes for it to become
official.
It has worked well in the meantime and met my needs. The only thing
missing is the support for octopus merges. But I would need that only to
satisfy my geek self: I would set up an automatic Hg mirror of git.git
itself on bitbucket.
> I have a feeling that some of those answers are buried deep within the
> discussion, but I have had a hard time following all of the back and
> forth due to the volume and tone of the discussion. Are we at a point
> now where some of the participants can try to summarize the situation?
Hopefully my attempt met your expectations.
Thank you,
Dscho
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
