To duplicate: Add and commit a file (e.g., 'test') Remove and commit 'test'. Add and commit new file called 'test' that is unrelated to first 'test' file. Execute hg log -f test Expected result: to see file history for just the new 'test' file. Current result: you see combined file history for both old and new 'test' files.
I find the actual behavior normal and not an issue.
On Wed, 2007-09-19 at 15:28 +0000, Dorin Marinca wrote: > Dorin Marinca <dorin.marinca@gmail.com> added the comment: > > I find the actual behavior normal and not an issue. Hi, Could you please explain why? The two files are unrelated, but have the same name. I would like to see the history only for the new file, not the new + previous. Thanks, Paul
Nobody seems very interested in this, but note $ hg init ex $ cd ex $ touch foo; hg add foo; hg ci -m "add foo" $ hg mv foo bar; hg ci -m "rename foo to bar" $ hg log foo changeset: 0:f9aaaebd3638 user: Faheem Mitha <faheem@email.unc.edu> date: Fri Apr 16 00:34:52 2010 +0530 summary: add foo This really should fail, because there is no foo in parents of wd any longer, and there might be multiple foo's in history, so this is an ill-defined request. This may be the same bug as below, and is certainly related, hence appending. Regards, Faheem.
@faheem IMHO you can still: $ hg update -C 0 and there will be a file 'foo'. So you get a history entry for that. logs are not correlated with the current state of the repository but rather it shows all its history and configuration where you can 'update' your repository.
I have a set of patches to fix this issue locally. I'll clean them and post them to -devel on Monday.
Did you perf-test them ? :)
nicdumz, what is the status of this? I recall you sent patches to the ml.
For reference, the patches were posted in a thread to devel starting with http://markmail.org/message/senwzxdioqq5d6mb From the thread it seems like one patch was applied, but I think it does not solve this issue.
Most recent version of patch at http://markmail.org/message/3zjkvsoptddb3m6t
Fixed by http://hg.intevation.org/mercurial/crew/rev/99cafcae25d9 Nicolas Dumazet <nicdumz.commits@gmail.com> log: do not --follow file that is deleted and recreated later (issue732)
Um, the recipe in http://mercurial.selenic.com/bts/msg12274 is still reproducible as of 1.7.2. Am I missing something?
faheem: The issue that has been reported and discussed here on this issue has been solved. If you have another issue then file it as a new issue. FWIW I think msg12274 shows the intended (and thus (by definition) the correct) behavior when you don't use --follow. But you might have a point if --follow is used.
--- Bug imported by bugzilla@serpentine.com 2012-05-12 08:43 EDT --- This bug was previously known as _bug_ 732 at http://mercurial.selenic.com/bts/issue732 Imported an attachment (id=822)