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.

Attachment: pgpKcjZY3cZsB.pgp
Description: PGP signature

Reply via email to