Felipe Contreras <felipe.contreras@xxxxxxxxx> writes:
> That doesn't change the fact that 'git fetch .' does not make any
> sense whatsoever. The user *will* get confused when (s)he does 'git
> fetch' and nothing happens. The problem is not solved.
>
> % git checkout -b fixes master
> % git fetch
> % git branch -u master
> % git fetch
>
> # scratch head
# reads manual, perhaps?
Why do you declare without justification that "git fetch ." does not
make sense? If you come from "git pull" is "git fetch" + "git merge",
and if your current branch is integrating with your local branch, it
is natural that "git fetch" that does not say where to fetch from
fetches from your local repository (object-transfer wise, it is a
no-op) and update FETCH_HEAD. You can say "it is not necessary, as
we can directly go to @{u}", but that is different from "it does not
make any sense".
I think the real cause of the problem is that some people advocate
the use of "git fetch" that does not say "from where" and "get
what". When the user understand what it does and what it does it
for, not having to type is a convenience, but as a recipe to be
blindly followed, it leaves the new people in the dark.
--
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