Re: [PATCH v2 0/2] remote-bzr: couple of fixes
- From
Junio C Hamano <gitster@pobox.com>
- Date
- May 5, 2013, 19:03 UTC
- Message-ID
- <7v4nehuu3o.fsf@alter.siamese.dyndns.org>
- In-Reply-To
- <CAMP44s1D7LOhDGkZguosPiXyuJ5cP2hmgq4AWagwadrJYK1Pgg@mail.gmail.com>
Felipe Contreras <felipe.contreras@gmail.com> writes:
Show 34 quoted lines
> 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'?