* [PATCH] Add --no-reuse-delta option to git-gc
From: Theodore Ts'o @ 2007-05-08 13:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List, Theodore Ts'o
In-Reply-To: <11786309072612-git-send-email-tytso@mit.edu>
This allows the user to regenerate the deltas in packs while doing
a git-gc. The user could just run git-repack -a -d -f -l after
running git-gc, but then the first git-repack run by git-gc is
a bit of waste.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
---
Documentation/git-gc.txt | 7 ++++++-
builtin-gc.c | 24 ++++++++++++++++++++++--
2 files changed, 28 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-gc.txt b/Documentation/git-gc.txt
index bc16584..0493d06 100644
--- a/Documentation/git-gc.txt
+++ b/Documentation/git-gc.txt
@@ -8,7 +8,7 @@ git-gc - Cleanup unnecessary files and optimize the local repository
SYNOPSIS
--------
-'git-gc' [--prune]
+'git-gc' [--prune] [--no-reuse-delta]
DESCRIPTION
-----------
@@ -35,6 +35,11 @@ OPTIONS
repository at the same time (e.g. never use this option
in a cron script).
+--no-reuse-delta::
+ This causes deltas in existing packs to be recalculated instead
+ of reusing the existing deltas. This can save disk space at
+ the cost of taking more time to recalculate them from scratch.
+
Configuration
-------------
diff --git a/builtin-gc.c b/builtin-gc.c
index 3b1f8c2..5cb7ffd 100644
--- a/builtin-gc.c
+++ b/builtin-gc.c
@@ -15,13 +15,14 @@
#define FAILED_RUN "failed to run %s"
-static const char builtin_gc_usage[] = "git-gc [--prune]";
+static const char builtin_gc_usage[] = "git-gc [--prune] [--no-reuse-delta]";
static int pack_refs = -1;
+#define MAX_ADD 10
static const char *argv_pack_refs[] = {"pack-refs", "--prune", NULL};
static const char *argv_reflog[] = {"reflog", "expire", "--all", NULL};
-static const char *argv_repack[] = {"repack", "-a", "-d", "-l", NULL};
+static const char *argv_repack[MAX_ADD] = {"repack", "-a", "-d", "-l", NULL};
static const char *argv_prune[] = {"prune", NULL};
static const char *argv_rerere[] = {"rerere", "gc", NULL};
@@ -37,6 +38,21 @@ static int gc_config(const char *var, const char *value)
return git_default_config(var, value);
}
+static append_option(const char **cmd, const char *opt, int max_length)
+{
+ int i;
+
+ for (i=0; cmd[i]; i++)
+ ;
+
+ if (i+2 >= max_length) {
+ fprintf(stderr, "Too many options specified\n");
+ exit(1);
+ }
+ cmd[i++] = opt;
+ cmd[i] = 0;
+}
+
int cmd_gc(int argc, const char **argv, const char *prefix)
{
int i;
@@ -53,6 +69,10 @@ int cmd_gc(int argc, const char **argv, const char *prefix)
prune = 1;
continue;
}
+ if (!strcmp(arg, "--no-reuse-delta")) {
+ append_option(argv_repack, "-f", MAX_ADD);
+ continue;
+ }
/* perhaps other parameters later... */
break;
}
--
1.5.2.rc2.22.ga39d
^ permalink raw reply related
* Re: [PATCH] Add --no-reuse-delta, --window, and --depth options to
From: Theodore Ts'o @ 2007-05-08 13:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vr6ps3oyk.fsf@assigned-by-dhcp.cox.net>
OK, here's a patch to implement pack.depth (with the default tweaked
to 50 --- is that too high?), followed by a simplified and reworked
patch to git-gc that only implements --no-reuse-delta.
I don't imagine that most users will want to use that feature most of
the time, hence the long option name, but occasionally, it might be
useful. Yes, the user could just run "git-repack -a -d -f -l" after
running git-gc, but then the "git-repack -a -d -l" in git-gc is just a
wasted disk i/o. I don't know if I'll manage to convince you, if not,
just drop the second patch, I guess. :-)
- Ted
^ permalink raw reply
* [PATCH] Add pack.depth option to git-pack-objects and change default depth to 50
From: Theodore Ts'o @ 2007-05-08 13:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List, Theodore Ts'o
In-Reply-To: <11786309073709-git-send-email-tytso@mit.edu>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
---
Documentation/config.txt | 6 +++++-
Documentation/git-pack-objects.txt | 2 +-
Documentation/git-repack.txt | 2 +-
builtin-pack-objects.c | 6 +++++-
4 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 24f9655..c7674c2 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -544,7 +544,11 @@ merge.<driver>.recursive::
pack.window::
The size of the window used by gitlink:git-pack-objects[1] when no
- window size is given on the command line. Defaults to 10.
+ window size is given on the command line. Defaults to 10.
+
+pack.depth::
+ The maximum delta depth used by gitlink:git-pack-objects[1] when no
+ maximum depth is given on the command line. Defaults to 50.
pull.octopus::
The default merge strategy to use when pulling multiple branches
diff --git a/Documentation/git-pack-objects.txt b/Documentation/git-pack-objects.txt
index d9e11c6..bd3ee45 100644
--- a/Documentation/git-pack-objects.txt
+++ b/Documentation/git-pack-objects.txt
@@ -83,7 +83,7 @@ base-name::
it too deep affects the performance on the unpacker
side, because delta data needs to be applied that many
times to get to the necessary object.
- The default value for both --window and --depth is 10.
+ The default value for --window is 10 and --depth is 50.
--incremental::
This flag causes an object already in a pack ignored
diff --git a/Documentation/git-repack.txt b/Documentation/git-repack.txt
index d39abc1..cc3b0b2 100644
--- a/Documentation/git-repack.txt
+++ b/Documentation/git-repack.txt
@@ -63,7 +63,7 @@ OPTIONS
space. `--depth` limits the maximum delta depth; making it too deep
affects the performance on the unpacker side, because delta data needs
to be applied that many times to get to the necessary object.
- The default value for both --window and --depth is 10.
+ The default value for --window is 10 and --depth is 50.
Configuration
diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
index 7bff8ea..966f843 100644
--- a/builtin-pack-objects.c
+++ b/builtin-pack-objects.c
@@ -64,6 +64,7 @@ static char tmpname[PATH_MAX];
static unsigned char pack_file_sha1[20];
static int progress = 1;
static int window = 10;
+static int depth = 50;
static int pack_to_stdout;
static int num_preferred_base;
static struct progress progress_state;
@@ -1489,6 +1490,10 @@ static int git_pack_config(const char *k, const char *v)
window = git_config_int(k, v);
return 0;
}
+ if(!strcmp(k, "pack.depth")) {
+ depth = git_config_int(k, v);
+ return 0;
+ }
return git_default_config(k, v);
}
@@ -1584,7 +1589,6 @@ static int adjust_perm(const char *path, mode_t mode)
int cmd_pack_objects(int argc, const char **argv, const char *prefix)
{
- int depth = 10;
int use_internal_rev_list = 0;
int thin = 0;
uint32_t i;
--
1.5.2.rc2.22.ga39d
^ permalink raw reply related
* Re: [PATCH] Add --no-reuse-delta, --window, and --depth options to git-gc
From: Nicolas Pitre @ 2007-05-08 13:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Theodore Tso, git
In-Reply-To: <7vr6ps3oyk.fsf@assigned-by-dhcp.cox.net>
On Mon, 7 May 2007, Junio C Hamano wrote:
> Theodore Tso <tytso@mit.edu> writes:
>
> > On Mon, May 07, 2007 at 11:13:58PM -0400, Nicolas Pitre wrote:
> >> ...
> >> Especially if you're aware and interested in those options, you won't be
> >> afraid of 'git repack -a -f -d --window=...".
> >>
> >> In the context of "gc", having an option that reads "window" looks a bit
> >> strange too.
> >
> > I suppose, but you either need to then know all of the other commands
> > which git-gc runs, and do them manually, skipping git-gc altogether,
> > or use git-gc, and end up rewriting the pack twice,...
>
> If the user really wants to tweak the parameters that much and
> that often, I think what Nico says, plus your pack.depth/window
> configuration variables, make more sense.
Also, once you've run git-repack with -f and the window/depth params you
want, those deltas will be reused as is by default afterwards even if
you use git-gc. So the big repack to tighten a large repo needs only to
be done once.
Nicolas
^ permalink raw reply
* git pull failure, truncated object
From: Bill Lear @ 2007-05-08 14:28 UTC (permalink / raw)
To: git
Our QA dude had a disk fill up a while back. Forgot about it. Went
to pull during a nightly build. Got this:
% git pull
remote: Generating pack...
remote: Done counting 104 objects.
remote: Result has 72 objects.
remote: Deltifying 72 objects.
remote: 100% (72/72) done
Unpacking 72 objects
remote: Total 72 (delta 46), reused 52 (delta 26)
error: failed to read delta-pack base object
4b93eb81265ea4f2b436618a4b1c3bea2bedf06d
fatal: unpack-objects died with error code 1
He did a git-gc, twice, and retried. Still failed.
So, he called me in and we tried to see if the server was acting up
--- perhaps an NFS problem, as we've had those before, but got very
different error messages. Watched the log file from git-daemon, and
saw nothing. Finally we took a look at the local repos
.git/objects/4b, and 4b93eb81265ea4f2b436618a4b1c3bea2bedf06d was of
length 0.
So, I looked in the man page of git-gc and thought to try --prune,
as this was not an active repository. This worked, and then
the pull did as well.
I'm wondering why git-gc did not at least warn us of this problem when
we tried it. It appeared to us that git-gc gave our repo a clean bill
of health, and so we turned our attention to the remote and
investigated there, instead of continuing in the local repo.
Should we have tried git fsck instead in this case?
It might be nice to have a better error message in this case, one
that locates the problem in the local repo.
If the failure is a short/bad (?) read of a local object, then it
might be nice to say something like:
error: this repo's local object 4b93eb81265ea4f2b436618a4b1c3bea2bedf06d
in .git/objects/4b is corrupt. You will need to run
XXX to diagnose and YYY to repair this.
Or some such.
Bill
^ permalink raw reply
* Re: [PATCH] git-gui: Call changes "Staged" and "Unstaged" in file list titles.
From: Shawn O. Pearce @ 2007-05-08 14:38 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <46405FF2.1B600CBE@eudaptics.com>
Johannes Sixt <J.Sixt@eudaptics.com> wrote:
> From: Johannes Sixt <johannes.sixt@telecom.at>
>
> All menu entries talk about "staging" and "unstaging" changes, but the
> titles of the file lists use different wording, which may confuse
> newcomers.
>
> Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
> ---
> I hope the patch went through without my MUA's "improvements".
Yes. But...
> git-gui/git-gui.sh | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
That's the wrong path. Clearly you made this patch in git.git and
not the git-gui.git repository itself. Fortunately for me I added
-3 to git-am out of habit:
$ git am -3 -s gg
Applying 'git-gui: Call changes "Staged" and "Unstaged" in file list titles.'
error: git-gui/git-gui.sh: does not exist in index
Using index info to reconstruct a base tree...
Falling back to patching base and 3-way merge...
Renamed git-gui/git-gui.sh => git-gui.sh
Wrote tree 8e034a94d9533af707279766e174b78ddf3874cc
Committed: a1a4975824e8f9f88a8c96ae908c488a2c6047c5
Yay Git! Go go gadget rename detection! ;-)
I didn't even realize the git-gui/ prefix on the path in the patch
until after I saw the rename detection message.
--
Shawn.
^ permalink raw reply
* Re: git-svn: importing branches later
From: Seth Falcon @ 2007-05-08 14:51 UTC (permalink / raw)
To: git
In-Reply-To: <20070508085149.GB24409@diana.vm.bytemark.co.uk>
Karl Hasselström <kha@treskal.com> writes:
> On 2007-05-07 13:07:06 -0600, Michael Hendricks wrote:
>
>> Now I want to import the 'foo' branch from the same SVN repo without
>> grabbing all the branches. Any suggestions?
>
> I seem to recall that just adding another "fetch" line to the git-svn
> configuration in .git/config will do this for you.
Yes, this should work. As long as you started out with a fairly
recent git (sorry, I don't know how recent is needed) you should have
in your repository a git/config file containing something like:
[svn-remote "svn"]
url = http://main.svn.url.com/
fetch = trunk:refs/remotes/git-svn
fetch = branches/b1:refs/remotes/b1 <-- this line added by you
Then a 'git svn fetch' should pull it all down and you can checkout
the branch using 'git checkout -b myb1 remotes/b1'. At this point,
'git svn rebase' is smart enough to know where the branch comes from.
What may not work when you add branches in this way is that the
history may not connect with the actual branch commit in svn. I'm
fairly sure there is some way to fix that, but I haven't done it.
+ seth
^ permalink raw reply
* Re: [FAQ?] Rationale for git's way to manage the index
From: Shawn O. Pearce @ 2007-05-08 14:52 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Julian Phillips, Matthieu Moy, git
In-Reply-To: <20070508073739.GA24409@diana.vm.bytemark.co.uk>
Karl Hasselstr??m <kha@treskal.com> wrote:
> It's currently possible to split some hunks by
> reducing the number of content lines, but if the changes aren't
> separated by any unchanged lines at all, that doesn't work.
Yea, I've played that game before too (reduce content lines) to
try and simulate a hunk splitter. ;-) Doesn't always work.
Right now I feel like a huge chunk of the git-gui code is simply not
maintainable. The 0.7.0 release is really more about refactoring the
code to make it more maintainable, than it is about actual features
(though there are some new things, like vi-keys).
The hunk selection stuff is just one part of the 2,000 lines
still left in git-gui.sh itself, and that still uses a lot of
messy globals. I want to get the code better organized before
I take on major new additions to it.
> > I also want to let you revert hunks from the working directory copy.
>
> That would be handy. But unlike stage/unstage, this can lose
> information, so there'd need to be some kind of "are you _really_
> sure? [Yes] [No]" safety hatch, which would make it less convenient.
True, but that beats the tar out of copying the - lines to your
clipboard and pasting them into your text editor, then deleting
the - prefix. Especially if its a couple of hunks that you want
to revert. Which I find myself doing all to often.
Actually I work around it today by staging what I care about,
then reverting the file. Since the revert comes out of the index,
I get (mostly) the same action as reverting a particular hunk.
But it does mean that I lose my index state, if that happened to
be of any particular interest.
> I assume that shelves would be implemented as branches that are
> precisely one commit on top of HEAD? If so, I'd just like to point out
> that they're exactly like unapplied patches in StGIT.
I haven't looked at StGIT in a while. I've seen noise on the list
about nifty features being added, but I haven't kept up with what
those features actually are. I think you are right about this and
maybe git-gui should try to be compatible with StGIT's unapplied
patches, should I get into actually implementing a shelving system.
> Hmm. I find it inconsistent to force or strongly encourage the user to
> commit precisely the working directory changes and not a subset
> thereof, which the shelf idea seems to encourage, while at the same
> time not committing straight from the working directory but from a
> specific staging area (the index).
Indeed; I was thinking that this very morning. Making an index that
you stage things into, but then also saying you cannot really do that
and instead have to shelve what you don't want - that's just evil.
I'll have to think about it more.
The blame interface in git-gui needs help more than the index
staging features. The colors suck. ;-)
--
Shawn.
^ permalink raw reply
* Re: [FAQ?] Rationale for git's way to manage the index
From: Karl Hasselström @ 2007-05-08 14:53 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Johannes Sixt, git
In-Reply-To: <20070508124027.GA14366@fieldses.org>
On 2007-05-08 08:40:27 -0400, J. Bruce Fields wrote:
> On Tue, May 08, 2007 at 12:28:36PM +0200, Karl Hasselström wrote:
>
> > I think it would be worth introducing git-gui as a commit tool in
> > the tutorial(s) and the manual. It gives a very nice graphical
> > representation of the dirty state you're going to commit, and the
> > dirty state you aren't going to commit because you haven't staged
> > it yet. The only drawback is that it's a lot of work to make
> > documentation with screenshots ...
>
> For the tutorial and user manual, could git-gui be treated similar
> gitk, with just a one- or two- line mention here and there? I
> haven't used it, so don't know where it would most logically fit
> in....
I would introduce it with a paragraph or two right where committing is
covered the first time. Explain that the empty file list box to the
left contains the changes that will be committed when you press the
commit button, and that the file list box on the right contains the
changes that won't be committed. By clicking on a file name you get to
see the diff to the file, and by clicking on the icon you move it to
the other file list box -- that is, you stage/unstage it.
And now comes the clever part: Introduce the index, by explaining that
it essentially _is_ the left file list box. Explain that git-add is
the command-line equivalent of moving changes to the left box, and
that git-commit without arguments simply commits what's in the index
-- exactly like git-gui's Commit button.
I think it could work. :-)
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: git pull failure, truncated object
From: Shawn O. Pearce @ 2007-05-08 14:59 UTC (permalink / raw)
To: Bill Lear; +Cc: git
In-Reply-To: <17984.35097.568689.482933@lisa.zopyra.com>
Bill Lear <rael@zopyra.com> wrote:
...
> error: failed to read delta-pack base object
> 4b93eb81265ea4f2b436618a4b1c3bea2bedf06d
> fatal: unpack-objects died with error code 1
Danger Will Robinson! Danger! Your repository is not acting
normally...
> So, I looked in the man page of git-gc and thought to try --prune,
> as this was not an active repository. This worked, and then
> the pull did as well.
Don't run git-gc on a repository that is acting strangely, unless
you have concluded that the correct course of action is to just
repack the repository. (It rarely is, btw.) You could make things
worse if a packfile contains a corrupt object and you have the
same valid loose object; a gc would delete the valid object and
keep the corrupt one.
> I'm wondering why git-gc did not at least warn us of this problem when
> we tried it. It appeared to us that git-gc gave our repo a clean bill
> of health, and so we turned our attention to the remote and
> investigated there, instead of continuing in the local repo.
>
> Should we have tried git fsck instead in this case?
Yes, git-fsck is meant for checking the "health" of a repository.
In this case it should have caught the 0 length object and told
you that loose object was corrupt. A sure sign that you have a
problem. If you have a loose object problem, `git prune` might
fix it, as it did here, but only if that object isn't actually
needed. A `git fsck` immediately after would tell you if the
prune fixed the issue, or not.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] [TRIVIAL] Change default man page path to /usr/share/man
From: Uwe Kleine-König @ 2007-05-08 15:02 UTC (permalink / raw)
To: Ismail Dönmez; +Cc: git
In-Reply-To: <200705081349.34964.ismail@pardus.org.tr>
Hallo,
Ismail Dönmez wrote:
> According to FHS standard default man page path is $prefix/share/man [0] ,
> attached patch fixes this for GIT.
According to some GNU standard it's $prefix/man.
E.g. autoconf managed projects use $prefix/man if you don't give
--mandir=... to configure.
Personally I prefer FHS, so I have
mandir=$(prefix)/share/man
in my config.mak.
Best regards
Uwe
--
Uwe Kleine-König
http://www.google.com/search?q=72+PS+point+in+inch
^ permalink raw reply
* Re: git pull failure, truncated object
From: Shawn O. Pearce @ 2007-05-08 15:05 UTC (permalink / raw)
To: Bill Lear; +Cc: git
In-Reply-To: <20070508145916.GQ11311@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> wrote:
> Don't run git-gc on a repository that is acting strangely, unless
> you have concluded that the correct course of action is to just
> repack the repository. (It rarely is, btw.) You could make things
> worse if a packfile contains a corrupt object and you have the
> same valid loose object; a gc would delete the valid object and
> keep the corrupt one.
OK, my statement is a little blown-out-of-proportion. Its pretty
hard these days to corrupt an object within a packfile such that
we'll be able to reuse it during the repack that goes on in git-gc,
but still actually have it be corrupt enough that the object is
useless. The recent index version 2 work from Nico makes it even
harder, as the index adds an additional checksum over the entire
object header and body.
But still, even though the risk is pretty small, I think that
running a destructive operation like git-gc in a repository that is
not acting normally is a bad idea. You should try to diagnose and
correct the issue before making further changes (or reorganizations)
to that repository's contents.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] git-gui: Call changes "Staged" and "Unstaged" in file list titles.
From: Johannes Schindelin @ 2007-05-08 15:13 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Johannes Sixt, git
In-Reply-To: <20070508143859.GO11311@spearce.org>
Hi,
On Tue, 8 May 2007, Shawn O. Pearce wrote:
> Yay Git! Go go gadget rename detection! ;-)
Now, how cool is _that_!
Ciao,
Dscho
^ permalink raw reply
* [PATCH] Add a birdview-on-the-source-code section to the user manual
From: Johannes Schindelin @ 2007-05-08 15:10 UTC (permalink / raw)
To: bfields, junio, git
In http://thread.gmane.org/gmane.comp.version-control.git/42479,
a birdview on the source code was requested.
J. Bruce Fields suggested that my reply should be included in the
user manual, and there was nothing of an outcry, so here it is,
not even 2 months later.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
Documentation/user-manual.txt | 196 +++++++++++++++++++++++++++++++++++++++++
1 files changed, 196 insertions(+), 0 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 67f5b9b..3c67b68 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -3161,6 +3161,202 @@ confusing and scary messages, but it won't actually do anything bad. In
contrast, running "git prune" while somebody is actively changing the
repository is a *BAD* idea).
+[[birdview-on-the-source-code]]
+A birdview on Git's source code
+-----------------------------
+
+While Git's source code is quite elegant, it is not always easy for
+new developers to find their way through it. A good idea is to look
+at the contents of the initial commit:
+_e83c5163316f89bfbde7d9ab23ca2e25604af290_ (also known as _v0.99~954_).
+
+Tip: you can see what files are in there with
+
+----------------------------------------------------
+$ git show e83c5163316f89bfbde7d9ab23ca2e25604af290:
+----------------------------------------------------
+
+and look at those files with something like
+
+-----------------------------------------------------------
+$ git show e83c5163316f89bfbde7d9ab23ca2e25604af290:cache.h
+-----------------------------------------------------------
+
+Be sure to read the README in that revision _after_ you are familiar with
+the terminology (<<glossary>>), since the terminology has changed a little
+since then. For example, we call the things "commits" now, which are
+described in that README as "changesets".
+
+Actually a lot of the structure as it is now can be explained by that
+initial commit.
+
+For example, we do not call it "cache" any more, but "index", however, the
+file is still called `cache.h`. Remark: Not much reason to change it now,
+especially since there is no good single name for it anyway, because it is
+basically _the_ header file which is included by _all_ of Git's C sources.
+
+If you grasp the ideas in that initial commit (it is really small and you
+can get into it really fast, and it will help you recognize things in the
+much larger code base we have now), you should go on skimming `cache.h`,
+`object.h` and `commit.h`.
+
+By now, you know what the index is (and find the corresponding data
+structures in `cache.h`), and that there are just a couple of object types
+(blobs, trees, commits and tags) which inherit their common structure from
+`struct object`, which is their first member (and thus, you can cast e.g.
+`(struct object *)commit` to achieve the _same_ as `&commit->object`, i.e.
+get at the object name and flags).
+
+Now is a good point to take a break to let this information sink in.
+
+Next step: get familiar with the object naming. Read <<naming-commits>>.
+There are quite a few ways to name an object (and not only revisions!).
+All of these are handled in `sha1_name.c`. Just have a quick look at
+the function `get_sha1()`. A lot of the special handling is done by
+functions like `get_sha1_basic()` or the likes.
+
+This is just to get you into the groove for the most libified part of Git:
+the revision walker.
+
+Basically, the initial version of `git log` was a shell script:
+
+----------------------------------------------------------------
+$ git-rev-list --pretty $(git-rev-parse --default HEAD "$@") | \
+ LESS=-S ${PAGER:-less}
+----------------------------------------------------------------
+
+What does this mean?
+
+`git-rev-list` is the original version of the revision walker, which
+_always_ printed a list of revisions to stdout. It is still functional,
+and needs to, since most new Git programs start out as scripts using
+`git-rev-list`.
+
+`git-rev-parse` is not as important any more; it was only used to filter out
+options that were relevant for the different plumbing commands that were
+called by the script.
+
+Most of what `git-rev-list` did is contained in `revision.c` and
+`revision.h`. It wraps the options in a struct named rev_info, which
+controls how and what revisions are walked, and more.
+
+Nowadays, `git log` is a builtin, which means that it is _contained_ in the
+command `git`. The source side of a builtin is
+
+- a function called `cmd_<bla>`, typically defined in `builtin-<bla>.c`,
+ and declared in `builtin.h`,
+
+- an entry in the `commands[]` array in `git.c`, and
+
+- an entry in `BUILTIN_OBJECTS` in the `Makefile`.
+
+Sometimes, more than one builtin is contained in one source file. For
+example, `cmd_whatchanged()` and `cmd_log()` both reside in `builtin-log.c`,
+since they share quite a bit of code. In that case, the commands which are
+_not_ named like the `.c` file in which they live have to be listed in
+`BUILT_INS` in the `Makefile`.
+
+`git log` looks more complicated in C than it does in the original script,
+but that allows for a much greater flexibility and performance.
+
+Here again it is a good point to take a pause.
+
+Lesson three is: study the code. Really, it is the best way to learn about
+the organization of Git (after you know the basic concepts).
+
+So, think about something which you are interested in, say, "how can I
+access a blob just knowing the object name of it?". The first step is to
+find a Git command with which you can do it. In this example, it is either
+`git show` or `git cat-file`.
+
+For the sake of clarity, let's stay with `git cat-file`, because it
+
+- is plumbing, and
+
+- was around even in the initial commit (it literally went only through
+ some 20 revisions as `cat-file.c`, was renamed to `builtin-cat-file.c`
+ when made a builtin, and then saw less than 10 versions).
+
+So, look into `builtin-cat-file.c`, search for `cmd_cat_file()` and look what
+it does.
+
+------------------------------------------------------------------
+ git_config(git_default_config);
+ if (argc != 3)
+ usage("git-cat-file [-t|-s|-e|-p|<type>] <sha1>");
+ if (get_sha1(argv[2], sha1))
+ die("Not a valid object name %s", argv[2]);
+------------------------------------------------------------------
+
+Let's skip over the obvious details; the only really interesting part
+here is the call to `get_sha1()`. It tries to interpret `argv[2]` as an
+object name, and if it refers to an object which is present in the current
+repository, it writes the resulting SHA-1 into the variable `sha1`.
+
+Two things are interesting here:
+
+- `get_sha1()` returns 0 on _success_. This might surprise some new
+ Git hackers, but there is a long tradition in UNIX to return different
+ negative numbers in case of different errors -- and 0 on success.
+
+- the variable `sha1` in the function signature of `get_sha1()` is `unsigned
+ char *`, but is actually expected to be a pointer to `unsigned
+ char[20]`. This variable will contain the big endian version of the
+ 40-character hex string representation of the SHA-1.
+
+You will see both of these things throughout the code.
+
+Now, for the meat:
+
+-----------------------------------------------------------------------------
+ case 0:
+ buf = read_object_with_reference(sha1, argv[1], &size, NULL);
+-----------------------------------------------------------------------------
+
+This is how you read a blob (actually, not only a blob, but any type of
+object). To know how the function `read_object_with_reference()` actually
+works, find the source code for it (something like `git grep
+read_object_with | grep ":[a-z]"` in the git repository), and read
+the source.
+
+To find out how the result can be used, just read on in `cmd_cat_file()`:
+
+-----------------------------------
+ write_or_die(1, buf, size);
+-----------------------------------
+
+Sometimes, you do not know where to look for a feature. In many such cases,
+it helps to search through the output of `git log`, and then `git show` the
+corresponding commit.
+
+Example: If you know that there was some test case for `git bundle`, but
+do not remember where it was (yes, you _could_ `git grep bundle t/`, but that
+does not illustrate the point!):
+
+------------------------
+$ git log --no-merges t/
+------------------------
+
+In the pager (`less`), just search for "bundle", go a few lines back,
+and see that it is in commit 18449ab0... Now just copy this object name,
+and paste it into the command line
+
+-------------------
+$ git show 18449ab0
+-------------------
+
+Voila.
+
+Another example: Find out what to do in order to make some script a
+builtin:
+
+-------------------------------------------------
+$ git log --no-merges --diff-filter=A builtin-*.c
+-------------------------------------------------
+
+You see, Git is actually the best tool to find out about the source of Git
+itself!
+
[[glossary]]
include::glossary.txt[]
--
1.5.2.rc2.2469.gea95f
^ permalink raw reply related
* Re: [PATCH] [TRIVIAL] Change default man page path to /usr/share/man
From: Ismail Dönmez @ 2007-05-08 15:23 UTC (permalink / raw)
To: Uwe Kleine-König; +Cc: git
In-Reply-To: <20070508150220.GA18860@informatik.uni-freiburg.de>
[-- Attachment #1: Type: text/plain, Size: 659 bytes --]
Hi,
On Tuesday 08 May 2007 18:02:20 Uwe Kleine-König wrote:
> Ismail Dönmez wrote:
> > According to FHS standard default man page path is $prefix/share/man [0]
> > , attached patch fixes this for GIT.
>
> According to some GNU standard it's $prefix/man.
>
> E.g. autoconf managed projects use $prefix/man if you don't give
> --mandir=... to configure.
Just noticed one can do make mandir=/usr/share/man
> Personally I prefer FHS, so I have
>
> mandir=$(prefix)/share/man
>
> in my config.mak.
Same here, IMHO FHS makes more sense and AFAIK most distros
uses /usr/share/man.
Regards,
ismail
--
Le mieux est l'ennemi du bien.
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Add --no-reuse-delta, --window, and --depth options to
From: Nicolas Pitre @ 2007-05-08 15:30 UTC (permalink / raw)
To: Theodore Ts'o; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <11786309073709-git-send-email-tytso@mit.edu>
On Tue, 8 May 2007, Theodore Ts'o wrote:
> OK, here's a patch to implement pack.depth (with the default tweaked
> to 50 --- is that too high?),
This is most likely to affect runtime performances, but some benchmarks
would be needed to find out how much.
Having both pack.depth and pack.window as config options (with current
defaults of 10) would certainly be a good thing. Tweaking those
defaults should probably be investigated separately.
> followed by a simplified and reworked
> patch to git-gc that only implements --no-reuse-delta.
>
> I don't imagine that most users will want to use that feature most of
> the time, hence the long option name, but occasionally, it might be
> useful. Yes, the user could just run "git-repack -a -d -f -l" after
> running git-gc, but then the "git-repack -a -d -l" in git-gc is just a
> wasted disk i/o.
In which case, it is git-gc that needs to get a bit smarter. Maybe
something like this:
----- >*
Avoid running git-repack from git-gc if there is evidently nothing to
repack.
Signed-off-by: Nicolas Pitre <nico@cam.org>
---
diff --git a/builtin-count-objects.c b/builtin-count-objects.c
index ff90ebd..8d79764 100644
--- a/builtin-count-objects.c
+++ b/builtin-count-objects.c
@@ -67,13 +67,40 @@ static void count_objects(DIR *d, char *path, int len, int verbose,
}
}
-int cmd_count_objects(int ac, const char **av, const char *prefix)
+static void count_loose_objects(int verbose,
+ unsigned long *loose,
+ unsigned long *loose_size,
+ unsigned long *packed_loose,
+ unsigned long *garbage)
{
- int i;
- int verbose = 0;
const char *objdir = get_object_directory();
- int len = strlen(objdir);
+ int i, len = strlen(objdir);
char *path = xmalloc(len + 50);
+ memcpy(path, objdir, len);
+ if (len && objdir[len-1] != '/')
+ path[len++] = '/';
+ for (i = 0; i < 256; i++) {
+ DIR *d;
+ sprintf(path + len, "%02x", i);
+ d = opendir(path);
+ if (!d)
+ continue;
+ count_objects(d, path, len, verbose,
+ loose, loose_size, packed_loose, garbage);
+ closedir(d);
+ }
+}
+
+unsigned long num_loose_objects(void)
+{
+ unsigned long loose = 0, packed_loose = 0, garbage = 0, loose_size = 0;
+ count_loose_objects(0, &loose, &loose_size, &packed_loose, &garbage);
+ return loose;
+}
+
+int cmd_count_objects(int ac, const char **av, const char *prefix)
+{
+ int i, verbose = 0;
unsigned long loose = 0, packed = 0, packed_loose = 0, garbage = 0;
unsigned long loose_size = 0;
@@ -90,19 +117,8 @@ int cmd_count_objects(int ac, const char **av, const char *prefix)
/* we do not take arguments other than flags for now */
if (i < ac)
usage(count_objects_usage);
- memcpy(path, objdir, len);
- if (len && objdir[len-1] != '/')
- path[len++] = '/';
- for (i = 0; i < 256; i++) {
- DIR *d;
- sprintf(path + len, "%02x", i);
- d = opendir(path);
- if (!d)
- continue;
- count_objects(d, path, len, verbose,
- &loose, &loose_size, &packed_loose, &garbage);
- closedir(d);
- }
+
+ count_loose_objects(verbose, &loose, &loose_size, &packed_loose, &garbage);
if (verbose) {
struct packed_git *p;
unsigned long num_pack = 0;
diff --git a/builtin-gc.c b/builtin-gc.c
index 3b1f8c2..b9b3c05 100644
--- a/builtin-gc.c
+++ b/builtin-gc.c
@@ -40,7 +40,7 @@ static int gc_config(const char *var, const char *value)
int cmd_gc(int argc, const char **argv, const char *prefix)
{
int i;
- int prune = 0;
+ int prune = 0, do_repack = 0;
git_config(gc_config);
@@ -65,7 +65,20 @@ int cmd_gc(int argc, const char **argv, const char *prefix)
if (run_command_v_opt(argv_reflog, RUN_GIT_CMD))
return error(FAILED_RUN, argv_reflog[0]);
- if (run_command_v_opt(argv_repack, RUN_GIT_CMD))
+ if (num_loose_objects() > 0) {
+ do_repack = 1;
+ } else {
+ struct packed_git *p;
+ unsigned long num_pack = 0;
+ if (!packed_git)
+ prepare_packed_git();
+ for (p = packed_git; p; p = p->next)
+ if (p->pack_local)
+ num_pack++;
+ if (num_pack > 1)
+ do_repack = 1;
+ }
+ if (do_repack && run_command_v_opt(argv_repack, RUN_GIT_CMD))
return error(FAILED_RUN, argv_repack[0]);
if (prune && run_command_v_opt(argv_prune, RUN_GIT_CMD))
diff --git a/cache.h b/cache.h
index 8e76152..3a140f1 100644
--- a/cache.h
+++ b/cache.h
@@ -359,6 +359,8 @@ extern int legacy_loose_object(unsigned char *);
extern int has_pack_file(const unsigned char *sha1);
extern int has_pack_index(const unsigned char *sha1);
+extern unsigned long num_loose_objects(void);
+
extern signed char hexval_table[256];
static inline unsigned int hexval(unsigned int c)
{
^ permalink raw reply related
* Re: gitk and git-gui, was Re: FFmpeg considering GIT
From: Linus Torvalds @ 2007-05-08 15:33 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Shawn O. Pearce, Paul Mackerras, Brett Schwarz, Karl Hasselstr?m,
Junio C Hamano, Carl Worth, Michael Niedermayer, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0705081311550.4167@racer.site>
On Tue, 8 May 2007, Johannes Schindelin wrote:
>
> It might be a much better idea to write something a la git-fetch--tool,
> which is a helper in C (thus very fast and memory efficient), outputting
> easily parseable data.
Well, we actually do have that. "git log" (or "git-rev-list") really does
all the heavy lifting. The reason you can do things like "gitk --merge" is
not because gitk itself has _any_ idea about anything, but because it just
passes the arguments down to git-rev-list (and hopefully soon git log),
which really does all the complex stuff.
But gitk still ends up having a big memory footpring, simply because if
you get the data for a few hundred thousand commits (with commit messages
etc), and have to keep track of the relationships between them, you are
going to easily use hundreds of megs of memory.
Linus
^ permalink raw reply
* Re: [PATCH] Add pack.depth option to git-pack-objects and change default depth to 50
From: Nicolas Pitre @ 2007-05-08 15:38 UTC (permalink / raw)
To: Theodore Ts'o; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <11786309072612-git-send-email-tytso@mit.edu>
On Tue, 8 May 2007, Theodore Ts'o wrote:
> Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
I'd prefer if tests were performed on the performance impact before
changing the default depth. If done separately from this patch then the
commit log could contain those results as well.
Nicolas
^ permalink raw reply
* Re: git pull failure, truncated object
From: Nicolas Pitre @ 2007-05-08 15:41 UTC (permalink / raw)
To: Bill Lear; +Cc: git
In-Reply-To: <17984.35097.568689.482933@lisa.zopyra.com>
On Tue, 8 May 2007, Bill Lear wrote:
> He did a git-gc, twice, and retried. Still failed.
>
> So, he called me in and we tried to see if the server was acting up
> --- perhaps an NFS problem, as we've had those before, but got very
> different error messages. Watched the log file from git-daemon, and
> saw nothing. Finally we took a look at the local repos
> .git/objects/4b, and 4b93eb81265ea4f2b436618a4b1c3bea2bedf06d was of
> length 0.
>
> So, I looked in the man page of git-gc and thought to try --prune,
> as this was not an active repository. This worked, and then
> the pull did as well.
>
> I'm wondering why git-gc did not at least warn us of this problem when
> we tried it. It appeared to us that git-gc gave our repo a clean bill
> of health, and so we turned our attention to the remote and
> investigated there, instead of continuing in the local repo.
git-gc != git-fsck.
Nicolas
^ permalink raw reply
* Re: [PATCH] Add --no-reuse-delta option to git-gc
From: Nicolas Pitre @ 2007-05-08 15:35 UTC (permalink / raw)
To: Theodore Ts'o; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <11786309071033-git-send-email-tytso@mit.edu>
On Tue, 8 May 2007, Theodore Ts'o wrote:
> This allows the user to regenerate the deltas in packs while doing
> a git-gc. The user could just run git-repack -a -d -f -l after
> running git-gc, but then the first git-repack run by git-gc is
> a bit of waste.
Given the patch I just posted and my previous arguments I don't think
this patch is in the spirit of git-gc. I'd prefer if git-gc remained as
simple with the least options as possible, but I don't care that much
either.
Nicolas
^ permalink raw reply
* Re: git-svn: importing branches later
From: Michael Hendricks @ 2007-05-08 15:34 UTC (permalink / raw)
To: git
In-Reply-To: <m2odkv2wtd.fsf@ziti.local>
On Tue, May 08, 2007 at 07:51:10AM -0700, Seth Falcon wrote:
> Karl Hasselström <kha@treskal.com> writes:
>
> > On 2007-05-07 13:07:06 -0600, Michael Hendricks wrote:
> >
> >> Now I want to import the 'foo' branch from the same SVN repo without
> >> grabbing all the branches. Any suggestions?
> >
> > I seem to recall that just adding another "fetch" line to the git-svn
> > configuration in .git/config will do this for you.
>
> Yes, this should work. As long as you started out with a fairly
> recent git (sorry, I don't know how recent is needed) you should have
> in your repository a git/config file containing something like:
>
> [svn-remote "svn"]
> url = http://main.svn.url.com/
> fetch = trunk:refs/remotes/git-svn
> fetch = branches/b1:refs/remotes/b1 <-- this line added by you
Thanks Seth and Karl, that does indeed work.
I noticed that after changing .git/config and running fetch, git-svn
retrieves the log for the entire project (presumably because it doesn't
know when the new branch was created). In one project with ~30,000
revisions, I found it beneficial to specify "git svn fetch -r
12345:HEAD" where revision 12345 is somewhere close to and before the
point at which the new branch was created from trunk. That makes the
initial fetch must faster.
--
Michael
^ permalink raw reply
* Re: git pull failure, truncated object
From: Bill Lear @ 2007-05-08 15:46 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
In-Reply-To: <alpine.LFD.0.99.0705081140000.24220@xanadu.home>
On Tuesday, May 8, 2007 at 11:41:14 (-0400) Nicolas Pitre writes:
>On Tue, 8 May 2007, Bill Lear wrote:
>
>> He did a git-gc, twice, and retried. Still failed.
>>
>> So, he called me in and we tried to see if the server was acting up
>> --- perhaps an NFS problem, as we've had those before, but got very
>> different error messages. Watched the log file from git-daemon, and
>> saw nothing. Finally we took a look at the local repos
>> .git/objects/4b, and 4b93eb81265ea4f2b436618a4b1c3bea2bedf06d was of
>> length 0.
>>
>> So, I looked in the man page of git-gc and thought to try --prune,
>> as this was not an active repository. This worked, and then
>> the pull did as well.
>>
>> I'm wondering why git-gc did not at least warn us of this problem when
>> we tried it. It appeared to us that git-gc gave our repo a clean bill
>> of health, and so we turned our attention to the remote and
>> investigated there, instead of continuing in the local repo.
>
>git-gc != git-fsck.
Indeed, as is now clear to me. Would it be prudent to have git-gc
run a quick git-fsck internally and warn if things are not in a kosher
state?
Bill
^ permalink raw reply
* [PATCH] Add howto files to rpm packages.
From: Quy Tonthat @ 2007-05-08 14:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
RPM packages did not include howto files which causes broken
links in howto-index.html
Signed-off-by: Quy Tonthat <qtonthat@gmail.com>
---
diff --git a/git.spec.in b/git.spec.in
index 556bdda..9de655c 100644
--- a/git.spec.in
+++ b/git.spec.in
@@ -183,9 +183,12 @@ rm -rf $RPM_BUILD_ROOT
%defattr(-,root,root)
%{_datadir}/git-core/
%doc README COPYING Documentation/*.txt
-%{!?_without_docs: %doc Documentation/*.html }
+%{!?_without_docs: %doc Documentation/*.html Documentation/howto}
%changelog
+* Tue May 8 2007 Quy Tonthat <qtonthat@gmail.com>
+- Added howto files
+
* Tue Mar 27 2007 Eygene Ryabinkin <rea-git@codelabs.ru>
- Added the git-p4 package: Perforce import stuff.
^ permalink raw reply related
* Re: FFmpeg considering GIT
From: Gábor Farkas @ 2007-05-08 15:53 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy
Cc: Jan Hudec, Paul Mackerras, Linus Torvalds, Karl Hasselstr?m,
Junio C Hamano, Carl Worth, Michael Niedermayer, Git Mailing List
In-Reply-To: <fcaeb9bf0705080707x7ad28afelf98ecd93276042d1@mail.gmail.com>
Nguyen Thai Ngoc Duy wrote:
> On 5/7/07, Gábor Farkas <gabor@nekomancer.net> wrote:
>> >> MacOS AFAIK.
>>
>> GTK does not work natively on OSX (it only works using the X11 server ).
>> QT works fine.
>>
>> gabor
>
> Recent GTK+ can work on OSX without X11:
> http://developer.imendio.com/projects/gtk-macosx
>
i know about that project, but it does not seem to be finished yet.
for example, in
http://developer.imendio.com/projects/gtk-macosx/build-instructions
they write:
NOTE: This is mainly meant for developers wanting to help out with GTK+
Mac OS X, not for users. The port is not yet finished or usable for
mainstream use.
gabor
^ permalink raw reply
* Re: [PATCH] Add pack.depth option to git-pack-objects and change default depth to 50
From: Theodore Tso @ 2007-05-08 16:30 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <alpine.LFD.0.99.0705081136050.24220@xanadu.home>
On Tue, May 08, 2007 at 11:38:46AM -0400, Nicolas Pitre wrote:
> On Tue, 8 May 2007, Theodore Ts'o wrote:
>
> > Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
>
> I'd prefer if tests were performed on the performance impact before
> changing the default depth. If done separately from this patch then the
> commit log could contain those results as well.
The following results are on a recent git repository, using time to
record the real, user, and sys times on the two commands: "git-gc
--no-reuse-delta --window=X --depth=Y" and "git log --pretty=oneline
-S'object' > /dev/null". All of these tests were done with a hot
cache, so disk speed didn't enter into the calculations.
git-gc git log -S'object' pack size
w=10,d=10 27.1s/25.2s/0.3s 20.8s/20.4s/0.1s 15292k
w=10,d=30 23.8s/22.3s/0.2s 21.2s/20.9s/0.1s 12996k
w=10,d=50 24.8s/22.4s/0.4s 21.8s/21.2s/0.1s 12340k
w=100,d=100 24.1s/22.8s/0.3s 22.4s/21.8s/0.2s 11772k
w=30,d=10 45.0s/43.1s/0.4s 20.8s/20.5s/0.1s 14388k
w=30,d=30 35.8s/34.1s/0.3s 21.6s/21.1s/0.1s 11800k
w=30,d=50 34.6s/33.0s/0.3s 22.1s/21.4s/0.1s 11376k
w=30,d=100 34.0s/32.2s/0.3s 22.2s/21.6s/0.1s 11012k
w=50,d=10 56.1s/54.3s/0.4s 21.3s/20.5s/0.1s 14224k
w=50,d=30 47.2s/45.4s/0.4s 21.6s/21.0s/0.1s 11496k
w=50,d=50 44.5s/43.0s/0.3s 21.7s/21.2s/0.1s 11108k
w=50,d=100 44.3s/42.7s/0.4s 22.4s/21.7s/0.1s 10824k
So a couple of things immediately become evident. First of all, as
Junio predicted, changing --depth makes no difference to the git-gc or
git log times. The latter is thanks to the delta chaching. Secondly,
changing --depth does make a signficiant difference to the pack size.
Finally, --window does help somewhat in reducing the pack size, but it
_significantly_ increases the time to calculate the pack.
My conclusion given this quick benchmark is that it seems to me that
changing the defaults of --depth to 50, and keeping --window at 10, is
a reasonable thing to do.
Regards,
- Ted
^ 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