threads / discuss / 30071

query: picking dependant commits from a latest tree

Subject: query: picking dependant commits from a latest tree

## tl;dr

4 messages between Mar 27, 2012 and Apr 3, 2012.

replies: 3people: 2as markdown or json

Shiraz Hashim· Mar 27, 2012, 09:55 UTC · lore
Hi,

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 ?

-- regards Shiraz

Neal Kreitzinger· Mar 30, 2012, 16:29 UTC · re: Shiraz Hashim · lore

Re: query: picking dependant commits from a latest tree

On 3/27/2012 4:55 AM, Shiraz Hashim wrote:
Show 10 quoted lines
>
> 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.

v/r, neal

Shiraz Hashim· Apr 3, 2012, 04:00 UTC · re: Neal Kreitzinger · lore

Re: query: picking dependant commits from a latest tree

Hi Neal,
On Sat, Mar 31, 2012 at 12:29:10AM +0800, Neal Kreitzinger wrote:
Show 15 quoted lines
> 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.

-- regards Shiraz

Neal Kreitzinger· Apr 3, 2012, 16:55 UTC · re: Shiraz Hashim · lore

Re: query: picking dependant commits from a latest tree

On 4/2/2012 11:00 PM, Shiraz Hashim wrote:
Show 18 quoted lines
> 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

← back to recent threads