* Re: [PATCH] Resurrect diff-tree-helper -R
From: Daniel Jacobowitz @ 2005-05-01 1:47 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.58.0504301805300.2296@ppc970.osdl.org>
On Sat, Apr 30, 2005 at 06:09:53PM -0700, Linus Torvalds wrote:
> So it would be much nicer (I think) if mode changes are handled
> separately, with a simple separate line before the diff saying
>
> "Mode change: %o->%o %s", oldmode, newmode, path
>
> and not mess up the diff header. That way, you only see it when it
> actually makes any difference, and it's more readable both for humans
> _and_ machines as a result.
>
> Normal "patch" will just ignore the extra lines before the diff anyway, so
> it won't matter there.
>
> Comments?
It sounds good - but could you efficiently collect them before any diff
output? If you have something like this, it'll be easy to read:
Mode change: 644->755 foo.sh
Mode change: 644->755 bar.sh
--- ChangeLog
+++ ChangeLog
@@ -1,0 +1,1 @@
+New line
--- copyright
+++ copyright
@@ -1,0 +1,1 @@
+New line
But if you generate this then you might as well not generate the mode
lines at all, for all a human looking at the diff is going to notice
them:
--- ChangeLog
+++ ChangeLog
@@ -1,0 +1,1 @@
+New line
Mode change: 644->755 foo.sh
--- copyright
+++ copyright
@@ -1,0 +1,1 @@
+New line
Mode change: 644->755 bar.sh
The latter is how diff does its "Only in" messages. I never see them
when I'm looking through a diff of any size; only via diffstat, where
they're clearly disambiguated.
--
Daniel Jacobowitz
CodeSourcery, LLC
^ permalink raw reply
* Re: [PATCH] Resurrect diff-tree-helper -R
From: Linus Torvalds @ 2005-05-01 1:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7jij3htp.fsf@assigned-by-dhcp.cox.net>
On Sat, 30 Apr 2005, Junio C Hamano wrote:
>
> Diff-tree-helper take two patch inadvertently dropped the
> support of -R option
Talking about the diffs, I'm beginning to hate those "mode" things.
Not only do they screw up diffstat (big deal), but they are pointless,
since 99.9% of the time the mode stays the same.
So it would be much nicer (I think) if mode changes are handled
separately, with a simple separate line before the diff saying
"Mode change: %o->%o %s", oldmode, newmode, path
and not mess up the diff header. That way, you only see it when it
actually makes any difference, and it's more readable both for humans
_and_ machines as a result.
Normal "patch" will just ignore the extra lines before the diff anyway, so
it won't matter there.
Comments?
Linus
^ permalink raw reply
* Re: Trying to use AUTHOR_DATE
From: H. Peter Anvin @ 2005-04-30 23:14 UTC (permalink / raw)
To: David Woodhouse; +Cc: Edgar Toernig, Linus Torvalds, Luck, Tony, git
In-Reply-To: <1114859594.24014.60.camel@localhost.localdomain>
David Woodhouse wrote:
> On Sat, 2005-04-30 at 12:53 +0200, Edgar Toernig wrote:
>
>>+ tm = localtime(&now); /* get timezone and tm_isdst */
>>+ offset = -timezone / 60;
>>+ if (tm->tm_isdst > 0)
>>+ offset += 60;
>
>
> Some locales have DST offsets which aren't 60 minutes, don't they?
>
Correct. I believe South Australia is among them.
-hpa
^ permalink raw reply
* Re: Trying to use AUTHOR_DATE
From: Linus Torvalds @ 2005-04-30 23:18 UTC (permalink / raw)
To: Edgar Toernig; +Cc: git
In-Reply-To: <20050501005434.2d47131a.froese@gmx.de>
On Sun, 1 May 2005, Edgar Toernig wrote:
>
> > I'll probably tweak it a bit more (make "no timezone means local
> > timezone", for example, rather than UTC like it is now).
>
> Here's my try on that. But whether it works everywhere ...
I already did that part.
> Btw, your %+03d%02d printf gave wrong results for i.e. -0130 (-01-30).
Dang. Oh, well. That's what I get for not testing.
I don't much like that "%+05s" trick either, since that one also depends
on the direction of rounding for negative division (it just gets it right
for the normal case, and I guess C90 finally specified it precisely).
Let's just do unsigned arithmetic and check the sign specially. I already
did that on input, just not on output.
Linus
^ permalink raw reply
* Re: Trying to use AUTHOR_DATE
From: H. Peter Anvin @ 2005-04-30 23:14 UTC (permalink / raw)
To: Luck, Tony; +Cc: Edgar Toernig, git
In-Reply-To: <B8E391BBE9FE384DAA4C5C003888BE6F035EDE5C@scsmsx401.amr.corp.intel.com>
Luck, Tony wrote:
>>Fixed version below.
>
>
> Yup ... that fixes it for my initial test cases. Thanks.
>
> -Tony
>
> P.S. The libcurl that I found (curl-7.12.1-3.src.rpm) has curl_getdate()
> implemented as >1000 lines of yacc. Which seems like overkill (unless
> I really need to set AUTHOR_DATE="a week ago last tuesday" :-)
That one is obsolete.
-hpa
^ permalink raw reply
* Re: [PATCH] Resurrect diff-tree-helper -R
From: Junio C Hamano @ 2005-05-01 2:22 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.58.0504301805300.2296@ppc970.osdl.org>
>>>>> "LT" == Linus Torvalds <torvalds@osdl.org> writes:
LT> Talking about the diffs, I'm beginning to hate those "mode" things.
Likewise.
LT> Not only do they screw up diffstat (big deal), but they are pointless,
LT> since 99.9% of the time the mode stays the same.
Pointless, yes. mode is not what screwing up diffstat but
comparing against /dev/null is, so it is not a reason to hate
mode, and my fingers learned to say diffstat -p1 already so it
is not a big deal anymore.
LT> Normal "patch" will just ignore the extra lines before the
LT> diff anyway, so it won't matter there.
LT> Comments?
I am 100% in agreement with you here. The only reason I added
it was to match what Pasky does so that his cg-patch can eat its
output. To me, pleasing cg-patch is far lower priority than
pleasing l-k developers, so your veto counts.
My JIT tools do not use that mode thing in the patch. I apply a
patch between two commits (or trees) to the work tree by doing
something like this:
GIT_EXTERNAL_DIFF=jit-diff-extract \
jit-diff "$@" | {
cd "${GIT_PROJECT_TOP}"
sh
}
Here jit-diff-extract is the gem that creates a small shell
script that patches the file and runs "chmod +x" or "chmod -x"
when necessary, and does git-update-cache for added or removed
files. Its output would look something like this:
patch -p1 <<\EOF
--- /dev/null
+++ fs/ext9/Makefile
@@ ....
EOF
chmod -x 'fs/ext9/Makefile'
git-update-cache --add --remove -- 'fs/ext9/Makefile'
Maybe I can make the default diff output just like the above?
As you say, normal patch would not look at those shell script
part at all anyway.
^ permalink raw reply
* Re: [PATCH] Resurrect diff-tree-helper -R
From: Linus Torvalds @ 2005-05-01 5:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vis231y7y.fsf@assigned-by-dhcp.cox.net>
On Sat, 30 Apr 2005, Junio C Hamano wrote:
> Its output would look something like this:
>
> patch -p1 <<\EOF
> --- /dev/null
> +++ fs/ext9/Makefile
> @@ ....
> EOF
> chmod -x 'fs/ext9/Makefile'
> git-update-cache --add --remove -- 'fs/ext9/Makefile'
>
> Maybe I can make the default diff output just like the above?
> As you say, normal patch would not look at those shell script
> part at all anyway.
I actually do end up looking at diffs, and I'd hate it. I'd much rather
have as little extra fluff as possible, and putting shell scipt fragments
in it definitely counts as distraction.
The fewer lines there are that don't usually tell a human anything, the
better. Dense is good.
Linus
^ permalink raw reply
* Re: [PATCH] Resurrect diff-tree-helper -R
From: Linus Torvalds @ 2005-05-01 5:33 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: Junio C Hamano, git
In-Reply-To: <20050501014726.GA15220@nevyn.them.org>
On Sat, 30 Apr 2005, Daniel Jacobowitz wrote:
>
> It sounds good - but could you efficiently collect them before any diff
> output? If you have something like this, it'll be easy to read:
>
> Mode change: 644->755 foo.sh
> Mode change: 644->755 bar.sh
>
> --- ChangeLog
> +++ ChangeLog
That may sound like a good idea, but it's horrid.
You'd only have to gather them back later anyway, since you can only apply
the mode change _after_ you've done the diff. Why? The diff may be the
thing that creates the file in the first place. Sp you should consider the
mode changes as part of the "stream", not as something separate from the
stream.
So I'd really much rather see it more as an "Index" line, which gets
prepended as part of the patch for that file (of course, either patch or
modeline can be missing).
Linus
^ permalink raw reply
* Re: [PATCH] Resurrect diff-tree-helper -R
From: Junio C Hamano @ 2005-05-01 6:22 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.58.0504302224510.2296@ppc970.osdl.org>
>>>>> "LT" == Linus Torvalds <torvalds@osdl.org> writes:
LT> I actually do end up looking at diffs, and I'd hate it. I'd much rather
LT> have as little extra fluff as possible, and putting shell scipt fragments
LT> in it definitely counts as distraction.
Well I was half joking when I suggested that and I am glad to
see that you have a good aesthetics ;-). How about:
- Stop attempting to be compatible with cg-patch, and drop
(mode:XXXXXX) bits from the diff.
- Do keep the /dev/null change for created and deleted case.
- No "Index:" line, no "Mode change:" line, anywhere in the
output. Anything that wants the mode bits and sha1 hash can
do things from GIT_EXTERNAL_DIFF mechanism. Maybe document
suggested usage mechanism better.
I'll whip something up along the above lines and submit it.
^ permalink raw reply
* [PATCH] Rework built-in diff to make its output more dense.
From: Junio C Hamano @ 2005-05-01 7:19 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.58.0504302224510.2296@ppc970.osdl.org>
Linus says,
The fewer lines there are that don't usually tell a human
anything, the better. Dense is good.
This patch makes the default diff output more dense. This
removes the previous misguided attempt to be cg-patch
compatible.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
diff.c | 26 +++++++++++++++-----------
1 files changed, 15 insertions(+), 11 deletions(-)
# - [PATCH] Resurrect diff-tree-helper -R
# + [PATCH] Rework built-in diff to make its output more dense.
--- k/diff.c
+++ l/diff.c
@@ -82,35 +82,32 @@ static void builtin_diff(const char *nam
struct diff_tempfile *temp)
{
int i, next_at;
- const char *diff_cmd = "diff -L'%s%s%s' -L'%s%s%s'";
+ const char *diff_cmd = "diff -L'%s%s' -L'%s%s'";
const char *diff_arg = "'%s' '%s'";
const char *input_name_sq[2];
const char *path0[2];
const char *path1[2];
- char mode[2][20];
const char *name_sq = sq_expand(name);
char *cmd;
- /* diff_cmd and diff_arg have 8 %s in total which makes
- * the sum of these strings 16 bytes larger than required.
+ /* diff_cmd and diff_arg have 6 %s in total which makes
+ * the sum of these strings 12 bytes larger than required.
* we use 2 spaces around diff-opts, and we need to count
- * terminating NUL, so we subtract 13 here.
+ * terminating NUL, so we subtract 9 here.
*/
int cmd_size = (strlen(diff_cmd) + strlen(diff_opts) +
- strlen(diff_arg) - 13);
+ strlen(diff_arg) - 9);
for (i = 0; i < 2; i++) {
input_name_sq[i] = sq_expand(temp[i].name);
if (!strcmp(temp[i].name, "/dev/null")) {
path0[i] = "/dev/null";
path1[i] = "";
- mode[i][0] = 0;
} else {
path0[i] = i ? "l/" : "k/";
path1[i] = name_sq;
- sprintf(mode[i], " (mode:%s)", temp[i].mode);
}
cmd_size += (strlen(path0[i]) + strlen(path1[i]) +
- strlen(mode[i]) + strlen(input_name_sq[i]));
+ strlen(input_name_sq[i]));
}
cmd = xmalloc(cmd_size);
@@ -118,13 +115,20 @@ static void builtin_diff(const char *nam
next_at = 0;
next_at += snprintf(cmd+next_at, cmd_size-next_at,
diff_cmd,
- path0[0], path1[0], mode[0],
- path0[1], path1[1], mode[1]);
+ path0[0], path1[0], path0[1], path1[1]);
next_at += snprintf(cmd+next_at, cmd_size-next_at,
" %s ", diff_opts);
next_at += snprintf(cmd+next_at, cmd_size-next_at,
diff_arg, input_name_sq[0], input_name_sq[1]);
+ if (!path1[0][0])
+ printf("Created: %s (mode:%s)\n", name, temp[1].mode);
+ else if (!path1[1][0])
+ printf("Deleted: %s\n", name);
+ else if (strcmp(temp[0].mode, temp[1].mode))
+ printf("Mode changed: %s (%s->%s)\n", name,
+ temp[0].mode, temp[1].mode);
+ fflush(NULL);
execlp("/bin/sh","sh", "-c", cmd, NULL);
}
^ permalink raw reply
* [PATCH] Add git-apply-patch-script.
From: Junio C Hamano @ 2005-05-01 7:21 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <7vr7grzcqu.fsf@assigned-by-dhcp.cox.net>
I said:
- Stop attempting to be compatible with cg-patch, and drop
(mode:XXXXXX) bits from the diff.
- Do keep the /dev/null change for created and deleted case.
- No "Index:" line, no "Mode change:" line, anywhere in the
output. Anything that wants the mode bits and sha1 hash can
do things from GIT_EXTERNAL_DIFF mechanism. Maybe document
suggested usage better.
This adds an example script git-apply-patch-script, that can be
used as the GIT_EXTERNAL_DIFF to apply changes between two trees
directly on the current work tree, like this:
GIT_EXTERNAL_DIFF=git-apply-patch-script git-diff-tree -p <tree> <tree>
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
Makefile | 4 +--
git-apply-patch-script | 60 +++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 62 insertions(+), 2 deletions(-)
# - [PATCH] Rework built-in diff to make its output more dense.
# + [PATCH] Add git-apply-patch-script.
--- k/Makefile
+++ l/Makefile
@@ -12,8 +12,8 @@ CFLAGS=-g -O2 -Wall
CC=gcc
AR=ar
-SCRIPTS=git-merge-one-file-script git-prune-script git-pull-script \
- git-tag-script
+SCRIPTS=git-apply-patch-script git-merge-one-file-script git-prune-script \
+ git-pull-script git-tag-script
PROG= git-update-cache git-diff-files git-init-db git-write-tree \
git-read-tree git-commit-tree git-cat-file git-fsck-cache \
Created: git-apply-patch-script (mode:100755)
--- /dev/null
+++ l/git-apply-patch-script
@@ -0,0 +1,60 @@
+#!/bin/sh
+# Copyright (C) 2005 Junio C Hamano
+#
+# Applying diff between two trees to the work tree can be
+# done with the following single command:
+#
+# GIT_EXTERNAL_DIFF=git-apply-patch-script git-diff-tree -p $tree1 $tree2
+#
+
+case "$#" in
+2) exit 1 ;; # do not feed unmerged diff to me!
+esac
+name="$1" tmp1="$2" hex1="$3" mode1="$4" tmp2="$5" hex2="$6" mode2="$7"
+case "$mode1" in *7??) mode1=+x ;; *6??) mode1=-x ;; esac
+case "$mode2" in *7??) mode2=+x ;; *6??) mode2=-x ;; esac
+
+if test -f "$name.orig" || test -f "$name.rej"
+then
+ echo >&2 "Unresolved patch conflicts in the previous run found."
+ exit 1
+fi
+# This will say "patching ..." so we do not say anything outselves.
+
+diff -u -L "a/$name" -L "b/$name" "$tmp1" "$tmp2" | patch -p1
+test -f "$name.rej" || {
+ case "$mode1,$mode2" in
+ .,?x)
+ # newly created
+ case "$mode2" in
+ +x)
+ echo >&2 "created $name with mode +x."
+ chmod "$mode2" "$name"
+ ;;
+ -)
+ echo >&2 "created $name."
+ ;;
+ esac
+ git-update-cache --add -- "$name"
+ ;;
+ ?x,.)
+ # deleted
+ echo >&2 "deleted $name."
+ rm -f "$name"
+ git-update-cache --remove -- "$name"
+ ;;
+ *)
+ # changed
+ case "$mode1,$mode2" in
+ "$mode2,$mode1") ;;
+ *)
+ echo >&2 "changing mode from $mode1 to $mode2."
+ chmod "$mode2" "$name"
+ ;;
+ esac
+ esac
+ # This bit is debatable---the SCM may not want to keep
+ # cache in sync with the work tree (JIT does want to).
+ git-update-cache -- "$name"
+}
+exit 0
^ permalink raw reply
* Todays update (with cogito 0.8)
From: Russell King @ 2005-05-01 8:27 UTC (permalink / raw)
To: git
This still doesn't seem to be working properly (details below):
MOTD:
MOTD: Welcome to the Linux Kernel Archive.
MOTD:
MOTD: Due to U.S. Exports Regulations, all cryptographic software on this
MOTD: site is subject to the following legal notice:
MOTD:
MOTD: This site includes publicly available encryption source code
MOTD: which, together with object code resulting from the compiling of
MOTD: publicly available source code, may be exported from the United
MOTD: States under License Exception "TSU" pursuant to 15 C.F.R. Section
MOTD: 740.13(e).
MOTD:
MOTD: This legal notice applies to cryptographic software only.
MOTD: Please see the Bureau of Industry and Security,
MOTD: http://www.bis.doc.gov/ for more information about current
MOTD: U.S. regulations.
MOTD:
receiving file list ... done
.git/refs/heads/origin
sent 142 bytes received 857 bytes 399.60 bytes/sec
total size is 41 speedup is 0.04
receiving file list ... done
00/83f2ab03ca2ec99ef2d31104710cf3898ce065
04/783ceb050c13d7a475a60bdb916b6eb56ffddf
06/6744ef2b6f86d258c40b00ad6390060d4b4288
07/a8f51940fb0ee87721628b0e84dd48b293d9a0
12/be8c2f4969d94e724aecaee7681a99ed4ba41d
12/f1b1dca9d98e3aaed6e9d8e5db123da16d6e9e
13/59cf3d21c56aa884c704656c16c0df87c3e6cb
17/47e1bfd5a700bc4242981c82ac35afcf834124
18/a6f4b9824853e4afb4f42410eb855f6b188fa1
1a/844ca139e0df85e57cee2a67916aa305b1ffcb
1a/b353e235955eee63e43a3a030d0b8b4b719a2b
1d/651f3332340c232ff66b7f5bab66cb8903859f
1d/db8a16aa0e60e7fdc48b1f532cf43e692f8fae
1f/dbe77e8211508763d1e0e9c5fec7065fc1c599
24/c3666b0f36f9e99c6d91a3266032285781cae6
28/96a380d4ea902d88f3831d23e847f63ffcf7c3
2c/acb3da620a4a93f3a77e1d2c8c06bb3c74bcb0
2f/e7cf50bb45a3ca94f095695bab5414fa56c1f3
31/eba8fc14bad5baac157b6f9a1123d02e6e89ce
32/1dbe91dc14e270450216cf4cc79562d89ca225
33/d8b5800cfaa3d75fd738c3c39411d27e6f9086
36/d362b6f5522e59e663031f4ce2eaf6169b38c3
37/0dfe77589d2abd9d8a963772fc79072feba5c0
3b/948e8c27513f7896263a87a99123ad5394b860
3c/2fa5c284c04ef223c468c2df53f6c7676dc20a
41/4f0ffac3493a9c34ded9c137ce8dfdda83ae7e
47/74e2260cf25c54f2188dd0407676e3af6f1f23
48/990899db0d9a9506e72fe2fa79570c3b5a306b
49/e7dc54cd4cbdb439ecc4e06214b0ca1a1a72b4
4f/a27a868f60eabcffec9971c03cdb7b12629ca6
53/8f078cc9db35255c8224d3bd39292357c7d998
68/575476718ed1c6d6ddafeec8310b109e7a7a7f
6f/2a6107859521b5f6b498aa50421cf0d0aebb7a
72/b03f201eb946f97c9f419090d683ece6ea5bc1
74/0fd350c127e12a902e7d781250429c30282bd7
74/1ff0c69f37f44154247020649b4104afff0cda
75/22285ae23e8375d91e3ef1e1a8a38acc6707d0
77/11c1cb3bfa0ef6ba82a20b3af86a490e844131
7a/76d85912492f50504ba428f4e1c9bdd3725c37
86/43112fac20933b0abcb5ccb5ea4fb3206962f2
8c/c881694e2911d0a2eff3ca7eb5dd5efc0503d3
90/ab8bb6a1d7dcced48f3d079dd455dd66cfdfc0
93/9c6303e46bbb5f763d51ad43768a4379ef46d0
95/483baab706baa9921eb14757c08da90970fdb5
95/c744856cbe042190fe5a346f4f99fd8d655931
97/47dd6fa98f2983f4dd09cd6dad1fa3d2a4c5f2
99/c47c498867ff5ee2fe0845622f4d1c4e1df1f4
9d/31aaad024e5e56d0ee124ea5909e1513e351c7
9e/a1f8f505f6f770bd593e689960ac4f893509b2
9e/b5099b4517719370a7655b825dc78ff0051d56
a3/183c173e2fbd44f4cc23da7a18bb283b00c64f
a3/89c37a97b58a3c31d19b2ab9665bb96196972e
a4/5aaa115a76664bb81438455b06a6ff890886f7
b3/d9ae4b98f6d28481d4d4b768d860a2cfb5805d
b5/9438bc23460062417fe1d5e3aa16679cde91bb
b5/fd078b5a6deada354ca78f0e6334c718ad6989
b6/d8654a4f75e8eeba365d4fa20073e0e39258b0
b7/d0f7f2fe5498c5845a974df475132634af4a74
bb/9bffcbef6166cf03385fbcde97c27bc1a5e689
bf/12fe2ba57544a73e0cc33858973f842e6490d3
c1/c9aa8a8e8fe3a3ffd5559ff0432bcb0a7249d8
c2/a7103979aff61109bdc6c6d572238338b79ce3
cf/04dd7d7b54dd2cb21ff305dae41a770278bf4e
d5/aa207e46ff7ee838683a7d95ecf46fe42a9a56
d6/66db0d6c68a8bc887e65e873d84ffa2c7e02d8
d8/c98e6ebdade1c73ea6926b6be3d86d9ade9cb6
dd/b7d643d247c1f7650245794433b7c1eec92331
dd/e77151cc2360c15c804ef82eb1fd628e53f10e
df/0d2d760073f9bd841a85ed0e1d758c8bacd3e3
df/4e2c7e4254667485a73c0b8960151fe47043f2
e3/06d25a5ad1ad6b22aefbdf8bb5e557cead1e4b
e8/e6993178344eb348f60f05b16d9dc30db3b9cf
eb/42422f72456e40a1152ae0ce4f4df44f4d1ef5
ed/562ab12733ab75437b3390427d41fce9da83c3
ed/867db550a9da16a690a9a122b28d33491ac6f8
f5/0443f1c9ea6c85a2733e67840d4860cdab4d3b
f8/50fb0fb5118be47d976291ee028697fbdeb688
f8/e191827f6ff913d083a89028b1b732ef56b231
sent 1674 bytes received 1186530 bytes 34440.70 bytes/sec
total size is 70393608 speedup is 59.24
receiving file list ... done
client: nothing to do: perhaps you need to specify some filenames or the --recursive option?
receiving file list ... done
client: nothing to do: perhaps you need to specify some filenames or the --recursive option?
unable to get tags list (non-fatal)
Tree change: a6ad57fb4b5e9d68553f4440377b99f75588fa88:e8e6993178344eb348f60f05b16d9dc30db3b9cf
*100644->100644 blob 8da3a306d0c0c070d87048d14a033df02f40a154->48990899db0d9a9506e72fe2fa79570c3b5a306b Makefile
*100644->100644 blob c397e71f938d0f79fbcbf29869fbb1d40cf09306->72b03f201eb946f97c9f419090d683ece6ea5bc1 arch/arm/common/rtctime.c
*100644->100644 blob 68e15c36e33610d6ed0ccec61d7d7a23ebcd4fa3->3b948e8c27513f7896263a87a99123ad5394b860 arch/arm/mach-integrator/integrator_cp.c
*100644->100644 blob 20729de2af285d62102691ef20942f7caab184af->1a844ca139e0df85e57cee2a67916aa305b1ffcb arch/arm/mach-integrator/time.c
*100644->100644 blob b1575b8dc1cd3e043f78794c56df9d57e6e96afa->a45aaa115a76664bb81438455b06a6ff890886f7 arch/arm/mach-pxa/generic.c
*100644->100644 blob 314c7146e9bf0a58c9df75c86065b4ad7598b419->04783ceb050c13d7a475a60bdb916b6eb56ffddf arch/i386/Makefile
*100644->100644 blob 774de8e2387193be0570a3fba681fd6dd1936816->f850fb0fb5118be47d976291ee028697fbdeb688 arch/ppc/boot/images/Makefile
*100644->100644 blob b0e167db6af9c68f49949d409abc747d3119842f->3c2fa5c284c04ef223c468c2df53f6c7676dc20a arch/ppc64/kernel/signal32.c
*100644->100644 blob 8e61be34a1d328c5a948a646504ad65629eaef62->ed867db550a9da16a690a9a122b28d33491ac6f8 drivers/char/s3c2410-rtc.c
*100644->100644 blob 3e386fd4c5c6e627699ccd04117b712030f0f3f4->321dbe91dc14e270450216cf4cc79562d89ca225 drivers/video/amba-clcd.c
*100644->100644 blob 4d2404305ab687c2a0eee84b3c5842ba9852965a->95483baab706baa9921eb14757c08da90970fdb5 fs/cifs/CHANGES
*100644->100644 blob 1e8490ed694878b3bbed1e96ab792791ddf1daed->8cc881694e2911d0a2eff3ca7eb5dd5efc0503d3 fs/cifs/TODO
*100644->100644 blob b004fef0a42bac42e8b3490fba19df1ea233762d->741ff0c69f37f44154247020649b4104afff0cda fs/cifs/cifssmb.c
*100644->100644 blob d31c1a71f781ccc7c189e3bff9dc1ee4ee282188->1ab353e235955eee63e43a3a030d0b8b4b719a2b include/asm-arm/arch-integrator/cm.h
*100644->100644 blob aa7e16b2e2255fbcc0f5aef2cf72c241daf2f81b->370dfe77589d2abd9d8a963772fc79072feba5c0 include/asm-arm/rtc.h
Applying changes...
Fast-forwarding a6ad57fb4b5e9d68553f4440377b99f75588fa88 -> e8e6993178344eb348f60f05b16d9dc30db3b9cf
on top of a6ad57fb4b5e9d68553f4440377b99f75588fa88...
The next patch would create the file arch/ia64/sn/include/pci/pcibus_provider_defs.h,
which already exists! Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file arch/ia64/sn/include/pci/pcibus_provider_defs.h.rej
The next patch would create the file arch/ia64/sn/include/pci/pcidev.h,
which already exists! Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file arch/ia64/sn/include/pci/pcidev.h.rej
The diff between these two IDs is:
$ cg-diff -r a6ad57fb4b5e9d68553f4440377b99f75588fa88:e8e6993178344eb348f60f05b16d9dc30db3b9cf| diffstat
Makefile | 6 ++++--
arch/arm/common/rtctime.c | 29 +++++++++++++++--------------
arch/arm/mach-integrator/integrator_cp.c | 17 ++++++++++++++++-
arch/arm/mach-integrator/time.c | 17 ++++++++++++-----
arch/arm/mach-pxa/generic.c | 25 +++++++++++++++++++++++++
arch/i386/Makefile | 7 ++++---
arch/ppc/boot/images/Makefile | 3 ++-
arch/ppc64/kernel/signal32.c | 4 ++--
drivers/char/s3c2410-rtc.c | 8 ++++++--
drivers/video/amba-clcd.c | 8 ++++----
fs/cifs/CHANGES | 4 +++-
fs/cifs/TODO | 12 ++++++++++--
fs/cifs/cifssmb.c | 6 ++++--
include/asm-arm/arch-integrator/cm.h | 6 +++---
include/asm-arm/rtc.h | 4 ++--
15 files changed, 112 insertions(+), 44 deletions(-)
which doesn't touch those files it's complaining about. So something's
up with the merging process - I don't see why we'd even be trying to
touch these two files.
--
Russell King
^ permalink raw reply
* update-cache ./test.c
From: Lennert Buytenhek @ 2005-05-01 8:41 UTC (permalink / raw)
To: git
Hi,
update-cache seems to ignore paths containing path components
starting with a dot:
pi% update-cache --add ./test.c
Ignoring path ./test.c
pi% update-cache --add test.c
pi%
This is slightly annoying as 'find -type f | xargs update-cache --add'
doesn't work because of this. ('find * -type f | ...` does.) Instead
of ignoring the file, can we just strip off the leading "./" ?
--L
^ permalink raw reply
* Re: update-cache ./test.c
From: Thomas Glanzmann @ 2005-05-01 8:47 UTC (permalink / raw)
To: git
In-Reply-To: <20050501084145.GA30692@xi.wantstofly.org>
Hello,
> update-cache seems to ignore paths containing path components
> starting with a dot:
> pi% update-cache --add ./test.c
> Ignoring path ./test.c
> pi% update-cache --add test.c
> pi%
> This is slightly annoying as 'find -type f | xargs update-cache --add'
> doesn't work because of this. ('find * -type f | ...` does.) Instead
> of ignoring the file, can we just strip off the leading "./" ?
just use a shell script to obtain that:
find -type f | sed "s#^./##" | xargs update-cache --add
Greetings,
Thomas
^ permalink raw reply
* Re: update-cache ./test.c
From: Lennert Buytenhek @ 2005-05-01 8:54 UTC (permalink / raw)
To: git
In-Reply-To: <20050501084710.GJ26663@cip.informatik.uni-erlangen.de>
On Sun, May 01, 2005 at 10:47:10AM +0200, Thomas Glanzmann wrote:
> Hello,
Hi,
> > update-cache seems to ignore paths containing path components
> > starting with a dot:
>
> > pi% update-cache --add ./test.c
> > Ignoring path ./test.c
> > pi% update-cache --add test.c
> > pi%
>
> > This is slightly annoying as 'find -type f | xargs update-cache --add'
> > doesn't work because of this. ('find * -type f | ...` does.) Instead
> > of ignoring the file, can we just strip off the leading "./" ?
>
> just use a shell script to obtain that:
>
> find -type f | sed "s#^./##" | xargs update-cache --add
This also works:
find * -type f | xargs update-cache --add
But that wasn't quite the point :) It makes sense that update-cache
doesn't like ambiguous path names, but it's easier for update-cache to
detect and strip "^./" than for me to remember to type sed "s#^./##"
every time.
--L
^ permalink raw reply
* Re: update-cache ./test.c
From: Lennert Buytenhek @ 2005-05-01 8:59 UTC (permalink / raw)
To: git
In-Reply-To: <20050501085427.GB30692@xi.wantstofly.org>
On Sun, May 01, 2005 at 10:54:27AM +0200, Lennert Buytenhek wrote:
> But that wasn't quite the point :) It makes sense that update-cache
> doesn't like ambiguous path names, but it's easier for update-cache to
> detect and strip "^./" than for me to remember to type sed "s#^./##"
> every time.
Something like this:
--- git/update-cache.c.orig 2005-05-01 10:56:17.859313581 +0200
+++ git/update-cache.c 2005-05-01 10:57:31.634897508 +0200
@@ -328,6 +328,7 @@
for (i = 1 ; i < argc; i++) {
char *path = argv[i];
+ char *_path;
if (allow_options && *path == '-') {
if (!strcmp(path, "--")) {
@@ -358,12 +359,15 @@
}
die("unknown option %s", path);
}
- if (!verify_path(path)) {
+ _path = path;
+ if (!strncmp(_path, "./", 2))
+ _path += 2;
+ if (!verify_path(_path)) {
fprintf(stderr, "Ignoring path %s\n", argv[i]);
continue;
}
- if (add_file_to_cache(path))
- die("Unable to add %s to database", path);
+ if (add_file_to_cache(_path))
+ die("Unable to add %s to database", _path);
}
if (write_cache(newfd, active_cache, active_nr) || rename(lockfile, indexfile))
die("Unable to write new cachefile");
^ permalink raw reply
* Re: update-cache ./test.c
From: Thomas Glanzmann @ 2005-05-01 9:04 UTC (permalink / raw)
To: GIT
In-Reply-To: <20050501085922.GC30692@xi.wantstofly.org>
Hello,
> --- git/update-cache.c.orig 2005-05-01 10:56:17.859313581 +0200
> +++ git/update-cache.c 2005-05-01 10:57:31.634897508 +0200
> @@ -328,6 +328,7 @@
> for (i = 1 ; i < argc; i++) {
> char *path = argv[i];
> + char *_path;
I think there is no need to introduce an extra variable. Just increase
path by two. I knew that it is easy to fix in the code, but I think the
'logic' should go into the frontend not in the backend. But this one is
really easy to fix. Maybe regenerate a patch and sign it off, maybe it
will be included.
Greetings,
Thomas
^ permalink raw reply
* [PATCH] Really fix git-merge-one-file-script this time.
From: Junio C Hamano @ 2005-05-01 9:29 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
The merge-cache program was updated to pass executable bits when
calling git-merge-one-file-script, but the called script
supplied as an example were not using them carefully.
This patch fixes the following problems in the script:
* When a new file is created in a directory, which is a file in
the work tree, it tried to create leading directory but did
not check for failure from the "mkdir -p" command.
* The script did not check the exit status from the
git-update-cache command at all.
* The parameter "$4" to the script is a file name that can
contain almost any characters, so it must be quoted with
double quotes and also needs to be preceded with -- to mark
it as a non-option when passed to certain commands.
* The chmod command was used with parameter "$6" or "$7" to set
the mode bits. This contradicts with the strategy taken by
checkout-cache, where we honor user's umask and force only
the executable bits. With this patch, it creates a new file
by redirecting into it (thus honoring user's default umask),
and then uses "chmod +x" if we want the resulting file
executable. Without this fix, the merge result becomes 0644
or 0755 for users whose umask is 002 for whom it should
become 0664 or 0775.
* When "$1 -> $2 -> $3" case was not handled, the script did
not say which path it was working on, which was not so useful
when used with the -a option of git-merge-cache.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
git-merge-one-file-script | 41 ++++++++++++++++++-----------------------
1 files changed, 18 insertions(+), 23 deletions(-)
# - [PATCH] Resurrect diff-tree-helper -R
# + [PATCH] Really fix git-merge-one-file-script this time.
--- k/git-merge-one-file-script
+++ l/git-merge-one-file-script
@@ -16,7 +16,7 @@
# if the directory is newly added in a branch, it might not exist
# in the current tree
dir=$(dirname "$4")
-mkdir -p "$dir"
+mkdir -p "$dir" || exit
case "${1:-.}${2:-.}${3:-.}" in
#
@@ -30,22 +30,18 @@ case "${1:-.}${2:-.}${3:-.}" in
# deleted in one and unchanged in the other
#
"$1.." | "$1.$1" | "$1$1.")
- rm -f -- "$4"
echo "Removing $4"
- git-update-cache --remove -- "$4"
- exit 0
- ;;
-
+ rm -f -- "$4" && exec git-update-cache --remove -- "$4" ;;
#
# added in one
#
".$2." | "..$3" )
- echo "Adding $4 with perm $6$7"
- mv $(git-unpack-file "$2$3") $4
- chmod "$6$7" $4
- git-update-cache --add -- $4
- exit 0
- ;;
+ case "$6$7" in *7??) mode=+x;; *) mode=-x;; esac
+ echo "Adding $4 with perm $mode"
+ rm -f -- "$4" &&
+ git-cat-file blob "$2$3" >"$4" &&
+ chmod "$mode" -- "$4" &&
+ exec git-update-cache --add -- "$4" ;;
#
# Added in both (check for same permissions)
#
@@ -54,11 +50,12 @@ case "${1:-.}${2:-.}${3:-.}" in
echo "ERROR: File $4 added in both branches, permissions conflict $6->$7"
exit 1
fi
- echo "Adding $4 with perm $6"
- mv $(git-unpack-file "$2") $4
- chmod "$6" $4
- git-update-cache --add -- $4
- exit 0;;
+ case "$6" in *7??) mode=+x;; *) mode=-x;; esac
+ echo "Adding $4 with perm $mode"
+ rm -f -- "$4" &&
+ git-cat-file blob "$2" >"$4" &&
+ chmod "$mode" -- "$4" &&
+ exec git-update-cache --add -- "$4" ;;
#
# Modified in both, but differently ;(
#
@@ -76,16 +73,14 @@ case "${1:-.}${2:-.}${3:-.}" in
fi
exit 1
fi
- chmod -- "$6" "$src2"
if [ $ret -ne 0 ]; then
echo "ERROR: Leaving conflict merge in $src2"
exit 1
fi
- cp -- "$src2" "$4" && chmod -- "$6" "$4" && git-update-cache --add -- "$4" && exit 0
- ;;
-
+ case "$6" in *7??) mode=+x;; *) mode=-x;; esac
+ rm -f -- "$4" && cat "$src2" >"$4" && chmod "$mode" -- "$4" &&
+ exec git-update-cache --add -- "$4" ;;
*)
- echo "Not handling case $1 -> $2 -> $3"
- ;;
+ echo "Not handling case $4: $1 -> $2 -> $3" ;;
esac
exit 1
^ permalink raw reply
* Re: update-cache ./test.c
From: David Greaves @ 2005-05-01 9:43 UTC (permalink / raw)
To: Lennert Buytenhek; +Cc: git, Linus Torvalds
In-Reply-To: <20050501084145.GA30692@xi.wantstofly.org>
Lennert Buytenhek wrote:
>Hi,
>
>update-cache seems to ignore paths containing path components
>starting with a dot:
>
> pi% update-cache --add ./test.c
> Ignoring path ./test.c
> pi% update-cache --add test.c
> pi%
>
>This is slightly annoying as 'find -type f | xargs update-cache --add'
>doesn't work because of this. ('find * -type f | ...` does.) Instead
>of ignoring the file, can we just strip off the leading "./"
>
>
This is documented behaviour:
<file>
Files to act on.
Note that files begining with '.' are discarded. This includes
"./file" and "dir/./file". If you don't want this, then use
cleaner names.
The same applies to directories ending '/' and paths with '//'
"Where?" you ask...
Well, Linus hasn't accepted the docs for some reason - you have to
search the archives...
Sorry about that...
David
PS Changing this behaviour was discussed and dismissed for the core tools.
If the problem appears in Cogito however, then it's worth patching...
^ permalink raw reply
* Re: update-cache ./test.c
From: Junio C Hamano @ 2005-05-01 10:31 UTC (permalink / raw)
To: Lennert Buytenhek; +Cc: git
In-Reply-To: <20050501085922.GC30692@xi.wantstofly.org>
>>>>> "LB" == Lennert Buytenhek <buytenh@wantstofly.org> writes:
LB> Something like this:
LB> --- git/update-cache.c.orig 2005-05-01 10:56:17.859313581 +0200
LB> +++ git/update-cache.c 2005-05-01 10:57:31.634897508 +0200
LB> @@ -328,6 +328,7 @@
LB> - if (!verify_path(path)) {
LB> + _path = path;
LB> + if (!strncmp(_path, "./", 2))
LB> + _path += 2;
LB> + if (!verify_path(_path)) {
Once you start doing ./ specially, you would be tempted to
handle foo/../bar/../../baz, which would lead to complexity
Linus did not want in the Core GIT layer. Please do not pursue
this path again.
I once advocated that the path we get from the user should be
treated relative to the working directory on the filesystem and
not relative to the cache entry root as the current Core GIT
layer does (see archive). With some clever scripting this
inconvenience can be hidden by the Porcelain layer without much
difficulty [*1*] and that was the reason behind the decision by
Linus to keep paths Plumbing layer gets relative to the cache.
I do not know Cogito already can do this, but you should be able
to do something like:
$ cd linux-2.6
$ ls -a
./ ../ .git/ fs/ mm/ Makefile ...
$ cd fs
$ xx-update-cache Makefile ../Makefile ext3/Makefile
$ xx-diff-files Makefile ../Makefile ext3/Makefile
where xx-* are what the Porcelain layer would provide the end
user with.
[Footnotes]
*1* (PLUG) An implementation of my little SCM on top of GIT is
found at <http://members.cox.net/junkio/> I've been using it
to manage the patches I feed Linus on the plumbing side.
^ permalink raw reply
* Should git-prune-script warn about dircache?
From: Junio C Hamano @ 2005-05-01 10:50 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
When the user has a change that is recorded in the dircache but
the change has not been committed, git-fsck-cache --unreachable
would report blobs and trees (if you have a subdirectory) that
are involved.
$ git-init-db
defaulting to local storage area
$ date >foo
$ git-update-cache --add foo
$ date | git-commit-tree $(git-write-tree) >.git/HEAD
Committing initial tree 9061076c3ec10fef339c84f4e0c9e06576d3b7db
$ date >foo
$ git-update-cache foo
$ git-fsck-cache --unreachable $(cat .git/HEAD)
unreachable blob d8c61e975a591ad5905c7defc567a77fca58f092
$ git-ls-files --stage
100644 d8c61e975a591ad5905c7defc567a77fca58f092 0 foo
At this point, if we run git-prune-script with the current head,
we would remove the blob, and after that, code that assumes the
objects pointed by SHA1s recorded in the dircache are locally
available start failing.
$ git-prune-script
$ touch foo
$ git-diff-files -p
.git/objects/d8/c61e975a591....: No such file or directory
fatal: unable to read blob object for foo (d8c61e975a591....)
I have a feeling somewhere in the chain from git-prune-script we
should have a mechanism to prevent us from losing such blob and
trees. I know it should not be in git-fsck-cache, but I have
not decided what my suggestions would be for us to do yet.
Maybe a big warning in red ugly bold blinking typeface somewhere
in the doc?
^ permalink raw reply
* [PATCH] Allow removing files in a subdirectory.
From: Junio C Hamano @ 2005-05-01 11:16 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
I found this during a conflict merge testing. The original did
not have either DF (a file) or DF/DF (a file DF/DF under a
directory DF). One side created DF, the other created DF/DF. I
first resolved DF as a new file by taking what the first side
did. After that, the entry DF/DF cannot be resolved by running
git-update-cache --remove although it does not exist on the
filesystem.
$ /bin/ls -F
AN DF MN NM NN SS Z/
$ git-ls-files --stage | grep DF
100644 71420ab81e254145d26d6fc0cddee64c1acd4787 0 DF
100644 68a6d8b91da11045cf4aa3a5ab9f2a781c701249 2 DF/DF
$ git-update-cache --remove DF/DF
fatal: Unable to add DF/DF to database
It turns out that the errno from open() in this case was not
ENOENT but ENOTDIR, which the code did not check. Here is a
fix.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
BTW, Linus do you want the updates to my merge-test-script-from-hell?
update-cache.c | 2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
# - [PATCH] Resurrect diff-tree-helper -R
# + [PATCH] Allow removing files in a subdirectory.
--- k/update-cache.c
+++ l/update-cache.c
@@ -111,7 +111,7 @@ static int add_file_to_cache(char *path)
fd = open(path, O_RDONLY);
if (fd < 0) {
- if (errno == ENOENT) {
+ if (errno == ENOENT || errno == ENOTDIR) {
if (allow_remove)
return remove_file_from_cache(path);
}
^ permalink raw reply
* Re: How to get bash to shut up about SIGPIPE?
From: Herbert Xu @ 2005-05-01 12:07 UTC (permalink / raw)
To: Ryan Anderson; +Cc: torvalds, rene.scharfe, git, pasky
In-Reply-To: <20050428202739.GE30308@mythryan2.michonline.com>
Ryan Anderson <ryan@michonline.com> wrote:
> On Thu, Apr 28, 2005 at 12:21:26PM -0700, Linus Torvalds wrote:
>
>> Defining "DONT_REPORT_SIGPIPE" in config-top.h when building bash gets rid
>> of it, but I really don't want to rebuild bash just because of this ;)
>
> Debian's bash seems to have that set, so it's a bit hard for me to test
This issue has been around for years. The discussion that led to
Debian setting this option may be helpful in understanding it:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=10494
A brief time line:
11 Jun 1997 The issue was reported to Debian.
20 Nov 1999 Chet Ramey remarks that bash's default will not change.
4 Sep 2004 Debian sets DONT_REPORT_SIGPIPE.
Chet Ramey claims that setting DONT_REPORT_SIGPIPE by default
would make bash incompatible with every other shell out there.
Interestingly, all the non-bash shells that I've tried disagree
with him.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Quick command reference
From: Paul Mackerras @ 2005-05-01 12:58 UTC (permalink / raw)
To: git
As an aid to my understanding of the core git commands, I created this
summary of the commands and their options and parameters. I hope it
will be useful to others. Corrections welcome of course.
Paul.
---
git-cat-file -t sha1-id
Prints type of object with given sha1-id to stdout.
git-cat-file type sha1-id
Copies contents of object with given sha1-id to stdout.
Complains if type of sha1-id isn't of the type specified.
git-check-files pathname...
Checks that each pathname given is up-to-date in the w.d.
(i.e. matches the dircache) or is not present.
git-checkout-cache [-a] [-f] [-q] [-n] [--prefix=path] [--] [files...]
Copies files from the git object repository to the
working directory or another directory. Does not rewrite
files that already exist and match the dircache.
-a: check out all files listed in dircache.
-f: overwrite existing files; without this, checkout-cache
will not overwrite an existing file even if it
differs from what is in the dircache.
-q: quiet; don't print an error message when a file is
unmerged or not in the dircache, or when a file exists
but differs from the dircache and -f was not given.
-n: not new files; don't checkout any file that doesn't
already exist in the dircache.
--prefix=path: prepend path to the pathname of each file
being checked out. If you want to use this to
check out files with their normal names but in
another directory, make sure the path ends in /.
The order of the flags matters; checkout-cache -a -f
is different from checkout-cache -f -a. Flags may be
interspersed between file names.
git-commit-tree tree-id [-p parent-commit-id]* < changelog
Generates a commit object referring to the given tree with
the parent commit-ids given. (If no parents are given, this
is an initial commit.) Prints the sha1 id of the generated
commit to stdout.
git-diff-cache [-r] [-p] [-z] [--cached] tree-id
Show differences between the tree identified by tree-id
and the dircache and/or the working directory.
-r: ignored (old recursive flag)
-p: generate patches (full diff listings)
-z: terminate lines with \0 instead of \n
--cached: diff against last cached state rather than
file in w.d. for new or changed files. New and changed
files are always identified by comparing dircache and
tree entries, but without this flag, the files that are
identified as new or changed are compared against the
working directory rather than the cached version.
Unmerged (non-stage 0) entries in dircache are shown as:
U <pathname>
or if -p is given, as
* Unmerged path pathname
Files in tree but not in dircache (or w.d., without --cached):
-mode<tab>blob<tab>sha1<tab>pathname
or with -p, as a patch deleting the file.
Files in dircache but not in tree are shown as:
+mode<tab>blob<tab>sha1<tab>pathname
or with -p, as a patch adding the file.
Files that differ are shown as:
*mode->mode<tab>blob<tab>sha1->sha1<tab>pathname
or with -p, as a patch showing the differences
git-diff-files
Compares working-directory with dircache and prints a listing
of changed files.
-p: generate patches (full diff listings)
-q: Silent; don't show files missing from w.d.
-r: ignored (old recursive flag)
-s: ignored (old silent flag)
-z: terminate lines with \0 instead of \n
If no pathnames given, compare all files in dircache.
Checks mode, uid, gid, size, mtime, ctime, dev/ino, size.
Output is as for git-diff-cache ("-" indicates file in
dircache but not in w.d.).
git-diff-tree [-p] [-r] [-z] tree1-id tree2-id
Compares two trees identified by their ids.
-p: generate patches (implies -r)
-r: recursive
-z: terminate lines with \0 instead of \n
Output is as for git-diff-cache (except there are no unmerged
entries, since they can only exist in the dircache).
git-diff-tree-helper [-R] [-z] pathname...
Reads the output of git-diff-tree and generates diffs (patches)
for the files listed on the command line.
-R: generate reverse diff
-z: expect input lines to be terminated with \0
git-export top-sha1 [base-sha1]
top-sha1 and base-sha1 are commit-ids
Outputs all the changesets to get to top-sha1, with patches.
If base-sha1 is given, only outputs changesets from base-sha1
to top-sha1.
git-fsck-cache [--tags] [--root] [--unreachable] head-sha1...
Checks the consistency of the object repository.
If given, the head-sha1 parameter(s) is/are the ids of
one or more heads of the commit graph.
git-http-pull [-c] [-t] [-a] commit-id url
-t: tree
-c: commits
-a: all
Fetches the commit object with id commit-id.
With -t or -a, fetches the tree and blobs for that commit-id.
With -c or -a, fetches the parents, and recursively fetches
each of their parents, etc.; with -a, fetches the tree and
blobs for each of the ancestors as well.
git-init-db
makes .git directory
if SHA1_FILE_DIRECTORY not set, makes .git/objects/xx dirs
git-ls-files [-c|--cached] [-d|--deleted] [-o|--others] [-i|--ignored]
[-s|--stage] [-u|--unmerged] [-x pattern|--exclude=pattern]
[-X excl-file|--exclude-from=excl-file] [-z]
Lists filenames from dircache.
-c|--cached: list files in dircache (default)
-d|--deleted: list files in dircache but not in w.d.
-o|--others: list files in w.d. but not in dircache
-i|--ignored: show files that would be excluded;
requires at least one -x|-X|--exclude|--exclude-from
-s|--stage: show full information including merge stage
for each file
-u|--unmerged: only show files with merge stage > 0 in dircache
-x pattern|--exclude=pattern: exclude files matching pattern
-X file|--exclude-from=file: read exclude patterns from
file, one per line
-z: terminate lines with \0 instead of \n
Without -s, just prints pathnames, one per line.
With -s, prints:
mode sha1 stage pathname
git-ls-tree [-z] [-r] sha1
prints contents of tree object in readable form
4 columns: mode type sha1 name
-z: terminate lines with \0 instead of \n
-r: show subdirectories recursively
git-merge-base commit1-id commit2-id
Finds the nearest common ancestor of commit1 and commit2,
and prints its sha1 id
git-merge-cache <merge-program> [-a] [--] <filename>*
-a: merge all files listed in dircache
For each file to be merged, do nothing if it is at stage
0 in the dircache. Otherwise run:
merge-program stage1-id stage2-id stage3-id \
pathname stage1-mode stage2-mode stage3-mode
The stageX-id and stageX-mode are "" if that stage isn't
present in the dircache for that file.
git-mktag < signature-file
Verifies the input is a syntactically valid tag,
creates an object containing the input, and prints
its sha1 id.
git-read-tree (-m | stage0-sha1) [stage1-sha1] [stage2-sha1] [stage3-sha1]
tree-object(s) -> dircache (uids, gids, inos, times, sizes == 0)
-m: merge, i.e. start in stage 1; requires all objects in
dircache to be stage 0 initially; requires 1 or 3 trees.
With 1 tree, merges stat info from existing dircache
for unchanged files (same name and sha1 as tree).
With 3 trees, does a trivial 3-way merge. Files merged
are made stage 0 and old stat info is used if possible.
Anything non-trivial is left as stage 1,2,3 entries.
Result goes into new index file.
Without -m, existing dircache contents are discarded.
Normally only one sha1 id would be given; more than one can be
given but no merging is done.
git-rev-list commit-id
prints the commit-ids of the ancestors of commit-id,
ordered by date.
git-rev-tree [--edges] [^]commit-id [[^]commit-id]*
--edges: show commits whose reachability differs from one or
more of its parents (reachability == which subset of the
commit-ids given on the command line it's reachable from).
^ means don't show commits reachable from this commit-id
(ignored with --edges)
each line of output is formatted as:
decimal-date commit-id:flags [parent-commit-id:flags]*
flags is in decimal and is a reachability bitmap, i.e.
0x1 is set if reachable from the first commit-id given,
0x2 if reachable from the second, etc.
git-rpull [-t] [-c] [-a] commit-id url
Flags are like http-pull.
Pulls commits, trees and blobs from another machine over
ssh; execs ssh to run rpush on the remote machine.
url can be "-" meaning just talk over stdin/stdout
instead of running ssh.
git-rpush [-t] [-c] [-a] commit-id url
Flags are like http-pull.
Pushes commits, tree and blobs from this machine to another
machine over ssh; execs ssh to run rpull on the remote machine.
url can be "-" meaning just talk over stdin/stdout
instead of running ssh.
git-tar-tree sha1-id [basedir]
Generates a tar-file on stdout for the tree identified by
sha1-id, which can be a commit id or a tree id.
If basedir is given, basedir/ is prepended to all pathnames.
git-unpack-file sha1-id
Generates a temporary file name of the form .merge_file_XXXXXX
and writes the contents of the blob object identified by sha1-id
to it; outputs the generated name to stdout.
git-update-cache [--add] [--remove] [--] pathname...
Update dircache entry for filename(s) from w.d.
--add: add pathnames that are in w.d. but not dircache to
the dircache (without --add, print a message)
--remove: remove pathnames which are in dircache but not
w.d. from the dircache (without --remove, print a message)
git-update-cache --refresh [--ignore-missing]
Sets uid, gid, times, size on each entry in dircache from w.d.
Complains if mode or data differs (assumes data matches
if size and date match).
Complains if any file not in w.d. unless --ignore-missing is given.
git-update-cache --cacheinfo mode sha1 path
Adds an entry to the dircache for path with given mode and sha1.
git-write-tree
Creates a tree object from the contents of the dircache
(creating tree objects for subdirectories, recursively).
Prints sha1 of top-level tree-object to stdout.
Complains if any files are unmerged (merge stage > 0).
N.B.
w.d. = working directory (.)
dircache is in .git/index
object files are in $SHA1_FILE_DIRECTORY or .git/objects
^ permalink raw reply
* Re: Quick command reference
From: David Greaves @ 2005-05-01 14:44 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git, Linus Torvalds, Petr Baudis
In-Reply-To: <17012.53862.704670.858276@cargo.ozlabs.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 542 bytes --]
Paul Mackerras wrote:
>As an aid to my understanding of the core git commands, I created this
>summary of the commands and their options and parameters. I hope it
>will be useful to others. Corrections welcome of course.
>
>Paul.
>
>
Thanks Paul
Shame to see duplicated effort...
I've submitted this document to Linus and the list a few times and
included all the feedback but for some reason it's not gone into any of
the trees which means that people like you have to redo it from scratch...
Getting frustrated now...
David
--
[-- Attachment #2: README.reference --]
[-- Type: text/plain, Size: 35927 bytes --]
This file contains reference information for the core git commands.
It is actually based on the source from Petr Baudis' tree and may
therefore contain a few 'extras' that may or may not make it upstream.
The README contains much useful definition and clarification info -
read that first. And of the commands, I suggest reading
'update-cache' and 'read-tree' first - I wish I had!
Thanks to original email authors and proof readers esp Junio C Hamano
<junkio@cox.net>
David Greaves <david@dgreaves.com>
24/4/05
Identifier terminology used:
<object>
Indicates any object sha1 identifier
<blob>
Indicates a blob object sha1 identifier
<tree>
Indicates a tree object sha1 identifier
<commit>
Indicates a commit object sha1 identifier
<tree/commit>
Indicates a tree or commit object sha1 identifier (usually
because the command can read the <tree> a <commit> contains).
[Eventually may be replaced with <tree> if <tree> means
<tree/commit> in all commands]
<type>
Indicates that an object type is required.
Currently one of: blob/tree/commit
<file>
Indicates a filename - often includes leading path
<path>
Indicates the path of a file (is this ever useful?)
################################################################
cat-file
cat-file (-t | <type>) <object>
Provide contents or type of objects in the repository. The type is
required if -t is not being used to find the object type.
<object>
The sha1 identifier of the object.
-t
show the object type identified by <object>
<type>
One of: blob/tree/commit
Output
If -t is specified, one of:
blob/tree/commit
Otherwise the raw (though uncompressed) contents of the <object> will
be returned.
################################################################
check-files
check-files <file>...
Check that a list of files are up-to-date between the filesystem and
the cache. Used to verify a patch target before doing a patch.
Files that do not exist on the filesystem are considered up-to-date
(whether or not they are in the cache).
Emits an error message on failure.
preparing to update existing file <file> not in cache
<file> exists but is not in the cache
preparing to update file <file> not uptodate in cache
<file> on disk is not up-to-date with the cache
exits with a status code indicating success if all files are
up-to-date.
see also: update-cache
################################################################
checkout-cache
checkout-cache [-q] [-a] [-f] [-n] [--prefix=<string>]
[--] <file>...
Will copy all files listed from the cache to the working directory
(not overwriting existing files). Note that the file contents are
restored - NOT the file permissions.
??? l 58 checkout-cache.c says restore executable bit.
-q
be quiet if files exist or are not in the cache
-f
forces overwrite of existing files
-a
checks out all files in the cache (will then continue to
process listed files).
-n
Don't checkout new files, only refresh files already checked
out.
--prefix=<string>
When creating files, prepend <string> (usually a directory
including a trailing /)
--
Do not interpret any more arguments as options.
Note that the order of the flags matters:
checkout-cache -a -f file.c
will first check out all files listed in the cache (but not overwrite
any old ones), and then force-checkout file.c a second time (ie that
one _will_ overwrite any old contents with the same filename).
Also, just doing "checkout-cache" does nothing. You probably meant
"checkout-cache -a". And if you want to force it, you want
"checkout-cache -f -a".
Intuitiveness is not the goal here. Repeatability is. The reason for
the "no arguments means no work" thing is that from scripts you are
supposed to be able to do things like
find . -name '*.h' -print0 | xargs -0 checkout-cache -f --
which will force all existing *.h files to be replaced with their
cached copies. If an empty command line implied "all", then this would
force-refresh everything in the cache, which was not the point.
To update and refresh only the files already checked out:
checkout-cache -n -f -a && update-cache --ignore-missing --refresh
Oh, and the "--" is just a good idea when you know the rest will be
filenames. Just so that you wouldn't have a filename of "-a" causing
problems (not possible in the above example, but get used to it in
scripting!).
The prefix ability basically makes it trivial to use checkout-cache as
a "export as tree" function. Just read the desired tree into the
index, and do a
checkout-cache --prefix=export-dir/ -a
and checkout-cache will "export" the cache into the specified
directory.
NOTE! The final "/" is important. The exported name is literally just
prefixed with the specified string, so you can also do something like
checkout-cache --prefix=.merged- Makefile
to check out the currently cached copy of "Makefile" into the file
".merged-Makefile".
################################################################
commit-tree
commit-tree <tree> [-p <parent commit>]* < changelog
Creates a new commit object based on the provided tree object and
emits the new commit object id on stdout. If no parent is given then
it is considered to be an initial tree.
A commit object usually has 1 parent (a commit after a change) or up
to 16 parents. More than one parent represents a merge of branches
that led to them.
While a tree represents a particular directory state of a working
directory, a commit represents that state in "time", and explains how
to get there.
Normally a commit would identify a new "HEAD" state, and while git
doesn't care where you save the note about that state, in practice we
tend to just write the result to the file ".git/HEAD", so that we can
always see what the last committed state was.
Options
<tree>
An existing tree object
-p <parent commit>
Each -p indicates a the id of a parent commit object.
Commit Information
A commit encapsulates:
all parent object ids
author name, email and date
committer name and email and the commit time.
If not provided, commit-tree uses your name, hostname and domain to
provide author and committer info. This can be overridden using the
following environment variables.
AUTHOR_NAME
AUTHOR_EMAIL
AUTHOR_DATE
COMMIT_AUTHOR_NAME
COMMIT_AUTHOR_EMAIL
(nb <,> and '\n's are stripped)
A commit comment is read from stdin (max 999 chars). If a changelog
entry is not provided via '<' redirection, commit-tree will just wait
for one to be entered and terminated with ^D
see also: write-tree
################################################################
diff-cache
diff-cache [-p] [-r] [-z] [--cached] <tree/commit>
Compares the content and mode of the blobs found via a tree object
with the content of the current cache and, optionally ignoring the
stat state of the file on disk.
<tree/commit>
The id of a tree or commit object to diff against.
-p
generate patch (see section on generating patches)
-r
recurse
-z
\0 line termination on output
--cached
do not consider the on-disk file at all
Output format:
See "Output format from diff-cache, diff-tree and show-diff" section.
Operating Modes
You can choose whether you want to trust the index file entirely
(using the "--cached" flag) or ask the diff logic to show any files
that don't match the stat state as being "tentatively changed". Both
of these operations are very useful indeed.
Cached Mode
If --cached is specified, it allows you to ask:
show me the differences between HEAD and the current index
contents (the ones I'd write with a "write-tree")
For example, let's say that you have worked on your index file, and are
ready to commit. You want to see eactly _what_ you are going to commit is
without having to write a new tree object and compare it that way, and to
do that, you just do
diff-cache --cached $(cat .git/HEAD)
Example: let's say I had renamed "commit.c" to "git-commit.c", and I had
done an "upate-cache" to make that effective in the index file.
"show-diff" wouldn't show anything at all, since the index file matches
my working directory. But doing a diff-cache does:
torvalds@ppc970:~/git> diff-cache --cached $(cat .git/HEAD)
-100644 blob 4161aecc6700a2eb579e842af0b7f22b98443f74 commit.c
+100644 blob 4161aecc6700a2eb579e842af0b7f22b98443f74 git-commit.c
And as you can see, the output matches "diff-tree -r" output (we
always do equivalent of "-r", since the index is flat).
You can trivially see that the above is a rename.
In fact, "diff-cache --cached" _should_ always be entirely equivalent to
actually doing a "write-tree" and comparing that. Except this one is much
nicer for the case where you just want to check where you are.
So doing a "diff-cache --cached" is basically very useful when you are
asking yourself "what have I already marked for being committed, and
what's the difference to a previous tree".
Non-cached Mode
The "non-cached" mode takes a different approach, and is potentially
the even more useful of the two in that what it does can't be emulated
with a "write-tree + diff-tree". Thus that's the default mode. The
non-cached version asks the question
"show me the differences between HEAD and the currently checked out
tree - index contents _and_ files that aren't up-to-date"
which is obviously a very useful question too, since that tells you what
you _could_ commit. Again, the output matches the "diff-tree -r" output to
a tee, but with a twist.
The twist is that if some file doesn't match the cache, we don't have a
backing store thing for it, and we use the magic "all-zero" sha1 to show
that. So let's say that you have edited "kernel/sched.c", but have not
actually done an update-cache on it yet - there is no "object" associated
with the new state, and you get:
torvalds@ppc970:~/v2.6/linux> diff-cache $(cat .git/HEAD )
*100644->100664 blob 7476bbcfe5ef5a1dd87d745f298b831143e4d77e->0000000000000000000000000000000000000000 kernel/sched.c
ie it shows that the tree has changed, and that "kernel/sched.c" has is
not up-to-date and may contain new stuff. The all-zero sha1 means that to
get the real diff, you need to look at the object in the working directory
directly rather than do an object-to-object diff.
NOTE! As with other commands of this type, "diff-cache" does not actually
look at the contents of the file at all. So maybe "kernel/sched.c" hasn't
actually changed, and it's just that you touched it. In either case, it's
a note that you need to upate-cache it to make the cache be in sync.
NOTE 2! You can have a mixture of files show up as "has been updated" and
"is still dirty in the working directory" together. You can always tell
which file is in which state, since the "has been updated" ones show a
valid sha1, and the "not in sync with the index" ones will always have the
special all-zero sha1.
################################################################
diff-tree
diff-tree [-p] [-r] [-z] <tree/commit> <tree/commit> [<pattern>]*
Compares the content and mode of the blobs found via two tree objects.
Note that diff-tree can use the tree encapsulated in a commit object.
<tree sha1>
The id of a tree or commit object.
<pattern>
If provided, the results are limited to a subset of files
matching one of these prefix strings.
ie file matches /^<pattern1>|<pattern2>|.../
Note that pattern does not provide any wildcard or regexp features.
-p
generate patch (see section on generating patches)
-r
recurse
-z
\0 line termination on output
Limiting Output
If you're only interested in differences in a subset of files, for
example some architecture-specific files, you might do:
diff-tree -r <tree/commit> <tree/commit> arch/ia64 include/asm-ia64
and it will only show you what changed in those two directories.
Or if you are searching for what changed in just kernel/sched.c, just do
diff-tree -r <tree/commit> <tree/commit> kernel/sched.c
and it will ignore all differences to other files.
The pattern is always the prefix, and is matched exactly (ie there are no
wildcards - although matching a directory, which it does support, can
obviously be seen as a "wildcard" for all the files under that directory).
Output format:
See "Output format from diff-cache, diff-tree and show-diff" section.
An example of normal usage is:
torvalds@ppc970:~/git> diff-tree 5319e4d609cdd282069cc4dce33c1db559539b03 b4e628ea30d5ab3606119d2ea5caeab141d38df7
*100664->100664 blob ac348b7d5278e9d04e3a1cd417389379c32b014f->a01513ed4d4d565911a60981bfb4173311ba3688 fsck-cache.c
which tells you that the last commit changed just one file (it's from
this one:
commit 3c6f7ca19ad4043e9e72fa94106f352897e651a8
tree 5319e4d609cdd282069cc4dce33c1db559539b03
parent b4e628ea30d5ab3606119d2ea5caeab141d38df7
author Linus Torvalds <torvalds@ppc970.osdl.org> Sat Apr 9 12:02:30 2005
committer Linus Torvalds <torvalds@ppc970.osdl.org> Sat Apr 9 12:02:30 2005
Make "fsck-cache" print out all the root commits it finds.
Once I do the reference tracking, I'll also make it print out all the
HEAD commits it finds, which is even more interesting.
in case you care).
################################################################
diff-tree-helper
diff-tree-helper [-z]
Reads output from diff-cache, diff-tree and show-diff and
generates patch format output.
-z
\0 line termination on input
See also the section on generating patches.
################################################################
fsck-cache
fsck-cache [[--unreachable] <commit>*]
Verifies the connectivity and validity of the objects in the database.
<commit>
A commit object to treat as the head of an unreachability
trace
--unreachable
print out objects that exist but that aren't readable from any
of the specified root nodes
It tests SHA1 and general object sanity, but it does full tracking of
the resulting reachability and everything else. It prints out any
corruption it finds (missing or bad objects), and if you use the
"--unreachable" flag it will also print out objects that exist but
that aren't readable from any of the specified root nodes.
So for example
fsck-cache --unreachable $(cat .git/HEAD)
or, for Cogito users:
fsck-cache --unreachable $(cat .git/heads/*)
will do quite a _lot_ of verification on the tree. There are a few
extra validity tests to be added (make sure that tree objects are
sorted properly etc), but on the whole if "fsck-cache" is happy, you
do have a valid tree.
Any corrupt objects you will have to find in backups or other archives
(ie you can just remove them and do an "rsync" with some other site in
the hopes that somebody else has the object you have corrupted).
Of course, "valid tree" doesn't mean that it wasn't generated by some
evil person, and the end result might be crap. Git is a revision
tracking system, not a quality assurance system ;)
Extracted Diagnostics
expect dangling commits - potential heads - due to lack of head information
You haven't specified any nodes as heads so it won't be
possible to differentiate between un-parented commits and
root nodes.
missing sha1 directory '<dir>'
The directory holding the sha1 objects is missing.
unreachable <type> <object>
The <type> object <object>, isn't actually referred to directly
or indirectly in any of the trees or commits seen. This can
mean that there's another root na SHA1_ode that you're not specifying
or that the tree is corrupt. If you haven't missed a root node
then you might as well delete unreachable nodes since they
can't be used.
missing <type> <object>
The <type> object <object>, is referred to but isn't present in
the database.
dangling <type> <object>
The <type> object <object>, is present in the database but never
_directly_ used. A dangling commit could be a root node.
warning: fsck-cache: tree <tree> has full pathnames in it
And it shouldn't...
sha1 mismatch <object>
The database has an object who's sha1 doesn't match the
database value.
This indicates a ??serious?? data integrity problem.
(note: this error occured during early git development when
the database format changed.)
Environment Variables
SHA1_FILE_DIRECTORY
used to specify the object database root (usually .git/objects)
################################################################
git-export
git-export top [base]
probably deprecated:
On Wed, 20 Apr 2005, Petr Baudis wrote:
>> I will probably not buy git-export, though. (That is, it is merged, but
>> I won't make git frontend for it.) My "git export" already does
>> something different, but more importantly, "git patch" of mine already
>> does effectively the same thing as you do, just for a single patch; so I
>> will probably just extend it to do it for an (a,b] range of patches.
That's fine. It was a quick hack, just to show that if somebody wants to,
the data is trivially exportable.
Linus
Although in Linus' distribution, git-export is not part of 'core' git.
################################################################
init-db
init-db
This simply creates an empty git object database - basically a .git
directory.
If the object storage directory is specified via the
SHA1_FILE_DIRECTORY environment variable then the sha1 directories are
created underneath - otherwise the default .git/objects directory is
used.
init-db won't hurt an existing repository.
################################################################
ls-tree
ls-tree [-r] [-z] <tree/commit>
convert the tree object to a human readable (and script
processable) form.
<tree/commit>
Id of a tree or commit object.
-r
recurse into sub-trees
-z
\0 line termination on output
Output Format
<mode>\t <type>\t <object>\t <path><file>
################################################################
merge-base
merge-base <commit> <commit>
merge-base finds as good a common ancestor as possible. Given a
selection of equally good common ancestors it should not be relied on
to decide in any particular way.
The merge-base algorithm is still in flux - use the source...
################################################################
merge-cache
merge-cache <merge-program> (-a | -- | <file>*)
This looks up the <file>(s) in the cache and, if there are any merge
entries, unpacks all of them (which may be just one file, of course)
into up to three separate temporary files, and then executes the
supplied <merge-program> with those three files as arguments 1,2,3
(empty argument if no file), and <file> as argument 4.
--
Interpret all future arguments as filenames
-a
Run merge against all files in the cache that need merging.
If merge-cache is called with multiple <file>s (or -a) then it
processes them in turn only stopping if merge returns a non-zero exit
code.
Typically this is run with the a script calling the merge command from
the RCS package.
A sample script called git-merge-one-file-script is included in the
ditribution.
ALERT ALERT ALERT! The git "merge object order" is different from the
RCS "merge" program merge object order. In the above ordering, the
original is first. But the argument order to the 3-way merge program
"merge" is to have the original in the middle. Don't ask me why.
Examples:
torvalds@ppc970:~/merge-test> merge-cache cat MM
This is MM from the original tree. # original
This is modified MM in the branch A. # merge1
This is modified MM in the branch B. # merge2
This is modified MM in the branch B. # current contents
or
torvalds@ppc970:~/merge-test> merge-cache cat AA MM
cat: : No such file or directory
This is added AA in the branch A.
This is added AA in the branch B.
This is added AA in the branch B.
fatal: merge program failed
where the latter example shows how "merge-cache" will stop trying to
merge once anything has returned an error (ie "cat" returned an error
for the AA file, because it didn't exist in the original, and thus
"merge-cache" didn't even try to merge the MM thing).
################################################################
read-tree
read-tree (<tree/commit> | -m <tree/commit1> [<tree/commit2> <tree/commit3>])"
Reads the tree information given by <tree> into the directory cache,
but does not actually _update_ any of the files it "caches". (see:
checkout-cache)
Optionally, it can merge a tree into the cache or perform a 3-way
merge.
Trivial merges are done by read-tree itself. Only conflicting paths
will be in unmerged state when read-tree returns.
-m
Perform a merge, not just a read
<tree#>
The id of the tree object(s) to be read/merged.
Merging
If -m is specified, read-tree performs 2 kinds of merge, a single tree
merge if only 1 tree is given or a 3-way merge if 3 trees are
provided.
Single Tree Merge
If only 1 tree is specified, read-tree operates as if the user did not
specify "-m", except that if the original cache has an entry for a
given pathname; and the contents of the path matches with the tree
being read, the stat info from the cache is used. (In other words, the
cache's stat()s take precedence over the merged tree's)
That means that if you do a "read-tree -m <newtree>" followed by a
"checkout-cache -f -a", the checkout-cache only checks out the stuff
that really changed.
This is used to avoid unnecessary false hits when show-diff is
run after read-tree.
3-Way Merge
Each "index" entry has two bits worth of "stage" state. stage 0 is the
normal one, and is the only one you'd see in any kind of normal use.
However, when you do "read-tree" with multiple trees, the "stage"
starts out at 0, but increments for each tree you read. And in
particular, the "-m" flag means "start at stage 1" instead.
This means that you can do
read-tree -m <tree1> <tree2> <tree3>
and you will end up with an index with all of the <tree1> entries in
"stage1", all of the <tree2> entries in "stage2" and all of the
<tree3> entries in "stage3".
Furthermore, "read-tree" has special-case logic that says: if you see
a file that matches in all respects in the following states, it
"collapses" back to "stage0":
- stage 2 and 3 are the same; take one or the other (it makes no
difference - the same work has been done on stage 2 and 3)
- stage 1 and stage 2 are the same and stage 3 is different; take
stage 3 (some work has been done on stage 3)
- stage 1 and stage 3 are the same and stage 2 is different take
stage 2 (some work has been done on stage 2)
Write-tree refuses to write a nonsensical tree, so write-tree will
complain about unmerged entries if it sees a single entry that is not
stage 0".
Ok, this all sounds like a collection of totally nonsensical rules,
but it's actually exactly what you want in order to do a fast
merge. The different stages represent the "result tree" (stage 0, aka
"merged"), the original tree (stage 1, aka "orig"), and the two trees
you are trying to merge (stage 2 and 3 respectively).
In fact, the way "read-tree" works, it's entirely agnostic about how
you assign the stages, and you could really assign them any which way,
and the above is just a suggested way to do it (except since
"write-tree" refuses to write anything but stage0 entries, it makes
sense to always consider stage 0 to be the "full merge" state).
So what happens? Try it out. Select the original tree, and two trees
to merge, and look how it works:
- if a file exists in identical format in all three trees, it will
automatically collapse to "merged" state by the new read-tree.
- a file that has _any_ difference what-so-ever in the three trees
will stay as separate entries in the index. It's up to "script
policy" to determine how to remove the non-0 stages, and insert a
merged version. But since the index is always sorted, they're easy
to find: they'll be clustered together.
- the index file saves and restores with all this information, so you
can merge things incrementally, but as long as it has entries in
stages 1/2/3 (ie "unmerged entries") you can't write the result.
So now the merge algorithm ends up being really simple:
- you walk the index in order, and ignore all entries of stage 0,
since they've already been done.
- if you find a "stage1", but no matching "stage2" or "stage3", you
know it's been removed from both trees (it only existed in the
original tree), and you remove that entry. - if you find a
matching "stage2" and "stage3" tree, you remove one of them, and
turn the other into a "stage0" entry. Remove any matching "stage1"
entry if it exists too. .. all the normal trivial rules ..
Incidentally - it also means that you don't even have to have a separate
subdirectory for this. All the information literally is in the index file,
which is a temporary thing anyway. There is no need to worry about what is in
the working directory, since it is never shown and never used.
see also:
write-tree
show-files
################################################################
rev-list <commit>
Lists commit objects in reverse chronological order starting at the
given commit, taking ancestry relationship into account. This is
useful to produce human-readable log output.
################################################################
rev-tree
rev-tree [--edges] [--cache <cache-file>] [^]<commit> [[^]<commit>]
Provides the revision tree for one or more commits.
--edges
Show edges (ie places where the marking changes between parent
and child)
--cache <cache-file>
Use the specified file as a cache. [Not implemented yet]
[^]<commit>
The commit id to trace (a leading caret means to ignore this
commit-id and below)
Output:
<date> <commit>:<flags> [<parent-commit>:<flags> ]*
<date>
Date in 'seconds since epoch'
<commit>
id of commit object
<parent-commit>
id of each parent commit object (>1 indicates a merge)
<flags>
The flags are read as a bitmask representing each commit
provided on the commandline. eg: given the command:
$ rev-tree <com1> <com2> <com3>
The output:
<date> <commit>:5
means that <commit> is reachable from <com1>(1) and <com3>(4)
A revtree can get quite large. rev-tree will eventually allow you to
cache previous state so that you don't have to follow the whole thing
down.
So the change difference between two commits is literally
rev-tree [commit-id1] > commit1-revtree
rev-tree [commit-id2] > commit2-revtree
join -t : commit1-revtree commit2-revtree > common-revisions
(this is also how to find the most common parent - you'd look at just
the head revisions - the ones that aren't referred to by other
revisions - in "common-revision", and figure out the best one. I
think.)
################################################################
show-diff
show-diff [-p] [-q] [-s] [-z] [paths...]
Compares the files in the working tree and the cache. When paths
are specified, compares only those named paths. Otherwise all
entries in the cache are compared. The output format is the
same as diff-cache and diff-tree.
-p
generate patch (see section on generating patches)
-q
Remain silent even on nonexisting files
-s
Does not do anything other than what -q does.
Output format:
See "Output format from diff-cache, diff-tree and show-diff" section.
################################################################
show-files
show-files [-z] [-t]
(--[cached|deleted|others|ignored|stage|unmerged])*
(-[c|d|o|i|s|u])*
[-x <pattern>|--exclude=<pattern>]
[-X <file>|--exclude-from=<file>]
This merges the file listing in the directory cache index with the
actual working directory list, and shows different combinations of the
two.
One or more of the options below may be used to determine the files
shown:
-c|--cached
Show cached files in the output (default)
-d|--deleted
Show deleted files in the output
-o|--others
Show other files in the output
-i|--ignored
Show ignored files in the output
Note the this also reverses any exclude list present.
-s|--stage
Show stage files in the output
-u|--unmerged
Show unmerged files in the output (forces --stage)
#-t [not in Linus' tree (yet?)]
# Identify the file status with the following tags (followed by
# a space) at the start of each line:
# H cached
# M unmerged
# R removed/deleted
# ? other
-z
\0 line termination on output
-x|--exclude=<pattern>
Skips files matching pattern.
Note that pattern is a shell wildcard pattern.
-X|--exclude-from=<file>
exclude patterns are read from <file>; 1 per line.
Allows the use of the famous dontdiff file as follows to find
out about uncommitted files just as dontdiff is used with
the diff command:
show-files --others --exclude-from=dontdiff
Output
show files just outputs the filename unless --stage is specified in
which case it outputs:
[<tag> ]<mode> <object> <stage> <file>
show-files --unmerged" and "show-files --stage " can be used to examine
detailed information on unmerged paths.
For an unmerged path, instead of recording a single mode/SHA1 pair,
the dircache records up to three such pairs; one from tree O in stage
1, A in stage 2, and B in stage 3. This information can be used by
the user (or Cogito) to see what should eventually be recorded at the
path. (see read-cache for more information on state)
see also:
read-cache
################################################################
unpack-file
unpack-file <blob>
Creates a file holding the contents of the blob specified by sha1. It
returns the name of the temporary file in the following format:
.merge_file_XXXXX
<blob>
Must be a blob id
################################################################
update-cache
update-cache [--add] [--remove] [--refresh [--ignore-missing]]
[--cacheinfo <mode> <object> <path>]*
[--] [<file>]*
Modifies the index or directory cache. Each file mentioned is updated
into the cache and any 'unmerged' or 'needs updating' state is
cleared.
The way update-cache handles files it is told about can be modified
using the various options:
--add
If a specified file isn't in the cache already then it's
added.
Default behaviour is to ignore new files.
--remove
If a specified file is in the cache but is missing then it's
removed.
Default behaviour is to ignore removed file.
--refresh
Looks at the current cache and checks to see if merges or
updates are needed by checking stat() information.
--ignore-missing
Ignores missing files during a --refresh
--cacheinfo <mode> <object> <path>
Directly insert the specified info into the cache.
--
Do not interpret any more arguments as options.
<file>
Files to act on.
Note that files begining with '.' are discarded. This includes
"./file" and "dir/./file". If you don't want this, then use
cleaner names.
The same applies to directories ending '/' and paths with '//'
Using --refresh
--refresh does not calculate a new sha1 file or bring the cache
up-to-date for mode/content changes. But what it _does_ do is to
"re-match" the stat information of a file with the cache, so that you
can refresh the cache for a file that hasn't been changed but where
the stat entry is out of date.
For example, you'd want to do this after doing a "read-tree", to link
up the stat cache details with the proper files.
Using --cacheinfo
--cacheinfo is used to register a file that is not in the current
working directory. This is useful for minimum-checkout merging.
To pretend you have a file with mode and sha1 at path, say:
$ update-cache --cacheinfo mode sha1 path
To update and refresh only the files already checked out:
checkout-cache -n -f -a && update-cache --ignore-missing --refresh
################################################################
write-tree
write-tree
Creates a tree object using the current cache.
The cache must be merged.
Conceptually, write-tree sync()s the current directory cache contents
into a set of tree files.
In order to have that match what is actually in your directory right
now, you need to have done a "update-cache" phase before you did the
"write-tree".
################################################################
Output format from diff-cache, diff-tree and show-diff.
These commands all compare two sets of things; what are
compared are different:
diff-cache <tree/commit>
compares the <tree/commit> and the files on the filesystem.
diff-cache --cached <tree/commit>
compares the <tree/commit> and the cache.
diff-tree [-r] <tree/commit-1> <tree/commit-2> [paths...]
compares the trees named by the two arguments.
show-diff [paths...]
compares the cache and the files on the filesystem.
The following desription uses "old" and "new" to mean those
compared entities.
For files in old but not in new (i.e. removed):
-<mode> \t <type> \t <object> \t <path>
For files not in old but in new (i.e. added):
+<mode> \t <type> \t <object> \t <path>
For files that differ:
*<old-mode>-><new-mode> \t <type> \t <old-sha1>-><new-sha1> \t <path>
<new-sha1> is shown as all 0's if new is a file on the
filesystem and it is out of sync with the cache. Example:
*100644->100660 blob 5be4a414b32cf4204f889469942986d3d783da84->0000000000000000000000000000000000000000 file.c
################################################################
Generating patches
When diff-cache, diff-tree, or show-diff are run with a -p
option, they do not produce the output described in "Output
format from diff-cache, diff-tree and show-diff" section. It
instead produces a patch file.
The patch generation can be customized at two levels. This
customization also applies to diff-tree-helper.
1. When the environment variable GIT_EXTERNAL_DIFF is not set,
these commands internally invoke diff like this:
diff -L k/<path> -L l/<path> -pu <old> <new>
For added files, /dev/null is used for <old>. For removed
files, /dev/null is used for <new>
The first part of the above command-line can be customized via
the environment variable GIT_DIFF_CMD. For example, if you
do not want to show the extra level of leading path, you can
say this:
GIT_DIFF_CMD="diff -L'%s' -L'%s'" show-diff -p
Caution: Do not use more than two '%s' in GIT_DIFF_CMD.
The diff formatting options can be customized via the
environment variable GIT_DIFF_OPTS. For example, if you
prefer context diff:
GIT_DIFF_OPTS=-c diff-cache -p $(cat .git/HEAD)
2. When the environment variable GIT_EXTERNAL_DIFF is set, the
program named by it is called, instead of the diff invocation
described above.
For a path that is added, removed, or modified,
GIT_EXTERNAL_DIFF is called with 7 parameters:
path old-file old-hex old-mode new-file new-hex new-mode
where
<old|new>-file are files GIT_EXTERNAL_DIFF can use to read the
contents of <old|ne>,
<old|new>-hex are the 40-hexdigit SHA1 hashes,
<old|new>-mode are the octal representation of the file modes.
The file parameters can point at the user's working file
(e.g. new-file in show-diff), /dev/null (e.g. old-file when a
new file is added), or a temporary file (e.g. old-file in the
cache). GIT_EXTERNAL_DIFF should not worry about
unlinking the temporary file --- it is removed when
GIT_EXTERNAL_DIFF exits.
For a path that is unmerged, GIT_EXTERNAL_DIFF is called with
1 parameter, path.
################################################################
Terminology: - see README for description
Each line contains terms used interchangeably
object database, .git directory
directory cache, index
id, sha1, sha1-id, sha1 hash
type, tag
blob, blob object
tree, tree object
commit, commit object
parent
root object
changeset
git Environment Variables
AUTHOR_NAME
AUTHOR_EMAIL
AUTHOR_DATE
COMMIT_AUTHOR_NAME
COMMIT_AUTHOR_EMAIL
GIT_DIFF_CMD
GIT_DIFF_OPTS
GIT_EXTERNAL_DIFF
GIT_INDEX_FILE
SHA1_FILE_DIRECTORY
^ 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