- User Since
- Mar 10 2020, 5:14 PM (113 w, 6 d)
Mon, May 9
I’m a bit confused. Shouldn’t it fail already on the line stdout = _make_write_all(sys.stdout.buffer) because sys.stdout has no attribute buffer?
Sun, May 8
Does the exception in the description happen with the code before this patch or only if replacing sys.stderr.buffer by getattr(sys.stderr, 'buffer', sys.stderr)?
Sep 19 2020
I think it’s reasonable that Mercurial expects that the stdio streams are initialized properly. Is there a use case for running Mercurial with FDs 0, 1 or 2 set to non-standard streams?
Aug 6 2020
I agree (with some previous answers) that adding more stuff to --force should be avoided.
Jul 29 2020
Jul 28 2020
Jul 27 2020
Jul 20 2020
Jul 17 2020
@durin42 suggested "N:deadbeef: N file(s) changed, became M:f005ba11 (empty change)" on the mailing list. That doesn’t quite nail it, as the message should only be shown if there was a change from non-empty to empty.
Jul 14 2020
Jul 13 2020
Jul 11 2020
Jul 10 2020
Jul 8 2020
Can you give an example of an extension that would benefit from this? It’s not immediately obvious to me, and ideally patches should be written such that it’s obvious for most people. :)
Can you separate the change from "unresolved conflicts (see hg resolve, then hg rebase --continue)" to "unresolved conflicts (see 'hg resolve', then 'hg rebase --continue')", to make the diff less noisy?
Our sources should already be formatted. E.g. if I run black --config=black.toml hgext/rebase.py, it doesn’t change anything. The tests would catch if a file should be reformatted.
Jul 6 2020
@acezar No problem! Thanks for taking take of the failures. In the meantime, Yuya rebased the other changesets, so that there’s another head now: https://www.mercurial-scm.org/pipermail/mercurial-devel/2020-July/142306.html
Jul 4 2020
For one failure, I already sent a patch: https://www.mercurial-scm.org/pipermail/mercurial-devel/2020-July/142287.html
I don’t know if it was this or the next changeset, but the tests are currently broken:
Jun 23 2020
This is probably not the conceptual feedback you were looking for. I hope it’s still helpful.
I think it would be a good idea to mention both --clean and --merge, but mentioning only --merge is better than mentioning only --clean.
Jun 18 2020
Jun 6 2020
Personally, I would have used REs in the first place, but since they were already using globs, this LGTM.
Jun 4 2020
Mar 11 2020
Mar 10 2020
I like the name --from for the option. It would also make sense in combination with a possible future --into option.