On 6/18/13 11:26 AM, Adam Fuchs wrote:
On Jun 18, 2013 11:05 AM, "Josh Elser" <josh.el...@gmail.com> wrote:
On 6/18/13 10:53 AM, Adam Fuchs wrote:
2. Back-porting performance improvements to a prior release line that
is not EOL (end-of-life) is usually okay (subject to normal lazy
consensus), so long as it does not change user-facing behavior or API.
It is still strongly preferred to add such fixes in the older branch
first, and merge forward to the newer one(s).
Agree, although doesn't the transition to git alleviate the problems with
order of operations?
I don't understand what you mean by "order of operations". If you push a
commit in 1.6.0-SNAPSHOT that should really be in 1.4.4-SNAPSHOT, Git will
not handle this well in terms of an accurate history.
I don't really understand either -- that was mostly speculation. Doesn't
the reliance on hashes of the patch rather than commit IDs make it
immaterial as to which branch a patch was committed to first? Admitedly, I
am not an expert on git.
Adam
No, that's incorrect. A commit is uniquely identified by a set of
attributes which, most importantly, include the parent commit. As such,
what you would have typically (happily) done with subversion (`svn merge
-r 12345 .`) has implications to the Git history graph.
The only way to accomplish this in Git is to cherry-pick that commit
which causes multiple unique commits which apply the same changes to
content. This also makes using tools like `git-bisect` much less
effective as a bug introduced in a cherry-pick'ed commit now has
multiple points of introduction instead of a single commit.
In the downtime before we hear back from INFRA, it would be good to read
through the documentation: http://git-scm.com/documentation
