[prev in list] [next in list] [prev in thread] [next in thread]
List: git
Subject: Re: Why git-whatchanged shows a commit touching every file, but git-log doesn't?
From: Jonathan Nieder <jrnieder () gmail ! com>
Date: 2013-01-31 19:34:34
Message-ID: 20130131193434.GG27340 () google ! com
[Download RAW message or body]
Hi Constantine,
Constantine A. Murenin wrote:
> DragonFly BSD uses git as its SCM, with one single repository and
> branch for both the kernel and the whole userland.
>
> On 2011-11-26 (1322296064), someone did a commit that somehow touched
> every single file in the repository, even though most of the files
> were not modified one bit.
"gitk --simplify-by-decoration" might provide some insight.
In the dragonfly history, it seems that imports of a packages typically
proceed in two steps:
1. First, the upstream code is imported as a new "initial commit"
with no history:
cd ~/src
git init gcc-4.7.2-import
cd gcc-4.7.2-import
tar -xf /path/to/gcc-4.7.2
mkdir contrib
mv gcc-4.7.2 contrib/gcc-4.7
git add .
git commit -m 'Import gcc-4.7.2 to new vendor branch'
2. Next, that code is incorporated into dragonfly.
cd ~/src/dragonfly
git fetch ../gcc-4.7.2-import master:refs/heads/vendor/GCC47
git merge vendor/GCC47
rm -fr ../gcc-4.7.2-import
Unfortunately in the commit you mentioned, someone made a mistake.
Instead of importing a single new upstream package, the author
imported the entire dragonfly tree as a new vendor branch. Oops.
The effects might be counterintuitive:
* tools like "git blame" and path-limited "git log" get a choice:
when looking at the merge that pulled in a copy of dragonfly into
the existing dragonfly codebase, either parent is an equally
sensible from blame's point of view as an explanation of the origin
of this code. I think both prefer the first parent here, making them
happen to produce the "right" result.
* tools like "git show" that describe what change a commit made
get a choice: when looking at a parentless commit, the diff that
brings a project into existence may or may not be interesting,
depending on the situation.
See
http://thread.gmane.org/gmane.comp.version-control.git/182571/focus=182577
for more about that.
But at its heart, this is just an instance of "lie when creating your
history and history-mining tools will lie back to you." :)
Hoping that clarifies a little,
Jonathan
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic