git log --first-parent опускает все коммиты слияния, кроме первого родителя.
Пример:
$ git log --oneline --graph
* 087f5ed Master C
* 36c50a2 Merge branch 'feature'
|\
| * 98c89df Feature B
| * 89b3a7b Feature A
* | 9a95133 Master B
|/
* 766c9b0 Master A
$ git log --oneline --graph --first-parent
* 087f5ed Master C
* 36c50a2 Merge branch 'feature'
* 9a95133 Master B
* 766c9b0 Master A
Есть ли эквивалент Mercurial?
hg log -r '_firstancestors(...)'Существует прямой эквивалент: скрытый набор ревизий _firstancestors следует за стороной первого родителя (p1) каждого слияния. В Mercurial, как и в Git, первый родитель — это коммит, который был проверен при вызове hg merge [second parent].
hg log -r '_firstancestors(myfeature)'
«скрытый» означает, что он начинается со знака подчеркивания и не указан в справке и т. д., но его можно использовать, если вы знаете, что он существует. Я не знаю, почему это скрыто.
Этот псевдоним revset перечисляет все коммиты в функциональной ветке, игнорируя все предки всякий раз, когда master объединяется с веткой, чтобы обновить ее. (Магазин, в котором я работаю, предпочитает слияние, а не перебазирование).
[revsetalias]
feature($1) = _firstancestors($1) and not _firstancestors(master)
[alias]
f = log -r "feature($(echo $HG_ARGS| sed 's/^f //'))"
Пример использования (использует мой собственный шаблон ведения журнала):
$ hg f myfeature
o 423 myfeature default/myfeature -- Esteis -- 2016-07-12 -- 123abc
| this
o 422 -- Esteis -- 2016-07-12 -- 123def
|\ merge master into myfeature
o ~ 421 -- Esteis -- 2016-07-12 -- 456abc
| that
o 420 -- Esteis -- 2016-07-12 -- 789def
| and the other
Для этого вы можете использовать revsets:
hg log -r "p1(merge())"
merge() получает все коммиты слияния, а p1() получает первого родителя этих коммитов.
Используйте hg help revsets для получения дополнительной информации о наборах изменений.
>hg glog -r 410:426 --template "{rev} - {desc|firstline|fill68}\n"
o 426 - Merge test fixes for dulwich changes and output changes.
|\
| o 425 - Merge incoming fix.
| |\
| | o 424 - getremotechanges: fix incoming support
| | |
o | | 423 - overlay: stop using deprecated tree.entries() method
| | |
| o | 422 - Fix all-version-tests.
| | |
o | | 421 - Test output format tweaks for test-outgoing.
| | |
o | | 420 - test-incoming: fixes for hg 1.7
| | |
| o | 419 - Merge fix for `hg out` failing on empty repo.
| |\ \
| | o | 418 - In some situations where a reference is being used but does not
| | | | exist in _map_git or _map_hg, silently skip the reference rather
| | | | than throwing an error. This allows hg outgoing to work on
| | | | repositories which do not contain any revisions at all.
| o | | 417 - only want heads and tags
| |/ /
| o | 416 - test-url-parsing: update expecations missed by edaadbd99074
| | |
| o | 415 - to be recognized port number in path to repository
| | |
| o | 414 - Unbreak outgoing to non-git repos with hg pre-1.9
| | |
| o | 413 - test fixes for progress cleanup
| |/
| o 412 - Fix mercurial issue2855
| |
| o 411 - Convert dulwich progress into mercurial ui.progress
|/
o 410 - test-incoming: only run on hg 1.7.x and newer
Вместо крайне уродливого кейса из gist я использую часть реального репозитория DAG (репозиторий hg-git). Надеюсь, подборка достаточно показательна для решаемой задачи.
Необходимый набор изменений (на английском языке) будет
"Диапазон A:B без второго родителя и его предков для наборов слияния"
На функциональном языке revset (TBT!)
-r "410::426 - (p2(merge()) or ancestors(p2(merge())))"
В случае полного набора наборов изменений в качестве исходника более читаемая форма будет примерно такой
hg log -r "!(p2(merge()) or ancestors(p2(merge())))"
Изменить 1
Я протестировал revset, переосмыслил методологию (вместо того, чтобы исключать, я хочу добавлять только необходимое в пустой набор), ближайшая итерация для моего варианта использования на данный момент (есть ошибки, не могу найти решение)
(p1(ancestors(p1(426))) or p1(426) or 426) and 410::426
которые (все еще) включают некоторые нежелательные изменения
hg log -G --follow-first.
- person Max Nanasy; 18.03.2013
--first-parent тогда? Как вы удерживаете других людей от того, что вы считаете анти-шаблоном?
- person Omnifarious; 19.03.2013
hg log --follow-first, кажется, делает примерно то же самое, но с несколькими положениями:
Это устарело (без объяснения, которое я могу найти).
Я не могу понять, как заставить его отображать что-либо, кроме прямой истории из текущего набора изменений (например, отображать историю после первого родителя из двух расходящихся головок (эквивалент git log --first-parent branch-a branch-b), хотя это может быть просто потому, что моего незнания Mercurial.
Он показывает пустые ветки с hg log -G:
$ hg log -G --template '{node|short} {desc|firstline}'
@ 51b90923fc9d Master C
|
o bb51d979fd68 Merge branch 'feature'
|\
| o a9ca2597ebbc Feature B
| |
| o d0a54af09272 Feature A
| |
o | 77ceb31100be Master B
|/
o b5a0b2c7468f Master A
$ hg log -G --template '{node|short} {desc|firstline}' --follow-first
@ 51b90923fc9d Master C
|
o bb51d979fd68 Merge branch 'feature'
|\
o | 77ceb31100be Master B
|/
o b5a0b2c7468f Master A
Приведенный выше пример может показаться не таким уж плохим, но см. https://gist.github.com/MaxNanasy/5184202 для примера, в котором это поведение приводит к громоздкому выводу.
Эта проблема может не иметь большого значения, если проблема № 2 неразрешима, потому что тогда hg log без -G будет единственным полезным способом использования --follow-first AFAICT.
--follow-first?
- person Max Nanasy; 18.03.2013
hg log -G -r 'branch(stable)' дает тот же результат, что и hg log -G --follow-first (включая громоздкие строки слияния)), но что, если, например. репозиторий, который я просматриваю, не находится под моим контролем и не использует именованные ветки таким образом?
- person Max Nanasy; 18.03.2013
diff -u <(hg log -r 'branch(stable)' --template '{node|short} {desc|firstline}\n' | sort) <(hg log --follow-first --template '{node|short} {desc|firstline}\n' | sort) показывает, что они охватывают разные наборы наборов изменений, тем самым подтверждая мою точку зрения о том, что делать, когда репозиторий, который я просматриваю, не находится под моим контролем.
- person Max Nanasy; 18.03.2013
-r 'branch(stable)' на самом деле является более точным отражением того, что происходит.
- person Omnifarious; 18.03.2013
git merge. Поэтому, если я объединяю функцию ветки с главной (т.е. на главной,git merge feature), текущая главная фиксация является первым родителем коммита слияния, тогда как, если я объединяю основную ветку с функцией (т.е. на функции,git merge master), текущая фиксация функции будет первый родитель коммита слияния. - person Max Nanasy schedule 15.03.2013