Jem [off-list ref] writes:
Pulling without any local commits deletes staged files without
warning. Is this intended behaviour?
It is an unanticipated corner case interfering our attempt to be too
nice that backfired.
For a long time, having no history and asking to pull was forbidden,
because "git pull" is is about combining two (or more) histories
together and pulling when you have no history is a nonsense --- you only
have one history (the history from the other side) and there is nothing
to combine.
Later we tried to be nicer, as some new users triggered an error when
doing "git init" in an empty directory followed by "git pull", by
redefining "merge" into no history to mean resetting to the other
history.
This solved "git init && git pull", but we did not anticipate anybody
would do a "git init && git add && git pull" sequence, to which there is
no sane outcome other than just erroring out.
A patch to give that only sane outcome may look like this.
git-pull.sh | 3 +++
1 file changed, 3 insertions(+)
diff --git a/git-pull.sh b/git-pull.sh
index 2a10047..da102d0 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -261,6 +261,9 @@ esac
if test -z "$orig_head"
then
+ test $(git ls-files | wc -l) = 0 ||
+ die "$(gettext "Uncommitted changes in the index")"
+
git update-ref -m "initial pull" HEAD $merge_head "$curr_head" &&
git read-tree -m -u HEAD || exit 1
exit