Re: git-rev-list feature request

On Fri, 10 Mar 2006, Paul Mackerras wrote:

Nope. "git-rev-list -- foo" will just start from the heads given, and walk down.

Ahh, ok, you actually wanted something simpler than I thought you might.

What you want is (in its most trivial form) really trivial: mark the special commits you want to save with TREECHANGE, so that they aren't pruned by the logic that prunes off the "this commit doesn't change the file, so ignore it" commits.

HOWEVER. That trivial thing has problems. What if the history got simplified at a merge because one side of the merge changed it, and the other one did not - in that case we'll follow the history down the leg that didn't change (since that's the history that ended up being the final one). Now, that means that we will totally prune out the other parent info, and the commits you want to remain simply won't be "connected" any more.

To explain that better, let's say that history looks like this:

	     a
	    / \
	   b   c
	   |   |
	   d   e
	    \ /
	     f

and you're following file "foo", which is the same in "a" and "c". The fact that they are the same there means that the name pruning will decide that the history that led to "a" through "b" wasn't interesting, so it will prune that out, and make the whole history be

	   a
	   |
	   c
	   |
	   e
	   |
	   f

and then after that, it will remove all commits that didn't actually change foo at all (we know "a" was such a commit since we already simplified the merge, but let's say that "e" was one too), so you get

	   c
	   |
	   f

as the final simplified history right now.

Now, the problem is that what should you do if you want to tag "d" and "e" as inherently interesting (perhaps because they are tagged releases)?

Now, the "e" case is the above trivial case: just mark any "inherently interesting" commit with the TREECHANGE flag, and the history won't be pruned away. So it now looks like

	   c
	   |
	   e    <- faked "interesting"
	   |
	   f

however, the fact that you did the same to "d" means that we will have that too on our list of "interesting" commits, even though we've pruned away all of the history leading _from_ it, so the trivial algorithm would actually result in

	     c
	     |
	 d   e
	  \ /
	   f

in that case. We'd see "d" because it's somehow intrisically interesting, but it ends up being shown as that "dead tip", because the merge that would reach it was simplified away.

Is that what you'd want?

If so, then the appended trivial path should effectively do what you ask for. It keeps all the revs you passed in as "interesting" whether they are or not, so now you can effectively just pass in all the refs you want, and it will never remove any of the positive refs you passed it.

If you want a commit that has a ref pointing to it be marked as interesting only if we see it while parsing the tree, then you need to do slightly more (in "rewrite_one()", you should look up whether that commit has a ref pointing to it).

		Linus

----