`hg log -p` no longer shows patches if the largefiles extension is enabled. This is a regression between 3.0.1 and 3.1.
I cannot reproduce. Can you provide us with a small list of step to reproduce (or even better a small script)
Created attachment 1784 [details] Creates a repo, runs hg log -p with largefiles enabled
On 3.1 the attached script does not show patch data, tested on OS X 10.9 & Centos 6. Patch data is displayed as expected on 3.0.1.
Hum, works better when I do not mis spell largefiles. I can reproduce: % 0:14 pyd@marginatus /tmp/babar > hg --config extensions.largefiles= log -p changeset: 0:c976fad4e630 tag: tip user: Pierre-Yves David <pierre-yves.david@fb.com> date: Tue Aug 12 23:49:07 2014 -0700 summary: t
Using `hg bisect` to narrow it down to the changesets that broke it in mercurial would be a good next step. (adding Sean Farley that changed changectx code recently and mads kiilerich who currently maintains most of the largefile burden)
This was my first time using bisect! Fun! The breaking changeset is 5809d62e7106.
yay largefiles
Regression -> urgent How did this get past our test suite? $ grep -- --- tests/*largefiles* $ I see.. not a single diff test. <facepalm>
*** Bug 4120 has been marked as a duplicate of this bug. ***
Problem was there since mercurial 2.5.4. sh -x /tmp/largefiles.sh + export HGRCPATH= + HGRCPATH= + mkdir largefilestest + cd largefilestest /home/lvu/repos/trunk/largefilestest + hg init + echo foo + hg add adding bar + hg ci -m 'adding bar' -u testuser + hg log -p --config extensions.largefiles= changeset: 0:fa232aeb9c80 tag: tip user: testuser date: Thu Aug 14 16:19:05 2014 -0400 summary: adding bar diff -r 000000000000 -r fa232aeb9c80 bar --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/bar Thu Aug 14 16:19:05 2014 -0400 @@ -0,0 +1,1 @@ +foo + cd .. + rm -rf largefilestest
Yes, this is a semi-regression (it was always broken when largefiles were present -- in 3.1, it also broke when no largefiles were present). The patches I've sent to the mailing list should fix hg log --patch for both cases.
Fixed by http://selenic.com/repo/hg/rev/1b9d0dc1bbe1 Siddharth Agarwal <sid0@fb.com> largefiles: drop setting lfstatus in overridelog (issue4334) lfstatus should only be True for operations where we want standins to be printed out. We explicitly do not want that for historical operations like log. Other historical operations like hg diff -r A -r B don't print out standins either. This is required to fix issue4334, but doesn't fix anything by itself. That's why there aren't any tests accompanying this patch. (please test the fix)
Fixed by http://selenic.com/repo/hg/rev/35cc5b07b3fc Siddharth Agarwal <sid0@fb.com> largefiles: in overridelog, use non-lf matcher for patch generation (issue4334) This has actually been broken since at least Mercurial 2.8 -- hg log --patch with largefiles only used to work when no largefiles existed. Rev 5809d62e7106 exposed this bug for all cases. (please test the fix)
Fixed by http://selenic.com/repo/hg/rev/0e1b02f984c7 Siddharth Agarwal <sid0@fb.com> largefiles: don't override matchandpats for always matchers (issue4334) This makes hg log --follow --patch work, since in cmdutil._makelogrevset we use the non-follow matcher for hg log --follow --patch with no file arguments. (please test the fix)
Works for me, thanks!
Bulk testing -> fixed