Fri, 08 Feb 2013 08:02:57 -0600 convert/git: catch errors from modern git-ls-remote (issue3428)
Ross Lagerwall <rosslagerwall@gmail.com> [Fri, 08 Feb 2013 08:02:57 -0600] rev 18570
convert/git: catch errors from modern git-ls-remote (issue3428) Since git v1.7.8.2-327-g926f1dd (the change was first released in git 1.7.10), git does not return non-zero when "git ls-remote --tags ..." is run and the repository is damaged. This causes the "damaged repository with missing commit" test in test-convert-git.t to unexpectedly succeed. Fix by aborting if git outputs any lines beginning with "error:", which required adding some subprocess use in convert/git.py.
Fri, 08 Feb 2013 14:26:00 +0000 merge with stable
Kevin Bullock <kbullock@ringworld.org> [Fri, 08 Feb 2013 14:26:00 +0000] rev 18569
merge with stable
Wed, 06 Feb 2013 07:55:29 +0000 incoming: fix incoming when a local head is remotely filtered (issue3805) stable
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 06 Feb 2013 07:55:29 +0000] rev 18568
incoming: fix incoming when a local head is remotely filtered (issue3805) In its current state discovery may return (remotely) filtered elements in "common". This has usually no impact as "missing" is kept clear of filtered elements. However when the "remote" repo is a local repo (disk accessible, and directly created in memory) the incoming code takes a shortcut and directly uses the "remote" repo to generate the incoming output. When some common elements are filtered this led to a crash. We now ensure we use an unfiltered repository to generate the incoming output. This does not change the behavior as missing is clear of filtered revision. Now that we have proper low level filtering, incoming code needs a deeper cleanup but it is already planned.
Thu, 17 Jan 2013 23:46:08 -0800 dirstate: move pure python dirstate packing to pure/parsers.py
Siddharth Agarwal <sid0@fb.com> [Thu, 17 Jan 2013 23:46:08 -0800] rev 18567
dirstate: move pure python dirstate packing to pure/parsers.py
Tue, 05 Feb 2013 16:22:53 -0800 bookmark: don't allow integers as bookmark/branch/tag names
Durham Goode <durham@fb.com> [Tue, 05 Feb 2013 16:22:53 -0800] rev 18566
bookmark: don't allow integers as bookmark/branch/tag names Bookmarks/branches/tags shouldn't be allowed to be integers because that overlaps with revision numbers. Right now if a user created one they can't use it anyway because the revision numbers take precedence. The check only happens when creating a new bookmark/etc from a command so it shouldn't affect existing bookmarks/branches/tags or importing branches from git. This fix was prompted by us having a user create a bookmark named "404" then accidentally checkout a very old version of our repository.
Wed, 24 Oct 2012 23:09:31 +0200 run-tests: do not fail on empty tsttest file
Simon Heimberg <simohe@besonet.ch> [Wed, 24 Oct 2012 23:09:31 +0200] rev 18565
run-tests: do not fail on empty tsttest file Initialize n for not failing on empty tsttest files.
Wed, 06 Feb 2013 14:43:29 -0600 merge with stable
Matt Mackall <mpm@selenic.com> [Wed, 06 Feb 2013 14:43:29 -0600] rev 18564
merge with stable
Tue, 05 Feb 2013 11:31:43 -0600 hgweb: make 'summary' work with hidden changesets (issue3810) stable
Kevin Bullock <kbullock@ringworld.org> [Tue, 05 Feb 2013 11:31:43 -0600] rev 18563
hgweb: make 'summary' work with hidden changesets (issue3810) Since the 'summary' view used by e.g. gitweb and monoblue shows both a changelog and a bookmarks list, the same changes are needed here as were made to the 'changelog' and 'bookmarks' web commands (56ca4443a343 and 886936ecc21b, respectively).
(0) -10000 -3000 -1000 -300 -100 -30 -10 -8 +8 +10 +30 +100 +300 +1000 +3000 +10000 +30000 tip