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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to