On Fri, 17 Nov 2006, Han-Wen Nienhuys wrote: > > Until that time, it would be good goal to remove all idiosyncrasies, > all gratuitious asymetries and needless limitations in the commands of > git, eg. Well, a lot of the assymmetries aren't actually gratuitous at all. > - clone but not a put-clone, As mentioned, in order to "put-clone", you generally have to "create" first, so the "put-clone" really makes no sense. The _true_ reverse is really your - "git init-db" on both sides - "git pull" (your workflow ;) on receiving - "git push" on sending. The fact that we can do "git clone" on the _receiving_ side is an assymmetry, but it's not gratutous: when receiving we don't need any extra permissions or setup to create a new archive. In contrast, when sending, you do have to have that "get permission to create new archive" phase. > - pull = merge + fetch, but no command for merge + throw Again, this is not gratuitous, and the reason is very similar: when you pull, you're pulling into something that _you_ control and _you_ have access to, namely your working directory. In order to merge you have to have the ability to fix up conflicts (whether automatically or manually), and this is something that you _fundamentally_ can only do when you own the repo space. Again, when you do "push", the reason you can't merge is not a "gratuitous assymmetry", but a _fundamental_ assymmetry: by definition, you're pushing to a _remote_ thing, and as such you can't merge, because you can't fix up any merge problems. See? In many ways, if you want _symmetry_, you need to make sure that the _cases_ are symmetrical. If you have ssh shell access, you can often do that, and the "reverse" of a "git pull" is actually just another "git pull" from the other side: ssh other-side "cd repo ; git pull back" Now they really _are_ symmetrical: "git pull" is really in many ways ITS OWN reverse operation. But "push" and "pull" _fundamentally_ aren't symmetric operations, and you simply cannot possibly make them symmetric. Any system that tries would be absolutely horrible to use, exactly because it would be either: - making local/remote operations totally equivalent This sounds like a "good" thing, but from a real user perspective it's actually horribly horribly bad. Knowing the difference between local and remote is what allows a lot of performance optimizations, and a lot of security. Your local repo is _yours_, and nobody can take that away from you, and that's a really fundamental reason for why the symmetry cannot exist, and why local/remote operations MUST NOT be something that you can mix without thinking about them, - limit local operations in a way to make them effectively unusable and unscriptable. You'd basically have to do everything even _locally_ through some server interface, and you'd not be allowed to ever touch your local checked-out repository directly. Again: local repositories really _are_ special, because you can touch the checked out copy. If you try to suppress that, you're screwed. > - clone for getting all branches of a repo, but no command for > updating all branches of a repo. As in sending? Sure there is: use "git push --all". It will push out every branch (and tag) you have. Add "--force" if you want to make sure that it also pushed out branches even if the result isn't a strict superset (of course, the receiving end may actually end up refusing to take it, there's a option for the receiver to say "I will refuse any update that isn't a strict superset of what I had"). If you mean as in "receiving new branches", then yeah, you do have to script it, with some fairly trivial "git ls-remote" to make sure you get the new remotes. 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