Theodore Tso <tytso@xxxxxxx> writes: > Careful; that's actually an argument for recording the directory > rename. I do not think so. More precisely, I can see people could make that argument, but I think that argument is weak. Suppose the original project's implementor only knew about innodb interface, so he had the "database interface" directory and innodb access method file in the source tree, perhaps at <db/inno.c>. I forked the project, and added gdbm support at <db/gdbm.c>. You also forked the project without knowing what I was working on, and you started working on refining the innodb support. All the while, the development community started discussing how the source tree should be organized to support multiple backends, and you learned that the plan is to have one directory per larger backend, while keeping single file ones in <db/*.c>. Specifically, you learned that innodb related code will be stored in <innodb/*.c>, and there may be other <somedb/*.c> and <someotherdb/*.c> groups added, but you are not interested in anything but enhancing innodb support. You rename "scm mv db innodb" and then add <innodb/enhanced.c>, or perhaps you may have done it the other way, i.e. added <db/enhanced.c> and then renamed "scm mv db innodb". Suppose you would want to merge my changes, but the upstream's plan hasn't happened yet. Neither of us merged from the upstream in the meantime. Recording your "scm mv db innodb" as "the user's intention to rename directory" does not help when you want to merge with me to handle the new file <db/gdbm.c> I added. You not only need to record the "intent to rename db to innodb", but need to know that the validity of that "intent to rename" is contingent on the absense of anything unrelated to innodb in db/ directory, in order to merge the two branches correctly. Otherwise you will end up moving my <db/gdbm.c> to <innodb/gdbm.c>. The correct outcome in this case would probably be to leave it as it is. > In other cases, maybe the right thing *is* to drop the new file in the > original directory. So as the Hg and Bzr apologists might say, if the > SCM actually records whether the user intention was a *directory* > rename, versus a series of *file* rename/moves, then it becomes > obvious what the right thing to do. See how that argument is flawed? The point of my example is that the line between your example (1) and (2) in the previous message is blurry. -- 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
