Johannes Sixt <j.sixt@xxxxxxxxxxxxx> writes:
> Is there a combination of options that does --first-parent on the full
> history, but then --dense on the resulting strand of pearls with respect
> to a certain path?
The way these features are combined in the revision walker is
pretty much hardwired.
Marking commits that do not change the tree with respect to set
of paths as irrelevant (i.e. REV_TREE_SAME) comes first, and the
merge simplification happens about the same time. Following
first-parent-chain only works on the result of that. If you
tell a single-tree form of diff-tree to be applied to the
resulting commit (i.e. give -p/--stat/--name-status and friends
to "git log"), they work on the resulting commit with the same
pathspec unless --full-diff is given.
Side note: incidentally, this is why you do not get "git
log $single_pathspec" to notice a file that matches the
single pathspec was created by copying or renaming.
But there is a deeper issue between "first-parent" and the
simplification (both merge history simplification and dense
processing) with pathspec. They are based on quite different
viewpoint to what the history is.
The first-parent view is about what was seen by who made merges.
If you follow a branch that never fast-forwards (e.g. my "next"
is that way) using --first-parent, you will see the evolution of
the branch: "I merged updates to this topic, then I merged
updates to that topic, etc." Even though there is no meaning to
the concept of "branch" other than "a sticky label that moves
around, mostly going forward, on a possible DAG of commits", it
makes you pretend that one person and nobody else "owns" the
branch and grows it, and ask only about what that one person did
and saw. It is probably against the distributed nature of git
history that fast-forward merge can happen anytime and there is
no true mainline nor owner of the branch.
On the other hand, history simplification based on pathspecs is
about what changed the area. It does not matter the feature was
cooked in a side branch (which is a second class citizen in the
world view "first-parent" takes) --- if "the mainline" did not
touch that area and the changes to the area were merged from a
side branch, the history on that side branch is much more
interesting than the history of the mainline when you are
inspecting the changes to the area specified by a set of paths.
The philosophy is more natural to the distributed nature of git
history.
These two inherently do not mesh well.
Having said that, culling with first-parent first and then
applying pathspecs may have its own use. You will be asking
this question:
I do not care about the details of what other people did.
Among the actions that was made to this branch of mine, find
the ones that change the area.
This will not find the "Make fetch built-in" commit if you dig
from 'master' (because that was not something that happened on
"master"), but will find the merge to the "mainline" that
touched the file.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
