On Tuesday, February 27, 2007 at 21:22:31 (+0100) Johannes Schindelin writes: >... >Basically, shallow clones cut off branches at some point, even if those >commits have references to their parents. Ah, so a sort of temporal surgery. I don't think this will help, and I don't think this is a unique git issue, either. It happens with any system, I would think. Let's say I have 6 code repos on my system and one data repo. If I make changes in one of my code repos that requires a test data change, I have to move to my test data repo, make the change there, and commit there. Then, back in my code repo, I commit also. Now, instead of one tidy package (a commit) that holds code and test together in a coherent package, I have two separate commits in two repos that now have to be coordinated. Imagine I do more changes in similar fashion, and others do as well. Now our lead of the QA department is pulling his hair out, trying to figure out which commits in the data directory match those in the code directory so he can do regressions properly. As I said, I don't think this is a git-specific issue, but more one of organizational techniques. Perhaps there is no good answer... Bill - 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