On Fri, May 4, 2012 at 11:29 PM, Rich Pixley <rich.pixley@xxxxxxxx> wrote: > On 5/4/12 1:45 PM, Felipe Contreras wrote: >> >> It doesn't matter how you look at it; 'push -f' is not ideal. > > > Push -f offers an alternative A crappy alternative. > that is available in other source code control systems, (not just mercurial), Which other systems? monotone? That doesn't say much. > but not in git. It's a bit of a culture > shock to discover that it's not available in git. If you don't find a crappy problematic feature in git that you rely on--that's your problem. >> In the git world there's many ways to resolve this; push to another >> branch, push to another repo, allow ssh access to your machine, send >> the changes by mail, copy the git repo to a shared location, etc. >> *All* of those alternatives are better than 'push -f'. > > In your opinion, and that's fine. I don't need to argue this point any > longer. All of those other solutions are also available in the other source > code control systems too. And they are preferred, even the mercurial documentation says you should avoid 'push -f'. It seems you are the only one that thinks 'push -f' is ideal. >> It seems to me that this *huge* thread basically boils down to Rich >> wanting 'hg push -f', when clearly that just creates problems, even in >> mercurial. > > > Actually, I wanted a work flow that was functional for me and supported a > shared branch between multiple repositories. I think I have a process for > that now. The key things I've learned so far are: > > * Git can't cope with repository collisions, (in essence, because it's not > willing to ever create multiple heads, but also because it doesn't track the > entire pedigree of a branch, and because destructive rewrites on the > repository are common in typical git usage). Wrong. Git copes with collisions just fine; you don't need multiple heads, multiple heads are bad, even in mercurial, even mercurial documentation says so. You merge before you push; easy. > The usual way to deal with this in the git world is to use geographical > branches and triangles everywhere, Again wrong. The usual way is to have feature branches: % git checkout -b rich-reorganize-foo % git push origin rich-reorganize-foo > but using "mege before push" can provide > a way to use shared branches within git, (provided you can live within a > fair number of restrictions, which I probably can.) That's the preferred way in mercurial too; it's the sane way to do it. > * That that cryptic message means that git would need to cope with a > repository collision, which it can't do. It doesn't actually mean that the > repository is corrupt, which is what I took it to mean. > > Frankly, if the cryptic message had been clearer, I probably would never > have posted here. I'd likely have figured out that git had this restriction > and found a way to work around it on my own. Stop thinking your opinion is truth, and stop playing with words. Mercurial has the "restriction" that you can't push to a repository where you don't have permissions; that might be a restriction to somebody, but using the word restriction to describe that situation would be a cheap rhetorical device to be abrasiveness against mercurial. In mercurial and in git you should merge before you pull, if you don't like to be forced to do the sane thing; go use mercurial and be happy with the pain you create to yourself. And BTW, this is the clear message from mercurial: abort: push creates new remote head 6d2eb0a6a278! Not cryptic at all! Personally I don't care, I know a collision when I see it. If you want to help improve the error message, feel free to participate in the other thread that is meant for that. As for the workflow it's clear that the git workflow is a bit simpler than mercurial one, you just want to make your life difficult with 'hg push -f', and if you want to shoot yourself in the foot, you have mercurial for that (even though it's not recommended there either). -- Felipe Contreras -- 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