In the absence of merging with the master, the last git rev-list master..feature/new-branch entry will be the one you want. a..b in rev-list gives you all the commits in history b that are not in history a . But since you merged, all the commits in the history of elements / new branches are also in the master story, so we need to be a little smarter.
The question you linked (rather, this answer to it ) gives a very good start. The trick is to use --first-parent so as not to take into account the right side of all merges into the master as part of the main story. git rev-list --first-parent master gives you all the commits that were passed directly to the host and does not show any commits that have been merged. Alas, --first-parent does not combine with .. way we want, so we have to make our own equivalent .. using diff . We can use diff to take our list of all commits in the history of objects / new branches and delete all commits that are in the main “direct” history. I used backslash to split one command into several lines: -
diff --new-line-format=%L --old-line-format= --unchanged-line-format= \ <(git rev-list --first-parent master) \ <(git rev-list --first-parent feature/new-branch)
The diff parameters allow you to print lines that are in the second input, but not the first input, without the + or - elements and without the headers. I am not very good at POSIX, so there can only be that version of GNU diff. Similarly, for the <( ) operator on the other two lines, you need bash or zsh. If you need to use a different shell, you probably have to use temporary files.
The first entry (one of the lines to ignore) is a “direct” story for mastering, as we found out above; the second entry is the “direct” history of the function / new branch. The output of the command is all the commits that were tied to the function / new branch "directly", but not in order to "directly" learn where "directly" means "not through merging". The inclusion of --first-parent in the second input is necessary to avoid including any commits that were merged into master before the branch function / new branch, but it will have the side effect of excluding commits from any other branches that have been merged into the / function new -branch (which doesn't matter if you only want to commit the first commit).
The output is in reverse order, as usual, so the last line of output is the command you are interested in.
I am very interested to know what you are trying to achieve with this information, since it does not seem to fit the Git world model at all. Git users know and expect that the history of the branch includes the history from the ancestor of the branch, and the history of any merger into it.