Re: Users of git-check-files?

Hi,

On Wed, 3 Aug 2005, Linus Torvalds wrote:

On Wed, 3 Aug 2005, Johannes Schindelin wrote:

quoted

I try to write a "git annotate" based on the output of git-whatchanged.

You can't. It's fundamentally not doable, because you lose the merge
information.

That's why I said I need git-rev-tree. In the meantime I discovered, that 
git-rev-list has a "--parents" option which suits me just fine. Therefore 
I'd say: kill git-rev-tree.

So you need to use a combination of git-rev-list _and_ git-whatchanged.

I tried to do without the ugly "script is calling script is calling 
program" idiom. That is why my attempt at git-annotate (see attached) is 
so slow.

I have been thinking of adding a "follow this file" mode to git-rev-list,
which just ignores all children of merges that used the file directly from
one of the other children. Exactly because then you could have a
git-rev-list that prunes based on filename, and would potentially be a lot
more efficient (not follow the "uninteresting" side of a merge).

Let's sit and see if people pick it up at all. If yes, I'd rather rewrite 
the whole thing in C eventually (it is in perl now and uses hashes quite 
extensively...).

quoted

P.S.: My only unsolved problem is that git-whatchanged sometimes shows
the diffs in the wrong order (clock-skew problem?)

Nope, this is a direct result of two branches modifying the same file in
parallel. There is no "right" or "wrong" order.

Exactly. But there is a "you probably meant that": the branch in which it 
was modified last (not counting merges, of course).

Notes:

- You can either annotate by commit (this is the default), or show 
some other informations with the "-f" flag: Try "-f author,commit:8".

- If you don't specify any files, it assumes you mean all files 
(Attention: slow).

- You can start at a commit instead of the current state by specifying
"-c other_commit".

- The list of commits is traversed as output by git-rev-list, i.e. 
chronologically. Each line is marked with the commit whose parent does not 
contain that line.

- I am not at all sure if my handling of merges is sane. The logic is like 
this: If the commit is parent to more than one commit (i.e. a merge), then 
the touched lines are tentatively marked as changed in that commit, but 
are possibly overridden at a later stage.

Ciao,
Dscho