* Re: How do I...
From: Thomas Glanzmann @ 2005-05-06 10:03 UTC (permalink / raw)
To: git
In-Reply-To: <20050506095904.GC11506@cip.informatik.uni-erlangen.de>
Hello,
> git-diff-tree <child> <parent>
of course this is: git-diff-tree <parent> <child>
Thomas
^ permalink raw reply
* Re: How do I...
From: Thomas Glanzmann @ 2005-05-06 9:59 UTC (permalink / raw)
To: git
In-Reply-To: <427B3DB3.4000507@tuxrocks.com>
hello,
> How can I git a list of commits that have modified a particular file?
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.
> How can I output a list of the filename(s) modified by a particular
> commit? (for example)
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
^ permalink raw reply
* How do I...
From: Frank Sorenson @ 2005-05-06 9:49 UTC (permalink / raw)
To: git
-----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-----
^ permalink raw reply
* GIT blame (was Re: Quick command reference)
From: Junio C Hamano @ 2005-05-06 9:32 UTC (permalink / raw)
To: Linus Torvalds; +Cc: David Greaves, git
In-Reply-To: <7vhdhgeuj1.fsf@assigned-by-dhcp.cox.net>
>>>>> I == Junio C Hamano <junkio@cox.net> said:
JCH> Linus, please pull from git-jc.git archive at:
JCH> http://members.cox.net/junkio/git-jc.git/
Since that message I have added a couple more commits there.
One of the things is a backport of -t (tag) flag to git-ls-files
from Cogito fork.
The reason I am writing this message is not because I am excited
about the backport [*1*], but because I find it quite cool the
way I found out which commit in Pasky's development line
introduced the change. It demonstrates your previous "renames
does not matter when doing CVS blame" argument actually works.
Here is what I did:
1. Go into git.pasky and look at ls-files.c, grab a couple of
lines that look particular to Cogito version and store
those lines in a file. I used the following:
$ cat >pattern <<\EOF
static const char *tag_cached = "";
static const char *tag_unmerged = "";
static const char *tag_removed = "";
static const char *tag_other = "";
EOF
2. Run the following command:
$ jit-search-change HEAD pattern
What jit-search-change does is essentially what you described in
your "renames do not matter" argument. It does git-rev-list to
list the commits from newer to older, runs git-diff-tree between
parent-commit pairs, with GIT_EXTERNAL_DIFF set to a script that
shows the diff between corresponding file in these two trees
only if the file from one tree has that pattern string and the
other tree's does not. When it shows this diff, it also reports
the commit pair, and that's how you can find out which commit
introduced that change.
It currently shows useless hits when it sees merges from you to
Cogito, since those merges re-introduces the same change by
forward porting it over and over, which I am thinking about ways
to cull. Maybe limiting the search only to parent-commit pair
that has only one parent would be good enough. There are other
things to improve, but I am reasonably happy how it worked out.
[Footnote]
*1* The reason for the backport is because it is so small and
trivial change that does not affect the operation of the command
when the flag is not used. I do not see a reason to force Pasky
to keep shipping the version modified for Cogito use.
^ permalink raw reply
* Re: Kernel nightly snapshots..
From: David Woodhouse @ 2005-05-06 7:42 UTC (permalink / raw)
To: Linus Torvalds; +Cc: H. Peter Anvin, Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0505050834550.2328@ppc970.osdl.org>
On Thu, 2005-05-05 at 08:46 -0700, Linus Torvalds wrote:
> So this _should_ work for a while, but will eventually (before a -rc10
> happens or we get to v2.6.100 ;^) need something better. That something
> better probably being to ignore any tags that don't point to commits, and
> then sorting by the date of the commit object.
Enough with the dates already. I don't want to be doing snapshots
against 2.6.11.9 just because that happened to get tagged more recently
than 2.6.12-rc4. Time is an illusion; especially so when looking at
branches which may not even have been merged.
The tag I want is the one which refers to a commit which is made by
yourself and is accessible from the current HEAD in the lowest number of
steps. And I don't _care_ if you tagged it 'Woozy Numbat'.
--
dwmw2
^ permalink raw reply
* Re: Kernel nightly snapshots..
From: David Woodhouse @ 2005-05-06 7:29 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Linus Torvalds, Git Mailing List
In-Reply-To: <427ABA45.3050803@zytor.com>
On Thu, 2005-05-05 at 17:28 -0700, H. Peter Anvin wrote:
> Could you add that to 2.4 as well, too?
Is there a 2.4 git tree?
--
dwmw2
^ permalink raw reply
* Quick command reference
From: Junio C Hamano @ 2005-05-06 6:30 UTC (permalink / raw)
To: Linus Torvalds; +Cc: David Greaves, git
In-Reply-To: <42750D06.70004@dgreaves.com>
Linus, please pull from git-jc.git archive at:
http://members.cox.net/junkio/git-jc.git/
(this time I have refs/heads/master there as well as HEAD; sorry
but no rsync).
I've added the Documentation directory as you suggested and
placed the copy of Quick reference David Greaves has been
working on. I've minimally copy edited it to match the current
command names after the big git-* renaming, and also added
descriptions of commands and scripts that was missing back
then. These three steps are recorded as separate commits (in
sequence, not Octopus).
The format is still plain text. AsciiDoc can come in the next
round, but let's get the ball rolling by putting something in
there.
Please note that I do not intend to take the document over from
David. I am just trying to help him get the result of his
effort into the mainline so that the document helps wider
audience, and to encourage (and remind) patch writers to keep it
up to date when modifying the Plumbing.
^ permalink raw reply
* Re: tool to diff cache <-> working directory
From: Thomas Glanzmann @ 2005-05-06 3:13 UTC (permalink / raw)
To: git
In-Reply-To: <7vy8atdq7i.fsf@assigned-by-dhcp.cox.net>
Hello,
> Are you using pure GIT, without any Porcelain layer like Cogito?
no, I actually write a porcelain layer myself in perl. For several reasons:
- I want something that runs on Solaris without gnu-utils
- I want to understand the git internals.
- I don't need branches and refs in .git
> Cogito has "cg-status" that shows something like "cvs -n update"
> output.
I just finished implementing my 'git status' command which does the
following:
(faui01) [~/work/git/git] git status
+ 1
? 2
- COPYING
D* Makefile
* commit.c
D export.c
+/-/* -> add, rm, mod
? -> orphan (not under revision control)
D -> dirty -> was explicit modified in cache but cache doesn't match working copy
I also have a ignore list for known orphans:
(faui01) [~/work/git/git] cat .git/ignore
\.o$
git-cat-file
...
git-write-tree
libgit.a
Sincerely,
Thomas
^ permalink raw reply
* Re: commit-id fails after cg-init
From: David A. Wheeler @ 2005-05-06 3:06 UTC (permalink / raw)
To: Alexey Nezhdanov; +Cc: git
In-Reply-To: <200505051122.03111.snake@penza-gsm.ru>
I said:
>>There's an interesting side-effect of this; I _think_ it's
>>fine but it might be worth thinking through. If all
>>new projects start with an empty tree, that creates a
>>"common root" that all projects can appeal to.
>>That means that in theory a merge between any two project root
>>trees can eventually find a common ancestor: the empty tree.
>>I _think_ that's okay... is it?
Alexey Nezhdanov wrote:
> I think this problem can be easily solved with:
> 1) Restricting to auto-select empty commit as the merge base
> 2) Make an exception from rule (1) for first real commit
Okay, but that's only true if this is really a problem.
I'm not sure it _is_, in fact I think the semantics make perfect sense.
I just wanted to note that as the kind of change
that MIGHT have a surprising side-effect, so if anyone knew of one,
please speak up!
> By (1) we will restrict accidental bad merges that can happen due to crasy
> operator - he will need to explicitly select empty commit as merge base.
Is that really a problem, though? It seems to me that since a
bad merge can be undone, it's not really a problem.
--- David A. Wheeler
^ permalink raw reply
* Re: read-only git repositories (ancient history)
From: David A. Wheeler @ 2005-05-06 3:01 UTC (permalink / raw)
To: David Lang; +Cc: git
In-Reply-To: <Pine.LNX.4.62.0505050231300.15451@qynat.qvtvafvgr.pbz>
David Lang wrote:
> given that git already treats everything in the object storage as being
> fixed it occured to me that there may be value in makeing it so that git
> can make use of more then one pool of storage
...
> there are probably other uses and it seems like a fairly small
> modification to add a hook to use if the object isn't found initially
> that I thought I'd mention it to the group.
Reasonable. Another use would be to have a repository with
"ancient history" (e.g., Linux pre-2.6) that isn't normally
loaded or looked at, but COULD be looked at if you added
that repository. For that use, though, you'd need a way to
record "the parent of X is Y" since the information creating
connections BETWEEN the repositories might not be stored in
the later repository itself (see the discussions about Linux kernel
history recreation).
--- David A. Wheeler
^ permalink raw reply
* Re: tool to diff cache <-> working directory
From: Junio C Hamano @ 2005-05-06 2:48 UTC (permalink / raw)
To: Thomas Glanzmann; +Cc: git
In-Reply-To: <20050506020759.GA11506@cip.informatik.uni-erlangen.de>
>>>>> "TG" == Thomas Glanzmann <sithglan@stud.uni-erlangen.de> writes:
TG> I thought there would be no cache<->working directory delta generation.
TG> And I need a way to see if there are unchecked-in deltas in the working
TG> tree. So I thought about looking at the 'git-diff-cache --cached tree1'
TG> and comparing it with the self generated SHAs of the working tree. But
TG> now, that there is such a tool, I am perfectly fine.
Are you using pure GIT, without any Porcelain layer like Cogito?
Cogito has "cg-status" that shows something like "cvs -n update"
output.
My (shameless plug ;-) JIT [*1*] also has "jit-status".
[References]
*1* http://members.cox.net/junkio/
^ permalink raw reply
* Re: tool to diff cache <-> working directory
From: Thomas Glanzmann @ 2005-05-06 2:07 UTC (permalink / raw)
To: git
In-Reply-To: <7vhdhhf88u.fsf@assigned-by-dhcp.cox.net>
Hello,
> git-diff-tree tree1 tree2 two trees
> git-diff-cache --cached tree1 cache and tree
> git-diff-cache tree1 tree and working directory
> git-diff-files cache and working directory
that makes it clear. Thanks.
> So git-diff-files is not just similar to but exactly is what you
> want if I read your question correctly.
Yes, it is. :-)
> Yes there is a way, git-write-blob, but why would you want to do
> that?
I thought there would be no cache<->working directory delta generation.
And I need a way to see if there are unchecked-in deltas in the working
tree. So I thought about looking at the 'git-diff-cache --cached tree1'
and comparing it with the self generated SHAs of the working tree. But
now, that there is such a tool, I am perfectly fine.
Thanks,
Thomas
^ permalink raw reply
* Re: list all dirty files in working directory
From: Linus Torvalds @ 2005-05-06 2:06 UTC (permalink / raw)
To: Thomas Glanzmann; +Cc: GIT
In-Reply-To: <20050505212152.GP20994@cip.informatik.uni-erlangen.de>
On Thu, 5 May 2005, Thomas Glanzmann wrote:
>
> is there another way than call 'checkout-cache -a' and parse the output?
> Maybe a command which lists one dirty file per line?
A simple
git-diff-files
does what I think you want.
Of course, it does a lot more too, but part of the deal is that you get to
know which files are dirty.
Linus
^ permalink raw reply
* Re: tool to diff cache <-> working directory
From: Junio C Hamano @ 2005-05-06 1:33 UTC (permalink / raw)
To: Thomas Glanzmann; +Cc: git
In-Reply-To: <20050506002347.GU20994@cip.informatik.uni-erlangen.de>
>>>>> "TG" == Thomas Glanzmann <sithglan@stud.uni-erlangen.de> writes:
TG> Is there a tool to compare cache with working directory
TG> similiar to diff-tree, diff-cache and diff-files?
git-diff-tree tree1 tree2 two trees
git-diff-cache --cached tree1 cache and tree
git-diff-cache tree1 tree and working directory
git-diff-files cache and working directory
So git-diff-files is not just similar to but exactly is what you
want if I read your question correctly.
TG> Or is there a way to find out the SHA checksum of a file in
TG> a working directory without adding it to a temporary cache?
Yes there is a way, git-write-blob, but why would you want to do
that?
^ permalink raw reply
* Re: Kernel nightly snapshots..
From: H. Peter Anvin @ 2005-05-06 0:28 UTC (permalink / raw)
To: David Woodhouse; +Cc: Linus Torvalds, Git Mailing List
In-Reply-To: <1115307033.16187.146.camel@hades.cambridge.redhat.com>
David Woodhouse wrote:
> On Thu, 2005-05-05 at 16:10 +0100, David Woodhouse wrote:
>
>>2.6.12-rc3-git1 is in the process of being built; if the attached
>>script works and continues working when invoked from cron, we might
>>even see nightly snapshots again as requested...
>
> Eep. That'll be a whole lot more useful if I do
> cg-diff -r $RELTREE:$CURTREE
> instead of
> cg-diff -r $CURTREE:$RELTREE
> ... but it should be OK now. This is the md5sum of the correct one:
>
> 21a0ee13c539e8b016682c1542bb9167 patch-2.6.12-rc3-git1.gz
>
Hi David,
Could you add that to 2.4 as well, too?
-hpa
^ permalink raw reply
* tool to diff cache <-> working directory
From: Thomas Glanzmann @ 2005-05-06 0:23 UTC (permalink / raw)
To: GIT
Hello,
is there a tool to compare cache with working directory similiar to
diff-tree, diff-cache and diff-files? Or is there a way to find out the
SHA checksum of a file in a working directory without adding it to a
temporary cache?
Thomas
^ permalink raw reply
* [PATCH] create subdirs for symlinks
From: Kay Sievers @ 2005-05-05 23:34 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
We may need to create subdirectories, before we can create a
symlink.
Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
---
--- a/checkout-cache.c
+++ b/checkout-cache.c
@@ -96,6 +96,7 @@ static int write_entry(struct cache_entr
case S_IFLNK:
memcpy(target, new, size);
target[size] = '\0';
+ create_directories(path);
if (symlink(target, path)) {
free(new);
return error("checkout-cache: unable to create symlink %s (%s)",
^ permalink raw reply
* Re: git-diff-cache uses checked-out-working-directory-files if files are newer than the cache entry
From: Thomas Glanzmann @ 2005-05-05 22:58 UTC (permalink / raw)
To: GIT
In-Reply-To: <20050505223727.GR20994@cip.informatik.uni-erlangen.de>
Hello,
* Thomas Glanzmann <sithglan@stud.uni-erlangen.de> [050506 00:38]:
> I have trouble with git-diff-cache, because it uses the file from the
> working directory instead of the cache file if the working directory is
> newer than the entry in the cache:
'git-diff-cache -r --cached HEAD' does what I want.
~~~~~~~~
Thomas
^ permalink raw reply
* git-diff-cache uses checked-out-working-directory-files if files are newer than the cache entry
From: Thomas Glanzmann @ 2005-05-05 22:37 UTC (permalink / raw)
To: GIT
Hello,
I have trouble with git-diff-cache, because it uses the file from the
working directory instead of the cache file if the working directory is
newer than the entry in the cache:
(faui01) [~/work/git/git] echo 1 > 1
(faui01) [~/work/git/git] ./git-update-cache --add 1
(faui01) [~/work/git/git] ./git-diff-cache -r HEAD
+100644 blob d00491fd7e5bb6fa28c517a0bb32b8b506539d4d 1
(faui01) [~/work/git/git] echo 2 > 1
(faui01) [~/work/git/git] ./git-diff-cache -r HEAD
+100644 blob 0000000000000000000000000000000000000000 1
(faui01) [~/work/git/git] ./git-diff-cache -p -r HEAD
Created: 1 (mode:100644)
--- /dev/null
+++ b/1
@@ -0,0 +1 @@
+2
Note this Output is wrong because the '1' get committed, if I call write-tree
(faui01) [~/work/git/git] write-tree
5a38ca90309671c5029f32f67e1aba970a4f1e08
(faui01) [~/work/git/git] ./git-ls-tree 5a38ca90309671c5029f32f67e1aba970a4f1e08 | grep 1\$
100644 blob d00491fd7e5bb6fa28c517a0bb32b8b506539d4d 1
040000 tree 9823f134bfb89097ce796f931d3efc92aadfcfbf mozilla-sha1
Same for modification:
(faui01) [~/work/git/git] echo 1 >> COPYING
(faui01) [~/work/git/git] update-cache COPYING
(faui01) [~/work/git/git] ./git-diff-cache -r HEAD
*100644->100644 blob 6ff87c4664981e4397625791c8ea3bbb5f2279a3->c17665dc78a012a55b11d083bfa065d8cd2b0df1 COPYING
(faui01) [~/work/git/git] echo 2 >> COPYING
(faui01) [~/work/git/git] ./git-diff-cache -r HEAD
*100644->100644 blob 6ff87c4664981e4397625791c8ea3bbb5f2279a3->0000000000000000000000000000000000000000 COPYING
(faui01) [~/work/git/git] write
write write-tree writevt
(faui01) [~/work/git/git] write-tree
a3f88e4c7c6818ee880d97bf3293ea56fe12c478
(faui01) [~/work/git/git] ./git-ls-tree a3f88e4c7c6818ee880d97bf3293ea56fe12c478 | grep COPYING\$
100644 blob c17665dc78a012a55b11d083bfa065d8cd2b0df1 COPYING
Is this behaviour intended? I would like to see that git-diff-cache
doesn't even look at the working directory but only operates on the
cache.
Greetings,
Thomas
^ permalink raw reply
* Re: Please rename cg-X* to something else
From: H. Peter Anvin @ 2005-05-05 22:31 UTC (permalink / raw)
To: Pavel Roskin; +Cc: git
In-Reply-To: <1115329026.3838.8.camel@dv.roinet.com>
Pavel Roskin wrote:
> Hello!
>
> Since cg-X* scripts are not supposed to be used by the end users, I
> suggest that we rename them so something not starting with "cg-" or even
> "cg" so that tab completion in bash doesn't show them. I suggest "_cgX"
> instead of "cg-X"
>
> In the long term, the internal scripts should go to
> $prefix/share/cogito, but it would require generating other scripts from
> templates to substitute $prefix, which could be inconvenient at this
> stage.
>
$prefix/libexec/cogito rather...
Pattern-substituting in bulk isn't really very hard.
-hpa
^ permalink raw reply
* Please rename cg-X* to something else
From: Pavel Roskin @ 2005-05-05 21:37 UTC (permalink / raw)
To: git
Hello!
Since cg-X* scripts are not supposed to be used by the end users, I
suggest that we rename them so something not starting with "cg-" or even
"cg" so that tab completion in bash doesn't show them. I suggest "_cgX"
instead of "cg-X"
In the long term, the internal scripts should go to
$prefix/share/cogito, but it would require generating other scripts from
templates to substitute $prefix, which could be inconvenient at this
stage.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: list all dirty files in working directory
From: Andreas Gal @ 2005-05-05 21:35 UTC (permalink / raw)
To: Thomas Glanzmann; +Cc: GIT
In-Reply-To: <20050505212152.GP20994@cip.informatik.uni-erlangen.de>
git-update-cache --refresh | while read line; do
echo $line | cut -d ':' -f 1
done
That should give you one file per line, for every dirty file.
Andreas
On Thu, 5 May 2005, Thomas Glanzmann wrote:
> Hello,
> is there another way than call 'checkout-cache -a' and parse the output?
> Maybe a command which lists one dirty file per line?
>
> Thomas
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: list all dirty files in working directory
From: Thomas Glanzmann @ 2005-05-05 21:32 UTC (permalink / raw)
To: GIT
In-Reply-To: <20050505212152.GP20994@cip.informatik.uni-erlangen.de>
Hello,
* Thomas Glanzmann <sithglan@stud.uni-erlangen.de> [050505 23:24]:
> is there another way than call 'checkout-cache -a' and parse the output?
> Maybe a command which lists one dirty file per line?
of course I meant parsing the output of 'update-cache --refresh'.
Thomas
^ permalink raw reply
* Re: git and symlinks as tracked content
From: Daniel Barkalow @ 2005-05-05 21:23 UTC (permalink / raw)
To: Alan Chandler; +Cc: git
In-Reply-To: <200505050709.43307.alan@chandlerfamily.org.uk>
On Thu, 5 May 2005, Alan Chandler wrote:
> On Thursday 05 May 2005 00:03, Daniel Barkalow wrote:
>
> > (on the other hand, it might make sense for git to handle files starting
> > with '.', and only skip .git).
>
> definitely only as an option. I envisage checking out (maybe anonymously)
> from svn or other repositories and then using git locally to manage my own
> development. It would be preferable for the .git repository not to be
> "polluted" with the svn prisine trees etc
It wouldn't touch them at all unless you specifically added them. The
present situation is that git ignores files starting with "." even if you
specifically add them.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* list all dirty files in working directory
From: Thomas Glanzmann @ 2005-05-05 21:21 UTC (permalink / raw)
To: GIT
Hello,
is there another way than call 'checkout-cache -a' and parse the output?
Maybe a command which lists one dirty file per line?
Thomas
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox