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