I'm trying to setup a workflow to track vendor releases (upstream).
Each new release are provided as an archive of source code, data,
documentation, etc.
I've been doing more or less this. A few comments:
I suggest that you not view CRLF->LF as a "patch". I would do EOL
hygiene as a preprocessing script, with a checked-in script, after
unpacking the tarball or whatever, and before 'import'. Otherwise
it's just going to be too messy.
I use "vendor.foo" as the branch name.
If your repo is only for this program, you can ignore this, but
otherwise you way want to use subtree merge so that vendor.foo: maps
to master:foo (putting foo in a subtree in master). This lets you
have multiple upstreams in one repo, which is useful for system
building more than maintaining.
I would avoid rebase. You are essentially merging someone else's
branch (that they aren't putting in git, but you are with the
vendor.foo) into your master. With regular merge, you can still
diff, but the natural history will be right. With rebase each "local
version" as you call it will have different commits that will not have
clear ancestry.