Відмова від змін без видалення з історії


180

Є зобов'язання, яке просто не спрацювало, тому я хочу відмовитися від нього, не видаляючи його з історії .

Я оновив попередню редакцію та здійснив, створивши нову голову.


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

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


1
Це у вашому репо, тому його не видалено з історії. Ви створили нового керівника, тож ви можете без змін помилитися. Що заважає вам продовжувати роботу з новою головою?
ataylor

Що з вашою відразою до гілок?
Андрес Яан Так

@Andres Це не зовсім відраза до гілок. Мені просто знадобилося це для роботи без дурного зайвого кроку створення одного, щоб його закрити.
o0 '.

Усі, хто читає - зверніть увагу, що філія вже створена за цим сценарієм; зверніть увагу пояснення , дане в цій відповіді: stackoverflow.com/a/3692607/3195477
UuDdLrLrSs

Відповіді:


181

Оновіть свій сховище до голови редакцією, про яку ви хочете забути, а потім hg commit --close-branchпозначте цю (анонімну) гілку як закриту. Потім оновитися до керівника філії , що ви дійсно хочете, і продовжувати працювати.

Ви все ще можете побачити закриту гілку, якщо використовувати -cопцію для hg heads, але вона не відображатиметься за замовчуванням і не hg mergeбуде намагатися злитися з закритою головою.

Вам потрібно буде використовувати hg push --forceперший раз, коли ви натискаєте цю закриту головку до іншого сховища, оскільки ви фактично створюєте додаткові голови у віддаленому сховищі при натисканні. Тож скажіть Меркуріалу, що це нормально --force. Люди, які тягнуть закриту голову, не будуть турбувати будь-які попередження.


3
@Niall C. це не спрацює лише, якщо він позначив це як названу гілку? Я припускаю, що він говорить, що він зробив це за замовчуванням
msarchet

але ... це неправда, я все одно перераховую обидві голови, коли дзвоню hg heads... Я використовую ртутний 1.4.3, це новіша функція?
o0 '.

2
@msarchet: AFAIK, пробуючи це сьогодні, --close-branch НЕ працює для анонімних гілок. Слід, але ні. Я сподіваюся, що це зміниться в якійсь майбутній версії Mercurial. Анонімні гілки дуже приємні, але повинні бути такими ж першокласними, як названі гілки.
Krazy Glew

4
@KrazyGlew: Проблема полягає в тому, що "анонімна" гілка - це справді лише друга гілка з такою ж назвою, що і гілка, на якій вона базувалася. Ви насправді не намагаєтесь закрити (названу) гілку: ви намагаєтесь відмінити внесені вами зміни. Іншими словами, hg branchesусе ж слід вказати назву філії, на якій ви перебуваєте. Замість того, щоб намагатися закрити гілку, об’єднайте свою анонімну гілку назад у початкову гілку, відкинувши всі зміни.
StriplingWarrior

2
У моєму випадку у мене є гілка під назвою default (це стандартно) та інша під назвою default / master (я думаю, через те, що віддалене депо насправді git). hg оновлення за замовчуванням / master; hg commit --закрити-відділити; hg оновлення за замовчуванням працювало для мене.
МтД

68

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


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

У документації по Меркуріалу є хороший розділ, який пропонує вам декілька варіантів навколо обрізки мертвих гілок .

Я думаю, що найкращий варіант для вас - позначити стару гілку як «закриту». Якщо ваша стара голова переглянула "123", тоді:

hg update -r 123
hg commit --close-branch -m 'Closing old branch'
hg update -C default

3
Blurgh - щойно я побачив відповідь @ Niall після того, як я ввійшов. Буде спровоковано Найла та моє може промазати в пулі нульових очок. :)
Нік Пірпойнт,

1
Мені більше подобається ваша відповідь, вона вимагає менше термінології термінології мерурика (яка, наскільки я можу сказати, здається, вибрана для того, щоб збити з пантелику користувачів git)
tacaswell

8
хаха, це навпаки! Термінологія mercurial була обрана таким чином, щоб звучати природно для користувачів svn, в той час як одна з git плутає як пекло! у будь-якому разі, підтримуючи цю відповідь, тому що вона включає останнє оновлення -C
Tobia

2
Навіщо вам -Cв hg update? Здавалося б, жоден файл не був би змінений, тому він повинен працювати без нього.
макс.

1
наскільки я можу сказати, вам не потрібно ніде -C. однак, якщо у вас виникнуть видатні зміни при спробі оновлення, ви отримаєте перерву.
Елі Альберт

21

Перш за все, введіть:

hg heads

Уявіть, у вас в списку три голови:

changeset:   223:d1c3deae6297
user:        Your name  <your@email.com>
date:        Mon Jun 09 02:24:23 2014 +0200
summary:     commit description #3

changeset:   123:91c5402959z3
user:        Your name <your@email.com>
date:        Sat Dec 23 16:05:38 2013 +0200
summary:     commit description #2

changeset:   59:81b9804156a8
user:        Your name <your@email.com>
date:        Sat Sep 14 13:14:40 2013 +0200
summary:     commit description #1

Скажімо, ви хочете тримати останню голову активною (223), а решту закрити.

Потім ви зробите наступне:

Закрийте голову №59

hg up -r 59
hg ci --close-branch -m "clean up heads; approach abandoned"

Закрийте голову №123

hg up -r 123
hg ci --close-branch -m "clean up heads; approach abandoned"

Внесіть зміни

hg push

Не забудьте перейти на праву голову наприкінці

hg up -r 223

І ви закінчили.


Це хороший підручник, але приклад повідомлень про фіксацію є трохи мета. Я б наводив кращі приклади, щоб ті, хто вчився у вас, могли краще повідомляти про вчинення. Щось подібне --close-branch -m "Closing branch - technique #2 abandoned in favor of technique #3".
Джейсон Р. Кумбс

5
Крім того, ви закінчуєте своє завершення, за винятком того, що ваша робоча копія все ще знаходиться на голові, яку ви щойно закрили. Здійснення ще однієї зміни відбудеться на закритій голові, повторно відкривши її. Ви захочете, hg up -r 223перш ніж вносити будь-які зміни.
Джейсон Р. Кумбс

@Jason R. Coombs: Правильно!
Артур Барсегян

Згідно @Niall, і моєму власному досвіду зараз вам знадобиться hg push --forceне просто hg pushдля того, щоб пройти попередження про натискання кількох голів.
craq

1
@Artur Я згоден взагалі. У цьому випадку, hg pushсам по собі мені не вийшло. Як ви рекомендуєте натискати зміни на зовнішній репо, якщо він відмовляється через кілька головок?
craq

12

Ви хочете використовувати hg backout. Це видаляє зміни, внесені набором змін, з будь-якого набору дітей.

Перевірте це, щоб отримати гарне пояснення. Меркуріальна резервація


2
Це точно правильна відповідь. Backout додає зворотний набір змін, скасовуючи діючу та даючи вам повідомлення про прихильність, щоб нагадати собі, чому вам не сподобалася ідея.
Bra4 Ry4an Brase

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

1
@Martin Geisler, добре, я згоден з цим загалом, але ОП заявив, що хоче відмовитися від змін без гілок
msarchet

2
@Martin Geisler так, я все для того, щоб розгалужуватись, просто іноді запускаючи погані зміни - це найкраще
msarchet

1
це може бути корисним часом, але це було насправді не те, що я хотів. Все одно дякую :)
o0 '.

2

І відповіді Ніалла, і Ніка прямі. Оскільки мені здається, що я створюю багато звислих голів, я закінчив писати псевдонім, щоб легше закрити голови. Додавши це до свого .hgrc:

[alias]
behead = !REV=$($HG id -i); $HG update $@ -q && $HG ci --close-branch -m "Closing dead head" && $HG update $REV -q

(якщо у вас вже є [alias]розділ, ви можете додати його до нього)

Тепер ви можете закрити голову однією командою (і не потребуючи оновлення до іншого набору змін вручну), наприклад:

$ hg behead 123

Примітка: псевдонім використовує той факт, що псевдоніми Mercurial можуть бути командами оболонки . Це означає, що це, ймовірно, працює лише в UNIX, а не в Windows.


2

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

Скажімо, історія змін змін виглядає приблизно так:

1-2-3-4-5-6    
       \    
        7-8-*

і воно є 5і 6яке вже не хочеться.

Ви можете зробити це:

hg up 8
hg merge -r 6 -t :local
hg commit ...

що створить це:

1-2-3-4-5-6    
       \   \
        7-8-9-*

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

У -t :localінструктує ¯hG використовувати Об'єднати «інструмент» під назвою місцевий , який говорить йому , щоб ігнорувати зміни з іншої гілки, тобто не представленого поточного стану робочої папки. Більше інформації .

Таким чином, небажані зміни 5і 6зберігаються в історії, але не зачіпають нічого пізнішого.


2

Це випадок використання для розширення Evolve . Наразі це не в комплекті з Mercurial, тому технічно це розширення третьої сторони. Але його досить активно використовують безліч людей, включаючи розробників Mercurial, дуже активно розвиваються і нікуди не діваються.

З розширенням Evolve ви просто робите

hg prune -r revname

і продовжуй своє життя. Комплект все ще буде, але застарілий. Він не буде видимим, якщо ви не передасте цей --hiddenпараметр командам Mercurial, і за замовчуванням не буде перенесено у віддалені сховища. Хоча я думаю, що ти можеш змусити це зробити, якщо дуже хочеш.

Якщо набір, який ви обрізаєте, має предків, яких ви хочете зберегти, тоді вам доведеться бігти, hg evolveщоб відновити ці набори змін. hg evolveзробить це автоматично. В іншому випадку вам нічого не потрібно робити.


1

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

hg clone --rev myGoodResition myDirtyRepo myCleanRepo

1
Це зовсім не те, про що я запитав.
o0 '.

4
@Kristof: це жарт? Перечитайте перший рядок мого допису: "
відмовтесь

-1

Я не раз стикався з цим питанням, коли хочу обезголовити голову, створену помилково. Мені завжди хочеться, щоб це зникло з лиця Землі.

Отримайте останню, а потім:

  1. Знайдіть початок голови, яку ви хочете зняти (там, де нова шия починає відгалужуватися), отримайте номер ревізії

  2. Роздягніть його.


Джерело: TipsAndTricks .

Джерело: PruningDeadBranches # Using_strip .

hg --config extensions.hgext.mq= strip -n <rev>
  1. Зробіть тривіальне оновлення файлу (додайте пробіл у файл), зробіть команду та натисніть.

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


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