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.
M.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
