This patch makes diff-tree accept either tree or commit.
Signed-off-by: Junio C Hamano [EMAIL PROTECTED]
---
diff-tree.c | 12 +++-
1 files changed, 7 insertions(+), 5 deletions(-)
--- a/diff-tree.c
+++ b/diff-tree.c
@@ -160,18 +160,20 @@ static int diff_tree(void *tree1, unsign
This patch makes read-tree accept either tree or commit.
Signed-off-by: Junio C Hamano [EMAIL PROTECTED]
---
read-tree.c |4 +---
1 files changed, 1 insertion(+), 3 deletions(-)
Makefile: needs update
--- a/read-tree.c
+++ b/read-tree.c
@@ -29,11 +29,9 @@ static int read_tree(unsigned char
This patch makes ls-tree accept either tree or commit.
Signed-off-by: Junio C Hamano [EMAIL PROTECTED]
---
ls-tree.c |2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
Makefile: needs update
cache.h: needs update
sha1_file.c: needs update
--- a/ls-tree.c
+++ b/ls-tree.c
@@ -74,7 +74,7
cover-paragraph
_BLUSH_
The 1/4 in the series was a buggy one I sent by mistake. Please
replace it with this fixed one. The other three are OK.
BTW, do you have a preferred patch-mail convention to mark the
cover paragraph like this to be excluded from the commit log,
like the three-dash one
On Tue, 19 Apr 2005, Chris Mason wrote:
I'll finish off the patch once you ok the basics below. My current code
works
like this:
Chris, before you do anything further, let me re-consider.
Assuming that the real cost of write-tree is the compression (and I think
it is), I really suspect
* Petr Baudis [EMAIL PROTECTED] wrote:
I think pull is pull. If you are doing lots of local stuff and do not
want it overwritten, it should have been in a forked branch.
I disagree. This already forces you to have two branches (one to pull
from to get the data, mirroring the remote
Linus Torvalds wrote:
So I'll see if I can turn the current fsck into a convert into
uncompressed format, and do a nice clean format conversion.
Just let me know what you want to do, and I can trivially change the
conversion scripts I've already written to do what you want.
-hpa
-
To
* Linus Torvalds [EMAIL PROTECTED] wrote:
On Wed, 13 Apr 2005, Ingo Molnar wrote:
well, the 'owned by another user' solution is valid though, and doesnt
have this particular problem. (We've got a secure multiuser OS, so can
as well use it to protect the DB against corruption.)
So
This patch changes identical cut-and-paste usage strings into a
single instance of static string, to make maintenance easier.
Signed-off-by: Junio C Hamano [EMAIL PROTECTED]
---
commit-tree.c | 14 ++
diff-cache.c |6 --
diff-tree.c |6 --
read-tree.c | 10
* Ingo Molnar [EMAIL PROTECTED] wrote:
perhaps having a new 'immutable hardlink' feature in the Linux VFS
would help? I.e. a hardlink that can only be readonly followed, and
can be removed, but cannot be chmod-ed to a writeable hardlink. That i
think would be a large enough barrier for
Hi,
thanks to my friend Frank Sattelberger I got access to a site where I
could set up a demo for wit:
http://grmso.net:8090
Couple of notes wrt why I work on another git web interface compared
with Kay's work:
* I was already experimenting and implementing for a couple of days when
Kay's tool
As shipped, the example git-merge-one-file-script often leaves
the merge result with not-so-useful mode bits, especially with
glibc 2.0.7 or later whose mkstemp() creates temporary file with
mode 0600. This contradicts the way checkout-cache creates new
files, which is to use 0666 (or 0777 for
On Wed, 2005-04-20 at 10:42 +0100, Christoph Hellwig wrote:
On Tue, Apr 19, 2005 at 09:18:29PM -0700, Greg KH wrote:
On Wed, Apr 20, 2005 at 02:29:11AM +0200, Christian Meder wrote:
Hi,
ok it's starting to look like spam ;-)
I uploaded a new version of wit to
* Linus Torvalds [EMAIL PROTECTED] wrote:
So to convert your old git setup to a new git setup, do the following:
[...]
did this for two repositories (git and kernel-git), it works as
advertised.
Ingo
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a
`git', by Linus Torvalds, contains some very good ideas and some
very entertaining source code -- recommended reading for hackers.
/GNU Arch/ will adopt `git':
From the /Arch/ perspective: `git' technology will form the
basis of a new archive/revlib/cache format and the basis
of new network
`git', by Linus Torvalds, contains some very good ideas and some
very entertaining source code -- recommended reading for hackers.
/GNU Arch/ will adopt `git':
From the /Arch/ perspective: `git' technology will form the
basis of a new archive/revlib/cache format and the basis
of new network
Way to go.
-Miles
--
Do not taunt Happy Fun Ball.
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Apr 19, 2005 at 09:49:12AM -0700, Linus Torvalds wrote:
On Tue, 19 Apr 2005, Tupshin Harper wrote:
I suspect that any use of wildcards in a new format would be impossible
for darcs since it wouldn't allow darcs to construct dependencies,
though I'll leave it to david to respond to
On Tue, Apr 19, 2005 at 02:25:18PM +0200, Petr Baudis wrote:
Dear diary, on Tue, Apr 19, 2005 at 02:20:55PM CEST, I got a letter
where Juliusz Chroboczek [EMAIL PROTECTED] told me that...
The problem is that there is no sequence of alien versions that one
can differentiate. Git has a
On Tue, Apr 19, 2005 at 02:20:55PM +0200, Juliusz Chroboczek wrote:
[Removing Linus from CC, keeping the Git list -- or should we remove it?]
I think leaving much of this on git would be appropriate, since there are
issues of how to relate to git that should be relevant.
If we do it right
On 4/20/05, Linus Torvalds [EMAIL PROTECTED] wrote:
I converted my git archives (kernel and git itself) to do the SHA1 hash
_before_ the compression phase.
Linus,
Am I correct to understand that with this change, all the objects in
the database are still being compressed (so no net
Use a generic rule for executables that depend only on the corresponding
.o and on $(LIB_FILE).
Signed-Off-By: Andre Noll [EMAIL PROTECTED]
---
Makefile | 49 ++---
1 files changed, 2 insertions(+), 47 deletions(-)
Makefile:
On Wed, Apr 20, 2005 at 10:11:10PM +1000, Jon Seymour wrote:
On 4/20/05, Linus Torvalds [EMAIL PROTECTED] wrote:
I converted my git archives (kernel and git itself) to do the SHA1 hash
_before_ the compression phase.
Linus,
Am I correct to understand that with this change,
So I wrote up my ideas regarding blob chunking as code; see attached.
This is against git-0.4 (I know, ancient, but I had to start somewhere.)
The idea here is that blobs are chunked using a rolling checksum (so the
chunk boundaries are content-dependent and stay fixed even if you mutate
pieces
On 4/20/05, Martin Uecker [EMAIL PROTECTED] wrote:
The storage method of the database of a collection of
files in the underlying file system. Because of the
random nature of the hashes this leads to a horrible
amount of seeking for all operations which walk the
logical structure of some tree
The main point is not about trying different compression
techniques but that you don't need to compress at all just
to calculate the hash of some data. (to know if it is
unchanged for example)
Ah, ok, I didn't understand that there were extra compresses being
performed for that reason.
On Wed, 2005-04-20 at 02:08 -0700, Linus Torvalds wrote:
I converted my git archives (kernel and git itself) to do the SHA1
hash _before_ the compression phase.
I'm happy to see that -- because I'm going to be asking you to make
another change which will also require a simple repository
On Wed, 20 Apr 2005, Jon Seymour wrote:
Am I correct to understand that with this change, all the objects in the
database are still being compressed (so no net performance benefit), but by
doing the SHA1 calculations before compression you are keeping open the
possibility that at some
On Wed, Apr 20, 2005 at 10:30:15AM -0400, C. Scott Ananian wrote:
Hi,
your code looks pretty cool. thank you!
On Wed, 20 Apr 2005, Martin Uecker wrote:
The other thing I don't like is the use of a sha1
for a complete file. Switching to some kind of hash
tree would allow to introduce
On Wednesday 20 April 2005 02:43, Linus Torvalds wrote:
On Tue, 19 Apr 2005, Chris Mason wrote:
I'll finish off the patch once you ok the basics below. My current code
works like this:
Chris, before you do anything further, let me re-consider.
Assuming that the real cost of write-tree is
On Tue, 19 Apr 2005, Junio C Hamano wrote:
This patch lifts the tree-from-tree-or-commit logic from
diff-cache.c and moves it to sha1_file.c, which is a common
library source for the SHA1 storage part.
I don't think that's a good interface. It changes the sha1 passed into it:
that may
On Wed, 20 Apr 2005, Chris Mason wrote:
With the basic changes I described before, the 100 patch time only goes down
to 40s. Certainly not fast enough to justify the changes. In this case, the
bulk of the extra time comes from write-tree writing the index file, so I
split write-tree.c up into
On Wed, 20 Apr 2005, C. Scott Ananian wrote:
Hmm. Are our index files too large, or is there some other factor?
They _are_ pretty large, but they have to be,
For the kernel, the index file is about 1.6MB. That's
- 17,000+ files and filenames
- stat information for all of them
- the
On Wed, 20 Apr 2005, Linus Torvalds wrote:
I was considering using a chunked representation for *all* files (not just
blobs), which would avoid the original 'trees must reference other trees
or they become too large' issue -- and maybe the performance issue you're
referring to, as well?
No. The
On Wed, Apr 20, 2005 at 11:28:20AM -0400, C. Scott Ananian wrote:
Hi,
A merkle-tree (which I think you initially pointed me at) makes the hash
of the internal nodes be a hash of the chunk's hashes; ie not a straight
content hash. This is roughly what my current implementation does, but
I
On 4/20/05, Linus Torvalds [EMAIL PROTECTED] wrote:
It really _shouldn't_ be faster. It still does the compression, and throws
the end result away.
Am I misunderstanding or is the proglem that doing:
file with unknown status - compress - sha1 - compare with existing hash
is expensive?
What
On Wed, 20 Apr 2005, C. Scott Ananian wrote:
OK, sure. But how 'bout chunking trees? Are you grown happy with the new
trees-reference-other-trees paradigm, or is there a deep longing in your
heart for the simplicity of 'trees-reference-blobs-period'?
I'm pretty sure we do better
On Wed, 20 Apr 2005, Linus Torvalds wrote:
To actually go faster, it _should_ need this patch. Untested. See if it
works..
NO! Don't see if this works. For the sha1 file already exists file, it
forgot to return the SHA1 value in returnsha1, and would thus corrupt
the trees it wrote.
So
On Wednesday 20 April 2005 11:40, Linus Torvalds wrote:
On Wed, 20 Apr 2005, Chris Mason wrote:
Thanks for looking at this. Your new tree is faster, it gets the commit
100 patches time down from 1m5s to 50s.
It really _shouldn't_ be faster. It still does the compression, and throws
the
On Wed, 20 Apr 2005, Linus Torvalds wrote:
NO! Don't see if this works. For the sha1 file already exists file, it
forgot to return the SHA1 value in returnsha1, and would thus corrupt
the trees it wrote.
Proper version with fixes checked in. For me, it brings down the time to
write a
Linus Torvalds [EMAIL PROTECTED] writes:
Real merges have no patches taking place _anywhere_. And they take about
half a second. Doing an update of your tree should _literally_ boil down
to
#
# repo needs to point to the repo we update from
#
rsync -avz
On Wed, 20 Apr 2005, Chris Mason wrote:
At any rate, the time for a single write-tree is pretty consistent. Before
it
was around .5 seconds, and with this change it goes down to .128s.
Oh, wow.
I bet your SHA1 implementation is done with hand-optimized and scheduled
x86 MMX code or
Hi
I'm starting to write some docs...
Comments... even yep, looks OK, carry on :)
I plan on putting the 'git command' ones into the 'git help ...'
structure once Petr accepts it.
I guess the low level ones go into a README.reference until they
stabilise and become man pages...
In doing this I
On Wed, 20 Apr 2005, Zlatko Calusic wrote:
I see this -avz incantation mentioned everytime when rsync is
involved. But, is the -z part (compression) really necessary knowing
that we're dealing with an already compressed tree? Doesn't it put
additional strain on the rsync server without any
Hi Ray,
Give me a case where assuming it's a replace will do the wrong thing,
for C code, where it's a variable or function name.
How about two patches.
1. s/foo/bar/ throughout file because foo() has been decided upon
as the name of a new globally visible forthcoming function but
Petr Baudis graced us with:
Dear diary, on Tue, Apr 19, 2005 at 02:36:32PM CEST, I got a letter
where Klaus Robert Suetterlin [EMAIL PROTECTED] told me that...
1) There is no clear (e.g. by name) distinction between ``git as done
by Linus'', which is a kind of content addressable database
Ingo Molnar [EMAIL PROTECTED] writes:
TREE1=$(cat-file commit 2/dev/null $1 | head -4 | grep ^tree | cut -d' ' -f2)
--
And to make it easier on your eyes, you can always rewrite stuff like
that (mentioned everywhere
On Wed, 20 Apr 2005, David Greaves wrote:
In doing this I noticed a couple of points:
* update-cache won't accept ./file or fred/./file
The comment in update-cache.c reads:
/*
* We fundamentally don't like some paths: we don't want
* dot or dot-dot anywhere, and in fact, we don't even want
*
Hi Tom,
just as a datapoint, here is an experiment I carried out. I wanted to evaluate
how much overhead is incurred by using several levels of directories to
implement a discrimating index. I used the key format you specified:
SHA1,SIZE
As data, I used my /usr/src/linux which uses
C. Scott Ananian wrote:
On Wed, 20 Apr 2005, David Greaves wrote:
In doing this I noticed a couple of points:
* update-cache won't accept ./file or fred/./file
The comment in update-cache.c reads:
/*
* We fundamentally don't like some paths: we don't want
* dot or dot-dot anywhere, and in fact,
Here's a quick rev of the chunking code. This is compatible with
git-current, where the hashes are of the *uncompressed* file.
The 'chunk' file gets dropped in at the same SHA1 filename as the
'blob' file, as it represents identical contents. Martin won't like
this (because of how the hash is
On Wed, 20 Apr 2005 10:06:15 -0700 (PDT)
Linus Torvalds [EMAIL PROTECTED] wrote:
I bet your SHA1 implementation is done with hand-optimized and scheduled
x86 MMX code or something, while my poor G5 is probably using some slow
generic routine. As a result, it only improved by 33% for me since
On Tue, Apr 19, 2005 at 06:48:57PM -0400, C. Scott Ananian wrote:
On Tue, 19 Apr 2005, David Meybohm wrote:
But doesn't this require assuming the distribution of MD5 is uniform,
and don't the papers finding collisions in less show it's not? So, your
birthday-argument for calculating the
On Wed, 20 Apr 2005, Chris Mason wrote:
Well, the difference there should be pretty hard to see with any benchmark.
But I was being lazy...new patch attached. This one gets the same perf
numbers, if this is still wrong then I really need some more coffee.
I did my preferred version.
Dear diary, on Wed, Apr 20, 2005 at 12:08:24PM CEST, I got a letter
where Ingo Molnar [EMAIL PROTECTED] told me that...
* Petr Baudis [EMAIL PROTECTED] wrote:
just FYI, Olivier Andrieu was kind enough to port his monotone-viz
tool to git (http://oandrieu.nerim.net/monotone-viz/ - use the
Hello, Petr and everybody!
gittrack.sh allows abbreviated branch names, e.g. it's possible to run
git track lin when there is a branch called linus.
I believe it's a bug, not a feature. Please look at this line from
gittrack.sh:
grep -q $(echo -e ^$name\t | sed 's/\./\\./g') .git/remotes
The
Ingo Molnar [EMAIL PROTECTED] [Wed, 20 Apr 2005]:
* Petr Baudis [EMAIL PROTECTED] wrote:
Hi,
just FYI, Olivier Andrieu was kind enough to port his monotone-viz
tool to git (http://oandrieu.nerim.net/monotone-viz/ - use the one
from the monotone repository). The tool
Dear diary, on Wed, Apr 20, 2005 at 09:01:57AM CEST, I got a letter
where Ingo Molnar [EMAIL PROTECTED] told me that...
[...]
fatal: unable to execute 'gitmerge-file.sh'
fatal: merge program failed
Pure stupidity of mine, I forgot to add gitmerge-file.sh to the list of
scripts which get
On Wed, 20 Apr 2005, David Greaves wrote:
So maybe it's left as documented behaviour and higher level tools must
manage the data they feed to it...
That was the plan.
I agree that find . -type f | xargs update-cache --add -- in _theory_ is
a nice thing to do. But in practice, you want to
* Petr Baudis [EMAIL PROTECTED] wrote:
Dear diary, on Wed, Apr 20, 2005 at 09:01:57AM CEST, I got a letter
where Ingo Molnar [EMAIL PROTECTED] told me that...
[...]
fatal: unable to execute 'gitmerge-file.sh'
fatal: merge program failed
Pure stupidity of mine, I forgot to add
Hello,
so I've released git-pasky-0.6.2 (my SCMish layer on top of Linus
Torvalds' git tree history storage system), find it at the usual
http://pasky.or.cz/~pasky/dev/git/
git-pasky-0.6 has couple of big changes; mainly enhanced git diff,
git patch (to be renamed to cg mkpatch),
Dear diary, on Wed, Apr 20, 2005 at 10:56:33PM CEST, I got a letter
where Petr Baudis [EMAIL PROTECTED] told me that...
cg pull will now always only pull, never merge.
cg update will do pull + merge.
Note that what you will probably do _most_ by far is cg update.
You generally do cg pull
Dear diary, on Wed, Apr 20, 2005 at 10:32:35PM CEST, I got a letter
where Ingo Molnar [EMAIL PROTECTED] told me that...
* Petr Baudis [EMAIL PROTECTED] wrote:
yet another thing: what is the canonical 'pasky way' of simply nuking
the current files and checking out the latest tree
On Wed, Apr 20, 2005 at 10:56:33PM +0200, Petr Baudis wrote:
The short command version will change from 'git' to 'cg', which should
be shorter to type and free the 'git' command for possible eventual
entry gate for the git commands (so that they are more
namespace-friendly, and it might make
Hey,
The following is a copy of the terminal session in question:
[EMAIL PROTECTED]:~/repo/tmp.repo$ ls
[EMAIL PROTECTED]:~/repo/tmp.repo$ init-db
defaulting to local storage area
[EMAIL PROTECTED]:~/repo/tmp.repo$ ls -l .git
total 4
drwxr-xr-x 258 rhys rhys 4096 2005-04-20 20:52 objects
[EMAIL
Dear diary, on Wed, Apr 20, 2005 at 11:28:35PM CEST, I got a letter
where Rhys Hardwick [EMAIL PROTECTED] told me that...
Hey,
Hi,
[EMAIL PROTECTED]:~/repo/tmp.repo$ commit-tree
c80156fafbac377ab35beb076090c8320f874f91
Committing initial tree c80156fafbac377ab35beb076090c8320f874f91
Cheers for the help!
Rhys
On Wednesday 20 Apr 2005 22:35, Petr Baudis wrote:
Dear diary, on Wed, Apr 20, 2005 at 11:28:35PM CEST, I got a letter
where Rhys Hardwick [EMAIL PROTECTED] told me that...
Hey,
Hi,
[EMAIL PROTECTED]:~/repo/tmp.repo$ commit-tree
On Wed, 20 Apr 2005, Rhys Hardwick wrote:
[EMAIL PROTECTED]:~/repo/tmp.repo$ commit-tree
c80156fafbac377ab35beb076090c8320f874f91
Committing initial tree c80156fafbac377ab35beb076090c8320f874f91
At this point, the command seems to be just waiting.
That's _exactly_ what it's doing.
Dear diary, on Wed, Apr 20, 2005 at 11:19:19PM CEST, I got a letter
where Greg KH [EMAIL PROTECTED] told me that...
On Wed, Apr 20, 2005 at 10:56:33PM +0200, Petr Baudis wrote:
The short command version will change from 'git' to 'cg', which should
be shorter to type and free the 'git'
I keep thinking perversely that we need something as obtuse as possible
in the unix tradition, but easy to type... git requires that the fingers
move off the home row...
how about asdf or jkl? :)
cg is singularly uncomfortable to type. I think that's why it isn't
commonly used.
Greg KH
On Wed, 20 Apr 2005 23:51:18 +0200 Petr Baudis wrote:
| Dear diary, on Wed, Apr 20, 2005 at 11:19:19PM CEST, I got a letter
| where Greg KH [EMAIL PROTECTED] told me that...
| On Wed, Apr 20, 2005 at 10:56:33PM +0200, Petr Baudis wrote:
| The short command version will change from 'git' to
On 20 April 2005 17:51, Mike Taht wrote:
I keep thinking perversely that we need something as obtuse as possible
in the unix tradition, but easy to type... git requires that the fingers
move off the home row...
how about asdf or jkl? :)
cg is singularly uncomfortable to type. I think
On Wed, 20 Apr 2005, Petr Baudis wrote:
Grm. Cg is also name of some scary NVidia thing, and cog is GNOME
Configurator. CGT are Chimera Grid Tools, but I think we can clash
with those - at least *I* wouldn't mind. ;-)
I realize that there is probably a law that there has to be a space, but
Randy.Dunlap wrote:
On Wed, 20 Apr 2005 23:51:18 +0200 Petr Baudis wrote:
| Dear diary, on Wed, Apr 20, 2005 at 11:19:19PM CEST, I got a letter
| where Greg KH [EMAIL PROTECTED] told me that...
| On Wed, Apr 20, 2005 at 10:56:33PM +0200, Petr Baudis wrote:
| The short command version will
Linus Torvalds wrote:
On Wed, 20 Apr 2005, Rhys Hardwick wrote:
[EMAIL PROTECTED]:~/repo/tmp.repo$ commit-tree
c80156fafbac377ab35beb076090c8320f874f91
Committing initial tree c80156fafbac377ab35beb076090c8320f874f91
At this point, the command seems to be just waiting.
That's _exactly_ what
On Wed, 2005-04-20 at 07:59 -0700, Linus Torvalds wrote:
external-parent commit-hash external-parent-ID
comment for this parent
and the nice thing about that is that now that information allows you to
add external parents at any point.
Why do it like this? First
On Wed, 2005-04-20 at 19:15 +0200, [EMAIL PROTECTED] wrote:
...
As data, I used my /usr/src/linux which uses 301M and contains 20753 files and
1389 directories. To compute the key for a directory, I considered that its
contents were a mapping from names to keys.
I suppose if you used the blob
On Wed, 20 Apr 2005, Petr Baudis wrote:
I think one thing git's objects database is not very well suited for are
network transports. You want to have something smart doing the
transports, comparing trees so that it can do some delta compression;
that could probably reduce the amount of data needed
On Wed, 20 Apr 2005, C. Scott Ananian wrote:
I'm hoping my 'chunking' patches will fix this. This ought to reduce the
size of the object store by (in effect) doing delta compression; rsync
will then Do The Right Thing and only transfer the needed deltas.
Running some benchmarks right now
On Wed, 2005-04-20 at 19:15 +0200, [EMAIL PROTECTED] wrote:
...
As data, I used my /usr/src/linux which uses 301M and contains 20753 files and
1389 directories. To compute the key for a directory, I considered that its
contents were a mapping from names to keys.
I suppose if you used the blob
From: Linus Torvalds [EMAIL PROTECTED]
On Wed, 20 Apr 2005, Tom Lord wrote:
I think you have made a mistake by moving the sha1 checksum from the
zipped form to the inflated form. Here is why:
I'd have agreed with you (and I did, violently) if it wasn't for the
On Wed, 20 Apr 2005, Tom Lord wrote:
How many times per day do you invoke `write-tree' and why?
Every single commit does a write-tree, so when I merge with Andrew, it's
usually a series of 100-250 of them in a row.
(Actually, _usualyl_ it's smaller series, but it's the big series that can
On Thu, Apr 21, 2005 at 12:28:15AM +0200, Petr Baudis wrote:
Dear diary, on Thu, Apr 21, 2005 at 12:09:06AM CEST, I got a letter
where Linus Torvalds [EMAIL PROTECTED] told me that...
Yeah, yeah, it looks different from cvs update, but dammit, wouldn't it
be cool to just write cg-tabtab and
After getting the latest tarball, and make, make install:
[EMAIL PROTECTED] git-pasky-0.6.2]$ git pull pasky
MOTD: Welcome to Petr Baudis' rsync archive.
MOTD:
MOTD: If you are pulling my git branch, please do not repeat that
MOTD: every five minutes or so - new stuff is likely not going to
From: [EMAIL PROTECTED]
Thank you for your experiment. I'm not surprised by the
result but it is very nice to know that my expectations
are right.
I think that to a large extent you are seeing artifacts
of the questionable trade-offs that (reports tell me) the
ext* filesystems make.
Dear diary, on Thu, Apr 21, 2005 at 01:06:09AM CEST, I got a letter
where Steven Cole [EMAIL PROTECTED] told me that...
After getting the latest tarball, and make, make install:
Tree change:
55f9d5042603fff4ddfaf4e5f004d2995286d6d3:a46844fcb6afef1f7a2d93f391c82f08ea31
*100755-100755
Dear diary, on Wed, Apr 20, 2005 at 09:48:30PM CEST, I got a letter
where Pavel Roskin [EMAIL PROTECTED] told me that...
--- a/gittrack.sh
+++ b/gittrack.sh
@@ -35,7 +35,7 @@ die () {
mkdir -p .git/heads
if [ $name ]; then
- grep -q $(echo -e ^$name\t | sed 's/\./\\./g')
Dear diary, on Tue, Apr 19, 2005 at 09:04:16PM CEST, I got a letter
where David Greaves [EMAIL PROTECTED] told me that...
I don't love the 'require gitadd.pl' but it's a gradual start...
I hate it, for one. ;-)
Cogito.pm seems to be a good place for the library stuff.
Sounds sensible.
(I'll have to study/think about that for a while before a proper
reply. Tomorrow, probably.)
Thanks,
-t
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, 20 Apr 2005, Linus Torvalds wrote:
What's the disk usage results? I'm on ext3, for example, which means that
even small files invariably take up 4.125kB on disk (with the inode).
Even uncompressed, most source files tend to be small. Compressed, I'm
seeing the median blob size being ~1.6kB
Petr Baudis wrote:
Dear diary, on Wed, Apr 20, 2005 at 10:32:35PM CEST, I got a letter
where Ingo Molnar [EMAIL PROTECTED] told me that...
* Petr Baudis [EMAIL PROTECTED] wrote:
yet another thing: what is the canonical 'pasky way' of simply nuking
the current files and checking out the latest
Pasky,
what do you think about this change to git log?
It makes it a _lot_ easier to parse the result, as it indents all the
comments by two spaces, meaning that the header is clearly marked, and you
can then do various 'sed'/'grep' things with nice normal regular
expressions like '^parent'
Linus,
sorry for bringing up an issue that is already 8 hours old.
LT I don't think that's a good interface. It changes the sha1 passed into it:
LT that may actually be nice, since you may want to know what it changed to,
LT but I think you'd want to have that as an (optional) separate
LT
Updates diff-tree.c to use read_tree_with_tree_or_commit_sha1()
function. The command can take either tree or commit IDs with this patch.
Signed-off-by: Junio C Hamano [EMAIL PROTECTED]
---
diff-tree.c | 25 -
1 files changed, 4 insertions(+), 21 deletions(-)
Updates ls-tree.c to use read_tree_with_tree_or_commit_sha1()
function. The command can take either tree or commit IDs with
this patch.
Signed-off-by: Junio C Hamano [EMAIL PROTECTED]
---
ls-tree.c | 11 +--
1 files changed, 5 insertions(+), 6 deletions(-)
ls-tree.c:
On Wednesday 20 April 2005 05:15 pm, Steven Cole wrote:
On Wednesday 20 April 2005 05:12 pm, Petr Baudis wrote:
Dear diary, on Thu, Apr 21, 2005 at 01:06:09AM CEST, I got a letter
where Steven Cole [EMAIL PROTECTED] told me that...
After getting the latest tarball, and make, make install:
Updates read-tree to use read_tree_with_tree_or_commit_sha1()
function. The command can take either tree or commit IDs with
this patch.
The change involves a slight modification of how it recurses down
the tree. Earlier the caller only supplied SHA1 and the recurser
read the object using it,
JCH == Junio C Hamano [EMAIL PROTECTED] writes:
JCH Updates ls-tree.c to use read_tree_with_tree_or_commit_sha1()
JCH function. The command can take either tree or commit IDs with
JCH this patch.
Sorry, but the numbering is wrong this should have been [4/5]
not [3/4]. The contents should be
On Wed, 20 Apr 2005, Junio C Hamano wrote:
Sorry, but the numbering is wrong this should have been [4/5]
not [3/4]. The contents should be fine, though.
Applied and pushed out.
Btw, I edited your subject lines to make them be more specific
to one particular patch.
Linus
-
On Wed, 20 Apr 2005, Linus Torvalds wrote:
Pasky,
what do you think about this change to git log?
Here's a slightly updated version.
It's identical to the previous one, except that it also feeds the result
through | ${PAGER:-less} which makes it a lot more useful, in my
opinion.
If you
1 - 100 of 117 matches
Mail list logo
