* Re: [PATCH] make file merging respect permissions
From: James Bottomley @ 2005-04-24 4:42 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Petr Baudis, Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0504231759010.2344@ppc970.osdl.org>
On Sat, 2005-04-23 at 18:01 -0700, Linus Torvalds wrote:
>
> On Sat, 23 Apr 2005, James Bottomley wrote:
> >
> > This is the actual diff
>
> This is _still_ corrupted.
>
> Are you editing your diffs by hand without understanding how the diffs
> work?
Sort of: I'm taking a diff between my tree and yours but stripping out
the extraneous pieces (which are whole file diffs, nothing in the actual
diffs I send you).
> The second chunk of the "git-merge-one-file" diff _still_ claims to change
> twelve lines, and that diff _still_ only changes eleven lines. My "patch"
> isn't happy, and I can count the lines in the diff myself and verify that
> it's not patch that is wrong, it's your diff.
>
> Please please _please_ don't edit diffs by hand if you don't know what
> you're doing. Generate the diff from a clean source instead. Or ask me to
> fix it up, I'm so used to editing diffs that I can do it in my sleep.
OK ... this is done by reapplying to the top of your git tree and then
doing a show-diff. I've checked that it actually applies without
rejections to a pristine git tree.
James
git-merge-one-file-script: b2adc5fc4583e6089f4b38a47e1a73caad183f20
--- a/git-merge-one-file-script
+++ b/git-merge-one-file-script
@@ -20,23 +20,45 @@ mkdir -p "$dir"
case "${1:-.}${2:-.}${3:-.}" in
#
-# deleted in both, or deleted in one and unchanged in the other
+# deleted in both
+#
+"$1..")
+ echo "ERROR: $4 is removed in both branches"
+ echo "ERROR: This is a potential rename conflict"
+ exit 1;;
+#
+# deleted in one and unchanged in the other
#
"$1.." | "$1.$1" | "$1$1.")
rm -f -- "$4"
+ echo "Removing $4"
update-cache --remove -- "$4"
exit 0
;;
#
-# added in one, or added identically in both
+# added in one
#
-".$2." | "..$3" | ".$2$2")
- mv $(unpack-file "${2:-$3}") $4
+".$2." | "..$3" )
+ echo "Adding $4 with perm $6$7"
+ mv $(unpack-file "$2$3") $4
+ chmod "$6$7" $4
update-cache --add -- $4
exit 0
;;
-
+#
+# Added in both (check for same permissions)
+#
+".$2$2")
+ if [ "$6" != "$7" ]; then
+ echo "ERROR: File $4 added in both branches, permissions conflict $6->$7"
+ exit 1
+ fi
+ echo "Adding $4 with perm $6"
+ mv $(unpack-file "$2") $4
+ chmod "$6" $4
+ update-cache --add -- $4
+ exit 0;;
#
# Modified in both, but differently ;(
#
@@ -46,11 +68,20 @@ case "${1:-.}${2:-.}${3:-.}" in
src1=$(unpack-file $2)
src2=$(unpack-file $3)
merge "$src2" "$orig" "$src1"
- if [ $? -ne 0 ]; then
- echo Leaving conflict merge in $src2
+ ret=$?
+ if [ "$6" != "$7" ]; then
+ echo "ERROR: Permissions $5->$6->$7 don't match merging $src2"
+ if [ $ret -ne 0 ]; then
+ echo "ERROR: Leaving conflict merge in $src2"
+ 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" && update-cache --add -- "$4" && exit 0
+ cp -- "$src2" "$4" && chmod -- "$6" "$4" && update-cache --add -- "$4" && exit 0
;;
*)
merge-cache.c: 68ac4ab2d926005a5a729017c1bcb70a30634bd8
--- a/merge-cache.c
+++ b/merge-cache.c
@@ -4,7 +4,7 @@
#include "cache.h"
static const char *pgm = NULL;
-static const char *arguments[5];
+static const char *arguments[8];
static void run_program(void)
{
@@ -18,6 +18,9 @@ static void run_program(void)
arguments[2],
arguments[3],
arguments[4],
+ arguments[5],
+ arguments[6],
+ arguments[7],
NULL);
die("unable to execute '%s'", pgm);
}
@@ -36,9 +39,13 @@ static int merge_entry(int pos, const ch
arguments[2] = "";
arguments[3] = "";
arguments[4] = path;
+ arguments[5] = "";
+ arguments[6] = "";
+ arguments[7] = "";
found = 0;
do {
static char hexbuf[4][60];
+ static char ownbuf[4][60];
struct cache_entry *ce = active_cache[pos];
int stage = ce_stage(ce);
@@ -46,7 +53,9 @@ static int merge_entry(int pos, const ch
break;
found++;
strcpy(hexbuf[stage], sha1_to_hex(ce->sha1));
+ sprintf(ownbuf[stage], "%o", ntohl(ce->ce_mode) & (~S_IFMT));
arguments[stage] = hexbuf[stage];
+ arguments[stage + 4] = ownbuf[stage];
} while (++pos < active_nr);
if (!found)
die("merge-cache: %s not in the cache", path);
^ permalink raw reply
* Re: [PATCH] PPC assembly implementation of SHA1
From: Paul Mackerras @ 2005-04-24 4:40 UTC (permalink / raw)
To: linux; +Cc: git
In-Reply-To: <20050423124246.30071.qmail@science.horizon.com>
linux@horizon.com writes:
> I was working on the same thing, but hindered by lack of access to PPC
> hardware. I notice that you also took advantage of the unaligned load
> support and native byte order to do the hash straight from the source.
Yes. :) In previous experiments (in the context of trying different
ways to do memcpy) I found that doing unaligned word loads is faster
than doing aligned loads plus extra rotate and mask instructions to
get the bytes you want together.
> But I came up with a few additional refinements:
>
> - You are using three temporaries (%r0, %r6, and RT(x)) for your
> round functions. You only need one temporary (%r0) for all the functions.
> (Plus %r15 for k)
The reason I used more than one temporary is that I was trying to put
dependent instructions as far apart as reasonably possible, to
minimize the chances of pipeline stalls. Given that the 970 does
register renaming and out-of-order execution, I don't know how
essential that is, but it can't hurt.
> All are three logical instrunctions on PPC. The second form
> lets you add it into the accumulator e in two pieces:
A sequence of adds into a single register is going to incur the
2-cycle latency between generation and use of a value; i.e. the adds
will only issue on every second cycle. I think we are better off
making the dataflow more like a tree than a linear chain where
possible.
> And the last function, majority(x,y,z), can be written as:
> f3(x,y,z) = (x & y) | (y & z) | (z & x)
> = (x & y) | z & (x | y)
> = (x & y) | z & (x ^ y)
> = (x & y) + z & (x ^ y)
That's cute, I hadn't thought of that.
> - You don't need to decrement %r1 before saving registers.
> The PPC calling convention defines a "red zone" below the
> current stack pointer that is guaranteed never to be touched
> by signal handlers or the like. This is specifically for
> leaf procedure optimization, and is at least 224 bytes.
Not in the ppc32 ELF ABI - you are not supposed to touch memory below
the stack pointer. The kernel is more forgiving than that, and in
fact you can currently use the red zone without anything bad
happening, but you really shouldn't.
> - Is that many stw/lwz instructions faster than stmw/lmw?
> The latter is at least more cahce-friendly.
I believe the stw/lwz and the stmw/lmw will actually execute at the
same speed on the 970, but I have seen lwz/stw go faster than lmw/stmw
on other machines. In any case we aren't executing the prolog and
epilog as often as the instructions in the main loop, hopefully.
> - You can avoid saving and restoring %r15 by recycling %r5 for that
> purpose; it's not used after the mtctr %r5.
True.
> - The above changes actually save enough registers to cache the whole hash[5]
> in registers as well, eliminating *all* unnecessary load/store traffic.
That's cool.
> With all of the above changes, your sha1ppc.S file turns into:
I added a stwu and an addi to make a stack frame, and changed %r15 to
%r5 as you mentioned in another message. I tried it in a little test
program I have that calls SHA1_Update 256,000 times with a buffer of
4096 zero bytes, i.e. it processes 1000MB. Your version seems to be
about 2% faster; it took 4.53 seconds compared to 4.62 for mine. But
it also gives the wrong answer; I haven't investigated why.
Thanks,
Paul.
^ permalink raw reply
* Re: [ANNOUNCE] git-pasky-0.7
From: Paul Jackson @ 2005-04-24 4:35 UTC (permalink / raw)
To: James Purser; +Cc: pasky, git
In-Reply-To: <1114316259.25535.4.camel@kryten>
James wrote:
> Try separating out the git directory and linux directory. As I
> understand it each project/git repo needs its own directory.
I'm willing to do that - but I still don't get what I actually type.
I just tried:
mkdir linux
cd linux
git init
git addremote linus rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
# The above complained:
# grep: .git/remotes: No such file or directory
# but still seemed to work ?
git pull linus # seems to get the same files I pulled before ... ok.
# The above complained:
# client: nothing to do: perhaps you need to specify some filenames or the --recursive option?
Now what? I still don't have the working source files for a kernel,
and I don't see how to specify in particular whatever Linus meant by
a2755a80f40e5794ddc20e00f781af9d6320fafb
I issued a 'git --help' command (yeah - git is different - should be 'git help')
but I don't see any command that looks like it would checkout the working files.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <pj@engr.sgi.com> 1.650.933.1373, 1.925.600.0401
^ permalink raw reply
* Git cancel work
From: Dan Weber @ 2005-04-24 4:34 UTC (permalink / raw)
To: Git Mailing List
[-- Attachment #1: Type: TEXT/PLAIN, Size: 165 bytes --]
I noticed that git cancel was always doing a full checkout. So I figured,
"what about just checking out the modified files?". Attached is a patch
to do so.
Dan
[-- Attachment #2: Fast Cancel --]
[-- Type: TEXT/PLAIN, Size: 1420 bytes --]
Lets not do a full checkout on git cancel
---
commit 47197d9accb420ec55f6dfd63d990d4fb2537330
tree e8f3699877dd220440808087632ef87cce2288a7
parent c83b95297c2a6336c2007548f909769e0862b509
author Dan Weber <dan@mirrorlynx.com> 1114316504 -0400
committer Dan Weber <dan@mirrorlynx.com> 1114316504 -0400
Index: gitcancel.sh
===================================================================
--- 2aaf94eae20acc451553766f3c063bc46cfa75c6/gitcancel.sh (mode:100755 sha1:26eecb50bc812211454e98d98e8818387ae97df5)
+++ e8f3699877dd220440808087632ef87cce2288a7/gitcancel.sh (mode:100755 sha1:c836b75bb8a7c461b2d0ad536d1c3bc2d2440ab4)
@@ -2,6 +2,7 @@
#
# Cancels current edits in the working tree.
# Copyright (c) Petr Baudis, 2005
+# Copyright (c) Dan Weber, 2005
#
# This script reverts the working tree to a consistent state before
# any changes to it (including merges etc) were done.
@@ -26,5 +27,23 @@
rm -f .git/blocked .git/merging .git/merging-sym .git/merge-base
read-tree -m $(tree-id) || read-tree $(tree-id)
-checkout-cache -f -a
-update-cache --refresh
+general() {
+ for name in $(diff-cache -r $(tree-id)|awk '{print $4}')
+ do
+ checkout-cache -f $name
+ done
+ update-cache --refresh
+}
+
+full () {
+ checkout-cache -f -a
+ update-cache --refresh
+}
+
+
+if [ "$1" == "-a" -o "$1" == "--full" -o "$1" == "--all" ]; then
+ full
+else
+ general
+fi
+
^ permalink raw reply
* Re: [ANNOUNCE] git-pasky-0.7
From: Daniel Barkalow @ 2005-04-24 4:32 UTC (permalink / raw)
To: Paul Jackson; +Cc: Petr Baudis, git
In-Reply-To: <20050423205847.7758bfaa.pj@sgi.com>
On Sat, 23 Apr 2005, Paul Jackson wrote:
> I'm missing something here (well, missing alot, but ...).
>
> What are the exact steps, given that I have an empty chunk
> of diskspace, to get Linux 2.6.12-rc3 to appear there, using
> git.
>
> Actually, I got part way. Perhaps someone can complete
> the following:
>
> mkdir git
> cd git
> curl -O ftp://ftp.kernel.org/pub/software/scm/cogito/git-pasky-0.6.3.tar.bz2
> tar xvfj git-pasky-0.6.3.tar.bz2
> cd git-pasky-0.6.3
> ls -l /usr/local/include/openssl/sha.h # yup - I have openssl header
> make
> ./git init rsync://rsync.kernel.org/pub/scm/cogito/cogito.git
> make install
> git addremote pasky rsync://rsync.kernel.org/pub/scm/cogito/cogito.git
> git pull pasky
You might need a "git seek" or a "git cancel" or a "git track
pasky" here; make sure that VERSION is 0.7.
Then do make install again (to install the 0.7 version that you just got).
Then you want to go into the directory you want linux in:
cd ..
mkdir linux
cd linux
And get a version of Linux:
git init linus rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
(IIRC; I've only really worked on git with git)
If you do another addremote in the git directory, it will think that both
remote repositories are for different versions of the same project, and it
will be unhappy with the fact that they are completely unrelated.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: git-changes-script to show inter tree changes
From: James Bottomley @ 2005-04-24 1:39 UTC (permalink / raw)
To: Petr Baudis; +Cc: Linus Torvalds, git
In-Reply-To: <20050423230937.GF13222@pasky.ji.cz>
On Sun, 2005-04-24 at 01:09 +0200, Petr Baudis wrote:
> Linus isn't probably the right person to Cc on this, since this is
> git-pasky thing. Can you please post it as a signed-off patch?
I'm just offering it as one of the scripts I need to operate a git tree
as a maintainer. I don't have git-pasky installed, so I can't patch it
against anything. However, feel free to incorporate any pieces you
need.
> I don't get what are you doing anyway. I don't know the "bk changes"
> tool. Can't you just do
>
> git log theothertree yourtree
No idea .. not used it. However, how does this show the -L and -R diffs
since there are two possible views of changes between trees? It's
primarily -L (changes in local) I need to keep the changes in my local
tree. -R (changes in remote) is just useful to show what changes I'm
missing and might need to merge.
James
^ permalink raw reply
* Re: [ANNOUNCE] git-pasky-0.7
From: James Purser @ 2005-04-24 4:17 UTC (permalink / raw)
To: Paul Jackson; +Cc: Petr Baudis, git
In-Reply-To: <20050423205847.7758bfaa.pj@sgi.com>
Try separating out the git directory and linux directory. As I
understand it each project/git repo needs its own directory.
--
James Purser
http://ksit.dynalias.com
^ permalink raw reply
* Re: [ANNOUNCE] git-pasky-0.7
From: Paul Jackson @ 2005-04-24 3:58 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20050424005923.GA8859@pasky.ji.cz>
I'm missing something here (well, missing alot, but ...).
What are the exact steps, given that I have an empty chunk
of diskspace, to get Linux 2.6.12-rc3 to appear there, using
git.
Actually, I got part way. Perhaps someone can complete
the following:
mkdir git
cd git
curl -O ftp://ftp.kernel.org/pub/software/scm/cogito/git-pasky-0.6.3.tar.bz2
tar xvfj git-pasky-0.6.3.tar.bz2
cd git-pasky-0.6.3
ls -l /usr/local/include/openssl/sha.h # yup - I have openssl header
make
./git init rsync://rsync.kernel.org/pub/scm/cogito/cogito.git
make install
git addremote pasky rsync://rsync.kernel.org/pub/scm/cogito/cogito.git
git pull pasky
git addremote linus rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
git pull linus
And I have the SHA1 for Linus's 2.6.12-rc3:
a2755a80f40e5794ddc20e00f781af9d6320fafb
And I've set DB_ENVIRONMENT=<this-git-directory>/.git/objects
Now I'd like to get 2.6.12-rc3 working kernel files to appear
in a separate directory.
Now what ... how do I do that?
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <pj@engr.sgi.com> 1.650.933.1373, 1.925.600.0401
^ permalink raw reply
* Re: [PATCH] Add --strict switch to diff-cache to force SHA1 checking
From: Linus Torvalds @ 2005-04-24 3:57 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: pasky, git
In-Reply-To: <20050424033554.GA23293@diku.dk>
On Sun, 24 Apr 2005, Jonas Fonseca wrote:
>
> It seems by far the easiest to let diff-cache take care of skipping
> files which have not been modified. The alternative is to keep
> diff-cache's lazy checking and make cogito's diff jump through hoops.
> Note, although the new SHA1 signature is derived, diff-cache still
> prints the special no-SHA1 for the modified file.
The reason I don't want this is that if the commands keep on silently
fixing things like this up, then performance will go down the toilet.
What _should_ happen is that you do an "update-cache --refresh" before
doing the diff-cache. That way you do _not_ end up having to check the
sha1 match over and over again if you just did a "touch" on the file.
In other words, you're adding bandage for a problem that shouldn't exist,
and you're doing it in a way which means that _if_ the problem exists,
you'll never fix it, but you'll just rely on your bandage all the time.
So cogito definitely does not have to jump through any hoops at all. It
should just make sure to keep the cache up-to-date if it ever cares (ie
do "update-cache --refresh").
Some commands obviously won't care.
Linus
^ permalink raw reply
* Re: [ANNOUNCE] git-pasky-0.7
From: Linus Torvalds @ 2005-04-24 3:45 UTC (permalink / raw)
To: Martin Schlemmer; +Cc: Petr Baudis, git
In-Reply-To: <1114306009.27940.23.camel@nosferatu.lan>
On Sun, 24 Apr 2005, Martin Schlemmer wrote:
>
> Over here gitmerge-file.sh is looking for a 'merge' command not present.
It's usually packaged up with RCS. So in that sense git does need RCS,
although it's really only the traditional three-way merge program it
wants.
Do "yum install rcs" and you should get it (or whatever your local
alternative is).
Linus
^ permalink raw reply
* [PATCH] Use diff-cache --strict in gitdiff.sh
From: Jonas Fonseca @ 2005-04-24 3:38 UTC (permalink / raw)
To: pasky, git
In-Reply-To: <20050424033554.GA23293@diku.dk>
Use diff-cache --strict invokation to only show diff of changed files.
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
--- 2aaf94eae20acc451553766f3c063bc46cfa75c6/gitdiff.sh (mode:100755 sha1:1478a0cfb23a85c259eae1a36cf2a48597fbe8a2)
+++ uncommitted/gitdiff.sh (mode:100755)
@@ -76,7 +76,7 @@
# FIXME: Update ret based on what did we match. And take "$@"
# to account after all.
ret=
- diff-cache -r -z $tree | xargs -0 gitdiff-do "$tree" uncommitted "$filter"
+ diff-cache -r -z --strict $tree | xargs -0 gitdiff-do "$tree" uncommitted "$filter"
if [ "$id1" != " " ]; then
rm $GIT_INDEX_FILE
--
Jonas Fonseca
^ permalink raw reply
* [PATCH] Add --strict switch to diff-cache to force SHA1 checking
From: Jonas Fonseca @ 2005-04-24 3:35 UTC (permalink / raw)
To: torvalds, pasky; +Cc: git
It seems by far the easiest to let diff-cache take care of skipping
files which have not been modified. The alternative is to keep
diff-cache's lazy checking and make cogito's diff jump through hoops.
Note, although the new SHA1 signature is derived, diff-cache still
prints the special no-SHA1 for the modified file.
-
Add --strict switch to diff-cache to force it to check the SHA1
signature of modified files so files are only listed if the mode or
content changed.
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
--- 3b4a5bb703599458ce8fe504f37f8e28b77bd6ca/diff-cache.c (mode:100644 sha1:2ec6c29ab6b79a10277a2ff9021a2032d656abf0)
+++ uncommitted/diff-cache.c (mode:100644)
@@ -1,6 +1,7 @@
#include "cache.h"
static int cached_only = 0;
+static int strict_checking = 0;
static int line_termination = '\n';
/* A file entry went away or appeared */
@@ -10,6 +11,26 @@
sha1_to_hex(ce->sha1), ce->name, line_termination);
}
+static int check_modified_signature(struct cache_entry *old, struct stat *st)
+{
+ void *map;
+ int ret = -1;
+ int fd = open(old->name, O_RDONLY);
+
+ if (fd < 0)
+ return -1;
+
+ map = mmap(NULL, st->st_size, PROT_READ, MAP_PRIVATE, fd, 0);
+ if (map != MAP_FAILED) {
+ ret = check_sha1_signature(old->sha1, map, st->st_size, "blob");
+ munmap(map, st->st_size);
+ }
+
+ close(fd);
+
+ return ret;
+}
+
static int show_modified(struct cache_entry *old, struct cache_entry *new)
{
unsigned int mode = ntohl(new->ce_mode), oldmode;
@@ -27,6 +48,12 @@
changed = cache_match_stat(new, &st);
if (changed) {
mode = st.st_mode;
+
+ if (strict_checking
+ && mode == ntohl(old->ce_mode)
+ && check_modified_signature(old, &st) == 0)
+ return 0;
+
sha1 = no_sha1;
}
}
@@ -85,7 +112,7 @@
}
}
-static char *diff_cache_usage = "diff-cache [-r] [-z] [--cached] <tree sha1>";
+static char *diff_cache_usage = "diff-cache [-r] [-z] [--cached] [--strict] <tree sha1>";
int main(int argc, char **argv)
{
@@ -110,6 +137,10 @@
cached_only = 1;
continue;
}
+ if (!strcmp(arg, "--strict")) {
+ strict_checking = 1;
+ continue;
+ }
usage(diff_cache_usage);
}
--
Jonas Fonseca
^ permalink raw reply
* Re: Date handling.
From: James Purser @ 2005-04-24 3:33 UTC (permalink / raw)
To: Jan Harkes; +Cc: David Woodhouse, Linus Torvalds, git
In-Reply-To: <20050424030416.GE16751@delft.aura.cs.cmu.edu>
Wouldn't it be easier to force GMT or UTC as the base timezone for the
application. This would remove any confusion between different
timezones.
--
James Purser
http://ksit.dynalias.com
^ permalink raw reply
* [PATCH] Add -u option to diff-cache to show UNCHANGED files
From: Andreas Gal @ 2005-04-24 3:28 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0504231906110.2344@ppc970.osdl.org>
With -u diff-cache shows unchanged files, instead of files that changed.
This is useful to implement a "git clean" command that throws away all
checked out files that have not changed (yes, I really would like to
have that). One could also do show-files and then substract the
diff-cache output from it, but thats slow and clumsy.
Signed-off-by: Andreas Gal <gal@uci.edu>
--- b407d753e520fa0b1523d770d98b3015af197275/diff-cache.c
+++ diff-cache.c
@@ -2,6 +2,7 @@
static int cached_only = 0;
static int line_termination = '\n';
+static int show_unchanged = 0;
/* A file entry went away or appeared */
static void show_file(const char *prefix, struct cache_entry *ce)
@@ -32,7 +33,7 @@
}
oldmode = ntohl(old->ce_mode);
- if (mode == oldmode && !memcmp(sha1, old->sha1, 20))
+ if ((mode == oldmode && !memcmp(sha1, old->sha1, 20)) != show_unchanged)
return 0;
strcpy(old_sha1_hex, sha1_to_hex(old->sha1));
@@ -85,7 +86,7 @@
}
}
-static char *diff_cache_usage = "diff-cache [-r] [-z] [--cached] <tree sha1>";
+static char *diff_cache_usage = "diff-cache [-r] [-u] [-z] [--cached] <tree sha1>";
int main(int argc, char **argv)
{
@@ -102,6 +103,10 @@
/* We accept the -r flag just to look like diff-tree */
continue;
}
+ if (!strcmp(arg, "-u")) {
+ show_unchanged = 1;
+ continue;
+ }
if (!strcmp(arg, "-z")) {
line_termination = '\0';
continue;
^ permalink raw reply
* Re: Date handling.
From: Jan Harkes @ 2005-04-24 3:04 UTC (permalink / raw)
To: David Woodhouse; +Cc: Linus Torvalds, git
In-Reply-To: <1113500316.27227.8.camel@hades.cambridge.redhat.com>
On Thu, Apr 14, 2005 at 06:38:36PM +0100, David Woodhouse wrote:
> +/* Gr. strptime is crap for this; it doesn't have a way to require RFC2822
> + (i.e. English) day/month names, and it doesn't work correctly with %z. */
> +static void parse_rfc2822_date(char *date, char *result, int maxlen)
> +{
...
> + then = mktime(&tm); /* mktime appears to ignore the GMT offset, stupidly */
I noticed that some commit timestamps seemed to be off, looking into it
a bit more it seems like mktime is influenced by the setting of the
local TZ environment. However in parse_rfc2822_date we are trying to
interpret a time in the timezone of the original author not in the
timezone of the committer.
Here is a short test program that I believe shows the problem.
The question is, do we want to just calculate the time_t offset
ourselves without using mktime, or force the TZ environment to UTC.
Jan
/* cc -o mktime mktime.c ; ./mktime
*
* I get the following output,
* current 18000
* TZ=EST 18000
* TZ=UTC 0
* TZ=CET -3600
*/
#include <time.h>
#include <stdlib.h>
#include <stdio.h>
int main(int argc, char **argv)
{
struct tm tm = { 0, };
time_t zero;
/* 1970-01-01 00:00:00 UTC, should map to 'time_t 0' */
tm.tm_mday = 1;
tm.tm_year = 70;
zero = mktime(&tm); printf("current %d\n", zero);
setenv("TZ", "EST", 1); zero = mktime(&tm); printf("TZ=EST %d\n", zero);
setenv("TZ", "UTC", 1); zero = mktime(&tm); printf("TZ=UTC %d\n", zero);
setenv("TZ", "CET", 1); zero = mktime(&tm); printf("TZ=CET %d\n", zero);
}
^ permalink raw reply
* [PATCH] Allow multiple date-ordered lists
From: Daniel Barkalow @ 2005-04-24 2:59 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Petr Baudis, Git Mailing List
In-Reply-To: <Pine.LNX.4.21.0504232230080.30848-100000@iabervon.org>
Make pop_most_recent_commit() return the same objects multiple times, but only
if called with different bits to mark.
This is necessary to make merge-base work again.
Signed-Off-By: Daniel Barkalow <barkalow@iabervon.org>
---
commit 58ec99a22e3a8dac158d9949b0a704752991ac8a
tree 6f24c9b481d76e067d64bac1a8dbd5cf5d0dfb05
parent f4adf2687593e8d6e58ac1c4710e0385a82500e5
author Daniel Barkalow <barkalow@iabervon.org> 1114311416 -0400
committer Daniel Barkalow <barkalow@silva-tulga.(none)> 1114311416 -0400
Index: commit.c
===================================================================
--- 34933617a2e8284ffca6ab2a1b2f00d6996a58e7/commit.c (mode:100644 sha1:0243e77cb8e839e2972a2882bb1d0719f6e3cff1)
+++ 6f24c9b481d76e067d64bac1a8dbd5cf5d0dfb05/commit.c (mode:100644 sha1:2502688262819033f5b8ed60a7bef5eed0aa2d6a)
@@ -114,7 +114,8 @@
*list = ret;
}
-struct commit *pop_most_recent_commit(struct commit_list **list)
+struct commit *pop_most_recent_commit(struct commit_list **list,
+ unsigned int mark)
{
struct commit *ret = (*list)->item;
struct commit_list *parents = ret->parents;
@@ -125,8 +126,9 @@
while (parents) {
struct commit *commit = parents->item;
- if (!commit->object.parsed) {
- parse_commit(commit);
+ parse_commit(commit);
+ if (!(commit->object.flags & mark)) {
+ commit->object.flags |= mark;
insert_by_date(list, commit);
}
parents = parents->next;
Index: commit.h
===================================================================
--- 34933617a2e8284ffca6ab2a1b2f00d6996a58e7/commit.h (mode:100644 sha1:c8684d1cd07d7c9ed0af06a3f3d9e7b49fbed0a2)
+++ 6f24c9b481d76e067d64bac1a8dbd5cf5d0dfb05/commit.h (mode:100644 sha1:d61d084c89c72f4fe79c654db721df31c4f04224)
@@ -31,6 +31,7 @@
/** Removes the first commit from a list sorted by date, and adds all
* of its parents.
**/
-struct commit *pop_most_recent_commit(struct commit_list **list);
+struct commit *pop_most_recent_commit(struct commit_list **list,
+ unsigned int mark);
#endif /* COMMIT_H */
Index: merge-base.c
===================================================================
--- 34933617a2e8284ffca6ab2a1b2f00d6996a58e7/merge-base.c (mode:100644 sha1:0e4c58ede915aca5719bbd12ecd1945f2f300590)
+++ 6f24c9b481d76e067d64bac1a8dbd5cf5d0dfb05/merge-base.c (mode:100644 sha1:2c40881302e586366f03ae6ac6e7c0035847e2f0)
@@ -6,29 +6,11 @@
int other_mark)
{
struct commit *item = (*list_p)->item;
-
- if (item->object.flags & this_mark) {
- /*
- printf("%d already seen %s %x\n",
- this_mark
- sha1_to_hex(posn->parent->sha1),
- posn->parent->flags);
- */
- /* do nothing; this indicates that this side
- * split and reformed, and we only need to
- * mark it once.
- */
- *list_p = (*list_p)->next;
- } else if (item->object.flags & other_mark) {
+
+ if (item->object.flags & other_mark) {
return item;
} else {
- /*
- printf("%d based on %s\n",
- this_mark,
- sha1_to_hex(posn->parent->sha1));
- */
- pop_most_recent_commit(list_p);
- item->object.flags |= this_mark;
+ pop_most_recent_commit(list_p, this_mark);
}
return NULL;
}
@@ -39,7 +21,9 @@
struct commit_list *rev2list = NULL;
commit_list_insert(rev1, &rev1list);
+ rev1->object.flags |= 0x1;
commit_list_insert(rev2, &rev2list);
+ rev2->object.flags |= 0x2;
parse_commit(rev1);
parse_commit(rev2);
Index: rev-list.c
===================================================================
--- 34933617a2e8284ffca6ab2a1b2f00d6996a58e7/rev-list.c (mode:100644 sha1:1c797d24a91b44994dc11180dd61c3ecf8f93349)
+++ 6f24c9b481d76e067d64bac1a8dbd5cf5d0dfb05/rev-list.c (mode:100644 sha1:77bfc29db1aad08ba9d7d87ce08d33d4a88e74e3)
@@ -16,7 +16,7 @@
commit_list_insert(commit, &list);
do {
- struct commit *commit = pop_most_recent_commit(&list);
+ struct commit *commit = pop_most_recent_commit(&list, 0x1);
printf("%s\n", sha1_to_hex(commit->object.sha1));
} while (list);
return 0;
^ permalink raw reply
* Re: [PATCH] PPC assembly implementation of SHA1
From: Benjamin Herrenschmidt @ 2005-04-24 2:49 UTC (permalink / raw)
To: linux; +Cc: Paul Mackerras, git
In-Reply-To: <20050423124246.30071.qmail@science.horizon.com>
On Sat, 2005-04-23 at 12:42 +0000, linux@horizon.com wrote:
> - You don't need to decrement %r1 before saving registers.
> The PPC calling convention defines a "red zone" below the
> current stack pointer that is guaranteed never to be touched
> by signal handlers or the like. This is specifically for
> leaf procedure optimization, and is at least 224 bytes.
On ELF ppc32 ABI ? Hrm... the SysV ABI document says
"The only permitted references with negative offsets from the stack
pointer are those described here for establishing a stack frame."
I know MacOS had a red zone, but do we ?
> - Is that many stw/lwz instructions faster than stmw/lmw?
> The latter is at least more cahce-friendly.
More cache friendly ? Hrm.. I wouldn't be sure. Also, I remember readind
a while ago that those store/load multiple instructions aren't that
recommended. They aren't very good on some CPU models. I would expect
the bus/cache bandwidth to be the limiting factor here anyway, and as
you point out below, the they don't deal with unaligned access very well
in all cases.
^ permalink raw reply
* Re: A very basic tutorial
From: James Purser @ 2005-04-24 2:45 UTC (permalink / raw)
To: dwheeler; +Cc: git
In-Reply-To: <426B0226.8020001@dwheeler.com>
Thanks for the heads up, I shall update the tutorial with the new
information as soon as possible.
--
James Purser
http://ksit.dynalias.com
^ permalink raw reply
* Re: [PATCH 1/5] Add some functions for commit lists
From: Daniel Barkalow @ 2005-04-24 2:40 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Petr Baudis, Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0504231916300.2344@ppc970.osdl.org>
On Sat, 23 Apr 2005, Linus Torvalds wrote:
>
>
> On Sat, 23 Apr 2005, Linus Torvalds wrote:
> >
> > Ok. This is more in like with what I was hoping for, looks good.
>
> Oh, Daniel, I notice that you have the same old bug: it will happily add
> the same parent to the list several times. You need to prune them out, and
> ignore things you've seen.
>
> I pushed out the fix (don't parse and add parents to the list that were
> already parsed).
This won't actually work for merge-base, which wants to run two of these,
one for each head, in parallel, and find the first commit on both lists. I
think making insert_by_date() ignore items already in the list is a better
solution, although that might run into problems if there's a complicated
graph of commits all with the same time.
Another option is to specify a object.flags bit to mark for each commit
and ignore commits that are already marked.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH 1/5] Add some functions for commit lists
From: Linus Torvalds @ 2005-04-24 2:20 UTC (permalink / raw)
To: Daniel Barkalow, Petr Baudis; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0504231906110.2344@ppc970.osdl.org>
On Sat, 23 Apr 2005, Linus Torvalds wrote:
>
> Ok. This is more in like with what I was hoping for, looks good.
Oh, Daniel, I notice that you have the same old bug: it will happily add
the same parent to the list several times. You need to prune them out, and
ignore things you've seen.
I pushed out the fix (don't parse and add parents to the list that were
already parsed).
Linus
^ permalink raw reply
* Re: A very basic tutorial
From: David A. Wheeler @ 2005-04-24 2:19 UTC (permalink / raw)
To: James Purser, git
In-Reply-To: <1114305552.3114.3.camel@kryten>
James Purser wrote:
> I've done a very basic tutorial for using git. If someone who knows more
> about git (pretty much everyone on this list I think) could have a look
> and point out any glaring errors that would be great.
You mention two layers, but the layers are about to get (pun?)
separate names: git (lower layer) and Cogito (upper layer, and
separable from the "real" git lower layer). You should explain
the two names.
You concentrate on Cogito, which is almost certainly reasonable
for normal starting points, but that's not clear in your text.
Also: The Cogito user interface is about to undergo a
significant rename of the commands. It won't be hard to update
your text for it, but you'll need to do so.
--- David A. Wheeler
^ permalink raw reply
* Re: [PATCH 1/5] Add some functions for commit lists
From: Linus Torvalds @ 2005-04-24 2:12 UTC (permalink / raw)
To: Daniel Barkalow, Petr Baudis; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.21.0504232003490.30848-100000@iabervon.org>
On Sat, 23 Apr 2005, Daniel Barkalow wrote:
>
> This adds a function for inserting an item in a commit list, a function
> for sorting a commit list by date, and a function for progressively
> scanning a commit history from most recent to least recent.
Ok. This is more in like with what I was hoping for, looks good.
All patches applied and pushed out, and I wrote a trivial "rev-list" thing
that is kind of a cut-down rev-tree which just lists the commits in the
order the "fake time order".
The "fake time order" just uses this progressive commit history scan,
which is different from the old "sort by date" in that it still takes
parenthood into account, and always shows the child first.
It turns out that since git is so damn fast, when I commit a mbox of
patches, they often all get the same date, since we "only" do dates with a
one-second granularity. So sorting by date ends up doing strange things,
when some of the entries have no sort order.
Daniel's date-based incremental scanning solves this problem, and also
means that we get output immediately without having to parse the whole
tree down to the root.
So with this, git-pasky should probably do the following..
Linus
-
Make gitlog.sh use the new simple time-based commit traversal
helpers.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
gitlog.sh: a496a864f9586e47a4d7bd3ae0af0b3e07b7deb8
--- a/gitlog.sh
+++ b/gitlog.sh
@@ -11,7 +11,7 @@
base=$(gitXnormid.sh -c $1) || exit 1
-rev-tree $base | sort -rn | while read time commit parents; do
+rev-list $base | while read commit; do
echo commit ${commit%:*};
cat-file commit $commit | \
while read key rest; do
^ permalink raw reply
* fsck-cache problem
From: Morten Welinder @ 2005-04-24 1:55 UTC (permalink / raw)
To: GIT Mailing List, Linus Torvalds
While downloading the sparse git database I got impatient and ran
fsck-cache on it.
I got...
...
missing (null) ff515b91674ff2f5b082a927676dbf392d04d9ce
missing (null) ff94be6fbcce10b83824defbdc2f8819121bbd4d
missing (null) ffa4ddda950185bf313654e903207a3fc2d5f261
That "(null)" is not from git, but from glibc in response to NULL
passed for %s. It might
as well crash (as some other libc do) or send in the marines.
Morten
^ permalink raw reply
* [PATCH] Add archive-tree, a cpio archive creator
From: Rene Scharfe @ 2005-04-24 1:43 UTC (permalink / raw)
To: Petr Baudis; +Cc: git, torvalds
This patch adds archive-tree, a program to create a cpio archive of all
files referenced by a given tree or commit object. Why cpio and not
e.g., tar? The cpio format I chose (GNU cpio calls it "odc") is dead
simple compared to any tar variant. I was simply being lazy. :-P
archive-tree optionally accepts a basedir, i.e. a prefix added to all
names in the archive. Example usage:
$ ./archive-tree `tree-id` frob-1.1 | gzip -9 > frob-1.1.cpio.gz
Directory permissions are not handled properly, yet. All directories
get a mode of (at least) 0755.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
--- git-pasky/Makefile~ 2005-04-20 01:43:51.000000000 +0200
+++ git-pasky/Makefile 2005-04-24 02:02:22.000000000 +0200
@@ -29,7 +29,7 @@
PROG= update-cache show-diff init-db write-tree read-tree commit-tree \
cat-file fsck-cache checkout-cache diff-tree rev-tree show-files \
check-files ls-tree merge-base merge-cache unpack-file git-export \
- diff-cache convert-cache
+ diff-cache convert-cache archive-tree
SCRIPT= parent-id tree-id git gitXnormid.sh gitadd.sh gitaddremote.sh \
gitcommit.sh gitdiff-do gitdiff.sh gitlog.sh gitls.sh gitlsobj.sh \
--- /dev/null 2004-12-03 19:50:49.000000000 +0100
+++ git-pasky/archive-tree.c 2005-04-24 03:31:39.000000000 +0200
@@ -0,0 +1,206 @@
+/*
+ * GIT - The information manager from hell
+ *
+ * Copyright (C) Linus Torvalds, 2005
+ */
+#include "cache.h"
+
+const char *basedir = NULL;
+
+struct path_prefix {
+ struct path_prefix *prev;
+ const char *name;
+};
+
+static void append_string(char **buffer, const char *s)
+{
+ unsigned int len = strlen(s);
+ memcpy(*buffer, s, len);
+ *buffer += len;
+}
+
+static void append_char(char **buffer, char c)
+{
+ **buffer = c;
+ *buffer += 1;
+}
+
+static unsigned int path_prefix_len(struct path_prefix *prefix)
+{
+ if (!prefix)
+ return 0;
+ return path_prefix_len(prefix->prev) + strlen(prefix->name) + 1;
+}
+
+static void append_path_prefix(char **buffer, struct path_prefix *prefix)
+{
+ if (!prefix)
+ return;
+ append_path_prefix(buffer, prefix->prev);
+ append_string(buffer, prefix->name);
+ append_char(buffer, '/');
+}
+
+static unsigned long loopy_write(void *buf, unsigned long size)
+{
+ while (size > 0) {
+ long ret = write(1, buf, size);
+ if (ret < 0) {
+ if (errno == EAGAIN)
+ continue;
+ /* Ignore epipe */
+ if (errno == EPIPE)
+ break;
+ die("archive-tree: %s", strerror(errno));
+ } else if (!ret) {
+ die("archive-tree: disk full?");
+ }
+ size -= ret;
+ buf += ret;
+ }
+ return size;
+}
+
+static long write_header(const char *basepath,
+ struct path_prefix *prefix,
+ const char *path,
+ unsigned int mode,
+ unsigned long size)
+{
+ unsigned int namelen;
+ char *header, *p;
+ long ret;
+
+ namelen = path_prefix_len(prefix) + strlen(path) + 1;
+ if (basepath)
+ namelen += strlen(basepath) + 1;
+
+ header = malloc(76 + namelen);
+ if (!header)
+ die("archive-tree: %s", strerror(errno));
+
+ sprintf(header, "%06o%06o%06o%06o%06o%06o%06o%06o%011o%06o%011lo",
+ 070707, /* magic */
+ 0, /* dev */
+ 0, /* ino */
+ S_ISDIR(mode) ? mode | 0755 : mode, /* mode */ /*FIXME*/
+ 0, /* uid */
+ 0, /* gid */
+ 1, /* nlink */
+ 0, /* rdev */
+ 0, /* mtime */
+ namelen, /* namesize */
+ S_ISDIR(mode) ? 0 : size); /* filesize */
+
+ p = header + 76;
+ if (basepath) {
+ append_string(&p, basepath);
+ append_char(&p, '/');
+ }
+ append_path_prefix(&p, prefix);
+ append_string(&p, path);
+ append_char(&p, '\0');
+
+ ret = loopy_write(header, 76 + namelen);
+ free(header);
+ return ret;
+}
+
+static void write_trailer(void)
+{
+ write_header(NULL, NULL, "TRAILER!!!", 0, 0);
+}
+
+static void list_recursive(void *buffer,
+ const unsigned char *type,
+ unsigned long size,
+ struct path_prefix *prefix)
+{
+ struct path_prefix this_prefix;
+ this_prefix.prev = prefix;
+
+ if (strcmp(type, "tree"))
+ die("expected a 'tree' node");
+
+ while (size) {
+ int namelen = strlen(buffer)+1;
+ void *eltbuf;
+ char elttype[20];
+ unsigned long eltsize;
+ unsigned char *sha1 = buffer + namelen;
+ char *path = strchr(buffer, ' ') + 1;
+ unsigned int mode;
+
+ if (size < namelen + 20 || sscanf(buffer, "%o", &mode) != 1)
+ die("corrupt 'tree' file");
+ buffer = sha1 + 20;
+ size -= namelen + 20;
+
+ if (! (eltbuf = read_sha1_file(sha1, elttype, &eltsize)) ) {
+ error("cannot read %s", sha1_to_hex(sha1));
+ continue;
+ }
+
+ if (write_header(basedir, prefix, path, mode, eltsize))
+ die("archive-tree: could not write header");
+
+ if (S_ISDIR(mode)) {
+ this_prefix.name = path;
+ list_recursive(eltbuf, elttype, eltsize, &this_prefix);
+ } else {
+ if (loopy_write(eltbuf, eltsize))
+ die("archive-tree: could not write body");
+ }
+
+ free(eltbuf);
+ }
+}
+
+static int list(unsigned char *sha1)
+{
+ void *buffer;
+ unsigned long size;
+
+ buffer = read_tree_with_tree_or_commit_sha1(sha1, &size, 0);
+ if (!buffer)
+ die("unable to read sha1 file");
+ if (basedir)
+ write_header(NULL, NULL, basedir, 040755, 0); /*FIXME*/
+ list_recursive(buffer, "tree", size, NULL);
+ free(buffer);
+ return 0;
+}
+
+static const char *archive_tree_usage = "archive-tree <key> [basedir]";
+
+int main(int argc, char **argv)
+{
+ unsigned char sha1[20];
+
+ while (1 < argc && argv[1][0] == '-') {
+ switch (argv[1][1]) {
+ default:
+ usage(archive_tree_usage);
+ }
+ argc--; argv++;
+ }
+
+ switch (argc) {
+ case 3:
+ basedir = argv[2];
+ /* FALLTHROUGH */
+ case 2:
+ if (get_sha1_hex(argv[1], sha1) < 0)
+ usage(archive_tree_usage);
+ break;
+ default:
+ usage(archive_tree_usage);
+ }
+ sha1_file_directory = getenv(DB_ENVIRONMENT);
+ if (!sha1_file_directory)
+ sha1_file_directory = DEFAULT_DB_ENVIRONMENT;
+ if (list(sha1) < 0)
+ die("list failed");
+ write_trailer();
+ return 0;
+}
^ permalink raw reply
* git-pasky "tutorial"
From: Benjamin Herrenschmidt @ 2005-04-24 1:35 UTC (permalink / raw)
To: git
Hi !
Is it really only my own stupidity, or is the "tutorial" in the README
file in there only understandable if you in fact already know what it
tries to explain ?
The more I read it, the more confused I am about the whole thing...
Is there some document somewhere that starts by explaining what are the
concepts of "branch", "tracking", etc... in the context of git ?
Ben.
^ 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