Paul Jakma <paul@xxxxxxxx> writes: > For sake of argument assume the workflow corresponds to: > > o-o-o-o---o--o > / \ > --o----------------m-> > > And collapsing just the 'oops, made a typo' commits so it looks like: > > o-----o------o > / \ > --o----------------m-> > > > The /real/ point, other than workflow, is: > > - can we track 'rename and rewrite'? Yes. Especially the collapsing is 'oops, made a typo' kind. Interestingly enough, there are two levels of "rename tracking" the current git does. Whey you run "git whatchanged -M", you are looking at renames between each commit in the commit chain, one step at a time. There as long as the rename+rewrite does not amount to too much rewrite, you would see what should be detected as rename to be detected as renames. I found the current default threshold parameters to be about right, maybe a bit too tight sometimes, though. If you want to loosen the default, you can specify similiarity index after -M. The way recursive merge strategy uses the rename detection, unlike what whatchanged shows you, does not use chains of commits down to the common merge base in order to detect renames (my recollection may be wrong here -- it's a while since I looked at the recursive merge the last time). It just looks at the two heads being merged, and detects similarility between them. So it does not make _any_ difference with the current implementation of recursive merge if you kept a history full of "honest but disgusting" commits or collapsed them into a history with small number of "cleaned up" commits. One thing it _could_ do (and you _could_ implement as another merge strategy and call it "pauls-rename" merge) is to follow the commit chain one by one down to the common merge base from both heads being merged, and analyze rename history on the both commit chains. Then, you would get better rename+rewrite detection than what it currently does. HOWEVER. If you have that kind of rename-following merge, a workflow that collapses a useful history into a single huge commit "Ok, this commit is a roll-up patch between version 2.6.14 and 2.6.15" becomes far less attractive than it currently already is. At that point, you _are_ throwing away useful history. - : 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