The commit 39676192da53261efd441ccf0c67c85a341ae1a1
introduced a regression in the capability to fetch a
sha1 ref.
The command 'git lfs fetch origin <sha1>' was returning
following error: 'Invalid ref argument: [<sha1>]'.
This is due to the fact that 'git rev-parse --symbolic-full-name <ref>'
returns an empty content if the ref is a sha1.
Signed-off-by: Olivier Monnier <olivier.monnier@intel.com>
Previously only local branches were included by default. However this
way is more useful in practice; otherwise when you needed to checkout
or pull new commits from the remote you were forced to fetch on demand;
fetch --recent wouldn't pick them up without including the remote
branches. While you *can* create / update local branches without
checking out manually (e.g. git reset to manually fast-forward) to make
fetch --recent then pickup the changes from local branches, it's
too cumbersome. Including remote refs by default makes more sense for
most people, respecting the idea that you do this as an optimistic fetch
to save time at checkout/pull. However, limit the operation to the
current remote only (which makes sense anyway).
Because we changed fetch command to use --no-walk, prove that files which
were not changed at that ref but had state from previous commits are
included, i.e. that the fetch is a complete snapshot of the state at
that ref.
The first arg to fetch & pull is now a remote. In addition, the default
remote if you don't specify is now the tracking remote as in `git pull`
if it exists, and origin if that's not set. This makes it more consistent
with the underlying git workflow especially in triangular fork setups.
