Re: bisect / history preserving on rename + update

From: David Kastrup <dak@gnu.org>
Date: Aug 14, 2007, 10:03 UTC
Message-ID: <86d4xqh1r5.fsf@lola.quinscape.zz>
In-Reply-To: <1187080681.12828.174.camel@chaos>

Thomas Gleixner <tglx@linutronix.de> writes:

Show 29 quoted lines

> 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