Re: Tracking vendor release with Git

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



  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: pgphaZunRWQ8j.pgp
Description: PGP signature


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]