This makes the merge code chain and filter copies when grafting with
copies already in the working copy. For example, if the working copy
has renamed file A to B and you somehow graft in a change that renames
B to C, then that will now become a rename from A to C. That will
soon be necessary for hg rebase --collapse. It seems that we don't
have any existing cases where chaining makes a difference.
Details
- Reviewers
- None
- Group Reviewers
hg-reviewers
Diff Detail
- Repository
- rHG Mercurial
- Branch
- default
- Lint
No Linters Available - Unit
No Unit Test Coverage
Event Timeline
This patch seems related to D8596 which @martinvonz pointed as "not meant to be merged". What should we do with this diff ? is it intended for landing ? If not could get we it out of need-review and marke it RFC ?
mercurial/merge.py | ||
---|---|---|
1918–1923 | I am not sure why we gain all these new cases? where do they comes from? |
mercurial/merge.py | ||
---|---|---|
1918–1923 | Did you miss the comment I added on line 1914 or do you think it's not enough? Each case is documented there. |
(I have an unsubmitted question laying around for over a month…)
mercurial/merge.py | ||
---|---|---|
1918–1923 | I don't understand how it answser my question of "why does these new cases pops up?" |
mercurial/merge.py | ||
---|---|---|
1918–1923 | I guess I don't understand what your question was in that case. Can you rephrase it? |
mercurial/merge.py | ||
---|---|---|
1918–1923 | Previously, theses extra ifs clause were not necessary, Now they appears. Why do they become necessary now ? |
mercurial/merge.py | ||
---|---|---|
1918–1923 | Ah, I see. See copies.filter() (called copies._filter() at head) for details. |
I am not sure why we gain all these new cases? where do they comes from?