On Fri, 8 Jun 2007, Johannes Sixt wrote: > > When two branches are merged that modify a subdirectory (possibly in > different intermediate steps) such that both end up identical, then > rev-list chooses only one branch. But when we filter history, we want to > keep both branches. Therefore, we must use --full-history. --full-history needs to be fixed up for this, I think. It leaves *too* many merges around, in particular, it leaves merges where both parents end up (after simplification) being related to each other. As an example, do this: mkdir hello cd hello/ git init echo "Initial state" > file-A echo "Another initial state" > file-B git add file-A file-B git commit -m "Initial commit" echo "Add a line" >> file-A echo "Add another line" >> file-B git commit -a -m "On master branch" git checkout -b another HEAD^ echo "Add a line" >> file-A git commit -a -m "On another branch" git checkout master git merge another and then do gitk --full-history file-B and notice what happens.. There was no actual developmet on branch "another", so all the commits went away, but it left the merge (because that's how --full-history works), which has now become pointless. So you should do a "merge cleanup" phase after running --full-history. Linus - 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
