* Re: full kernel history, in patchset format
From: Catalin Marinas @ 2005-04-18 10:07 UTC (permalink / raw)
To: Ingo Molnar; +Cc: git
In-Reply-To: <20050416131528.GB19908@elte.hu>
Ingo Molnar <mingo@elte.hu> wrote:
> i've converted the Linux kernel CVS tree into 'flat patchset' format,
> which gave a series of 28237 separate patches. (Each patch represents a
> changeset, in the order they were applied. I've used the cvsps
> utility.)
AFAIK, cvsps uses the date/time to create the changesets. There is a
problem with the BKCVS export since some files in the same commit can
have a different time (by an hour). I posted a mail some time ago
about this -
http://marc.theaimsgroup.com/?l=linux-kernel&m=110026570201544&w=2
I read that the old history won't be merged into the new repository
but, if you are interested, I have a script that can do this based on
the "(Logical change ...)" string in the file commit logs and it is
quite fast at generating the patches.
--
Catalin
^ permalink raw reply
* Re: Re-done kernel archive - real one?
From: Russell King @ 2005-04-18 9:23 UTC (permalink / raw)
To: Linus Torvalds, Petr Baudis; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0504171621330.7211@ppc970.osdl.org>
On Sun, Apr 17, 2005 at 04:24:24PM -0700, Linus Torvalds wrote:
> On Sun, 17 Apr 2005, Russell King wrote:
> > I pulled it tonight into a pristine tree (which of course worked.)
>
> Goodie.
Note the "pristine". Now comes the real test...
> > In doing so, I noticed that I'd messed up one of the commits - there's
> > a missing new file. Grr. I'll put that down to being a newbie git.
>
> Actually, you should put that down to horribly bad interface tools. With
> BK, we had these nice tools that pointed out that there were files that
> you might want to commit (ie "bk citool"), and made this very obvious.
>
> Tools absolutely matter. And it will take time for us to build up that
> kind of helper infrastructure. So being newbie might be part of it, but
> it's the smaller part, I say. Rough interfaces is a big issue.
Ok, I just tried pulling your tree into the tree you pulled from, and
got this:
Tree change: e7905b2f22eb5d5308c9122b9c06c2d02473dd4f ee423ea56280512778a5961ee58a785a73acb7d1
...
*100644->100644 blob 46f0a3caae02b4bb8f903d7ac86456aa0c37954b->ba4afd7956173b6f89eb6b0b9ad23b392d5c0aee arch/arm/kernel/process.c
*100644->100644 blob 4a36fa7192e11df36f5e0928b064239dabe1e305->ec0bc8f315ab5d78a4220e176e7aee76d52d1c74 arch/arm/kernel/traps.c
*100644->100644 blob 311d19ee00208faf02359f9e7c5394577a40f253->bf923a953703c6ca0c88eac3b2850cf07b838996 arch/arm/lib/changebit.S
*100644->100644 blob c07afa31695654e6489ec59c3f837183b325e9da->41f89b3a393d5af939f04f63c5bf4991b2bf6599 arch/arm/lib/clearbit.S
...
Tracked branch, applying changes...
Merging e7905b2f22eb5d5308c9122b9c06c2d02473dd4f -> ee423ea56280512778a5961ee58a785a73acb7d1
to df4449813c900973841d0fa5a9e9bc7186956e1e...
COPYING: needs update
CREDITS: needs update
Documentation/00-INDEX: needs update
Documentation/BK-usage/00-INDEX: needs update
...
patching file arch/arm/kernel/process.c
Reversed (or previously applied) patch detected! Skipping patch.
2 out of 2 hunks ignored -- saving rejects to file arch/arm/kernel/process.c.rejpatching file arch/arm/kernel/traps.c
Reversed (or previously applied) patch detected! Skipping patch.
3 out of 3 hunks ignored -- saving rejects to file arch/arm/kernel/traps.c.rej
patching file arch/arm/lib/changebit.S
Reversed (or previously applied) patch detected! Skipping patch.
2 out of 2 hunks ignored -- saving rejects to file arch/arm/lib/changebit.S.rej
patching file arch/arm/lib/clearbit.S
Reversed (or previously applied) patch detected! Skipping patch.
2 out of 2 hunks ignored -- saving rejects to file arch/arm/lib/clearbit.S.rej
so obviously git pull isn't able to indentify what's already in the
local repository.
Interestingly, the files listed above as having rejects are excluded
from the list of "needs update". And I don't know why git is staying
that these files need updating, because they haven't changed since
they were initially checked out.
This was with some random version of git-pasky-0.04. Unfortunately,
this version doesn't have the sha1 ID appended, so I couldn't say
definitively that it's the latest and greatest. It might be a day
old.
--
Russell King
^ permalink raw reply
* git options
From: Mike Taht @ 2005-04-18 9:23 UTC (permalink / raw)
To: git
In-Reply-To: <20050417213632.1f099ff9.pj@sgi.com>
Would it be useful at this point to make common and centralize some/most
of the various options that control git? (as well as add some useful
ones). Something like:
struct _git_opt {
int verbose:1;
int debug:1;
int dry-run:1;
int should_block:1;
int remove_lock:1;
int allow_add:1;
int allow_remove:1;
int null_termination:1;
int show_cached:1;
int show_deleted:1;
int show_others:1;
int show_ignored:1;
int show_stage:1;
int show_unmerged:1;
int show_edges:1;
int show_unreachable:1;
int basemask:1;
int recursive:1;
int force_filename:1;
int force:1;
int quiet:1;
int stage:1;
};
--
Mike Taht
"Avoid letting temper block progress; keep cool.
-- William Feather"
^ permalink raw reply
* Re: [patch] git: fix 1-byte overflow in show-files.c
From: Ingo Molnar @ 2005-04-18 8:28 UTC (permalink / raw)
To: Petr Baudis; +Cc: git, Linus Torvalds
In-Reply-To: <20050417235920.GY1461@pasky.ji.cz>
* Petr Baudis <pasky@ucw.cz> wrote:
> > will attempt to append a "/" string to the directory name - resulting in
> > a 1-byte overflow (a zero byte is written to offset 4097, which is
> > outside the array).
>
> The name ends precisely at offset 4095 with its NUL character:
>
> {PATH_MAX}
> Maximum number of bytes in a pathname, including the terminating
> null character.
> [ http://www.opengroup.org/onlinepubs/009695399/basedefs/limits.h.html ]
>
> So, if I'm not mistaken, '/' will be written at offset 4095 instead of
> the NUL and the NUL will be written at 4096. Everything's fine, right?
yeah, you are right - ignore this patch.
Ingo
^ permalink raw reply
* Re: SHA1 hash safety
From: Andy Isaacson @ 2005-04-18 7:43 UTC (permalink / raw)
To: omb; +Cc: git
In-Reply-To: <4261852B.6090507@khandalf.com>
[trimmed cc list, nobody wants to read this noise]
On Sat, Apr 16, 2005 at 11:35:39PM +0200, Brian O'Mahoney wrote:
> >> (1) I _have_ seen real-life collisions with MD5, in the context of
> >> Document management systems containing ~10^6 ms-WORD documents.
> >
> > Dude! You could have been *famous*! Why the
> > aitch-ee-double-hockey-sticks didn't you publish this when you found it?
> > Seriously, man.
>
> The MD5 has was fine, or at least the code (a) produced the correct
> results on the published test cases, and, (b) was properly applied to
> all bytes of the file(s). I was surprised when it happened, which is why
> I bothered to post to this list at this time, so I make two more points
OK, I guess it's time for some remedial math.
There are 2^128 = 340282366920938463463374607431768211456 different MD5
hashes.
You are suggesting that you found a collision using ~1e6 = ~1,000,000
plaintexts.
Let's suppose there were actually 100,000,000 = 1e8 plaintexts, just in
case you underestimated the number.
Applying the birthday paradox, we have a 50% probability that you'd find
one collision if there were ~7,213,475,309,916,173 possible hash values.
If you extend the birthday argument ("what is the probability of a
collision if you take N samples from a set of size M?") you get the
following results, with N = 1e8:
50% (1 in 2) probability of collision in 7,213,475,309,916,173.
1% (1 in 100) probability of collision in 497,496,027,172,833,194.
.05% (1 in 1845) probability of collision in 9,223,372,036,854,775,806.
That's where my quick-and-dirty solver craps out, but we're still a
really long ways from
340,282,366,920,938,463,463,374,607,431,768,211,456.
A simple linear extrapolation (certainly wrong, but not by more than a
few dozen orders of magnitude) says that the odds would be
1 in 68,056,473,384,187,692,692 for the full MD5 hash (I'm not even
going to dignify that with a percentage).
I'm not going to do the sums, but I would hazard a guess that it's more
likely your PC suffered a cosmic-ray-induced memory fault - EACH OF THE
FOUR TIMES YOU TESTED IT - causing it to report the same MD5, than that
you actually discovered a collision with a measly million (or even
hundred million) plaintexts.
(Of course, I don't know how many tests of the hash you actually did.
But the point stands.)
Hell, if you're *that* lucky, what are you doing in IT? You could be
making a killing at the roulette table.
Or, even more likely, there was some other factor in the system (most
likely that it was only using a few bits, probably 32, of the hash
when looking for collisions) that resulted in a false alarm.
If you had actual evidence of a collision, I'd love to see it - even if
it's just the equivalent of
% md5 foo
d3b07384d113edec49eaa6238ad5ff00 foo
% md5 bar
d3b07384d113edec49eaa6238ad5ff00 bar
% cmp foo bar
foo bar differ: byte 25, line 1
%
But in the absence of actual evidence, we have to assume (just based on
the probabilities) that there was some error in your testing.
-andy
^ permalink raw reply
* Re: Re: Merge with git-pasky II.
From: Ingo Molnar @ 2005-04-18 7:42 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Petr Baudis, Simon Fowler, David Lang, git
In-Reply-To: <Pine.LNX.4.58.0504171014430.7211@ppc970.osdl.org>
* Linus Torvalds <torvalds@osdl.org> wrote:
> On Sun, 17 Apr 2005, Ingo Molnar wrote:
> >
> > in fact, this attack cannot even be proven to be malicious, purely via
> > the email from Malice: it could be incredible bad luck that caused that
> > good-looking patch to be mistakenly matching a dangerous object.
>
> I really hate theoretical discussions.
i was only replying to your earlier point:
> > > Almost all attacks on sha1 will depend on _replacing_ a file with
> > > a bogus new one. So guys, instead of using sha256 or going
> > > overboard, just make sure that when you synchronize, you NEVER
> > > import a file you already have.
which point i still believe is subtly wrong. You were suggesting to
concentrate on file replacement to counter most of the practical
attacks, while i pointed out an attack _using the same basic mechanism
that your point above supposed_.
[ if you can replace a file with a known hash, with a bogus new one, and
you still have enough control over the contents of your bogus new file
that it is 1) a valid file that builds 2) compromises the kernel, then
you likely have the same amount of control my 'theoretical' attack
requires. ]
> And the thing is, _if_ somebody finds a way to make sha1 act as just a
> complex parity bit, and comes up with generating a clashing object
> that actually makes sense, then going to sha256 is likely pointless
> too [...]
yes, that's why i suggested to not actually trust the hash to be
cryptographically secure, but to just assume it's a good generic hash we
can design a DB around, and to turn -DCOLLISION_CHECK on and enforce
consistency rules on boundaries.
[ it's not bad to keep sha1 because even my suggested enhancement still
leaves 'content-less trust-pointers to untrusted content via email'
vectors open against attack (maintainer sends you an email that commit
X in Malice's repository Y is fine to pull, and you pull it blindly,
while the attacker has replaced his content with the compromised one
meanwhile), but it at least validates the bulk traffic that goes into
the DB: patches via emails and trusted repositories. ]
so all i was suggesting was to extend your suggested 'overwrite
collision check' to a stricter 'content we throw away and use the sha1
shortcut for needs to be checked against the in-DB content as well'.
in other words, your suggested 'rename check' is checking for 'positive
duplicate content', while my addition would also check for 'negative
duplicate content' as well.
but as usual, i could be wrong, so dont take this too serious :-)
Ingo
^ permalink raw reply
* Re: Yet another base64 patch
From: H. Peter Anvin @ 2005-04-18 6:28 UTC (permalink / raw)
To: Paul Dickson; +Cc: git
In-Reply-To: <20050415165532.05ed5dc4.paul@permanentmail.com>
Paul Dickson wrote:
>
> Since 160-bits does not go into base64 evenly anyways, what happens if
> you use 2^10 instead of 2^12 for the subdir names? That will be 1/4 the
> directories of the base64 given above.
>
I was going to try one-character subdirs, so 2^6, but I haven't had a
chance to do that since I'm at LCA.
Anyway, I'm starting to suspect it's too late to change the format,
especially since Linus seems highly disinclined.
-hpa
^ permalink raw reply
* Re: Yet another base64 patch
From: H. Peter Anvin @ 2005-04-18 6:23 UTC (permalink / raw)
To: David Lang; +Cc: Linus Torvalds, bert hubert, Christopher Li, git
In-Reply-To: <Pine.LNX.4.62.0504162107040.22904@qynat.qvtvafvgr.pbz>
David Lang wrote:
>
> note that default configs of ext2 and ext3 don't qualify as sane
> filesystems by this definition.
Not using dir_index *IS* insane.
-hpa
^ permalink raw reply
* [PATCH] Fix confusing behaviour of update-cache --refresh on unmerged paths.
From: Junio C Hamano @ 2005-04-18 6:09 UTC (permalink / raw)
To: torvalds; +Cc: git
The "update-cache --refresh" command attempts refresh_entry()
on unmerged path, which results in as many "needs update" messages
as there are unmerged stages for that path. This does not do
any harm to the working directory, but it is confusing.
$ ls -al
total 16
drwxrwsr-x 3 junio src 4096 Apr 17 23:00 ./
drwxrwsr-x 10 junio src 4096 Apr 17 22:58 ../
drwxr-sr-x 3 junio src 4096 Apr 17 22:59 .git/
-rw-rw-r-- 1 junio src 363 Apr 17 23:00 TT
$ show-files --stage
100644 e14bafaadce6c34768ba2ff8b3c6419e8839e7d2 1 TT
100644 99ef1b30fc6d6ea186d6eac62619e1afd65ad64e 2 TT
100644 033b9385f7a29882a6b4b34f67b20e2304d3489d 3 TT
$ ../++linus/update-cache --refresh
TT: needs update
TT: needs update
TT: needs update
$ ../update-cache --refresh
TT: needs merge
Here is a fix.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
update-cache.c | 13 +++++++++++--
1 files changed, 11 insertions(+), 2 deletions(-)
update-cache.c: 5742c6ca084a7761ad728651d85509736e2ebc7c
--- update-cache.c
+++ update-cache.c 2005-04-17 22:58:06.000000000 -0700
@@ -196,9 +196,18 @@ static void refresh_cache(void)
int i;
for (i = 0; i < active_nr; i++) {
- struct cache_entry *ce = active_cache[i];
- struct cache_entry *new = refresh_entry(ce);
+ struct cache_entry *ce, *new;
+ ce = active_cache[i];
+ if (ce_stage(ce)) {
+ printf("%s: needs merge\n", ce->name);
+ while ((i < active_nr) &&
+ ! strcmp(active_cache[i]->name, ce->name))
+ i++;
+ i--;
+ continue;
+ }
+ new = refresh_entry(ce);
if (!new) {
printf("%s: needs update\n", ce->name);
continue;
^ permalink raw reply
* [PATCH] Pretty-print date in 'git log'
From: David Woodhouse @ 2005-04-18 5:46 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
Add tool to render git's "<utcseconds> <zone>" into an RFC2822-compliant
string, because I don't think date(1) can do it. Use same for 'git log'
output.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
--- Makefile
+++ Makefile 2005-04-18 15:40:43.000000000 +1000
@@ -14,7 +14,7 @@
PROG= update-cache show-diff init-db write-tree read-tree commit-tree \
cat-file fsck-cache checkout-cache diff-tree rev-tree show-files \
- check-files ls-tree merge-base
+ check-files ls-tree merge-base show-date
SCRIPT= parent-id tree-id git gitXnormid.sh gitadd.sh gitaddremote.sh \
gitcommit.sh gitdiff-do gitdiff.sh gitlog.sh gitls.sh gitlsobj.sh \
--- gitlog.sh
+++ gitlog.sh 2005-04-18 15:39:38.000000000 +1000
@@ -13,6 +13,23 @@
rev-tree $base | sort -rn | while read time commit parents; do
echo commit ${commit%:*};
- cat-file commit $commit
+ cat-file commit $commit | while read type rest ; do
+ case "$type" in
+ "author"|"committer")
+ DATESTAMP="`echo $rest | cut -f2 -d\>`"
+ RFC2822DATE="`show-date $DATESTAMP 2>/dev/null || echo $DATESTAMP`"
+ echo $type $rest | sed "s/$DATESTAMP\$/ $RFC2822DATE/"
+ ;;
+
+ "")
+ echo ""
+ cat
+ ;;
+ *)
+ echo $type $rest
+ ;;
+ esac
+ done
+
echo -e "\n--------------------------"
done
--- show-date.c.orig 2005-04-18 15:43:06.000000000 +1000
+++ show-date.c 2005-04-18 15:42:15.000000000 +1000
@@ -0,0 +1,48 @@
+#include <time.h>
+#include <stdio.h>
+#include <stdlib.h>
+#include "cache.h"
+
+static const char *month_names[] = {
+ "Jan", "Feb", "Mar", "Apr", "May", "Jun",
+ "Jul", "Aug", "Sep", "Oct", "Nov", "Dec"
+};
+
+static const char *weekday_names[] = {
+ "Sun", "Mon", "Tue", "Wed", "Thu", "Fri", "Sat"
+};
+
+int main(int argc, char **argv)
+{
+ time_t t;
+ int offset;
+ char *p;
+ struct tm tm;
+
+ if (argc != 3)
+ usage("usage: show-date <seconds> <zone>");
+
+ t = strtol(argv[1], &p, 0);
+ if (*p || !t)
+ usage("usage: show-date <seconds> <zone>");
+
+ if (argv[2][0] != '-' && argv[2][0] != '+')
+ usage("usage: show-date <seconds> <zone>");
+
+ offset = strtol(argv[2]+1, &p, 10);
+ if (*p || p!= argv[2]+5)
+ usage("usage: show-date <seconds> <zone>");
+
+ if (argv[2][0] == '-')
+ offset = -offset;
+
+ offset = 60 * (offset % 100 + (offset / 100 * 60));
+
+ t += offset;
+ gmtime_r(&t, &tm);
+
+ printf("%s, %d %s %04d %02d:%02d:%02d %s\n",
+ weekday_names[tm.tm_wday], tm.tm_mday, month_names[tm.tm_mon],
+ tm.tm_year+1900, tm.tm_hour, tm.tm_min, tm.tm_sec, argv[2]);
+ return 0;
+}
--
dwmw2
^ permalink raw reply
* Re: Yet another base64 patch
From: David A. Wheeler @ 2005-04-18 5:13 UTC (permalink / raw)
To: Petr Baudis; +Cc: Paul Jackson, git
In-Reply-To: <20050417181935.GD1461@pasky.ji.cz>
I said:
>>I'd look at some of the more constraining, yet still
>>common cases, and make sure it worked reasonably
>>well without requiring magic. My list would be:
>>ext2, ext3, NFS, and Windows' NTFS (stupid short filenames,
>>case-insensitive/case-preserving).
Petr Baudis replied:
> I personally don't mind getting it work on more places, if it doesn't
> make git work (measurably) worse on modern Linux systems, the code will
> not go to hell, you tell me what needs to be done and preferably give me
> the patches. ;-)
Okay, that's great.
The one potential issue I know of (after trying to read from the
firehose^Wlist archives) is that some are worried about poor filesystems
when there are a large number of objects in an object directory.
After doing some calculations, it seems to me that perhaps this
isn't really such a big deal, if there's a top directory such as
the 16-bit (2-char) top directory currently in git-pasky.
Removing the top directory would improve performance for the better
filesystems, but would be an absolute KILLER to poorer systems, so
I'd keep the 2**8 top directory just as it is in git-pasky.
It's a compromise that means people can ease into git, and then
switch when their projects grow to large sizes.
My calculations are below, but I could be mistaken; let me
know if I'm all wet.
Does anyone know of any other issues in how git data is stored that
might cause problems for some situations? Windows' case-insensitive/
case-preserving model for NTFS and vfat32 seems to be enough
(since the case is preserved) so that the format should work,
and you can just demand that
special git files use Unix formats ("/" as dir separator,
Unix end-of-lines). The implementation currently would need
change to work easily on Windows (dealing with binary opens at least,
and probably rewriting the shell programs for those unwilling to
install Cygwin), but those can be done later if desired
without interfering with the interface formats.
========================= Details =========================
Basically, I'd like "git" to work on:
(1) nearly ANY system on small-to-medium projects,
even if their filesystems do linear searches in directories,
over a lengthy time. Ideally possibly (though poorly)
on larger systems.
(2) work well on large projects (e.g., kernel) on _common_
development platforms (ext2, ext3, NTFS, NFS).
It all depends on what you're optimizing for; but humor me
if those were your requirements...
Case 1:
The top (2-char) directory appears likely to make small projects
perform okay, and large projects possible, on stupid filesystems.
The one level extra directory is actually not a bad compromise
to make things "just work" on just about anything for smaller scales.
* git-paskey (a tiny project) has ~2K objects in 2weeks; at that pace,
4Kobjects/month for 10 years, you'd have 480K objects.
That's absurd for even tiny projects, and it's unlikely that
a participant in a tiny project would be willing to change
filesystems just to participate. But then if you
divide it among 256 directories = 1875 files/directory average.
Linear search is undesirable (about 1000 entry checks on
average to find each entry), but it's nowhere near the
2^16 dir entries that made people afraid.
Switching to a 2^12 top directory, you have an average of 117 entries
in each subdir (and 4096 entries at the top), yielding
an average of (117+4096)/2 = 2106 entry checks to find an entry.
* I estimated also for the big end, using the Linux kernel;
I guesstimated 36,000 objects/month for the kernel**. Over 10 years that
accumulates 4,320,000 objects, completely insane for a flat file
on a stupid filesystem. If it has a one-level 256dir directory, that's
16875 objects/directory. Now THAT'S painful,
though nowhere near the 2^16 limit most quoted as bad.
* For 10K objects/month, and a top dir of 2**8, you have 1,200,000
objects; each dir has 4680 entries (average lookup: 2468 entries).
Dividing into 2**12 has 292/directory, average lookup: 2194.
On 2**12 vs. 2**8, it's not clear-cut. 2**8 works best for small
projects, 2**12 for larger. My guess is that stupid filesystems
will tend to be used primarily only on small projects, so 2**8 might
be the better choice but that's debatable.
Case 2:
Thankfully adequate systems are finally more common, and they're
common enough that for really large projects (kernel) it seems
reasonable to demand such filesystems.
Ext2 & ext3 have had htree for a while now, and it's enabled by
default on at least Fedora Core 3. If it's off, just do:
tune2fs -O dir_index /dev/hdFOO; e2fsck -fD /dev/hdFOO
This stuff has been around so long that it should just be
a trivial command by any developer today.
ReiserFS has hashing too. Windows' NTFS does
tree-balancing (it appears not as good as the hashing htree
system of ext2/ext3, but it should work tolerably since it's no
longer a linear search). One useful factoid: For good NTFS
performance with git on large projects,
you should disable short name generation on the big directories
(Microsoft recommends this when >300,000 names are in one dir).
NTFS (and VFAT32) allow filenames up to 255 chars, and
filepaths up to 260 chars, so that seems okay.
I was primarily concerned about NTFS, and that seems to have
the necessities. This info should in some FAQ or
documentation ("Using git for large projects").
It _seems_ to me that the NFS implementations are likely to
do similar things, but I don't know. And I've not tested
anything on real systems, which is the real test.
Anyone know more about the limits of the NFS implementations?
More directory levels could be created to make
stupid filesystems happier, but that interferes with smart filesystems.
You could try to make filesystem layout a per-user issue,
but that makes using rsync more complicated.
A link farm could be created, though those are a pain to maintain.
It DOES turn out there are many alternatives if necesary, e.g.,
configurations per object database, or automatically "fixing"
things for a local configuration as data comes in or out,
though if you can avoid that it'd be better.
** Looking at "linux-2.4.0-to-2.6.12-rc2-patchset", I count
28237 patches; "RCS file:" occurs 188119 times & I'll claim
that that approximates the number of different file objects
IF there were no intermediate files. If on average there are
5 versions of a file before it gets into the mainline,
and 3 commits before the final mainline patch, I get
approximately this many objects in a "real" object db:
(28237*(3+1) trees) *2 (if #commits==#trees) +
(188119*(5+1) file objs))
= 1,354,610 objects from 2002/02/05 to 2005/04/04
= about 36,000 objects/month.
Am I missing anything?
--- David A. Wheeler
^ permalink raw reply
* Re: [4/5] Add option for hardlinkable cache of extracted blobs
From: Paul Jackson @ 2005-04-18 4:49 UTC (permalink / raw)
To: Petr Baudis; +Cc: barkalow, git
In-Reply-To: <20050418014858.GI1461@pasky.ji.cz>
Pasky wrote:
> It has some room for more
> crystal-clearness, though. ;-)
True indeed ;).
--
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: fix mktemp (remove mktemp ;)
From: Paul Jackson @ 2005-04-18 4:47 UTC (permalink / raw)
To: Herbert Xu; +Cc: pasky, git, mj
In-Reply-To: <E1DNMVX-00013d-00@gondolin.me.apana.org.au>
Herbert wrote:
> mktemp(1) creates the file before exiting. ... O_EXCL
Aha - right you are. Thanks for pointing that out.
--
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
* [PATCH] Add help details to git help command.
From: Steven Cole @ 2005-04-18 4:42 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
There's a patch at the bottom of this, so please look at that first before
my reading my whining immediately below.
I'm having some troubles with git pull, so this is just an ordinary diff.
Otherwise, I would have used the in-house diff command.
<troubles>
patch: **** Only garbage was found in the patch input.
</troubles>
<more troubles>
Tracked branch, applying changes...
error: bad signature
error: verify header failed
read_cache: Invalid argument
error: bad signature
error: verify header failed
error: bad signature
error: verify header failed
</more troubles>
Anyway, it's late, and I'm sure there is an easy fix to the above.
Here is a patch which provides the comment lines in the associated
script files when the git help command is invoked with an argument
thusly:
[steven@spc git-pasky-new]$ ./git help merge
Merge a branch to the current tree.
Copyright (c) Petr Baudis, 2005
Takes a parameter identifying the branch to be merged.
Optional "-b base_commit" parameter specifies the base for the
merge. "-a" parameter may come first to tell git merge
to check out the full tree to the merge tree.
It creates a new ,,merge/ directory, which is git-controlled
but has only the changed files checked out. You then have to
examine it and then do git commit, which will also automatically
bring your working tree up-to-date.
---------
This patch will provide the comment lines in the shell script associated
with the command, cleaned up a bit for presentation.
BUGS: This will also print any comments in the entire file, which may
not be desired. If a command name and shell script filename
do not follow the usual convention, this won't work, e.g. ci for commit.
Signed-off-by: Steven Cole <elenstev@mesatop.com>
--- gp-newest-orig/git 2005-04-17 22:16:55.000000000 -0600
+++ gp-newest/git 2005-04-17 22:19:49.000000000 -0600
@@ -19,6 +19,11 @@
help () {
+
+command=$1
+scriptfile=git$command.sh
+
+if [ ! $command ]; then
cat <<__END__
The GIT scripted toolkit $(gitversion.sh)
@@ -48,7 +53,10 @@
update COMMIT_ID
version
+Additional help is available with: git help COMMAND
+
Note that these expressions can be used interchangably as "ID"s:
+
empty string (current HEAD)
local (the local branch if tracking a remote one)
remote name (as registered with git addremote)
@@ -57,6 +65,10 @@
commit object hash (as returned by commit-id)
tree object hash (accepted only by some commands)
__END__
+fi
+if [ ! $scriptfile = "git.sh" ]; then
+grep ^# $scriptfile | grep -v "!/bin" | cut -c 2-
+fi
}
^ permalink raw reply
* Re: [RFC] General object parsing
From: David Woodhouse @ 2005-04-18 4:45 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Daniel Barkalow, Petr Baudis, git
In-Reply-To: <Pine.LNX.4.58.0504171807590.7211@ppc970.osdl.org>
On Sun, 2005-04-17 at 18:15 -0700, Linus Torvalds wrote:
> In particular, is there some easy way to walk backwards by time? "git log"
> definitely needs that, and merge-base clearly wants something similar.
Actually the ideal output of 'git log' isn't strictly chronological.
IIRC my bkexport scripts used to make a chronologically sorted list, and
I ended up changing it.
Simple example: if there are changesets which have been lurking in some
tree for months waiting for you to pull, and the only thing you did
since I ran 'git log' on your tree yesterday is pull from that tree,
then those changesets are what I want to see at the top of 'git log'
output.
In fact this probably means that the depth-first tree walking of the
original gitlog.sh is probably the right thing to do, but when we hit a
merge we want to try to make sure we process the _remote_ parent first.
Are we sorting the 'parent' links in merges so that two merges of the
same branches are guaranteed to be identical (assuming identical
contents otherwise)? Or is it just that we didn't think about it, and so
merges are putting the local and remote parents in the 'wrong' order by
coincidence?
--
dwmw2
^ permalink raw reply
* Re: using git directory cache code in darcs?
From: Paul Jackson @ 2005-04-18 4:36 UTC (permalink / raw)
To: Linus Torvalds; +Cc: droundy, git, darcs-devel
In-Reply-To: <Pine.LNX.4.58.0504172005450.7211@ppc970.osdl.org>
> Not until all the data structures are really really stable.
Fine by me to wait, though perhaps not for the same reason, and perhaps
not as long.
A libgit.so can deal with data structure changes just as well as a set
of command line utilities. So long as everything funnels through one
place, you can change by changing that one place.
However I am willing to agree that its not libgit time yet, for two
reasons:
1) everyone who has two clues on the subject is too busy and
too productive on more pressing git issues, and
2) in addition to internal data structures being not yet stable,
I suspect that the operations (git commands, options and
behaviour) are also not stable.
The first step of a good libgit is not coding to the internal data
structures, but rather designing the interface (the operations,
arguments, data types, and behaviour).
So, until people have time, and the interface ops are settled down, its
too early to design libgit. Or at least too early to publish a design
and seek concensus. If I had the time the first thing I'd be doing
right now would be designing libgit on the side, anticipating the day
when it was time to publish a draft and engage the community discussion
that leads to an adequate concensus.
===
By the way, a good libgit design, in my view, would isolate the data
structures written to files below .git from the data structures
presented at the library API, to some extent. Changes in the file
structures must be handled without disrupting the library API.
If a libgit API didn't isolate the library caller from details of the
structures in files below .git, then yes you'd want really really stable
data structures, impossibly stable in fact. That way leads to hacks and
workarounds in the future, because the data structures are never
perfectly stable.
--
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: Merge with git-pasky II.
From: Sanjoy Mahajan @ 2005-04-18 4:16 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Ingo Molnar, Petr Baudis, Simon Fowler, David Lang, git
In-Reply-To: <Pine.LNX.4.58.0504171014430.7211@ppc970.osdl.org>
> So until proven otherwise, I worry about accidental hashes, and in
> 160 bits of good hashing, that just isn't an issue either...[Going
> from 128 bits to 160 bits made it] so _unbelievably_ less likely to
> happen that it's not even funny.
You are right. Here's how I learnt to stop worrying and love the 160
bits.
A 160-bit hash requires 2^80=10^24 files before the collision
probability is roughly 0.5 (actually 1-e^{-1/2}). Now be very
conservative: Instead of tolerating a 0.5 probability, worry about
even a 10^-8 probability of a collision anywhere, anytime.
The magic number of files for that probability is 10^20 (roughly 10^40
pairs for 2^160=10^48 boxes).
Given 10 billion people using git, each producing 1 source file per
second -- busy beavers all -- they would need 300 years to produce
10^20 files. And to reach the 10^-8 collision probability, all 10^20
files must belong to the same project, and even OpenOffice will not be
that bloated.
-Sanjoy
^ permalink raw reply
* Re: [PATCH] use gcrypt instead of libssl for hash
From: Edgar Toernig @ 2005-04-18 3:58 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junichi Uekawa, git
In-Reply-To: <Pine.LNX.4.58.0504171039460.7211@ppc970.osdl.org>
Linus Torvalds wrote:
>
> Well, libgcrypt seems to be pretty rare out there - I certainly don't have
> it installed on my machine.
Well, I don't even have openssl ...
> Or merge the SHA1 code from the kernel, even, and make the project
> entirely self-sufficient.
... so I took the sha1 code from Firefox (it's MPL or GPL - you choose).
Here's the patch.
diff -ruN git-0.04-orig/Makefile git-0.04/Makefile
--- git-0.04-orig/Makefile Mon Apr 11 05:48:10 2005
+++ git-0.04/Makefile Mon Apr 18 05:41:49 2005
@@ -9,42 +9,57 @@
install: $(PROG)
install $(PROG) $(HOME)/bin/
-LIBS= -lssl -lz
+LIBS= -lz
init-db: init-db.o
-update-cache: update-cache.o read-cache.o
- $(CC) $(CFLAGS) -o update-cache update-cache.o read-cache.o $(LIBS)
+update-cache: update-cache.o read-cache.o sha1.o
+ $(CC) $(CFLAGS) -o update-cache update-cache.o read-cache.o sha1.o $(LIBS)
-show-diff: show-diff.o read-cache.o
- $(CC) $(CFLAGS) -o show-diff show-diff.o read-cache.o $(LIBS)
+show-diff: show-diff.o read-cache.o sha1.o
+ $(CC) $(CFLAGS) -o show-diff show-diff.o read-cache.o sha1.o $(LIBS)
-write-tree: write-tree.o read-cache.o
- $(CC) $(CFLAGS) -o write-tree write-tree.o read-cache.o $(LIBS)
+write-tree: write-tree.o read-cache.o sha1.o
+ $(CC) $(CFLAGS) -o write-tree write-tree.o read-cache.o sha1.o $(LIBS)
-read-tree: read-tree.o read-cache.o
- $(CC) $(CFLAGS) -o read-tree read-tree.o read-cache.o $(LIBS)
+read-tree: read-tree.o read-cache.o sha1.o
+ $(CC) $(CFLAGS) -o read-tree read-tree.o read-cache.o sha1.o $(LIBS)
-commit-tree: commit-tree.o read-cache.o
- $(CC) $(CFLAGS) -o commit-tree commit-tree.o read-cache.o $(LIBS)
+commit-tree: commit-tree.o read-cache.o sha1.o
+ $(CC) $(CFLAGS) -o commit-tree commit-tree.o read-cache.o sha1.o $(LIBS)
-cat-file: cat-file.o read-cache.o
- $(CC) $(CFLAGS) -o cat-file cat-file.o read-cache.o $(LIBS)
+cat-file: cat-file.o read-cache.o sha1.o
+ $(CC) $(CFLAGS) -o cat-file cat-file.o read-cache.o sha1.o $(LIBS)
-fsck-cache: fsck-cache.o read-cache.o
- $(CC) $(CFLAGS) -o fsck-cache fsck-cache.o read-cache.o $(LIBS)
+fsck-cache: fsck-cache.o read-cache.o sha1.o
+ $(CC) $(CFLAGS) -o fsck-cache fsck-cache.o read-cache.o sha1.o $(LIBS)
-checkout-cache: checkout-cache.o read-cache.o
- $(CC) $(CFLAGS) -o checkout-cache checkout-cache.o read-cache.o $(LIBS)
+checkout-cache: checkout-cache.o read-cache.o sha1.o
+ $(CC) $(CFLAGS) -o checkout-cache checkout-cache.o read-cache.o sha1.o $(LIBS)
-diff-tree: diff-tree.o read-cache.o
- $(CC) $(CFLAGS) -o diff-tree diff-tree.o read-cache.o $(LIBS)
-
-read-cache.o: cache.h
-show-diff.o: cache.h
+diff-tree: diff-tree.o read-cache.o sha1.o
+ $(CC) $(CFLAGS) -o diff-tree diff-tree.o read-cache.o sha1.o $(LIBS)
clean:
rm -f *.o $(PROG) temp_git_file_*
backup: clean
cd .. ; tar czvf dircache.tar.gz dir-cache
+
+depend:
+ makedepend -Y -- -- *.c 2>/dev/null
+
+# DO NOT DELETE
+
+cat-file.o: cache.h sha1.h
+checkout-cache.o: cache.h sha1.h
+commit-tree.o: cache.h sha1.h
+diff-tree.o: cache.h sha1.h
+fsck-cache.o: cache.h sha1.h
+init-db.o: cache.h sha1.h
+read-cache.o: cache.h sha1.h
+read-tree.o: cache.h sha1.h
+sha1.o: sha1.h
+show-diff.o: cache.h sha1.h
+update-cache.o: cache.h sha1.h
+write-tree.o: cache.h sha1.h
diff -ruN git-0.04-orig/cache.h git-0.04/cache.h
--- git-0.04-orig/cache.h Sun Apr 10 20:19:02 2005
+++ git-0.04/cache.h Mon Apr 18 05:46:47 2005
@@ -11,7 +11,7 @@
#include <errno.h>
#include <sys/mman.h>
-#include <openssl/sha.h>
+#include "sha1.h"
#include <zlib.h>
/*
diff -ruN git-0.04-orig/sha1.c git-0.04/sha1.c
--- git-0.04-orig/sha1.c Thu Jan 1 01:00:00 1970
+++ git-0.04/sha1.c Mon Apr 18 05:40:25 2005
@@ -0,0 +1,152 @@
+/*
+ * The contents of this file are subject to the Mozilla Public
+ * License Version 1.1 (the "License"); you may not use this file
+ * except in compliance with the License. You may obtain a copy of
+ * the License at http://www.mozilla.org/MPL/
+ *
+ * Software distributed under the License is distributed on an "AS
+ * IS" basis, WITHOUT WARRANTY OF ANY KIND, either express or
+ * implied. See the License for the specific language governing
+ * rights and limitations under the License.
+ *
+ * The Original Code is SHA 180-1 Reference Implementation (Compact version)
+ *
+ * The Initial Developer of the Original Code is Paul Kocher of
+ * Cryptography Research. Portions created by Paul Kocher are
+ * Copyright (C) 1995-9 by Cryptography Research, Inc. All
+ * Rights Reserved.
+ *
+ * Contributor(s):
+ *
+ * Paul Kocher
+ *
+ * Alternatively, the contents of this file may be used under the
+ * terms of the GNU General Public License Version 2 or later (the
+ * "GPL"), in which case the provisions of the GPL are applicable
+ * instead of those above. If you wish to allow use of your
+ * version of this file only under the terms of the GPL and not to
+ * allow others to use your version of this file under the MPL,
+ * indicate your decision by deleting the provisions above and
+ * replace them with the notice and other provisions required by
+ * the GPL. If you do not delete the provisions above, a recipient
+ * may use your version of this file under either the MPL or the
+ * GPL.
+ */
+
+#include "sha1.h"
+
+static void shaHashBlock(SHA_CTX *ctx);
+
+void SHA1_Init(SHA_CTX *ctx) {
+ int i;
+
+ ctx->lenW = 0;
+ ctx->sizeHi = ctx->sizeLo = 0;
+
+ /* Initialize H with the magic constants (see FIPS180 for constants)
+ */
+ ctx->H[0] = 0x67452301;
+ ctx->H[1] = 0xefcdab89;
+ ctx->H[2] = 0x98badcfe;
+ ctx->H[3] = 0x10325476;
+ ctx->H[4] = 0xc3d2e1f0;
+
+ for (i = 0; i < 80; i++)
+ ctx->W[i] = 0;
+}
+
+
+void SHA1_Update(SHA_CTX *ctx, void *_dataIn, int len) {
+ unsigned char *dataIn = _dataIn;
+ int i;
+
+ /* Read the data into W and process blocks as they get full
+ */
+ for (i = 0; i < len; i++) {
+ ctx->W[ctx->lenW / 4] <<= 8;
+ ctx->W[ctx->lenW / 4] |= (unsigned int)dataIn[i];
+ if ((++ctx->lenW) % 64 == 0) {
+ shaHashBlock(ctx);
+ ctx->lenW = 0;
+ }
+ ctx->sizeLo += 8;
+ ctx->sizeHi += (ctx->sizeLo < 8);
+ }
+}
+
+
+void SHA1_Final(unsigned char hashout[20], SHA_CTX *ctx) {
+ unsigned char pad0x80 = 0x80;
+ unsigned char pad0x00 = 0x00;
+ unsigned char padlen[8];
+ int i;
+
+ /* Pad with a binary 1 (e.g. 0x80), then zeroes, then length
+ */
+ padlen[0] = (unsigned char)((ctx->sizeHi >> 24) & 255);
+ padlen[1] = (unsigned char)((ctx->sizeHi >> 16) & 255);
+ padlen[2] = (unsigned char)((ctx->sizeHi >> 8) & 255);
+ padlen[3] = (unsigned char)((ctx->sizeHi >> 0) & 255);
+ padlen[4] = (unsigned char)((ctx->sizeLo >> 24) & 255);
+ padlen[5] = (unsigned char)((ctx->sizeLo >> 16) & 255);
+ padlen[6] = (unsigned char)((ctx->sizeLo >> 8) & 255);
+ padlen[7] = (unsigned char)((ctx->sizeLo >> 0) & 255);
+ SHA1_Update(ctx, &pad0x80, 1);
+ while (ctx->lenW != 56)
+ SHA1_Update(ctx, &pad0x00, 1);
+ SHA1_Update(ctx, padlen, 8);
+
+ /* Output hash
+ */
+ for (i = 0; i < 20; i++) {
+ hashout[i] = (unsigned char)(ctx->H[i / 4] >> 24);
+ ctx->H[i / 4] <<= 8;
+ }
+
+ /*
+ * Re-initialize the context (also zeroizes contents)
+ */
+ SHA1_Init(ctx);
+}
+
+
+#define SHA_ROT(X,n) (((X) << (n)) | ((X) >> (32-(n))))
+
+static void shaHashBlock(SHA_CTX *ctx) {
+ int t;
+ unsigned int A,B,C,D,E,TEMP;
+
+ for (t = 16; t <= 79; t++)
+ ctx->W[t] =
+ SHA_ROT(ctx->W[t-3] ^ ctx->W[t-8] ^ ctx->W[t-14] ^ ctx->W[t-16], 1);
+
+ A = ctx->H[0];
+ B = ctx->H[1];
+ C = ctx->H[2];
+ D = ctx->H[3];
+ E = ctx->H[4];
+
+ for (t = 0; t <= 19; t++) {
+ TEMP = SHA_ROT(A,5) + (((C^D)&B)^D) + E + ctx->W[t] + 0x5a827999;
+ E = D; D = C; C = SHA_ROT(B, 30); B = A; A = TEMP;
+ }
+ for (t = 20; t <= 39; t++) {
+ TEMP = SHA_ROT(A,5) + (B^C^D) + E + ctx->W[t] + 0x6ed9eba1;
+ E = D; D = C; C = SHA_ROT(B, 30); B = A; A = TEMP;
+ }
+ for (t = 40; t <= 59; t++) {
+ TEMP = SHA_ROT(A,5) + ((B&C)|(D&(B|C))) + E + ctx->W[t] + 0x8f1bbcdc;
+ E = D; D = C; C = SHA_ROT(B, 30); B = A; A = TEMP;
+ }
+ for (t = 60; t <= 79; t++) {
+ TEMP = SHA_ROT(A,5) + (B^C^D) + E + ctx->W[t] + 0xca62c1d6;
+ E = D; D = C; C = SHA_ROT(B, 30); B = A; A = TEMP;
+ }
+
+ ctx->H[0] += A;
+ ctx->H[1] += B;
+ ctx->H[2] += C;
+ ctx->H[3] += D;
+ ctx->H[4] += E;
+}
+
diff -ruN git-0.04-orig/sha1.h git-0.04/sha1.h
--- git-0.04-orig/sha1.h Thu Jan 1 01:00:00 1970
+++ git-0.04/sha1.h Mon Apr 18 05:40:25 2005
@@ -0,0 +1,45 @@
+/*
+ * The contents of this file are subject to the Mozilla Public
+ * License Version 1.1 (the "License"); you may not use this file
+ * except in compliance with the License. You may obtain a copy of
+ * the License at http://www.mozilla.org/MPL/
+ *
+ * Software distributed under the License is distributed on an "AS
+ * IS" basis, WITHOUT WARRANTY OF ANY KIND, either express or
+ * implied. See the License for the specific language governing
+ * rights and limitations under the License.
+ *
+ * The Original Code is SHA 180-1 Header File
+ *
+ * The Initial Developer of the Original Code is Paul Kocher of
+ * Cryptography Research. Portions created by Paul Kocher are
+ * Copyright (C) 1995-9 by Cryptography Research, Inc. All
+ * Rights Reserved.
+ *
+ * Contributor(s):
+ *
+ * Paul Kocher
+ *
+ * Alternatively, the contents of this file may be used under the
+ * terms of the GNU General Public License Version 2 or later (the
+ * "GPL"), in which case the provisions of the GPL are applicable
+ * instead of those above. If you wish to allow use of your
+ * version of this file only under the terms of the GPL and not to
+ * allow others to use your version of this file under the MPL,
+ * indicate your decision by deleting the provisions above and
+ * replace them with the notice and other provisions required by
+ * the GPL. If you do not delete the provisions above, a recipient
+ * may use your version of this file under either the MPL or the
+ * GPL.
+ */
+
+typedef struct {
+ unsigned int H[5];
+ unsigned int W[80];
+ int lenW;
+ unsigned int sizeHi,sizeLo;
+} SHA_CTX;
+
+void SHA1_Init(SHA_CTX *ctx);
+void SHA1_Update(SHA_CTX *ctx, void *dataIn, int len);
+void SHA1_Final(unsigned char hashout[20], SHA_CTX *ctx);
Ciao, ET.
^ permalink raw reply
* Re: [RFC] General object parsing
From: Daniel Barkalow @ 2005-04-18 3:51 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Petr Baudis, git
In-Reply-To: <Pine.LNX.4.21.0504172206460.30848-100000@iabervon.org>
On Sun, 17 Apr 2005, Daniel Barkalow wrote:
> > But if there are simple helper functions to get the "next backwards in
> > time" case (by looking at the parent dates in a merge), then that should
> > be ok to do incrementally.
>
> Haven't written that yet, but I can do so.
Okay, I wrote this. I now have a merge-base that will find the most recent
ancestor while never looking at any parents of any commit older than the
answer. (But I'll let the previous stuff get reviewed first)
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: using git directory cache code in darcs?
From: Linus Torvalds @ 2005-04-18 3:06 UTC (permalink / raw)
To: Paul Jackson; +Cc: git, droundy, darcs-devel
In-Reply-To: <20050417195600.6894e576.pj@sgi.com>
On Sun, 17 Apr 2005, Paul Jackson wrote:
>
> I'd encourage you to invite someone to provide a libgit.
Not until all the data structures are really really stable.
That's the thing - we can keep the _program_ interfaces somewhat stable.
But internally we may change stuff wildly, and anybody who depends on a
library interface would be screwed.
Ergo: no library interfaces yet. Wait for it to stabilize. Start trying to
just script the programs.
Linus
^ permalink raw reply
* Re: [PATCH] "checkout-cache -m" writes unmerged contents for each stage.
From: Linus Torvalds @ 2005-04-18 3:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk6n0vnbq.fsf@assigned-by-dhcp.cox.net>
On Sun, 17 Apr 2005, Junio C Hamano wrote:
>
> LT> What do you think? I can whip up a "merge-cache" program like that in five
> LT> minutes, and it _seems_ like the right interface..
>
> Yes. I think that is the right thing to do. In fact the idea
> is quite similar to what I've been working on, which is a
> rewrite of that perl thing to use "read-tree -m O A B".
I pushed the thing out. It was indeed pretty trivial.
Just as an example, on your merge-test, I can then do
merge-cache echo -a
and the output is
.merge_file_Raanu4 .merge_file_q7ZoLY AA
.merge_file_zMXLAW .merge_file_SOugrU AN
.merge_file_tWf5zS DD
.merge_file_YmGzgR DM
.merge_file_N1M8oO DN
.merge_file_eAC5WL .merge_file_ROg7mM MD
.merge_file_G1AWSM .merge_file_LMCruN .merge_file_ucVx7N MM
.merge_file_3YxD2O NA
.merge_file_2SJa6P .merge_file_3V5g6Q ND
.merge_file_SIo4nQ S/DD
.merge_file_dO8AOP S/DM
.merge_file_wOO6iP S/DN
.merge_file_RrgnYR .merge_file_KQxqHU S/MD
.merge_file_F0sQRX .merge_file_E4DC00 .merge_file_HQkyn2 S/MM
.merge_file_od0mf4 .merge_file_Xvv035 S/ND
.merge_file_oEtq17 .merge_file_TwkT5c .merge_file_aqx58h Trivial
(Note that the spaces signify an empty argument in those places, since the
file in question didn't always exist). It executed the "echo" thing 16
times (once for each object that your script-from-hell had caused a clash
with).
In all cases you have $1 being "original", $2 being "branch 1", $3 being
"branch 2", and $4 being "name in cache".
ALERT ALERT ALERT! The git "merge object order" is different from the
"merge" program merge object order. In the above ordering, the original is
first. But the argument order to the 3-way merge program "merge" is to
have the original in the middle. Don't ask me why.
Anyway, another example:
torvalds@ppc970:~/merge-test> merge-cache cat MM
This is MM from the original tree. # original
This is modified MM in the branch A. # merge1
This is modified MM in the branch B. # merge2
This is modified MM in the branch B. # current contents
or
torvalds@ppc970:~/merge-test> merge-cache cat AA MM
cat: : No such file or directory
This is added AA in the branch A.
This is added AA in the branch B.
This is added AA in the branch B.
fatal: merge program failed
where the latter example shows how "merge-cache" will stop trying to merge
once anything has returned an error (ie "cat" returned an error for the AA
file, because it didn't exist in the original, and thus "merge-cache"
didn't even try to merge the MM thing).
Linus
^ permalink raw reply
* Re: fix mktemp (remove mktemp ;)
From: Herbert Xu @ 2005-04-18 3:01 UTC (permalink / raw)
To: Paul Jackson; +Cc: pasky, git, mj
In-Reply-To: <20050416170221.38b3e66c.pj@sgi.com>
Paul Jackson <pj@sgi.com> wrote:
>
> Even mktemp(1) can collide, in theory, since there is no practical way
> in shell scripts to hold open and locked the file from the instant of it
> is determined to be a unique name.
mktemp(1) creates the file before exiting. Other instances of mktemp(1)
cannot successfully create the same file (they all use O_EXCL).
Therefore this race does not exist, even in theory :)
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: using git directory cache code in darcs?
From: Paul Jackson @ 2005-04-18 2:56 UTC (permalink / raw)
To: Linus Torvalds; +Cc: droundy, git, darcs-devel
In-Reply-To: <Pine.LNX.4.58.0504170916080.7211@ppc970.osdl.org>
Linus wrote:
> But then I'd really suggest that you use "git" itself, not any
> "libgit". Ie you take _all_ the plumbing as real programs, and instead of
> trying to link against individual routines, you'd _script_ it.
I think you've got this upside down, Linus.
Trying to make the executable 'git' commands the bottom layer of the
user implementation stack forces inefficiencies on higher layers
of the stack, and thus encourages stupid workarounds and cheats in
an effort to speed things up.
I'd encourage you to invite someone to provide a libgit.
Such work should _start_ with proposing and gaining acceptance on the
API - the calls, the arguments, the types, the rough idea of the
semantics. The actual coding is the easy part. One is not slave to the
agreed API when coding. The API will continue to evolve, but if the
originally accepted proposal was sound, the evolution will be at a
modest rate, with few incompatibilities introduced.
If several operations should be done as a unit, to preserve the
integrity of the .git data or to provide sane results, then libgit need
only provide such pre-packaged units, not the incomplete fragments from
which they are composed. That is, the libgit calls could quite possibly
be at roughly the same semantic level as your git commands. One could
even code up some of the libgit calls, in early versions of libgit, by
simply invoking the corresponding git command. But, eventually, all the
git commands should be recoded on top of the libgit library, and the
libgit library become the canonical user interface to git, on which all
else is layered.
One typical way that this choice manifests itself is in the strace
output from doing some ordinary git command from a C program that is
implementing an SCM system on top of git. Forcing every operation to be
done via a separate git command execution mushrooms the number of kernel
system calls a hundred fold, or two hundred fold if some dang fool uses
system(3S) to invoke the git command. What might have been a handful of
calls to stat/open/read/write/close a file turns into a mini-shell
session. That way lies insanity, or at least painful inefficiency, and
the usual parade of bugs, stupid coding tricks and painful user
interfaces that follow in the wake.
The recommended layering of such user facilities is well known, with a C
library at the bottom. Granted, the history of source code management
tools provides few examples of this recommended layering.
On top of this library go plugin modules for the fancier scripting
languages that accept such. Swig can be used to aid this construction,
for Tcl, Python, Perl, Guile, Java, Ruby, Mzscheme, PHP, Ocaml, Pike,
C#, Chicken Allegro CL, Modula-3, Javascript and Eiffel. Though I
personally have not worked with Swig enough to gain success with it.
The only such modules I've done were handcoded Python modules.
Also on top of this library one provides a set of command line utilities
or one multiplexed 'git foo ...' command, for use at shell prompts. Or
the command line utilities can be coded in one of the above higher level
scripting languages, using in turn the git library plugin. However many
of these scripting languages bring runtime requirements that are not
universally satisfied on all target systems, so are a poor choice for
this purpose.
If I am recalling correctly, from the days when I regularly used bk, one
of the things that Larry did right with bk, which RCS and SCCS did not
do right before then, was to provide a low level library to his storage
- a cleanroom recoded variant of SCCS in his case.
Implementing production source control systems on top of a set of
executable commands is a pain in the arse. An all too familiar pain.
I'd repeat my encouragement that you invite someone to provide such a
libgit, however since I have other commitments for the next month at
least, so can't volunteer right away, if ever, it is more appropriate
that I shut up now, under the old "put up code or be quiet" rule.
--
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
* yet another gitting started
From: randy_dunlap @ 2005-04-18 2:55 UTC (permalink / raw)
To: git
Here's the beginnings of yet another git usage/howto/tutorial.
It can grow or die... I'll gladly take patches for it,
or Pasky et al can merge more git plumbing and toilet usages
into it, with or without me.
http://www.xenotime.net/linux/doc/git-usage-howto
---
~Randy
^ permalink raw reply
* Re: [PATCH] "checkout-cache -m" writes unmerged contents for each stage.
From: Linus Torvalds @ 2005-04-18 2:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfyxovm6j.fsf@assigned-by-dhcp.cox.net>
On Sun, 17 Apr 2005, Junio C Hamano wrote:
>
> One small detail. What about the "-x" bit?
You'll need to merge those kinds of changes separately for now. We'll have
to resolve that too, right now I think the -x bit gets lost on a merge
simply because we just write the temp-files, something merges them, and
does an "update-cache" on the merged result, and we'll pick up the -x bit
(or rather, lack of one) at that point.
Linus
^ 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