But today (a mere ~12h after the original clone, and without having
done any edits to the tree at all), I did a "git pull" and the merge
failed due to conflicts. The output was:
I would suggest:
doing 'git status' before pull
using an alias 'git up' that doesn't do pull:
git config --global alias.up "!git remote update -p && git merge --ff-only
@{u}"
which will fetch and then merge if fast-forward. If it's not
fast-forward, you may want to rebase your local changes instead,
or at least figure out what's up and decide, rather than letting pull
make a non-ff merge that you didn't intend.
Are you making local commits?
For what it's worth, I have a private git repo with ~10K commits over a
few years that has NetBSD and other stuff imported (snapshots imported,
not history converted!!), and other than git being slow it's been solid.
If you interrupt git in the middle of a checkout the index can be in a
bad state and in need of reset --hard. (Because it stats all those
files on 'git status', which isn't fair to gripe about because cvs
doesn't have an equivalent command or perhaps 'cvs -n update', which is
obviously much slower).
Attachment:
pgpqdJZR2nzMX.pgp
Description: PGP signature