Як об’єднати дві гілки з різними ієрархіями каталогів у git?


78

Я почав використовувати Maven у проекті веб-додатків, тому ієрархія каталогів змінилася. Я створив нову гілку для інтеграції Maven. Зараз у мене є дві гілки - одна зі старою ієрархією каталогів, а друга - з ієрархією каталогів maven. В обох гілках є нові коміти (виправлення помилок та нові функції).

Я хотів би позбутися старої гілки та об’єднати її зміни з гілкою Maven. Git merge дає незліченну кількість конфліктів, які, здається, неможливо вирішити. Я вважаю, що це тому, що шлях до файлів змінився.

Який найкращий спосіб підійти до цього злиття?


10
Просто щоб інші читачі знали: типовим повідомленням про помилку для цих проблем є too many files skipping inexact rename detection.
Nils Werner

Відповіді:


166

Спробуйте встановити merge.renameLimitщось високе для цього злиття. git намагається виявити перейменування, але лише якщо кількість файлів нижче цієї межі, оскільки для цього потрібен час обробки O (n ^ 2):

git config merge.renameLimit 999999

тоді коли закінчите:

git config --unset merge.renameLimit

8
Зверніть увагу, після збільшення renameLimit, мені довелося запустити "git merge --abort", щоб я міг спробувати повторити витяг. В іншому випадку це зробило трюк.
leontx

27

Блог « Confluence, мерзотник, перейменування, злиття про мій ... » додає деяку цікаву інформацію , яка ілюструє Робі «сек відповідь (upvoted):

При спробі виявити перейменування git розрізняє точні та неточні перейменування за допомогою:

  • перший - перейменування без зміни вмісту файлу та
  • остання - перейменування, яке може включати зміни у вмісті файлу (наприклад, перейменування / переміщення класу Java).

Ця різниця важлива, оскільки алгоритм виявлення точних перейменувань є лінійним і завжди буде виконуватися, тоді як алгоритм виявлення неточного перейменування є квадратичним ( O(n^2)), а git не намагається це зробити, якщо кількість файлів, що змінюються, перевищує певний поріг (1000 на за замовчуванням).

Якщо явно не встановлено, merge.renameLimitза замовчуванням становить 1000 файлів або використовує значення diff.renameLimitif, якщо встановлено. Впливає , і в той час як ставиться до спроб злиття ( , ) тільки.
diff.renameLimitgit diffgit showgit logmerge.renameLimitgit mergegit cherry-pick

Це гарна ідея змінити на merge.renameLimitвідміну від зміни diff.renameLimitтак, щоб git не намагався знаходити перейменування під час загальних операцій, таких як перегляд git diffвихідних даних.

Щоб показати перейменування, команди, як git showабо git logможуть бути використані з -Mопцією, яка вмикає виявлення перейменування.

Лінус згадує :

Так, ядро ​​у мене є

    [diff]
            renamelimit=0

повністю вимкнути ліміт, оскільки ліміт за замовчуванням справді дуже низький. Git досить добре розпізнає перейменування.

Однак причина низького значення за замовчуванням полягає не в тому, що він недостатньо швидкий - це тому, що він може в кінцевому підсумку зайняти багато пам'яті (і якщо у вас мало пам'яті, обмін буде означати, що він переходить із "досить швидко" "повільний, як патока" - але він все одно не буде обмежений процесором, він просто підкачує, як божевільний).

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.