Re: [PATCH resend] make "git push" update origin and mirrors, "git push --mirror" update mirrors

"Shawn O. Pearce" [off-list ref] writes:

But then they later wonder why they need `git pull origin branch`
to merge in branch, when they usually just say `git pull`.  What is
the need for that funny keyword `origin`?  Why do I have to say
where to get the branch from sometimes and not others?
...
Just take the above as the rantings of someone who knows git a
little too well, and has tried to teach it to people who don't,
and they all have asked about the funny (to them) need for origin
in git-pull/git-push command line sometimes (no refspecs) and not
others (with refspecs).

What's the constructive suggestion for improvement we can draw from this
after all?  Should we deprecate the defaulting of "origin" so that
everybody now should always say "git pull $where"?  In other words, make
people more aware that what _they_ do is the special case to have only one
remote to interact with?

What's the constructive suggestion for improvement we can draw from this
after all?  Should we deprecate the defaulting of "origin" so that
everybody now should always say "git pull $where"?

branch.*.remote would still provide a default, wouldn't it?  And if 
master is by default set up to track origin/master, the behavior 
wouldn't change.

In other words, make
people more aware that what _they_ do is the special case to have only one
remote to interact with?

I think "git pull" is different, because it is more often fetching from 
one defined place (while Shawn said that he has a need for one-to-many 
"git push"es and so do I).  For "git pull", the branch config provides a 
valuable default more often than for "git push".

Paolo

On Sun, Apr 27, 2008 at 10:22:47PM +0200, Paolo Bonzini wrote:

I think "git pull" is different, because it is more often fetching from  
one defined place (while Shawn said that he has a need for one-to-many  
"git push"es and so do I).  For "git pull", the branch config provides a  
valuable default more often than for "git push".

I think it is highly dependent on your workflow. I would have said the
exact opposite.

For example, on one project, I keep a "working" repo on my laptop where
I develop and integrate work from others. I get their work by pulling
individually from other developers. But when I push, it always goes to
one place: my "publish" repo, where the other developers will grab my
changes.

In that workflow, I pull from many different places, but always push to
one. I assumed that is actually similar to the Linus "integrator"
workflow (although I think he just does one-shot pulls without defining
remotes).

-Peff

Junio C Hamano [off-list ref] wrote:

"Shawn O. Pearce" [off-list ref] writes:

quoted

But then they later wonder why they need `git pull origin branch`
to merge in branch, when they usually just say `git pull`.  What is
the need for that funny keyword `origin`?  Why do I have to say
where to get the branch from sometimes and not others?

What's the constructive suggestion for improvement we can draw from this
after all?  Should we deprecate the defaulting of "origin" so that
everybody now should always say "git pull $where"?

Yes, I think that is what I was thinking.  By making users always say
where they are pulling, fetching or pushing from/to it becomes less
weird when you have to give a refspec too.

But this clearly harms the `git pull` case that relies upon the magic
branch.$name.remote and branch.$name.merge keys, as now git-pull is
expecting the user to supply a remote name, but one was already saved
for this current branch.

It also clearly harms people who have only origin and want to grab
updates from there with just `git fetch` or `git pull`.  Such a
change would be asking these users to enter a longer command line.

On the other hand, I think it would teach those users how to better
make use of git, and may cause less questions when they have to
step slightly outside of their normal use case and specify a refspec.

In other words, make
people more aware that what _they_ do is the special case to have only one
remote to interact with?

My special case is always the other guys' common case.  You can't
please everone.  But here I think that _our_ special case (where we
always give the remote name/URL to fetch/pull/push) helps users to
learn the tool better, because it erases a special case from their
vocabularly of Git commands.

-- 
Shawn.

Yes, I think that is what I was thinking.  By making users always say
where they are pulling, fetching or pushing from/to it becomes less
weird when you have to give a refspec too.

But this clearly harms the `git pull` case that relies upon the magic
branch.$name.remote and branch.$name.merge keys, as now git-pull is
expecting the user to supply a remote name, but one was already saved
for this current branch.

I would have no problem at all in removing the defaulting to "origin". 
Leaving the magic branch.<name>.{remote,merge} as the only case where 
0-argument "git pull" is allowed, would be much simpler to explain, and 
would not impact the "centralized" operation mode.

Paolo

quoted

I think "git pull" is different, because it is more often fetching from  
one defined place (while Shawn said that he has a need for one-to-many  
"git push"es and so do I).  For "git pull", the branch config provides a  
valuable default more often than for "git push".

I think it is highly dependent on your workflow. I would have said the
exact opposite.

Ah, to do so I always do fetch+gitk+merge (or cherry-pick instead of 
merge).  I use "git pull" (without arguments) only when I can blindly 
not care about what's on the other side, e.g. because it's Junio who 
assures it is good. :-)

I actually think I never use "git pull" with arguments, but that's 
evidently me.

Paolo

Shawn O. Pearce wrote:

It also clearly harms people who have only origin and want to grab
updates from there with just `git fetch` or `git pull`.  Such a
change would be asking these users to enter a longer command line.

Maybe this can be accomodated by having git fetch/git pull reference
all targets specified in the config file if none are specified on the
command line?

On the other hand, I think it would teach those users how to better
make use of git, and may cause less questions when they have to
step slightly outside of their normal use case and specify a refspec.

I've been using git since november, and I found the magic "origin"
default one of the most confusing aspects (to figure out when it applies
and when not, and why (or why not)).
-- 
Sincerely,                                                          srb@cuci.nl
           Stephen R. van den Berg.

On Mon, Apr 28, 2008 at 07:07:11AM +0200, Paolo Bonzini wrote:

Ah, to do so I always do fetch+gitk+merge (or cherry-pick instead of  
merge).  I use "git pull" (without arguments) only when I can blindly not 
care about what's on the other side, e.g. because it's Junio who assures 
it is good. :-)

Well, I lied a little; I also use fetch + examine + merge. But the idea
about arguments holds true for "git fetch".

-Peff

On Mon, Apr 28, 2008 at 05:09:48AM -0400, Jeff King wrote:

On Mon, Apr 28, 2008 at 07:07:11AM +0200, Paolo Bonzini wrote:

quoted

Ah, to do so I always do fetch+gitk+merge (or cherry-pick instead of  
merge).  I use "git pull" (without arguments) only when I can blindly not 
care about what's on the other side, e.g. because it's Junio who assures 
it is good. :-)

Well, I lied a little; I also use fetch + examine + merge. But the idea
about arguments holds true for "git fetch".

BTW, I find myself decreasingly using "git fetch" in favor of "git
remote update" which handles fetching from multiple remotes. That seems
to be analagous to what you want with "git push". IOW, maybe instead of
changing the default behavior of "git push" you would be happy with a
"git remote push" which impacted multiple remotes.

-Peff

BTW, I find myself decreasingly using "git fetch" in favor of "git
remote update" which handles fetching from multiple remotes. That seems
to be analagous to what you want with "git push". IOW, maybe instead of
changing the default behavior of "git push" you would be happy with a
"git remote push" which impacted multiple remotes.

I'm preparing a patch that has "git fetch" fetch from all remotes (same 
as "git remote update" with no groups defined) and "git push" push to 
all remotes.  I think this is much more sound; and it's not really as 
easy as this, but that's the idea. :-)

As always, thanks to the list for straightening my first design.  It 
happened for --track, for prepare-commit-msg (by the way, I am using it 
now that it's in 1.5.5, and it helps me so much) and for this too.  I 
hope that my improvements to git is worth your time, guys.

Paolo

Hi,

On Mon, 28 Apr 2008, Paolo Bonzini wrote:

I'm preparing a patch that has "git fetch" fetch from all remotes (same 
as "git remote update" with no groups defined)

Funny, I would think that this functionality belongs into git-remote 
instead of git-fetch.  Especially since it would be possible to reuse the 
code you referred to...

Ciao,
Dscho

Johannes Schindelin wrote:

Hi,

On Mon, 28 Apr 2008, Paolo Bonzini wrote:

quoted

I'm preparing a patch that has "git fetch" fetch from all remotes (same 
as "git remote update" with no groups defined)

Funny, I would think that this functionality belongs into git-remote 
instead of git-fetch.

Maybe, but I'm pretty satisfied with the result.  It would take more 
effort than that to add all the functionality within "git remote 
update", and my patch series removes most of the magic associated with 
"origin".

Especially since it would be possible to reuse the 
code you referred to...

I checked and there's not much to reuse, since we don't care about 
groups or anything else.

Stay tuned -- I'm looking forward to any criticism.

Paolo

Hi,

On Mon, 28 Apr 2008, Paolo Bonzini wrote:

Johannes Schindelin wrote:

quoted

On Mon, 28 Apr 2008, Paolo Bonzini wrote:

quoted

I'm preparing a patch that has "git fetch" fetch from all remotes 
(same as "git remote update" with no groups defined)

Funny, I would think that this functionality belongs into git-remote 
instead of git-fetch.

Maybe, but I'm pretty satisfied with the result.  It would take more 
effort than that to add all the functionality within "git remote 
update", and my patch series removes most of the magic associated with 
"origin".

Then I must have misread your statement "same as "git remote 
update" with no groups defined".

Ciao,
Dscho