Mailing-List: contact dev-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@accumulo.apache.org
Received-SPF: pass (nike.apache.org: domain of josh.elser@gmail.com designates
 209.85.213.54 as permitted sender)
Message-ID: <51C08021.1050201@gmail.com>
Date: Tue, 18 Jun 2013 11:43:29 -0400
From: Josh Elser <josh.elser@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6;
 rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: dev@accumulo.apache.org
Subject: Re: Backporting policy proposal
References: 
 <CAL5zq9YoJA=caJzXC_vmY-di=ijhJ_W0rhQJzEWHkxfrB2imGg@mail.gmail.com>
 <CAPMpPc6fs0kvC=TBG8uktWDqCgJBSvnEy88CCnbmORoo2yjv_Q@mail.gmail.com>
 <51C07730.2050104@gmail.com>
 <CAPMpPc43kfmLMLPHsem3aX9=jFCHVpOjTe-8+AyxnyGo_ELRug@mail.gmail.com>
In-Reply-To: 
 <CAPMpPc43kfmLMLPHsem3aX9=jFCHVpOjTe-8+AyxnyGo_ELRug@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


On 6/18/13 11:26 AM, Adam Fuchs wrote:
> On Jun 18, 2013 11:05 AM, "Josh Elser" <josh.elser@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