Fri, 09 Mar 2018 12:45:50 -0800 rebase: also restore "ui.allowemptycommit" value
Martin von Zweigbergk <martinvonz@google.com> [Fri, 09 Mar 2018 12:45:50 -0800] rev 36929
rebase: also restore "ui.allowemptycommit" value It looks like this was lost when the code was converted to the ui.configoverride() context manager in f255b1811f5e (rebase: get rid of ui.backupconfig, 2017-03-16). (And then the bad example was duplicated in 228916ca12b5 (rebase: add concludememorynode(), and call it when rebasing in-memory, 2017-12-07).) Differential Revision: https://phab.mercurial-scm.org/D2760
Thu, 08 Mar 2018 14:17:24 -0800 rebase: fix issue 5494 also with --collapse
Martin von Zweigbergk <martinvonz@google.com> [Thu, 08 Mar 2018 14:17:24 -0800] rev 36928
rebase: fix issue 5494 also with --collapse Differential Revision: https://phab.mercurial-scm.org/D2759
Fri, 09 Mar 2018 10:35:48 -0800 rebase: also include commit of collapsed commits in single transaction
Martin von Zweigbergk <martinvonz@google.com> [Fri, 09 Mar 2018 10:35:48 -0800] rev 36927
rebase: also include commit of collapsed commits in single transaction When rebase.singletransaction is set, we still used to create a second transaction when committing with --collapse. It's simpler to create a single transaction. Note that in the affected .t file, the test that uses --collapse still appears to create two transactions (it prints "rebase status stored" twice). However, only a single transaction is actually created and the second printout comes from cmdutil.commitforceeditor() that explicitly calls tr.writepending(). Also note the that we now roll back any commits if the user closes the commit message editor with an error code (or leaves the message empty). That might be unfortunate, but it's consistent with how we behave in the --no-collapse case (if the user passed --edit). If we want to change that, I think it should be done consistently in a separate patch. Differential Revision: https://phab.mercurial-scm.org/D2728
Mon, 12 Mar 2018 23:08:47 -0400 lfs: debug print HTTP headers and JSON payload received from the server
Matt Harbison <matt_harbison@yahoo.com> [Mon, 12 Mar 2018 23:08:47 -0400] rev 36926
lfs: debug print HTTP headers and JSON payload received from the server This has been extremely valuable to show divergences between `hg serve` and `lfs-test-server`. Once the `hg serve` code lands, there will be a certain amount of conditionalizing that needs to be done, because `lfs-test-server` doesn't always follow its spec. The $ISO_8601_DATE_TIME$ pattern masks the fact that `lfs-test-serve` is sending out an expires_at value of "0001-01-01T00:00:00Z". `hg serve` will (probably) use current time + 10 minutes or similar. The $HTTP_DATE$ is the current time.
Mon, 12 Mar 2018 22:30:01 -0400 test-lfs: dial up the debugging on commands that interact with the server
Matt Harbison <matt_harbison@yahoo.com> [Mon, 12 Mar 2018 22:30:01 -0400] rev 36925
test-lfs: dial up the debugging on commands that interact with the server This will be useful to let the client print out the HTTP headers and JSON in a future patch, so we can compare native LFS serving against test-lfs-server behavior. There tends to be a lot of debug stuff that we don't care about here in a push, so I was tempted to print this output with a [devel] config. But this will be useful for field debugging too, so just put up with the extra output here. It would have been nice to be able to set ui.debug once, but issue5815 prevents that.
Sat, 24 Feb 2018 15:12:01 -0500 tests: add a substitution pattern for dates in HTTP headers and LFS payload
Matt Harbison <matt_harbison@yahoo.com> [Sat, 24 Feb 2018 15:12:01 -0500] rev 36924
tests: add a substitution pattern for dates in HTTP headers and LFS payload This will be useful when printing HTTP headers and JSON payload received from an LFS server. The RFC 1123 date masking has uses elsewhere too.
(0) -30000 -10000 -3000 -1000 -300 -100 -30 -10 -6 +6 +10 +30 +100 +300 +1000 +3000 +10000 tip