* [PATCH] Fix broken diff-cache output on added files
From: Petr Baudis @ 2005-04-23 23:43 UTC (permalink / raw)
To: torvalds; +Cc: git
Added files were errorneously reported with the - prefix by diff-cache,
obviously leading to great confusion.
Signed-off-by: Petr Baudis <pasky@ucw.cz>
Index: diff-cache.c
===================================================================
--- 099679c62a98433d9d9b38581f39563c9574478e/diff-cache.c (mode:100644 sha1:b407d753e520fa0b1523d770d98b3015af197275)
+++ 3df862ae5cc66733dab3d8bd5c4ea359b2ca1884/diff-cache.c (mode:100644 sha1:2ec6c29ab6b79a10277a2ff9021a2032d656abf0)
@@ -57,7 +57,7 @@
}
/* No matching 1-stage (tree) entry? Show the current one as added */
if (entries == 1 || !same_name(ce, ac[1])) {
- show_file("-", ce);
+ show_file("+", ce);
ac++;
entries--;
continue;
--
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] Add help details to git help command. (This time with Perl)
From: Petr Baudis @ 2005-04-23 23:41 UTC (permalink / raw)
To: David Greaves; +Cc: Steven Cole, git
In-Reply-To: <42677284.1010005@dgreaves.com>
Please ignore the reply marker part. ;-)
Sorry,
--
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] fixup GECOS handling
From: Petr Baudis @ 2005-04-23 23:38 UTC (permalink / raw)
To: Martin Schlemmer; +Cc: kyle, GIT Mailing Lists
In-Reply-To: <1114196803.29271.52.camel@nosferatu.lan>
Dear diary, on Fri, Apr 22, 2005 at 09:06:43PM CEST, I got a letter
where Martin Schlemmer <azarah@nosferatu.za.org> told me that...
> @@ -311,6 +296,17 @@
> if (!pw)
> die("You don't exist. Go away!");
> realgecos = pw->pw_gecos;
> + /*
> + * The GECOS fields are seperated via ',' on Linux, FreeBSD, etc,
> + * and ';' on AIX.
> + */
> +#if defined(__aix__)
> + if (strchr(realgecos, ';'))
> + *strchr(realgecos, ';') = 0;
> +#else
> + if (strchr(realgecos, ','))
> + *strchr(realgecos, ',') = 0;
> +#endif
> len = strlen(pw->pw_name);
> memcpy(realemail, pw->pw_name, len);
> realemail[len] = '@';
I'm confused, what does this has to do with AIX? Do we even have / can
expect to have any major AIX users?
I'm not too happy with this, I have to say. It seems it won't do always
the right thing anyway. I would still favour the approach when you cut
off everything after ';', and everything after ',' if no ';' is found.
Seems simplest, safest, etc.
Tell me about anyone who has a semicolon in his realname.
--
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-commits mailing list feed.
From: Linus Torvalds @ 2005-04-23 23:29 UTC (permalink / raw)
To: Jan Harkes
Cc: David Woodhouse, Jan Dittmer, Greg KH, Kernel Mailing List,
Git Mailing List
In-Reply-To: <20050423204957.GA16751@delft.aura.cs.cmu.edu>
On Sat, 23 Apr 2005, Jan Harkes wrote:
>
> I respectfully disagree,
>
> rsync works fine for now, but people are already looking at implementing
> smarter (more efficient) ways to synchronize git repositories by
> grabbing missing commits, and from there fetching any missing tree and
> file blobs.
Bit this is a _feature_.
Other people normally shouldn't be interested in your tags. I think it's a
mistake to make everybody care.
So you normally would fetch only tags you _know_ about. For example, one
of the reasons we've been _avoiding_ personal tags in teh BK trees is that
it just gets really ugly really quickly because they get percolated up to
everybody else. That means that in a BK tree, you can't sanely use tags
for "private" stuff, like telling somebody else "please sync with this
tag".
So having the tag in the object database means that fsck etc will notice
these things, and can build up a list of tags you know about. It also
means that you can have tag-aware synchronization tools, ie exactly the
kind of tools that only grab missing commits can also then be used to
select missing tags according to some _private_ understanding of what tags
you might want to find..
Linus
^ permalink raw reply
* Re: [PATCH] make file merging respect permissions
From: James Bottomley @ 2005-04-23 23:21 UTC (permalink / raw)
To: Petr Baudis; +Cc: Linus Torvalds, Git Mailing List
In-Reply-To: <20050423230238.GD13222@pasky.ji.cz>
On Sun, 2005-04-24 at 01:02 +0200, Petr Baudis wrote:
> *cough*
OK, dirty file in the local tree, sorry.
This is the actual diff
---
1) permissions aren't respected in the merge script (primarily because
they're never passed in to it in the first place). Fix that and also
check for permission conflicts in the merge
2) the delete of a file in both branches may indeed be just that, but it
could also be the indicator of a rename conflict (file moved to
different locations in both branches), so error out and ask the
committer for guidance.
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
--- 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,12 +68,21 @@ 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
;;
*)
--- 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: Hash collision count
From: Jeff Garzik @ 2005-04-23 23:20 UTC (permalink / raw)
To: Ray Heasman; +Cc: Git Mailing List, Linus Torvalds
In-Reply-To: <1114297231.10264.12.camel@maze.mythral.org>
Ray Heasman wrote:
> On Sat, 2005-04-23 at 16:27 -0400, 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
>>
>
>
> Great. So what have you done here? Suppose you have 32 bits of counter
> for n. Whoopee, you just added 32 bits to your hash, using a two stage
> algorithm. So, you have a 192 bit hash assuming you started with the 160
> bit SHA. And, one day your 32 bit counter won't be enough. Then what?
First, there is no 32-bit limit. git stores keys (aka hashes) as
strings. As it should.
Second, in your scenario, it's highly unlikely you would get 4 billion
sha1 hash collisions, even if you had the disk space to store such a git
database.
>>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.
>
>
> You aren't solving anything. You're just putting it off, and doing it in
> a way that breaks all the wonderful semantics possible by just assuming
> that the hash is unique. All of a sudden we are doing checks of data
> that we never did before, and we have to do the check trillions of times
> before the CPU time spent pays off.
First, the hash is NOT unique.
Second, you lose data if you pretend it is unique. I don't like losing
data.
Third, a data check only occurs in the highly unlikely case that a hash
already exists -- a collision. Rather than "trillions of times", more
like "one in a trillion chance."
Jeff
^ permalink raw reply
* Re: Git-commits mailing list feed.
From: Andreas Gal @ 2005-04-23 23:16 UTC (permalink / raw)
To: Fabian Franz
Cc: Linus Torvalds, David Woodhouse, Jan Dittmer, Greg KH,
Git Mailing List
In-Reply-To: <200504231950.43903.FabianFranz@gmx.de>
I would prefer a generic mechanism to sign _any_ object, not just tag
objects:
- Introduce "signature objects" that contains an implementation-specific
signature. git doesn't care about the content, as long some script can
verify that the signature in the signature object matches the content of
the object(s) it references. The "name" of a signature object is the
SHA1 hash of the content (=gpg signature, for example).
- Referencing signatures in tags makes no sense IMO, because it would
require to change the (hash) name of tags when someone else wants to
co-sign it later on. I would just distribute two names for that (here is
tag xxxxx and its signature is yyyyy). Tags should only contain a
symbolic name and the hash of the commit object they point to.
- A nice benefit of this is that we could sign unnamed commits (think
automatic signing of intermediate commit), or even sign individual
files in the tree.
Just my 2c.
Andreas
On Sat, 23 Apr 2005, Fabian Franz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Am Samstag, 23. April 2005 19:31 schrieb Linus Torvalds:
> > On Sun, 24 Apr 2005, David Woodhouse wrote:
> > > Nah, asking Linus to tag his releases is the most comfortable way.
> > >
> > The reason I've not done tags yet is that I haven't decided how to do
> > them.
> >
> > commit a2755a80f40e5794ddc20e00f781af9d6320fafb
> > tag v2.6.12-rc3
> > signer Linus Torvalds
> >
> > This is my official original 2.6.12-rc2 release
> >
> > -----BEGIN PGP SIGNATURE-----
> > ....
> > -----END PGP SIGNATURE-----
> >
> > If somebody writes a script to generate the above kind of thing (and tells
> > me how to validate it), I'll do the rest, and start tagging things
> > properly. Oh, and make sure the above sounds sane (ie if somebody has a
> > better idea for how to more easily identify how to find the public key to
> > check against, please speak up).
>
> To generate those you do:
>
> # cat unsigned_tag
>
> commit a2755a80f40e5794ddc20e00f781af9d6320fafb
> tag v2.6.12-rc3
> signer Linus Torvalds
> This is my official original 2.6.12-rc2 release
>
> # gpg --clearsign < unsigned_tag > signed_tag # gpg will ask here for the
> secret key phrase
>
> To verify you do:
>
> # gpg --verify < signed_tag
>
> and check exit status.
>
> Hope that helps,
>
> cu
>
> Fabian
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.4 (GNU/Linux)
>
> iD8DBQFCaorzI0lSH7CXz7MRAr3QAJ45f2CQTgJ0sYfF9kRyrWHbsazVQQCeMqW7
> HCsah/llt/I8sQ36dlDnRWg=
> =Fgq1
> -----END PGP SIGNATURE-----
>
> -
> 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 remote repositories
From: Petr Baudis @ 2005-04-23 23:16 UTC (permalink / raw)
To: Dan Weber; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.62.0504221929480.20133@mirrorlynx.com>
Dear diary, on Sat, Apr 23, 2005 at 01:38:43AM CEST, I got a letter
where Dan Weber <dan@mirrorlynx.com> told me that...
> It wasn't that long ago that the pasky git tree was relocated. This
> required a modification to the .git directory in a local pull. A dns
> system could be built to ensure the following:
>
> A) quick easy lookup of archive locations
> B) handle changes of repository location
> C) add mirror support
What's wrong with just doing roundrobin? :)
--
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: [pasky] tags issue on mirrors
From: Petr Baudis @ 2005-04-23 23:13 UTC (permalink / raw)
To: Martin Schlemmer; +Cc: GIT Mailing Lists
In-Reply-To: <1114215547.27940.14.camel@nosferatu.lan>
Dear diary, on Sat, Apr 23, 2005 at 02:19:07AM CEST, I got a letter
where Martin Schlemmer <azarah@nosferatu.za.org> told me that...
> Hi,
Hi,
> Just check, you currently have:
>
> rsync://rsync.kernel.org/pub/scm/cogito/cogito.git/tags/tags
>
> Both with the same tag files.
yes, sorry about that. A mistake in git pull tag rsync invocation.
--
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-23 23:09 UTC (permalink / raw)
To: James Bottomley; +Cc: Linus Torvalds, git
In-Reply-To: <1114281792.5068.10.camel@mulgrave>
Dear diary, on Sat, Apr 23, 2005 at 08:43:12PM CEST, I got a letter
where James Bottomley <James.Bottomley@SteelEye.com> told me that...
> One of the features I found most useful about bk changes was the ability
> to see changes in my tree that weren't in the other tree (I use this to
> keep track of what patches I actually have).
>
> I've modified the gitlog script to take the -L and -R options (local
> directories only; won't work on remotes like bk changes would) to add
> this functionality.
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 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
?
--
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] make file merging respect permissions
From: James Bottomley @ 2005-04-23 23:09 UTC (permalink / raw)
To: Petr Baudis; +Cc: Linus Torvalds, Git Mailing List
In-Reply-To: <20050423230238.GD13222@pasky.ji.cz>
On Sun, 2005-04-24 at 01:02 +0200, Petr Baudis wrote:
> > + if [ $ -ne 0 ]; then
>
> *cough*
You're kidding me?
Well ... it's correct in my repository ... I'll investigate my diff
script
James
^ permalink raw reply
* Re: [PATCH] make file merging respect permissions
From: Petr Baudis @ 2005-04-23 23:02 UTC (permalink / raw)
To: James Bottomley; +Cc: Linus Torvalds, Git Mailing List
In-Reply-To: <1114292680.4799.4.camel@mulgrave>
Dear diary, on Sat, Apr 23, 2005 at 11:44:40PM CEST, I got a letter
where James Bottomley <James.Bottomley@SteelEye.com> told me that...
> On Sat, 2005-04-23 at 13:17 -0700, Linus Torvalds wrote:
> > Yeah, yeah, you obviously meant "$?", but the fact
> > is, your patch is bogus, and I don't trust it. Can you re-send a valid
> > one
> > (and sign off on it).]
>
> OK, here it is .. I have an excuse, honest ... and a note from my mum.
>
> + 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 [ $ -ne 0 ]; then
*cough*
--
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: Hash collision count
From: Ray Heasman @ 2005-04-23 23:00 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Git Mailing List, Linus Torvalds
In-Reply-To: <426AAFC3.800@pobox.com>
On Sat, 2005-04-23 at 16:27 -0400, 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
>
Great. So what have you done here? Suppose you have 32 bits of counter
for n. Whoopee, you just added 32 bits to your hash, using a two stage
algorithm. So, you have a 192 bit hash assuming you started with the 160
bit SHA. And, one day your 32 bit counter won't be enough. Then what?
> 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.
You aren't solving anything. You're just putting it off, and doing it in
a way that breaks all the wonderful semantics possible by just assuming
that the hash is unique. All of a sudden we are doing checks of data
that we never did before, and we have to do the check trillions of times
before the CPU time spent pays off.
If you want to use a bigger hash then use a bigger hash, but don't fool
yourself into thinking that isn't what you are doing.
Ciao,
Ray
^ permalink raw reply
* Re: [PATCH] make file merging respect permissions
From: James Bottomley @ 2005-04-23 21:44 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0504231311300.2344@ppc970.osdl.org>
On Sat, 2005-04-23 at 13:17 -0700, Linus Torvalds wrote:
> Yeah, yeah, you obviously meant "$?", but the fact
> is, your patch is bogus, and I don't trust it. Can you re-send a valid
> one
> (and sign off on it).]
OK, here it is .. I have an excuse, honest ... and a note from my mum.
---
This patch fixes two problems
1) permissions aren't respected in the merge script (primarily because
they're never passed in to it in the first place). Fix that and also
check for permission conflicts in the merge
2) the delete of a file in both branches may indeed be just that, but it
could also be the indicator of a rename conflict (file moved to
different locations in both branches), so error out and ask the
committer for guidance.
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
--- a/git-merge-one-file-script
+++ b/git-merge-one-file-script
@@ -20,23 +20,47 @@ 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:"
+ echo "ERROR: File $4 added in both branches, permissions conflict $6->$7"
+ echo "ERROR:"
+ 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,12 +70,21 @@ 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 [ $ -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
;;
*)
--- 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: Git transfer protocols (was: Re: Git-commits mailing list feed)
From: Jan Harkes @ 2005-04-23 22:22 UTC (permalink / raw)
To: Mike Taht
Cc: Jan Harkes, Linus Torvalds, David Woodhouse, Jan Dittmer, Greg KH,
Git Mailing List
In-Reply-To: <426ABE1B.7000905@timesys.com>
On Sat, Apr 23, 2005 at 02:28:59PM -0700, Mike Taht wrote:
> Jan Harkes wrote:
>
> >rsync works fine for now, but people are already looking at implementing
> >smarter (more efficient) ways to synchronize git repositories by
> >grabbing missing commits, and from there fetching any missing tree and
> >file blobs. However there is no such linkage to discover missing tag
> >objects, only a full rsync would be able to get them and for that it has
> >to send the name of every object in the repository to the other side to
> >check for any missing ones.
Actually I just realized that I personally probably wouldn't care about
most of the tags that people might add to their trees. Maybe once in a
while, but the tag would probably be obtained through email or the web.
> I think that one reason why rsync is inefficient for git is that it
...
> lastly, Monotone has it's own "netsync" protocol
> (via http://www.venge.net/monotone/faq.html)
Interesting, probably something like any of these might end up useful to
replace rsync for mirroring full git repositories.
I'm actually more selfish than that and am thinking on how I expect to
use git.
See, I don't care about most of the objects in the repository. In
practice I would probably pull only the latest 'head' once in a while
look for missing commits to give me a quick overview of what has
changed. Then if a diff between the new head and my current tree shows
that anything might have changed in an area I actually do care about,
such as the VFS, I'd want something that does a quick binary search to
identify the commits where the changes occured. But for that I only
need to look at a limited number of tree objects.
As long as I know that someone, somewhere is archiving the whole
repository I can always come back later and fill in the blanks.
HTTP/1.1 with persistent connections and some request interleaving is
probably the fastest and most server friendly way to grab those objects
I really care about.
Jan
^ permalink raw reply
* Re: git pull issues...
From: Petr Baudis @ 2005-04-23 22:00 UTC (permalink / raw)
To: Morten Welinder; +Cc: GIT Mailing List
In-Reply-To: <118833cc050423142573729ce2@mail.gmail.com>
Dear diary, on Sat, Apr 23, 2005 at 11:25:32PM CEST, I got a letter
where Morten Welinder <mwelinder@gmail.com> told me that...
> Minor issues with "git pull":
>
> 1. Multiple rsync call might connect to different servers (with
> round-robin DNS). The effect
> will be interesting. One call, if possible, would be better.
If you can do it without overwriting HEAD, please go ahead and send me
the patch. :-)
> 2. If any rsync fails, the process should be aborted.
Fixed.
> As long as we do have multiple calls:
>
> 3. The "grep -v '^MOTD:'" should be changed to kill blank lines after
> MOTDs also.
Actually, I currently use this as a poor man's progress indicator. ;-)
*hide*
--
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: Linux 2.6.12-rc3
From: Pavel Machek @ 2005-04-23 21:31 UTC (permalink / raw)
To: Petr Baudis; +Cc: Linus Torvalds, kernel list, git
In-Reply-To: <20050421190956.GA7443@pasky.ji.cz>
Hi!
> > > > Well, not sure.
> > > >
> > > > I did
> > > >
> > > > git track linus
> > > > git cancel
> > > >
> > > > but Makefile still contains -rc2. (Is "git cancel" right way to check
> > > > out the tree?)
> > >
> > > No. git cancel does what it says - cancels your local changes to the
> > > working tree. git track will only set that next time you pull from
> > > linus, the changes will be automatically merged. (Note that this will
> > > change with the big UI change.)
> >
> > Is there way to say "forget those changes in my repository, I want
> > just plain vanilla" without rm -rf?
>
> git cancel will give you "plain last commit". If you need plain vanilla,
> the "hard way" now is to just do
>
> commit-id >.git/HEAD
>
> but your current HEAD will be lost forever. Or do
>
> git fork vanilla ~/vanilla linus
>
> and you will have the vanilla tree tracking linus in ~/vanilla.
Yep, symlinked in nice way. Good trap; it cought me ;-). (I of course
deleted the original directory).
> I'm not yet sure if we should have some Cogito interface for doing this
> and what its semantics should be.
Perhaps "git init" is right command for this? Running it in non-empty
directory for faster restart after bad problem....
Pavel
--
Boycott Kodak -- for their patent abuse against Java.
^ permalink raw reply
* Git transfer protocols (was: Re: Git-commits mailing list feed)
From: Mike Taht @ 2005-04-23 21:28 UTC (permalink / raw)
To: Jan Harkes
Cc: Linus Torvalds, David Woodhouse, Jan Dittmer, Greg KH,
Git Mailing List
In-Reply-To: <20050423204957.GA16751@delft.aura.cs.cmu.edu>
Jan Harkes wrote:
> rsync works fine for now, but people are already looking at implementing
> smarter (more efficient) ways to synchronize git repositories by
> grabbing missing commits, and from there fetching any missing tree and
> file blobs. However there is no such linkage to discover missing tag
> objects, only a full rsync would be able to get them and for that it has
> to send the name of every object in the repository to the other side to
> check for any missing ones.
I think that one reason why rsync is inefficient for git is that it
appears to need an acknowledgement after every file. (at least, that's
what what the rhythm of the packets looked like when I sniffed it
earlier, I don't know anything else about it) For a series of very small
files this interacts badly with tcp's flow control mechanisms. Perhaps
rsync could be modified for a "sliding file acknowledgement window".
Most "swarming protocols" (e.g BitTorrent, eDonkey) work well for one
big file shared among multiple hosts, but poorly for lots of small files.
*Nothing* out there matches the simplicity of git's sha1 filename
length... but
Something like robcast or fcast/flute might be of interest:
http://www.inrialpes.fr/planete/people/roca/mcl/mcl_in_short.html
Or one of the multicast netnews experiments:
"mcntp" http://mcntp.sourceforge.net/
"newscaster" http://www.dmn.tzi.org/en/newscaster.html
lastly, Monotone has it's own "netsync" protocol
(via http://www.venge.net/monotone/faq.html)
"[netsync] is a bi-directional pipelined protocol for synchronizing
collections using a tree of hashed indices. It allows any copy of
monotone to function as either a client or a server, and rapidly
synchronize or half-synchronize (push / pull) their database with
another user. It is somewhat similar in flavor to rsync or Unison, in
that it quickly and idempotently synchronizes information across the
network without needing to store any local state; however, it is much
more efficient than these protocols."
--
Mike Taht
^ permalink raw reply
* Re: Catching up: git-pasky-0.6.2 broken?
From: Petr Baudis @ 2005-04-23 21:25 UTC (permalink / raw)
To: Russell King; +Cc: git
In-Reply-To: <20050423151238.C32116@flint.arm.linux.org.uk>
Dear diary, on Sat, Apr 23, 2005 at 04:12:39PM CEST, I got a letter
where Russell King <rmk@arm.linux.org.uk> told me that...
> Could the problem be related to some random garbage left in .git/add-queue
> and .git/rm-queue?
Quite likely.
> If so, how did these files get generated in the first place, and why
> weren't they removed when they were finished with?
That was a bug in git apply, fixed for quite some time already.
> IMHO updating a repository from an external source should _NOT_ be
> affected by the presence (or absense) of these two files, which
> contain only _local_ state information.
Note that the latest git-pasky (post-0.6.3) is already completely
queues-free.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* git pull issues...
From: Morten Welinder @ 2005-04-23 21:25 UTC (permalink / raw)
To: GIT Mailing List
Minor issues with "git pull":
1. Multiple rsync call might connect to different servers (with
round-robin DNS). The effect
will be interesting. One call, if possible, would be better.
2. If any rsync fails, the process should be aborted.
As long as we do have multiple calls:
3. The "grep -v '^MOTD:'" should be changed to kill blank lines after
MOTDs also.
Morten
^ permalink raw reply
* Re: Git-commits mailing list feed.
From: Jan Harkes @ 2005-04-23 20:49 UTC (permalink / raw)
To: Linus Torvalds
Cc: David Woodhouse, Jan Dittmer, Greg KH, Kernel Mailing List,
Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0504231228480.2344@ppc970.osdl.org>
On Sat, Apr 23, 2005 at 12:30:38PM -0700, Linus Torvalds wrote:
> On Sat, 23 Apr 2005, Jan Harkes wrote:
> >
> > Why not keep the tags object outside of the tree in the tags/ directory.
>
> Because then you have all those special cases with fetching them and with
> fsck, and with shared object directories. In other words: no.
I respectfully disagree,
rsync works fine for now, but people are already looking at implementing
smarter (more efficient) ways to synchronize git repositories by
grabbing missing commits, and from there fetching any missing tree and
file blobs. However there is no such linkage to discover missing tag
objects, only a full rsync would be able to get them and for that it has
to send the name of every object in the repository to the other side to
check for any missing ones.
So fetching tags is already going to be a special case.
And any form of validation of a tag is a special operation. In fact tags
could be as simple as a the sha of an (like pasky's tags) followed by
the detached pgp signature of the tagged object instead of trying to
signing the tag itself. That also avoids having to strip the signature
part from the tag when we want to validate it.
Jan
^ permalink raw reply
* Re: [PATCH] make file merging respect permissions
From: James Bottomley @ 2005-04-23 20:37 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0504231311300.2344@ppc970.osdl.org>
On Sat, 2005-04-23 at 13:17 -0700, Linus Torvalds wrote:
> The attached patch was seriously corrupt. Did you edit it by hand? The
> second chunk of the git-merge-one-file-script patch claims to have 12
> source lines, but only has 11, causing patch no end of confusion.
OK ... yes I admit it ... the shame ... I noticed a problem after I
generated it and then edited it in source
> I fixed up the line counts by hand, and the end result looked almost sane,
> but when looking closer, I noticed the
>
> + if [ $ -ne 0 ]; then
> + echo "ERROR: Leaving conflict merge in $src2"
> exit 1
>
> which just can't be right either ("$" never equals 0, so the above will
> always report an error), so I assume that whatever editing you did was
> really quite corrupt. Yeah, yeah, you obviously meant "$?", but the fact
> is, your patch is bogus, and I don't trust it. Can you re-send a valid one
> (and sign off on it).
Yes boss ... Just getting on a 'plane now. Should be able to send it
out in an hour or so.
James
^ permalink raw reply
* Re: Hash collision count
From: Jeff Garzik @ 2005-04-23 20:33 UTC (permalink / raw)
To: Git Mailing List, Linus Torvalds
In-Reply-To: <426AAFC3.800@pobox.com>
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
This of course presumes that you know that your new data does not exist
in the cache.
Otherwise, you would need to hash the on-disk $hash-0 to determine if
its a collision or a reference.
Jeff
^ permalink raw reply
* Hash collision count
From: Jeff Garzik @ 2005-04-23 20:27 UTC (permalink / raw)
To: Git Mailing List, Linus Torvalds
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
^ permalink raw reply
* Re: Git-commits mailing list feed.
From: Junio C Hamano @ 2005-04-23 20:24 UTC (permalink / raw)
To: Linus Torvalds
Cc: Sean, Thomas Glanzmann, David Woodhouse, Jan Dittmer, Greg KH,
Kernel Mailing List, Git Mailing List
In-Reply-To: <7vis2d2rmv.fsf@assigned-by-dhcp.cox.net>
>>>>> "JCH" == I said:
JCH> If that is the case, can't you do it without introducing this
JCH> new tag object, like this?
Of course It Would Not Work. I am an idiot X-<. Sorry. What I
suggested does not authenticate the tag itself.
^ 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