* Re: change of git-diff-tree and symlinks
From: Junio C Hamano @ 2005-05-25 22:43 UTC (permalink / raw)
To: Kay Sievers; +Cc: Linus Torvalds, Git Mailing List
In-Reply-To: <20050525222622.GA8552@vrfy.org>
>>>>> "KS" == Kay Sievers <kay.sievers@vrfy.org> writes:
KS> If we introduce 'T', how is a content _and_ a type change represented
KS> if they happen at the same time?
If you have this pair in two trees:
ln -s frotz xyzzy
echo -n frotz >xyzzy
it is a 'T'. If you instead have these in two trees:
ln -s rezrov xyzzy
echo -n frotz >xyzzy
it is also a 'T'.
I do not think we would want patch format to give us a diff
showing that string rezrov changing into frotz in the latter
example anyway. When we have a type change, content change is
irrelevant.
^ permalink raw reply
* Re: change of git-diff-tree and symlinks
From: Kay Sievers @ 2005-05-25 22:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, Git Mailing List
In-Reply-To: <7vzmujjdq4.fsf@assigned-by-dhcp.cox.net>
On Wed, May 25, 2005 at 12:40:51PM -0700, Junio C Hamano wrote:
> >>>>> "KS" == Kay Sievers <kay.sievers@vrfy.org> writes:
>
> KS> Ok, works again. Any reason not to mark it as 'M'? It's easyly to
> KS> distinguish between a content change and a mode change by looking if
> KS> the sha has changed.
>
> I'd need some time to think about this in the evening (I'm at
> work now) but I think Linus did '?' as an interim measure. I
> suspect 'M' would work just as well without introducing a new
> class 'T', but on the other hand having them distinct would be
> easier for people who read diff-raw format, so my knee-jerk
> reaction is that we should use 'T'. It's the same reasoning to
> have N, D, and U --- they can be gleaned by looking at mode and
> sha fields and there is no need to mark them any differently but
> surely marking them the way we do now is much nicer.
If we introduce 'T', how is a content _and_ a type change represented
if they happen at the same time?
Kay
^ permalink raw reply
* [PATCH] Fix type-change handling when assigning the status code to filepairs.
From: Junio C Hamano @ 2005-05-25 22:07 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Kay Sievers, Git Mailing List
In-Reply-To: <7vzmujjdq4.fsf@assigned-by-dhcp.cox.net>
The interim single-liner '?' fix resulted delete entries that
should not have emitted coming out in the output as an
unintended side effect; I caught this with the "rename" test in
the test suite. This patch instead fixes the code that assigns
the status code to each filepair.
I verified this does not break the testcase in udev.git tree Kay
Sievers gave us, by running git-diff-tree on that tree which
showed 21 file to symlink changes.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
*** Linus, it just struck me that there is nothing inherently
*** wrong to detect whole subtree renames (diffcore-rename
*** currently does not attempt to match tree creation against
*** tree delete to produce tree rename/copy). This is something
*** I am _not_ going to do, but it still would be interesting to
*** keep in mind...
diff.c | 36 ++++++++++++++++++++++--------------
diffcore.h | 3 +++
2 files changed, 25 insertions(+), 14 deletions(-)
diff --git a/diff.c b/diff.c
--- a/diff.c
+++ b/diff.c
@@ -691,27 +691,34 @@ static void diff_resolve_rename_copy(voi
for (i = 0; i < q->nr; i++) {
p = q->queue[i];
- p->status = 0;
+ p->status = 0; /* undecided */
if (DIFF_PAIR_UNMERGED(p))
p->status = 'U';
else if (!DIFF_FILE_VALID((p)->one))
p->status = 'N';
else if (!DIFF_FILE_VALID((p)->two)) {
/* Deletion record should be omitted if there
- * is another entry that is a rename or a copy
- * and it uses this one as the source. Then we
- * can say the other one is a rename.
+ * are rename/copy entries using this one as
+ * the source. Then we can say one of them
+ * is a rename and the rest are copies.
*/
+ p->status = 'D';
for (j = 0; j < q->nr; j++) {
pp = q->queue[j];
if (!strcmp(pp->one->path, p->one->path) &&
- strcmp(pp->one->path, pp->two->path))
+ strcmp(pp->one->path, pp->two->path)) {
+ p->status = 'X';
break;
+ }
}
- if (j < q->nr)
- continue; /* has rename/copy */
- p->status = 'D';
}
+ else if (DIFF_PAIR_TYPE_CHANGED(p))
+ p->status = 'T';
+
+ /* from this point on, we are dealing with a pair
+ * whose both sides are valid and of the same type, i.e.
+ * either in-place edit or rename/copy edit.
+ */
else if (strcmp(p->one->path, p->two->path)) {
/* See if there is somebody else anywhere that
* will keep the path (either modified or
@@ -719,7 +726,7 @@ static void diff_resolve_rename_copy(voi
* not a rename. In addition, if there is
* some other rename or copy that comes later
* than us that uses the same source, we
- * cannot be a rename either.
+ * have to be a copy, not a rename.
*/
for (j = 0; j < q->nr; j++) {
pp = q->queue[j];
@@ -745,10 +752,9 @@ static void diff_resolve_rename_copy(voi
}
else if (memcmp(p->one->sha1, p->two->sha1, 20))
p->status = 'M';
- else {
- /* we do not need this one */
- p->status = 0;
- }
+ else
+ /* this is a "no-change" entry */
+ p->status = 'X';
}
diff_debug_queue("resolve-rename-copy done", q);
}
@@ -767,8 +773,10 @@ void diff_flush(int diff_output_style, i
for (i = 0; i < q->nr; i++) {
struct diff_filepair *p = q->queue[i];
+ if (p->status == 'X')
+ continue;
if (p->status == 0)
- p->status = '?';
+ die("internal error in diff-resolve-rename-copy");
switch (diff_output_style) {
case DIFF_FORMAT_PATCH:
diff_flush_patch(p);
diff --git a/diffcore.h b/diffcore.h
--- a/diffcore.h
+++ b/diffcore.h
@@ -45,6 +45,9 @@ struct diff_filepair {
#define DIFF_PAIR_UNMERGED(p) \
(!DIFF_FILE_VALID((p)->one) && !DIFF_FILE_VALID((p)->two))
+#define DIFF_PAIR_TYPE_CHANGED(p) \
+ ((S_IFMT & (p)->one->mode) != (S_IFMT & (p)->two->mode))
+
extern int diff_unmodified_pair(struct diff_filepair *);
struct diff_queue_struct {
------------------------------------------------
^ permalink raw reply
* [PATCH] Adjust show-files test for dotfiles.
From: Junio C Hamano @ 2005-05-25 22:06 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Kay Sievers, Git Mailing List
In-Reply-To: <7vzmujjdq4.fsf@assigned-by-dhcp.cox.net>
The earlier test was relying on the fact that dotfiles do not
appear in the output to prepare expected test results, which
inevitably got broken when we started handling dotfiles. Change
the test to be honest about what "--other" file it creates.
The problem was originally pointed out by Mark Allen.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
t/t3000-ls-files-others.sh | 7 ++++---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/t/t3000-ls-files-others.sh b/t/t3000-ls-files-others.sh
--- a/t/t3000-ls-files-others.sh
+++ b/t/t3000-ls-files-others.sh
@@ -20,8 +20,9 @@ mkdir path2
date >path2/file2
test_expect_success \
'git-ls-files --others to show output.' \
- 'git-ls-files --others >.output'
-cat >.expected <<EOF
+ 'git-ls-files --others >output'
+cat >expected <<EOF
+output
path0
path1
path2/file2
@@ -29,5 +30,5 @@ EOF
test_expect_success \
'git-ls-files --others should pick up symlinks.' \
- 'diff .output .expected'
+ 'diff output expected'
test_done
------------------------------------------------
^ permalink raw reply
* Re: [PATCH] diff-cache path restriction fix.
From: Matthias Urlichs @ 2005-05-25 20:31 UTC (permalink / raw)
To: git
In-Reply-To: <20050525090616.GB27025@elte.hu>
Hi, Ingo Molnar wrote:
> But if someone has a strong math background
> (Junio?) then the "1 < x < 5" syntax could be the natural thing he got
> used to.
Or Python -- and I assume there are more languages where this idiom works
correctly.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
^ permalink raw reply
* Re: gitweb wishlist
From: David Greaves @ 2005-05-25 20:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Kay Sievers, Git Mailing List
In-Reply-To: <7vll63ktfc.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
>>>>>>"DG" == David Greaves <david@dgreaves.com> writes:
>>>>>>
>>>>>>
>
>DG> Anyway, done now, give it time to replicate.
>
>Thanks. Would something like the following (1) easy to arrange
>and (2) make your life easier?
>
> - make index.html symlink to git.html
> - have cron job to build and install those pages at
> www.kernel.org
>
>
Hmm - sounds complicated ;)
--
^ permalink raw reply
* Re: change of git-diff-tree and symlinks
From: Junio C Hamano @ 2005-05-25 19:40 UTC (permalink / raw)
To: Kay Sievers; +Cc: Linus Torvalds, Git Mailing List
In-Reply-To: <20050525183546.GA4241@vrfy.org>
>>>>> "KS" == Kay Sievers <kay.sievers@vrfy.org> writes:
KS> Ok, works again. Any reason not to mark it as 'M'? It's easyly to
KS> distinguish between a content change and a mode change by looking if
KS> the sha has changed.
I'd need some time to think about this in the evening (I'm at
work now) but I think Linus did '?' as an interim measure. I
suspect 'M' would work just as well without introducing a new
class 'T', but on the other hand having them distinct would be
easier for people who read diff-raw format, so my knee-jerk
reaction is that we should use 'T'. It's the same reasoning to
have N, D, and U --- they can be gleaned by looking at mode and
sha fields and there is no need to mark them any differently but
surely marking them the way we do now is much nicer.
More importantly I need to double check that diffcore stuff
including rename/copy are doing the right thing about type
changes. If some of them are throwing type-change pair away
under certain obscure conditions, then tweaking the part Linus
added the '?' is too late to remedy the situation.
^ permalink raw reply
* [PATCH] update cogito cg-diff to use new git diff format
From: McMullan, Jason @ 2005-05-25 19:38 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 1552 bytes --]
Updates cg-Xdiffdo to handle the new cg-diff-* output format
(Not strictly necessary, since git-diff-* -p is better anyway, but if
someone is relying on cg-* Porcelain....)
Signed-Off-By: Jason McMullan <jason.mcmullan@timesys.com>
Index: cg-Xdiffdo
===================================================================
--- be7e79d03a25ad69405c8e17c024f0c83a9d16cd/cg-Xdiffdo (mode:100755)
+++ uncommitted/cg-Xdiffdo (mode:100755)
@@ -48,13 +48,13 @@
while [ "$1" ]; do
declare -a param
- param=($1);
- op=${param[0]:0:1}
- mode=${param[0]:1}
- type=${param[1]}
- sha=${param[2]}
- name=${param[3]}
+ param=($1 $2);
+ mode=${param[0]:1}"->"${param[1]}
+ sha=${param[2]}"->"${param[3]}
+ op=${param[4]}
+ name=${param[5]}
+ type=`git-cat-file -t $sha`
if [ "$filter" ] && (echo "$name" | grep -vqxFf $filter); then
shift; continue
fi
@@ -72,15 +72,15 @@
([ -d "$dir1" ] && [ -d "$dir2" ]) || mkdir -p "$dir1" "$dir2"
case $op in
- "+")
+ "A")
mkbanner "$loc2" $id2 "$name" $mode $sha
diff -L "/dev/null (tree:$id1)" -L "$label" -u /dev/null "$loc2"
;;
- "-")
+ "D")
mkbanner "$loc1" $id1 "$name" $mode $sha
diff -L "$label" -L "/dev/null (tree:$id2)" -u "$loc1" /dev/null
;;
- "*")
+ "M")
modes=(${mode/->/ });
mode1=${modes[0]}; mode2=${modes[1]}
shas=(${sha/->/ });
@@ -94,7 +94,7 @@
esac
#rm -f "$loc1" "$loc2"
- shift
+ shift 2
done
rm -rf "$diffdir"
--
Jason McMullan <jason.mcmullan@timesys.com>
TimeSys Corporation
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] show changed tree objects with recursive git-diff-tree
From: Junio C Hamano @ 2005-05-25 19:18 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Linus Torvalds, git
In-Reply-To: <Pine.LNX.4.62.0505250934040.16151@localhost.localdomain>
>>>>> "NP" == Nicolas Pitre <nico@cam.org> writes:
NP> Now there is only the minor inconsistency that the recursive output
NP> without -t doesn't display tree objects while the non recursive output
NP> does output tree objects regardless. Do we care?
Hmph. I agree, although I do not care about that much myself
enough to start coding right now. With luck I may have
something by tomorrow morning US Pacific time though.
^ permalink raw reply
* Re: [PATCH] diff-cache path restriction fix.
From: Thomas Glanzmann @ 2005-05-25 19:17 UTC (permalink / raw)
To: git
In-Reply-To: <7vpsvfktiw.fsf@assigned-by-dhcp.cox.net>
Hello,
> return !!some_function();
I actually wanted to send a diff to get rid of this thing from
sha_file.c :-)
Thomas
^ permalink raw reply
* Re: gitweb wishlist
From: Junio C Hamano @ 2005-05-25 19:16 UTC (permalink / raw)
To: David Greaves; +Cc: Kay Sievers, Git Mailing List
In-Reply-To: <42945961.8060708@dgreaves.com>
>>>>> "DG" == David Greaves <david@dgreaves.com> writes:
DG> Anyway, done now, give it time to replicate.
Thanks. Would something like the following (1) easy to arrange
and (2) make your life easier?
- make index.html symlink to git.html
- have cron job to build and install those pages at
www.kernel.org
^ permalink raw reply
* Re: [PATCH] diff-cache path restriction fix.
From: Junio C Hamano @ 2005-05-25 19:14 UTC (permalink / raw)
To: Ingo Molnar; +Cc: Linus Torvalds, git
In-Reply-To: <20050525090616.GB27025@elte.hu>
>>>>> "IM" == Ingo Molnar <mingo@elte.hu> writes:
IM> ... But if someone has a strong math
IM> background (Junio?) then the "1 < x < 5" syntax could be the natural
IM> thing he got used to.
I was trained by somebody with a strong math background, but I
suspect he insisted that ordering not from math reasons. The
reason given to me was "visual ordering".
I suck at math myself. I even get confused when people do
return !!some_function();
^ permalink raw reply
* Re: gitweb wishlist
From: Junio C Hamano @ 2005-05-25 19:01 UTC (permalink / raw)
To: Kay Sievers; +Cc: GIT
In-Reply-To: <20050525125143.GB1481@vrfy.org>
Stupidly, I use "%d" without precision to output score, and
worse yet the score is not scaled (meaning it would change when
definition of MAX_SCORE changes, exposing internal scale that
rename/copy uses).
For the sake of parsability, I think I should make that number
always 3 digit and per-cent; so 86% hit would be "C086" and the
bogus R10000 you pointed out would become "R100".
^ permalink raw reply
* Re: gitweb wishlist
From: Junio C Hamano @ 2005-05-25 19:01 UTC (permalink / raw)
To: Kay Sievers; +Cc: Git Mailing List
In-Reply-To: <20050525123544.GA1420@vrfy.org>
>>>>> "KS" == Kay Sievers <kay.sievers@vrfy.org> writes:
KS> gitweb could follow the old filename and show the whole history. :)
Yes, it would work for diff-helper.c, but not for merge-tree.c,
which does not have any equivalent in the tip of the tree.
^ permalink raw reply
* Re: change of git-diff-tree and symlinks
From: Kay Sievers @ 2005-05-25 18:35 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0505251054110.2307@ppc970.osdl.org>
On Wed, May 25, 2005 at 11:08:54AM -0700, Linus Torvalds wrote:
>
>
> On Wed, 25 May 2005, Kay Sievers wrote:
> >
> > 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
>
> Yes, the new diff-tree thing doesn't show symlinks.
>
> The problem seems to be that we just don't have a "status" flag for it. I
> think we should call it "T" for "Type change" or something, but in the
> meantime let's just have the rule that instead of ignoring unknown state
> changes, we always print them out as "?" instead.
>
> Ie something like this..
>
> (And I'd suggest you make gitweb flexible enough that it does something
> sane if it sees an unknown reason code - let's see what Junio thinks about
> what status code we should use for this).
Ok, works again. Any reason not to mark it as 'M'? It's easyly to
distinguish between a content change and a mode change by looking if
the sha has changed.
Kay
^ permalink raw reply
* Re: git-rev-tree ---stdin -s -p broken
From: Linus Torvalds @ 2005-05-25 18:14 UTC (permalink / raw)
To: Thomas Glanzmann; +Cc: GIT
In-Reply-To: <20050525121738.GC24325@cip.informatik.uni-erlangen.de>
On Wed, 25 May 2005, Thomas Glanzmann wrote:
>
> this doesn't produce any output for me:
I think you're hitting the bug where "-s" was broken for a while
yesterday, and was a bit _too_ silent.
It was fixed by the
"Use DIFF_FORMAT_NO_OUTPUT to implement diff-tree -s option"
commit. So update your git repo, you should be ok.
Linus
^ permalink raw reply
* [PATCH] Make cvs2git support remote CVS repos
From: Mark Allen @ 2005-05-25 18:11 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 630 bytes --]
Added a "--module=cvsmodule" command line option and (since we're going to process argv
anyway) made "-v" for verbose mode a command line option too, instead of a compile time
option.
I've tested it on some (small) private CVS repos and it *seems* to work, although some of
the initial commit ordering is wrong, but I think this is due to the commit time being
wrong within my CVS repo itself.
I didn't make author and email prettyprint, but I really want to make it a command line
option, the discussion from yesterday about whether prettyprinting should be at the
plumbing or porcelain layer notwithstanding.
Regards,
--Mark
[-- Attachment #2: 1888918109-add-remote-cvs.patch --]
[-- Type: application/octet-stream, Size: 1580 bytes --]
Index: cvs2git.c
===================================================================
--- a0e0d3940c350f14545a481b179217f626c93440/cvs2git.c (mode:100644)
+++ uncommitted/cvs2git.c (mode:100644)
@@ -32,6 +32,8 @@
};
static char *rcsdir;
+static char *cvsroot;
+static char *cvsmodule;
static char date[100];
static char author[100];
@@ -194,9 +196,13 @@
if (dir)
printf("mkdir -p %.*s\n", (int)(dir - name), name);
- get_rcs_name(rcspathname, name, dir);
-
- printf("co -q -p -r%s '%s' > '%s'\n", version, rcspathname, name);
+ if ( !cvsmodule ) {
+ get_rcs_name(rcspathname, name, dir);
+ printf("co -q -p -r%s '%s' > '%s'\n", version, rcspathname, name);
+ } else {
+ printf("cvs -d %s checkout -r%s -p '%s/%s' > '%s'\n", cvsroot, version, cvsmodule, name, name);
+ }
+
printf("git-update-cache --add -- '%s'\n", name);
}
@@ -217,13 +223,34 @@
{
static char line[1000];
enum state state = Header;
+ int i;
+
+ for (i = 1; i < argc; i++) {
+ const char *arg = argv[i];
+ if (!memcmp(arg, "--module=", 9)) {
+ cvsroot = getenv("CVSROOT");
+ cvsmodule = (char *)arg+9;
+ continue;
+ }
+ if (!strcmp(arg, "-v")) {
+ verbose = 1;
+ continue;
+ }
+ }
+
+ if (!cvsmodule)
+ rcsdir = getenv("RCSDIR");
- rcsdir = getenv("RCSDIR");
- if (!rcsdir) {
+ if (!cvsmodule && !rcsdir) {
fprintf(stderr, "I need an $RCSDIR\n");
exit(1);
}
+ if (cvsmodule && !cvsroot) {
+ fprintf(stderr, "I need a $CVSROOT\n");
+ exit(1);
+ }
+
printf("[ -d .git ] && exit 1\n");
printf("git-init-db\n");
printf("mkdir -p .git/refs/heads\n");
^ permalink raw reply
* Re: change of git-diff-tree and symlinks
From: Linus Torvalds @ 2005-05-25 18:08 UTC (permalink / raw)
To: Kay Sievers; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <20050525111711.GA27492@vrfy.org>
On Wed, 25 May 2005, Kay Sievers wrote:
>
> 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
Yes, the new diff-tree thing doesn't show symlinks.
The problem seems to be that we just don't have a "status" flag for it. I
think we should call it "T" for "Type change" or something, but in the
meantime let's just have the rule that instead of ignoring unknown state
changes, we always print them out as "?" instead.
Ie something like this..
(And I'd suggest you make gitweb flexible enough that it does something
sane if it sees an unknown reason code - let's see what Junio thinks about
what status code we should use for this).
Linus
----
diff --git a/diff.c b/diff.c
--- a/diff.c
+++ b/diff.c
@@ -768,7 +768,7 @@ void diff_flush(int diff_output_style, i
for (i = 0; i < q->nr; i++) {
struct diff_filepair *p = q->queue[i];
if (p->status == 0)
- continue;
+ p->status = '?';
switch (diff_output_style) {
case DIFF_FORMAT_PATCH:
diff_flush_patch(p);
^ permalink raw reply
* gitk feature request
From: H. Peter Anvin @ 2005-05-25 17:29 UTC (permalink / raw)
To: Git Mailing List, paulus
It would be really nice to be able to select a set of commits in gitk
and write out a patch from one to the other -- just a wrapper arount
git-diff.
-hpa
^ permalink raw reply
* [PATCH] optimize git-resolve-script
From: Jeff Garzik @ 2005-05-25 17:21 UTC (permalink / raw)
To: Linus Torvalds, Git Mailing List
[-- Attachment #1: Type: text/plain, Size: 126 bytes --]
This change was suggested for my git-switch-tree script, so it probably
applies to core git's git-resolve-script as well.
[-- Attachment #2: patch --]
[-- Type: text/plain, Size: 793 bytes --]
diff --git a/git-resolve-script b/git-resolve-script
--- a/git-resolve-script
+++ b/git-resolve-script
@@ -39,7 +39,7 @@ if [ "$common" == "$head" ]; then
echo "Destroying all noncommitted data!"
echo "Kill me within 3 seconds.."
sleep 3
- git-read-tree -m $merge && git-checkout-cache -f -a && git-update-cache --refresh
+ git-read-tree -m $merge && git-checkout-cache -f -u -a
echo $merge > "$GIT_DIR"/HEAD
git-diff-tree -p ORIG_HEAD HEAD | diffstat -p1
exit 0
@@ -57,5 +57,5 @@ fi
result_commit=$(echo "$merge_msg" | git-commit-tree $result_tree -p $head -p $merge)
echo "Committed merge $result_commit"
echo $result_commit > "$GIT_DIR"/HEAD
-git-checkout-cache -f -a && git-update-cache --refresh
+git-checkout-cache -f -u -a
git-diff-tree -p ORIG_HEAD HEAD | diffstat -p1
^ permalink raw reply
* Re: [PATCH] diff-cache path restriction fix.
From: Linus Torvalds @ 2005-05-25 17:07 UTC (permalink / raw)
To: Ingo Molnar; +Cc: Junio C Hamano, git
In-Reply-To: <20050525090616.GB27025@elte.hu>
On Wed, 25 May 2005, Ingo Molnar wrote:
>
> 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.
Absolutely. And you _should_ like it, because it means that you can
concentrate on the big problems.
I suspect I react more strongly to some coding style issues than most,
exactly because I've been so involved with just one language and one style
for so long that I've got more of an auto-pilot than most: normally my
brain just coasts past 99% of all code, without having to be very
conscious about it at all, exactly because the patterns have become so
ingrained.
In contrast, somebody who works on different projects and with many
different languages is likely to have many more patterns, but they are
probably less deep, so breaking them isn't as disturbing.
> But if someone has a strong math background (Junio?) then
> the "1 < x < 5" syntax could be the natural thing he got used to.
Actually, even in math (in fact, very _much_ in math) I'd say that people
always aim to put the variable on the left side, and you very much tend to
try to aim for canonical formats (sort by exponent and variable name).
You'd never see anybody write "y + x = 5" or "x + x^2", because there's a
canonical format for it, and people use it.
The "1 < x < 5" syntax is very much the odd man out, and that order for
the first part is _only_ used for two-sided comparisons afaik. Math people
(at least all math texts I've ever seen, and I had math as a strong minor
although admittedly that is some time ago) will invariably write the
variable on the left side if there's just one comparison.
In fact, in math, I'd expect a person to often tend to take the canonical
format even further, and sort _everything_ to the left side, and aim to
leave the right side totally empty (ie "0"), exactly because that makes
certain combinations much easier. So it wouldn't surprise me at all to see
a math person change "x > 1" into "x - 1 > 0", but it _would_ surprise me
to see a math person change it into "1 < x" unless it is to combine it
with _another_ comparison with "x".
Linus
^ permalink raw reply
* Re: [PATCH] diff-cache path restriction fix.
From: Florian Weimer @ 2005-05-25 16:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git
In-Reply-To: <7vekbwru6x.fsf@assigned-by-dhcp.cox.net>
* Junio C. Hamano:
> 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".
In a comparison, it's common to mention the most-varying part first.
If you do this consistently, it increases readability.
^ permalink raw reply
* Re: [PATCH] show changed tree objects with recursive git-diff-tree
From: Nicolas Pitre @ 2005-05-25 13:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git
In-Reply-To: <7vmzqjn7qh.fsf@assigned-by-dhcp.cox.net>
On Tue, 24 May 2005, Junio C Hamano wrote:
> 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.
Yes, that does what I need, thanks.
Now there is only the minor inconsistency that the recursive output
without -t doesn't display tree objects while the non recursive output
does output tree objects regardless. Do we care?
Nicolas
^ permalink raw reply
* Re: gitweb wishlist
From: Kay Sievers @ 2005-05-25 12:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: GIT
In-Reply-To: <20050525123544.GA1420@vrfy.org>
On Wed, May 25, 2005 at 02:35:44PM +0200, Kay Sievers wrote:
> 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
^^^^^
Btw:
Can we add a leading '0' to have 3-digit values every time? It's pretty
stupid to get the '100' out ot that field instead of '10'. :)
Kay
^ permalink raw reply
* 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
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