deprecated, use 'repr()'
Which is a whole bunch of errors and warnings thrown by pep8. Is pep8
just getting put by the wayside? I would much rather have these scripts
conform to that and have an actual coding style rather than just be a
hodge-podge of different styles.
Thanks,
--
W
Quite a large change, most of this was whitespace changes, though there
were a few places where I removed a comma or added a few characters.
Should pass through pep8 and pass every test.
---
contrib/svn-fe/svnrdump_sim.py | 93 +++---
1 file changed, 52 insertio
On Thu, May 08, 2014 at 07:46:33PM -0700, Jonathan Nieder wrote:
> Hi,
>
> William Giokas wrote:
>
> > Quite a large change, most of this was whitespace changes, though there
> > were a few places where I removed a comma or added a few characters.
> > Should pass th
On Thu, May 08, 2014 at 09:10:25PM -0500, Felipe Contreras wrote:
> William Giokas wrote:
> > Which is a whole bunch of errors and warnings thrown by pep8. Is pep8
> > just getting put by the wayside? I would much rather have these
> > scripts conform to that and have an actua
On Thu, May 08, 2014 at 11:36:29PM -0500, Felipe Contreras wrote:
> William Giokas wrote:
> > E401: Multi-line imports seems like something that would just be
> > changing one line
>
> Yes, and make the code very annoying.
It's 1 extra line in git-remote-hg, and 4 lin
On Fri, May 09, 2014 at 02:18:54AM -0500, Felipe Contreras wrote:
> William Giokas wrote:
> > On Thu, May 08, 2014 at 11:36:29PM -0500, Felipe Contreras wrote:
> > > William Giokas wrote:
> > > > E401: Multi-line imports seems like something that would jus
On Fri, May 09, 2014 at 02:35:34AM -0500, Felipe Contreras wrote:
> William Giokas wrote:
> > Yeah. In fact, for the mercurial stuff the `from mercurial import
> > changegroup`
> > line should be on the same line as the other `from mercurial import ...`
> > line.
>
[*1*], seeing
> it did not lead to a productive discussion, I gave up. So I haven't
> even managed to convince myself that that commit is the best
> solution to the problem.
I was really sad to see that, and didn't have time to really look at it
because of work and other projects, but I hope this presents a better
solution than the current patch.
Thanks,
--
William Giokas | KaiSforza | http://kaictl.net/
GnuPG Key: 0x73CD09CF
Fingerprint: F73F 50EF BBE2 9846 8306 E6B8 6902 06D8 73CD 09CF
pgpC7ZLGG4hd9.pgp
Description: PGP signature
we do change it.
The try:except block at the beginning of git-remote-hg.py tries first to
import mercurial.changegroup.getbundle, and if that fails we set the
function 'getbundle' to work correctly with mercurial.repo.getbundle by
removing the first argument.
Signed-off-by: William
On Tue, May 13, 2014 at 02:09:55PM -0500, Felipe Contreras wrote:
> William Giokas wrote:
> > On Tue, May 13, 2014 at 10:30:26AM -0700, Junio C Hamano wrote:
>
> > > Why do we "import changegroup" unconditionally, even though it
> > > is only
we do change it.
The try:except block at the beginning of git-remote-hg.py tries first to
import mercurial.changegroup.getbundle, and if that fails we set the
function 'getbundle' to work correctly with mercurial.repo.getbundle by
removing the first argument.
Signed-off-by: William
On Tue, May 13, 2014 at 03:24:51PM -0500, Felipe Contreras wrote:
> William Giokas wrote:
> > On Tue, May 13, 2014 at 02:09:55PM -0500, Felipe Contreras wrote:
> > > As you say, it's perfectly OK.
> >
> > But wrong. Yes, it works, but it's not how it shoul
t any real hassle on git or mercurial's side.
This goes for bzr, too, but it looks to be changing less quickly.
tl;dr: This may not block a release, but it will make releases a lot
more dependent on outside forces.
Thanks,
--
William Giokas | KaiSforza | http://kaictl.net/
GnuPG Key: 0x73CD09CF
Fingerprint: F73F 50EF BBE2 9846 8306 E6B8 6902 06D8 73CD 09CF
pgp52E8cms84y.pgp
Description: PGP signature
ould have:
>
> Git < v2.5 fail, Git >= 2.5 get the fix
>
> If we unbundle, we have:
>
> git-remote-hg < v0.5 fail, git-remote-hg >= v0.5 get the fix
>
> What is the big difference?
It's a matter of scope and where the releases happen, that is all.
this further?
Thank you,
--
William Giokas | KaiSforza
GnuPG Key: 0x73CD09CF
Fingerprint: F73F 50EF BBE2 9846 8306 E6B8 6902 06D8 73CD 09CF
pgpkOlM_UNxBu.pgp
Description: PGP signature
bar should also work, but local optimizations are off in
> that case, which may be unwanted. While at there, warn the users about
> --local being ignored in this case.
>
> Reported-by: William Giokas <1007...@gmail.com>
> Signed-off-by: Nguyễn Thái Ngọc Duy
> ---
Working f
patches
* run `git am` on the maildir containing these patches
Expected result:
* Apply patches in [01..N] order
Actual result:
* Patches applied in [N N-1..01] order
[0]: https://mailman.archlinux.org/pipermail/pacman-dev/2013-March/016541.html
Thank you,
--
William Giokas | KaiSforza
GnuPG Key
17 matches
Mail list logo
