Re: Users of git-check-files?

Linus Torvalds [off-list ref] writes:

It has no point any more, all the tools check the file status on their 
own, and yes, the thing should probably be removed.

How about git-rev-tree?  Does anybody care?

Hi,

On Tue, 2 Aug 2005, Junio C Hamano wrote:

Linus Torvalds [off-list ref] writes:

quoted

It has no point any more, all the tools check the file status on their
own, and yes, the thing should probably be removed.

How about git-rev-tree?  Does anybody care?

I try to write a "git annotate" based on the output of git-whatchanged. 
Since git-whatchanged only shows the commit and its parent, I need to 
figure out what was the last diff that led to the current commit's state. 
This needs git-rev-tree.

Ciao,
Dscho

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

On Tue, 2 Aug 2005, Junio C Hamano wrote:

How about git-rev-tree?  Does anybody care?

Yeah, probably not. git-rev-list does so much more than git-rev-tree ever 
did.

		Linus

On Wed, 3 Aug 2005, Johannes Schindelin wrote:

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.

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

Use the "--parents" flag to git-rev-list to get the parents output for 
doing your own graph, if you want to.

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).

I haven't gotten around to it, partly because I wonder if it would be
better as a separate program - even if that would mean that you'd lose all
the cool features of git-rev-list (the ability to limit it to certain
versions, and the ability to sort the output in relevant orders).

Partly because I'm just too friggin lazy.

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.

		Linus

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

Linus Torvalds [off-list ref] writes:

On Tue, 2 Aug 2005, Junio C Hamano wrote:

quoted

How about git-rev-tree?  Does anybody care?

Yeah, probably not. git-rev-list does so much more than git-rev-tree ever 
did.

I will keep git-rev-list; used in Jeff's git-changes-script and
some parts of Cogito as well.

Hi,

On Thu, 4 Aug 2005, Junio C Hamano wrote:

I will keep git-rev-list; used in Jeff's git-changes-script and
some parts of Cogito as well.

According to my grep's, these files use git-rev-list:

git-bisect-script
git-cherry
git-format-patch-script
git-log-script
git-repack-script
git-whatchanged
gitk
send-pack.c
upload-pack.c

So better keep it :-)

Ciao,
Dscho