Re: --first-parent plus path limiting

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 29, 2008, 08:47 UTC
Message-ID: <7vk5ltow61.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <479EE405.1010001@viscovery.net>

Johannes Sixt <j.sixt@viscovery.net> writes:

Show 6 quoted lines

> While trying to find out when builtin-fetch.c was merged into master, I
> noticed that this:
>
> $ git log --first-parent --pretty=oneline -- builtin-fetch.c
>
> lists b888d61c (Make fetch a builtin), which I did not expect.

Why didn't you?

> This one
> doesn't list it, as expected:
>
> $ git log --first-parent --pretty=oneline

Why did you expect that? This tells "follow only the first parent chain, ignoring all merges".

As most everything that is nontrivial is developed on a topic branch in git.git, "Make fetch a builtin" will not be on the first parent chain of the "master".

The former is about "First simplify the history with respect to builtin-fetch.c, and then follow the first-parent of the simplified history.

As the builtin-fetch topic was worked on for some time on its own topic, like this:

 ---o---o---o---...---o---A---M--- master
     \                       /
      o---o---X---...---o---B

So if a commit M has two parents A and B, and the file in M is the same as the file in B, the history simplifies commit A and the side branch that leads to it away. Perhaps commit A was the first parent and B was the last commit of the fetch-pack series, and "Make fetch a builtin" was an ancestor of B, like X above.

$ gitk b888d61c^..v1.5.4-rc5 -- builtin-fetch.c

is somewhat interesting to view.