* Re: [PATCH] make file merging respect permissions
From: Linus Torvalds @ 2005-04-23 20:17 UTC (permalink / raw)
To: James Bottomley; +Cc: Git Mailing List
In-Reply-To: <1114280570.5068.5.camel@mulgrave>
On Sat, 23 Apr 2005, James Bottomley wrote:
>
> The attached fixes both issues
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.
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).
Linus
^ permalink raw reply
* Re: Git-commits mailing list feed.
From: Jeff Garzik @ 2005-04-23 20:15 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.0504231010580.2344@ppc970.osdl.org>
Linus Torvalds wrote:
> That was my plan, at least. But I haven't set up any signature generation
> thing, and this really isn't my area of expertise any more. But my _plan_
> literally was to have the tag object look a lot like a commit object, but
> instead of pointing to the tree and the commit parents, it would point to
> the commit you are tagging. Somehting like
>
> 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-----
> with a few fixed headers and then a place for free-form commentary,
groovy
> 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).
[tangent]
Any chance you'll have a tree tagged with older releases?
Is someone with access to BK working on that?
I do a lot of patch merges where someone sends me a 2.6.10 patch.
Presuming the fix is still valid, I'll clone to 2.6.10, merge the patch,
pull 2.6.latest into the 2.6.10-based repo, then push the whole she-bang
into one of my for-upstream repos.
Jeff
^ permalink raw reply
* Re: Humble request of 'git' developers
From: Chris Wedgwood @ 2005-04-23 20:18 UTC (permalink / raw)
To: Jeff Garzik; +Cc: git
In-Reply-To: <426AAB65.2060401@pobox.com>
On Sat, Apr 23, 2005 at 04:09:09PM -0400, Jeff Garzik wrote:
> * flat namespaces grow cumbersome
agreed
> * if everybody uses the 'git' command, which does all the internal
> execution, then it's just namespace pollution.
sure, but not everyone body is
i agree everybody *should* and then it can go into <prefix>/libexec or
similar
^ permalink raw reply
* Re: Git-commits mailing list feed.
From: Linus Torvalds @ 2005-04-23 20:23 UTC (permalink / raw)
To: Junio C Hamano
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>
On Sat, 23 Apr 2005, Junio C Hamano wrote:
>
> If that is the case, can't you do it without introducing this
> new tag object, like this?
No, because I also want to sign the _name_ I gave it.
Otherwise somebody can take my "signed commit", and claim that I called it
something else.
Just signing the commit is indeed sufficient to just say "I trust this
commit". But I essentially what to also say what I trust it _for_ as well.
And sure, I could make a totally bogus "commit" object that just points to
the original commit, uses the same "tree" from that original commit, and
write what I want to trust into that commit. I then sign that, and create
yet _another_ commit that has the signature (and the pointer to the just
signed commit) in its commit message, and then I point to _that_ commit.
So yes, we can certainly do this with playing games with commits. That
sounds singularly ugly, though, since just doing a "tag" object is a lot
more straightforward, and really tells the world what's going on (and
makes it easy for automated tools to just browse the object database and
see "that's a tag").
Linus
^ 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
* 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: 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
* 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: 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
* 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: 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 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: 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
* 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: 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: [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: 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: 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: [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: 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: [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 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: 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: 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: [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
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