Thomas Gleixner <tglx@xxxxxxxxxxxxx> writes: > is there a built in way to handle the following situation: > > file A is renamed to B > file A is created again and new content is added. > > I found only two ways to do that, which both suck: > > 1) > git-mv A B > git-add A > git commit > > results in a copy A to B and lost history of B > > 2) > git-mv A B > git commit > git-add A > git commit > > preserves the history of B, but breaks bisection because > A is needed to compile > > I have no real good idea how to solve this. After staring at the git > source for a while, I think that 1) is quite hard to solve. A sane > solution for 2) might be to add a flag to the second commit, which > bundles the two commits for bisection. > > Any other solutions ? You are confused, probably because something like "git-mv" exists (it is just syntactic sugar, and it might be less confusing to users to actually remove it). git does _not_ track file histories. Not the tiniest bit. It _constructs_ them when you ask it nicely. All commands that display "tracking" information have options like -M -C -R and so on that tell git just how much effort it should spend on keeping abreast of copying/renaming/modification. -- David Kastrup - 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
