Hi,
On Wed, 21 Mar 2007, Steven Grimm wrote:
> Johannes Schindelin wrote:
> > P.S.: It would be so nice if somebody (preferably someone who
> > previously thought manual renames were a pretty clever thing) to write
> > up the arguments, and add that to the "why automatic renaming?"
> > section of the FAQ...
>
> For some reason whenever I try to argue that we need, IN ADDITION to the
> automatic rename detection, a way to provide hints to the merge engine
> that a non-auto-detectable rename has occurred, the responses I get back
> are mostly of the form, "But the automatic rename detection handles all
> these cases that wouldn't be handled with manual rename marking!"
No. That's not the argument. The argument goes like this:
Whatever solutions you choose to handle renames, it _will_ have
problems. We chose a solution which appears to have the least
problems.
> Say you're tracking a directory full of video files. Even a slight tweak
> to one of them (to put a logo in the corner, say, while moving it into
> an "accessible by the public" directory) will result in a file that has
> no content in common at all if you look at it as purely a stream of
> bytes. Short of decoding the thing to video frames and looking for
> similarities in the images, there's no way any merge tool will ever be
> able to tell the two versions are the same file unless the user
> indicates it.
That is a particularly bad example: you are not renaming files in that
example!
> Of course, git actually does give you a way to mark renames manually:
> commit them by themselves without changing the content. The problem is
> that that overloads the "record this snapshot of the tree for posterity"
> command purely for the purpose of working around the merge tool's
> inability to detect the rename.
Not at all. You are actually recording the rename. So, you proved that you
do have a method to record a rename manually.
> It also means that if I want reliable renames, I can no longer impose
> the requirement that my project be in a buildable state at each commit.
> That doesn't seem like all that unreasonable a thing to want (but maybe
> it is?) -- I don't want to be in the situation where I say, e.g. "git
> checkout -b testbranch '@{1 day ago}'" and get a broken working copy
> because I happened to do it at just the wrong time of day. But with the
> "just commit your renames separately" approach, that's exactly what can
> happen.
Hey, I might be wrong. Why don't you prove me wrong? Code talks.
Ciao,
Dscho
-
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