3 ms·

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 backp

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).