Git development
 help / color / mirror / Atom feed
* Re: unseeking?
From: Petr Baudis @ 2005-04-24 16:05 UTC (permalink / raw)
  To: Zack Brown; +Cc: git
In-Reply-To: <20050424154754.GA11094@tumblerings.org>

Dear diary, on Sun, Apr 24, 2005 at 05:47:54PM CEST, I got a letter
where Zack Brown <zbrown@tumblerings.org> told me that...
> Hi,

Hi,

> I've been pulling cogito and the kernel, and just fumbling around trying to
> learn the tool. My latest cogito is version 0.7, tracking
> 
> pasky   rsync://rsync.kernel.org/pub/scm/cogito/cogito.git
> linus   rsync://www.kernel.org/pub/linux/kernel/people/torvalds/git.git
> 
> I have many questions.
> 
> 1) I saw some discussion of 'seek' as a way to get to an earlier version of a
> tree; so I tried it on my own test directory. I 'seek'ed to the first patch, and
> it worked - but now all I have is that very early version of my test directory.
> All subsequent changes are apparently gone. How can I seek back to the most
> recent state of the dir?

git seek, without any arguments.

Perhaps we should prohibit absence of arguments and add 'unseek'?

> 2) How can I 'check out' my local repository? i.e. I want to pretend to be
> two developers, one of whom wants to grab a copy of the project leader's work. I
> tried things like:
> 
> mkdir mygitdir2
> git init ../mygitdir
> 
> where mydir is my test git repository. This didn't work. I tried rephrasing the

Actually, this _would_ work:

	git init ../mygitdir/.git

Then, you would need to git pull to get the latest changes.

> command with an rsync url:
> 
> git init rsync://home/zbrown/site/gitstuff/mygitdir
> 
> but that didn't work either. It just said:
> 
> defaulting to local storage area
> rsync: getaddrinfo: home 873: Name or service not known
> rsync error: error in socket IO (code 10) at clientserver.c(94)
> gitpull.sh: unable to get the head pointer of branch master
> gitinit.sh: pull failed

git fork seconddeveloper ../mygitdir

> 3) How can I do a rename with cogito? There doesn't seem to be a rename command,
> and if I manually do a mv and 'git add', I can commit the result, but what
> actually happened? Did I really do a rename? Is the file's history preserved?
> How can I verify these things?

Git does not record renames, and neither does Cogito (for now).

> 4) fork, seek, tag, and track are a little mysterious to me. I can guess at what
> these things do in general, but the specifics are confusing, and the README is a
> little vague.

Try head git*.sh. ;-)

> 5) I'm a little confused about how to use a git repository to follow along with
> a project. I have no problem pulling the latest version, but I'm interested in
> generating changelogs for specific releases like 2.6.12-rc3. How can I
> 
>    a) identify the proper 'c83b95297c2a6336c2007548f909769e0862b509' string that
>    represents the release I'm interested in

Assuming that it is tagged, just do

	commit-id linux-2.6.12-rc3

or whatever the tag name is. From Cogito perspective, you can use the
symbolic name anywhere you would use the proper string.

There is also tree-id and parent-id, with same usage.

>    b) generate the changelog between that version and the previous one,
>    once I've solved (a)

	git log previous that

Any ideas how to improve the user interface further are deeply
appreciated. (However please note that it is going to undergo a big
change in an hour or two, so you might want to postpone them until
that.)

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor

^ permalink raw reply
* unseeking?
From: Zack Brown @ 2005-04-24 15:47 UTC (permalink / raw)
  To: git

Hi,

I've been pulling cogito and the kernel, and just fumbling around trying to
learn the tool. My latest cogito is version 0.7, tracking

pasky   rsync://rsync.kernel.org/pub/scm/cogito/cogito.git
linus   rsync://www.kernel.org/pub/linux/kernel/people/torvalds/git.git

I have many questions.

1) I saw some discussion of 'seek' as a way to get to an earlier version of a
tree; so I tried it on my own test directory. I 'seek'ed to the first patch, and
it worked - but now all I have is that very early version of my test directory.
All subsequent changes are apparently gone. How can I seek back to the most
recent state of the dir?

2) How can I 'check out' my local repository? i.e. I want to pretend to be
two developers, one of whom wants to grab a copy of the project leader's work. I
tried things like:

mkdir mygitdir2
git init ../mygitdir

where mydir is my test git repository. This didn't work. I tried rephrasing the
command with an rsync url:

git init rsync://home/zbrown/site/gitstuff/mygitdir

but that didn't work either. It just said:

defaulting to local storage area
rsync: getaddrinfo: home 873: Name or service not known
rsync error: error in socket IO (code 10) at clientserver.c(94)
gitpull.sh: unable to get the head pointer of branch master
gitinit.sh: pull failed

3) How can I do a rename with cogito? There doesn't seem to be a rename command,
and if I manually do a mv and 'git add', I can commit the result, but what
actually happened? Did I really do a rename? Is the file's history preserved?
How can I verify these things?

4) fork, seek, tag, and track are a little mysterious to me. I can guess at what
these things do in general, but the specifics are confusing, and the README is a
little vague.

5) I'm a little confused about how to use a git repository to follow along with
a project. I have no problem pulling the latest version, but I'm interested in
generating changelogs for specific releases like 2.6.12-rc3. How can I

   a) identify the proper 'c83b95297c2a6336c2007548f909769e0862b509' string that
   represents the release I'm interested in

   b) generate the changelog between that version and the previous one,
   once I've solved (a)

Many thanks,
Zack





-- 
Zack Brown

^ permalink raw reply
* gitweb.pl
From: Kay Sievers @ 2005-04-24 15:23 UTC (permalink / raw)
  To: git; +Cc: Greg KH, H. Peter Anvin

We have a new improved version of the git web-interface:
  http://ehlo.org/~kay/gitweb.pl

You can download it from:
  ftp://ehlo.org/gitweb.pl


gitweb exports now a simple RSS feed: :)
  http://ehlo.org/~kay/gitweb.pl/linux-2.6/rss

gitweb accepts now a whole path instead of only a name to a project.
Example:
  ftp://kernel.org/pub/scm/linux/kernel/git/gregkh/usb-2.6.git/
gitweb-URL:
  http://kernel.org/cgi-bin/gitweb.pl/pub/scm/linux/kernel/git/gregkh/usb-2.6.git/

Thanks,
Kay


^ permalink raw reply
* Adding quilt functionality to git?
From: Roman Zippel @ 2005-04-24 15:23 UTC (permalink / raw)
  To: git

Hi,

Currently git reproduces the old bk work flow and with this it also has 
the same problems and makes quilt still a very useful tool, so how about 
adding quilt functionality to git?

What basically would be needed is adding a new file type 'series' which 
basically has a contents like this:

top	<sha1>
foo.patch	<sha1>
bar.patch	<sha1>

The sha1 points to commit objects. Next we need a new merge operator, 
which basically does "merge differences between tree1 and tree2 into 
another tree" (without renames this is quite simple, basically just 
calling diff3).
With these two things one can implement quilt on top of git. A push of 
foo.patch would merge its changes into the current working tree. A refresh 
would generate a diff between top and current working tree and stores it 
as the new foo.patch.
This would also allow cherry picking by simply editing the series file. 
E.g. Andrew could merge other patches simply by adding a few lines to his 
series file and run a few updates with an url where to get the missing 
changes from. When he wants to send patches to Linus, he just needs to 
extract a new series file and send it off.

git is currently a bit too much moving target to do this myself right now, 
but maybe someone else wants to do this. As inspiration I appended below 
a simple script to implement something similiar with quilt. It basically 
does a 3-way-merge when updating the patches to a new source tree, so one 
basically uses it like this:

cp -al <src> <dest>
<update dest>
qm <src> <dest>

If there are any conflicts, it just calls kdiff3 or diff3+vi.
With git now one could skip the copy step and simply change the top sha1 
and pull the old files out of the cache.

Personally I think this merging style is more suited for the kernel 
development style then the bk merging method. There might be of course 
other problems, but due the simple design of git it would be a lot easier
to try out new things compared to other traditional SCM.

bye, Roman

---

#!/bin/bash

if [ $# -ne 2 ]; then
	echo "Usage: $0 <src> <dst>"
	exit
fi

DIR1=$1
test ${DIR1:0:1} = / || DIR1=$PWD/$DIR1
DIR2=$2
test ${DIR2:0:1} = / || DIR2=$PWD/$DIR2

if [ ! -d $DIR1/patches -o ! -d $DIR2 ]; then
	echo "Invalid arguments"
	exit
fi

type kdiff3 >& /dev/null && test -n "$DISPLAY" && use_kdiff=1

if [ -e $DIR2/patches ]; then
	time=`date +.%y%m%d.%H%M%S`
	echo "Backing up old patches as patches$time"
	mv $DIR2/patches $DIR2/patches$time
fi

cd $DIR1
cp -a patches $DIR2
quilt top > /dev/null && quilt pop -qa
cd $DIR2
while [ -n "`quilt next`" ]; do
	p=`quilt next`
	echo "Merging patch $p"
	rej=`quilt push | sed -n 's/.* -- rejects in file \(.*\)$/\1/p'`
	if [ -n "$rej" ]; then
		echo "need to resolve conflicts in $rej"
		cd $DIR1
		quilt push -q $p
		cd $DIR2
		for m in $rej; do
			cp $m $m.rq.cur
		done
		quilt push -f
		for m in $rej; do
			if [ "$use_kdiff" -eq 1 ]; then
				kdiff3 -m -o $m \
					-L "$m (`quilt prev`)" \
					-L "$m ($p)" \
					-L "$m (current)" \
					$DIR1/.pc/$p/$m $DIR1/$m $m.rq.cur
			else
				diff3 -mE > $m \
					-L "$m (current)" \
					-L "$m (`quilt prev`)" \
					-L "$m ($p)" \
					$m.rq.cur $DIR1/.pc/$p/$m $DIR1/$m
				${EDITOR:-vi} $m
			fi
			if cmp -s $m.rq.cur $m; then
				echo "No changes"
				quilt remove $m
			fi
			rm $m.rq.cur
		done
		if [ -z "`quilt files`" ]; then
			echo "Empty patch"
			quilt pop -qf
			quilt delete $p
		else
			quilt ref
		fi
	fi
done


^ permalink raw reply
* [RFC] updates for git-pull-script
From: James Bottomley @ 2005-04-24 14:14 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: git

The current git-pull-script has several behaviours that always trip me
up

1) when pulling from a local tree, you have to remember to append
the .git/ directory to the base
2) It always tries to checkout the files ... this drives me nuts since I
don't have a lot of space on my laptop so I keep most trees empty.
3) It doesn't attempt a more sophisticated merge.  The SCSI tree seems
to be the one that always has added or removed files.  Since I think
git-merge-one-file-script is reasonably trustworthy, I made automatic
merges using it one of the pull features.
4) It doesn't remember the old head.  This is useful for unpulling
(pruning back to if the merge misfires) or simply seeing the changes
between the old and new heads.

The attached addresses all these points.  It's what I use, but since
others may prefer the original behaviour, I'm sending it as a straw
horse.

James

--- a/git-pull-script
+++ b/git-pull-script
@@ -3,9 +3,17 @@
 # use "$1" or something in a real script, this 
 # just hard-codes it.
 #
-merge_repo=$1
+merge_repo="$1"
+
+[  -d .git ] || die
+
+if [ -d "$merge_repo" -a -d "$merge_repo/.git" ]; then
+	merge_repo="$merge_repo/.git"
+fi
 
 rm -f .git/MERGE_HEAD
+rm -f .git/OLD_HEAD
+cp .git/HEAD .git/OLD_HEAD
 
 echo "Getting object database"
 rsync -avz --ignore-existing $merge_repo/objects/. .git/objects/.
@@ -32,17 +40,22 @@ if [ "$common" == "$merge_head" ]; then
 fi
 if [ "$common" == "$head" ]; then
 	echo "Updating from $head to $merge_head."
-	echo "Destroying all noncommitted data!"
-	echo "Kill me within 3 seconds.."
-	sleep 3
-	read-tree -m $merge_tree && checkout-cache -f -a && update-cache --refresh
+	echo "Reading the current tree"
+	read-tree -m $merge_tree || exit 1
 	echo $merge_head > .git/HEAD
 	exit 0
 fi
 echo "Trying to merge $merge_head into $head"
 read-tree -m $common_tree $head_tree $merge_tree
-result_tree=$(write-tree) || exit 1
-result_commit=$(echo "Merge $merge_repo" | commit-tree $result_tree -p $head -p $merge_head)
+merge_msg="Merge $merge_repo"
+result_tree=$(write-tree 2>/dev/null)
+if [ $? -ne 0 ]; then
+	echo "Simple merge failed, trying Automatic merge"
+	merge-cache git-merge-one-file-script -a
+	merge_msg="Automatic merge of $merge_repo"
+	result_tree=$(write-tree) || exit 1
+fi
+result_commit=$(echo $merge_msg | commit-tree $result_tree -p $head -p $merge_head)
 echo "Committed merge $result_commit"
 echo $result_commit > .git/HEAD
-checkout-cache -f -a && update-cache --refresh
+#checkout-cache -f -a && update-cache --refresh



^ permalink raw reply
* [PATCH] make git-prune-script actually work
From: James Bottomley @ 2005-04-24 13:58 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: git

I find this script very useful to get back to where I started from after
test merges, and also for cloning trees from a non-current base.  The
functionality is altered so it now takes an optional commit argument
(and a -q flag to make it be quiet).

Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>

--- a/git-prune-script
+++ b/git-prune-script
@@ -1,2 +1,23 @@
 #!/bin/sh
-fsck-cache --unreachable $(cat .git/HEAD ) | grep unreachable | cut -d' ' -f3 | sed 's:^\(..\):.git/objects/\1/:' | xargs rm
+verbose=true
+case $1 in 
+	-q)	verbose=false
+		shift;;
+esac
+head=$1
+if [ -z "$head" ]; then
+	head=$(cat .git/HEAD)
+fi
+f=$(fsck-cache --unreachable $head | awk '/^unreachable /{print $3}'| sed 's:^\(..\):.git/objects/\1/:')
+if [ -z "$f" ]; then
+	echo "Nothing to remove"
+	exit 0
+fi
+
+for g in $f; do
+	if $verbose; then
+		echo $g
+	fi
+	rm -f $g
+done
+echo $head > .git/HEAD



^ permalink raw reply
* Re: Git cancel work
From: Dan Holmsand @ 2005-04-24 13:11 UTC (permalink / raw)
  To: git
In-Reply-To: <Pine.LNX.4.62.0504240859210.27230@mirrorlynx.com>

Dan Weber wrote:
> 
> Why does it take so ridiculously long then?

Perhaps because you're using an older version of git-pasky? Newer 
versions use read-tree -m, which speeds up git cancel by several orders 
of magnitude for me.

Btw. gitdiff.sh and gitseek.sh are still using read-tree without "-m", 
so they are still very slow.

For exampel, try "git diff -p" on the kernel. Compare with plain "git diff".

/dan


^ permalink raw reply
* [PATCH] Cleanup sha1_file_directory initialization
From: Jonas Fonseca @ 2005-04-24 13:07 UTC (permalink / raw)
  To: torvalds; +Cc: git

Use get_object_directory() when initializing sha1_file_directory
and make sha1_file_name() work on the global.

Signed-off-by: Jonas Fonseca <fonseca@diku.dk>

---
Actually the initiailzation in ls-tree.c can be removed because call to
list() will end up in sha1_file_name() which will do it.

commit 6a06750a72231eaf285f9fbd2bcb88a39b699679
tree bec1c4178131a67de1fa639a274b13adec21c1e5
parent 32141512fff2d42c0233c07610db866926c89a75
author Jonas Fonseca <jonas@cvalda.(none)> 1114346881 +0200
committer Jonas Fonseca <jonas@cvalda.(none)> 1114346881 +0200

Index: ls-tree.c
===================================================================
--- 31e9af73983d640090508b06784ef7db4816c957/ls-tree.c  (mode:100644 sha1:bd99f9ac7b2d6dc23c1ec7d8f03877c20afec63f)
+++ bec1c4178131a67de1fa639a274b13adec21c1e5/ls-tree.c  (mode:100644 sha1:b630f69d8430f18f52799cf32787059b4427f3e8)
@@ -104,9 +104,8 @@ int main(int argc, char **argv)
 		usage(ls_tree_usage);
 	if (get_sha1_hex(argv[1], sha1) < 0)
 		usage(ls_tree_usage);
-	sha1_file_directory = getenv(DB_ENVIRONMENT);
-	if (!sha1_file_directory)
-		sha1_file_directory = DEFAULT_DB_ENVIRONMENT;
+
+	sha1_file_directory = get_object_directory();
 	if (list(sha1) < 0)
 		die("list failed");
 	return 0;
Index: read-cache.c
===================================================================
--- 31e9af73983d640090508b06784ef7db4816c957/read-cache.c  (mode:100644 sha1:f67aceb6b12f6d9cadf6a80bb1d33cf1bcd7f619)
+++ bec1c4178131a67de1fa639a274b13adec21c1e5/read-cache.c  (mode:100644 sha1:deb60df8cbb4f9ec8367f4ff96c62e383b5699e8)
@@ -183,9 +183,7 @@ int read_cache(void)
 	if (active_cache)
 		return error("more than one cachefile");
 	errno = ENOENT;
-	sha1_file_directory = getenv(DB_ENVIRONMENT);
-	if (!sha1_file_directory)
-		sha1_file_directory = DEFAULT_DB_ENVIRONMENT;
+	sha1_file_directory = get_object_directory();
 	if (access(sha1_file_directory, X_OK) < 0)
 		return error("no access to SHA1 file directory");
 	fd = open(get_index_file(), O_RDONLY);
Index: sha1_file.c
===================================================================
--- 31e9af73983d640090508b06784ef7db4816c957/sha1_file.c  (mode:100644 sha1:97a515a073fec5870dfaaa279868ce9330853d3d)
+++ bec1c4178131a67de1fa639a274b13adec21c1e5/sha1_file.c  (mode:100644 sha1:94ab1119383a00a821254c3454fe349845027346)
@@ -71,8 +71,11 @@ char *sha1_file_name(const unsigned char
 	static char *name, *base;
 
 	if (!base) {
-		char *sha1_file_directory = getenv(DB_ENVIRONMENT) ? : DEFAULT_DB_ENVIRONMENT;
-		int len = strlen(sha1_file_directory);
+		int len;
+
+		if (!sha1_file_directory)
+			sha1_file_directory = get_object_directory();
+		len = strlen(sha1_file_directory);
 		base = malloc(len + 60);
 		memcpy(base, sha1_file_directory, len);
 		memset(base+len, 0, 60);

-- 
Jonas Fonseca

^ permalink raw reply
* Re: Git cancel work
From: Dan Weber @ 2005-04-24 13:04 UTC (permalink / raw)
  To: Petr Baudis; +Cc: Git Mailing List
In-Reply-To: <20050424130028.GG1507@pasky.ji.cz>



On Sun, 24 Apr 2005, Petr Baudis wrote:

> Dear diary, on Sun, Apr 24, 2005 at 02:59:31PM CEST, I got a letter
> where Dan Weber <dan@mirrorlynx.com> told me that...
>> Why does it take so ridiculously long then?
>
> That's strange.
>
> Could you show some time comparisons between the current and your
> approaches? (Please make sure the cache condition is about the same for
> both tests; it makes many orders of magnitude difference.)
>

No need.  Go try running it on the linux kernel. The command git cancel.

Dan
> -- 
> 				Petr "Pasky" Baudis
> Stuff: http://pasky.or.cz/
> C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
>

^ permalink raw reply
* Re: Git cancel work
From: Petr Baudis @ 2005-04-24 13:00 UTC (permalink / raw)
  To: Dan Weber; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.62.0504240859210.27230@mirrorlynx.com>

Dear diary, on Sun, Apr 24, 2005 at 02:59:31PM CEST, I got a letter
where Dan Weber <dan@mirrorlynx.com> told me that...
> Why does it take so ridiculously long then?

That's strange.

Could you show some time comparisons between the current and your
approaches? (Please make sure the cache condition is about the same for
both tests; it makes many orders of magnitude difference.)

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor

^ permalink raw reply
* Re: Git cancel work
From: Dan Weber @ 2005-04-24 12:59 UTC (permalink / raw)
  To: Petr Baudis; +Cc: Git Mailing List
In-Reply-To: <20050424124930.GE1507@pasky.ji.cz>


Why does it take so ridiculously long then?

Dan

On Sun, 24 Apr 2005, Petr Baudis wrote:

> Dear diary, on Sun, Apr 24, 2005 at 06:34:44AM CEST, I got a letter
> where Dan Weber <dan@mirrorlynx.com> told me that...
>> 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.
>
> But that is what checkout-cache -f -a does:
>
>        if (!stat(path, &st)) {
>                unsigned changed = cache_match_stat(ce, &st);
>                if (!changed)
>                        return 0;
>
> in checkout_entry().
>
> -- 
> 				Petr "Pasky" Baudis
> Stuff: http://pasky.or.cz/
> C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
>

^ permalink raw reply
* Re: Git cancel work
From: Petr Baudis @ 2005-04-24 12:49 UTC (permalink / raw)
  To: Dan Weber; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.62.0504240033230.1980@mirrorlynx.com>

Dear diary, on Sun, Apr 24, 2005 at 06:34:44AM CEST, I got a letter
where Dan Weber <dan@mirrorlynx.com> told me that...
> 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.

But that is what checkout-cache -f -a does:

        if (!stat(path, &st)) {
                unsigned changed = cache_match_stat(ce, &st);
                if (!changed)
                        return 0;

in checkout_entry().

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor

^ permalink raw reply
* Re: git-changes-script to show inter tree changes
From: James Bottomley @ 2005-04-24 12:48 UTC (permalink / raw)
  To: Petr Baudis; +Cc: Linus Torvalds, git
In-Reply-To: <20050424123621.GB1507@pasky.ji.cz>

On Sun, 2005-04-24 at 14:36 +0200, Petr Baudis wrote:
> Aha,  I thought this is based on the current gitlog.sh, sorry.

I think it is ... such a beast briefly appeared in the git tree, which
is where I got the skeleton from.

> For -R, you'd probably do
> 
> 	git log yourtree theothertree
> 
> (the range of changes between yourtree and theothertree, literally).

As long as that's a true what's in the other tree only, -L should appear
if you simply reverse the arguments.

James



^ permalink raw reply
* Re: [PATCH] make file merging respect permissions
From: James Bottomley @ 2005-04-24 12:46 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.

Just to get closure on this, I went over all the parts of patch
generation, and the culprit turns out to be emacs.  Apparently its diff
mode (which I never thought to investigate how to use) does these re-
writes ... no idea why, but the problem goes away if I strip out the
extraneous pieces in fundamental-mode.  It's never given me this trouble
before ... I think the diff I'm producing must be confusing it somehow.

James



^ permalink raw reply
* Re: [PATCH] Add -u option to diff-cache to show UNCHANGED files
From: Petr Baudis @ 2005-04-24 12:43 UTC (permalink / raw)
  To: Andreas Gal; +Cc: Linus Torvalds, Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0504232022180.4690@sam.ics.uci.edu>

Dear diary, on Sun, Apr 24, 2005 at 05:28:17AM CEST, I got a letter
where Andreas Gal <gal@uci.edu> told me that...
> 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>

I don't think this fits to diff-cache (since the output is basically
nonsensical apart of the filename, right?). Maybe rather show-files?

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor

^ permalink raw reply
* Re: git-changes-script to show inter tree changes
From: Petr Baudis @ 2005-04-24 12:36 UTC (permalink / raw)
  To: James Bottomley; +Cc: Linus Torvalds, git
In-Reply-To: <1114306762.4805.3.camel@mulgrave>

Dear diary, on Sun, Apr 24, 2005 at 03:39:22AM CEST, I got a letter
where James Bottomley <James.Bottomley@SteelEye.com> told me that...
> 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.

Aha,  I thought this is based on the current gitlog.sh, sorry.

> > 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.

For -R, you'd probably do

	git log yourtree theothertree

(the range of changes between yourtree and theothertree, literally).

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor

^ permalink raw reply
* Re: [PATCH] PPC assembly implementation of SHA1
From: Wayne Scott @ 2005-04-24 12:04 UTC (permalink / raw)
  To: Paul Mackerras; +Cc: linux, git
In-Reply-To: <17003.9009.226712.220822@cargo.ozlabs.ibm.com>

_The_ book on expression rewriting tricks like this, especially for
the PPC, is "Hacker's Delight" by Henry Warren.  Great reading!!!
http://www.hackersdelight.org/

-Wayne

On 4/23/05, Paul Mackerras <paulus@samba.org> wrote:
> 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.
> -
> 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: [ANNOUNCE] git-pasky-0.7
From: Junio C Hamano @ 2005-04-24 10:52 UTC (permalink / raw)
  To: Petr Baudis; +Cc: Linus Torvalds, git
In-Reply-To: <20050424005923.GA8859@pasky.ji.cz>

I was reviewing the differences in C-part between what is in
git-pasky and Linus tree.  By the way, I finally decided to look
at the upper layer again, now you switched to dircache based
implementation.  It looks like a good start.  Anyway, this
message is about purely C part.

First some nitpicks and possible bugs.

 - The remove_file_from_cache() function in read-cache.c was
   fixed for quite some time ago in the Linus tree to let users
   resolve unmerged path by "update-cache --remove".  You do not
   seem to have this part (the diff is reversed) [*R1*].  If this is
   not a merge oversight I'd like to know why?

 - show-diff exiting non-zero when unmatched paths are specified
   does not make much sense.  diff traditionally exits non-zero
   when differences are found.  Are you using this exit status
   to see if entries on the command line are in the dircache?
   If so that is not show-diff's job but probably belongs to
   show-files [*R2*].

Comments, commends and requests.

 - The -t option you have in show-files sounds generally
   useful [*R3*].  Could you push this upstream?

 - There are many small changes that adds free() and close(fd)
   and from my cursory looking they all look reasonable fixes.
   If you are confident with these, could please also push them
   upstream?

Thanks.

[References]

*R1*

This hunk should be reverted from Pasky if there is no good reason.

--- git.linus/read-cache.c	2005-04-24 00:05:02.000000000 -0700
+++ git.pasky/read-cache.c	2005-04-24 00:49:00.000000000 -0700
@@ -99,9 +99,7 @@
 int remove_file_from_cache(char *path)
 {
 	int pos = cache_name_pos(path, strlen(path));
-	if (pos < 0)
-		pos = -pos-1;
-	while (pos < active_nr && !strcmp(active_cache[pos]->name, path))
+	if (pos >= 0)
 		remove_entry_at(pos);
 	return 0;
 }

*R2*

This hunk should be reverted from Pasky if there is no good reason.

--- git.linus/show-diff.c	2005-04-24 00:05:02.000000000 -0700
+++ git.pasky/show-diff.c	2005-04-24 00:49:00.000000000 -0700
@@ -126,6 +127,7 @@
 	int machine_readable = 0;
 	int reverse = 0;
 	int entries = read_cache();
+	int matched = 0;
 	int i;
 
 	while (1 < argc && argv[1][0] == '-') {
@@ -161,6 +163,7 @@
 		if (1 < argc &&
 		    ! matches_pathspec(ce, argv+1, argc-1))
 			continue;
+		matched++;
 
 		if (ce_stage(ce)) {
 			if (machine_readable)
@@ -192,10 +195,8 @@
 			continue;
 		if (!machine_readable)
 			printf("%s: %s\n", ce->name, sha1_to_hex(ce->sha1));
-		else {
-			printf("%s %s%c", sha1_to_hex(ce->sha1), ce->name, 0);
-			continue;
-		}
+		else
+			printf("M %s %s%c", sha1_to_hex(ce->sha1), ce->name, 0);
 		if (silent)
 			continue;
 
@@ -208,5 +209,8 @@
 					 reverse);
 		free(old);
 	}
+
+	if (1 < argc && !matched)
+		return 1;
 	return 0;
 }

*R3*

This should be pushed upstream.

--- git.linus/show-files.c	2005-04-24 00:05:02.000000000 -0700
+++ git.pasky/show-files.c	2005-04-24 00:49:00.000000000 -0700
@@ -17,6 +17,11 @@
 static int show_unmerged = 0;
 static int line_terminator = '\n';
 
+static const char *tag_cached = "";
+static const char *tag_unmerged = "";
+static const char *tag_removed = "";
+static const char *tag_other = "";
+
 static const char **dir;
 static int nr_dir;
 static int dir_alloc;
@@ -107,7 +112,7 @@
 	}
 	if (show_others) {
 		for (i = 0; i < nr_dir; i++)
-			printf("%s%c", dir[i], line_terminator);
+			printf("%s%s%c", tag_other, dir[i], line_terminator);
 	}
 	if (show_cached | show_stage) {
 		for (i = 0; i < active_nr; i++) {
@@ -115,10 +120,13 @@
 			if (show_unmerged && !ce_stage(ce))
 				continue;
 			if (!show_stage)
-				printf("%s%c", ce->name, line_terminator);
+				printf("%s%s%c",
+				       ce_stage(ce) ? tag_unmerged : tag_cached,
+				       ce->name, line_terminator);
 			else
 				printf(/* "%06o %s %d %10d %s%c", */
-				       "%06o %s %d %s%c",
+				       "%s %06o %s %d %s%c",
+				       ce_stage(ce) ? tag_unmerged : tag_cached,
 				       ntohl(ce->ce_mode),
 				       sha1_to_hex(ce->sha1),
 				       ce_stage(ce),
@@ -132,7 +140,7 @@
 			struct stat st;
 			if (!stat(ce->name, &st))
 				continue;
-			printf("%s%c", ce->name, line_terminator);
+			printf("%s%s%c", tag_removed, ce->name, line_terminator);
 		}
 	}
 	if (show_ignored) {
@@ -151,6 +159,13 @@
 			line_terminator = 0;
 			continue;
 		}
+		if (!strcmp(arg, "-t")) {
+			tag_cached = "H ";
+			tag_unmerged = "M ";
+			tag_removed = "R ";
+			tag_other = "? ";
+			continue;
+		}
 
 		if (!strcmp(arg, "--cached")) {
 			show_cached = 1;
@@ -179,7 +194,7 @@
 			continue;
 		}
 
-		usage("show-files [-z] (--[cached|deleted|others|ignored|stage])*");
+		usage("show-files [-z] [-t] (--[cached|deleted|others|ignored|stage])*");
 	}
 
 	/* With no flags, we default to showing the cached files */


*R4*

These leak fixes look reasonable from cursory looking.  If you
are confident, please push them upstream.

--- git.linus/checkout-cache.c	2005-04-24 00:05:02.000000000 -0700
+++ git.pasky/checkout-cache.c	2005-04-24 00:49:00.000000000 -0700
@@ -48,6 +48,7 @@
 		buf[len] = 0;
 		mkdir(buf, 0755);
 	}
+	free(buf);
 }
 
 static int create_file(const char *path, unsigned int mode)
@@ -75,6 +76,8 @@
 
 	new = read_sha1_file(ce->sha1, type, &size);
 	if (!new || strcmp(type, "blob")) {
+		if (new)
+			free(new);
 		return error("checkout-cache: unable to read sha1 file of %s (%s)",
 			path, sha1_to_hex(ce->sha1));
 	}


--- git.linus/ls-tree.c	2005-04-24 00:05:02.000000000 -0700
+++ git.pasky/ls-tree.c	2005-04-24 00:49:00.000000000 -0700
@@ -77,6 +77,7 @@
 	if (!buffer)
 		die("unable to read sha1 file");
 	list_recursive(buffer, "tree", size, NULL);
+	free(buffer);
 	return 0;
 }
 

--- git.linus/read-tree.c	2005-04-24 00:05:02.000000000 -0700
+++ git.pasky/read-tree.c	2005-04-24 00:49:00.000000000 -0700
@@ -11,11 +11,14 @@
 {
 	void *buffer;
 	unsigned long size;
+	int ret;
 
 	buffer = read_tree_with_tree_or_commit_sha1(sha1, &size, 0);
 	if (!buffer)
 		return -1;
-	return read_tree(buffer, size, stage);
+	ret = read_tree(buffer, size, stage);
+	free(buffer);
+	return ret;
 }
 
 static char *lockfile_name;


--- git.linus/rev-tree.c	2005-04-24 00:05:02.000000000 -0700
+++ git.pasky/rev-tree.c	2005-04-24 00:49:00.000000000 -0700
@@ -56,10 +56,10 @@
 	struct commit_list *parents;
 	struct commit *obj = lookup_commit(sha1);
 
-	if (obj->object.parsed)
+	if (obj && obj->object.parsed)
 		return;
-
-	parse_commit(obj);
+	if (!obj || parse_commit(obj))
+		die("unable to parse commit (%s)", sha1_to_hex(sha1));
 	
 	parents = obj->parents;
 	while (parents) {


--- git.linus/show-diff.c	2005-04-24 00:05:02.000000000 -0700
+++ git.pasky/show-diff.c	2005-04-24 00:49:00.000000000 -0700
@@ -100,6 +100,7 @@
 		return;
 	}
 	show_differences("/dev/null", ce->name, old, size, reverse);
+	free(old);
 }
 
 static const char *show_diff_usage = "show-diff [-q] [-s] [-z] [paths...]";


* These all look genuine leak fixes.  If applicable to Linus tree please
  push them upstream.

--- git.linus/checkout-cache.c	2005-04-24 00:05:02.000000000 -0700
+++ git.pasky/checkout-cache.c	2005-04-24 00:49:00.000000000 -0700
@@ -48,6 +48,7 @@
 		buf[len] = 0;
 		mkdir(buf, 0755);
 	}
+	free(buf);
 }
 
 static int create_file(const char *path, unsigned int mode)
@@ -75,6 +76,8 @@
 
 	new = read_sha1_file(ce->sha1, type, &size);
 	if (!new || strcmp(type, "blob")) {
+		if (new)
+			free(new);
 		return error("checkout-cache: unable to read sha1 file of %s (%s)",
 			path, sha1_to_hex(ce->sha1));
 	}


--- git.linus/ls-tree.c	2005-04-24 00:05:02.000000000 -0700
+++ git.pasky/ls-tree.c	2005-04-24 00:49:00.000000000 -0700
@@ -77,6 +77,7 @@
 	if (!buffer)
 		die("unable to read sha1 file");
 	list_recursive(buffer, "tree", size, NULL);
+	free(buffer);
 	return 0;
 }
 
--- git.linus/read-tree.c	2005-04-24 00:05:02.000000000 -0700
+++ git.pasky/read-tree.c	2005-04-24 00:49:00.000000000 -0700
@@ -11,11 +11,14 @@
 {
 	void *buffer;
 	unsigned long size;
+	int ret;
 
 	buffer = read_tree_with_tree_or_commit_sha1(sha1, &size, 0);
 	if (!buffer)
 		return -1;
-	return read_tree(buffer, size, stage);
+	ret = read_tree(buffer, size, stage);
+	free(buffer);
+	return ret;
 }
 
 static char *lockfile_name;

--- git.linus/rev-tree.c	2005-04-24 00:05:02.000000000 -0700
+++ git.pasky/rev-tree.c	2005-04-24 00:49:00.000000000 -0700
@@ -56,10 +56,10 @@
 	struct commit_list *parents;
 	struct commit *obj = lookup_commit(sha1);
 
-	if (obj->object.parsed)
+	if (obj && obj->object.parsed)
 		return;
-
-	parse_commit(obj);
+	if (!obj || parse_commit(obj))
+		die("unable to parse commit (%s)", sha1_to_hex(sha1));
 	
 	parents = obj->parents;
 	while (parents) {

--- git.linus/sha1_file.c	2005-04-24 00:05:02.000000000 -0700
+++ git.pasky/sha1_file.c	2005-04-24 00:49:00.000000000 -0700
@@ -278,6 +278,7 @@
 
 	if (write(fd, compressed, size) != size)
 		die("unable to write file");
+	free(compressed);
 	close(fd);
 		
 	return 0;
@@ -295,8 +296,10 @@
 	if (fd < 0)
 		return -1;
 
-	if (fstat(fd, &st) < 0 || size != st.st_size)
+	if (fstat(fd, &st) < 0 || size != st.st_size) {
+		close(fd);
 		return -1;
+	}
 
 	map = mmap(NULL, size, PROT_READ, MAP_PRIVATE, fd, 0);
 	close(fd);


--- git.linus/show-diff.c	2005-04-24 00:05:02.000000000 -0700
+++ git.pasky/show-diff.c	2005-04-24 00:49:00.000000000 -0700
@@ -100,6 +100,7 @@
 		return;
 	}
 	show_differences("/dev/null", ce->name, old, size, reverse);
+	free(old);
 }
 
 static const char *show_diff_usage = "show-diff [-q] [-s] [-z] [paths...]";


--- git.linus/update-cache.c	2005-04-24 00:05:02.000000000 -0700
+++ git.pasky/update-cache.c	2005-04-24 00:49:00.000000000 -0700
@@ -104,6 +104,11 @@
 		close(fd);
 		return -1;
 	}
+	if (S_ISDIR(st.st_mode)) {
+		fprintf(stderr, "'%s' is a directory, ignoring\n", path);
+		close(fd);
+		return 0;
+	}
 	namelen = strlen(path);
 	size = cache_entry_size(namelen);
 	ce = malloc(size);
@@ -113,10 +118,15 @@
 	ce->ce_mode = create_ce_mode(st.st_mode);
 	ce->ce_flags = htons(namelen);
 
-	if (index_fd(ce->sha1, fd, &st) < 0)
+	if (index_fd(ce->sha1, fd, &st) < 0) {
+		free(ce);
 		return -1;
-
-	return add_cache_entry(ce, allow_add);
+	}
+	if (add_cache_entry(ce, allow_add)) {
+		free(ce);
+		return -1;
+	}
+	return 0;
 }
 
 static int match_data(int fd, void *buffer, unsigned long size)
@@ -141,7 +151,7 @@
 	if (fd >= 0) {
 		void *buffer;
 		unsigned long size;
-		char type[10];
+		char type[20];
 
 		buffer = read_sha1_file(ce->sha1, type, &size);
 		if (buffer) {
@@ -216,6 +226,9 @@
 			printf("%s: needs update\n", ce->name);
 			continue;
 		}
+		/* You can NOT just free active_cache[i] here, since it
+		 * might not be necessarily malloc()ed but can also come
+		 * from mmap(). */
 		active_cache[i] = new;
 	}
 }


^ permalink raw reply
* Re: [ANNOUNCE] git-pasky-0.7
From: Martin Schlemmer @ 2005-04-24 10:35 UTC (permalink / raw)
  To: Paul Jackson; +Cc: Daniel Barkalow, pasky, git
In-Reply-To: <20050423220236.26f834ee.pj@sgi.com>

[-- Attachment #1: Type: text/plain, Size: 695 bytes --]

On Sat, 2005-04-23 at 22:02 -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
> 

If you want a new directory that only goes to official 2.6.12-rc3, try:

    git fork linux-2.6.12-rc3 ../linux-2.6.12-rc3 a2755a80f40e5794ddc20e00f781af9d6320fafb

This will also share the object database, so only space for the checked
out files will be needed.


Cheers,

-- 
Martin Schlemmer


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply
* Re: [ANNOUNCE] git-pasky-0.7
From: Martin Schlemmer @ 2005-04-24  9:50 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Petr Baudis, git
In-Reply-To: <Pine.LNX.4.58.0504232044040.2344@ppc970.osdl.org>

[-- Attachment #1: Type: text/plain, Size: 494 bytes --]

On Sat, 2005-04-23 at 20:45 -0700, Linus Torvalds wrote:
> 
> 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.
> 

Thanks, thought it was something like this, but did not see a new
dependency in the README.


Thanks,

-- 
Martin Schlemmer


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply
* Re: Hash collision count
From: David Lang @ 2005-04-24  7:56 UTC (permalink / raw)
  To: Jeff Garzik; +Cc: Git Mailing List, Linus Torvalds
In-Reply-To: <426AAFC3.800@pobox.com>

On Sat, 23 Apr 2005, Jeff Garzik wrote:

> Ideally a hash + collision-count pair would make the best key, rather than 
> just hash alone.
>
> A collision -will- occur eventually, and it is trivial to avoid this problem:
>
> 	$n = 0
> 	attempt to store as $hash-$n
> 	if $hash-$n exists (unlikely)
> 		$n++
> 		goto restart
> 	key = $hash-$n
>
> Tangent-as-the-reason-I-bring-this-up:
>
> One of my long-term projects is an archive service, somewhat like Plan9's 
> venti:  a multi-server key-value database, with sha1 hash as the key.
>
> However, as the database grows into the terabyte (possibly petabyte) range, 
> the likelihood of a collision transitions rapidly from unlikely -> possible 
> -> likely.
>
> Since it is -so- simple to guarantee that you avoid collisions, I'm hoping 
> git will do so before the key structure is too ingrained.

Jeff, this can't work becouse you don't know what objects exist on other 
servers, in fact given the number of different repositories that will 
eventually exist the odds are good that when the colision occures it will 
be when object repositories get combined,

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: Git for redundant mail servers
From: David Lang @ 2005-04-24  7:45 UTC (permalink / raw)
  To: David Woodhouse; +Cc: jon, git
In-Reply-To: <1114322071.3419.68.camel@localhost.localdomain>

On Sun, 24 Apr 2005, David Woodhouse wrote:

> Date: Sun, 24 Apr 2005 15:54:30 +1000
> From: David Woodhouse <dwmw2@infradead.org>
> To: David Lang <david.lang@digitalinsight.com>
> Cc: jon@zeta.org.au, git@vger.kernel.org
> Subject: Re: Git for redundant mail servers
> 
> 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.

IMAP defines an offline mode, I haven't looked at it, but it would have to 
deal with this in some way.

> 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.

good point.

there are two things that will cause competing commits of full mail 
messages.

1. new mail arriving from the Net (probably via SMTP/LMTP

2. Client actions

2a. direct posting of messages (most common for FCC folders)

2b. copying of messages between folders

2c. flag changes

2d. expunging 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)
>
> 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".

I'm familiar with Cyrus which has a similar concept of mail storage, but 
I'm only vaguely familar with maildir (I don't know all the details of how 
it does things)

the key question to answer is are you trying to just replicate maildir 
underneith the normal programs that use it?, or are you trying to have a 
replicated mailserver and are willing to modify the software as well as 
fiddle with the storage?

if you are after the first then you have to do everything at the 
filesystem level, if you are after the second it's amuch easier job, but 
you need to think carefully up front to decide what capabilities you need 
the software to have and pick the right software to start modifying.

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: [GIT PATCH] Selective diff-tree
From: Junio C Hamano @ 2005-04-24  7:40 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: David Woodhouse, Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0504232202340.19877@ppc970.osdl.org>

Is either of you planning to do the same for diff-cache?


^ permalink raw reply
* Re: [ANNOUNCE] git-pasky-0.7
From: Paul Jackson @ 2005-04-24  7:20 UTC (permalink / raw)
  To: Petr Baudis; +Cc: git
In-Reply-To: <20050424071413.GA578@pasky.ji.cz>

> (although I'm not sure why did I write it when apparently noone bothers
> to read it anyway ;-)

I read it - that's how I got the rest of the steps.

I did not recognize that what I wanted to do next was:

> and if you want to have a look at someone else's project, do
> 
>         git init URL

Good documentation is hard -- different people catch on to different
ways of saying the same thing at different times in different ways.

-- 
                  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: [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
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox