* Re: git-rev-tree ---stdin -s -p broken
From: Thomas Glanzmann @ 2005-05-25 12:49 UTC (permalink / raw)
To: Kay Sievers; +Cc: GIT
In-Reply-To: <20050525123925.GA1481@vrfy.org>
Hello,
> Works for me with the latest git. Does git-rev-list work? Try
> strace'ing git-diff-tree.
false alert. With git HEAD it works. Strange I thought I had verified
that in the first place. Thanks.
Thomas
^ permalink raw reply
* Re: git-rev-tree ---stdin -s -p broken
From: Kay Sievers @ 2005-05-25 12:39 UTC (permalink / raw)
To: GIT
In-Reply-To: <20050525121738.GC24325@cip.informatik.uni-erlangen.de>
On Wed, May 25, 2005 at 02:17:38PM +0200, Thomas Glanzmann wrote:
> Hello,
> this doesn't produce any output for me:
>
> (faui01) [~/work/git/yagf] git-rev-list HEAD | git-diff-tree --stdin -v -s
> (faui01) [~/work/git/yagf]
Works for me with the latest git.
Does git-rev-list work?
Try strace'ing git-diff-tree.
Kay
^ permalink raw reply
* Re: gitweb wishlist
From: Kay Sievers @ 2005-05-25 12:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vu0ksoxg4.fsf@assigned-by-dhcp.cox.net>
On Tue, May 24, 2005 at 07:23:39PM -0700, Junio C Hamano wrote:
> I was browsing www.kernel.org/git and noticed that it shows
> only files that exist at the tip. How do I get history of a
> file that does not exist anymore at the tip?
>
> For example, diff-helper.c history is (quite correctly)
> truncated somewhere close to where diff-tree-helper.c was
> renamed to it. From the commit log, humans can easily tell that
> it used to be called diff-tree-helper.c. I could not find an
> easy way to see the history of diff-tree-helper.c file.
If git-diff-tree is given the -M:
git-rev-list HEAD | git-diff-tree -r -M --stdin diff-helper.c
and it would print:
99665af5c0be0fe4319b39183e84917993153576 (from 13ab4462d2aefb252d7c916bd537151856b7c967)
:100644 100644 51bb658be4f73c00016b4ecb82f09d30941998a4 51bb658be4f73c00016b4ecb82f09d30941998a4 R10000 diff-tree-helper.c diff-helper.c
instead of:
99665af5c0be0fe4319b39183e84917993153576 (from 13ab4462d2aefb252d7c916bd537151856b7c967)
:000000 100644 0000000000000000000000000000000000000000 51bb658be4f73c00016b4ecb82f09d30941998a4 N diff-helper.c
gitweb could follow the old filename and show the whole history. :)
Thanks,
Kay
^ permalink raw reply
* git-rev-tree ---stdin -s -p broken
From: Thomas Glanzmann @ 2005-05-25 12:17 UTC (permalink / raw)
To: GIT
Hello,
this doesn't produce any output for me:
(faui01) [~/work/git/yagf] git-rev-list HEAD | git-diff-tree --stdin -v -s
(faui01) [~/work/git/yagf]
Thomas
^ permalink raw reply
* change of git-diff-tree and symlinks
From: Kay Sievers @ 2005-05-25 11:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
Hi,
I'm catching up with gitweb.cgi to parse the changed output. Works fine
so far and is really much easier to parse. Here is something that does
not work anymore. See the difference between:
http://www.kernel.org/git/?p=linux/hotplug/udev.git;a=commit;h=49cedafaf893bfe348eb7598227f1a11ae24bfd6
http://ehlo.org/~kay/gitweb.cgi?p=linux/hotplug/udev.git;a=commit;h=49cedafaf893bfe348eb7598227f1a11ae24bfd6
On my box is the lates git with the adapted gitweb.cgi. Here is the raw
output of the old git-diff-tree:
kay@dhcp-188:~/src/udev> /home/kay/src/cogito/git-diff-tree -r 49cedafaf893bfe348eb7598227f1a11ae24bfd6 17f2b1a7e0d10334af7f9622848788add125dea8
*120000->100644 blob 2d78258b1a0fe49afabc8c16a352117df5dc338a->2d78258b1a0fe49afabc8c16a352117df5dc338a test/sys/block/cciss!c0d0/device
*120000->100644 blob 2d78258b1a0fe49afabc8c16a352117df5dc338a->2d78258b1a0fe49afabc8c16a352117df5dc338a test/sys/block/rd!c0d0/device
*120000->100644 blob 2d78258b1a0fe49afabc8c16a352117df5dc338a->2d78258b1a0fe49afabc8c16a352117df5dc338a test/sys/block/sda/device
*120000->100644 blob 1c776568bdc9dc750addd0885dded6b008a44460->1c776568bdc9dc750addd0885dded6b008a44460 test/sys/bus/pci/devices/0000:00:09.0
*120000->100644 blob e000c77614a23ad57fed284bd007ed7c1cb7872e->e000c77614a23ad57fed284bd007ed7c1cb7872e test/sys/bus/pci/devices/0000:00:1e.0
...
The new one shows simply nothing.
Shouldn't it print the mode changes like the old one?
Kay
^ permalink raw reply
* Re: gitweb wishlist
From: David Greaves @ 2005-05-25 10:54 UTC (permalink / raw)
To: Kay Sievers; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <20050525094841.GA24172@vrfy.org>
>>On probably a bit different topic (but I do not know who is
>>updating the copy on www.kernel.org, sorry). Could somebody
>>update http://www.kernel.org/pub/software/scm/git/docs/ to
>>rename git-diff-tree-helper to git-diff-helper please?
>>git.git/Documentation/git.txt has been corrected quite some
>>time ago [*1*] and I do not know how the updates are propagated
>>to the web version of the documentation; is it a manual process?
>>
>>
>
>David Greaves can write to that directory. David?
>
>
Yep.
It is a manual rsync process.
I last ran it on the 22nd as soon as Linus committed my latest doc patches.
It's my bad though - I didn't update index.html which should be a copy
of git.html
http://www.kernel.org/pub/software/scm/git/docs/git.html
is correct.
Anyway, done now, give it time to replicate.
David
^ permalink raw reply
* Re: gitweb wishlist
From: Kay Sievers @ 2005-05-25 9:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List, David Greaves
In-Reply-To: <7vu0ksoxg4.fsf@assigned-by-dhcp.cox.net>
On Tue, May 24, 2005 at 07:23:39PM -0700, Junio C Hamano wrote:
> I was browsing www.kernel.org/git and noticed that it shows
> only files that exist at the tip. How do I get history of a
> file that does not exist anymore at the tip?
>
> For example, diff-helper.c history is (quite correctly)
> truncated somewhere close to where diff-tree-helper.c was
> renamed to it. From the commit log, humans can easily tell that
> it used to be called diff-tree-helper.c. I could not find an
> easy way to see the history of diff-tree-helper.c file.
I will add a search function when the git binaries on kernel.org get an
update. Currently it's cogito-0.10.
> On probably a bit different topic (but I do not know who is
> updating the copy on www.kernel.org, sorry). Could somebody
> update http://www.kernel.org/pub/software/scm/git/docs/ to
> rename git-diff-tree-helper to git-diff-helper please?
> git.git/Documentation/git.txt has been corrected quite some
> time ago [*1*] and I do not know how the updates are propagated
> to the web version of the documentation; is it a manual process?
David Greaves can write to that directory. David?
Kay
^ permalink raw reply
* Re: [PATCH] diff-cache path restriction fix.
From: Ingo Molnar @ 2005-05-25 9:06 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.58.0505242002340.2307@ppc970.osdl.org>
* Linus Torvalds <torvalds@osdl.org> wrote:
> On Tue, 24 May 2005, Junio C Hamano wrote:
> >
> > LT> Also, what language do you actually speak?
> >
> > Japanese.
>
> It is possible it is cultural. I certainly find it harder to read the
> "unexpected" way.
i'm quite sure it's related to ambiguity. The main problem for the human
brain when reading code is ambiguity of expression - ambiguity triggers
'logic' areas of the brain, instead of the 'visual automation' portions
of the brain. Like it or not, most of the code reading we do is all
automatism, if we had to _think_ about the visual structure of the code
we'd be much less effective.
The moment we fall out of automation (you go to the bathroom in the
morning but the toothpaste is empty, or you are in the shop and the
coffee area got moved to another place), we feel unease. Thinking during
normally routine activities means problems, it means distraction, it
meant larger reaction times in the jungle for millions of years, and
that's why the built-in unease. Thinking generates unease _especially_
if you dont expect it and dont want it - even if you happen to be Albert
Einstein or Linus Torvalds ;) [And it's way too easy to let the
autopilot drive all the time - there are people who stop thinking in
their childhood and autopilot through life.]
Coding styles are mostly there to reduce the syntactic ambiguities of
computer languages (and hence reducing parsing complexity), and thus to
make it easier for the human brain to parse them - and thus to give more
brain capacity for the real thinking.
the other interesting question is, why do most coders pick the 'x < 1'
variant? I'm quite sure that's due to most of us having learned coding
via operators. It's "x := 1" and "x /= 2", where the mirror image is not
valid - and we extend that expectation to ambiguous operators too. It's
the more complex entitity (the variable) that we think about first, and
then comes the less complex entity. But if someone has a strong math
background (Junio?) then the "1 < x < 5" syntax could be the natural
thing he got used to.
so as long as the actual expressions are used in an unambiguous way,
it's fine and it's part of the coding style and it's all a matter of
getting used to it. Junio's method is just as unambiguous. How quickly
you can adopt to another coding style is directly related to how
practiced you are at it, but it also depends on your fundamental
abstraction abilities. The overwhelming majority of coders dont "switch"
a coding style that easily, but e.g. people who maintain a large number
of packages or use lots of languages are very good at it. You have the
luxory to be able to read your own coding style all day so it's pretty
natural to feel unease if something else comes along :)
Ingo
^ permalink raw reply
* Re: [PATCH] diff-cache path restriction fix.
From: Ingo Molnar @ 2005-05-25 8:31 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.58.0505241814220.2307@ppc970.osdl.org>
* Linus Torvalds <torvalds@osdl.org> wrote:
> Hmm. According to that logic, ">" and ">=" is superfluous.
>
> Also, what language do you actually speak? Every human language I know
> (admittedly, apart from Finnish they are all related) tends to say
> things like "if you have more than four children, you're in trouble",
> rather than saying "if four is less than the number of children you
> have".
[ add Hungarian to that short list - there it's a pretty natural thing
to say "if four is less than the number of ..." in everyday life :-|
Interestingly, having an insanely complex wacko weird language helps
kids learn abstraction early, and results in an unusually high per
capita proportion of scientists. If China adopted Finnish as a second
language the global domination of the US would be history in 50 years
;-) ]
Ingo
^ permalink raw reply
* Re: [PATCH] show changed tree objects with recursive git-diff-tree
From: Junio C Hamano @ 2005-05-25 6:24 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Linus Torvalds, git
In-Reply-To: <Pine.LNX.4.62.0505231724270.16151@localhost.localdomain>
Sorry, I did not get back to you earlier.
My only hesitation is that I'd rather want to see outputs from
"git-diff-tree -r $O $A" and "git-read-tree $A && git-diff-cache
--cached $O" exactly match by default, but this is quite minor (I
cannot even justify why myself).
As you already know, diff-helper knows it cannot do anything
about trees, so that is not a reason to fear your change.
That said, I have already acquired a habit of running diff-tree
with raw output to see what files have changed between two
trees, relying on the traditional behaviour of showing only
blobs and not trees, so turning this "tree" output on by default
is a minor nuisance to adjust to (it is minor --- I just need to
filter them out by looking at the first 7 bytes of each line).
How about this patch instead? Does it do what you need? My
understanding of your needs is that you do not like having to
call diff-tree (w/o recursive) only to get tree IDs involved,
because you are indeed interested in the whole tree and prefer
recursive behaviour; for that reason I made -t to imply -r.
Only lightly tested.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
diff --git a/diff-tree.c b/diff-tree.c
--- a/diff-tree.c
+++ b/diff-tree.c
@@ -6,6 +6,7 @@ static int show_root_diff = 0;
static int verbose_header = 0;
static int ignore_merges = 1;
static int recursive = 0;
+static int show_tree_entry_in_recursive = 0;
static int read_stdin = 0;
static int diff_output_format = DIFF_FORMAT_HUMAN;
static int detect_rename = 0;
@@ -123,6 +124,8 @@ static int compare_tree_entry(void *tree
if (recursive && S_ISDIR(mode1)) {
int retval;
char *newbase = malloc_base(base, path1, pathlen1);
+ if (show_tree_entry_in_recursive)
+ diff_change(mode1, mode2, sha1, sha2, base, path1);
retval = diff_tree_sha1(sha1, sha2, newbase);
free(newbase);
return retval;
@@ -463,7 +466,7 @@ static int diff_tree_stdin(char *line)
}
static char *diff_tree_usage =
-"git-diff-tree [-p] [-r] [-z] [--stdin] [-M] [-C] [-R] [-S<string>] [-m] [-s] [-v] <tree-ish> <tree-ish>";
+"git-diff-tree [-p] [-r] [-z] [--stdin] [-M] [-C] [-R] [-S<string>] [-m] [-s] [-v] [-t] <tree-ish> <tree-ish>";
int main(int argc, const char **argv)
{
@@ -498,6 +501,10 @@ int main(int argc, const char **argv)
recursive = 1;
continue;
}
+ if (!strcmp(arg, "-t")) {
+ recursive = show_tree_entry_in_recursive = 1;
+ continue;
+ }
if (!strcmp(arg, "-R")) {
reverse_diff = 1;
continue;
diff --git a/Documentation/git-diff-tree.txt b/Documentation/git-diff-tree.txt
--- a/Documentation/git-diff-tree.txt
+++ b/Documentation/git-diff-tree.txt
@@ -9,7 +9,7 @@ git-diff-tree - Compares the content and
SYNOPSIS
--------
-'git-diff-tree' [-p] [-r] [-z] [--stdin] [-M] [-R] [-C] [-S<string>] [-m] [-s] [-v] <tree-ish> <tree-ish> [<pattern>]\*
+'git-diff-tree' [-p] [-r] [-z] [--stdin] [-M] [-R] [-C] [-S<string>] [-m] [-s] [-v] [-t] <tree-ish> <tree-ish> [<pattern>]\*
DESCRIPTION
-----------
@@ -48,6 +48,9 @@ OPTIONS
-r::
recurse
+-t::
+ show tree entry itself as well as subtrees. Implies -r.
+
-z::
\0 line termination on output
^ permalink raw reply
* Re: [PATCH] Make tests more portable
From: Junio C Hamano @ 2005-05-25 5:11 UTC (permalink / raw)
To: Mark Allen; +Cc: git
In-Reply-To: <20050525045229.29706.qmail@web41205.mail.yahoo.com>
>>>>> "MA" == Mark Allen <mrallen1@yahoo.com> writes:
MA> I made some minor changes to the test suite to make the
MA> tests more portable. The sed on Darwin doesn't understand
MA> extended regex, cmp won't read from '-', and xargs doesn't
MA> have an '-r' command line flag.
Thank you for doing this.
MA> The t3000 test was broken because it wasn't updated when
MA> Linus merged Junio's patch to make git-ls-files show
MA> filenames with leading dots. I fixed that with a trivial
MA> addition.
Not updating the tests to match code was my fault, not Linus.
Thanks again for the fix.
^ permalink raw reply
* Re: gitweb wishlist
From: Junio C Hamano @ 2005-05-25 5:09 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0505242153150.2307@ppc970.osdl.org>
>>>>> "LT" == Linus Torvalds <torvalds@osdl.org> writes:
LT> The only sane interface I can think of is to expose the subdirectory
LT> history and then pick from that. Otherwise you'd have to actually type in
LT> the name, which is a bit against the notion of a graphical browsing
LT> interface.
Knowing to type "merge-tree.c" you need to be an old timer ;-).
Since I asked that question I found out that each commit has a
link to the diff and the tree, so if I know when merge-tree.c
disappeared, I can go backwards from there.
I think what is useful, from software archaeologist point of
view, would be to give a way to the web users to use pickaxe.
Type piece of code in the textbox and have the CGI run "rev-log
| diff-tree -S'<that piece of the code>'".
^ permalink raw reply
* Re: gitweb wishlist
From: Linus Torvalds @ 2005-05-25 4:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vu0ksoxg4.fsf@assigned-by-dhcp.cox.net>
On Tue, 24 May 2005, Junio C Hamano wrote:
>
> I was browsing www.kernel.org/git and noticed that it shows
> only files that exist at the tip. How do I get history of a
> file that does not exist anymore at the tip?
The only sane interface I can think of is to expose the subdirectory
history and then pick from that. Otherwise you'd have to actually type in
the name, which is a bit against the notion of a graphical browsing
interface.
Linus
^ permalink raw reply
* [PATCH] Make tests more portable
From: Mark Allen @ 2005-05-25 4:52 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 403 bytes --]
I made some minor changes to the test suite to make the tests more portable. The sed on
Darwin doesn't understand extended regex, cmp won't read from '-', and xargs doesn't have
an '-r' command line flag.
The t3000 test was broken because it wasn't updated when Linus merged Junio's patch to
make git-ls-files show filenames with leading dots. I fixed that with a trivial
addition.
Cheers,
--Mark
[-- Attachment #2: 3636773645-git-tests.patch --]
[-- Type: application/octet-stream, Size: 2586 bytes --]
Make t0000-basic.sh and t0110-environment-names-old.sh more portable.
Fix t3000-ls-files-others to pick up filenames that start with dots.
---
commit 36c3e78b55d6740201296aadd32430c0212ad0bf
tree b17eadf351f4d2a9c7f8851863188ddb8e9e3c5a
parent c4ee2952b3146fe7dc9433b92bf066e55987ef74
author Mark Allen <mallen@aeris.local> 1116996230 -0500
committer Mark Allen <mallen@aeris.local> 1116996230 -0500
t0000-basic.sh | 2 +-
t0110-environment-names-old.sh | 6 ++----
t3000-ls-files-others.sh | 1 +
3 files changed, 4 insertions, 5 deletions
Index: t/t0000-basic.sh
===================================================================
--- 0a6dd114f3cbd19fc9773dc31f19c21b59007800/t/t0000-basic.sh (mode:100755)
+++ b17eadf351f4d2a9c7f8851863188ddb8e9e3c5a/t/t0000-basic.sh (mode:100755)
@@ -84,7 +84,7 @@
done
test_expect_success \
'adding various types of objects with git-update-cache --add.' \
- 'find path* ! -type d -print0 | xargs -0 -r git-update-cache --add'
+ 'find path* ! -type d -print0 | xargs -0 git-update-cache --add'
# Show them and see that matches what we expect.
test_expect_success \
Index: t/t0110-environment-names-old.sh
===================================================================
--- 0a6dd114f3cbd19fc9773dc31f19c21b59007800/t/t0110-environment-names-old.sh (mode:100755)
+++ b17eadf351f4d2a9c7f8851863188ddb8e9e3c5a/t/t0110-environment-names-old.sh (mode:100755)
@@ -86,8 +86,7 @@
EOF
test_expect_success \
'verify old AUTHOR variables were used correctly in commit' \
- 'sed -ne '\''/^\(author\|committer\)/s|>.*|>|p'\'' current |
- cmp - expected'
+ 'sed -ne '\''/^\(author\)/s|>.*|>|p'\'' -e'\''/^\(committer\)/s|>.*|>|p'\''\ current > out && cmp out expected'
unset GIT_DIR
test_expect_success \
@@ -128,7 +127,6 @@
EOF
test_expect_success \
'verify new AUTHOR variables were used correctly in commit.' \
- 'sed -ne '\''/^\(author\|committer\)/s|>.*|>|p'\'' current |
- cmp - expected'
+ 'sed -ne '\''/^\(author\)/s|>.*|>|p'\'' -e'\''/^\(committer\)/s|>.*|>|p'\''\ current > out && cmp out expected'
test_done
Index: t/t3000-ls-files-others.sh
===================================================================
--- 0a6dd114f3cbd19fc9773dc31f19c21b59007800/t/t3000-ls-files-others.sh (mode:100755)
+++ b17eadf351f4d2a9c7f8851863188ddb8e9e3c5a/t/t3000-ls-files-others.sh (mode:100755)
@@ -22,6 +22,7 @@
'git-ls-files --others to show output.' \
'git-ls-files --others >.output'
cat >.expected <<EOF
+.output
path0
path1
path2/file2
^ permalink raw reply
* Re: [PATCH] diff-cache path restriction fix.
From: Junio C Hamano @ 2005-05-25 3:22 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.58.0505242002340.2307@ppc970.osdl.org>
>>>>> "LT" == Linus Torvalds <torvalds@osdl.org> writes:
LT> On Tue, 24 May 2005, Junio C Hamano wrote:
>>
LT> Also, what language do you actually speak?
>>
>> Japanese.
LT> It is possible it is cultural. I certainly find it harder to read the
LT> "unexpected" way.
I doubt it is Japanese vs Western kind of cultural. When I said
"people around me", that set of people did not include a single
Japanese. I meant people who worked with the person I was
trained by to use this style. Cultural, maybe, but that is
programming culture and definitely not natural language culture
in my case.
Here is a quick and dirty experiment which showed quite an
interesting statistics. It counts number of '<' and '>' in the
program text, after stripping out ptr->deref (yes it catches
#include <stdlib.h>, but they even out and it also catches
whatever is in comments, but this is just a Q&D stats for fun).
The percentage is how close the program text is to "visually
ordered" style:
$ cat count-compare.perl
#!/usr/bin/perl -w
for my $filename (@ARGV) {
open I, '<', $filename;
my ($lt, $gt) = (0, 0);
while (<I>) {
s/->//g; # pointer deref not comparison
$lt += tr/</</; # count
$gt += tr/>/>/; # count
}
close I;
my $ratio = ($lt / ($lt + $gt)) * 100;
printf "'<' (%d) '>' (%d) (%d%%) %s\n", $lt, $gt, $ratio, $filename;
}
$ perl count-compare.perl diff*.c
'<' (9) '>' (4) (69%) diff-cache.c
'<' (20) '>' (26) (43%) diff-delta.c
'<' (8) '>' (1) (88%) diff-files.c
'<' (12) '>' (1) (92%) diff-helper.c
'<' (11) '>' (11) (50%) diff-tree.c
'<' (28) '>' (10) (73%) diff.c
'<' (3) '>' (0) (100%) diffcore-pathspec.c
'<' (2) '>' (0) (100%) diffcore-pickaxe.c
'<' (22) '>' (6) (78%) diffcore-rename.c
This clearly shows that diff-delta.c does not have my code at
all. Most of the others have been touched moderately to heavily
by me, or in some cases done entirely by me.
Personally, what I find most interesting is that diff-tree.c is
something you did quite a lot of nice features (and hence
something I was afraid to touch), and the number clearly shows
my hesitation. It does not have as many '<' as it would have
had, if I had mucked with it as freely as I did to the others.
^ permalink raw reply
* Re: [PATCH] diff-cache path restriction fix.
From: Linus Torvalds @ 2005-05-25 3:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v3bscqdlr.fsf@assigned-by-dhcp.cox.net>
On Tue, 24 May 2005, Junio C Hamano wrote:
>
> LT> Also, what language do you actually speak?
>
> Japanese.
It is possible it is cultural. I certainly find it harder to read the
"unexpected" way.
But maybe it's just me. I also have a _really_ hard time with reading
"unless(x)" (aka "if (!(x))"), that perl programmers seem to use.
Linus
^ permalink raw reply
* Re: [PATCH] diff-cache path restriction fix.
From: Junio C Hamano @ 2005-05-25 2:33 UTC (permalink / raw)
To: Russ Allbery; +Cc: git
In-Reply-To: <87u0kscaob.fsf@windlord.stanford.edu>
I do not think there is any right or wrong in this discussion,
so I would not make any more comment on this topic for now.
Your interpretation that "(a cmp-op b) is an assertion on a" is
one valid interpretation of a boolean expression. I would
understand it if you say you are used to think of it as an
assertion about the left hand side. I just do not think of it
that way. Rather, to me, "(a cmp-op b)" (or an boolean
expression in any shape for that matter) as a whole is an
assertion, and it is simply easier for me if a and b are ordered
from left to right, to visually match ascending order.
But that is only because I am used to read programs written that
way. Just like you are used to think of these expressions about
assertions of the left hand side.
^ permalink raw reply
* Re: gitweb wishlist
From: Junio C Hamano @ 2005-05-25 2:23 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <20050524213102.GB19180@vrfy.org>
I was browsing www.kernel.org/git and noticed that it shows
only files that exist at the tip. How do I get history of a
file that does not exist anymore at the tip?
For example, diff-helper.c history is (quite correctly)
truncated somewhere close to where diff-tree-helper.c was
renamed to it. From the commit log, humans can easily tell that
it used to be called diff-tree-helper.c. I could not find an
easy way to see the history of diff-tree-helper.c file.
On probably a bit different topic (but I do not know who is
updating the copy on www.kernel.org, sorry). Could somebody
update http://www.kernel.org/pub/software/scm/git/docs/ to
rename git-diff-tree-helper to git-diff-helper please?
git.git/Documentation/git.txt has been corrected quite some
time ago [*1*] and I do not know how the updates are propagated
to the web version of the documentation; is it a manual process?
[Footnotes]
*1* The following command tells me it was done about 10 days ago.
git-rev-list 0 |
git-diff-tree -S'diff-tree-helper' --stdin -v -p Documentation/git.txt
^ permalink raw reply
* Re: [PATCH] diff-cache path restriction fix.
From: Russ Allbery @ 2005-05-25 2:16 UTC (permalink / raw)
To: git
In-Reply-To: <7v3bscqdlr.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Yes, I was trained by Paul Eggert (me says that proudly).
> Practically speaking, the only time I deliberately used > and >=
> was when I was doing some dialect of SQL that always wanted
> literal on fixed side and column on the other; I do not remember
> which was which and whose SQL anymore.
> Of course I sometimes end up using them when I am trying to
> match the style of existing code. However, for that particular
> comparison in diff-cache, there weren't any other around there
> to match, other than the "if (argc < 2 || ...)" after the loop,
> which was what I myself wrote so it does not count.
My prior programming experience has taught me to read argv > 1 as an
assertion about argv, as opposed to 1 < argv, which would be an assertion
about 1. In other words, as I code, I'm generally thinking about testing
a variable against some sort of boundary condition (which may or may not
be itself variable), and the thing that I'm testing goes first, followed
by the test. As a result, 1 < argv throws me for a moment, since on first
read it seems to imply the programmer was expecting the value of 1 to
change.
--
Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>
^ permalink raw reply
* Re: [PATCH] diff-cache path restriction fix.
From: Junio C Hamano @ 2005-05-25 1:49 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.58.0505241814220.2307@ppc970.osdl.org>
>>>>> "LT" == Linus Torvalds <torvalds@osdl.org> writes:
LT> I checked in the fixed arg parsing already ;)
Thanks.
LT> Hmm. According to that logic, ">" and ">=" is superfluous.
Yes, I was trained by Paul Eggert (me says that proudly).
Practically speaking, the only time I deliberately used > and >=
was when I was doing some dialect of SQL that always wanted
literal on fixed side and column on the other; I do not remember
which was which and whose SQL anymore.
Of course I sometimes end up using them when I am trying to
match the style of existing code. However, for that particular
comparison in diff-cache, there weren't any other around there
to match, other than the "if (argc < 2 || ...)" after the loop,
which was what I myself wrote so it does not count.
LT> Also, what language do you actually speak?
Japanese.
I have not thought about that kind of relationship between the
natural language and if() expression at all, and I am certainly
not claiming comparing it the logic way is natural in Japanese.
I think it probably isn't.
LT> ... Usually google is a good way to get a feel for how
LT> common some phrase is, but not on things like this.
If you feel strongly about this, just write it in coding-style
document and I'll follow whatever you tell me while I am coding
for this project. Honestly, I do not particularly care how
common that is in the wider world outside.
^ permalink raw reply
* Re: [PATCH] diff-cache path restriction fix.
From: Linus Torvalds @ 2005-05-25 1:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vekbwru6x.fsf@assigned-by-dhcp.cox.net>
On Tue, 24 May 2005, Junio C Hamano wrote:
> >>>>> "LT" == Linus Torvalds <torvalds@osdl.org> writes:
>
> LT> No, it's more broken than that.
>
> I'll take a look at this later and submit an update, but an OT
> point I feel I should address.
I checked in the fixed arg parsing already ;)
> The comparison lists things in the ascending order from left to
> right. The fact that 1 comes before argc on that line of code
> visually makes it obvious that I am talking about argc being
> larger than one and that is the reason. I'd write (argc < 4)
> not (4 > argc) for the same reason.
Hmm. According to that logic, ">" and ">=" is superfluous.
Also, what language do you actually speak? Every human language I know
(admittedly, apart from Finnish they are all related) tends to say things
like "if you have more than four children, you're in trouble", rather than
saying "if four is less than the number of children you have".
Notice? People compare something _to_ a number. They don't compare a
number to something. We say "if more than four", we don't say "if four is
less".
Sadly, I can't get google to match "1 < x" and "x > 1" (it just considers
all special characters to be basically whitespace, so "1 < x" matches "1
x" and "1.x" according to google. Usually google is a good way to get a
feel for how common some phrase is, but not on things like this.
Linus
^ permalink raw reply
* [PATCH] Allow dot files in ls-files as well (take #2).
From: Junio C Hamano @ 2005-05-25 1:20 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.58.0505241753300.2307@ppc970.osdl.org>
This attempts to match "the directory '.git' anywhere in the
tree is ignored" approach taken in update-cache.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
cd /opt/packrat/playpen/public/in-place/git/git.junio/
PATH=.:$PATH jit-diff : ls-files.c
# - linus: git-update-cache: allow dot-files
# + (working tree)
diff --git a/ls-files.c b/ls-files.c
--- a/ls-files.c
+++ b/ls-files.c
@@ -136,7 +136,10 @@ static void read_directory(const char *p
while ((de = readdir(dir)) != NULL) {
int len;
- if (de->d_name[0] == '.')
+ if ((de->d_name[0] == '.') &&
+ (de->d_name[1] == 0 ||
+ !strcmp(de->d_name + 1, ".") ||
+ !strcmp(de->d_name + 1, "git")))
continue;
if (excluded(de->d_name) != show_ignored)
continue;
^ permalink raw reply
* Re: git-update-cache: allow dot-files
From: Junio C Hamano @ 2005-05-25 1:11 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.58.0505241748520.2307@ppc970.osdl.org>
>>>>> "LT" == Linus Torvalds <torvalds@osdl.org> writes:
LT> Heh. There's a difference between being anal, and allowing people to shoot
LT> themselves in the foot.
How about we do something like this:
(1) we keep hardcoded .git refusing as you did;
(2) we forbid GIT_DIR to be set to anything other than what
ends with "/.git", unless it is literally ".git";
^ permalink raw reply
* Re: [PATCH] Allow dot files in ls-files as well.
From: Junio C Hamano @ 2005-05-25 1:06 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.58.0505241753300.2307@ppc970.osdl.org>
>>>>> "LT" == Linus Torvalds <torvalds@osdl.org> writes:
LT> You really _do_ want to strip out the ".git" file.
Yes I do, but not probably hardcoded ".git".
^ permalink raw reply
* Re: [PATCH] diff-cache path restriction fix.
From: Junio C Hamano @ 2005-05-25 1:05 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.58.0505241757280.2307@ppc970.osdl.org>
>>>>> "LT" == Linus Torvalds <torvalds@osdl.org> writes:
LT> No, it's more broken than that.
I'll take a look at this later and submit an update, but an OT
point I feel I should address.
LT> Btw, that "1 < argc" order is very unintuitive to most humans.
Yeah? Not to people around where I come from, I do not know
why. It is not done for the assignment confusion avoidance
"1==a".
The comparison lists things in the ascending order from left to
right. The fact that 1 comes before argc on that line of code
visually makes it obvious that I am talking about argc being
larger than one and that is the reason. I'd write (argc < 4)
not (4 > argc) for the same reason.
^ 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