How do I...

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Okay, I've got some "How can I?" questions. I hope I'm not the only one still working to "git it".

How can I git a list of commits that have modified a particular file? For example, I'd like to do something like this: # git-file-revs Makefile f7eb55878f11575281add2a5726e483aed5e45bb aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb ...

How can I output a list of the filename(s) modified by a particular commit? (for example) # git-commit-info files 6741f3a7f9922391cd02b3ca1329e669497dc22f Makefile file1 arch/file2

Can I use cg-log to output just the information about a particular commit? (I don't need all the commits, just the one I'm interested in).

After doing a cg-update, can I cg-log just the changes since the last update? Alternatively, how can I tell cg-log I'm caught up, and don't need anything historical?

Can I do these with git/cogito, or will I need to start diving deeper into the code?

Thanks,

Frank
- --
Frank Sorenson - KD7TZK
Systems Manager, Computer Science Department
Brigham Young University
frank@tuxrocks.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCez2zaI0dwg4A47wRAuNAAJ0QsBkwwHFbFQshRGSDCLv/pEaZXQCfeZj6 rqC9ZoVAYNeMwKqppbyXx9o= =pJDl -----END PGP SIGNATURE-----

hello,

You have to parse the git-rev-list and look at every single commit. But I think cogito as well as jit have a command to obtain that.

A commit is only a pointer to a tree, so you can't. But you can see what files have changed between a parent (note: there are up to 16) and the dir which is associated with the commit:

git-diff-tree <child> <parent>

So calling git-diff-tree for every parent should do what you want.

	Thomas

Hello,

of course this is: git-diff-tree <parent> <child>

	Thomas

On Fri, 2005-05-06 at 03:49 -0600, Frank Sorenson wrote:

(Assuming pulling from "origin") Instead of doing cg-update, do cg-pull. Then "cg-log :origin" will give you you the changesets you just pulled. "cg-merge origin" will then complete operation, thereby catching you up.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dave Kleikamp wrote:

Super.  This works great.  Thanks.

Okay, not quite so great.  Here's the ouput when I ran it to update my
kernel this morning.  Note that I haven't made any local modifications.
 I'm seeing this sort of thing often enough that I'm blowing away my
whole git tree and regenerating it to get back to a stable state once or
twice a week.  I'm sure there's another way, but without me making
modifications on my end, I wouldn't expect this to happen.  Suggestions
are welcome! :)

# cg-merge origin
Fast-forwarding 6741f3a7f9922391cd02b3ca1329e669497dc22f ->
2512809255d018744fe6c2f5e996c83769846c07
        on top of 6741f3a7f9922391cd02b3ca1329e669497dc22f...
patching file fs/proc/Makefile
patching file fs/proc/array.c
patching file fs/proc/base.c
patching file fs/proc/generic.c
patching file fs/proc/inode-alloc.txt
patching file fs/proc/inode.c
patching file fs/proc/internal.h
patching file fs/proc/kcore.c
patching file fs/proc/kmsg.c
patching file fs/proc/mmu.c
patching file fs/proc/nommu.c
patching file fs/proc/proc_devtree.c
patching file fs/proc/proc_misc.c
patching file fs/proc/proc_tty.c
patching file fs/proc/root.c
patching file fs/proc/task_mmu.c
patching file fs/proc/task_nommu.c
touch: cannot touch `fs/proc/Makefile': No such file or directory
touch: cannot touch `fs/proc/array.c': No such file or directory
touch: cannot touch `fs/proc/base.c': No such file or directory
touch: cannot touch `fs/proc/generic.c': No such file or directory
touch: cannot touch `fs/proc/inode-alloc.txt': No such file or directory
touch: cannot touch `fs/proc/inode.c': No such file or directory
touch: cannot touch `fs/proc/internal.h': No such file or directory
touch: cannot touch `fs/proc/kcore.c': No such file or directory
touch: cannot touch `fs/proc/kmsg.c': No such file or directory
touch: cannot touch `fs/proc/mmu.c': No such file or directory
touch: cannot touch `fs/proc/nommu.c': No such file or directory
touch: cannot touch `fs/proc/proc_devtree.c': No such file or directory
touch: cannot touch `fs/proc/proc_misc.c': No such file or directory
touch: cannot touch `fs/proc/proc_tty.c': No such file or directory
touch: cannot touch `fs/proc/root.c': No such file or directory
touch: cannot touch `fs/proc/task_mmu.c': No such file or directory
touch: cannot touch `fs/proc/task_nommu.c': No such file or directory
rm: cannot remove `fs/proc/Makefile': No such file or directory
rm: cannot remove `fs/proc/array.c': No such file or directory
rm: cannot remove `fs/proc/base.c': No such file or directory
rm: cannot remove `fs/proc/generic.c': No such file or directory
rm: cannot remove `fs/proc/inode-alloc.txt': No such file or directory
rm: cannot remove `fs/proc/inode.c': No such file or directory
rm: cannot remove `fs/proc/internal.h': No such file or directory
rm: cannot remove `fs/proc/kcore.c': No such file or directory
rm: cannot remove `fs/proc/kmsg.c': No such file or directory
rm: cannot remove `fs/proc/mmu.c': No such file or directory
rm: cannot remove `fs/proc/nommu.c': No such file or directory
rm: cannot remove `fs/proc/proc_devtree.c': No such file or directory
rm: cannot remove `fs/proc/proc_misc.c': No such file or directory
rm: cannot remove `fs/proc/proc_tty.c': No such file or directory
rm: cannot remove `fs/proc/root.c': No such file or directory
rm: cannot remove `fs/proc/task_mmu.c': No such file or directory
rm: cannot remove `fs/proc/task_nommu.c': No such file or directory
fs/proc/Makefile: needs update
fs/proc/array.c: needs update
fs/proc/base.c: needs update
fs/proc/generic.c: needs update
fs/proc/inode-alloc.txt: needs update
fs/proc/inode.c: needs update
fs/proc/internal.h: needs update
fs/proc/kcore.c: needs update
fs/proc/kmsg.c: needs update
fs/proc/mmu.c: needs update
fs/proc/nommu.c: needs update
fs/proc/proc_devtree.c: needs update
fs/proc/proc_misc.c: needs update
fs/proc/proc_tty.c: needs update
fs/proc/root.c: needs update
fs/proc/task_mmu.c: needs update
fs/proc/task_nommu.c: needs update

Thanks,
Frank
- --
Frank Sorenson - KD7TZK
Systems Manager, Computer Science Department
Brigham Young University
frank@tuxrocks.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCe53EaI0dwg4A47wRAt5dAJ4wEG8KmRvEnqLMOtDiNrZqRhURMgCfTUaE JLGGFnRN4YGhix/7SkOwAtg= =aDQu -----END PGP SIGNATURE-----

On Fri, 2005-05-06 at 10:39 -0600, Frank Sorenson wrote:

I'm not sure if I was clear.  cg-pull should be 'cg-pull origin".

I take this to mean you're seeing problems with cg-update too. cg-update simply runs cg-pull & cg-merge together, so running them separately shouldn't make any difference.

I've seen some isolated problems running cg-update/cg-merge to a clean tree with files that have been deleted.

Saw this this morning:

shaggy@kleikamp linus-clean $ cg-merge origin
Fast-forwarding bfd4bda097f8758d28e632ff2035e25577f6b060 ->
2512809255d018744fe6c2f5e996c83769846c07
        on top of bfd4bda097f8758d28e632ff2035e25577f6b060...
patching file drivers/video/intelfb/intelfb.h
shaggy@kleikamp linus-clean $ cg-status
? drivers/video/intelfb/intelfbdrv.h

Removing the file manually appears to fix it.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dave Kleikamp wrote:

Got it, and it does just what I wanted.

Yes. cg-pull and cg-update have both shown odd breakage of this sort, putting my tree into a bad state. Sometimes deleting files fixes it, but more often than not, I've needed to just start a new tree again in order to fix it. This is probably due to inexperience with git, but tree corruption probably shouldn't occur like this.

Frank
- --
Frank Sorenson - KD7TZK
Systems Manager, Computer Science Department
Brigham Young University
frank@tuxrocks.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCe8BxaI0dwg4A47wRAk2OAJ915s2KHTNxrpi6k3wa7HiDhpOFGgCgrMxp 73JzFxl7lg2c9korTF8L7Ek= =ILPh -----END PGP SIGNATURE-----

On Fri, 6 May 2005, Frank Sorenson wrote:

There has been at least two different scripts for this posted, and one C source code version.

I just haven't integrated them, because I'm an idiot, and too much choice makes me run around in small circles and clucking.

Guys - whoever wrote one of the scripts, can you please send out your current version to the git list and cc me, and explain why yours is superior to the other peoples version. Please?

But I might cook something up myself too. 

You need to use "git-tree-diff", but it doesn't want one commit, it wants two.

In the case of "what did this one commit change", you need to look up its parents (there can be more than one! In fact, the current git repository has one entry with _five_ parents), and then you need to select one of them as the reference. In other words, if it's a merge, you need to select which side you care about.

You don't even need cg-log for that. If you already know which commit you're interested in, just output that one commit:

	git-cat-file commit <commit-name-here>

I don't know how to do with with cg-update, but if you use the "git-pull-script" thing, you can do

	git-diff-tree -p ORIG_HEAD HEAD

which shows you what the pull brought in.

Apart from finding the "which commit changed this", it's all trivially doable. And the "which commit" thing is also trivially doable if you just find the script..

		Linus

LT> On Fri, 6 May 2005, Frank Sorenson wrote:

LT> Guys - whoever wrote one of the scripts, can you please send out your LT> current version to the git list and cc me, and explain why yours is LT> superior to the other peoples version. Please?

I think I mentioned and posted an interactive version called jit-trackdown. It is part of JIT found at [*1*]. You may have an older version that does not have the command.

LT> But I might cook something up myself too. 

Yourself or not, I think it is a good idea to do something that does exactly Frank wants, namely, just list commits. Even better would be, to take commits with multiple parents into account, list of <commit> <parent> pairs, like:

    $ git-file-revs Makefile
    f7eb55....... aaaaaa.......
    f7eb55....... bbbbbb.......
    aaaaaa....... dddddd.......

which shows commit f7eb55... changed it relative to both of its parents aaaaaa... and bbbbbb...

[Footnotes] *1* http://members.cox.net/junkio/

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Junio C Hamano wrote:

Note that I could be just thinking about this all wrong, so my terminology could be in left field. Here, I'm mostly just interested in the case where "Hey, something broke with drivers/char/i8k.c. When was this changed? Who changed what?"

Thanks,

Frank
- --
Frank Sorenson - KD7TZK
Systems Manager, Computer Science Department
Brigham Young University
frank@tuxrocks.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCe5+yaI0dwg4A47wRAhIwAKD7R/D3ZU7JZz0mytEO04u04OTVZwCbBFhG sEYSTYiLLIMuLxU+r1mNuGw= =Mcg2 -----END PGP SIGNATURE-----

On Fri, 6 May 2005, Frank Sorenson wrote:

The tricky thing is that you want to *not* see commits where somebody adopted somebody else's change to drivers/char/i8k.c; you want to ignore those commits in favor of the commits where the original author of the changes made the changes. Otherwise, you mostly see merges with people submitting lines where they didn't change that file.

	-Daniel
*This .sig left intentionally blank*

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Daniel Barkalow wrote:

True. At least usually. Sometimes, though, we'll want to see the entire history of the file, so we can see when it went (for example) into Greg K-H's tree, then when Linus pulls into his tree, etc. I guess that makes "just when the file itself has actually changed" a special case of the entire history of a particular file.

Frank
- --
Frank Sorenson - KD7TZK
Systems Manager, Computer Science Department
Brigham Young University
frank@tuxrocks.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCe73XaI0dwg4A47wRAvxaAJ9E1mFepuHmTfvVfwr8zMwpqqcSZACgsz0M NVAd1f2ZGzu+NPqD3zDQ3Yo= =I3EA -----END PGP SIGNATURE-----

On Fri, 6 May 2005, Junio C Hamano wrote:

Actually, I spent some time just now to improve the interface to git-diff-tree, allowing it to take a list of trees to compare from stdin.

And if you only give it one entry on stdin, it assumes it is a commit, and lists the tree difference between that and the parent(s). If it's a merge commit, it will ignore it unless you use "-m".

So now you can do

	git-rev-list HEAD --max-count=10 | git-diff-tree --stdin update-cache.c

to see which of the last 10 commits changed "update-cache.c".

And if you add the "-p" flag, it will show it as a diff too.

Damn, I'm good. It was just a few lines of code added to git-diff-tree.

		Linus

On Fri, 2005-05-06 at 10:09 -0700, Linus Torvalds wrote:

Now show the graph of revision history which connects those commits.

On Fri, 6 May 2005, David Woodhouse wrote:

I don't do no steenking GUI's. That's for others, and you'll need to parse the git-rev-list output yourself to do that.

		Linus

On Fri, 2005-05-06 at 11:59 -0700, Linus Torvalds wrote:

When I said 'show' I meant merely provide sufficient information. 

I believe that what you get at the moment from the command you showed is an unconnected list of commits, each of which may be in different branches, where the _parent_ of each commit you show may not even be included in the list.

I.e. you're giving them a bag of unconnected objects which each look something like this...

		 (COMMIT)--> 
or
		 (COMMIT)--->
		         \-->

But you need to give them a _graph_...

	/------> (COMMIT) --> (COMMIT) --\
 (COMMIT)                                 -> (COMMIT) 
	\-----------> (COMMIT) ----------/

Leaving the pretty GUI as an exercise for the reader is fine. But we do actually have to give enough information to allow them to connect the bits together.

My recursive script attempted this but wasn't quite good enough -- we had enough information to track _merges_ but not _branches_. Hence I was only giving this much information...

	/------> (COMMIT) --> (COMMIT) --\
 (COMMIT)                                 -> (COMMIT) 
	              (COMMIT) ----------/

(...or this one, depending on which order I parsed the tree...)

	         (COMMIT) --> (COMMIT) --\
 (COMMIT)                                 -> (COMMIT) 
	\-----------> (COMMIT) ----------/

On Fri, 6 May 2005, David Woodhouse wrote:

To do that, you'd just have to always show the commit/parent pairs, regardless of whether it had a difference or not. That's actually what the first version did, but it was so ugly that I ended up changing it to only showing pairs that had differences.

It would be easy to add a "--all" flag or something, that shows all commit/parent information, and then you would use that, but the thing is, you're likely better off just using git-rev-tree to build the graph in the first place.

So it's doable, and it has nothing to do with git-diff-tree. So normally you'd do something like "show me all differences between v2.6.12-rc2 and now, and then you _do_ end up using git-rev-tree first to make a list of commits, and then you feed that list of commits into git-diff-tree - and notice that when you did the rev-tree in the first place, you actually did build up the history tree to get there, so if you want to visualize it, you should now use _that_ tree that you already built.

diff-tree never has any commit history tree information available to it. It just doesn't know, care, or bother.

		Linus

On Fri, 2005-05-06 at 15:57 -0700, Linus Torvalds wrote:

Nah, you just prune the commits from which aren't interesting, then dump the graph you're left with. So instead of printing just the immediate parent(s) for each interesting commit, you print the "nearest interesting ancestor(s)".

Take copy of rev-tree, let it mark commits as interesting if they touch the file(s) in question, then effectively perform a list_del() on any commit which _isn't_ interesting, and any merge which merges only uninteresting commits... then dump the resulting pruned graph.

On Sat, 7 May 2005, David Woodhouse wrote:

Nope. That's just stupid. 

Use the whole commit history, and if you want to simplify it from there once you notice that some branches end up never being interesting, then that's ok.

But trying to be clever while building this up is just crazy talk. When diff-tree prints out the changes, it has no way of knowing what the context around it was - it doesn't know about merges far away, and it _shouldn't_ know.

		Linus

On Fri, 2005-05-06 at 16:54 -0700, Linus Torvalds wrote:

Isn't that what I suggested? Start with full history, mark the 'interesting' commits which touch the file(s) in question, then prune.

I've written a script that shows all commits when a certain file was changed.

It goes back the commits, looks into the tree ... and if a change is found, print out the commit.

Thomas

--- /dev/null 1970-01-01 01:00:00.000000000 +0100 +++ git-file-history-script 2005-05-06 21:24:41.000000000 +0200

On Fri, 2005-05-06 at 09:13 -0700, Linus Torvalds wrote:

I already explained why mine sucks and shouldn't be merged. It was a proof of concept; hoping for the stone soup effect.

I haven't seen a C version or indeed anything which actually does the right thing, although I outlined how it would work and _threatened_ to do one. I had a half-arsed attempt at it on the way home from linux.conf.au but my brain tends to melt while I'm on airplanes so I didn't get very far.

On Fri, 2005-05-06 at 17:36 +0100, David Woodhouse wrote:

Note that paulus current dirdiff CVS can diff arbitrary revs of a git tree afaik (or a rev against current edited content).

Ben.

On Fri, 6 May 2005, Frank Sorenson wrote:

Ok, I now have the perfect interface for _most_ uses of this thing.

For example, let's say that you are interested in "what changed in the USB input layer lately". You can now do

	git-rev-list | git-diff-tree -p -v --stdin drivers/usb/input | less -S

and you'll get some very readable output that tells you _exactly_ what has changed to any file in that subdirectory.

Or, let's say that you're the author of the gt96100 ethernet driver (just to pick one that has both a .c and a .h file and that has had changes in the current git tree, you'd do:

	git-rev-list HEAD | git-diff-tree -p -v --stdin drivers/net/gt96100eth.* | less -S

and it gives you _exactly_ what you want (ie thanks to how diff-tree works, you can give it any number of files or directories you're interested in).

Normally, this thing will ignore merge commits, but if you want to see the merges that the changes came through (a merge _can_ have real changes of its own too), add the "-m" flag to the git-diff-tree thing.

Try out the above examples on the current kernel tree (and with my most current git version as of five minutes ago - it shows up at least on gitweb, but I don't know if it's mirrored out with rsync yet). Very pretty. Very useful.

		Linus