* 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
* 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: 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
* 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: [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: [ANNOUNCE] git-pasky-0.7
From: Paul Jackson @ 2005-04-24 4:50 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: pasky, git
In-Reply-To: <Pine.LNX.4.21.0504240018350.30848-100000@iabervon.org>
Daniel wrote:
> You might need a "git seek" or a "git cancel" or a "git track
> pasky" here; make sure that VERSION is 0.7.
Ok - I typed some random combination of "git seek", "git cancel" and
"git track pasky" and now I have a file named VERSION containing the
string "0.7\n", and I did a make install, with apparently useful
results (built and installed a bunch of stuff).
Then I did the following, with immediate, but not apparently useful, results:
$ rm -fr linux
$ mkdir linux
$ cd linux
$ git init linus rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
defaulting to local storage area
link_stat linus/HEAD : No such file or directory
rsync error: some files could not be transferred (code 23) at main.c(620)
gitpull.sh: unable to get the head pointer of branch master
gitinit.sh: pull failed
Still stuck ...
--
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] make file merging respect permissions
From: Linus Torvalds @ 2005-04-24 4:55 UTC (permalink / raw)
To: James Bottomley; +Cc: Petr Baudis, Git Mailing List
In-Reply-To: <1114317771.4980.7.camel@mulgrave>
On Sat, 23 Apr 2005, James Bottomley wrote:
>
> 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.
Well, I actually ended up editing the line numbers manually and already
pushed out the previous one, so you might want to double-check that my
current tree matches yours.
Linus
^ permalink raw reply
* Re: [ANNOUNCE] git-pasky-0.7
From: James Purser @ 2005-04-24 4:58 UTC (permalink / raw)
To: Paul Jackson; +Cc: Daniel Barkalow, pasky, git
In-Reply-To: <20050423215007.1b2877d2.pj@sgi.com>
try git init rsync://rsync.kernel.org/pub/linux/kernel/people/torvalds/linux-2.6.git
--
James Purser
http://ksit.dynalias.com
^ permalink raw reply
* Re: git pull on ia64 linux tree
From: Sanjoy Mahajan @ 2005-04-24 5:02 UTC (permalink / raw)
To: Linus Torvalds; +Cc: tony.luck, Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0504221521260.2344@ppc970.osdl.org>
> I think it would be nice to use the TZ data to show the thing in the
> timezone of the committer, though. Dunno how to do that, maybe
> something like
> TZ=$tz date -d "1970-01-01 + $sec sec"
> Sadly, it looks like "date" doesn't understand timezone syntax like
> that
Try:
negzone=`echo $tz | tr '[-]+' '+-'`
date -u -R -d "1970-01-01 $negzone + $sec sec" | sed "s/+0000/$tz/"
Or as a script:
#!/bin/bash
# usage: show-date.sh <utcseconds> <zone>
negzone=`echo $2 | tr '[-]+' '+-'`
date -u -R -d "1970-01-01 $negzone + $1 sec" | sed "s/+0000/$2/"
A simple test:
$ show-date.sh 10 +0200
Thu, 01 Jan 1970 02:00:10 +0200
Negating the timezone is an ugly workaround for date not understanding
a sensible TZ format. I almost always use -u with date, otherwise I
get confused about what timezone it is using to interpret and to print
the date.
-Sanjoy
^ permalink raw reply
* Re: [ANNOUNCE] git-pasky-0.7
From: Paul Jackson @ 2005-04-24 5:02 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: pasky, git
In-Reply-To: <Pine.LNX.4.21.0504240018350.30848-100000@iabervon.org>
The winning solution via private email:
mkdir linux
cd linux
git init rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Another email was missing the 'scm' term.
I still don't see how to get to the official 2.6.12-rc3:
a2755a80f40e5794ddc20e00f781af9d6320fafb
But it looks like a kernel now - thanks !!
--
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] make file merging respect permissions
From: James Bottomley @ 2005-04-24 5:03 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Petr Baudis, Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0504232153500.15879@ppc970.osdl.org>
On Sat, 2005-04-23 at 21:55 -0700, Linus Torvalds wrote:
> Well, I actually ended up editing the line numbers manually and already
> pushed out the previous one, so you might want to double-check that my
> current tree matches yours.
Yes, the sha1 of my changed file and the one you merged match, so
everything looks sane.
Sorry for the confusion,
James
^ permalink raw reply
* [PATH] fix segfault in fsck-cache
From: Andreas Gal @ 2005-04-24 5:05 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0504232153500.15879@ppc970.osdl.org>
I somehow got some corrupted object files in my repository that zlib
refuses to decompress. This patch makes sure we abort early before the
memcpy a few lines downtream segfaults (due to total_out == 0).
Andreas
Signed-off-by: Andreas Gal <gal@uci.edu>
--- 66308ede85c2dad6b184fb74a7215b06a173d8f7/sha1_file.c
+++ sha1_file.c
@@ -155,6 +155,8 @@
inflateInit(&stream);
ret = inflate(&stream, 0);
+ if (ret != Z_OK)
+ return NULL;
if (sscanf(buffer, "%10s %lu", type, size) != 2)
return NULL;
^ permalink raw reply
* Re: [GIT PATCH] Selective diff-tree
From: Linus Torvalds @ 2005-04-24 5:09 UTC (permalink / raw)
To: David Woodhouse; +Cc: Git Mailing List
In-Reply-To: <1113400651.20848.135.camel@hades.cambridge.redhat.com>
On Wed, 13 Apr 2005, David Woodhouse wrote:
>
> The patch below makes diff-tree take extra arguments, specifying the
> files or directories which should be considered 'interesting'. Changes
> in uninteresting directories are not reported; we don't even bother to
> recurse down into those trees.
David, I took your patch, updated it for some changes in diff-tree, and
then totally rewrote (and simplified) your testing for "interesting".
There was no reason to consider "/" special, as it falls out of the other
cases quite naturally.
It passes all the tests I threw at it, but they weren't exhaustive (but I
do think I tested the border cases). Mind double-checking that it works
for your cases too?
Linus
^ permalink raw reply
* Re: [ANNOUNCE] git-pasky-0.7
From: Greg KH @ 2005-04-24 5:11 UTC (permalink / raw)
To: Paul Jackson; +Cc: Daniel Barkalow, pasky, git
In-Reply-To: <20050423220236.26f834ee.pj@sgi.com>
On Sat, Apr 23, 2005 at 10:02:36PM -0700, Paul Jackson wrote:
> The winning solution via private email:
>
> mkdir linux
> cd linux
> git init rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
>
> Another email was missing the 'scm' term.
>
> I still don't see how to get to the official 2.6.12-rc3:
>
> a2755a80f40e5794ddc20e00f781af9d6320fafb
From your "linux" directory do:
cd ..
mkdir 2.6.12-rc3
cd 2.6.12-rc3
mkdir .git
cp -rl ../linux/.git/object .git/objects
TREE_HEAD=`cat-file commit a2755a80f40e5794ddc20e00f781af9d6320fafb | head -n 1 | cut -f 2 -d " "`
echo "$TREE_HEAD" > .git/HEAD
read-tree $TREE_HEAD
checkout-cache -a
update-cache --refresh
And you should have a 2.6.12-rc3 tree, all ready to commit new changes
into.
Or at least that's how my wrapper scripts do it, I haven't converted
them over to the "easier" git-pasky commands yet :)
thanks,
greg k-h
^ permalink raw reply
* Re: [ANNOUNCE] git-pasky-0.7
From: Daniel Barkalow @ 2005-04-24 5:12 UTC (permalink / raw)
To: Paul Jackson; +Cc: git
In-Reply-To: <20050423220236.26f834ee.pj@sgi.com>
On Sat, 23 Apr 2005, Paul Jackson wrote:
> I still don't see how to get to the official 2.6.12-rc3:
>
> a2755a80f40e5794ddc20e00f781af9d6320fafb
You've got the current head, which is a couple of days past 2.6.12-rc3. If
you actually want the release version,
git seek a2755a80f40e5794ddc20e00f781af9d6320fafb
should get you there, although it will not want to let you commit changes
when you are blatantly not up-to-date.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: Git for redundant mail servers
From: David Lang @ 2005-04-24 5:12 UTC (permalink / raw)
To: jon; +Cc: David Woodhouse, git
In-Reply-To: <2cfc403205042301243841fe0c@mail.gmail.com>
On Sat, 23 Apr 2005, Jon Seymour wrote:
> On 4/23/05, David Woodhouse <dwmw2@infradead.org> wrote:
>> Random alternative use for git... we could use it to provide a cluster
>> of redundant mail delivery/storage servers.
>>
>> The principle is simple; you use something like a set of Maildir
>> folders, stored in a git repository. Any action on the mail storage is
>> done as a commit -- that includes delivery of new mail, or user actions
>> from the IMAP server such as changing flags, deleting or moving mail.
>> These actions are actually fairly efficient when Maildir folders are
>> stored in a git repository -- the IMAP model is that mails are
>> immutable, and flag changes are done as renames.
>>
>> In the normal case where all the servers are online, each commit is
>> immediately pushed to each remote server. When a server is offline or
>> separated somehow from the rest of the group, it's going to have to do a
>> merge when it reconnects -- we'd implement a Maildir-specific merge
>> algorithm, which really isn't that hard to do.
>>
>
> This is a cool idea. When the concept is rendered this way, it sounds
> a lot like some of the core principles in the architecture of the
> Lotus Notes replication engine. I've always thought it would be cool
> to have an open engine that provided similar functionality to the
> Lotus Notes replication engine without the naff programming
> environment that sits on top. I can see how the git concepts and code
> could provide the basis of such a solution. Very cool.
Having been in several discussions on the cyrus mailing list about
replication let me point out a couple basic problems that you have to work
around.
1. when a new message arrives it gets given a numeric messageid, this
message id is not supposed to change without fairly drastic things
happening (the server telling all clients to forget everything they know
about the status of the mailbox). this requires syncronization between
servers if both are receiving messages.
2. git effectivly stores snapshots of things and you deduce the changes by
comparing the snapshots. for things like flags changing this is a
relativly inefficiant way to replicate changes (although if one server is
offline for a while it could be a firly efficiant way to do the merge)
and now a couple of starting points
Cyrus already implements single-instance store so the concept of the same
message living in multiple places doesn't have to be grafted in. it keeps
the message flags seperate from the messages themselves so the messages
could be replicated seperatly from the state.
personally I'm not seeing git being a huge advantage for this, but I do
see some advantages and it's very possible I'm missing some others.
go for it.
David Lang
--
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.
-- C.A.R. Hoare
^ permalink raw reply
* Re: Old "sparse" archive converted..
From: Jeff Garzik @ 2005-04-24 5:24 UTC (permalink / raw)
To: Linus Torvalds; +Cc: sparse mailing list, Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0504231815350.2344@ppc970.osdl.org>
Linus Torvalds wrote:
> Ok, I expanded on "convert-cache" quite a bit, to the point where it could
> actually re-write "commit" and "tree" objects entirely, at which point it
> now became possible to convert the broken old sparse archive that had the
> wrong date format in its commit objects, and had the old flat-file format
> for the "tree" objects.
>
> I updated the tree at
>
> kernel.org:/pub/linux/kernel/people/torvalds/sparse.git
Any chance you could copy it to
/pub/scm/linux/kernel/git/torvalds/sparse.git
?
Jeff
^ permalink raw reply
* Re: [PATH] fix segfault in fsck-cache
From: Andreas Gal @ 2005-04-24 5:24 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0504232202380.7195@sam.ics.uci.edu>
This isn't working right either, depending on your ZLIB version. Do not
apply.
Andreas
On Sat, 23 Apr 2005, Andreas Gal wrote:
>
> I somehow got some corrupted object files in my repository that zlib
> refuses to decompress. This patch makes sure we abort early before the
> memcpy a few lines downtream segfaults (due to total_out == 0).
>
> Andreas
>
> Signed-off-by: Andreas Gal <gal@uci.edu>
>
> --- 66308ede85c2dad6b184fb74a7215b06a173d8f7/sha1_file.c
> +++ sha1_file.c
> @@ -155,6 +155,8 @@
>
> inflateInit(&stream);
> ret = inflate(&stream, 0);
> + if (ret != Z_OK)
> + return NULL;
> if (sscanf(buffer, "%10s %lu", type, size) != 2)
> return NULL;
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: Humble request of 'git' developers
From: Sanjoy Mahajan @ 2005-04-24 5:47 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Chris Wedgwood, git, David A. Wheeler
In-Reply-To: <426AAB65.2060401@pobox.com>
[Added David Wheeler to the CC given his (admirable) pushes for wide
standards compliance.]
>>>Just have one 'git' script, which looks in /usr/local/libexec/git
> [or] /usr/libexec/git
The FHS <http://www.pathname.com/fhs/pub/fhs-2.3.html> looks like it
recommends a /usr/lib/git directory:
/usr/lib : Libraries for programming and packages
Purpose
/usr/lib includes object files, libraries, and internal binaries that
are not intended to be executed directly by users or shell scripts.
Applications may use a single subdirectory under /usr/lib. If an
application uses a subdirectory, all architecture-dependent data
exclusively used by the application must be placed within that
subdirectory.
My Debian sarge system has one libexec-like directory, but it follows
the FHS:
$ locate '/usr*libexec*'
/usr/lib/php4/libexec
-Sanjoy
^ permalink raw reply
* Re: Git for redundant mail servers
From: David Woodhouse @ 2005-04-24 5:54 UTC (permalink / raw)
To: David Lang; +Cc: jon, git
In-Reply-To: <Pine.LNX.4.62.0504232159030.32287@qynat.qvtvafvgr.pbz>
On Sat, 2005-04-23 at 22:12 -0700, David Lang wrote:
> 1. when a new message arrives it gets given a numeric messageid, this
> message id is not supposed to change without fairly drastic things
> happening (the server telling all clients to forget everything they know
> about the status of the mailbox). this requires syncronization between
> servers if both are receiving messages.
Yeah, that's the most interesting part. One option would be to require
quorum before a server is allowed to add to a mailbox -- but that would
render the thing unsuitable for _intentional_ offline use, where you
want to be able to move mails from one folder to another on your laptop
while it's disconnected.
Since it should be relatively rare for 'competing' commits to occur
during periods of disconnection, I suspect that the solution doesn't
have to be particularly efficient. I'm not sure I'd really want to
change UIDVALIDITY if it happened, but perhaps we could simply remove
_all_ the affected UIDs, and assign new UIDs to the same mails.
In practice, it's far more important that for us to ensure that an
existing UID _never_ refers to a different mail, than it is to make sure
that a given mail always keeps the same UID.
> 2. git effectivly stores snapshots of things and you deduce the changes by
> comparing the snapshots. for things like flags changing this is a
> relativly inefficiant way to replicate changes (although if one server is
> offline for a while it could be a firly efficiant way to do the merge)
We don't have to stick _precisely_ to Maildir -- but flag changes are
just a rename in Maildir, leaving the mail object entirely intact while
changing only the tree. That isn't _so_ bad; but yes, it could probably
be done a little better than just "Maildir in git".
--
dwmw2
^ permalink raw reply
* [PATCH] fix segfault in fsck-cache (2nd attempt)
From: Andreas Gal @ 2005-04-24 5:55 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.58.0504232056160.2344@ppc970.osdl.org>
Here is how to trigger it:
echo blob 100 > .git/objects/00/ae4e8d3208e09f2cf7a38202a126f728cadb49
Then run fsck-cache. It will try to unpack after the header to calculate
the hash, inflate returns total_out == 0 and memcpy() dies.
The patch below seems to work with ZLIB 1.1 and 1.2.
Signed-off-by: Andreas Gal <gal@uci.edu>
--- 97a515a073fec5870dfaaa279868ce9330853d3d/sha1_file.c
+++ sha1_file.c
@@ -155,6 +155,8 @@
inflateInit(&stream);
ret = inflate(&stream, 0);
+ if (ret < Z_OK)
+ return NULL;
if (sscanf(buffer, "%10s %lu", type, size) != 2)
return NULL;
On Sat, 23 Apr 2005, Linus Torvalds wrote:
>
>
> 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
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [GIT PATCH] Selective diff-tree
From: David Woodhouse @ 2005-04-24 6:25 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0504232202340.19877@ppc970.osdl.org>
On Sat, 2005-04-23 at 22:09 -0700, Linus Torvalds wrote:
> It passes all the tests I threw at it, but they weren't exhaustive (but I
> do think I tested the border cases). Mind double-checking that it works
> for your cases too?
It seems to work at least as well as my version did -- which is to say
it's fine for the handful of test cases I tried, which is probably about
the same as what you did.
On the other hand, my gitfilelog.sh is fairly fundamentally flawed and
probably needs rewriting in C based on rev-tree.
--
dwmw2
^ permalink raw reply
* Re: Date handling.
From: David Woodhouse @ 2005-04-24 6:38 UTC (permalink / raw)
To: Jan Harkes; +Cc: Linus Torvalds, git
In-Reply-To: <20050424030416.GE16751@delft.aura.cs.cmu.edu>
On Sat, 2005-04-23 at 23:04 -0400, Jan Harkes wrote:
> 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.
Ewww. I missed that in the documentation. I suppose I should have worked
it out having empirically determined that it ignores the tm_gmtoff
field.
> The question is, do we want to just calculate the time_t offset
> ourselves without using mktime, or force the TZ environment to UTC.
I don't think we want to be in the business of counting leap seconds; we
need to let the system do it. I don't much like setting TZ to UTC though
-- how about we use your test case to find the offset and subtract that?
Does this work?
Index: commit-tree.c
===================================================================
--- 31e9af73983d640090508b06784ef7db4816c957/commit-tree.c (mode:100644 sha1:c0b07f89286c3f6cceae8122b4c3142c8efaf8e1)
+++ uncommitted/commit-tree.c (mode:100664)
@@ -138,10 +138,14 @@
struct tm tm;
char *p;
int i, offset;
- time_t then;
+ time_t then, localofs;
memset(&tm, 0, sizeof(tm));
+ tm.tm_mday = 1;
+ tm.tm_year = 70;
+ localofs = mktime(&tm);
+
/* Skip day-name */
p = skipfws(date);
if (!isdigit(*p)) {
@@ -246,7 +250,9 @@
if (*(skipfws(p + 5)))
return;
- then = mktime(&tm); /* mktime appears to ignore the GMT offset, stupidly */
+ /* No way to convert to a time_t and honour tm_gmtoff; we have to
+ do the evil trick by subtracting the local offset */
+ then = mktime(&tm) - localofs;
if (then == -1)
return;
--
dwmw2
^ permalink raw reply
* Re: Date handling.
From: Russ Allbery @ 2005-04-24 6:43 UTC (permalink / raw)
To: git
In-Reply-To: <1114324729.3419.78.camel@localhost.localdomain>
David Woodhouse <dwmw2@infradead.org> writes:
> I don't think we want to be in the business of counting leap seconds; we
> need to let the system do it. I don't much like setting TZ to UTC though
> -- how about we use your test case to find the offset and subtract that?
> Does this work?
Nope, daylight savings time breaks this, since you may or may not be in
the same time zone on January 1st as you are at the current time.
However, you don't need to count leap seconds when you implement your own
mktime, since mktime doesn't have to take leap seconds into account. Unix
timestamps, unless you're using TAI, don't include leap seconds.
--
Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>
^ permalink raw reply
* Re: [ANNOUNCE] git-pasky-0.7
From: Petr Baudis @ 2005-04-24 7:14 UTC (permalink / raw)
To: Paul Jackson; +Cc: git
In-Reply-To: <20050423205847.7758bfaa.pj@sgi.com>
Dear diary, on Sun, Apr 24, 2005 at 05:58:47AM CEST, I got a letter
where Paul Jackson <pj@sgi.com> told me that...
> 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.
FWIW, excerpt from the README:
===
If you want to start out new project, do (IN NEW DIRECTORY)
git init
and if you want to have a look at someone else's project, do
git init URL
(your working directory will be by default tracking branch 'origin').
===
(although I'm not sure why did I write it when apparently noone bothers
to read it anyway ;-)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ 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