Hello, I try to understand "git mv"; here is how far I got: 1. Suppose I have "file" (under git control). 2. I issue "git mv file new_file". 3. Then I have to commit the renaming. I can't find anything on how to do this (neither in the git-mv- nor in the git-commit-documentation). So a hack is to use "git commit -a". Apparently this works. 4. Now I have "new_file" in the repository, but without history (except of the renaming operation), and I have still "file" in this history, but I can no longer get access to the history of "file" via "gitk file" ? This looks a bit strange to me (the renamed file has no history, the old file still lurking around, but not easily accessible). But perhaps this is as it is (since other solutions might be even stranger under certain circumstances)? Is it then possible to complete the move, that is, to really "move" the history of "file" to the history of "new_file", so that after that except of some moving-information there is no trace left of "file", while "new_file" has taken over the old history? (The motivation is as follows: I want to make the library I've developed available as a clone, but I have the problem that there are special files which I do not want to make available. So I hope that in the future with "git-submodule" I can filter out the special files, creating a (sub-)repository without the special files which then can be freely cloned. Now the special files yet are spread around, and to solve this I want to introduce a special naming-pattern for the special files (so that it becomes easy to separate the special files from the rest). But in order to do so I need the ability to fully move the special files to their renamed versions, completely with history (otherwise by browsing the history of the clone the special files would be revealed).) I would be glad for any help! Oliver - 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
