On Sat, 23 Apr 2005, Petr Baudis wrote:
Just FYI, this is bug in core git's diff-cache;
Nice find.
Yes, I told you guys I hadn't tested it well ;)
diff-cache does the same diff trees in lockstep thing that diff-tree
does, but it's actually more complex, since the _tree_ part always needs
On Fri, 22 Apr 2005, Junio C Hamano wrote:
Almost, with a counter-example. Please try this yourself:
I agree that what git outputs is always based on the archive base. But
that's an independent issue from where is the working directory. That's
the issue of how do you want me to print out
On Thu, 21 Apr 2005, Chris Mason wrote:
There have been a few threads on making git more space efficient, and
eventually someone mentions tiny files and space fragmentation. Now that git
object names are decoupled from their compression, it's easier to consider a
a variety of
I just pushed out this very useful thing to checkout-cache, which is
best just described by its commit log:
Add the ability to prefix something to the pathname to checkout-cache.c
This basically makes it trivial to use checkout-cache as a export as
tree function. Just read the desired
This checkin goes along with the previous one, and makes it easier to use
all the normal git operations on temporary index files:
Add support for a GIT_INDEX_FILE environment variable.
We use that to specify alternative index files, which can be useful
if you want to (for example)
On Thu, 21 Apr 2005, Chris Mason wrote:
Shrug, we shouldn't need help from the kernel for something like this. git
as
a database hits worst case scenarios for almost every FS.
I really disagree.
We've got:
1) subdirectories with lots of files
2) wasted space for tiny files
3)
On Thu, 21 Apr 2005, Junio C Hamano wrote:
I am thinking about an alternative way of doing the above by
some modifications to the git core. I think the root of this
problem is that there is no equivalent to GIT_INDEX_FILE and
SHA1_FILE_DIRECTORY that tells the core git where the project
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
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 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, 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, 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 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
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
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
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.
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
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.
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
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, 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
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'
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
On Wed, 20 Apr 2005, Daniel Jacobowitz wrote:
My logic: it's a lot more intuitive to say cg-log | less to get
paginated output than it is to say cg-log | cat to get unpaginated
output.
I disagree.
There is _never_ any valid situation where you do cg-log with
unpaginated output to a tty.
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 that.
Note that git _does_ very efficiently (and I mean
On Tue, 19 Apr 2005, Petr Baudis wrote:
I'd actually prefer, if:
(i) checkout-cache simply wouldn't touch files whose stat matches with
what is in the cache; it updates the cache with the stat informations
of touched files
Run update-cache --refresh _before_ doing the checkout-cache,
On Tue, 19 Apr 2005, Linus Torvalds wrote:
The real expense right now of a merge is that we always forget all the
stat information when we do a merge (since it does a read-tree). I have a
cunning way to fix that, though, which is to make read-tree -m read in
the old index state like
On Tue, 19 Apr 2005, Chris Mason wrote:
Very true, you can't replace quilt with git without ruining both of them.
But
it would be nice to take a quilt tree and turn it into a git tree for merging
purposes, or to make use of whatever visualization tools might exist someday.
Fair
On Tue, 19 Apr 2005, Greg KH wrote:
Nice, it looks like the merge of this tree, and my usb tree worked just
fine.
Yup, it all seems to work out.
So, what does this now mean? Is your kernel.org git tree now going to
be the real kernel tree that you will be working off of now? Should
we
On Tue, 19 Apr 2005, Steven Cole wrote:
But perhaps a progress bar right about here might be
a good thing for the terminally impatient.
real3m54.909s
user0m14.835s
sys 0m10.587s
4 minutes might be long enough to cause some folks to lose hope.
Well, the real operations
On Tue, 19 Apr 2005, Chris Mason wrote:
5) right before exiting, write-tree updates the index if it made any changes.
This part won't work. It needs to do the proper locking, which means that
it needs to create index.lock _before_ it reads the index file, and
write everything to that one
On Tue, 19 Apr 2005, Junio C Hamano wrote:
Let's for a moment forget what git-pasky currently does, which
is not to touch .git/index until the user says Ok, let's
commit.
I think git-pasky is wrong.
It's true that we want to often (almost always) diff against the last
released thing,
On Tue, 19 Apr 2005, Linus Torvalds wrote:
That is indeed the whole point of the index file. In my world-view, the
index file does _everything_. It's the staging area (work file), it's
the merging area (merge directory) and it's the cache file (stat
cache).
I'll immediately write a tool
On Tue, 19 Apr 2005, Zach Welch wrote:
This patch applies on top of:
[PATCH 1/3] init-db.c: cleanup comments
init-db.c | 11 +++
1 files changed, 3 insertions(+), 8 deletions(-)
Signed-Off-By: Zach Welch [EMAIL PROTECTED]
Normalize init-db environment variable
On Tue, 19 Apr 2005, Zach Welch wrote:
I feel even more abashed for my earlier scripting faux pas. Would you
like me to resend them to you off-list?
No, I edited them and applied them (the first series, I'll have to think
about the second one).
It's only when there are tens of patches
On Mon, 18 Apr 2005, Russell King wrote:
Ok, I just tried pulling your tree into the tree you pulled from, and
got this:
No, that can't work. The pesky tools are helpful, but they really don't do
merges worth cr*p right now, excuse my french.
The _real_ way to pull is to do the (horribly
On Mon, 18 Apr 2005, Imre Simon wrote:
How will git handle a corrupted (git) file system?
For instance, what can be done if objects/xy/z{38} does not pass the
simple consistency test, i.e. if the file's sha1 hash is not xyz{38}?
This might be a serious problem because, in general, one
On Mon, 18 Apr 2005, Greg KH wrote:
On Sun, Apr 17, 2005 at 04:24:24PM -0700, Linus Torvalds wrote:
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
On Mon, 18 Apr 2005, Linus Torvalds wrote:
No, that can't work. The pesky tools are helpful [...]
I'm afraid that until Pasky's tools script this properly, [... ]
If Pesky wants to take the above script, test it, [...]
Ok, one out of three isn't too bad, is it? Pesky/Pasky, so close yet so
On Sun, 17 Apr 2005, Daniel Barkalow wrote:
This series introduces common parsers for objects, and ports the programs
that currently use revision.h to them.
1: the header files
2: the implementations
3: port rev-tree
4: port fsck-cache
5: port merge-base
Ok, having now looked at
On Mon, 18 Apr 2005, James Bottomley wrote:
I had a problem with the SCSI tree in that there's a file removal in one
branch. Your git-merge-one-file-script wouldn't have handled this
correctly: It seems to think that the file must be removed in both
branches, which is wrong.
Yes, I
On Mon, 18 Apr 2005, Russell King wrote:
Since this happened, I've been working out what state my tree is in,
and I restored it back to a state where I had one dangling commit head,
which was _my_ head.
For the future, if your tree gets messed up to the point where you say
screw it and
On Mon, 18 Apr 2005, Petr Baudis wrote:
So, I'm confused. Why did you introduce unpack-file instead of doing
just this?
It was code that I already had (ie the old code from merge-cache just
moved over), and thanks to that, I don't have to worry about broken
mktemp crap in user space...
On Mon, 18 Apr 2005, Greg KH wrote:
Hm, have you pushed all of the recent changes public?
Oops. Obviously not. Will fix.
Linus
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On Mon, 18 Apr 2005, Greg KH wrote:
Anyway, I try it this way and get:
You should update to the newest version anyway..
$ dotest ~/linux/patches/usb/usb-visor-tapwave_zodiac.patch
Applying USB: visor Tapwave Zodiac support patch
fatal: preparing to update file
On Tue, 19 Apr 2005, Petr Baudis wrote:
What is actually a little annoying is having to cd ,,merge and then
back, though. I don't know, but the current pull-merge script does not
bother with the temporary merge directory neither, even though Linus
wanted it. Linus, do you still do? ;-)
On Mon, 18 Apr 2005, James Bottomley wrote:
It looks like the merge tree has contamination from the scsi-misc-2.6
tree ... possibly because the hosting system got the merged objects when
I pushed.
Nope, the way I merge, if I get a few objects it shouldn't matter at all.
I'll just look at
On Mon, 18 Apr 2005, James Bottomley wrote:
Then the git-pull... script actually does the merge and the resulting
tree checks out against BK
So?
What do you intend to do with all the other stuff I've already put on top?
Yes, I can undo my tree, but my tree has had more stuff in it since I
On Mon, 18 Apr 2005, James Bottomley wrote:
Fair enough. If you pull from
rsync://www.parisc-linux.org/~jejb/scsi-misc-2.6.git
Thanks. Pulled and pushed out.
Doing this exposed two bugs in your merge script:
1) It doesn't like a completely new directory (the misc tree contains a
On Sun, 17 Apr 2005, Stefan-W. Hahn wrote:
after playing a while with git-pasky it is a crap to interpret the date of
commit logs. Though it was a good idea to put the date in a parseable format
(seconds since), but the format of the commit itself is not good parseable.
Actually, it is.
On Sun, 17 Apr 2005, David A. Wheeler wrote:
There's a minor reason to write out ALL the perm bit data, but
only care about a few bits coming back in: Some people use
SCM systems as a generalized backup system
Yes. I was actually thinking about having system config files in a git
On Sun, 17 Apr 2005, David Roundy wrote:
That's all right. Darcs would only access the cached data through a
git-caching layer, and we've already got an abstraction layer over the
pristine cache. As long as the git layer can quickly retrieve the contents
of a given file, we should be
On Sun, 17 Apr 2005, Russell King wrote:
On Sat, Apr 16, 2005 at 04:01:45PM -0700, Linus Torvalds wrote:
So I re-created the dang thing (hey, it takes just a few minutes), and
pushed it out, and there's now an archive on kernel.org in my public
personal directory called linux-2.6.git
On Sun, 17 Apr 2005, Russell King wrote:
BTW, there appears to be errors in the history committed thus far.
I'm not sure where this came from though. Some of them could be
UTF8 vs ASCII issues, but there's a number which seem to have extra
random crap in them (^M) and lots of blank
really is special: some people have
Torvalds, Linus
and maybe I should not just remove the commas, I should convert it to
always be Linus Torvalds. But your gecos entry is just _strange_. Why
the extra commas, I wonder?)
Linus
-
To unsubscribe from this list: send the line
On Sun, 17 Apr 2005, Daniel Barkalow wrote:
--- 45f926575d2c44072bfcf2317dbf3f0fbb513a4e/revision.h (mode:100644
sha1:28d0de3261a61f68e4e0948a25a416a515cd2e83)
+++ 37a0b01b85c2999243674d48bfc71cdba0e5518e/revision.h (mode:100644
sha1:523bde6e14e18bb0ecbded8f83ad4df93fc467ab)
@@ -24,6
On Sun, 17 Apr 2005, Russell King wrote:
This will (and does) do exactly what I want. I'll also read into the
above a request that you want it in forward date order. 8)
No, I actually don't _think_ I care. In many ways I'm more used to
reverse date order, because that's usually how you
$(cat .git/HEAD)
tree 7792a93eddb3f9b8e3115daab8adb3030f258ce6
parent 8173055926cdb8534fbaed517a792bd45aed8377
parent df4449813c900973841d0fa5a9e9bc7186956e1e
author Linus Torvalds [EMAIL PROTECTED] 111377 -0700
committer Linus Torvalds [EMAIL PROTECTED
On Sun, 17 Apr 2005, Russell King wrote:
I pulled it tonight into a pristine tree (which of course worked.)
Goodie.
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
On Sun, 17 Apr 2005, Brad Roberts wrote:
braddr:x:1000:1000:Brad Roberts,,,:/home/braddr:/bin/bash
All gecos entries on all my debian boxes are of the form:
fullname, office number, office extension, and home number
Ahh, ok.
I'll make the cleanup thing just remove strange characters
On Mon, 18 Apr 2005, Herbert Xu wrote:
I wasn't disputing that of course. However, the same effect can be
achieved in using a single hash with a bigger length, e.g., sha256
or sha512.
No it cannot.
If somebody actually literally totally breaks that hash, length won't
matter. There are
On Sat, 16 Apr 2005, Junio C Hamano wrote:
LT NOTE NOTE NOTE! I could make read-tree do some of these nontrivial
LT merges, but I ended up deciding that only the matches in all three
LT states thing collapses by default.
* Understood and agreed.
Having slept on it, I think I'll merge
On Sat, 16 Apr 2005, Linus Torvalds wrote:
Having slept on it, I think I'll merge all the trivial cases that don't
involve a file going away or being added. Ie if the file is in all three
trees, but it's the same in two of them, we know what to do.
Junio, I pushed this out, along
On Sat, 16 Apr 2005, Ingo Molnar 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.)
the history data starts at
On Sat, 16 Apr 2005, Thomas Gleixner wrote:
One remark on the tree blob storage format.
The binary storage of the sha1sum of the refered object is a PITA for
scripting.
Converting the ASCII - binary for the sha1sum comparision should not
take much longer than the binary - ASCII
On Sat, 16 Apr 2005, Thomas Gleixner wrote:
For the export stuff its terrible slow. :(
I don't really see your point.
If you already know what the tree is like you say, you don't care about
the tree object. And if you don't know what the tree is, what _are_ you
doing?
In other words, show
On Sat, 16 Apr 2005, Junio C Hamano wrote:
When update-cache --refresh replaces an existing cache entry
with a new one, it forgets to free the original.
I've seen this patch now three times, and it's been wrong every single
time. Maybe we should add a comment?
That active-cache entry you
On Sat, 16 Apr 2005, Paul Jackson wrote:
Daniel wrote:
I'm working off of Linus's tree when not working on scripts, and it
doesn't have that section at all.
Ah so - nevermind my README comments then.
Well, actually, I suspect that something like this should go to Pasky. I
really see my
On Sat, 16 Apr 2005, Paul Jackson wrote:
Morten wrote:
It makes some sense in principle, but without storing what they mean
(i.e., group==?) it certainly makes no sense.
There's no they there.
I think Martin's proposal, to which I agreed, was to store a _single_
bit. If any of the
On Sat, 16 Apr 2005, Junio C Hamano wrote:
I am wondering if you have a particular reason not to do the
same for the removing half.
No. Except for me being silly.
Please just make it so.
Also do you have any comments on this one from the same message?
* read-tree
- When merging
On Sat, 16 Apr 2005, Linus Torvalds wrote:
Anybody want to send a patch to do this?
Actually, I just did it. Seems to work for the only test-case I tried,
namely I just committed it, and checked that the permissions all ended up
being recorded as 0644 in the tree (if it has the -x bit set
On Fri, 15 Apr 2005, Daniel Barkalow wrote:
Is there some reason you don't commit before merging? All of the current
merge theory seems to want to merge two commits, using the information git
keeps about them.
Note that the 3-way merge would _only_ merge the committed state. The
thing is,
On Sat, 16 Apr 2005, Petr Baudis wrote:
I'm wondering, whether each tree should be fixed to a certain branch.
I'm wondering why you talk about branches at all.
No such thing should exist. There are no branches. There are just
repositories. You can track somebody elses repository, but you
On Fri, 15 Apr 2005, Junio C Hamano wrote:
I'd take the hint, but I would say the current Perl version
would be far more usable than the C version I would come up with
by the end of this weekend because:
Actually, it turns out that I have a cunning plan.
I'm full of cunning plans, in
On Thu, 14 Apr 2005, David Woodhouse wrote:
I've been looking at tracking file revisions. One proposed solution was
to have a separate revision history for individual files, with a new
kind of 'filecommit' object which parallels the existing 'commit',
referencing a blob instead of a tree.
501 - 577 of 577 matches
Mail list logo
