Re: Getting list of changed objects...

From: James Ketrenos <jketreno@linux.intel.com>
Date: Jul 14, 2005, 20:20 UTC
Message-ID: <42D6C901.2060409@linux.intel.com>
In-Reply-To: <Pine.LNX.4.58.0507141053540.19183@g5.osdl.org>

Linus Torvalds wrote:

>Since you haven't merged A and B in the above, they _are_ needed, aren't 
>they?
>  
>

My original email wasn't worded quite right. I think you are tracking what I'm trying to do... but here is a different view anyway:

time
      |
1     A ------->  B  clone A to B
2     |           |  make changes on B and A
3     | --> C     |  clone A to C
4     |     | <---'  merge B into C
5     |     |
      A     C

I am merging B (as it was at time 3, or B3) into C (as it was at time 3, or C3) via:

    git-read-tree -m $(git-merge-base B3 C3) C3 B3

where $(git-merge-base B3 C3) resolves to A1. After I run git-read-tree, I resolve any conflicts via git-merge-cache, etc. and write the tree via git-write-tree.

Show 8 quoted lines

>Maybe what you want is 
>
>	git-rev-list --objects B ^A ^C
>
>ie "objects that are in B, but not in A or in C", since you seem to 
>consider A uninteresting too?
>  
>

That does seem to work here by doing:

    git-rev-list --objects C5 ^C3 ^$(git-merge-base C3 B3)

Show 9 quoted lines

>, and also, "git-rev-list
>--objects" is actually not 100% careful - it can include objects that are
>in the "not" group, just because it doesn't actually bother to do a full
>negative list (it only creates a negative list for the "boundary" objects,
>but it won't even do "mark_tree_uninteresting()" for commits that it has
>decided cannot be meaningful, so it's not in any way guaranteed to be a
>_minimal_ set of objects).
>  
>

Good to know. If git-rev-list is just checking the boundary, and the merge commit is between C5 and C3 (at C4) then that explains why I see what I see. It would grab all the objects listed in C4 and not exhuaustively be removing them via one of its ancestors.

The goal is to create the list of objects (tree, commit, and blob) required such that if someone already has all the objects for repo A, they just need to download the 'in C, not in A' objects and the HEAD from C and then they can create a full copy of C.

I'll look to modify my scripts that merge the parent repository to cache the parent repository's SHA. I can then pass that list of merge points to get-rev-list as a set of boundaries.

Thanks, James