3 ms·

If you had to, how would you backport a fix onto an earlier release using this? Or is that something that's not considered as necessary? (This is used for a we

• pilif 17y ago
  git cherry-pick can help. I'll add a bigger comment to this posting to explain how we are doing it with a web application - maybe if can yield some additional clues.
• spc476 17y ago
  As pilif said, use "git cherry-pick". I do that for a web application I'm responsible for. It needs to support both MySQL and PostgreSQL, and due to a few inconsistencies (mainly, dates and enums) I'm currently maintaining two parallel branches of the application. If I do a bug fix that isn't database specific, I'll commit to the branch I'm working on, and cherry-pick that change into the other branch. Yes, it's not as clean as I first expected it to be (and I'm working on merging the two into a single branch) but at least it's possible to do that with git.
  • DannoHung 17y ago
    Maybe pilif has a better example, but I don't think that necessarily applies to backporting a fix. Reason being that you can't cut the new release of the backported version on the master branch without doing a history rewrite. You could certainly have it on a separate branch off of the release version (of course), but then you have to keep that branch (which may or may not be a problem).
    • pyre 17y ago
      You could create that branch and then update the tags (IIRC, git-tag changes propagate). In general though, you're probably better off with separate branches for each major code change if you're business is obligated to support older versions (e.g. firefox-1.5, firefox-2.0, etc branches rather than relying solely on tags).