Getting list of changed objects...

I have the following tree path:

  A   C   B
  |   |
  | 3.|<--.   
  |   |   |
2.|-->'   |
  |       |
1.|------>'
  |

Where A is the root repository for my overlays. B was created by cloning A (1)

B is where development has been progressing. Finding the set of objects to move from A to B is easily obtained via:

  git-rev-list --objects B ^A 

The problem is now when I want to re-sync B with the latest version of A. What I currently do is:

Create a new C tree based on latest A (2) and then merge B back into it (3):

  git-merge-tree -m $(git-merge-base C B) C B

That works great. I now have a tree with all of the latest A code and the B changes applied. The problem is now in getting the list of objects to create the overlay repository.

  cg-log -f -r C:B

Will correctly show only those files that have actually changed between C and B in the first log entry. However, cg-log does not show me the list of tree objects that have changed between C and B.

The problem is that if I run:

  git-rev-list --objects B ^C

It shows me all of the tree and commit objects but also gives a list of all of the files that changed between A and C as if they are needed to move C to B.

Am I overlooking something, misusing things, or ?

Thanks, James

On Thu, 14 Jul 2005, James Ketrenos wrote:

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

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?

I don't actually understand what you want to do, 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).

			Linus

Linus Torvalds wrote:

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.

That does seem to work here by doing:

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

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