Message ID | pull.463.v5.git.1575740863.gitgitgadget@gmail.com (mailing list archive) |
---|---|
Headers | show |
Series | git-p4.py: Cast byte strings to unicode strings in python3 | expand |
On Sat, Dec 07, 2019 at 05:47:28PM +0000, Ben Keene via GitGitGadget wrote: > Ben Keene (13): > git-p4: select P4 binary by operating-system > git-p4: change the expansion test from basestring to list > git-p4: promote encodeWithUTF8() to a global function > git-p4: remove p4_write_pipe() and write_pipe() return values > git-p4: add new support function gitConfigSet() > git-p4: add casting helper functions for python 3 conversion > git-p4: python 3 syntax changes > git-p4: fix assumed path separators to be more Windows friendly > git-p4: add Py23File() - helper class for stream writing > git-p4: p4CmdList - support Unicode encoding > git-p4: support Python 3 for basic P4 clone, sync, and submit (t9800) > git-p4: added --encoding parameter to p4 clone > git-p4: Add depot manipulation functions > > Jeff King (2): > t/gitweb-lib.sh: drop confusing quotes > t/gitweb-lib.sh: set $REQUEST_URI Hmm, looks like rebasing leftovers. :) I think we can probably drop these first two? -Peff
Yes indeed! I hadn't pulled before I attempted the rebase, and got bit. Yes those shouldn't be there! On 12/7/2019 2:47 PM, Jeff King wrote: > On Sat, Dec 07, 2019 at 05:47:28PM +0000, Ben Keene via GitGitGadget wrote: > >> Ben Keene (13): >> git-p4: select P4 binary by operating-system >> git-p4: change the expansion test from basestring to list >> git-p4: promote encodeWithUTF8() to a global function >> git-p4: remove p4_write_pipe() and write_pipe() return values >> git-p4: add new support function gitConfigSet() >> git-p4: add casting helper functions for python 3 conversion >> git-p4: python 3 syntax changes >> git-p4: fix assumed path separators to be more Windows friendly >> git-p4: add Py23File() - helper class for stream writing >> git-p4: p4CmdList - support Unicode encoding >> git-p4: support Python 3 for basic P4 clone, sync, and submit (t9800) >> git-p4: added --encoding parameter to p4 clone >> git-p4: Add depot manipulation functions >> >> Jeff King (2): >> t/gitweb-lib.sh: drop confusing quotes >> t/gitweb-lib.sh: set $REQUEST_URI > Hmm, looks like rebasing leftovers. :) I think we can probably drop > these first two? > > -Peff
Ben Keene <seraphire@gmail.com> writes: > Yes indeed! > > I hadn't pulled before I attempted the rebase, and got bit. Yes those > shouldn't be there! So, other than that, this is ready to be at least queued on 'pu' if not 'next' at this point? Thanks.
On Wed, Dec 11, 2019 at 08:54:49AM -0800, Junio C Hamano wrote: > Ben Keene <seraphire@gmail.com> writes: > > > Yes indeed! > > > > I hadn't pulled before I attempted the rebase, and got bit. Yes those > > shouldn't be there! > > So, other than that, this is ready to be at least queued on 'pu' if > not 'next' at this point? From what I can tell, Ben agreed to have this series superseded by Yang Zhao's competing series[1]. That being said, I haven't been following along too closely but it seems to me this series is further along and has received more review feedback so maybe it should be picked up? [1]: https://lore.kernel.org/git/afa761cf-9c0e-cdcc-9c32-be88c5507042@gmail.com/
Denton Liu <liu.denton@gmail.com> writes: > On Wed, Dec 11, 2019 at 08:54:49AM -0800, Junio C Hamano wrote: >> Ben Keene <seraphire@gmail.com> writes: >> >> > Yes indeed! >> > >> > I hadn't pulled before I attempted the rebase, and got bit. Yes those >> > shouldn't be there! >> >> So, other than that, this is ready to be at least queued on 'pu' if >> not 'next' at this point? > > From what I can tell, Ben agreed to have this series superseded by Yang > Zhao's competing series[1]. OK. Let me not worry about this one, then, at least not yet.
On Wed, 11 Dec 2019 at 17:57, Junio C Hamano <gitster@pobox.com> wrote: > > Denton Liu <liu.denton@gmail.com> writes: > > > On Wed, Dec 11, 2019 at 08:54:49AM -0800, Junio C Hamano wrote: > >> Ben Keene <seraphire@gmail.com> writes: > >> > >> > Yes indeed! > >> > > >> > I hadn't pulled before I attempted the rebase, and got bit. Yes those > >> > shouldn't be there! > >> > >> So, other than that, this is ready to be at least queued on 'pu' if > >> not 'next' at this point? > > > > From what I can tell, Ben agreed to have this series superseded by Yang > > Zhao's competing series[1]. > > OK. Let me not worry about this one, then, at least not yet. > Oh, I hadn't seen Yang's python3 changes! What do we need to do to get these ready for merging?
Luke Diamand <luke@diamand.org> writes: > On Wed, 11 Dec 2019 at 17:57, Junio C Hamano <gitster@pobox.com> wrote: >> >> Denton Liu <liu.denton@gmail.com> writes: >> >> > On Wed, Dec 11, 2019 at 08:54:49AM -0800, Junio C Hamano wrote: >> >> Ben Keene <seraphire@gmail.com> writes: >> >> >> >> > Yes indeed! >> >> > >> >> > I hadn't pulled before I attempted the rebase, and got bit. Yes those >> >> > shouldn't be there! >> >> >> >> So, other than that, this is ready to be at least queued on 'pu' if >> >> not 'next' at this point? >> > >> > From what I can tell, Ben agreed to have this series superseded by Yang >> > Zhao's competing series[1]. >> >> OK. Let me not worry about this one, then, at least not yet. >> > > Oh, I hadn't seen Yang's python3 changes! I haven't been paying attention to them either. The patches I started commenting on from Ben were easy to read and understand, and I didn't even know until Denton pointed out that Ben's series yielded the way. > What do we need to do to get these ready for merging? Somebody needs to take the ownership of the topic---we cannot afford to have two independently made topics competing reviewers' attention. If Ben wants to drop his version and instead wants to use Yang's ones, that's OK but Ben probably is in a lot better position than bystanders like me to review and comment on Yang's to suggest improvements, if he hasn't done so. The same for those who reviewed Ben's series earlier. It would make sure that the single topic a combined effort to produce the best of both topics. If there is something Ben's patches did that is lacking in Yang's, it may be worth rebuilding it on top of Yang's series.
On Wed, Dec 11, 2019 at 1:46 PM Junio C Hamano <gitster@pobox.com> wrote: > > Luke Diamand <luke@diamand.org> writes: > > > On Wed, 11 Dec 2019 at 17:57, Junio C Hamano <gitster@pobox.com> wrote: > >> > >> Denton Liu <liu.denton@gmail.com> writes: > >> > >> > On Wed, Dec 11, 2019 at 08:54:49AM -0800, Junio C Hamano wrote: > >> > From what I can tell, Ben agreed to have this series superseded by Yang > >> > Zhao's competing series[1]. > >> > >> OK. Let me not worry about this one, then, at least not yet. > >> > > > > Oh, I hadn't seen Yang's python3 changes! ... > > What do we need to do to get these ready for merging? > > Somebody needs to take the ownership of the topic---we cannot afford > to have two independently made topics competing reviewers' attention. > > If Ben wants to drop his version and instead wants to use Yang's > ones, that's OK but Ben probably is in a lot better position than > bystanders like me to review and comment on Yang's to suggest > improvements, if he hasn't done so. The same for those who reviewed > Ben's series earlier. > > It would make sure that the single topic a combined effort to > produce the best of both topics. If there is something Ben's > patches did that is lacking in Yang's, it may be worth rebuilding it > on top of Yang's series. Sorry about the bit of communication mess there. I should have paid more attention to who were chiming in to Ben's series and added CCs appropriately. The timing was definitely a bit awkward as we were both only dedicating part of work-time to the patchsets. The outcome of discussion between Ben and I were that it made the most sense to use my set as the base to rebuild his quality-of-life changes. My patchset (plus one missing change I've not sent out yet) will pass all existing tests. I will take ownership of this merge, probably as a separate patchset.
On 12/11/2019 5:30 PM, Yang Zhao wrote: > On Wed, Dec 11, 2019 at 1:46 PM Junio C Hamano <gitster@pobox.com> wrote: >> Luke Diamand <luke@diamand.org> writes: >> >>> On Wed, 11 Dec 2019 at 17:57, Junio C Hamano <gitster@pobox.com> wrote: >>>> Denton Liu <liu.denton@gmail.com> writes: >>>> >>>>> On Wed, Dec 11, 2019 at 08:54:49AM -0800, Junio C Hamano wrote: >>>>> From what I can tell, Ben agreed to have this series superseded by Yang >>>>> Zhao's competing series[1]. >>>> OK. Let me not worry about this one, then, at least not yet. >>>> >>> Oh, I hadn't seen Yang's python3 changes! > ... >>> What do we need to do to get these ready for merging? >> Somebody needs to take the ownership of the topic---we cannot afford >> to have two independently made topics competing reviewers' attention. >> >> If Ben wants to drop his version and instead wants to use Yang's >> ones, that's OK but Ben probably is in a lot better position than >> bystanders like me to review and comment on Yang's to suggest >> improvements, if he hasn't done so. The same for those who reviewed >> Ben's series earlier. >> >> It would make sure that the single topic a combined effort to >> produce the best of both topics. If there is something Ben's >> patches did that is lacking in Yang's, it may be worth rebuilding it >> on top of Yang's series. > Sorry about the bit of communication mess there. I should have paid > more attention to who were chiming in to Ben's series and added CCs > appropriately. The timing was definitely a bit awkward as we were both > only dedicating part of work-time to the patchsets. Sorry for the silence, I was heads down on another issue at work. I had tried to pull Yang's work down to my machine and had trouble getting it to run under my configuration but I think I had a mixed environment. I'm going to reset everything on my machine and try again. Since I'm not a python developer and I won't be able to devote the overall time that Yang will, I'm deferring the changeset to Yang's code. I posted the code so that the work that I had done would be visible, I didn't mean to cause the cross-talk! > > The outcome of discussion between Ben and I were that it made the most > sense to use my set as the base to rebuild his quality-of-life > changes. My patchset (plus one missing change I've not sent out yet) > will pass all existing tests. I will take ownership of this merge, > probably as a separate patchset.
On 12/12/2019 9:13 AM, Ben Keene wrote: > > On 12/11/2019 5:30 PM, Yang Zhao wrote: >> On Wed, Dec 11, 2019 at 1:46 PM Junio C Hamano <gitster@pobox.com> >> wrote: >>> Luke Diamand <luke@diamand.org> writes: >>> >>>> On Wed, 11 Dec 2019 at 17:57, Junio C Hamano <gitster@pobox.com> >>>> wrote: >>>>> Denton Liu <liu.denton@gmail.com> writes: >>>>> >>>>>> On Wed, Dec 11, 2019 at 08:54:49AM -0800, Junio C Hamano wrote: >>>>>> From what I can tell, Ben agreed to have this series superseded >>>>>> by Yang >>>>>> Zhao's competing series[1]. >>>>> OK. Let me not worry about this one, then, at least not yet. >>>>> >>>> Oh, I hadn't seen Yang's python3 changes! >> ... >>>> What do we need to do to get these ready for merging? >>> Somebody needs to take the ownership of the topic---we cannot afford >>> to have two independently made topics competing reviewers' attention. >>> >>> If Ben wants to drop his version and instead wants to use Yang's >>> ones, that's OK but Ben probably is in a lot better position than >>> bystanders like me to review and comment on Yang's to suggest >>> improvements, if he hasn't done so. The same for those who reviewed >>> Ben's series earlier. >>> >>> It would make sure that the single topic a combined effort to >>> produce the best of both topics. If there is something Ben's >>> patches did that is lacking in Yang's, it may be worth rebuilding it >>> on top of Yang's series. I reviewed Yang's changes and added comments to his commits in GitHub. Except for using the version number instead of feature mapping, all of his changes are much simpler and cleaner than I was proposing and I expect will get adoption more quickly. I recommend the inclusion of the one change I added previously that removes the need for the basestring entirely. This moots some of need for the version checking. Kind regards, Ben