* Re: [PATCH] fmt-patch: understand old <his> notation
From: Olivier Galibert @ 2006-05-06 23:19 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Johannes Schindelin, git
In-Reply-To: <Pine.LNX.4.64.0605061527030.16343@g5.osdl.org>
On Sat, May 06, 2006 at 03:30:38PM -0700, Linus Torvalds wrote:
> Maybe not. I've actually cursed the fact that I made "git diff X" mean
> "diff from X to current working tree", because it almost never makes any
> sense at all when X is anything but "HEAD".
>
> I probably _should_ have made "git diff X" mean basically "git show X",
> and not what it means now.
Funny, when tracking other projects I use (sometimes path-filtered)
"git diff origin" often, but I find "git show origin" utterly
uninteresting.
OG.
^ permalink raw reply
* [PATCH] config: if mtime (or size) of the config file changed since last read, reread it
From: Johannes Schindelin @ 2006-05-06 23:26 UTC (permalink / raw)
To: git
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
This is extremely paranoic, I know.
config.c | 16 ++++++++++------
1 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/config.c b/config.c
index 05d4d8c..6765186 100644
--- a/config.c
+++ b/config.c
@@ -13,6 +13,7 @@ #define MAXNAME (256)
static const char *contents = NULL;
static int config_length = 0, config_offset = 0;
static const char *config_file_name;
+static time_t config_file_mtime = 0;
static int config_linenr;
static int get_next_char(void)
{
@@ -255,23 +256,26 @@ int git_default_config(const char *var,
int git_config_from_file(config_fn_t fn, const char *filename)
{
int ret, in_fd;
+ struct stat st;
config_offset = 0;
+ in_fd = open(filename, O_RDONLY);
+ fstat(in_fd, &st);
+
if (contents) {
- if (!strcmp(config_file_name, filename))
+ if (!strcmp(config_file_name, filename)
+ && config_file_mtime == st.st_mtime
+ && config_length == st.st_size) {
+ close(in_fd);
return git_parse_file(fn);
+ }
munmap((char*)contents, config_length);
free((char*)config_file_name);
}
- in_fd = open(filename, O_RDONLY);
-
ret = -1;
if (in_fd > 0) {
- struct stat st;
-
- fstat(in_fd, &st);
config_length = st.st_size;
contents = mmap(NULL, config_length, PROT_READ, MAP_PRIVATE,
in_fd, 0);
--
1.3.1.g5545a
^ permalink raw reply related
* Re: [PATCH] config: if mtime (or size) of the config file changed since last read, reread it
From: Johannes Schindelin @ 2006-05-06 23:45 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.63.0605070125010.6597@wbgn013.biozentrum.uni-wuerzburg.de>
Hi,
sorry: bad patch. This is needed on top.
diff --git a/config.c b/config.c
index 6765186..452b587 100644
--- a/config.c
+++ b/config.c
@@ -261,6 +261,10 @@ int git_config_from_file(config_fn_t fn,
config_offset = 0;
in_fd = open(filename, O_RDONLY);
+ if (in_fd < 0 && ENOENT != errno )
+ die("opening %s: %s", config_file_name,
+ strerror(errno));
+
fstat(in_fd, &st);
if (contents) {
@@ -288,9 +292,6 @@ int git_config_from_file(config_fn_t fn,
} else {
contents = NULL;
config_length = 0;
- if (in_fd < 0 && ENOENT != errno )
- die("opening %s: %s", config_file_name,
- strerror(errno));
}
return ret;
^ permalink raw reply related
* Re: Unresolved issues #2
From: Jakub Narebski @ 2006-05-07 0:41 UTC (permalink / raw)
To: git
In-Reply-To: <7vvesirh0q.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> It might make sense to rewrite it to parse and read the existing
> configuration as a whole, do necessary manupulations on the
> parsed internal representation in-core, and write the result out
> from scratch.
Or perhaps do git repo-config read and change config file in two passes:
read and build some kind of index (beginning of section, end of
section/last variable in section, number of elements in section), then in
second pass add some information if needed.
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: [PATCH] fmt-patch: understand old <his> notation
From: Junio C Hamano @ 2006-05-07 1:28 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0605062358280.6357@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> No, it is not too late. I did this patch only to prevent cluttering my
> directory with millions of patches, only because I forgot _again_ to type
> the two dots.
I did that as well, and the thing is, this is _so_ fast that
when I noticed and typed ^C, it already has done 400 or so
commits starting from the epoch (which was empty by the way).
I am already working on adjusting in-tree format-patch users not
to use <his> syntax but to use <his>.. syntax, so this should not
be a problem either way.
>> Also we probably would want to default the diff options to show
>> the root commit diff (rev.show_root_diff).
> I gather this is needed for git-am/git-rebase to continue working?
No, but people want to export the whole history sometimes.
^ permalink raw reply
* Re: [PATCH] fmt-patch: understand old <his> notation
From: Junio C Hamano @ 2006-05-07 1:31 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0605061527030.16343@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> Maybe not. I've actually cursed the fact that I made "git diff X" mean
> "diff from X to current working tree", because it almost never makes any
> sense at all when X is anything but "HEAD".
Actually, I do "git diff next" all the time while on the tip of
my topic branches, and also when merging a topic branch into
"master". This "a different tree with the current working
files" is probably the second most frequently used form for me
(the first one is of course HEAD vs working files).
^ permalink raw reply
* Re: [RFC] Managing projects - advanced Git tutorial/walkthrough
From: J. Bruce Fields @ 2006-05-07 1:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jakub Narebski, git
In-Reply-To: <7v64kisyow.fsf@assigned-by-dhcp.cox.net>
On Sat, May 06, 2006 at 01:09:03PM -0700, Junio C Hamano wrote:
> - Understanding git as an end user. Currently, this is
> included in the global map git(7) documentation. It might
> make sense to separate it out. This should talk about
> concepts like blobs/trees/commits/trust/index without going
> into lowlevel details of the implementation. The stress
> should be on what they are for, not operationally but
> philosophically. What's currently in README would be
> suitable for this part, with some additional topics:
Yeah, I actually made a start at a sequel to tutorial.txt, with the goal
that after reading the sequel a user would have encountered the main
concepts necessary to read any of the man pages--mainly the object
database and the index file. My work so far is in the
"advanced-tutorial" branch of
git://linux-nfs.org/~bfields/exports/git.git
but it needs some cleaning up.
I was hoping I'd be able to replace some of the README or
core-tutorial.txt in the process, but the latter has a lot of
git-hacker-only detail in it, and the former is a bit more verbose and
has some motivation (explaining why stuff was designed the way it was)
that is nice but maybe not necessary for a minimal tutorial.
--b.
^ permalink raw reply
* Locking a branch
From: Pavel Roskin @ 2006-05-07 2:50 UTC (permalink / raw)
To: git
Hello!
I see there is an active discussion about branch attributes. It would
be nice to have an attribute to prevent git from changing the branch
head in any way. The reason is that it interferes with StGIT on StGIT
managed branches. If StGIT is fine with the change, it would remove or
override the lock temporarily. StGIT could also unlock the branch
permanently if there are no applied patches.
Another use of the branch lock would be to prevent damage to remote
branches, such as "origin". Committing anything to "origin" would break
fetching. In this case, git-fetch should be allowed to override the
lock after checking .git/remotes, but other git commands should respect
the lock.
It should be possible to break locks, but the users would at least think
before doing so.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: [RFC] get_pathspec(): free() old buffer if rewriting
From: Junio C Hamano @ 2006-05-07 4:26 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0605061532190.16343@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Sun, 7 May 2006, Johannes Schindelin wrote:
>>
>> This might be the wrong way to do it, but as it is without this patch,
>> get_pathspec() is leaking memory.
>
> I'm not at all convinced we want to do somethng like this.
>
> get_pathspec() is a one-time event. It doesn't "leak" memory. To me,
> "leaking" is when you continually lose a bit of memory, and you eventually
> run out. I don't see that happening here.
I agree with that, except that blame does use it for each
commit and loses memory with deep history.
I have been contemplating to revamp pathspec stuff to deal with
not just an array pointers to strings. tree-diff already uses a
parallel array of ints (pathlens) to optimize away the repeated
use of strlen() for each pathspec elements, and I think we would
be better off using something like that everywhere. The API I
have in mind goes like this:
struct pathspec; /* opaque */
A type opaque to the caller.
struct pathspec **get_pathspec(const char *prefix,
const char **pathspec,
int wildcard);
The caller gives the prefix (return value from
setup_git_directory(), the user supplied pathspec list,
and if it wants to use ls-files style wildcard or
tree-diff style directory prefix bahaviour. A newly
allocated array is returned and the caller can free() it
when done.
int match_pathspec(const char *path, int len,
struct pathspec **pathspec);
See if the path (with length) matches the given spec.
path[len-1] == '/' signals that the caller is traversing
a tree and checking if it is worth descending into the
tree. In that case, original spec string "foo/bar/baz"
matches path = "foo/" (with len = 4). Otherwise the full
path is checked so that original spec string would match
path = "foo/bar/baz" (with len = 11), but not "foo"
(with len = 3). If the get_pathspec() was called with
wildcard support, spec string "foo/bar*" matches these:
"foo/" (i.e. should descend into it),
"foo/barboz/" (ditto)
"foo/bar.txt" (matches)
but not these:
"fob/" (no point descending into it)
"foo/bax" (does not match)
A wildcard aware diff-tree, when invoked like this:
cd Documentation
git-diff-tree -r A B -- 'ho*'
might do:
struct pathspec **spec;
const char *(paths[2]);
paths[0] = "how*"; paths[1] = NULL;
spec = get_pathspec("Documentation/", argv, 1);
and when traversing the tree for A and B, upon seeing "Documentation"
entry in the topleve tree object buffers, call:
path_match("Documentation", 14, 1, spec)
which would return true (worth descending into the directory).
The recursive call would, upon seeing "hooks.txt" entry, call:
path_match("Documentation/hooks.txt", 23, 0, spec)
which would say true and compares the entry from two trees.
Also, the same recursive invocation would call
path_match("Documentation/howto", 19, 1, spec)
which would return true to cause it further recurse into it.
^ permalink raw reply
* Re: [RFC] get_pathspec(): free() old buffer if rewriting
From: Junio C Hamano @ 2006-05-07 4:50 UTC (permalink / raw)
To: git
In-Reply-To: <7viroipijf.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> int match_pathspec(const char *path, int len,
> struct pathspec **pathspec);
>
> See if the path (with length) matches the given spec.
> path[len-1] == '/' signals that the caller is traversing
> a tree and checking if it is worth descending into the
> tree.
> ...
> and when traversing the tree for A and B, upon seeing "Documentation"
> entry in the topleve tree object buffers, call:
>
> path_match("Documentation", 14, 1, spec)
Oops, match_pathspec("Documentation/", 15, spec) is what I meant
here. Likewise in the later examples.
^ permalink raw reply
* Re: Unresolved issues #2 (shallow clone again)
From: Martin Langhoff @ 2006-05-07 6:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vbqubvdbr.fsf@assigned-by-dhcp.cox.net>
On 5/6/06, Junio C Hamano <junkio@cox.net> wrote:
> "Martin Langhoff" <martin.langhoff@gmail.com> writes:
> >
> > It means that for a merge or checkout involving stuff we "don't have",
> > it's trivial to know we are missing, and so we can attempt a fetch of
> > the missing objects or tell the user how to request them them before
> > retrying.
> >
> > And in any case commits and trees are lightweight and compress well...
>
> Commit maybe, but is this based on a hard fact?
No hard facts here :( but I think it's reasonable to assume that the
trees delta/compress reasonably well, as a given commit will change
just a few entries in each tree.
I might try and hack a shallow local clone of the kernel and pack it
tightly to see what it yields.
cheers,
martin
^ permalink raw reply
* Re: [PATCH] config: if mtime (or size) of the config file changed since last read, reread it
From: Jan-Benedict Glaw @ 2006-05-07 7:30 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0605070144530.7578@wbgn013.biozentrum.uni-wuerzburg.de>
[-- Attachment #1: Type: text/plain, Size: 820 bytes --]
On Sun, 2006-05-07 01:45:22 +0200, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> diff --git a/config.c b/config.c
> index 6765186..452b587 100644
> --- a/config.c
> +++ b/config.c
> @@ -261,6 +261,10 @@ int git_config_from_file(config_fn_t fn,
> config_offset = 0;
>
> in_fd = open(filename, O_RDONLY);
> + if (in_fd < 0 && ENOENT != errno )
I admit that I don't like the (constant -operator- variable) notation,
but mixing both in one line..?
MfG, JBG
--
Jan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481 _ O _
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg _ _ O
für einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Unresolved issues #2 (shallow clone again)
From: Jeff King @ 2006-05-07 7:56 UTC (permalink / raw)
To: git
In-Reply-To: <46a038f90605062308x53995076k7bf45f0aebcae0c6@mail.gmail.com>
On Sun, May 07, 2006 at 06:08:03PM +1200, Martin Langhoff wrote:
> >> And in any case commits and trees are lightweight and compress well...
> >Commit maybe, but is this based on a hard fact?
> No hard facts here :( but I think it's reasonable to assume that the
> trees delta/compress reasonably well, as a given commit will change
> just a few entries in each tree.
A few hard facts (using Linus' linux-2.6 tree):
- original packsize: 120996 kilobytes
- unpacked: 233338 objects, 1417476 kilobytes
This is an 11.7:1 compression ratio (of course, much of this is
wasted space from the 4k block size in the filesystem)
- There were 87915 total blob objects, of which 19321 were in the
current tree. I removed all non-current blobs to produce a "shallow"
tree.
- The shallow tree unpacked: 164744 objects, 761960 kilobytes
IOW, about half of the unpacked disk usage was old blobs.
- Shallow commit/tree/tag objects packed (using 1.3.1
git-pack-objects):
Total 164744, written 164744 (delta 92322), reused 0 (delta 0)
size: 108088
The compression ratio here is only 7.0:1
- Total savings by going shallow: 10.7%
So basically, trees and commits DON'T compress as well as historical
blobs (potentially because git-pack-objects isn't currently optimized
for this -- I haven't checked). As a result, we're saving only 10% by
going shallow instead of a potential 50%.
-Peff
^ permalink raw reply
* Re: Unresolved issues #2 (shallow clone again)
From: Sergey Vlasov @ 2006-05-07 8:01 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Junio C Hamano, git
In-Reply-To: <46a038f90605062308x53995076k7bf45f0aebcae0c6@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1915 bytes --]
On Sun, 7 May 2006 18:08:03 +1200 Martin Langhoff wrote:
> On 5/6/06, Junio C Hamano <junkio@cox.net> wrote:
> > "Martin Langhoff" <martin.langhoff@gmail.com> writes:
> > >
> > > It means that for a merge or checkout involving stuff we "don't have",
> > > it's trivial to know we are missing, and so we can attempt a fetch of
> > > the missing objects or tell the user how to request them them before
> > > retrying.
> > >
> > > And in any case commits and trees are lightweight and compress well...
> >
> > Commit maybe, but is this based on a hard fact?
>
> No hard facts here :( but I think it's reasonable to assume that the
> trees delta/compress reasonably well, as a given commit will change
> just a few entries in each tree.
>
> I might try and hack a shallow local clone of the kernel and pack it
> tightly to see what it yields.
For linux v2.6.16:
7,3M commits-b41b04a36afebdba3b70b74f419fc7d97249bd7f.pack
24M commits_trees-8397f1c2a885527acd07e2caa8c95df626451493.pack
97M full-c7b2747a674ff55cb4a59dabebe419f191e360df.pack
For comparizon, a single version in packed form:
51M v2.6.12-rc2-4f3526b6815eb63da6c43ed85be1494bb776e2c5.pack
Made with
git-rev-list v2.6.16 | git-pack-objects commits
git-rev-list --objects --no-blobs v2.6.16 | git-pack-objects commits_trees
git-rev-list --objects v2.6.16 | git-pack-objects full
and this hack to git-rev-list:
diff --git a/revision.c b/revision.c
index f2a9f25..b5a929e 100644
--- a/revision.c
+++ b/revision.c
@@ -636,6 +636,10 @@ int setup_revisions(int argc, const char
revs->blob_objects = 1;
continue;
}
+ if (!strcmp(arg, "--no-blobs")) {
+ revs->blob_objects = 0;
+ continue;
+ }
if (!strcmp(arg, "--objects-edge")) {
revs->tag_objects = 1;
revs->tree_objects = 1;
So trees are definitely not lightweight, and commits are rather large
too.
[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]
^ permalink raw reply related
* Re: [PATCH] config: if mtime (or size) of the config file changed since last read, reread it
From: Junio C Hamano @ 2006-05-07 8:42 UTC (permalink / raw)
To: Jan-Benedict Glaw; +Cc: git
In-Reply-To: <20060507073052.GC17031@lug-owl.de>
Jan-Benedict Glaw <jbglaw@lug-owl.de> writes:
>> + if (in_fd < 0 && ENOENT != errno )
>
> I admit that I don't like the (constant -operator- variable) notation,
> but mixing both in one line..?
Lol.
I would have written it as (in_fd < 0 && errno != ENOENT) BTW.
^ permalink raw reply
* Re: Unresolved issues #2
From: Junio C Hamano @ 2006-05-07 9:39 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0605062332420.6423@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> It was done because the very syntax of the config suggests it be a
> user-editable file. I do not want to mess with the comments more than
> necessary.
I personally feel that is a lost cause _unless_ you come up with
a reasonable convention for where to put comments, stress that
rule to the user in the documentation, _and_ make repo-config to
follow that rule as well.
We _do_ want to treat config file as hand editable and cat
reviewable file, not an unreadable gunk like xml, so trying to
preserve user comments is important and I am not opposed to that
you did (at least some of) it. But as the code currently
stands, what it does is at best half baked, at worst somewhat
confusing.
A demonstration. What is wrong with this picture?
$ cat .git/config
[core]
repositoryformatversion = 0
; are the mode bits trustworthy?
filemode = true ; yes, on ext3
; We want symlinked HEAD because we will bisect
; recent kernel history.
prefersymlinkrefs = true
$ git repo-config core.prefersymlinkrefs false
$ git repo-config core.filemode false
$ cat .git/config
[core]
repositoryformatversion = 0
; are the mode bits trustworthy?
filemode = false
; We want symlinked HEAD because we will bisect
; recent kernel history.
prefersymlinkrefs = false
$ exit
The comment given to "filemode" is "reasonable" in that it
describes what the value that is set to the variable does, and
losing the original comment given to its "true" when we set it
to false is better than keeping it, so that part happens to be
doing the right thing -- only because I knew what repo-config
would do to the comments and arranged original comments in the
file that way.
But what about prefersymlinkrefs one? When setting the variable
to such a non-standard value, it is unreasonable for people to
want to justify why with a comment like the above. But after
resetting the value the comment becomes stale.
It gets worse:
$ git repo-config --unset core.filemode
$ cat .git/config
[core]
repositoryformatversion = 0
; please please use symlinks please
prefersymlinkrefs = false
; are the mode bits trustworthy?
$ exit
There now is a confusing trailing comment left that does not
comment anything. Removing core.filemode is not so common, but
this can happen whenever you remove any variable, so we can use
any other variable as an example.
Now, enough being negative and pointing out problems. Time to
become constructive. Probably a reasonable convention would be
to define the config file format to be something like this:
<comment that applies to the section>
[section]
<comment that applies to the variable stands on
its own before the variable>
variable [= value] <comment that applies to the
fact the variable is set to
this particular value starts
on the same line as the
"variable = value" thing>
- when a variable is reset to another value, remove the
"value comment";
- when a variable disappears, remove "variable comment";
- when a section disappears, remove "section comment";
- otherwise leave the comment intact.
Then we could tell the user the rule is like above, and tell
them to structure the file with comments that way, if they ever
want to edit the file by hand.
Now if we wanted to do something like the above, I suspect that
it would be easier and less error prone to first scan the config
file, note what appears where, and do the processing in-core,
and then write the results out, perhaps using data structures
like these:
struct config_section {
char *pre_comment;
char *name; /* e.g. "core" */
struct config_section *next; /* next section */
struct config_var *vars; /* pointer to the first one */
};
struct config_var {
char *pre_comment;
char *name;
char *value; /* "existence" bool may have NULL,
* otherwise probably a string "= value"
*/
char *value_comment;
struct config_var *next; /* pointer to the next one
* in the section
*/
};
Obviously, data structures like these would make it even easier
if we decide we do _not_ care about comments (we would just lose
x_comment fields, parse the thing and write the resulting list
out).
^ permalink raw reply
* Re: Unresolved issues #2
From: Junio C Hamano @ 2006-05-07 9:42 UTC (permalink / raw)
To: git
In-Reply-To: <7vy7xekwbs.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> But what about prefersymlinkrefs one? When setting the variable
> to such a non-standard value, it is unreasonable for people to
> want to justify why with a comment like the above.
Obviously I was not reading what I was typing. It is very
reasonable for people to want to do that. Sorry.
^ permalink raw reply
* Re: Unresolved issues #2
From: Johannes Schindelin @ 2006-05-07 11:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vy7xekwbs.fsf@assigned-by-dhcp.cox.net>
Hi,
On Sun, 7 May 2006, Junio C Hamano wrote:
> [...] Probably a reasonable convention would be to define the config
> file format to be something like this:
>
> <comment that applies to the section>
> [section]
> <comment that applies to the variable stands on
> its own before the variable>
> variable [= value] <comment that applies to the
> fact the variable is set to
> this particular value starts
> on the same line as the
> "variable = value" thing>
>
> - when a variable is reset to another value, remove the
> "value comment";
> - when a variable disappears, remove "variable comment";
> - when a section disappears, remove "section comment";
> - otherwise leave the comment intact.
>
> Then we could tell the user the rule is like above, and tell
> them to structure the file with comments that way, if they ever
> want to edit the file by hand.
>
> Now if we wanted to do something like the above, I suspect that
> it would be easier and less error prone to first scan the config
> file, note what appears where, and do the processing in-core,
> and then write the results out, perhaps using data structures
> like these:
>
> struct config_section {
> char *pre_comment;
> char *name; /* e.g. "core" */
> struct config_section *next; /* next section */
> struct config_var *vars; /* pointer to the first one */
> };
> struct config_var {
> char *pre_comment;
> char *name;
> char *value; /* "existence" bool may have NULL,
> * otherwise probably a string "= value"
> */
> char *value_comment;
> struct config_var *next; /* pointer to the next one
> * in the section
> */
> };
>
> Obviously, data structures like these would make it even easier
> if we decide we do _not_ care about comments (we would just lose
> x_comment fields, parse the thing and write the resulting list
> out).
Sounds very reasonable.
Ciao,
Dscho
^ permalink raw reply
* Re: Unresolved issues #2
From: Jakub Narebski @ 2006-05-07 11:38 UTC (permalink / raw)
To: git
In-Reply-To: <7vy7xekwbs.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> char *value; /* "existence" bool may have NULL,
> * otherwise probably a string "= value"
> */
Probably " = value" to preserve whitespace (e.g. justify on equal sign in
hand crafted config file).
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: [PATCH] config: mmap() the contents of the config file
From: Johannes Schindelin @ 2006-05-07 11:40 UTC (permalink / raw)
To: git, junkio
In-Reply-To: <Pine.LNX.4.63.0605070103270.26358@wbgn013.biozentrum.uni-wuerzburg.de>
Hi,
On Sun, 7 May 2006, Johannes Schindelin wrote:
> This makes it possible to rewrite the config without accessing the config
> file twice.
Since commit c2b9e699, this is needed, too:
diff --git a/config.c b/config.c
index 59006fa..30effe3 100644
--- a/config.c
+++ b/config.c
@@ -362,7 +362,7 @@ static int store_aux(const char* key, co
} else if (strrchr(key, '.') - key == store.baselen &&
!strncmp(key, store.key, store.baselen)) {
store.state = SECTION_SEEN;
- store.offset[store.seen] = ftell(config_file);
+ store.offset[store.seen] = config_offset;
}
}
return 0;
--
1.3.2.g4e38b-dirty
^ permalink raw reply related
* Re: Unresolved issues #2 (shallow clone again)
From: Jakub Narebski @ 2006-05-07 13:30 UTC (permalink / raw)
To: git
In-Reply-To: <7v1wv92u7o.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> The vocabulary we would want from the requestor side is probably
> (at least):
>
> I WANT to have these
> I HAVE these
> I'm MISSING these
> Don't bother with these this time around (--since, ^v2.6.16, ...)
Wouldn't it be easier (sorry, no code yet) to have the following:
I WANT to have these
I HAVE these
These are GRAFT PARENTLESS
with the target side sending list of all parentless commits in the
info/grafts file. The source side will then do the grafting 'in memory' and
send the packs like normal, only with those cauterizing grafts in place.
Now I'm waiting for someone to say that it is too simple and cannot be done,
or that shallow clone/shallow fetch uses this method...
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* [PATCH] Sparse fix for builtin-diff
From: Peter Hagervall @ 2006-05-07 14:50 UTC (permalink / raw)
To: junkio; +Cc: git
You gotta love sparse:
builtin-diff.c:88:4: error: Just how const do you want this type to be?
Signed-off-by: Peter Hagervall <hager@cs.umu.se>
---
builtin-diff.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/builtin-diff.c b/builtin-diff.c
index 636edbf..d3ac581 100644
--- a/builtin-diff.c
+++ b/builtin-diff.c
@@ -84,8 +84,7 @@ static void stuff_change(struct diff_opt
if (opt->reverse_diff) {
unsigned tmp;
- const
- const unsigned char *tmp_u;
+ const unsigned char *tmp_u;
const char *tmp_c;
tmp = old_mode; old_mode = new_mode; new_mode = tmp;
tmp_u = old_sha1; old_sha1 = new_sha1; new_sha1 = tmp_u;
^ permalink raw reply related
* Re: Unresolved issues #2 (shallow clone again)
From: Linus Torvalds @ 2006-05-07 15:27 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20060507075631.GA24423@coredump.intra.peff.net>
On Sun, 7 May 2006, Jeff King wrote:
>
> - Total savings by going shallow: 10.7%
>
> So basically, trees and commits DON'T compress as well as historical
> blobs (potentially because git-pack-objects isn't currently optimized
> for this -- I haven't checked). As a result, we're saving only 10% by
> going shallow instead of a potential 50%.
The biggest size savers from packing is (in rough order of relevance, if
I recall the rough statistics I did):
- avoiding block boundaries.
- delta packing of blobs
- delta packing of trees
- regular compression
The block boundaries are huge, we have tons of small objects, and that was
one of the primary reasons for packing. I'd suspect that this is a 3:1
factor for a lot of things for many "common" filesystem setups. You
probably didn't even account for the size of inodes in your "du" setup.
And blobs with history generally delta very well (_much_ better than
regular compression).
Trees should _delta_ very well, but they basically don't compress,
especially after deltaing. The SHA1's are totally incompressible (in a
tree they aren't even ASCII), and as a deta, the names won't compress much
either because they are short.
Commits are fairly small, shouldn't delta all that much, and they don't
even compress _that_ well either (they're normal text and often have some
redundancy with the committer and author being the same, but they are
short and have some fairly incompressible elements, so..)
The thing with trees in particular is that they are very common for the
kernel (and probably not so much for many other projects). A single commit
ends up quite commonly being just one commit object, one blob (that deltas
really well), and three or four trees. Merges often have no new blobs at
all, just several new trees and the commit object.
So a huge amount of the wins from packing come from the file _history_,
the part that a shallow clone (on purpose) leaves behind.
The regular compression will pick up a fair amount of slack with the
blobs, but it's a much smaller factor than the delta compression for
something that has a long history.
It's somewhat interesting to note that over the year that we've used git,
the kernel pack-size hasn't even increased all that much. I forget exactly
what it was when we started packing, but it was on the order of ~75M. It
is now 115M for me. And the old linux-history thing (full BK history over
three years) is 177M - not much more than twice the size of just a few
kernel versions - with some higher packing ratios..
Exactly because blobs delta so incredibly well.
Linus
^ permalink raw reply
* [PATCH] Fix crash when reading the empty tree
From: Johannes Schindelin @ 2006-05-07 15:42 UTC (permalink / raw)
To: git, junkio
cvsimport needs to call git-read-tree without arguments to create an empty
tree.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
read-tree.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/read-tree.c b/read-tree.c
index 067fb95..a060a97 100644
--- a/read-tree.c
+++ b/read-tree.c
@@ -881,7 +881,7 @@ int main(int argc, char **argv)
* valid cache-tree because the index must match exactly
* what came from the tree.
*/
- if (trees->item && (!merge || (stage == 2))) {
+ if (trees && trees->item && (!merge || (stage == 2))) {
cache_tree_free(&active_cache_tree);
prime_cache_tree();
}
--
1.3.2.g5131-dirty
^ permalink raw reply related
* [PATCH] core-tutorial.txt: escape asterisk
From: Matthias Lederhofer @ 2006-05-07 17:32 UTC (permalink / raw)
To: git
---
I don't now exactly why, but this asterisk has to be escaped to show
up correctly in the html format.
Documentation/core-tutorial.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
7e3a9fbafb8b6aa4ce460221a982feda06549215
diff --git a/Documentation/core-tutorial.txt b/Documentation/core-tutorial.txt
index 4211c81..d1360ec 100644
--- a/Documentation/core-tutorial.txt
+++ b/Documentation/core-tutorial.txt
@@ -971,7 +971,7 @@ environment, is `git show-branch`.
The first two lines indicate that it is showing the two branches
and the first line of the commit log message from their
top-of-the-tree commits, you are currently on `master` branch
-(notice the asterisk `*` character), and the first column for
+(notice the asterisk `\*` character), and the first column for
the later output lines is used to show commits contained in the
`master` branch, and the second column for the `mybranch`
branch. Three commits are shown along with their log messages.
--
1.3.2
^ permalink raw reply related
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