Я користувач git, збентежений розгалуженням mercurial. Як я повинен відстежувати невеликі зміни?


32

Я завжди використовував git раніше, але хочу внести свій внесок у python, тому зараз мені доводиться вчитися меркуріалу, і мені здається, це дуже засмучує.

Отже, я зробив пару невеликих виправлень і хотів відстежити їх як коміти в моєму локальному сховищі даних. Мабуть, існує 4 способи впоратися з розгалуженням в ртутних . 1 і 4 виглядали мені абсолютно смішно, названі гілки здаються важкими, і я вважаю, що я не повинен використовувати їх для швидких виправлень 1-фіксації, тому я використовував закладки.

Тепер мій патч відхиляється, і я хочу видалити одну з моїх гілок закладок зі свого сховища. Гаразд, в git я просто змушу видалити свою гілку і забути про неї, тому я видалю свою закладку і тепер у мене є такі проблеми:

  • ЧерепахаHG і hg logдосі показують, що коміт і defaultвідділення мають 2 голови. І якщо я правильно зрозумів, ви не можете видалити комісії в hg без додаткових плагінів.

  • Mercurial має не тільки хеші, але і номери ревізії. Коли я додав пару моїх власних комітетів, усі комітети, витягнуті після цього, мають різні номери редагування від головного центрального репо.

  • Я hg updateпісля перетягування автоматично переношу свою masterзакладку до останньої фіксації, але в TortoiseHG не знайшов способу зробити це.

Що я роблю неправильно? Це нормально і очікується, і я повинен просто ігнорувати ці питання? Або як я повинен працювати зі своїми філіями?

Відповіді:


22

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

Просто клонуйте їх сховище і працюйте в ньому, а потім зробіть запит на виклик.

Якби я використовував гілку, тоді я б скоріше використовував названі гілки. Вони були розроблені саме для цієї мети, де закладок не було. Я не розумію, чому ви вважаєте це важким вагою.

У Mercurial є ціла сторінка на своїй вікі, що описує різні способи " Обрізання мертвих гілок ". Параметр "Використання клону" повинен відповідати вашим вимогам.

Щоб відповісти на ваші конкретніші питання ...

TortoiseHG і hg журнал все ще показують, що філія фіксації та за замовчуванням має 2 голови. І якщо я правильно зрозумів, ви не можете видалити комісії в hg без додаткових плагінів.

Це помилка, яку я зробив з Меркуріалом, коли я був у ній новий. Не бійтеся цих додаткових плагінів. Деякі з них є дуже потужними інструментами, і часто вони пізніше потрапляють в основний продукт. Саме так працює Меркурій. Якщо вам потрібна одна для виконання певного завдання, дістаньте його і використовуйте.

Перегляд історії вважається поганою справою в світі Меркуріалу, тому у продукту ванілі не завжди є все, що користувач Git вважає, що повинен мати, але для тих, хто хоче користуватися програмою, є багато плагінів, але вони мають різні пріоритети.

Mercurial має не тільки хеші, але і номери ревізії. Коли я додав пару моїх власних комітетів, усі комітети, витягнуті після цього, мають різні номери редагування від головного центрального репо.

Не переживайте за номери ревізії. Вони - справа зручності, не більше. Хеш-коди - це важливі ідентифікатори, які перейдуть від репо до репо. Номери редагування несумісні в сховищах. Ознайомтеся з Hg Init за гарним поясненням.

Ревізійні номери - це лише зручна і запам'ятовується ярлик під час роботи з одним репо.

Я оновлюю hg після того, як потягнув, щоб автоматично перемістити основну закладку до останньої фіксації, але я не зміг знайти спосіб зробити це в TortoiseHG.

Під час використання TortoiseHG використовуйте Workbench, а не інші інструменти. Все (майже) є там. Оновлення знаходиться в контекстних меню редакції. Це не завжди інтуїтивно, але є гарне керівництво за посиланням вище, і коли ви звикаєте до нього, ви в кінцевому підсумку клацаєте геть із впевненою відмовою.


Я, звичайно, бачив аргумент перед тим, що власне названі гілки означають, що історія редагування менше потрібна в hg
jk.

9

Мабуть, існує 4 способи впоратися з розгалуженням в ртутних. 1 і 4 видалися мені абсолютно смішними, названі гілки здаються важкими

У Mercurial ви не створюєте гілок. Кожне вчинення фактично є галуззю, будь-яке вчинення може мати декількох батьків та декількох дітей. Отже, це чотири різних способи організації одних і тих же утворень.

Ви можете давати їм різні імена, не потрібно , але це гарна ідея. У названих гілках немає нічого важкого - це лише додаткові метадані. Я особисто віддаю перевагу названим гілкам перед будь-яким іншим у будь-якій ситуації.

TortoiseHG і hg журнал все ще показують, що філія фіксації та за замовчуванням має 2 голови.

Яка саме причина використовувати названі гілки, а не скидати все в default.

І якщо я правильно зрозумів, ви не можете видалити комісії в hg без додаткових плагінів.

Насправді ви нічого не можете видалити з Mercurial, а також не слід . Ви можете використовувати, hg stripале це не зареєстровано - ви в основному просто відрізали частину місцевого репо. Ви не можете натиснути це, і якщо ви витягнете з репо, в якому є гілка, яку ви зняли локально, вона повернеться.

Mercurial має не тільки хеші, але і номери ревізії. Коли я додав пару моїх власних комітетів, усі комітети, витягнуті після цього, мають різні номери редагування від головного центрального репо.

Цифри нічого не означають. Ви можете їх знехтувати, якщо вони вас бентежать.

Я оновлюю hg після того, як потягнув, щоб автоматично перемістити основну закладку до останньої фіксації, але я не зміг знайти спосіб зробити це в TortoiseHG.

Я не використовував TortoiseHG, але hg pull -uбуду робити і те, pullі інше update.

Я завжди використовував git раніше, але хочу внести свій внесок у python, тому зараз мені доводиться вчитися меркуріалу, і мені здається, це дуже засмучує.

Це нормально, багато користувачів Mercurial відчувають те саме щодо Git (включаючи мене).


6

Навіть коли Mercurial і Git схожі, вони мають різні конструкції, можливо, найважливішою дизайнерською різницею є те, що в Mercurial модифікація історії не настільки гнучка, як у git (тому що вона є якось не приборканою).

Коротка відповідь : неважливо, чи є у вас невелика кількість змін, ви все одно можете використовувати гілку. Якщо ви думаєте про видалення цієї гілки, тоді використовуйте закладку, щоб потім можна було видалити її та знімати зміни згодом.

По-перше, намагаюся пролити трохи світла на деякі згаданих вами речей:

  • 1 і 4 вважаються розгалуженнями, тому що кожен раз, коли ви здійснюєте, ви ефективно створюєте неназвану гілку (якщо у вашому джерелі / благословенному репо є ще одна фіксація), яка технічно є галуззю. У методі 4 ви створюєте нову "голову", тоді як у методі 1 ви цього не робите . Голови повинні бути злиті. Я погоджуюсь, що метод 1 є дурним, але, здається, деяким подобається ... для невеликих проектів.

  • Щодо способу 2, то не те, що гілки важкі, це те, що вони постійні . Ви не можете видалити гілку, якщо не використовуєте щось на зразок розширення смуги. Знову ж таки, філософія дизайну Mercurial не йде на зміну історії (але в цьому вона стала кращою).

  • Що стосується номерів версій , то вони є лише локальною та читаною людиною посиланням для використання всіх команд, що стосуються змін. Якщо ви любите використовувати хеші, ви все одно можете це зробити. Номери редагування - це лише ярлик, і Mercurial не враховує будь-яких внутрішніх операцій між різними сховищами.

Тепер, щоб відповісти на ваші інші запитання:

  • Ви можете перевірити, з якими головами у вас є hg heads, якщо ви бачите 2+ голови в одній названій гілці, бажано, щоб вони були об'єднані. Це, мабуть, ваша закладка .
  • Щоб позбутися перегляду, який ви тільки що зробили, ви могли б зробити hg rollback, але я гадаю, що це не так.
  • Щоб видалити закладку, просто зробіть hg bookmark --delete yourbookmark
  • Ви будете щасливі, що в історії легко вирізати гілки. Подивіться на розширення Rebase та операцію Strip .
  • Mercurial вже поставляється в комплекті з декількома розширеннями, але вони не активовані за замовчуванням . Просто перейдіть у будь-яку папку і клацніть правою кнопкою миші будь-де, щоб отримати контекстне меню TortoiseHG, увійдіть у «Глобальні налаштування», а потім «Розширення»: активуйте розширення MQ та розширення Rebase. Це не шкодить сумісності між сховищами.
  • Тепер, коли ви тут, ви можете:
    • Складіть там, де почалася ваша закладка (це, ймовірно, вирішує вашу проблему)
    • Щоб полегшити візуалізацію, можливо, ви зможете змінити зміни на передній частині, а потім зняти їх. Я щойно згадав про базу даних, тому що це може бути корисним для вас в інший час.

Крім того, в git ви можете мати "приватні локальні відділення", оскільки ви повинні їх чітко натиснути, а потім можете видалити їх. У Mercurial ви натискаєте все, що у вас є , однак, якщо ви хочете цього уникнути, ви можете скористатися функцією Phases і позначити набір ревізій як таємний . Таємні зміни не будуть висунуті.

Нарешті, ви нічого не робите , просто пам’ятайте, що це просто різні інструменти, побудовані з дещо різними наборами мислення, які значною мірою зводяться до: зміни історії (git) чи не модифікації історії (hg). У Mercurial важче стріляти в ногу, змінюючи історію (особливо з Фазами), і тому деяким подобається це краще, ніж git .


Немає можливості гарантувати, що всі децентралізовані копії наборів змін, які записують названу гілку, були видалені після виконання hg strip. Я думаю, можна сказати те саме про децентралізовані копії імен гілок Git, за винятком того, що названі гілки мають глобальний простір імен, а назви гілок Git - ні. І кілька головок існують через гілки імен. Це своєрідна помилка дизайнерської помилки для децентралізованої системи ДКС.
Шелбі Мур III,

1

Я вважаю, що з mercurial найлегше не турбуватися про гілки. Я просто знаходжу, де в історії я хочу редагувати та створювати комісії за потребою (він же анонімні гілки). Іноді закладки можуть бути корисні, якщо мені доводиться стрибати між головами в різних контекстах, але найчастіше я з ними не переймаюся. Іменовані гілки добре для довгоживучих гілок (виправлення помилок, гілки проектів), але для виправлень 1- або 2-фіксації вони не є правильним інструментом для роботи.

Трюк з анонімними гілками полягає в тому, щоб встановити їх фазу на "секрет", якщо ви не хочете їх натискати, тобто якщо ви хочете тримати їх локальними. Якщо ви дійсно хочете , щоб підштовхнути їх, але ви не хочете більше ніяких фіксацій на їх основі, ви просто зробити «--close-гілка» на них зверху , який не означає , що вони більше не з'являються в списку "головок і ртутний перестане скаржитися на кілька голів на цій гілці.


-1

Я думаю, що ми можемо просто використовувати закладку замість гілки; ми все одно продовжимо підтримувати продукт, і об'єднання двох гілок у довгостроковій перспективі буде великим головним болем.

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