Wed, 08 Oct 2014 22:11:36 -0700 obsolete: _rename encodemeta to _fm0encodemeta
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 08 Oct 2014 22:11:36 -0700] rev 22846
obsolete: _rename encodemeta to _fm0encodemeta This will be format zero specific.
Wed, 08 Oct 2014 22:10:15 -0700 obsolete: store metadata as a tuple of (key, value) pairs (API)
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 08 Oct 2014 22:10:15 -0700] rev 22845
obsolete: store metadata as a tuple of (key, value) pairs (API) Different formats will encode metadata in different ways. So we cannot keep the binary blob in the object anymore. We use a tuple to ensure it is immutable and hashable.
Fri, 10 Oct 2014 12:15:46 -0500 merge with stable
Matt Mackall <mpm@selenic.com> [Fri, 10 Oct 2014 12:15:46 -0500] rev 22844
merge with stable
Fri, 10 Oct 2014 11:38:00 -0500 templater: fix ifcontains when list is a string (issue4399) stable
Matt Mackall <mpm@selenic.com> [Fri, 10 Oct 2014 11:38:00 -0500] rev 22843
templater: fix ifcontains when list is a string (issue4399)
Wed, 08 Oct 2014 07:47:11 -0400 shelve: don't delete "." when rebase is a no-op (issue4398) stable
Jordi Gutiérrez Hermoso <jordigh@octave.org> [Wed, 08 Oct 2014 07:47:11 -0400] rev 22842
shelve: don't delete "." when rebase is a no-op (issue4398) When unshelving and facing a conflict, if we resolve all conflicts in favour of the committed changes instead of the shelved changes, then the ensuing implicit rebase is a no-op. That is, there is nothing to rebase. In this case, there are no extra intermediate shelve commits to strip either. Prior to this change, the commit being unshelved to would be marked for destruction in a rather catastrophic way. The relevant part of the test case failed as follows: $ hg unshelve -c unshelve of 'default' complete $ hg diff warning: ignoring unknown working parent 33f7f61e6c5e! diff --git a/a/a b/a/a new file mode 100644 --- /dev/null b/a/a @@ -0,0 1,3 @@ a c x $ hg status warning: ignoring unknown working parent 33f7f61e6c5e! M a/a ? a/a.orig ? foo/foo $ hg summary warning: ignoring unknown working parent 33f7f61e6c5e! parent: -1:000000000000 (no revision checked out) branch: default commit: 1 modified, 2 unknown (new branch head) update: 4 new changesets (update) With this change, this test case now passes.
Wed, 08 Oct 2014 14:16:53 -0700 merge: make error message consistent with other commands
Martin von Zweigbergk <martinvonz@gmail.com> [Wed, 08 Oct 2014 14:16:53 -0700] rev 22841
merge: make error message consistent with other commands If a merge is attempted when another merge is already ongoing, we give the message "outstanding uncommitted merges". Many other commands (such as backout, rebase, histedit) give the same message in singular form. Since the singular form also seems to make more sense, let's use that for 'hg merge' as well.
Fri, 10 Oct 2014 10:34:52 -0400 test-run-tests: add a test for detection of failure to start a server
Augie Fackler <raf@durin42.com> [Fri, 10 Oct 2014 10:34:52 -0400] rev 22840
test-run-tests: add a test for detection of failure to start a server This also highlights a bug: right now we print "2 failed" but we only ran one test.
Thu, 09 Oct 2014 17:00:29 -0700 run-tests: more accurate/helpful message than "diff generation failed"
Kyle Lippincott <spectral@google.com> [Thu, 09 Oct 2014 17:00:29 -0700] rev 22839
run-tests: more accurate/helpful message than "diff generation failed" Diff generation didn't really fail, it recognized that an hg serve server has failed to start, and thus skipped the diff generation intentionally. The most common reason for a server to fail to start is that the port was already in use, so output HGPORT as well, to help finding it (since pgrep -f 'hg serve' is not sufficient, if the command line is something like 'hg -R main serve')
Thu, 09 Oct 2014 15:10:40 -0400 run-tests: handle --jobs and --first gracefully
Augie Fackler <raf@durin42.com> [Thu, 09 Oct 2014 15:10:40 -0400] rev 22838
run-tests: handle --jobs and --first gracefully Without this change, --first causes currently-running tests to explode in violent and surprising ways when their temporary directory gets cleaned up. Now we just suppress failure messages from non-first failures when running in --first mode.
Mon, 06 Oct 2014 16:35:02 -0400 config: use the same hgrc for a cloned repo as for an uninitted repo
Jordi Gutiérrez Hermoso <jordigh@octave.org> [Mon, 06 Oct 2014 16:35:02 -0400] rev 22837
config: use the same hgrc for a cloned repo as for an uninitted repo This just copies the same local sample hgrc, except it sets the default path to the repo it was cloned from. This is cut-and-paste from the local sample hgrc, but I think it's acceptable, since the two pieces of code are right next to each other and they're small. There is danger of them going out of synch, but it would complicate the code too much to get rid of this C&P. I also add ui as an import to hg.py, but with demandimport, this should not be a noticeable performance hit.
(0) -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 tip