git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH v4 00/13] New remote-hg helper

From
Felipe Contreras <felipe.contreras@gmail.com>
Date
Oct 31, 2012, 15:58 UTC
Message-ID
<CAMP44s2u=M5RvkM0nsGuYy_BJ=0KSoFmA8Hq=CeumwvHOZYkRQ@mail.gmail.com>
In-Reply-To
<20121031102712.GB30879@sigill.intra.peff.net>
On Wed, Oct 31, 2012 at 11:27 AM, Jeff King <peff@peff.net> wrote:
Show 16 quoted lines
> On Wed, Oct 31, 2012 at 10:30:50AM +0100, Michael J Gruber wrote:
>
>> For the record, Johannes is not the only one being kept from looking at
>> this series (further) by the tone of this discussion. Per hominem
>> attacks are neither professional nor helpful. We prefer to discuss code
>> here, just code. From my comments on an earlier version of your series
>> you can see I've tried. The way other comment threads on this series
>> unfolded made me choose to be a mere by-stander again.
>
> Me too. I really like some of the directions the series is taking, and
> as the maintainer, I'd like to pick it up. 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)?
>From the top of my head:
 * Support for tags
 * Support for bookmarks
 * Support for hg-git compatibility
 * Extensive tests (truly extensive)
 * _Much_ simpler code
 * No dependencies

But let's forget about msysgit, because it's not really clear what series of patches we are talking about. If we want to make a real try, and a real comparison, we need a clear set of patches, which seem to be available only on Max Horn's repo[1].

>   - 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?
Honestly I am not aware of anything we would loose.
>   - 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?

I explained that already. If indeed I was looking at the right commits, then I already sent patches that tackle, or otherwise deal with the very same problems (albet in much simpler way). These patches should have held the code, as they are not _needed_ but merely improving things. The rest of the patches would barely make any difference.

This is of course my guess by reading the code, I have not tried it.

In short, only this patch helps: http://article.gmane.org/gmane.comp.version-control.git/208729

And the rest of the code should work just fine on top of latest git.git.
> 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?

Let me try to summarize the situation: Johannes is not willing to collaborate, and nobody else has offered to push forward the patches in msysgit.

Show 10 quoted lines
> I am not saying that this implementation must be 100% better than the
> msysgit one. I do not want perfect to to be the enemy of good and end up
> with nothing. But at the same time, there really are two competing
> implementations, one of which has received substantially more field use.
> Even though the msysgit one is not in git.git, it seems like the path
> for making it happen exists (even if it has not been followed yet).
> Before merging an alternative implementation, I would want to know what
> we are potentially throwing away from the msysgit side, and make sure
> that we are not following a wrong path that msysgit has already tried
> and found to be lacking.

I also would like somebody to compare the two, so that we can have healthy competition, and hopefully also cooperation. But that doesn't seem to be likely.

So, what to do? Should I be the one making an analysis of that code? Since nobody else is willing to try to compare the two, I don't see many other choices, but when/if my conclusion is that my version is superior, I presume nobody would take my word for it, so what would be the point?

Cheers.
[1] http://github.com/fingolfin/git/tree/remote-hg

-- Felipe Contreras

Previous: Jeff KingNext: Johannes Schindelin
Message 29 of 75 in “New remote-hg helper”
  1. 00/13 New remote-hg helperFelipe Contreras, Oct 28, 2012
  2. 01/13 Add new remote-hg transport helperFelipe Contreras, Oct 28, 2012
  3. 02/13 remote-hg: add support for bookmarksFelipe Contreras, Oct 28, 2012
  4. 03/13 remote-hg: add support for pushingFelipe Contreras, Oct 28, 2012
  5. 04/13 remote-hg: add support for remote pushingFelipe Contreras, Oct 28, 2012
  6. 05/13 remote-hg: add support to push URLsFelipe Contreras, Oct 28, 2012
  7. 06/13 remote-hg: make sure the encoding is correctFelipe Contreras, Oct 28, 2012
  8. 07/13 remote-hg: match hg merge behaviorFelipe Contreras, Oct 28, 2012
  9. 08/13 remote-hg: add support for hg-git compat modeFelipe Contreras, Oct 28, 2012
  10. 09/13 remote-hg: add compat for hg-git author fixesFelipe Contreras, Oct 28, 2012
  11. 10/13 remote-hg: fake bookmark when there's noneFelipe Contreras, Oct 28, 2012
  12. 11/13 remote-hg: add support for fake remoteFelipe Contreras, Oct 28, 2012
  13. 12/13 remote-hg: add tests to compare with hg-gitFelipe Contreras, Oct 28, 2012
  14. 13/13 remote-hg: add extra author testFelipe Contreras, Oct 28, 2012
  15. Jeff KingOct 29, 2012
  16. Felipe ContrerasOct 29, 2012
  17. Jeff KingOct 29, 2012
  18. Felipe ContrerasOct 29, 2012
  19. Jeff KingOct 29, 2012
  20. Felipe ContrerasOct 29, 2012
  21. Jeff KingOct 29, 2012
  22. Felipe ContrerasOct 30, 2012
  23. Johannes SchindelinOct 30, 2012
  24. Felipe ContrerasOct 30, 2012
  25. Johannes SchindelinOct 30, 2012
  26. Felipe ContrerasOct 30, 2012
  27. Michael J GruberOct 31, 2012
  28. Jeff KingOct 31, 2012
  29. Felipe ContrerasOct 31, 2012
  30. Johannes SchindelinOct 31, 2012
  31. Felipe ContrerasOct 31, 2012
  32. Jonathan NiederOct 31, 2012
  33. Felipe ContrerasOct 31, 2012
  34. Lack of netiquette, was Re: [PATCH v4 00/13] New remote-hg helperJohannes Schindelin, Oct 31, 2012
  35. Felipe ContrerasOct 31, 2012
  36. Junio C HamanoNov 1, 2012
  37. Felipe ContrerasNov 1, 2012
  38. René ScharfeNov 1, 2012
  39. Tomas CarneckyNov 1, 2012
  40. Martin LanghoffNov 1, 2012
  41. Felipe ContrerasNov 1, 2012
  42. Martin LanghoffNov 1, 2012
  43. Felipe ContrerasNov 1, 2012
  44. Andreas EricssonNov 2, 2012
  45. Michael J GruberNov 2, 2012
  46. Felipe ContrerasNov 2, 2012
  47. Michael J GruberNov 5, 2012
  48. Felipe ContrerasNov 5, 2012
  49. Felipe ContrerasNov 5, 2012
  50. Michael J GruberNov 5, 2012
  51. Felipe ContrerasNov 5, 2012
  52. Jonathan NiederNov 1, 2012
  53. Daniel BarkalowOct 31, 2012
  54. Felipe ContrerasNov 1, 2012
  55. Junio C HamanoNov 1, 2012
  56. Felipe ContrerasNov 1, 2012
  57. Felipe ContrerasOct 31, 2012
  58. Michael J GruberOct 31, 2012
  59. Felipe ContrerasOct 31, 2012
  60. Jeff KingNov 2, 2012
  61. Felipe ContrerasNov 2, 2012
  62. Felipe ContrerasNov 2, 2012
  63. Felipe ContrerasNov 4, 2012
  64. Thomas AdamNov 2, 2012
  65. Felipe ContrerasNov 2, 2012
  66. Felipe ContrerasOct 31, 2012
  67. Felipe ContrerasOct 31, 2012
  68. Felipe ContrerasNov 1, 2012
  69. Jeff KingNov 2, 2012
  70. Felipe ContrerasNov 2, 2012
  71. Felipe ContrerasNov 2, 2012
  72. Michael J GruberNov 5, 2012
  73. Felipe ContrerasNov 5, 2012
  74. Junio C HamanoNov 1, 2012
  75. Felipe ContrerasNov 1, 2012

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.