|
|
Created on 2008-07-04.15:58:17 by gabrielgi, last changed 2008-08-13.18:23:55 by mpm.
| msg6764 (view) |
Author: mpm |
Date: 2008-08-13.18:23:47 |
|
Note this line:
ancestor fdedead1b396 local fdedead1b396+ remote fdedead1b396
The trouble here is really that we're updating from revision 'tip+' in the
working directory to revision 'tip'. That is, we're going backwards in time. And
the merge logic for going backwards is very different from the logic going
forward. If we go backwards in time, it's quite natural to reinstate deleted
files and so we do.
So the problem seems to actually be that we shouldn't try to update in this
case, not that there's anything wrong with the merge logic itself.
Updating title.
|
| msg6763 (view) |
Author: fgsch |
Date: 2008-08-13.15:03:52 |
|
ThomasAH: How is this related at all? The files in question are under hg
control. Your example is not equivalent, both foo and bar were modified outside
hg, not the case gabrielgi described.
|
| msg6762 (view) |
Author: gabrielgi |
Date: 2008-08-13.14:44:42 |
|
ThomasAH: Fair enough, although I'd consider it a "bad practice" to do rm
instead of hg rm
within a Mercurial workspace unless we're talking about a file that's in
.hgignore (e.g., .pyc).
I chatted about this issue some weeks ago and one of the main developers
acknowledged the bug and actually found where it was. Not sure about the details
myself though.
|
| msg6761 (view) |
Author: djc |
Date: 2008-08-13.14:42:14 |
|
ThomasAH: except that hg remove records R in dirstate. Since hg update without
-C keeps all dirstate changes, it shouldn't remove that, either.
|
| msg6760 (view) |
Author: ThomasAH |
Date: 2008-08-13.14:38:51 |
|
The behaviour is similar to making manual changes:
touch foo
rm bar
hg update
-> foo is still there, bar is revived.
But yes, this somehow looks like needing some thought about what is the correct way.
|
| msg6469 (view) |
Author: gabrielgi |
Date: 2008-07-04.15:58:17 |
|
Better explain this with an example:
---cut---
$ hg update
0 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ hg remove test.txt
$ hg status
R test.txt
$ hg --debug update
resolving manifests
overwrite False partial False
ancestor fdedead1b396 local fdedead1b396+ remote fdedead1b396
test.txt: recreating -> g
getting test.txt
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ hg status
$
---cut---
Originally, I spotted this while doing a rename:
---cut---
$ hg update
0 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ hg rename test.txt test1.txt
$ hg status
A test1.txt
R test.txt
$ hg --debug update
resolving manifests
overwrite False partial False
ancestor fdedead1b396 local fdedead1b396+ remote fdedead1b396
test.txt: recreating -> g
getting test.txt
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ hg status
A test1.txt
$
---cut---
Thanks!
|
|
| Date |
User |
Action |
Args |
| 2008-08-13 18:23:55 | mpm | set | nosy:
mpm, ThomasAH, djc, abuehl, gabrielgi, fgsch messages:
+ msg6764 title: hg update makes mercurial "forget" about a pending remove -> hg update acts weird if we're already at the tip |
| 2008-08-13 15:03:52 | fgsch | set | nosy:
+ fgsch messages:
+ msg6763 |
| 2008-08-13 14:44:43 | gabrielgi | set | status: unread -> chatting nosy:
mpm, ThomasAH, djc, abuehl, gabrielgi messages:
+ msg6762 |
| 2008-08-13 14:42:23 | djc | set | status: chatting -> unread nosy:
mpm, ThomasAH, djc, abuehl, gabrielgi messages:
+ msg6761 |
| 2008-08-13 14:38:52 | ThomasAH | set | status: unread -> chatting nosy:
+ ThomasAH, mpm messages:
+ msg6760 |
| 2008-08-13 14:23:04 | djc | set | nosy:
+ djc |
| 2008-07-04 17:35:21 | abuehl | set | nosy:
+ abuehl |
| 2008-07-04 15:58:17 | gabrielgi | create | |
|