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

Re: [PATCH v3 0/9] remote-helpers: fixes and cleanups

From
Felipe Contreras <felipe.contreras@gmail.com>
Date
Apr 26, 2013, 22:40 UTC
Message-ID
<CAMP44s2u1iLXKQ5zuif4xKvYREVQm3B+301J=F5CpqPW6E5wWw@mail.gmail.com>
In-Reply-To
<7vsj2due28.fsf@alter.siamese.dyndns.org>
On Fri, Apr 26, 2013 at 5:23 PM, Junio C Hamano <gitster@pobox.com> wrote:
Show 25 quoted lines
> Junio C Hamano <gitster@pobox.com> writes:
>
>> Felipe Contreras <felipe.contreras@gmail.com> writes:
>>
>>> Updated the commit messages, so we say Bazaar instead of Mercurial, and stuff.
>>>
>>> Here's a bunch of cleanups mostly to synchronize remote-bzr and remote-hg.
>>
>> Thanks.  Will queue on 'pu' without looking.
>
> Actually, I was going to merge fc/remote-hg and fc/remote-bzr down
> to master anyway, so I'll just apply them directly on 'master'.
>
> By the way, I personally do not think the quality of the changes to
> remote-bzr matters all that much at this point in its history.  It's
> not like millions of people use it heavily from the v1.8.2 release.
> A huge patch series from its original author and nobody else, either
> reviewed or unreviwed, would not hurt them more than the one in the
> v1.8.2 version anyway. And it is also not like bzr-to-git population
> will grow significantly in the future to require us to pile a lot of
> features on remote-bzr that makes the maintenance burden of it
> becomes an issue.
>
> Am I underestimating the pain of potentially breaking existing
> remote-bzr userbase?

No, I think it's reasonable. 1.8.2 was better because 1.8.1 didn't ave any support whatsoever, and 1.8.3 will be better, because 1.8.2 was barely usable for any real-world project. Will there be any regressions? I doubt it, and if there are, it's unlikely that they would be found in the review process, in 'pu', or in 'next', specially since very few people actually use remote-bzr, in part because it wasn't very useful, and in part because few people use bzr in the first place.

Of course, I would prefer if people reviewed the patches for the massive changes, the _important_ patches, and I would gladly explain the reasoning and update the commit messages if needed. But nobody is volunteering to review that. The only exception was for a few irrelevant patches that could be easily dropped.

remote-hg is a different story, and so I'm being more careful with the changes there, and I actually think the current patches are more than enough for 1.8.3, they should be tested in an actual release, and the rest would have to wait. For the rest, I'm still juggling in which order I should send them, and I want to send first the ones that should maximize the benefits for the users, with minimum possibility of breakage, but even then I wouldn't be confident with those landing in 1.8.3, so 1.8.4 it is.

Cheers.
-- 
Felipe Contreras
Previous: Junio C HamanoNext: Junio C Hamano
Message 13 of 15 in “remote-helpers: fixes and cleanups”
  1. 0/9 remote-helpers: fixes and cleanupsFelipe Contreras, Apr 26, 2013
  2. 1/9 remote-helpers: trivial cleanupsFelipe Contreras, Apr 26, 2013
  3. 2/9 remote-hg: remove extra checkFelipe Contreras, Apr 26, 2013
  4. 3/9 remote-bzr: fix bad state issueFelipe Contreras, Apr 26, 2013
  5. 4/9 remote-bzr: add support to push URLsFelipe Contreras, Apr 26, 2013
  6. 5/9 remote-hg: use hashlib instead of hg sha1 utilFelipe Contreras, Apr 26, 2013
  7. 6/9 remote-bzr: store converted URLFelipe Contreras, Apr 26, 2013
  8. 7/9 remote-bzr: tell bazaar to be quietFelipe Contreras, Apr 26, 2013
  9. 8/9 remote-bzr: strip extra newlineFelipe Contreras, Apr 26, 2013
  10. 9/9 remote-bzr: use proper push methodFelipe Contreras, Apr 26, 2013
  11. Junio C HamanoApr 26, 2013
  12. Junio C HamanoApr 26, 2013
  13. Felipe ContrerasApr 26, 2013
  14. Junio C HamanoApr 26, 2013
  15. Ramkumar RamachandraApr 27, 2013

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.