On 14-04-30 04:01 PM, Junio C Hamano wrote:
> Maybe I was unclear.
> I didn't mean "replace 'pull' with 'update' everywhere".  I meant
> "Introduce 'update' that lets integrate your history into that from
> the remote, which is to integrate in a direction opposite from how
> 'pull' does".  

That's what I understood.

> Then the downstream people (i.e. by definition, most of us) would
> use "git update" while integrators would use "git pull".  There is
> no workflow assumption if we do so.

Isn't merge-or-rebase a workflow assumption?  I don't think there's a good
rule of thumb for that choice.  Downstream-vs-Integrator doesn't seem like
enough, nor does it seem as simple as "'git pull' should merge" and "'git
update' should rebase" (or vice-versa).

But maybe I'm wrong and there really is only one salient axis (be it that one
or another).

>> I don't think we'll ever be able to create a One "Git Pull" To Rule Them All.
> Yes, that is exactly why I mentioned "git update".

I doubt that a new, additional command with different workflow assumptions
will be any more successful.

> Another way not to make any workflow assumption is to ask the user
> to tell us.

Yes.  But I wouldn't expect a new user to be able to answer.


To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to