On Thu, May 01, 2008 at 03:45:07PM -0400, Avery Pennarun wrote:
> In your example above, we compare the merge-base to the new version;
> in that case, the new file is in an *existing* directory which
> definitely corresponds to src/ in #1, because the the new version has
> never even heard about src/ being deleted. Thus, the file must be
> intended to be part of the original src/, wherever it may now be.
I disagree with the final statement of the quoted paragraph above.
Just because you didn't build on the commit that moved src/* doesn't
mean the thing you put in src/ was intended to be moved along with src/.
For example:
- it might have been a new work unrelated to the existing work in src/
that got moved
- it might have been a replacement for the work in src/ that was
started before the movement. E.g., developer1 begins the replacement
work. developer2 moves the old work out of the way. When the
branches are merged, you don't want developer1's work moved.
And yes, I think those are probably less common than "it should be moved
along with src/*". My point isn't that this isn't a valuable construct,
but that we should stop short of mind-reading, and focus on making it
_easy_ to see what happened and to concisely specify the choice and
proceed.
-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
