On Sun, May 5, 2013 at 2:03 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Felipe Contreras <felipe.contreras@xxxxxxxxx> writes: > >> On Sun, May 5, 2013 at 1:33 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: >>> Felipe Contreras <felipe.contreras@xxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html