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

Re: [PATCH v2 0/2] remote-bzr: couple of fixes

From
Felipe Contreras <felipe.contreras@gmail.com>
Date
May 5, 2013, 20:24 UTC
Message-ID
<CAMP44s3JtLzE0vne5VH+bHrLvSuOwaWwuGa7DFggjEOt6ixgTA@mail.gmail.com>
In-Reply-To
<7v4nehuu3o.fsf@alter.siamese.dyndns.org>
On Sun, May 5, 2013 at 2:03 PM, Junio C Hamano <gitster@pobox.com> wrote:
Show 39 quoted lines
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> On Sun, May 5, 2013 at 1:33 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>> Felipe Contreras <felipe.contreras@gmail.com> writes:
>>>
>>>> The previous version had an indentation bug (did I mention I hate python?).
>>>>
>>>> A few fixes to be applied on top of the massive changes already queued. Nothing
>>>> major.
>>>
>>> [2/2] may not matter much in the context of my tree (people would
>>> use post 1.8.2 fast-export if they are using remote-bzr from 1.8.3
>>> from my tree ;-),
>>
>> Maybe, but if even if they have the latest git, pushing a tag will
>> fail miserably, and with the patch it would fail nicely :)
>>
>>> but [1/2] sounds like it is a good thing to have
>>> in 1.8.3 (not "on top of that 'massive' series").
>>>
>>> Assuming the "otherwise some version of bzr might barf" problem is
>>> that repo.generate_revision_history() in those versions may not
>>> apply str() to its first parameter and the caller is expected to
>>> pass a string there, or something?
>>
>> No, there's no change to repo.generate_revision_history(), because we
>> already convert the elements of the array to strings, it's the other
>> callers of Marks::to_rev() that see a change, namely code that pushes
>> to a remote, I think.
>>
>> And BTW, they are already strings, but unicode strings, because they
>> come from a json file, somehow bazaar doesn't like that, but it works
>> fine in my machine without the patch. Shrugs.
>>
>> Also, the emacs developers seem to be fine with all these changes,
>> there's only one patch pending that I need to cleanup.
>
> So do you want to queue these on top of the "massive" in 'next', not
> directly on 'master'?

If they apply on master, master. But I'm confused, are the massive changes not going to graduate to master? Because if not, I should cherry-pick the safest changes, as there's a lot of good stuff there.

-- 
Felipe Contreras
Previous: Junio C HamanoNext: Junio C Hamano
Message 8 of 10 in “remote-bzr: couple of fixes”
  1. 0/2 remote-bzr: couple of fixesFelipe Contreras, May 4, 2013
  2. 1/2 remote-bzr: convert all unicode keys to strFelipe Contreras, May 4, 2013
  3. 2/2 remote-bzr: avoid bad refsFelipe Contreras, May 4, 2013
  4. Stefano LattariniMay 4, 2013
  5. Junio C HamanoMay 5, 2013
  6. Felipe ContrerasMay 5, 2013
  7. Junio C HamanoMay 5, 2013
  8. Felipe ContrerasMay 5, 2013
  9. Junio C HamanoMay 5, 2013
  10. Felipe ContrerasMay 5, 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.