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.

   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,
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to