Subject: Re: query: picking dependant commits from a latest tree

From: Neal Kreitzinger <[email-masked]>
Date: Tue, 03 Apr 2012 11:55:27 -0500

On 4/2/2012 11:00 PM, Shiraz Hashim wrote:
> On Sat, Mar 31, 2012 at 12:29:10AM +0800, Neal Kreitzinger wrote:
>> On 3/27/2012 4:55 AM, Shiraz Hashim wrote:
>>> If I try to pick commits from a latest tree for a particular feature
>>> then what is the best way to find out all dependant commits.
>>>
>>> So for example for the commit which I want to pick there are 10 other
>>> commits around that file but some affect other files which themselves
>>> have several commits which I must apply.
>>>
>>> Is their a way to do this efficiently ?
>>>
>> You're assuming all dependencies reside in the same commits or in common
>> files.  If the changes in a commit are dependent on the previous commit
>> and they do not share any of the same files then what you are proposing
>> is not going to catch that.
> You are right, but this would perhaps be caught during tests. But in
> the first place how can I find dependent commits to pass build test.
>
Theoretically, all the ancestors of a commit are dependencies.  When you 
cherry-pick you run the risk of not getting dependencies.  That will be 
up to you to figure out.  Different software has different dependency 
scenarios.  IMO, you will analyze what yours specifically are and then 
perhaps submit more specific examples to the newsgroup.  There are many 
possibilities.

Just one example is that you would have to write a script that scans 
your all programs in your commit for called programs and then 
interrogates history to see of any of the called programs were changed 
in other commits.  Of course you would have to repeat that and it could 
be quite extensive.  You would also have to git-grep repo history for 
all callers of programs changed in your commit.  Of course you would 
have to repeat that and it could be quite extensive.  Git is not going 
to do this for you.  You can use git to do powerful interrogations to 
aid you in this.  Even after all of that, someone has to review the 
results and make judgement calls on which dependencies matter and which 
ones don't.  This is where your own knowledge or that of senior 
(system-wise) people has to make judgement calls.  Human knowledge of 
your software is the best first approach at assessing commit 
dependencies, and then supplement it with git interrogations if you have 
any remaining questions or doubts.

v/r,
neal