Re: scan entire repo for changes to file

[Jonathan Nieder <jrnieder@gmail.com>]

Junio C Hamano wrote:
> Jonathan Nieder <jrnieder@gmail.com> writes:
>> Martin von Zweigbergk wrote:
>>> On Thu, Nov 11, 2010 at 8:28 PM, Neal Kreitzinger <neal@rsss.com> wrote:

>>>> Is there a way to scan my entire repo (many unmerged branches) for any
>>>> changes to a file?
>>>> e.g.
>>>> $ git log * -- somepath/myblob
>>>> would return all commits in the repo that changed myblob.
>>>
>>> Might replacing '*' by '--all' give you what are looking for?
>>
>> Probably with --full-history if you want to know what happened on
>> historic branches, too.
>
> You would need to clarify what you mean by "historic branches" here.

Yes, quite right.  I meant failed experiments of a certain kind.

The "git log -- path" facility can be used to learn the nature and
origin of a collection of files.

	$ git log --graph --oneline -- block-sha1/
	* 078e9bc msvc: Select the "fast" definition of the {get,put}_be32() macros
[...]
	* d7c208a Add new optimized C 'block-sha1' routines

The result is a list of commits that explains the current state of
that file, without commits irrelevant to that purpose.

What happens to merges?  Consider a history like this (history flowing
left to right):

 A --- B --- C --- D --- E --- F --- G ---- M --- H
              \                            /
               I ...                  ... J

There is a main line and a side branch.  On the mainline, the selected
files have been getting better and better.  The side branch does not
touch those files.  Then the side branch would irrelevant to the
history of those files.

To flesh out this idea, git history simplification.  When walking
through history, if a merge is encountered (M) and one of the parents
already matches the resulting state (G), then git will follow that
parent and ignore the others.  If no parent matches the resulting
state, git follows all parents.  So we get a simpler history that
should still adequately explain the result.

Consider another scenario, though:

 A --- B --- C --- D --- E --- F --- G ---- M' --- H'
              \                            /
               I' ...                ... J'

There is a mainline and a side branch.  On the mainline, the selected
files have been getting better and better.  On the side branch, there
was an abortive experiment; some changes were made to the selected
files there, but none of these changes survived as far as the merge M'.

The side branch is _still_ irrelevant to the purpose of explaining the
current state of those files.  Git will notice that (G matches M') and
ignore the side branch.  But if your goal is not to explain the
current state but to delve into the history of all thoughts this
project remembers on a subject, such history simplification would not
be appropriate and you should be using the --full-history option.

The History Simplification section of git-log(1) has details.

Caveat: the list of commits selected with --full-history --dense do
not convey a coherent history.  M' is uninteresting but some of the
commits on the I' ... J' track are; how do we stitch the interesting
commits together?  So history visualization tools cop out and show
all merges when --full-history is enabled.  (Put another way,
--parents --full-history implies --no-dense.)

Hope that helps.