Caleb Cushing wrote: >> Not sure I understood this completely, but I've found it >> helps to make the rename/move as a separate commit, then >> start changing stuff. In other words, do too many things in >> the same commit, and you could lose this coolness. > > well I the problem is.. in a sense I need to unmerge 2 files that I > once merged... they currently have the same name and are in the same > place, and where I merge them from they'll continue to have that name > (although they are different files with the same purpose) but I want > them to have different names and spots in my tree/repo. > Not having done this myself, I'd take this following suggestion with a grain of salt! :-) It seems to me that git is smart enough to figure out where contents get moved to, once. Of course, if you have conflicting moves in the same repo, git's automation falls down. So, if you need to move the "same" file in different repositories to different places, you need to do it via an intermediate repo that will be able to "remember" which movement you chose. e.g. upstream A: data <- contains one set of data upstream B: data <- contains another set of data pull upstream A into intermediate A, move the file as desired, and commit: Intermediate A: data/upstreamA pull upstream B into intermediate B, move the file as desired, and commit: Intermediate B: data/upstreamB merge Intermediate A and Intermediate B in master: master: data/upstreamA data/upstreamB Then, subsequent pulling from upstream A into Intermediate A will "remember" the move of "data" to "data/upstreamA", and similarly with B. Subsequent merges of Intermediates A & B into master will end in the desied result. Hope this helps. Rogan -- 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
