Ваш вопрос подразумевает концепцию коммита, «принадлежащего» ветви, или ветви, состоящей из коммитов. Возможно, именно так другие инструменты смотрят на мир, но git действительно не работает таким образом. Так как я понимаю, что вы хотите просматривать коммиты, я постараюсь ответить на вопрос в этом духе, но понимаю, что не будет никакого хорошего решения этой проблемы, потому что git сам не "помнит", какая ветвь "родитель" вашей ветви.
Итак ... ваш собственный ответ имеет два недостатка. Я рассмотрю их, а затем предложу другой подход, который мог бы работать лучше (хотя, имхо, все еще не идеально).
Проблемы с вашим ответом:
Во-первых, он не всегда может получить то, что вам нужно. Что если ветка была создана из вашей ветви?
O -- x -- x -- x <--(master)
\
A -- B -- C -- D <--(your_branch)
\
x -- x <--(other_branch)
На этом рисунке - опять же, если мы предположим, что коммиты и ветки связаны так, как предлагает ваш вопрос, - вы бы увидели your_branch как A, B, C и D, верно? Но если вы дадите log исключений для баз слияний всех ветвей с your_branch, одна из баз слияний будет B, поэтому A и B будут исключены.
Это изображение также иллюстрирует, почему нет реального решения поставленной проблемы. Я использовал визуальные подсказки, чтобы подразумевать, что other_branch был создан из your_branch, а не наоборот, но что касается того, как git хранит свои данные, это изображение такое же, как и то, где your_branch считается быть созданным из other_branch
O -- x -- x -- x <--(master)
\
A -- B -- x -- x <--(other_branch)
\
C -- D <--(your_branch)
Так что ничто git магазины не может сказать, хотите ли вы видеть A и B или нет.
Я добавлю, даже если вы говорите «ах, но я никогда этого не делаю», возникает другая возможная проблема, если вы когда-нибудь объедините ветку с ее родителем, но затем продолжите работу над ней. Все коммиты до слияния будут исключены из вашего вывода.
Во-вторых, это слишком сложно. Вместо исключения "базы слияния между и моя ветка ", почему бы просто не исключить каждую из других ссылок?
Другой подход:
Если git не хранит достаточно информации, чтобы сделать то, что Если вы хотите, то лучшее, что вы можете сделать, это следовать дисциплинированному подходу для преднамеренного хранения дополнительных данных.Например, вы можете создать псевдоним для ветвления, чтобы каждый раз, когда вы создаете ветку some_branch, вы также сразу же создавали легкий тег some_branch_root. Тогда вы всегда можете записать some_branch_root..some_branch.
Даже тогда, если у вас есть боковые ветви, которые объединяются обратно в some_branch, вы увидите их. Вы могли бы смягчить это, дав log --first-parent, но затем, если вы объедините свою ветвь с чем-то другим, а затем быстро перенесете свою ветвь через это слияние, у вас возникнут еще большие проблемы.
Самая большая проблема с этим подходом состоит в том, что теги будут должны быть перемещены, если вы перебазируете свою ветку, и, вероятно, должны быть удалены, если вы удаляете свою ветку. Снова комбинация сценариев и / или просто решите отсутствие определенных действий может смягчить проблему.
Поэтому я бы сказал, что это решение намного проще и приближает вас (скажем, на 95%) к тому, что вы хотите; но, тем не менее, это работает, только если вы можете сделать некоторые предположения о том, как выполняются ветвления и слияния в вашем репо.