On Wednesday, January 24, 2007 at 21:35:36 (+0100) Jakub Narebski writes: >Daniel Barkalow wrote: > >>> So, if the developer then commits on his branch on machine 1, all his >>> changes get undone. This has happened to him consistently --- he is >>> running git 1.4.4.1 throughout. I just reproduced it using the above, >>> and I am using 1.5.0-rc2 on machine 2, and 1.4.4.1 on machine 1. >> >> Git gets unhappy if you push into a branch that's checked out. It doesn't >> update the index or working directory, so the state after the push looks >> like the user reverted the patch in the working directory and updated the >> index. > >So you usually push into _bare_ repository, or use fetch / pull instead. Well, what we want to do is have a public repo as a collaborative hub. We would prefer this be bare. However, there are problems with that, at least with how we are doing things. For example, if I collaborate with a peer and make a few changes, I want to push my changes to my public repo and have an email sent to him, and any other interested persons, when the update hook runs. However, if I keep my private repo up-to-date with our company repo by doing periodic pulls into it, and then push into my public repo, ALL of the changes get noticed on the public repo side, and he gets a flood of mail. This also happens if I pull from my peer's repo into my private repo, make changes, and then push to my public repo --- all of his changes then get sent out to him again, and mine get mixed in with his. So, we resorted to using a non-bare public repo into which we could pull, to avoid this mess, and it appears, actually, that we have created a worse one. 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