* git-local-pull
From: David S. Miller @ 2005-06-27 3:05 UTC (permalink / raw)
To: git
I tried to start using git-clone-script to clone repositories
locally. It crunches on the disk for a couple of seconds,
that's fine, but then I notice the disk activity stop and
git-local-pull becomes cpu bound and grows to 80MB in size
over the course of 5 minutes.
Is this a side effect of the new pack/unpack stuff?
Compared to what this thing is doing, manually symlinking
the object database, copying over the HEAD, and building
the index file is significantly faster.
Actually, git-clone-script didn't build an index file.
So the compute time definitely came from something else
entirely.
^ permalink raw reply
* Re: git-local-pull
From: Linus Torvalds @ 2005-06-27 5:20 UTC (permalink / raw)
To: David S. Miller; +Cc: git
In-Reply-To: <20050626.200555.39157645.davem@davemloft.net>
On Sun, 26 Jun 2005, David S. Miller wrote:
>
> I tried to start using git-clone-script to clone repositories
> locally. It crunches on the disk for a couple of seconds,
> that's fine, but then I notice the disk activity stop and
> git-local-pull becomes cpu bound and grows to 80MB in size
> over the course of 5 minutes.
Try adding "-l" to the git-local-pull command line, to make it do
hardlinks by default (and fall back to a copy if that fails).
> Is this a side effect of the new pack/unpack stuff?
Nope, nothing uses that yet.
I think the 80MB is just because it built up the object relationship for
the whole kernel db there. I don't know what the 5 minutes of CPU are,
though, it should just be copying stuff (and at 250MB in and 250MB out,
that's a lot of stuff to copy, but it shouldn't be five minutes worth,
especially if it's all cached and you see a pegged CPU).
That copy is stupid, btw. Doing a "mmap + write" is a lot slower than
doing a "while (data) { read(8kB) + write(8kB) }" loop. The read() will
generally do better read-ahead and the small read/write will be better for
the caches. But that still doesn't explain 5 minutes worth.
> Compared to what this thing is doing, manually symlinking
> the object database, copying over the HEAD, and building
> the index file is significantly faster.
Well, with "-l" that is what git-local-pull will do too. And if you want
symlinks, use "-s". Or use both, in which case it will try a hardlink
first, and then a symlink if it gets an EXDEV.
Linus
^ permalink raw reply
* Re: git-local-pull
From: Jeff Garzik @ 2005-06-27 5:31 UTC (permalink / raw)
To: Linus Torvalds; +Cc: David S. Miller, git
In-Reply-To: <Pine.LNX.4.58.0506262213220.19755@ppc970.osdl.org>
Linus Torvalds wrote:
>
> On Sun, 26 Jun 2005, David S. Miller wrote:
>
>>I tried to start using git-clone-script to clone repositories
>>locally. It crunches on the disk for a couple of seconds,
>>that's fine, but then I notice the disk activity stop and
>>git-local-pull becomes cpu bound and grows to 80MB in size
>>over the course of 5 minutes.
>
>
> Try adding "-l" to the git-local-pull command line, to make it do
> hardlinks by default (and fall back to a copy if that fails).
>
>
>>Is this a side effect of the new pack/unpack stuff?
>
>
> Nope, nothing uses that yet.
>
> I think the 80MB is just because it built up the object relationship for
> the whole kernel db there. I don't know what the 5 minutes of CPU are,
> though, it should just be copying stuff (and at 250MB in and 250MB out,
> that's a lot of stuff to copy, but it shouldn't be five minutes worth,
> especially if it's all cached and you see a pegged CPU).
FWIW, I notice that git-diff-tree uses >100MB of RAM, on a large
git-pull-script run. It's generating the diffstat output, AFAICS.
Jeff
^ permalink raw reply
* git-pull-branch script
From: Jeff Garzik @ 2005-06-27 12:27 UTC (permalink / raw)
To: Git Mailing List
[-- Attachment #1: Type: text/plain, Size: 405 bytes --]
I've attached the 1-line git-pull-branch script that I just whipped
together, in case anybody finds it useful.
On occasion, I need to pull one branch into another branch, inside the
same repo. For this case, the objects are already present, so we can
skip the git-fetch-script step of git-pull-script completely. I also
modify the commit message so that we log the fact that we pulled a branch.
[-- Attachment #2: git-pull-branch --]
[-- Type: text/plain, Size: 59 bytes --]
#!/bin/sh
git-resolve-script HEAD $1 "`pwd` branch '$1'"
^ permalink raw reply
* Re: Mercurial vs Updated git HOWTO for kernel hackers
From: Pavel Machek @ 2005-06-27 18:31 UTC (permalink / raw)
To: Matt Mackall; +Cc: Jeff Garzik, Linux Kernel, Git Mailing List, mercurial
In-Reply-To: <20050623235634.GC14426@waste.org>
Hi!
> > Things in git-land are moving at lightning speed, and usability has
> > improved a lot since my post a month ago: http://lkml.org/lkml/2005/5/26/11
>
> And here's a quick comparison with the current state of Mercurial..
>
> > 1) installing git
> >
> > git requires bootstrapping, since you must have git installed in order
> > to check out git.git (git repo), and linux-2.6.git (kernel repo). I
> > have put together a bootstrap tarball of today's git repository.
> >
> > Download tarball from:
> > http://www.kernel.org/pub/linux/kernel/people/jgarzik/git-20050622.tar.bz2
> >
> > tarball build-deps: zlib, libcurl, libcrypto (openssl)
> >
> > install tarball: unpack && make && sudo make prefix=/usr/local install
> >
> > jgarzik helper scripts, not in official git distribution:
> > http://www.kernel.org/pub/linux/kernel/people/jgarzik/git-new-branch
> > http://www.kernel.org/pub/linux/kernel/people/jgarzik/git-changes-script
> >
> > After reading the rest of this document, come back and update your copy
> > of git to the latest:
> > rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/git.git
>
> Download from: http://selenic.com/mercurial/mercurial-snapshot.tar.gz
> Build-deps: Python 2.3
> Install: unpack && python setup.py install [--home=/usr/local]
Did that... (had to install python2.3-dev, first), but got...
> $ mkdir linux-2.6
> $ cd linux-2.6
> $ hg init http://www.kernel.org/hg/ # obviously you can also browse this
>
> This downloads about 125M of data, which include the whole kernel history
> back to 2.4.0 and everything in Linus' git repo as well.
byte-compiling /usr/local/lib/python/mercurial/fancyopts.py to
fancyopts.pyc
byte-compiling /usr/local/lib/python/mercurial/hg.py to hg.pyc
byte-compiling /usr/local/lib/python/mercurial/hgweb.py to hgweb.pyc
byte-compiling /usr/local/lib/python/mercurial/httprangereader.py to
httprangereader.pyc
byte-compiling /usr/local/lib/python/mercurial/lock.py to lock.pyc
byte-compiling /usr/local/lib/python/mercurial/mdiff.py to mdiff.pyc
byte-compiling /usr/local/lib/python/mercurial/revlog.py to revlog.pyc
byte-compiling /usr/local/lib/python/mercurial/transaction.py to
transaction.pyc
byte-compiling /usr/local/lib/python/mercurial/ui.py to ui.pyc
byte-compiling /usr/local/lib/python/mercurial/util.py to util.pyc
byte-compiling /usr/local/lib/python/mercurial/version.py to
version.pyc
running install_scripts
copying build/scripts-2.3/hg -> /usr/local/bin
copying build/scripts-2.3/hgmerge -> /usr/local/bin
changing mode of /usr/local/bin/hg to 755
changing mode of /usr/local/bin/hgmerge to 755
running install_data
creating /usr/local/lib/python/mercurial/templates
copying templates/map -> /usr/local/lib/python/mercurial/templates
copying templates/map-raw -> /usr/local/lib/python/mercurial/templates
copying templates/changelog.tmpl ->
/usr/local/lib/python/mercurial/templates
copying templates/changelogentry.tmpl ->
/usr/local/lib/python/mercurial/templates
copying templates/changeset-raw.tmpl ->
/usr/local/lib/python/mercurial/templates
copying templates/changeset.tmpl ->
/usr/local/lib/python/mercurial/templates
copying templates/fileannotate.tmpl ->
/usr/local/lib/python/mercurial/templates
copying templates/filediff-raw.tmpl ->
/usr/local/lib/python/mercurial/templates
copying templates/filediff.tmpl ->
/usr/local/lib/python/mercurial/templates
copying templates/filelog.tmpl ->
/usr/local/lib/python/mercurial/templates
copying templates/filelogentry.tmpl ->
/usr/local/lib/python/mercurial/templates
copying templates/filerevision-raw.tmpl ->
/usr/local/lib/python/mercurial/templates
copying templates/filerevision.tmpl ->
/usr/local/lib/python/mercurial/templates
copying templates/footer.tmpl ->
/usr/local/lib/python/mercurial/templates
copying templates/header-raw.tmpl ->
/usr/local/lib/python/mercurial/templates
copying templates/header.tmpl ->
/usr/local/lib/python/mercurial/templates
copying templates/manifest.tmpl ->
/usr/local/lib/python/mercurial/templates
copying templates/tags.tmpl ->
/usr/local/lib/python/mercurial/templates
root@Elf:/data/tmp/hg/mercurial-snapshot# Use "exit" to leave the
shell.
root@Elf:/data/tmp/hg/mercurial-snapshot# exit
pavel@Elf:/data/tmp/hg/mercurial-snapshot$ cd ../..
pavel@Elf:/data/tmp$ mkdir linux-hg
pavel@Elf:/data/tmp$ cd linux-hg/
pavel@Elf:/data/tmp/linux-hg$ hg init http://www.kernel.org/hg/
Traceback (most recent call last):
File "/usr/local/bin/hg", line 11, in ?
from mercurial import commands
ImportError: No module named mercurial
pavel@Elf:/data/tmp/linux-hg$
Pavel
--
teflon -- maybe it is a trademark, but it should not be.
^ permalink raw reply
* Re: git-local-pull
From: Linus Torvalds @ 2005-06-27 18:46 UTC (permalink / raw)
To: Jeff Garzik; +Cc: David S. Miller, git
In-Reply-To: <42BF8F2D.1070808@pobox.com>
On Mon, 27 Jun 2005, Jeff Garzik wrote:
>
> FWIW, I notice that git-diff-tree uses >100MB of RAM, on a large
> git-pull-script run. It's generating the diffstat output, AFAICS.
Ahh, yes, I should make the diffstat be conditional, not everybody wants
it, and it's often the most expensive part of the pull..
Linus
^ permalink raw reply
* [PATCH] git-ssh-pull: commit-id consistency
From: Sven Verdoolaege @ 2005-06-27 19:03 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Daniel Barkalow, git
In-Reply-To: <20050626214547.A29432@tin.liacs.nl>
As requested by Daniel, this new version leaves *-pull alone
and only changes the behaviour of git-ssh-push.
skimo
--
In contrast to other plumbing tools, git-ssh-push only
allow a very restrictive form of commit-id filenames.
This patch removes this restriction.
Acked-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Sven Verdoolaege <skimo@kotnet.org>
---
commit 28ec093e92206cd907249e741ca1d19f14da4cf3
tree 5ad7b33ec80c2c04272cb0abd4531e1d9abfbbe1
parent e18088451d92fbf83bfb57fd48201eda117f8103
author Sven Verdoolaege <skimo@kotnet.org> Mon, 27 Jun 2005 20:12:40 +0200
committer Sven Verdoolaege <skimo@kotnet.org> Mon, 27 Jun 2005 20:12:40 +0200
Documentation/git-ssh-push.txt | 2 +-
ssh-push.c | 18 ++++++++++++++----
2 files changed, 15 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-ssh-push.txt b/Documentation/git-ssh-push.txt
--- a/Documentation/git-ssh-push.txt
+++ b/Documentation/git-ssh-push.txt
@@ -20,7 +20,7 @@ git-ssh-pull, aside from which end you r
OPTIONS
-------
commit-id::
- Either the hash or the filename under $GIT_DIR/refs/ to push.
+ Id of commit to push.
-c::
Get the commit objects.
diff --git a/ssh-push.c b/ssh-push.c
--- a/ssh-push.c
+++ b/ssh-push.c
@@ -2,6 +2,8 @@
#include "rsh.h"
#include "refs.h"
+#include <string.h>
+
unsigned char local_version = 1;
unsigned char remote_version = 0;
@@ -103,6 +105,9 @@ void service(int fd_in, int fd_out) {
} while (1);
}
+static const char *ssh_push_usage =
+ "git-ssh-push [-c] [-t] [-a] [-w ref] commit-id url";
+
int main(int argc, char **argv)
{
int arg = 1;
@@ -110,18 +115,23 @@ int main(int argc, char **argv)
char *url;
int fd_in, fd_out;
const char *prog = getenv("GIT_SSH_PULL") ? : "git-ssh-pull";
+ unsigned char sha1[20];
+ char hex[41];
while (arg < argc && argv[arg][0] == '-') {
if (argv[arg][1] == 'w')
arg++;
arg++;
}
- if (argc < arg + 2) {
- usage("git-ssh-push [-c] [-t] [-a] [-w ref] commit-id url");
- return 1;
- }
+ if (argc < arg + 2)
+ usage(ssh_push_usage);
commit_id = argv[arg];
url = argv[arg + 1];
+ if (get_sha1(commit_id, sha1))
+ usage(ssh_push_usage);
+ memcpy(hex, sha1_to_hex(sha1), sizeof(hex));
+ argv[arg] = hex;
+
if (setup_connection(&fd_in, &fd_out, prog, url, arg, argv + 1))
return 1;
^ permalink raw reply
* Re: Mercurial vs Updated git HOWTO for kernel hackers
From: Kyle Moffett @ 2005-06-27 19:05 UTC (permalink / raw)
To: Pavel Machek
Cc: Matt Mackall, Jeff Garzik, Linux Kernel, Git Mailing List,
mercurial
In-Reply-To: <20050627183118.GB1415@elf.ucw.cz>
On Jun 27, 2005, at 14:31:18, Pavel Machek wrote:
> pavel@Elf:/data/tmp/linux-hg$ hg init http://www.kernel.org/hg/
> Traceback (most recent call last):
> File "/usr/local/bin/hg", line 11, in ?
> from mercurial import commands
> ImportError: No module named mercurial
Apparently your Python does not automatically look in /usr/local/lib/
python
and you don't have PYTHONPATH=/usr/local/lib/python. Try adding the
following
to your .bash_profile, then logging out and back in again:
if [ -z "$PYTHONPATH" ]; then
PYTHONPATH=/usr/local/lib/python
else
PYTHONPATH="$PYTHONPATH:/usr/local/lib/python"
fi
export PYTHONPATH
Cheers,
Kyle Moffett
--
Somone asked me why I work on this free (http://www.fsf.org/philosophy/)
software stuff and not get a real job. Charles Shultz had the best
answer:
"Why do musicians compose symphonies and poets write poems? They do it
because life wouldn't have any meaning for them if they didn't.
That's why
I draw cartoons. It's my life."
-- Charles Shultz
^ permalink raw reply
* Re: Mercurial vs Updated git HOWTO for kernel hackers
From: Matt Mackall @ 2005-06-27 19:40 UTC (permalink / raw)
To: Pavel Machek; +Cc: Jeff Garzik, Linux Kernel, Git Mailing List, mercurial
In-Reply-To: <20050627183118.GB1415@elf.ucw.cz>
On Mon, Jun 27, 2005 at 08:31:18PM +0200, Pavel Machek wrote:
> Hi!
>
> > > Things in git-land are moving at lightning speed, and usability has
> > > improved a lot since my post a month ago: http://lkml.org/lkml/2005/5/26/11
> >
> > And here's a quick comparison with the current state of Mercurial..
> >
> > > 1) installing git
> > >
> > > git requires bootstrapping, since you must have git installed in order
> > > to check out git.git (git repo), and linux-2.6.git (kernel repo). I
> > > have put together a bootstrap tarball of today's git repository.
> > >
> > > Download tarball from:
> > > http://www.kernel.org/pub/linux/kernel/people/jgarzik/git-20050622.tar.bz2
> > >
> > > tarball build-deps: zlib, libcurl, libcrypto (openssl)
> > >
> > > install tarball: unpack && make && sudo make prefix=/usr/local install
> > >
> > > jgarzik helper scripts, not in official git distribution:
> > > http://www.kernel.org/pub/linux/kernel/people/jgarzik/git-new-branch
> > > http://www.kernel.org/pub/linux/kernel/people/jgarzik/git-changes-script
> > >
> > > After reading the rest of this document, come back and update your copy
> > > of git to the latest:
> > > rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/git.git
> >
> > Download from: http://selenic.com/mercurial/mercurial-snapshot.tar.gz
> > Build-deps: Python 2.3
> > Install: unpack && python setup.py install [--home=/usr/local]
>
> Did that... (had to install python2.3-dev, first), but got...
> Traceback (most recent call last):
> File "/usr/local/bin/hg", line 11, in ?
> from mercurial import commands
> ImportError: No module named mercurial
>From the README:
To install system-wide:
$ python setup.py install # change python to python2.3 if 2.2 is default
To install in your home directory (~/bin and ~/lib, actually), run:
$ python2.3 setup.py install --home=~
$ export PYTHONPATH=${HOME}/lib/python # add this to your .bashrc
$ export PATH=${HOME}/bin:$PATH #
And finally:
$ hg # test installation, show help
If you get complaints about missing modules, you probably haven't set
PYTHONPATH correctly.
--
Mathematics is the supreme nostalgia of our time.
^ permalink raw reply
* Re: Mercurial vs Updated git HOWTO for kernel hackers
From: Benjamin LaHaise @ 2005-06-27 19:51 UTC (permalink / raw)
To: Matt Mackall
Cc: Git Mailing List, Jeff Garzik, Linux Kernel, Pavel Machek,
mercurial
In-Reply-To: <20050627194031.GK12006@waste.org>
On Mon, Jun 27, 2005 at 12:40:31PM -0700, Matt Mackall wrote:
> $ export PYTHONPATH=${HOME}/lib/python # add this to your .bashrc
This needs to be ${HOME}/lib64/python on x86-64.
-ben
^ permalink raw reply
* Re: Mercurial vs Updated git HOWTO for kernel hackers
From: Matt Mackall @ 2005-06-27 20:51 UTC (permalink / raw)
To: Benjamin LaHaise
Cc: Git Mailing List, Jeff Garzik, Linux Kernel, Pavel Machek,
mercurial
In-Reply-To: <20050627195134.GA17107@kvack.org>
On Mon, Jun 27, 2005 at 03:51:34PM -0400, Benjamin LaHaise wrote:
> On Mon, Jun 27, 2005 at 12:40:31PM -0700, Matt Mackall wrote:
> > $ export PYTHONPATH=${HOME}/lib/python # add this to your .bashrc
>
> This needs to be ${HOME}/lib64/python on x86-64.
Thanks, I'll add this to the README.
--
Mathematics is the supreme nostalgia of our time.
^ permalink raw reply
* Re: Mercurial vs Updated git HOWTO for kernel hackers
From: Ed Tomlinson @ 2005-06-27 21:53 UTC (permalink / raw)
To: Benjamin LaHaise
Cc: Matt Mackall, Pavel Machek, Jeff Garzik, Linux Kernel,
Git Mailing List, mercurial
In-Reply-To: <20050627195134.GA17107@kvack.org>
On Monday 27 June 2005 15:51, Benjamin LaHaise wrote:
> On Mon, Jun 27, 2005 at 12:40:31PM -0700, Matt Mackall wrote:
> > $ export PYTHONPATH=${HOME}/lib/python # add this to your .bashrc
>
> This needs to be ${HOME}/lib64/python on x86-64.
Be careful. This is not true on debian.
Ed Tomlinson
^ permalink raw reply
* new features in gitk
From: Paul Mackerras @ 2005-06-27 22:22 UTC (permalink / raw)
To: git
New features that I have added recently to the gitk repository at
rsync://rsync.kernel.org/pub/scm/gitk/gitk.git
include:
* Added a right-click context menu on the headlines displayed in the
top-left pane with the following entries:
- Display diff between two commits
- Generate a patch file containing the diff between two commits
- Create a local direct tag for a commit
* Left-click on a graph line now displays the parent and the children
connected by that line in the bottom-left pane, with buttons
allowing you to jump to the parent or a child.
* Pasting into the SHA1 ID field clears it first if it already
contains a SHA1 ID.
* Checks for a .git (or $GIT_DIR) directory at startup.
I'm interested to know if people find the diff/patch generation
options useful.
Paul.
^ permalink raw reply
* Re: new features in gitk
From: Luc Van Oostenryck @ 2005-06-27 22:49 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
In-Reply-To: <17088.31798.17291.605567@cargo.ozlabs.ibm.com>
Paul Mackerras wrote:
>
> I'm interested to know if people find the diff/patch generation
> options useful.
>
> Paul.
I find the patch generation very usefull (when I've seen the tool a few days ago, I've said to myself:
"what a wonderfull tool, if only I could create a patch from this")
but it doesn't work for me (the first three entries stay always in grey, only the last one "Create tag" is in black).
I'm missing something ?
Luc
^ permalink raw reply
* Re: new features in gitk
From: Paul Mackerras @ 2005-06-27 23:36 UTC (permalink / raw)
To: Luc Van Oostenryck; +Cc: git
In-Reply-To: <42C08265.2050209@looxix.net>
Luc Van Oostenryck writes:
> I find the patch generation very usefull (when I've seen the tool a few days ago, I've said to myself:
> "what a wonderfull tool, if only I could create a patch from this")
> but it doesn't work for me (the first three entries stay always in grey, only the last one "Create tag" is in black).
> I'm missing something ?
The diffs and patches are between the selected commit (one that you
clicked on with the left button and which is shown with a grey
background) and the commit where you click the right button. That was
the best way I could think of to indicate which were the two commits
to diff. If you (or anyone) has a better suggestion, let me know.
Paul.
^ permalink raw reply
* CAREFUL! No more delta object support!
From: Linus Torvalds @ 2005-06-28 1:14 UTC (permalink / raw)
To: Git Mailing List
Some people may have noticed already (hopefully not the hard way) that the
current git code doesn't support delta objects lying around in the object
directory any more.
In other words, if you have delta objects, you need to un-deltify your
repository _before_ you upgrade your git binaries, or they won't be able
to read your objects any more.
The reason? The new git understands packed files natively, which ends up
being a much bigger win in many many ways.
You should be very careful about using packed files (since they are a very
recent addition), but what you can do to try them out is to do so in a
separate repository.
Starting to use a packed repository is very simple indeed, and here's what
you need to do for git, for example:
In your regular "git" directory (once you have ypdated your git to a
recent version, in particular you need to have the "csum-file: fix missing
buf pointer update" commit), do:
git-rev-list --objects HEAD | git-pack-objects --window=50 --depth=50 out
which will say something like "Packing 3741 objects" and result in two new
files a few seconds later:
torvalds@ppc970:~/git> ls -lh out*
-rw-r--r-- 1 torvalds torvalds 89K Jun 27 17:59 out.idx
-rw-r--r-- 1 torvalds torvalds 1.3M Jun 27 17:59 out.pack
now, don't do anythign with those files, but instead go and create a
directory somewhere else:
cd ~
mkdir packed-git-trial
cd packed-git-trial
git-init-db
you have now obviously created a totally empty repository. Now, let's
populate that empty repository with _just_ the pack files:
mkdir .git/objects/pack
mv ~/git/out.* .git/objects/pack
and then, move over your tags, in particularly the HEAD pointer, with
something like
cat ~/git/.git/HEAD > .git/HEAD
and voila, you're done. Try "gitk", for example. Or "git log".
Now, what's even cooler is how you can just start using this packed tree:
feel free to do a test-commit or something, and notice how git starts
populating the empty .git/objects/xx/ subdirectories with new objects. But
it still relies on the pack-file for the old history.
Now, there's still a misfeature there, which is that when you create a new
object, it doesn't check whether that object already exists in the
pack-file, so you'll end up with a few recent objects that you really
don't need (notably tree objects), and we'll fix that eventually. But
notice how you started with a 17MB .git/objects/ directory in your
original tree, and you now have just a 1.3MB pack-file and a 90kB index
file that replaces all that?
There are some other issues too, like the fact that "git-fsck-cache"
doesn't know about the pack-files yet, so it will complain about missing
objects etc. Also, please note that the pack-file _only_ packs the commits
and the things reachable from them: things like tags (and your references
in your .git/refs directory) need to be copied over separately.
So this is all very rough, still, but the basics do actually seem to work
(ie anything that doesn't look directly at the object files - which is
pretty much all of it except for fsck and the direct-filesystem-access
things like "rsync" and "git-local-pull").
Maybe you might not want to switch over yet, and as mentioned, rsync then
ends up not being a good way to sync (nor git-local-pull), but the
"git-http/ssh-pull" family should hopefully just work.
I've used a packed kernel tree too, so this has gotten _some_ testing even
on really quite big git trees.
Linus
^ permalink raw reply
* Re: new features in gitk
From: Linus Torvalds @ 2005-06-28 1:21 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
In-Reply-To: <17088.31798.17291.605567@cargo.ozlabs.ibm.com>
On Tue, 28 Jun 2005, Paul Mackerras wrote:
>
> New features that I have added recently to the gitk repository at
Hey, cool, the automatic merge actually worked.
I knew it would, of course, but still.. It's nice when theory and practice
end up matching.
Linus
^ permalink raw reply
* [PATCH] replace sha1sum with sum in t/t1002
From: Mark Allen @ 2005-06-28 1:40 UTC (permalink / raw)
To: git, torvalds
[-- Attachment #1: Type: text/plain, Size: 421 bytes --]
Linus,
This patch replaces sha1sum(1) with sum(1) in t/t1002. GNU sum(1) runs in "BSD
compatibility" mode by default, and not all systems have GNU coreutils. On any system
without GNU coreutils (or sha1sum) t1002 will fail. This patch should make t1002 complete
successfully everywhere that sum(1) runs.
I've tested this on Darwin and Linux; it works on both platforms.
Signed-off-by: Mark Allen <mrallen1@yahoo.com>
[-- Attachment #2: 2003972814-test-portability.patch.txt --]
[-- Type: text/plain, Size: 5108 bytes --]
diff --git a/t/t1002-read-tree-m-u-2way.sh b/t/t1002-read-tree-m-u-2way.sh
--- a/t/t1002-read-tree-m-u-2way.sh
+++ b/t/t1002-read-tree-m-u-2way.sh
@@ -51,7 +51,7 @@ test_expect_success \
treeM=`git-write-tree` &&
echo treeM $treeM &&
git-ls-tree $treeM &&
- sha1sum bozbar frotz nitfol >M.sha1 &&
+ sum bozbar frotz nitfol >M.sum &&
git-diff-tree $treeH $treeM'
test_expect_success \
@@ -60,7 +60,8 @@ test_expect_success \
git-read-tree -m -u $treeH $treeM &&
git-ls-files --stage >1-3.out &&
cmp M.out 1-3.out &&
- sha1sum -c M.sha1 &&
+ sum bozbar frotz nitfol >actual3.sum &&
+ cmp M.sum actual3.sum &&
check_cache_at bozbar clean &&
check_cache_at frotz clean &&
check_cache_at nitfol clean'
@@ -76,7 +77,8 @@ test_expect_success \
diff --unified=0 M.out 4.out >4diff.out
compare_change 4diff.out expected &&
check_cache_at yomin clean &&
- sha1sum -c M.sha1 &&
+ sum bozbar frotz nitfol >actual4.sum &&
+ cmp M.sum actual4.sum &&
echo yomin >yomin1 &&
diff yomin yomin1 &&
rm -f yomin1'
@@ -92,7 +94,8 @@ test_expect_success \
diff --unified=0 M.out 5.out >5diff.out
compare_change 5diff.out expected &&
check_cache_at yomin dirty &&
- sha1sum -c M.sha1 &&
+ sum bozbar frotz nitfol >actual5.sum &&
+ cmp M.sum actual5.sum &&
: dirty index should have prevented -u from checking it out. &&
echo yomin yomin >yomin1 &&
diff yomin yomin1 &&
@@ -106,7 +109,8 @@ test_expect_success \
git-ls-files --stage >6.out &&
diff --unified=0 M.out 6.out &&
check_cache_at frotz clean &&
- sha1sum -c M.sha1 &&
+ sum bozbar frotz nitfol >actual3.sum &&
+ cmp M.sum actual3.sum &&
echo frotz >frotz1 &&
diff frotz frotz1 &&
rm -f frotz1'
@@ -121,7 +125,8 @@ test_expect_success \
git-ls-files --stage >7.out &&
diff --unified=0 M.out 7.out &&
check_cache_at frotz dirty &&
- if sha1sum -c M.sha1; then false; else :; fi &&
+ sum bozbar frotz nitfol >actual7.sum &&
+ if cmp M.sum actual7.sum; then false; else :; fi &&
: dirty index should have prevented -u from checking it out. &&
echo frotz frotz >frotz1 &&
diff frotz frotz1 &&
@@ -150,7 +155,8 @@ test_expect_success \
git-read-tree -m -u $treeH $treeM &&
git-ls-files --stage >10.out &&
cmp M.out 10.out &&
- sha1sum -c M.sha1'
+ sum bozbar frotz nitfol >actual10.sum &&
+ cmp M.sum actual10.sum'
test_expect_success \
'11 - dirty path removed.' \
@@ -189,9 +195,12 @@ test_expect_success \
git-ls-files --stage >14.out || exit
diff --unified=0 M.out 14.out >14diff.out
compare_change 14diff.out expected &&
+ sum bozbar frotz >actual14.sum &&
+ grep -v nitfol M.sum > expected14.sum &&
+ cmp expected14.sum actual14.sum &&
+ sum bozbar frotz nitfol >actual14a.sum &&
+ if cmp M.sum actual14a.sum; then false; else :; fi &&
check_cache_at nitfol clean &&
- grep -v nitfol M.sha1 | sha1sum -c &&
- if sha1sum -c M.sha1; then false; else :; fi &&
echo nitfol nitfol >nitfol1 &&
diff nitfol nitfol1 &&
rm -f nitfol1'
@@ -207,8 +216,11 @@ test_expect_success \
diff --unified=0 M.out 15.out >15diff.out
compare_change 15diff.out expected &&
check_cache_at nitfol dirty &&
- grep -v nitfol M.sha1 | sha1sum -c &&
- if sha1sum -c M.sha1; then false; else :; fi &&
+ sum bozbar frotz >actual15.sum &&
+ grep -v nitfol M.sum > expected15.sum &&
+ cmp expected15.sum actual15.sum &&
+ sum bozbar frotz nitfol >actual15a.sum &&
+ if cmp M.sum actual15a.sum; then false; else :; fi &&
echo nitfol nitfol nitfol >nitfol1 &&
diff nitfol nitfol1 &&
rm -f nitfol1'
@@ -237,7 +249,8 @@ test_expect_success \
git-ls-files --stage >18.out &&
diff --unified=0 M.out 18.out &&
check_cache_at bozbar clean &&
- sha1sum -c M.sha1'
+ sum bozbar frotz nitfol >actual18.sum &&
+ cmp M.sum actual18.sum'
test_expect_success \
'19 - local change already having a good result, further modified.' \
@@ -249,8 +262,11 @@ test_expect_success \
git-ls-files --stage >19.out &&
diff --unified=0 M.out 19.out &&
check_cache_at bozbar dirty &&
- grep -v bozbar M.sha1 | sha1sum -c &&
- if sha1sum -c M.sha1; then false; else :; fi &&
+ sum frotz nitfol >actual19.sum &&
+ grep -v bozbar M.sum > expected19.sum &&
+ cmp expected19.sum actual19.sum &&
+ sum bozbar frotz nitfol >actual19a.sum &&
+ if cmp M.sum actual19a.sum; then false; else :; fi &&
echo gnusto gnusto >bozbar1 &&
diff bozbar bozbar1 &&
rm -f bozbar1'
@@ -264,7 +280,8 @@ test_expect_success \
git-ls-files --stage >20.out &&
diff --unified=0 M.out 20.out &&
check_cache_at bozbar clean &&
- sha1sum -c M.sha1'
+ sum bozbar frotz nitfol >actual20.sum &&
+ cmp M.sum actual20.sum'
test_expect_success \
'21 - no local change, dirty cache.' \
^ permalink raw reply
* [PATCH] Trivial sed fix up in t/t6001
From: Mark Allen @ 2005-06-28 1:43 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 223 bytes --]
This trivial patch fixes up the sed expression used in t/t6001. It removes the semi-colon
seperator and replaces it with white space which makes the BSD sed(1) much happier.
Signed-off-by: Mark Allen <mrallen1@yahoo.com>
[-- Attachment #2: 1890562984-t6001-sed-fixup.patch.txt --]
[-- Type: text/plain, Size: 486 bytes --]
diff --git a/t/t6001-rev-list-merge-order.sh b/t/t6001-rev-list-merge-order.sh
--- a/t/t6001-rev-list-merge-order.sh
+++ b/t/t6001-rev-list-merge-order.sh
@@ -40,7 +40,8 @@ save_tag()
[ -n "$_tag" ] || error "usage: save_tag tag commit-args ..."
shift 1
"$@" >.git/refs/tags/$_tag
- sed_script="s/$(tag $_tag)/$_tag/g${sed_script+;}$sed_script"
+ sed_script="s/$(tag $_tag)/$_tag/g
+$sed_script"
}
# Replace unhelpful sha1 hashses with their symbolic equivalents
^ permalink raw reply
* Re: CAREFUL! No more delta object support!
From: Junio C Hamano @ 2005-06-28 2:01 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.58.0506271755140.19755@ppc970.osdl.org>
>>>>> "LT" == Linus Torvalds <torvalds@osdl.org> writes:
LT> Now, there's still a misfeature there, which is that when you create a new
LT> object, it doesn't check whether that object already exists in the
LT> pack-file, so you'll end up with a few recent objects that you really
LT> don't need (notably tree objects), and we'll fix that eventually.
Patch will be sent separately.
LT> ... Also, please note that the pack-file _only_ packs the commits
LT> and the things reachable from them ...
Shouldn't feeding "git-rev-list --object" output plus
handcrafted list of objects in 2.6.11 tree object to
git-pack-objects just work???
LT> Maybe you might not want to switch over yet, and as mentioned, rsync then
LT> ends up not being a good way to sync (nor git-local-pull), but the
LT> "git-http/ssh-pull" family should hopefully just work.
No. The pull protocol Dan did expects to throw compressed
representation around on the wire (which is valid if you assume
uncompressed transfer) and does not use read-sha1-file --
write-sha1-file pair, so all three do not work.
^ permalink raw reply
* [PATCH] Skip writing out sha1 files for objects in packed git.
From: Junio C Hamano @ 2005-06-28 2:03 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <7vwtofi6jk.fsf@assigned-by-dhcp.cox.net>
Now, there's still a misfeature there, which is that when you
create a new object, it doesn't check whether that object
already exists in the pack-file, so you'll end up with a few
recent objects that you really don't need (notably tree
objects), and this patch fixes it.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
apply.c | 2 +-
cache.h | 2 +-
commit-tree.c | 2 +-
convert-cache.c | 6 +++---
mktag.c | 2 +-
sha1_file.c | 44 ++++++++++++++++++++++++++++++--------------
unpack-objects.c | 4 ++--
update-cache.c | 2 +-
write-tree.c | 2 +-
9 files changed, 41 insertions(+), 25 deletions(-)
f4f76b275cdabc038bcb4f3c7ca0d443638df88d
diff --git a/apply.c b/apply.c
--- a/apply.c
+++ b/apply.c
@@ -1221,7 +1221,7 @@ static void add_index_file(const char *p
if (lstat(path, &st) < 0)
die("unable to stat newly created file %s", path);
fill_stat_cache_info(ce, &st);
- if (write_sha1_file(buf, size, "blob", ce->sha1) < 0)
+ if (write_sha1_file(buf, size, "blob", ce->sha1, 0) < 0)
die("unable to create backing store for newly created file %s", path);
if (add_cache_entry(ce, ADD_CACHE_OK_TO_ADD) < 0)
die("unable to add cache entry for %s", path);
diff --git a/cache.h b/cache.h
--- a/cache.h
+++ b/cache.h
@@ -165,7 +165,7 @@ extern int parse_sha1_header(char *hdr,
extern int sha1_object_info(const unsigned char *, char *, unsigned long *);
extern void * unpack_sha1_file(void *map, unsigned long mapsize, char *type, unsigned long *size);
extern void * read_sha1_file(const unsigned char *sha1, char *type, unsigned long *size);
-extern int write_sha1_file(void *buf, unsigned long len, const char *type, unsigned char *return_sha1);
+extern int write_sha1_file(void *buf, unsigned long len, const char *type, unsigned char *return_sha1, int do_expand);
extern int check_sha1_signature(const unsigned char *sha1, void *buf, unsigned long size, const char *type);
diff --git a/commit-tree.c b/commit-tree.c
--- a/commit-tree.c
+++ b/commit-tree.c
@@ -191,7 +191,7 @@ int main(int argc, char **argv)
while (fgets(comment, sizeof(comment), stdin) != NULL)
add_buffer(&buffer, &size, "%s", comment);
- write_sha1_file(buffer, size, "commit", commit_sha1);
+ write_sha1_file(buffer, size, "commit", commit_sha1, 0);
printf("%s\n", sha1_to_hex(commit_sha1));
return 0;
}
diff --git a/convert-cache.c b/convert-cache.c
--- a/convert-cache.c
+++ b/convert-cache.c
@@ -111,7 +111,7 @@ static int write_subdirectory(void *buff
buffer += len;
}
- write_sha1_file(new, newlen, "tree", result_sha1);
+ write_sha1_file(new, newlen, "tree", result_sha1, 0);
free(new);
return used;
}
@@ -251,7 +251,7 @@ static void convert_date(void *buffer, u
memcpy(new + newlen, buffer, size);
newlen += size;
- write_sha1_file(new, newlen, "commit", result_sha1);
+ write_sha1_file(new, newlen, "commit", result_sha1, 0);
free(new);
}
@@ -286,7 +286,7 @@ static struct entry * convert_entry(unsi
memcpy(buffer, data, size);
if (!strcmp(type, "blob")) {
- write_sha1_file(buffer, size, "blob", entry->new_sha1);
+ write_sha1_file(buffer, size, "blob", entry->new_sha1, 0);
} else if (!strcmp(type, "tree"))
convert_tree(buffer, size, entry->new_sha1);
else if (!strcmp(type, "commit"))
diff --git a/mktag.c b/mktag.c
--- a/mktag.c
+++ b/mktag.c
@@ -123,7 +123,7 @@ int main(int argc, char **argv)
if (verify_tag(buffer, size) < 0)
die("invalid tag signature file");
- if (write_sha1_file(buffer, size, "tag", result_sha1) < 0)
+ if (write_sha1_file(buffer, size, "tag", result_sha1, 0) < 0)
die("unable to write tag file");
printf("%s\n", sha1_to_hex(result_sha1));
return 0;
diff --git a/sha1_file.c b/sha1_file.c
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -891,31 +891,47 @@ void *read_object_with_reference(const u
}
}
-int write_sha1_file(void *buf, unsigned long len, const char *type, unsigned char *returnsha1)
+static char *write_sha1_file_prepare(void *buf,
+ unsigned long len,
+ const char *type,
+ unsigned char *sha1,
+ unsigned char *hdr,
+ int *hdrlen)
{
- int size;
- unsigned char *compressed;
- z_stream stream;
- unsigned char sha1[20];
SHA_CTX c;
- char *filename;
- static char tmpfile[PATH_MAX];
- unsigned char hdr[50];
- int fd, hdrlen, ret;
/* Generate the header */
- hdrlen = sprintf((char *)hdr, "%s %lu", type, len)+1;
+ *hdrlen = sprintf((char *)hdr, "%s %lu", type, len)+1;
/* Sha1.. */
SHA1_Init(&c);
- SHA1_Update(&c, hdr, hdrlen);
+ SHA1_Update(&c, hdr, *hdrlen);
SHA1_Update(&c, buf, len);
SHA1_Final(sha1, &c);
+ return sha1_file_name(sha1);
+}
+
+int write_sha1_file(void *buf, unsigned long len, const char *type,
+ unsigned char *returnsha1, int do_expand)
+{
+ int size;
+ unsigned char *compressed;
+ z_stream stream;
+ unsigned char sha1[20];
+ char *filename;
+ static char tmpfile[PATH_MAX];
+ unsigned char hdr[50];
+ int fd, hdrlen, ret;
+
+ /* Normally if we have it in the pack then we do not bother writing
+ * it out into .git/objects/??/?{38} file.
+ */
+ filename = write_sha1_file_prepare(buf, len, type, sha1, hdr, &hdrlen);
if (returnsha1)
memcpy(returnsha1, sha1, 20);
-
- filename = sha1_file_name(sha1);
+ if (!do_expand && has_sha1_file(sha1))
+ return 0;
fd = open(filename, O_RDONLY);
if (fd >= 0) {
/*
@@ -1082,7 +1098,7 @@ int index_fd(unsigned char *sha1, int fd
if ((int)(long)buf == -1)
return -1;
- ret = write_sha1_file(buf, size, "blob", sha1);
+ ret = write_sha1_file(buf, size, "blob", sha1, 0);
if (size)
munmap(buf, size);
return ret;
diff --git a/unpack-objects.c b/unpack-objects.c
--- a/unpack-objects.c
+++ b/unpack-objects.c
@@ -126,7 +126,7 @@ static int unpack_non_delta_entry(struct
case 'B': type_s = "blob"; break;
default: goto err_finish;
}
- if (write_sha1_file(buffer, size, type_s, sha1) < 0)
+ if (write_sha1_file(buffer, size, type_s, sha1, 1) < 0)
die("failed to write %s (%s)",
sha1_to_hex(entry->sha1), type_s);
printf("%s %s\n", sha1_to_hex(sha1), type_s);
@@ -223,7 +223,7 @@ static int unpack_delta_entry(struct pac
die("failed to apply delta");
free(delta_data);
- if (write_sha1_file(result, result_size, type, sha1) < 0)
+ if (write_sha1_file(result, result_size, type, sha1, 1) < 0)
die("failed to write %s (%s)",
sha1_to_hex(entry->sha1), type);
free(result);
diff --git a/update-cache.c b/update-cache.c
--- a/update-cache.c
+++ b/update-cache.c
@@ -77,7 +77,7 @@ static int add_file_to_cache(char *path)
free(target);
return -1;
}
- if (write_sha1_file(target, st.st_size, "blob", ce->sha1))
+ if (write_sha1_file(target, st.st_size, "blob", ce->sha1, 0))
return -1;
free(target);
break;
diff --git a/write-tree.c b/write-tree.c
--- a/write-tree.c
+++ b/write-tree.c
@@ -76,7 +76,7 @@ static int write_tree(struct cache_entry
nr++;
}
- write_sha1_file(buffer, offset, "tree", returnsha1);
+ write_sha1_file(buffer, offset, "tree", returnsha1, 0);
free(buffer);
return nr;
}
------------
^ permalink raw reply
* Re: CAREFUL! No more delta object support!
From: Linus Torvalds @ 2005-06-28 2:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwtofi6jk.fsf@assigned-by-dhcp.cox.net>
On Mon, 27 Jun 2005, Junio C Hamano wrote:
>
> LT> ... Also, please note that the pack-file _only_ packs the commits
> LT> and the things reachable from them ...
>
> Shouldn't feeding "git-rev-list --object" output plus
> handcrafted list of objects in 2.6.11 tree object to
> git-pack-objects just work???
You could do that. And yes, we can add support for "tag" objects too
(which the packing doesn't do at all right now. So this is not a
"fundamental" problem, it's just a practical one right now.
> > [.. git-ssh-pull hopefully working ..]
>
> No. The pull protocol Dan did expects to throw compressed
> representation around on the wire (which is valid if you assume
> uncompressed transfer) and does not use read-sha1-file --
> write-sha1-file pair, so all three do not work.
Fair enough. I'd prefer for the pull/push to push object packs around
anyway, so there's some more work there..
Linus
^ permalink raw reply
* Re: CAREFUL! No more delta object support!
From: Junio C Hamano @ 2005-06-28 2:32 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.58.0506271910390.19755@ppc970.osdl.org>
>>>>> "LT" == Linus Torvalds <torvalds@osdl.org> writes:
LT> Fair enough. I'd prefer for the pull/push to push object packs around
LT> anyway, so there's some more work there..
Yes, I'd prefer that too.
By the way, you broke t/t0000 with the last commit. Now an
empty GIT_OBJECT_DIRECTORY has 257 subdirectories.
^ permalink raw reply
* [PATCH] Adjust to git-init-db creating $GIT_OBJECT_DIRECTORY/pack
From: Junio C Hamano @ 2005-06-28 2:37 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <7vslz3yzwf.fsf@assigned-by-dhcp.cox.net>
Some tests expected the directory not to exist by default.
Updated git-init-db prepares it properly so adjust tests to
match that behaviour.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
t/t0000-basic.sh | 6 +++---
t/t5300-pack-object.sh | 1 -
2 files changed, 3 insertions(+), 4 deletions(-)
de500ab0379e4db18d1511cbe91ace106eee7830
diff --git a/t/t0000-basic.sh b/t/t0000-basic.sh
--- a/t/t0000-basic.sh
+++ b/t/t0000-basic.sh
@@ -28,11 +28,11 @@ test_expect_success \
'.git/objects should be empty after git-init-db in an empty repo.' \
'cmp -s /dev/null should-be-empty'
-# also it should have 256 subdirectories. 257 is counting "objects"
+# also it should have 257 subdirectories. 258 is counting "objects"
find .git/objects -type d -print >full-of-directories
test_expect_success \
- '.git/objects should have 256 subdirectories.' \
- 'test $(wc -l < full-of-directories) = 257'
+ '.git/objects should have 257 subdirectories.' \
+ 'test $(wc -l < full-of-directories) = 258'
################################################################
# Basics of the basics
diff --git a/t/t5300-pack-object.sh b/t/t5300-pack-object.sh
--- a/t/t5300-pack-object.sh
+++ b/t/t5300-pack-object.sh
@@ -99,7 +99,6 @@ test_expect_success \
'GIT_OBJECT_DIRECTORY=.git2/objects &&
export GIT_OBJECT_DIRECTORY &&
git-init-db &&
- mkdir .git2/objects/pack &&
cp test-1.pack test-1.idx .git2/objects/pack && {
git-diff-tree --root -p $commit &&
while read object
------------
^ permalink raw reply
* Re: [PATCH] Skip writing out sha1 files for objects in packed git.
From: Linus Torvalds @ 2005-06-28 2:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vr7eni6fy.fsf_-_@assigned-by-dhcp.cox.net>
On Mon, 27 Jun 2005, Junio C Hamano wrote:
>
> Now, there's still a misfeature there, which is that when you
> create a new object, it doesn't check whether that object
> already exists in the pack-file, so you'll end up with a few
> recent objects that you really don't need (notably tree
> objects), and this patch fixes it.
>
> Signed-off-by: Junio C Hamano <junkio@cox.net>
Actually, I don't think that "do_expand" flag should exist.
If we want to expand a packed file and really write the objects to the
.git/objects directories, we should just not have that packed file in the
.git/objects/pack directory.
And if we have a pack-file in .git/objects/ that already has the object,
that may not be the _same_ pack-file that we're expanding at all, so if
that pack file already has the object, then not writing it out is actually
the right thing to do.
That will also simplify your patch a bit. I'll fix it up.
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