Comment 4 for bug 875698
Revision history for this message
| Martin Pool (mbp) wrote Re: [Bug 875698] Re: Inconsistent internal state when altering order of commits using merge | #4 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
e3ace39
(Get the code!)
So where it goes depends a bit on where we think the bug is, but it
could arguably be in tests/blackbox/
these things are a bit arbitrary.
But first: is this a bug: what you're seeing is basically that after
uncommitting, you have a tree with a pending merge that is adding the
file 'b'. If you revert, b is deleted.
You're correct that this is in some ways inconsistent: add b directly
yourself, then revert, and 'b' remains as unversioned. But add b via
a merge, and revert removes it.
Pragmatically this is probably ok in that if you just added the file,
it may be your only copy, whereas if you just merged it, you can
probably merge again.
This is connected to, or a reflection of, the fact that merging
normally does delete removed files rather than leaving them. We could
make that configurable, which would let you perhaps get the desired
behaviour during rebase-interactive.