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

Should git-remote-hg/bzr be part of the core?

From
Felipe Contreras <felipe.contreras@gmail.com>
Date
May 11, 2014, 23:34 UTC
Message-ID
<537008f06ceb8_8e47492f89f@nysa.notmuch>
Hi,

Recently Junio said he was willing to hear the opinion of other people regarding the move from contrib to the core[1]. This move is already under way, but suddenly Junio changed his mind.

I have repeatedly asked him to clarify what argument changed his mind, but he hasn't done so. Hopefully he will do that in this thread, but I'll jump ahead and assume it's this one by John Keeping[2]:

  I do not want to end up in a situation where an update to Git is
  blocked by a distribution because git-remote-hg is not updated to
  support newer versions of Mercurial sufficiently quickly; this
  previously happened in Gentoo due to git-svn and meant that was stuck
  on 1.7.8 until 1.7.13 was released [X].

Now, I feel I addressed this argument at length, specially in this thread [3], but I'll try to provide a summary of the strongest arguments against:

 1) We can make the tests optional, say 't/optional'. So if they don't
    pass, the build of Git is not broken. Additionally, distributions
    might prefer to run test-essential if they don't want to run these
    optional tests.
 
 2) There's already continuous integration builds[4] to make sure all
    the possible incoming changes in Mercurial are detected early on.
 3) There has been a *single* case where a new Mercurial (3.0) broke
    things. This is due to the fact of how I implemented certain
    functionality due to limitations in Mercurial's API. Mercurial
    authors can be contacted to improve the API and minimize the
    possibility of it happening again.

Given these arguments, I don't see how moving git-remote-hg to the core could possibly cause any problems, and I don't understand why Junio would think otherwise. Even if such a breakage causes a problem to the whole Git, it would make sense to demote these tools *when* such a problem comes (which I argue it won't). Does it make sense to you that you get thrown in jail for a crime you haven't committed merely because someone thinks it's likely you will?

Given the huge amount of work I've put in these remote helpers, and the fact that Junio said since day 1 he wanted these in the core[5] (and I was operating under that assumption), I think the demotion back to the contrib area (and therefore out-of-tree) should be made carefully, and not from one day to he next as it happened.

Thoughts?

[1] http://article.gmane.org/gmane.comp.version-control.git/248676 [2] http://article.gmane.org/gmane.comp.version-control.git/248167 [3] http://article.gmane.org/gmane.comp.version-control.git/248683 [4] https://travis-ci.org/felipec/git [5] http://article.gmane.org/gmane.comp.version-control.git/220277

-- 
Felipe Contreras
Next: Michael Haggerty
Message 1 of 19 in “Should git-remote-hg/bzr be part of the core?”
  1. Felipe ContrerasMay 11, 2014
  2. Michael HaggertyMay 12, 2014
  3. Dennis KaarsemakerMay 12, 2014
  4. Felipe ContrerasMay 12, 2014
  5. Michael HaggertyMay 12, 2014
  6. Felipe ContrerasMay 12, 2014
  7. David KastrupMay 12, 2014
  8. Felipe ContrerasMay 12, 2014
  9. Michael HaggertyMay 12, 2014
  10. Felipe ContrerasMay 12, 2014
  11. David KastrupMay 12, 2014
  12. Felipe ContrerasMay 12, 2014
  13. Felipe ContrerasMay 12, 2014
  14. Stefan BellerMay 12, 2014
  15. Felipe ContrerasMay 12, 2014
  16. Felipe ContrerasMay 12, 2014
  17. Paolo CiarrocchiMay 12, 2014
  18. Stefan BellerMay 12, 2014
  19. Felipe ContrerasMay 12, 2014

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.