I think there's a fundamental assumption built into the design of git that most programmers accustomed to a corporate environment don't understand. Namely, that each programmer owns his or her entire "repository", and can do whatever he or she darn well pleases with it at any time. Go ahead and create hundreds of transient branches as part of a scripted "merge complexity metric" calculation. Try three different refactoring strategies on different branches, abandon two of them, and prune them months later. And generally use the power of the SCM to juggle a lot of things at once, because there's no sysadmin gatekeeper stopping you, and the thing is designed and coded scalably so it doesn't grind to a halt as soon as everyone has dozens of private branches. Even if you do find a way to push git in a direction that it doesn't scale, it's no one's problem but your own -- people who pull from you are pulling the _content_ on the branches they care about, not the structure of your repository. On 11/16/06, Han-Wen Nienhuys <hanwen@xxxxxxxxx> wrote:
I agree that discussions on naming may cloud the issue, but "learning the workflow" implies that people should adapt to the limitations of their tools. That's only a viable stance when the tools are finished and completely perfect. Until that time, it would be good goal to remove all idiosyncrasies, all gratuitious asymetries and needless limitations in the commands of git, eg.
One person's gratuitous asymmetry is another's minimalism. (If the symmetric thing doesn't make any sense or can't be implemented scalably, leave it out.) It is more important that git continue to work than that it appear symmetric without reference to its function.
- clone but not a put-clone,
What possible use would that be? git is not rsync.
- pull = merge + fetch, but no command for merge + throw
pull = fetch + merge. It is (almost?) always followed by a judgment call based on the merge results. merge + throw doesn't make any sense in terms of the job at hand, which is facilitating human judgments about whether to accept someone else's work into one's working tree.
- clone for getting all branches of a repo, but no command for updating all branches of a repo.
clone is shorthand for the steps involved in setting up a new repository with content similar to an existing one. There isn't any merge involved, and no scope for human judgment, so it's simplest to clone the whole state of the remote repository (including tags and branches) and let the user blow away any branches he doesn't need. But once the clone is done, all of those branches are _truly_ _local_ -- they don't retain any reference to the remote branches, and you can commit to all of them. The only entry placed in .git/remotes is the "origin" of the new clone, which is the "master" of the remote repository. That's for the user's convenience, and is about the only thing in the new clone that _isn't_ a copy of something in the remote tree. So the "update all" process wouldn't look anything like a clone, it would be a fetch and replay of each remote branch onto the corresponding local branch. You and Carl seem to want "git clone" not only to copy the heads of the remote branches but to populate .git/remotes with trackers for all of those branches, and then to start each "git update" by polling all of the remote repositories to see if branches have been created or deleted, then pull every branch in sight. What do you do when "upstream" creates a branch with the same name as a local branch you have created? How do you deal with branch points that don't exist in your repository because you touched one of the "tracker" branches between pulls? In short, if you want a local, read-only tracker for a whole remote repository instead of a branch that's actually published to you (and maintained accordingly), you might consider s/git/rsync/. Cheers, - Michael - 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