From: Junio C Hamano <gitster@pobox.com>
Date: Thu, 05 Feb 2009 00:04:43 GMT
Subject: Re: Comments on "Understanding Version Control" by Eric S. Raymond
Message-ID: <7v4oz9lpes.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <20090204235436.GA8945@mit.edu>

Theodore Tso <tytso@mit.edu> writes:

> 1) In branch A, the directory src/plugin/innodb-experimental is
>    renamed to src/plugin/innodb, and in branch B, a commit (i)
>    modifies a file src/plugin/innodb-experimental/table.c, and (ii)
>    creates a file src/plugin/innodb-experimental/mod-schema.c.  This
>    commit in branch B is then pulled into branch A, where the
>    directory rename has taken place.  The user may not know that a
>    directory rename had taken place under the covers, so they don't
>    give any magic options when they run the "git cherry-pick" or "git
>    merge" command.  Does the right thing happen such that the right
>    file in src/plugin/innodb is modified, and the new file is created
>    in src/plugin/innodb, even though in the original commit, the
>    changes were made to files in src/plugin/innodb-experimental?

Careful.

Although it is reasonable to expect that existing file's modification will
move to innodb/ directory, it is not as clear-cut as some people seem to
assume that the new file should always be created in the new directory
innodb/.  You seem to imply you understand the issues by having the second
example, though.