On 11/26/07, Michael Poole <mdpoole@xxxxxxxxxxx> wrote: > Jan Hudec writes: > > > On Mon, Nov 26, 2007 at 14:50:35 -0500, Michael Poole wrote: > >> Jan Hudec writes: > >> > >> > The basic pull/push actions are: > >> > > >> > git pull: Bring the remote ref value here. > >> > git push: Put the local ref value there. > >> > > >> > Are those not oposites? > >> > > >> > Than each command has it's different features on top of this -- pull merges > >> > and push can push multiple refs -- but in the basic operation they are > >> > oposites. > >> > >> I think that is in absolute agreement with David: Ducks swim on the > >> surface of the water and lobsters swim underneath. Why consider the > >> different features on top of where they swim? > >> > >> The thing about git-pull that surprises so many users is the merge. > >> There's a separate command to do that step, and git-pull had a fairly > >> good excuse to do the merge before git's 1.5.x remote system was in > >> place, but now the only really defensible reason for its behavior is > >> history. > > > > When I first looked at hg -- and that was long before I looked at git -- > > I was surprised that their pull did NOT merge and you had to do a separate > > step. Partly because doing those two steps is quite common. > > Frequency of use is a good argument for having one command that does > both. It is not a good argument that "fetch, then merge" should be > called "pull" or is the opposite of "push". I'm starting to think that things oriented around the default names of master and origin needs rethinking. Everything should use explicitly named remotes. You could always do something like set a default remote repository, but that is different than using the magic name 'origin'. -- Jon Smirl jonsmirl@xxxxxxxxx - 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
