* Re: [PATCH] Documentation: improve description of --glob=pattern and friends
From: Junio C Hamano @ 2010-01-22 0:51 UTC (permalink / raw)
To: Thomas Rast
Cc: git, Michael J Gruber, Ilari Liusvaara, Johannes Sixt,
Junio C Hamano
In-Reply-To: <e2e992cfb93335b400fd9ec67c6d38cb0157b006.1264119524.git.trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
> Consolidate the descriptions of --branches, --tags and --remotes a
> bit, to make it less repetitive. Improve the grammar a bit, and spell
> out the meaning of the 'append /*' rule.
>
> Signed-off-by: Thomas Rast <trast@student.ethz.ch>
> ---
>
> Compared to the earlier draft, I changed "it is anchored" (by
> appending '/*') to "it is turned into a prefix match", since this is
> not anchoring in the ^regex$ sense. (I guess 'leading-component
> match' would be even more accurate, but that makes the sentence
> unwieldy in my ears.)
By the way, we may someday want to change that to do FNM_PATHNAME instead
of just a flat glob.
Incidentally, that is why I prefer the earlier suggestion to do "check
with memcmp() if it is a path-prefix, and if it fails, then give
fnmatch(FNM_PATHNAME) a chance". That way, we don't have to say "by
appending '/*'" (which is an implementation detail we can change).
It seems that the suggestion was ignored, though.
^ permalink raw reply
* Re: Remove diff machinery dependency from read-cache
From: Junio C Hamano @ 2010-01-22 0:45 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Shawn O. Pearce, Git Mailing List
In-Reply-To: <alpine.LFD.2.00.1001211515470.13231@localhost.localdomain>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Thu, 21 Jan 2010, Linus Torvalds wrote:
>>
>> We could fix it a few ways
>>
>> - ignore it. Most git programs will get the pack handling functions
>> anyway, since they want to get object reading.
>
> In fact, we should probably remove git-show-index. It may have some
> historical significance as a pack-file index debugger, but it has no
> actual redeeming features now, considering that the binary is a megabyte
> of useless crud with debugging info.
>
> However, we do actually use it in t/t5302-pack-index.sh. So in the
> meantime, how about this hacky patch to simply just avoid xmalloc, and
> separating out the trivial hex functions into "hex.o".
>
> This results in
>
> [torvalds@nehalem git]$ size git-show-index
> text data bss dec hex filename
> 222818 2276 112688 337782 52776 git-show-index (before)
> 5696 624 1264 7584 1da0 git-show-index (after)
>
> which is a whole lot better, no?
>
> (Or make it a built-in, if we actually think we want to carry it along in
> the long run)
We tend to not remove things unless we are absolutely certain nobody uses
it, so probably making it built-in would be preferrable. I don't think
show-index is used very often if ever, but scripts that use hash-object
would use it really often and would do so via its --stdin interface if it
knows that it is creating more than a dozen objects, so start-up time
required to map the whole git is probably not an issue.
By the way, do you think anybody still uses "git merge-trees"?
^ permalink raw reply
* git-archive ignores export-ignore
From: Todd A. Jacobs @ 2010-01-21 22:13 UTC (permalink / raw)
To: git
Using git 1.6.4.2, the manual page prophesies that:
Files and directories with the attribute export-ignore won't be
added to archive files. See gitattributes(5) for details.
However, various tools seem to be unhappy about this attribute. In
particular, checkout complains about invalid attributes:
$ cat .gitattributes
*.py export-subst
*.html export-subst
juniperxml.cfg export-ignore
$ git checkout juniperxml.cfg
export-ignore is not a valid attribute name: .gitattributes:3
It appears that git-archive doesn't seem to respect the attribute
either. Consider the following example:
cd /tmp
mkdir foo
cd foo
git init
touch foo.sh
echo '*sh' > .gitattributes
git add foo.sh
git add .gitattributes
git commit -m test
git archive HEAD
pax_global_header00006660000000000000000000000064113261226070014512gustar00rootroot0000000000000052 comment=202d78e6a44c7f10bee2ad96a3b2adc80fc33468
.gitattributes000066400000000000000000000000041132612260700137430ustar00rootroot00000000000000*sh
foo.sh000066400000000000000000000000001132612260700121630ustar00rootroot00000000000000
In addition to whatever bugs there might be in reading and applying the
attributes correctly, it would seem that the man page could be a bit
clearer on how and where to apply the attributes.
Assuming PEBKAC for the moment, how can I get the behavior I'm
expecting?
--
"Oh, look: rocks!"
-- Doctor Who, "Destiny of the Daleks"
^ permalink raw reply
* Re: git-merge segfault in 1.6.6 and master
From: Junio C Hamano @ 2010-01-22 0:38 UTC (permalink / raw)
To: git; +Cc: Tim Olsen, Miklos Vajna, Johannes Schindelin
In-Reply-To: <7vhbqfj8fy.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> After I stared at the code for more than two hours, I gave up trying to
> diagnose this by myself. People more familiar with the merge-recursive
> implementation might be able to help figuring this out and may prove my
> suspicion wrong, but I have a feeling that without a fairly big rewrite
> the code is unsalvageable.
In the meantime, I think applying this patch is the right thing to do.
-- >8 --
Subject: merge-recursive: do not return NULL only to cause segfault
merge-recursive calls write_tree_from_memory() to come up with a virtual
tree, with possible conflict markers inside the blob contents, while
merging multiple common ancestors down. It is a bug to call the function
with unmerged entries in the index, even if the merge to come up with the
common ancestor resulted in conflicts. Otherwise the result won't be
expressible as a tree object.
We _might_ want to suggest the user to set GIT_MERGE_VERBOSITY to 5 and
re-run the merge in the message. At least we will know which part of
process_renames() or process_entry() functions is not correctly handling
the unmerged paths, and it might help us diagnosing the issue.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
merge-recursive.c | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/merge-recursive.c b/merge-recursive.c
index 1239647..cb53b01 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -202,14 +202,14 @@ struct tree *write_tree_from_memory(struct merge_options *o)
if (unmerged_cache()) {
int i;
- output(o, 0, "There are unmerged index entries:");
+ fprintf(stderr, "BUG: There are unmerged index entries:\n");
for (i = 0; i < active_nr; i++) {
struct cache_entry *ce = active_cache[i];
if (ce_stage(ce))
- output(o, 0, "%d %.*s", ce_stage(ce),
- (int)ce_namelen(ce), ce->name);
+ fprintf(stderr, "BUG: %d %.*s", ce_stage(ce),
+ (int)ce_namelen(ce), ce->name);
}
- return NULL;
+ die("Bug in merge-recursive.c");
}
if (!active_cache_tree)
^ permalink raw reply related
* Re: [RFC] Git Wiki Move
From: Johannes Schindelin @ 2010-01-22 0:39 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Petr Baudis, J.H., Matthieu Moy, git
In-Reply-To: <m3vdevat3m.fsf@localhost.localdomain>
Hi,
On Thu, 21 Jan 2010, Jakub Narebski wrote:
> Petr Baudis <pasky@suse.cz> writes:
> > On Mon, Jan 18, 2010 at 10:47:25AM -0800, J.H. wrote:
> > > On 01/18/2010 04:03 AM, Johannes Schindelin wrote:
>
> > > > - add a link from the old Wiki (with rewrite rules)
> > >
> > > I think the rewrites should be simple enough (the pages seem to line up
> > > 1:1 easily enough) so all I would need to do is discuss this with Petr.
> >
> > repo.or.cz migration to new server is now finished and on the new
> > system, I chose to not even install moinwiki at all. Instead, I've
> > installed a rewrite rule so all http://git.or.cz/gitwiki/ accesses are
> > sent to the appropriate place of http://git.wiki.kernel.org/ - thus,
> > that's the master copy of git wiki now. :-)
>
> Are all formatting bugs from MoinMoin + media4moin -> MediaWiki fixed?
No. The big ones are GitSurvey pages (except for 2007) and the SoC pages.
I went through all others, which means that maybe the occasional bug
slipped through, but basically the pages are sound.
Which makes me think that I finally deserve to see Henrik Nyh's logo on
the Wiki.
> If not, then it would be good to have reference read-only copy of old
> MoinMoin-based wiki to compare against.
If it would not involve more work for Pasky, I would agree. But mainly
the work was done.
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC] Git Wiki Move
From: Petr Baudis @ 2010-01-22 0:31 UTC (permalink / raw)
To: Jakub Narebski; +Cc: J.H., Johannes Schindelin, Matthieu Moy, git
In-Reply-To: <m3vdevat3m.fsf@localhost.localdomain>
On Thu, Jan 21, 2010 at 04:21:22PM -0800, Jakub Narebski wrote:
> Petr Baudis <pasky@suse.cz> writes:
> > On Mon, Jan 18, 2010 at 10:47:25AM -0800, J.H. wrote:
> > > On 01/18/2010 04:03 AM, Johannes Schindelin wrote:
>
> > > > - add a link from the old Wiki (with rewrite rules)
> > >
> > > I think the rewrites should be simple enough (the pages seem to line up
> > > 1:1 easily enough) so all I would need to do is discuss this with Petr.
> >
> > repo.or.cz migration to new server is now finished and on the new
> > system, I chose to not even install moinwiki at all. Instead, I've
> > installed a rewrite rule so all http://git.or.cz/gitwiki/ accesses are
> > sent to the appropriate place of http://git.wiki.kernel.org/ - thus,
> > that's the master copy of git wiki now. :-)
>
> Are all formatting bugs from MoinMoin + media4moin -> MediaWiki fixed?
> If not, then it would be good to have reference read-only copy of old
> MoinMoin-based wiki to compare against.
I'm not sure about the current state, I didn't really have time to look
carefully, so if people will say they have concrete need for the
reference read-only copy, I will set it up. But with the local hacks and
completely new system, it won't be trivial, so I'd prefer not to do it
just proactively.
Petr "Pasky" Baudis
^ permalink raw reply
* [PATCH] Documentation: improve description of --glob=pattern and friends
From: Thomas Rast @ 2010-01-22 0:21 UTC (permalink / raw)
To: git; +Cc: Michael J Gruber, Ilari Liusvaara, Johannes Sixt, Junio C Hamano
In-Reply-To: <7vbpgnp6d5.fsf@alter.siamese.dyndns.org>
Consolidate the descriptions of --branches, --tags and --remotes a
bit, to make it less repetitive. Improve the grammar a bit, and spell
out the meaning of the 'append /*' rule.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
Compared to the earlier draft, I changed "it is anchored" (by
appending '/*') to "it is turned into a prefix match", since this is
not anchoring in the ^regex$ sense. (I guess 'leading-component
match' would be even more accurate, but that makes the sentence
unwieldy in my ears.)
Documentation/git-rev-parse.txt | 32 +++++++++++++++-----------------
1 files changed, 15 insertions(+), 17 deletions(-)
diff --git a/Documentation/git-rev-parse.txt b/Documentation/git-rev-parse.txt
index e2cb913..e7845d4 100644
--- a/Documentation/git-rev-parse.txt
+++ b/Documentation/git-rev-parse.txt
@@ -104,25 +104,23 @@ OPTIONS
Show all refs found in `$GIT_DIR/refs`.
--branches[=pattern]::
- Show branch refs found in `$GIT_DIR/refs/heads`. If `pattern`
- is given, only branches matching given shell glob are shown.
- If pattern lacks '?', '*', or '[', '/*' at the end is impiled.
-
--tags[=pattern]::
- Show tag refs found in `$GIT_DIR/refs/tags`. If `pattern`
- is given, only tags matching given shell glob are shown.
- If pattern lacks '?', '*', or '[', '/*' at the end is impiled.
-
--remotes[=pattern]::
- Show tag refs found in `$GIT_DIR/refs/remotes`. If `pattern`
- is given, only remote tracking branches matching given shell glob
- are shown. If pattern lacks '?', '*', or '[', '/*' at the end is
- impiled.
-
---glob=glob-pattern::
- Show refs matching shell glob pattern `glob-pattern`. If pattern
- specified lacks leading 'refs/', it is automatically prepended.
- If pattern lacks '?', '*', or '[', '/*' at the end is impiled.
+ Show all branches, tags, or remote-tracking branches,
+ respectively (i.e., refs found in `$GIT_DIR/refs/heads`,
+ `$GIT_DIR/refs/tags`, or `$GIT_DIR/refs/remotes`,
+ respectively).
++
+If a `pattern` is given, only refs matching the given shell glob are
+shown. If the pattern does not contain a globbing character (`?`,
+`\*`, or `[`), it is turned into a prefix match by appending `/\*`.
+
+--glob=pattern::
+ Show all refs matching the shell glob pattern `pattern`. If
+ the pattern does not start with `refs/`, this is automatically
+ prepended. If the pattern does not contain a globbing
+ character (`?`, `\*`, or `[`), it is turned into a prefix
+ match by appending `/\*`.
--show-toplevel::
Show the absolute path of the top-level directory.
--
1.6.6.1.534.gf034a
^ permalink raw reply related
* Re: git-merge segfault in 1.6.6 and master
From: Junio C Hamano @ 2010-01-22 0:21 UTC (permalink / raw)
To: Tim Olsen; +Cc: git, Miklos Vajna, Johannes Schindelin
In-Reply-To: <7viqavs4xc.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> When they are called with non-zero o->call_depth, they are supposed to
> drop all the index entries that they handle down to stage #0 (even if the
> path had contents level conflict). For example, you see this bit in
> process_entry():
>
> } else if (a_sha && b_sha) {
> /* Case C: Added in both (check for same permissions) and */
> /* case D: Modified in both, but differently. */
> const char *reason = "content";
> ...
> mfi = merge_file(o, &one, &a, &b,
> o->branch1, o->branch2);
>
> clean_merge = mfi.clean;
> if (!mfi.clean) {
> if (S_ISGITLINK(mfi.mode))
> reason = "submodule";
> output(o, 1, "CONFLICT (%s): Merge conflict in %s",
> reason, path);
> }
> update_file(o, mfi.clean, mfi.sha, mfi.mode, path);
> } ...
>
> and update_file() eventually calls update_file_flags() to make sure that
> the content in mfi.sha is at the stage #0 of path when o->call_depth is
> non-zero (or mfi.clean is true). process_renames() and process_entry()
> are humongous functions that handle full of different cases, but all
> codepaths must follow the rule not to leave non-stage #0 entries in the
> index before merge_trees() function calls write_tree_from_memory().
>
> We've fixed a similar bug in c94736a (merge-recursive: don't segfault
> while handling rename clashes, 2009-07-30) and I think there were similar
> breakages we fixed over time in the same area, but the two functions being
> as huge as they are, I suspect you are hitting a codepath that hasn't been
> fixed.
And there are.
For example, this (drop it as t9999-junk.sh in t/ directory, go there and
run "sh ./t-9999-junk.sh -v") shows one codepath that makes merge-recursive
fail to resolve the "common ancestor" merge.
-- -- store in t/t9999-junk.sh and run -- --
#!/bin/sh
test_description='common ancestor merge corner cases'
. ./test-lib.sh
test_expect_success 'setup' '
mkdir D &&
echo 1 >D/F1 &&
echo 2 >D/F2 &&
echo 3 >D/F3 &&
echo 4 >D/F4 &&
echo 5 >D/F5 &&
echo 6 >D/F6 &&
git add D &&
test_tick &&
git commit -m initial &&
git branch side &&
git checkout master &&
git mv D/F1 D/M1 &&
git rm D/F2 &&
echo 7 >>D/F3 &&
git mv D/F4 D/M4 &&
git rm D/F5 &&
mkdir D/F5 &&
git mv D/F6 D/F5/M6 &&
git add -u &&
test_tick &&
git commit -m master &&
git tag A &&
git checkout side &&
git mv D/F1 D/S1 && # rename-rename conflict (dst)
echo 8 >>D/F2 && # remove-modify conflict
git mv D/F5 D/M4 && # rename-rename conflict (src)
git add -u &&
test_tick &&
git commit -m side &&
git tag B &&
git checkout side &&
test_tick &&
git merge -s ours master &&
git tag C &&
git checkout master &&
test_tick &&
git merge -s ours B &&
git tag D
'
test_expect_success 'criss-cross' '
git checkout D &&
test_must_fail git merge side
'
test_done
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
It dies after showing this (D/F5/M6 is left unresolved in the forced
"common ancestor" merge):
Merging:
f2f2f75 master
7994826 side
found 1 common ancestor(s):
f561e36 initial
CONFLICT (rename/rename): Rename "D/F1"->"D/M1" in branch "Temporary merge branch 1" rename "D/F1"->"D/S1" in "Temporary merge branch 2" (left unresolved)
CONFLICT (rename/add): Rename D/F4->D/M4 in Temporary merge branch 1. D/M4 added in Temporary merge branch 2
Adding merged D/M4
Skipped D/M4 (merged same as existing)
CONFLICT (rename/delete): Rename D/F5->D/M4 in Temporary merge branch 2 and deleted in Temporary merge branch 1
Skipped D/F5/M6 (merged same as existing)
CONFLICT (delete/modify): D/F2 deleted in Temporary merge branch 1 and modified in Temporary merge branch 2. Version Temporary merge branch 2 of D/F2 left in tree.
There are unmerged index entries:
2 D/F5/M6
The attached patch changes the behaviour to make this 9999-junk test pass,
but then it breaks t6036 (iow, the attached is _not_ a fix).
After I stared at the code for more than two hours, I gave up trying to
diagnose this by myself. People more familiar with the merge-recursive
implementation might be able to help figuring this out and may prove my
suspicion wrong, but I have a feeling that without a fairly big rewrite
the code is unsalvageable.
-- >8 --
Not a fix
diff --git a/merge-recursive.c b/merge-recursive.c
index 1239647..132a6fc 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -1052,8 +1052,8 @@ static int process_renames(struct merge_options *o,
update_stages(ren1_dst,
one, a, b, 1);
}
- update_file(o, mfi.clean, mfi.sha, mfi.mode, ren1_dst);
}
+ update_file(o, mfi.clean, mfi.sha, mfi.mode, ren1_dst);
}
}
}
^ permalink raw reply related
* Re: [RFC] Git Wiki Move
From: Jakub Narebski @ 2010-01-22 0:21 UTC (permalink / raw)
To: Petr Baudis; +Cc: J.H., Johannes Schindelin, Matthieu Moy, git
In-Reply-To: <20100121213514.GD3299@machine.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> On Mon, Jan 18, 2010 at 10:47:25AM -0800, J.H. wrote:
> > On 01/18/2010 04:03 AM, Johannes Schindelin wrote:
> > > - add a link from the old Wiki (with rewrite rules)
> >
> > I think the rewrites should be simple enough (the pages seem to line up
> > 1:1 easily enough) so all I would need to do is discuss this with Petr.
>
> repo.or.cz migration to new server is now finished and on the new
> system, I chose to not even install moinwiki at all. Instead, I've
> installed a rewrite rule so all http://git.or.cz/gitwiki/ accesses are
> sent to the appropriate place of http://git.wiki.kernel.org/ - thus,
> that's the master copy of git wiki now. :-)
Are all formatting bugs from MoinMoin + media4moin -> MediaWiki fixed?
If not, then it would be good to have reference read-only copy of old
MoinMoin-based wiki to compare against.
> Thanks a lot for stepping up to do this, J.H.!
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* [PATCH] Handle double slashes in make_relative_path()
From: Thomas Rast @ 2010-01-22 0:07 UTC (permalink / raw)
To: git; +Cc: Linus Torvalds, Junio C Hamano
If you say
git --git-dir=/some//path --work-tree=/some/ add <somefile>
then setup_work_tree() will call into make_relative_path() with
abs="/some//path" and base="/some". (Note how the latter has already
lost its trailing slash. One unfortunate user managed to trigger this
because his $HOME ended in a slash.)
This means that when checking whether 'abs' is a path under 'base', we
need to skip *two* slashes where the previous code only accounted for
one. Fix it to handle an arbitrary number of slashes at that
position.
Noticed-by: eldenz on freenode
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
path.c | 6 +++---
t/t1501-worktree.sh | 6 ++++++
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/path.c b/path.c
index 2ec950b..a195bab 100644
--- a/path.c
+++ b/path.c
@@ -400,10 +400,10 @@ int set_shared_perm(const char *path, int mode)
baselen = strlen(base);
if (prefixcmp(abs, base))
return abs;
- if (abs[baselen] == '/')
- baselen++;
- else if (base[baselen - 1] != '/')
+ if (abs[baselen] != '/' && base[baselen - 1] != '/')
return abs;
+ while (abs[baselen] == '/')
+ baselen++;
strcpy(buf, abs + baselen);
return buf;
}
diff --git a/t/t1501-worktree.sh b/t/t1501-worktree.sh
index 74e6443..9df3012 100755
--- a/t/t1501-worktree.sh
+++ b/t/t1501-worktree.sh
@@ -189,4 +189,10 @@ test_expect_success 'absolute pathspec should fail gracefully' '
)
'
+test_expect_success 'make_relative_path handles double slashes in GIT_DIR' '
+ : > dummy_file
+ echo git --git-dir="$(pwd)//repo.git" --work-tree="$(pwd)" add dummy_file &&
+ git --git-dir="$(pwd)//repo.git" --work-tree="$(pwd)" add dummy_file
+'
+
test_done
--
1.6.6.1.532.g594fe
^ permalink raw reply related
* Re: Remove diff machinery dependency from read-cache
From: Linus Torvalds @ 2010-01-21 23:25 UTC (permalink / raw)
To: Junio C Hamano, Shawn O. Pearce; +Cc: Git Mailing List
In-Reply-To: <alpine.LFD.2.00.1001211355500.13231@localhost.localdomain>
On Thu, 21 Jan 2010, Linus Torvalds wrote:
>
> We could fix it a few ways
>
> - ignore it. Most git programs will get the pack handling functions
> anyway, since they want to get object reading.
In fact, we should probably remove git-show-index. It may have some
historical significance as a pack-file index debugger, but it has no
actual redeeming features now, considering that the binary is a megabyte
of useless crud with debugging info.
However, we do actually use it in t/t5302-pack-index.sh. So in the
meantime, how about this hacky patch to simply just avoid xmalloc, and
separating out the trivial hex functions into "hex.o".
This results in
[torvalds@nehalem git]$ size git-show-index
text data bss dec hex filename
222818 2276 112688 337782 52776 git-show-index (before)
5696 624 1264 7584 1da0 git-show-index (after)
which is a whole lot better, no?
(Or make it a built-in, if we actually think we want to carry it along in
the long run)
Linus
---
Makefile | 1 +
sha1_file.c | 66 ----------------------------------------------------------
show-index.c | 2 +-
3 files changed, 2 insertions(+), 67 deletions(-)
diff --git a/Makefile b/Makefile
index ad890ec..a041b69 100644
--- a/Makefile
+++ b/Makefile
@@ -559,6 +559,7 @@ LIB_OBJS += graph.o
LIB_OBJS += grep.o
LIB_OBJS += hash.o
LIB_OBJS += help.o
+LIB_OBJS += hex.o
LIB_OBJS += ident.o
LIB_OBJS += levenshtein.o
LIB_OBJS += list-objects.o
diff --git a/sha1_file.c b/sha1_file.c
index 7086760..12478a3 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -35,54 +35,6 @@ static size_t sz_fmt(size_t s) { return s; }
const unsigned char null_sha1[20];
-const signed char hexval_table[256] = {
- -1, -1, -1, -1, -1, -1, -1, -1, /* 00-07 */
- -1, -1, -1, -1, -1, -1, -1, -1, /* 08-0f */
- -1, -1, -1, -1, -1, -1, -1, -1, /* 10-17 */
- -1, -1, -1, -1, -1, -1, -1, -1, /* 18-1f */
- -1, -1, -1, -1, -1, -1, -1, -1, /* 20-27 */
- -1, -1, -1, -1, -1, -1, -1, -1, /* 28-2f */
- 0, 1, 2, 3, 4, 5, 6, 7, /* 30-37 */
- 8, 9, -1, -1, -1, -1, -1, -1, /* 38-3f */
- -1, 10, 11, 12, 13, 14, 15, -1, /* 40-47 */
- -1, -1, -1, -1, -1, -1, -1, -1, /* 48-4f */
- -1, -1, -1, -1, -1, -1, -1, -1, /* 50-57 */
- -1, -1, -1, -1, -1, -1, -1, -1, /* 58-5f */
- -1, 10, 11, 12, 13, 14, 15, -1, /* 60-67 */
- -1, -1, -1, -1, -1, -1, -1, -1, /* 68-67 */
- -1, -1, -1, -1, -1, -1, -1, -1, /* 70-77 */
- -1, -1, -1, -1, -1, -1, -1, -1, /* 78-7f */
- -1, -1, -1, -1, -1, -1, -1, -1, /* 80-87 */
- -1, -1, -1, -1, -1, -1, -1, -1, /* 88-8f */
- -1, -1, -1, -1, -1, -1, -1, -1, /* 90-97 */
- -1, -1, -1, -1, -1, -1, -1, -1, /* 98-9f */
- -1, -1, -1, -1, -1, -1, -1, -1, /* a0-a7 */
- -1, -1, -1, -1, -1, -1, -1, -1, /* a8-af */
- -1, -1, -1, -1, -1, -1, -1, -1, /* b0-b7 */
- -1, -1, -1, -1, -1, -1, -1, -1, /* b8-bf */
- -1, -1, -1, -1, -1, -1, -1, -1, /* c0-c7 */
- -1, -1, -1, -1, -1, -1, -1, -1, /* c8-cf */
- -1, -1, -1, -1, -1, -1, -1, -1, /* d0-d7 */
- -1, -1, -1, -1, -1, -1, -1, -1, /* d8-df */
- -1, -1, -1, -1, -1, -1, -1, -1, /* e0-e7 */
- -1, -1, -1, -1, -1, -1, -1, -1, /* e8-ef */
- -1, -1, -1, -1, -1, -1, -1, -1, /* f0-f7 */
- -1, -1, -1, -1, -1, -1, -1, -1, /* f8-ff */
-};
-
-int get_sha1_hex(const char *hex, unsigned char *sha1)
-{
- int i;
- for (i = 0; i < 20; i++) {
- unsigned int val = (hexval(hex[0]) << 4) | hexval(hex[1]);
- if (val & ~0xff)
- return -1;
- *sha1++ = val;
- hex += 2;
- }
- return 0;
-}
-
static inline int offset_1st_component(const char *path)
{
if (has_dos_drive_prefix(path))
@@ -133,24 +85,6 @@ int safe_create_leading_directories_const(const char *path)
return result;
}
-char *sha1_to_hex(const unsigned char *sha1)
-{
- static int bufno;
- static char hexbuffer[4][50];
- static const char hex[] = "0123456789abcdef";
- char *buffer = hexbuffer[3 & ++bufno], *buf = buffer;
- int i;
-
- for (i = 0; i < 20; i++) {
- unsigned int val = *sha1++;
- *buf++ = hex[val >> 4];
- *buf++ = hex[val & 0xf];
- }
- *buf = '\0';
-
- return buffer;
-}
-
static void fill_sha1_path(char *pathbuf, const unsigned char *sha1)
{
int i;
diff --git a/show-index.c b/show-index.c
index 63f9da5..4c0ac13 100644
--- a/show-index.c
+++ b/show-index.c
@@ -48,7 +48,7 @@ int main(int argc, char **argv)
unsigned char sha1[20];
uint32_t crc;
uint32_t off;
- } *entries = xmalloc(nr * sizeof(entries[0]));
+ } *entries = malloc(nr * sizeof(entries[0]));
for (i = 0; i < nr; i++)
if (fread(entries[i].sha1, 20, 1, stdin) != 1)
die("unable to read sha1 %u/%u", i, nr);
^ permalink raw reply related
* Re: Remove diff machinery dependency from read-cache
From: Linus Torvalds @ 2010-01-21 22:18 UTC (permalink / raw)
To: Junio C Hamano, Shawn O. Pearce; +Cc: Git Mailing List
In-Reply-To: <alpine.LFD.2.00.1001211215080.13231@localhost.localdomain>
On Thu, 21 Jan 2010, Linus Torvalds wrote:
>
> Sure. Except, as I mentioned, it's not just git-hash-object. It's _all_ of
> them.
>
> The total space savings wasn't 1.7M, it was 12M.
There are some other interesting cases. For example, look at this:
[torvalds@nehalem git]$ size show-index.o git-show-index
text data bss dec hex filename
1310 0 1024 2334 91e show-index.o
222706 2296 112720 337722 5273a git-show-index
ie a trivial program like 'show-index' has ballooned to 220kB. Let's look
at why:
[torvalds@nehalem git]$ nm show-index.o | grep ' U '
U die
U fread
U free
U printf
U sha1_to_hex
U stdin
U usage
U xmalloc
ok, if you ignore standard library things (which will be from a shared
library anyway), it really only wants totally trivial things: die,
xmalloc, and sha1_to_hex. Those should be a few hundred bytes, not a few
hundred _kilo_bytes.
So what happens?
- sha1_to_hex brings in all of sha1_file.c, even though it doesn't need
any of it. Ok, that's easily fixed: split up the hex helpers into a
file of its own ("hex.c")
- "die()" brings in usage.c, which is actually designed correctly, so it
is all fine. No extra pain there. Sure, we'll get some other trivial
stuff from there, but we're talking maybe a kilobyte of code.
- "xmalloc()" brings in the trivial wrappers.
OOPS.
Those wrappers bring in zlib (through git_inflate*), which is not a huge
issue, we coult just move the git_inflate*() wrappers to its own file.
Trivial. But the wrappers also bring in:
- xmalloc/xrealloc/xstrdup:
U release_pack_memory
which in turn brings in _all_ of the rest of the git libraries. End
result: a trivial git helper program that _should_ be a couple of
kilobytes in size ends up being 200+kB of text, and 900kB with debug
information.
Absolutely _none_ of which is in the least useful.
Oh well.
We could fix it a few ways
- ignore it. Most git programs will get the pack handling functions
anyway, since they want to get object reading.
- as mentioned, just build in _everything_ so that we only ever have one
binary
- get rid of release_pack_memory() entirely. We have better ways to limit
pack memory use these days, but they do require configuration (we do
have a default packed_git_limit, though, so even without any explicit
configuration it's not insane).
- don't have explicit knowledge about 'release_pack_memory' in xmalloc,
but instead have the packing functions register a "xmalloc
pressure_reliever function". So then programs that have pack handling
will register the fixup function, and programs that don't will never
even know.
Hmm? We have about 20 external programs that may hide issues like this.
Linus
^ permalink raw reply
* Please, Kindly Indicate your Desire And Willingness to Assist!!
From: David Lambert @ 2010-01-21 22:18 UTC (permalink / raw)
To: lambiedavid011
[-- Attachment #1: Type: text/plain, Size: 24 bytes --]
Please read attachment.
[-- Attachment #2: Please, Kindly Indicate your Desire And Willingness to Assist.txt --]
[-- Type: application/octet-stream, Size: 10875 bytes --]
David Lambert
South Quay Plaza
183 Marsh Wall
London
E14 9SR
I am David Lambert,British citizen and Principal assurance manager for the HSBC in London. A staff of Yokozona consultancy firm got in touch with me regarding the estate of Philip Smith. And an investment placed under our banks management 3 years ago.I would respectfully request that you keep the contents of this mail confidential and respect the integrity of the information you come by as a result of this mail.I contact you independent of our investigation and no one is informed of this communication.
I would like to intimate you with certain facts that I believe would be of interest to you.In 1997,the subject matter;Philip Smith came to our bank to engage in business discussions with our private banking division.He informed us that he had a financial portfolio of 48.35 million United States dollars,which he wished to have us turn over (invest) on his behalf.I was the officer assigned to his case,I made numerous suggestions in line with my duties as the de-facto chief operations officer, especially given the volume of funds he wished to put into our bank. We met on numerous occasions prior to any investments being placed.I encouraged him to consider various growth funds with prime ratings.The favored route in my advice to customers is to start by assessing data on 6000 traditional stocks and bond managers and 2000 managers of alternative investments.Based on my advice,We spun the money around various opportunities and made attractive margins within few months of operation,the accrued profit and interest stood at this point at over 51 million United States Dollars,this margin was not the full potential of the fund but he desired low risk guaranteed returns on investments. In mid 1998, he asked that the money be liquidated because he needed to make an urgent investment requiring cash payments in United Kingdom.He directed that I liquidate the funds and had it deposited with United Assets Management UK (in their Securities Trading Firm).I informed him that HSBC London would have to make special arrangements to have this done and in order not to circumvent due process,the bank would have to make a 9.5 % deduction from the funds to cater for banking and statutory charges.He complained about the charges but later came around when I explained to him the complexities of the task he was asking of us.I contacted my affiliate in United Kingdom and had the funds made available to United Assets Management.
We undertook all the processes and made sure I followed his precise instructions to the letter and had the funds deposited at United Assets Management UK United Kingdom.United Assets Management UK is a specialist bank that accepts deposits from high net worth individuals and blue chip corporations that handle valuable products or undertake transactions that need immediate access to cash.In Line with instructions,the money was deposited with United Assets Management UK (in their Securities Trading Firm).
Philip Smith told me he wanted the money there as soon as he got into the United Kingdom,This was the last communication we had, this transpired around 25th February 1999.In Sept last year,we got a call from United Assets Management UK informing us about the inactivity of that particular portfolio.This was an astounding position as far as I was concerned,given the fact that I managed the international private banking sector I was the only one who knew about the deposit at United Assets Management UK,and I could not understand why Philip Smith had not come forward to claim his deposit.I made futile efforts to locate Philip Smith.Four days later,information started to trickle in,apparently Philip Smith was dead.A person who suited his description was declared dead of AUTO ACCIDENT TRAUMA in Birmingham England.We were soon enough,able to identify the body and cause of death was confirmed.The bank immediately launched an investigation into possible surviving next of kin to alert about the situation and also to come forward to claim his estate.In the field of private banking,opening an account with us means no one will know of its existence,accounts are rarely held under a name;depositors use numbers and codes to make the accounts anonymous.This bank also gives the choice to depositors of having their mail sent to them or held at the bank itself,ensuring that there are no traces of the account and as I said,rarely do they nominate next of kin.
Private banking clients apart from not nominating next of kin also usually in most cases leave wills in our care,in this case; Philip Smith died intestate.
In line with our internal processes for account holders who have passed away,we instituted our own investigations in good faith to determine who should have right to claim the estate.This investigation has for the past months been unfruitful.We have scanned every continent and used our private investigation affiliate companies to get to the root of the problem.It is this investigation that resulted in my being furnished with your details as a possible relative of the deceased.My official capacity dictates that I am the only party to supervise the investigation and the only party to receive the results of the investigation.You have unfortunately declared,and I know that you are in no way affiliated with this individual.What this means,you being the last batch of names we have considered is that our dear late fellow died with no known or identifiable family member.This leaves me as the only person with the full picture of what the prevailing situation is in relation to the deposit and the late beneficiary of the deposit.
According to practice, United Assets Management UK will by the end of this quarter broadcast a request for statements of claim to HSBC in London,failing to receive viable claims they will most probably revert the deposit back to HSBC in London.This will result in the money entering the HSBC in London accounting system and the portfolio will be out of my hands and out of the private banking division.This will not happen if I have my way. What I wish to relate to you will smack off unethical practice but I want you to understand something.It is only an outsider to the banking world who finds the internal politics of the banking world aberrational.The world of private banking especially is fraught with huge rewards for those who occupy certain offices and oversee certain portfolios.You should have begun by now to put together the general direction of what I propose.There is US$ 48,370,000.00 deposited in United Assets Management UK,I alone have the deposit details and they will release the deposit to no one unless I instruct them to do so.
I alone know of the existence of this deposit for as far as United Assets Management UK is concerned,the transaction with Philip Smith concluded when I sent the funds to United Assets Management UK,all outstanding interactions in relation to the file are just customer services and due process.United Assets Management UK has no single idea of the history or nature of the deposit.They are simply awaiting instructions to release the deposit to any party that comes forward.This is the situation.This bank has spent great amounts of money trying to track this man's family;they have investigated for months and have found no family.The investigation has come to an end.
My proposal,I am prepared to place you as the next of kin in a position to instruct United Assets Management UK to release the deposit to you as the closest surviving relation.Upon receipt of the deposit,I am prepared to share the money with you in half.That is:I will simply nominate you as the next of kin and have them release the deposit to you. We share the proceeds 50/50.
I would have gone ahead to ask the funds be released to me,but that would have drawn a straight line to my involvement in claiming the deposit.I assure you that I could have the deposit released to you within a few days.I will simply inform the bank of the final closing of the file relating to Philip Smith I will then officially communicate with United Assets Management UK and instruct them to release the deposit to you.With these:all is done.I am aware of the consequences of this proposal.I ask that if you find no interest in this project that you should discard this mail.I ask that you do not be vindictive and destructive.If my offer is of no appeal to you,delete this message and forget I ever contacted you.Do not destroy my career because you do not approve of my proposal.You may not know this but people like myself who have made tidy sums out of comparable situations run the whole private banking sector.I am not a criminal and what I do,I do not find against good conscience,this may be hard for you to understand,but the dynamics of my industry dictates that I make this move.Such opportunities only come once in a lifetime.I cannot let this chance pass me by,for once I find myself in total control of my destiny.
These chances wont pass me by.I ask that you do not destroy my chance,if you will not work with me let me know and let me move on with my life but do not destroy me.I am a family man and this is an opportunity to provide them with new opportunities.There is a reward for this project and it is a task well worth undertaking.I have evaluated the risks and the only risk I have here is from you refusing to work with me and alerting my bank.I am the only one who knows of this situation,good fortune has blessed you with a name that has planted you into the center of relevance in my life.Lets share the blessing.
If you give me positive signals,I will initiate this process towards a conclusion.I wish to inform you that should you contact me via official channels;I will deny knowing you and about this project.I repeat,I do not want you contacting me through my official phone lines nor do I want you contacting me through my official email account. Contact me only through the numbers I will provide you with and also through this email address; lambiedavid01@excite.co.uk I do not want any direct link between you and me.My official lines are not secure lines as they are periodically monitored to assess our level of customer care in line with our Total Quality Management Policy.Please observe this instruction religiously.Please,again,note I am a family man,I have a wife and children.I send you this mail not without a measure of fear as to what the consequences are,but I know within me that nothing ventured is nothing gained and that success and riches never come easy or on a platter of gold.This is the one truth I have learned from my private banking clients.Do not betray my confidence.If we can be of one accord,we should plan a meeting,soon.
I await your response.
Respectfully,
David Lambert
^ permalink raw reply
* Re: git-merge segfault in 1.6.6 and master
From: Tim Olsen @ 2010-01-21 21:56 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, git, Johannes Schindelin
In-Reply-To: <20100121140057.GP12429@genesis.frugalware.org>
Miklos Vajna wrote:
> Two ideas to help debugging:
>
> - Can you try if this happens in a new repo as well? (If not, is the
> repo public?) If yes, can you write a script that shows your problem?
The problem still happens in any clone of the repository, but I have not
attempted to reproduce the problem in a fresh repository. I've put our
repository up at git://les.limebits.net/site (warning: the repo is about
364MB). The following 3 commands will reproduce the problem:
git clone git://les.limebits.net/site
cd site
git merge origin/deployed
The problem starts with commit 9079b71b6f. I can merge its ancestors
with no problem into the default branch (build-dav-sync-05). But commit
9079b71b6f and its descendents cause a segfault when merging into
build-dav-sync-05.
> - Can you see if this happens with v1.6.0? If yes, can you bisect it?
With 1.6.0, the merge still fails but it doesn't outright segfault.
$ git merge origin/deployed
Merge with strategy recursive failed.
$
The output appears to be from line 1098 of builtin-merge.c. Bisecting
finds that the outright segfaulting starts with commit 18668f53:
tolsen@neurofunk:~/git/git [git:NO BRANCH*]$ git bisect good
18668f5319b079cce29e19817bc352b1413e0908 is first bad commit
commit 18668f5319b079cce29e19817bc352b1413e0908
Author: Miklos Vajna <vmiklos@frugalware.org>
Date: Thu Aug 28 15:43:00 2008 +0200
builtin-merge: avoid run_command_v_opt() for recursive and subtree
The try_merge_strategy() function always ran the strategy in a separate
process, though this is not always necessary. The recursive and subtree
strategy can be called without a fork(). This patch adds a check, and
calls recursive in the same process without wasting resources.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
:100644 100644 9ad9791068c9330f28413ac67315246989c8d96d
b857cf6246978846e0c19895fd6f66266cf6a6f4 M builtin-merge.c
tolsen@neurofunk:~/git/git [git:NO BRANCH*]$
This leads me to believe the segfault may still be occurring in v1.6.0,
but in a separate process.
Tim
>
> Thanks.
^ permalink raw reply
* [PATCH] git-svn: update svn mergeinfo test suite
From: Andrew Myrick @ 2010-01-21 21:55 UTC (permalink / raw)
To: git; +Cc: normalperson, sam, Andrew Myrick
In-Reply-To: <E10FB265-0C47-44C7-9347-687A9F447603@apple.com>
Add a partial branch (e.g., a branch from a project subdirectory) to the
git-svn mergeinfo test repository.
Add a tag and a branch from that tag to the git-svn mergeinfo test repository.
Update the test script to expect a known failure in git-svn exposed by these
additions where merge info for partial branches is not preserved.
Signed-off-by: Andrew Myrick <amyrick@apple.com>
---
t/t9151-svn-mergeinfo.sh | 2 +-
t/t9151/make-svnmerge-dump | 65 +++++-
t/t9151/svn-mergeinfo.dump | 545 ++++++++++++++++++++++++++++++++++----------
3 files changed, 485 insertions(+), 127 deletions(-)
diff --git a/t/t9151-svn-mergeinfo.sh b/t/t9151-svn-mergeinfo.sh
index 359eeaa..3569c62 100755
--- a/t/t9151-svn-mergeinfo.sh
+++ b/t/t9151-svn-mergeinfo.sh
@@ -33,7 +33,7 @@ test_expect_success 'svn non-merge merge commits did not become git merge commit
[ -z "$bad_non_merges" ]
'
-test_expect_success 'everything got merged in the end' '
+test_expect_failure 'everything got merged in the end' '
unmerged=$(git rev-list --all --not master)
[ -z "$unmerged" ]
'
diff --git a/t/t9151/make-svnmerge-dump b/t/t9151/make-svnmerge-dump
index d917717..3d73f14 100644
--- a/t/t9151/make-svnmerge-dump
+++ b/t/t9151/make-svnmerge-dump
@@ -26,8 +26,9 @@ i=0
cd foo
mkdir trunk
mkdir branches
-svn add trunk branches
-i=$(commit $i "Setup trunk and branches")
+mkdir tags
+svn add trunk branches tags
+i=$(commit $i "Setup trunk, branches, and tags")
git cat-file blob 6683463e:Makefile > trunk/Makefile
svn add trunk/Makefile
@@ -155,6 +156,66 @@ svn merge ../branches/right --accept postpone
i=$(commit $i "non-merge right to trunk 2")
cd ..
+say "Adding subdirectory to LEFT"
+svn update
+cd branches/left
+mkdir subdir
+echo "Yeehaw" > subdir/cowboy
+svn add subdir
+i=$(commit $i "add subdirectory to left branch")
+cd ../../
+
+say "Merging LEFT to TRUNK"
+svn update
+cd trunk
+svn merge ../branches/left --accept postpone
+i=$(commit $i "merge left to trunk")
+cd ..
+
+say "Make PARTIAL branch"
+svn update
+i=$(commit $i "make partial branch")
+svn cp trunk/subdir branches/partial
+
+say "Make a commit to PARTIAL"
+svn update
+cd branches/partial
+echo "racecar" > palindromes
+svn add palindromes
+i=$(commit $i "partial update")
+cd ../../
+
+say "Merge PARTIAL to TRUNK"
+svn update
+cd trunk/subdir
+svn merge ../../branches/partial --accept postpone
+i=$(commit $i "merge partial to trunk")
+cd ../../
+
+say "Tagging trunk"
+svn update
+i=$(commit $i "tagging v1.0")
+svn cp trunk tags/v1.0
+
+say "Branching BUGFIX from v1.0"
+svn update
+i=$(commit $i "make bugfix branch from tag")
+svn cp tags/v1.0 branches/bugfix
+
+say "Make a commit to BUGFIX"
+svn update
+cd branches/bugfix/
+echo "kayak" >> subdir/palindromes
+i=$(commit $i "commit to bugfix")
+cd ../../
+
+say "Merge BUGFIX to TRUNK"
+svn update
+cd trunk
+svn merge ../branches/bugfix/ --accept postpone
+i=$(commit $i "Merge BUGFIX to TRUNK")
+cd ..
+
cd ..
svnadmin dump foo.svn > svn-mergeinfo.dump
diff --git a/t/t9151/svn-mergeinfo.dump b/t/t9151/svn-mergeinfo.dump
index 9543e31..ebf386e 100644
--- a/t/t9151/svn-mergeinfo.dump
+++ b/t/t9151/svn-mergeinfo.dump
@@ -1,6 +1,6 @@
SVN-fs-dump-format-version: 2
-UUID: 64142547-0943-4db2-836a-d1e1eb2f9924
+UUID: d6191530-2693-4a8e-98e7-b194d4c3edd8
Revision-number: 0
Prop-content-length: 56
@@ -9,25 +9,25 @@ Content-length: 56
K 8
svn:date
V 27
-2009-12-19T16:17:51.232640Z
+2010-01-19T04:14:02.832406Z
PROPS-END
Revision-number: 1
-Prop-content-length: 128
-Content-length: 128
+Prop-content-length: 134
+Content-length: 134
K 7
svn:log
-V 29
-(r1) Setup trunk and branches
+V 36
+(r1) Setup trunk, branches, and tags
K 10
svn:author
-V 4
-samv
+V 3
+adm
K 8
svn:date
V 27
-2009-12-19T16:17:51.831965Z
+2010-01-19T04:14:03.055172Z
PROPS-END
Node-path: branches
@@ -39,6 +39,15 @@ Content-length: 10
PROPS-END
+Node-path: tags
+Node-kind: dir
+Node-action: add
+Prop-content-length: 10
+Content-length: 10
+
+PROPS-END
+
+
Node-path: trunk
Node-kind: dir
Node-action: add
@@ -49,8 +58,8 @@ PROPS-END
Revision-number: 2
-Prop-content-length: 112
-Content-length: 112
+Prop-content-length: 111
+Content-length: 111
K 7
svn:log
@@ -58,12 +67,12 @@ V 13
(r2) ancestor
K 10
svn:author
-V 4
-samv
+V 3
+adm
K 8
svn:date
V 27
-2009-12-19T16:17:52.300075Z
+2010-01-19T04:14:04.064506Z
PROPS-END
Node-path: trunk/Makefile
@@ -156,8 +165,8 @@ backup: clean
Revision-number: 3
-Prop-content-length: 120
-Content-length: 120
+Prop-content-length: 119
+Content-length: 119
K 7
svn:log
@@ -165,12 +174,12 @@ V 21
(r3) make left branch
K 10
svn:author
-V 4
-samv
+V 3
+adm
K 8
svn:date
V 27
-2009-12-19T16:17:52.768800Z
+2010-01-19T04:14:06.040389Z
PROPS-END
Node-path: branches/left
@@ -190,8 +199,8 @@ Text-copy-source-sha1: 103205ce331f7d64086dba497574734f78439590
Revision-number: 4
-Prop-content-length: 121
-Content-length: 121
+Prop-content-length: 120
+Content-length: 120
K 7
svn:log
@@ -199,12 +208,12 @@ V 22
(r4) make right branch
K 10
svn:author
-V 4
-samv
+V 3
+adm
K 8
svn:date
V 27
-2009-12-19T16:17:53.177879Z
+2010-01-19T04:14:08.040905Z
PROPS-END
Node-path: branches/right
@@ -224,8 +233,8 @@ Text-copy-source-sha1: 103205ce331f7d64086dba497574734f78439590
Revision-number: 5
-Prop-content-length: 117
-Content-length: 117
+Prop-content-length: 116
+Content-length: 116
K 7
svn:log
@@ -233,12 +242,12 @@ V 18
(r5) left update 1
K 10
svn:author
-V 4
-samv
+V 3
+adm
K 8
svn:date
V 27
-2009-12-19T16:17:53.604691Z
+2010-01-19T04:14:09.049169Z
PROPS-END
Node-path: branches/left/Makefile
@@ -329,8 +338,8 @@ backup: clean
Revision-number: 6
-Prop-content-length: 118
-Content-length: 118
+Prop-content-length: 117
+Content-length: 117
K 7
svn:log
@@ -338,12 +347,12 @@ V 19
(r6) right update 1
K 10
svn:author
-V 4
-samv
+V 3
+adm
K 8
svn:date
V 27
-2009-12-19T16:17:54.063555Z
+2010-01-19T04:14:10.049350Z
PROPS-END
Node-path: branches/right/Makefile
@@ -437,8 +446,8 @@ backup: clean
Revision-number: 7
-Prop-content-length: 117
-Content-length: 117
+Prop-content-length: 116
+Content-length: 116
K 7
svn:log
@@ -446,12 +455,12 @@ V 18
(r7) left update 2
K 10
svn:author
-V 4
-samv
+V 3
+adm
K 8
svn:date
V 27
-2009-12-19T16:17:54.523904Z
+2010-01-19T04:14:11.049209Z
PROPS-END
Node-path: branches/left/Makefile
@@ -542,8 +551,8 @@ backup: clean
Revision-number: 8
-Prop-content-length: 117
-Content-length: 117
+Prop-content-length: 116
+Content-length: 116
K 7
svn:log
@@ -551,12 +560,12 @@ V 18
(r8) left update 3
K 10
svn:author
-V 4
-samv
+V 3
+adm
K 8
svn:date
V 27
-2009-12-19T16:17:54.975970Z
+2010-01-19T04:14:12.049234Z
PROPS-END
Node-path: branches/left/Makefile
@@ -647,8 +656,8 @@ backup: clean
Revision-number: 9
-Prop-content-length: 124
-Content-length: 124
+Prop-content-length: 123
+Content-length: 123
K 7
svn:log
@@ -656,12 +665,12 @@ V 25
(r9) make left sub-branch
K 10
svn:author
-V 4
-samv
+V 3
+adm
K 8
svn:date
V 27
-2009-12-19T16:17:55.459904Z
+2010-01-19T04:14:14.040894Z
PROPS-END
Node-path: branches/left-sub
@@ -687,8 +696,8 @@ Text-copy-source-sha1: a13de8e23f1483efca3e57b2b64b0ae6f740ce10
Revision-number: 10
-Prop-content-length: 129
-Content-length: 129
+Prop-content-length: 128
+Content-length: 128
K 7
svn:log
@@ -696,12 +705,12 @@ V 30
(r10) left sub-branch update 1
K 10
svn:author
-V 4
-samv
+V 3
+adm
K 8
svn:date
V 27
-2009-12-19T16:17:55.862113Z
+2010-01-19T04:14:15.049935Z
PROPS-END
Node-path: branches/left-sub/README
@@ -718,8 +727,8 @@ crunch
Revision-number: 11
-Prop-content-length: 126
-Content-length: 126
+Prop-content-length: 125
+Content-length: 125
K 7
svn:log
@@ -727,12 +736,12 @@ V 27
(r11) Merge left to trunk 1
K 10
svn:author
-V 4
-samv
+V 3
+adm
K 8
svn:date
V 27
-2009-12-19T16:17:56.413416Z
+2010-01-19T04:14:18.056594Z
PROPS-END
Node-path: trunk
@@ -836,8 +845,8 @@ backup: clean
Revision-number: 12
-Prop-content-length: 118
-Content-length: 118
+Prop-content-length: 117
+Content-length: 117
K 7
svn:log
@@ -845,12 +854,12 @@ V 19
(r12) left update 4
K 10
svn:author
-V 4
-samv
+V 3
+adm
K 8
svn:date
V 27
-2009-12-19T16:17:56.831014Z
+2010-01-19T04:14:19.049620Z
PROPS-END
Node-path: branches/left/zlonk
@@ -867,8 +876,8 @@ touche
Revision-number: 13
-Prop-content-length: 119
-Content-length: 119
+Prop-content-length: 118
+Content-length: 118
K 7
svn:log
@@ -876,12 +885,12 @@ V 20
(r13) right update 2
K 10
svn:author
-V 4
-samv
+V 3
+adm
K 8
svn:date
V 27
-2009-12-19T16:17:57.341143Z
+2010-01-19T04:14:20.049659Z
PROPS-END
Node-path: branches/right/bang
@@ -898,8 +907,8 @@ thwacke
Revision-number: 14
-Prop-content-length: 141
-Content-length: 141
+Prop-content-length: 140
+Content-length: 140
K 7
svn:log
@@ -907,12 +916,12 @@ V 42
(r14) Cherry-pick right 2 commits to trunk
K 10
svn:author
-V 4
-samv
+V 3
+adm
K 8
svn:date
V 27
-2009-12-19T16:17:57.841851Z
+2010-01-19T04:14:23.041991Z
PROPS-END
Node-path: trunk
@@ -1029,8 +1038,8 @@ Text-copy-source-sha1: 0bc5bb345c0e71d28f784f12e0bd2d384c283062
Revision-number: 15
-Prop-content-length: 127
-Content-length: 127
+Prop-content-length: 126
+Content-length: 126
K 7
svn:log
@@ -1038,12 +1047,12 @@ V 28
(r15) Merge right to trunk 1
K 10
svn:author
-V 4
-samv
+V 3
+adm
K 8
svn:date
V 27
-2009-12-19T16:17:58.368520Z
+2010-01-19T04:14:26.054456Z
PROPS-END
Node-path: trunk
@@ -1061,8 +1070,8 @@ PROPS-END
Revision-number: 16
-Prop-content-length: 119
-Content-length: 119
+Prop-content-length: 118
+Content-length: 118
K 7
svn:log
@@ -1070,12 +1079,12 @@ V 20
(r16) right update 3
K 10
svn:author
-V 4
-samv
+V 3
+adm
K 8
svn:date
V 27
-2009-12-19T16:17:58.779056Z
+2010-01-19T04:14:27.049955Z
PROPS-END
Node-path: branches/right/urkkk
@@ -1092,8 +1101,8 @@ whamm
Revision-number: 17
-Prop-content-length: 119
-Content-length: 119
+Prop-content-length: 118
+Content-length: 118
K 7
svn:log
@@ -1101,12 +1110,12 @@ V 20
(r17) trunk update 1
K 10
svn:author
-V 4
-samv
+V 3
+adm
K 8
svn:date
V 27
-2009-12-19T16:17:59.221851Z
+2010-01-19T04:14:28.049615Z
PROPS-END
Node-path: trunk/vronk
@@ -1123,8 +1132,8 @@ pow
Revision-number: 18
-Prop-content-length: 135
-Content-length: 135
+Prop-content-length: 134
+Content-length: 134
K 7
svn:log
@@ -1132,12 +1141,12 @@ V 36
(r18) Merge right to left sub-branch
K 10
svn:author
-V 4
-samv
+V 3
+adm
K 8
svn:date
V 27
-2009-12-19T16:17:59.781666Z
+2010-01-19T04:14:31.061460Z
PROPS-END
Node-path: branches/left-sub
@@ -1262,8 +1271,8 @@ Text-copy-source-sha1: 3934264d277a0cf886b6b1c7f2b9e56da2525302
Revision-number: 19
-Prop-content-length: 129
-Content-length: 129
+Prop-content-length: 128
+Content-length: 128
K 7
svn:log
@@ -1271,12 +1280,12 @@ V 30
(r19) left sub-branch update 2
K 10
svn:author
-V 4
-samv
+V 3
+adm
K 8
svn:date
V 27
-2009-12-19T16:18:00.200531Z
+2010-01-19T04:14:32.049244Z
PROPS-END
Node-path: branches/left-sub/wham_eth
@@ -1293,8 +1302,8 @@ zowie
Revision-number: 20
-Prop-content-length: 118
-Content-length: 118
+Prop-content-length: 117
+Content-length: 117
K 7
svn:log
@@ -1302,12 +1311,12 @@ V 19
(r20) left update 5
K 10
svn:author
-V 4
-samv
+V 3
+adm
K 8
svn:date
V 27
-2009-12-19T16:18:00.659636Z
+2010-01-19T04:14:33.049332Z
PROPS-END
Node-path: branches/left/glurpp
@@ -1324,8 +1333,8 @@ eee_yow
Revision-number: 21
-Prop-content-length: 147
-Content-length: 147
+Prop-content-length: 146
+Content-length: 146
K 7
svn:log
@@ -1333,12 +1342,12 @@ V 48
(r21) Cherry-pick left sub-branch commit to left
K 10
svn:author
-V 4
-samv
+V 3
+adm
K 8
svn:date
V 27
-2009-12-19T16:18:01.194402Z
+2010-01-19T04:14:36.041839Z
PROPS-END
Node-path: branches/left
@@ -1364,8 +1373,8 @@ Text-copy-source-sha1: b165019b005c199237ba822c4404e771e93b654a
Revision-number: 22
-Prop-content-length: 134
-Content-length: 134
+Prop-content-length: 133
+Content-length: 133
K 7
svn:log
@@ -1373,12 +1382,12 @@ V 35
(r22) Merge left sub-branch to left
K 10
svn:author
-V 4
-samv
+V 3
+adm
K 8
svn:date
V 27
-2009-12-19T16:18:01.679218Z
+2010-01-19T04:14:39.045014Z
PROPS-END
Node-path: branches/left
@@ -1513,8 +1522,8 @@ Text-copy-source-sha1: 3934264d277a0cf886b6b1c7f2b9e56da2525302
Revision-number: 23
-Prop-content-length: 126
-Content-length: 126
+Prop-content-length: 125
+Content-length: 125
K 7
svn:log
@@ -1522,12 +1531,12 @@ V 27
(r23) Merge left to trunk 2
K 10
svn:author
-V 4
-samv
+V 3
+adm
K 8
svn:date
V 27
-2009-12-19T16:18:02.212349Z
+2010-01-19T04:14:42.052798Z
PROPS-END
Node-path: trunk
@@ -1591,8 +1600,8 @@ Text-copy-source-sha1: 9716527ebd70a75c27625cacbeb2d897c6e86178
Revision-number: 24
-Prop-content-length: 131
-Content-length: 131
+Prop-content-length: 130
+Content-length: 130
K 7
svn:log
@@ -1600,12 +1609,12 @@ V 32
(r24) non-merge right to trunk 2
K 10
svn:author
-V 4
-samv
+V 3
+adm
K 8
svn:date
V 27
-2009-12-19T16:18:02.672148Z
+2010-01-19T04:14:44.038434Z
PROPS-END
Node-path: trunk
@@ -1623,3 +1632,291 @@ V 64
PROPS-END
+Revision-number: 25
+Prop-content-length: 135
+Content-length: 135
+
+K 7
+svn:log
+V 37
+(r25) add subdirectory to left branch
+K 10
+svn:author
+V 3
+adm
+K 8
+svn:date
+V 27
+2010-01-19T04:14:46.052649Z
+PROPS-END
+
+Node-path: branches/left/subdir
+Node-kind: dir
+Node-action: add
+Prop-content-length: 10
+Content-length: 10
+
+PROPS-END
+
+
+Node-path: branches/left/subdir/cowboy
+Node-kind: file
+Node-action: add
+Prop-content-length: 10
+Text-content-length: 7
+Text-content-md5: f1d6530278ad409e68cc675476ad995f
+Text-content-sha1: 732d9e3e5c391ffd767a98b45ddcc848de778cea
+Content-length: 17
+
+PROPS-END
+Yeehaw
+
+
+Revision-number: 26
+Prop-content-length: 123
+Content-length: 123
+
+K 7
+svn:log
+V 25
+(r26) merge left to trunk
+K 10
+svn:author
+V 3
+adm
+K 8
+svn:date
+V 27
+2010-01-19T04:14:49.040783Z
+PROPS-END
+
+Node-path: trunk
+Node-kind: dir
+Node-action: change
+Prop-content-length: 99
+Content-length: 99
+
+K 13
+svn:mergeinfo
+V 64
+/branches/left:2-25
+/branches/left-sub:4-19
+/branches/right:2-22
+PROPS-END
+
+
+Node-path: trunk/subdir
+Node-kind: dir
+Node-action: add
+Node-copyfrom-rev: 25
+Node-copyfrom-path: branches/left/subdir
+
+
+Revision-number: 27
+Prop-content-length: 118
+Content-length: 118
+
+K 7
+svn:log
+V 20
+(r28) partial update
+K 10
+svn:author
+V 3
+adm
+K 8
+svn:date
+V 27
+2010-01-19T04:14:53.049037Z
+PROPS-END
+
+Node-path: branches/partial
+Node-kind: dir
+Node-action: add
+Node-copyfrom-rev: 26
+Node-copyfrom-path: trunk/subdir
+
+
+Node-path: branches/partial/palindromes
+Node-kind: file
+Node-action: add
+Prop-content-length: 10
+Text-content-length: 8
+Text-content-md5: 5d1c2024fb5efc4eef812856df1b080c
+Text-content-sha1: 5f8509ddd14c91a52864dd1447344e706f9bbc69
+Content-length: 18
+
+PROPS-END
+racecar
+
+
+Revision-number: 28
+Prop-content-length: 126
+Content-length: 126
+
+K 7
+svn:log
+V 28
+(r29) merge partial to trunk
+K 10
+svn:author
+V 3
+adm
+K 8
+svn:date
+V 27
+2010-01-19T04:14:56.041526Z
+PROPS-END
+
+Node-path: trunk/subdir
+Node-kind: dir
+Node-action: change
+Prop-content-length: 142
+Content-length: 142
+
+K 13
+svn:mergeinfo
+V 106
+/branches/left/subdir:2-25
+/branches/left-sub/subdir:4-19
+/branches/partial:27
+/branches/right/subdir:2-22
+PROPS-END
+
+
+Node-path: trunk/subdir/palindromes
+Node-kind: file
+Node-action: add
+Node-copyfrom-rev: 27
+Node-copyfrom-path: branches/partial/palindromes
+Text-copy-source-md5: 5d1c2024fb5efc4eef812856df1b080c
+Text-copy-source-sha1: 5f8509ddd14c91a52864dd1447344e706f9bbc69
+
+
+Revision-number: 29
+Prop-content-length: 131
+Content-length: 131
+
+K 7
+svn:log
+V 33
+(r31) make bugfix branch from tag
+K 10
+svn:author
+V 3
+adm
+K 8
+svn:date
+V 27
+2010-01-19T04:15:00.039761Z
+PROPS-END
+
+Node-path: tags/v1.0
+Node-kind: dir
+Node-action: add
+Node-copyfrom-rev: 28
+Node-copyfrom-path: trunk
+
+
+Revision-number: 30
+Prop-content-length: 120
+Content-length: 120
+
+K 7
+svn:log
+V 22
+(r32) commit to bugfix
+K 10
+svn:author
+V 3
+adm
+K 8
+svn:date
+V 27
+2010-01-19T04:15:03.043218Z
+PROPS-END
+
+Node-path: branches/bugfix
+Node-kind: dir
+Node-action: add
+Node-copyfrom-rev: 29
+Node-copyfrom-path: tags/v1.0
+
+
+Node-path: branches/bugfix/subdir/palindromes
+Node-kind: file
+Node-action: change
+Text-content-length: 14
+Text-content-md5: 3b12d98578a3f4320ba97e66da54fe5f
+Text-content-sha1: 672931c9e8ac2c408209efab2f015638b6d64042
+Content-length: 14
+
+racecar
+kayak
+
+
+Revision-number: 31
+Prop-content-length: 125
+Content-length: 125
+
+K 7
+svn:log
+V 27
+(r33) Merge BUGFIX to TRUNK
+K 10
+svn:author
+V 3
+adm
+K 8
+svn:date
+V 27
+2010-01-19T04:15:06.043723Z
+PROPS-END
+
+Node-path: trunk
+Node-kind: dir
+Node-action: change
+Prop-content-length: 133
+Content-length: 133
+
+K 13
+svn:mergeinfo
+V 98
+/branches/bugfix:30
+/branches/left:2-25
+/branches/left-sub:4-19
+/branches/right:2-22
+/tags/v1.0:29
+PROPS-END
+
+
+Node-path: trunk/subdir
+Node-kind: dir
+Node-action: change
+Prop-content-length: 190
+Content-length: 190
+
+K 13
+svn:mergeinfo
+V 154
+/branches/bugfix/subdir:30
+/branches/left/subdir:2-25
+/branches/left-sub/subdir:4-19
+/branches/partial:27
+/branches/right/subdir:2-22
+/tags/v1.0/subdir:29
+PROPS-END
+
+
+Node-path: trunk/subdir/palindromes
+Node-kind: file
+Node-action: change
+Text-content-length: 14
+Text-content-md5: 3b12d98578a3f4320ba97e66da54fe5f
+Text-content-sha1: 672931c9e8ac2c408209efab2f015638b6d64042
+Content-length: 14
+
+racecar
+kayak
+
+
--
1.6.6.2.g1fc48.dirty
^ permalink raw reply related
* Re: [RFC] Git Wiki Move
From: Petr Baudis @ 2010-01-21 21:35 UTC (permalink / raw)
To: J.H.; +Cc: Johannes Schindelin, Matthieu Moy, git
In-Reply-To: <4B54ACBD.6000000@eaglescrag.net>
On Mon, Jan 18, 2010 at 10:47:25AM -0800, J.H. wrote:
> On 01/18/2010 04:03 AM, Johannes Schindelin wrote:
> > - add a link from the old Wiki (with rewrite rules)
>
> I think the rewrites should be simple enough (the pages seem to line up
> 1:1 easily enough) so all I would need to do is discuss this with Petr.
repo.or.cz migration to new server is now finished and on the new
system, I chose to not even install moinwiki at all. Instead, I've
installed a rewrite rule so all http://git.or.cz/gitwiki/ accesses are
sent to the appropriate place of http://git.wiki.kernel.org/ - thus,
that's the master copy of git wiki now. :-) Thanks a lot for stepping up
to do this, J.H.!
--
Petr "Pasky" Baudis
A lot of people have my books on their bookshelves.
That's the problem, they need to read them. -- Don Knuth
^ permalink raw reply
* [PATCH 1/1] git-rebase.txt: Fix spelling
From: Horst H. von Brand @ 2010-01-21 20:34 UTC (permalink / raw)
To: git; +Cc: gitster, Horst H. von Brand
Signed-off-by: Horst H. von Brand <vonbrand@inf.utfsm.cl>
---
Documentation/git-rebase.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
index 89a957e..823f2a4 100644
--- a/Documentation/git-rebase.txt
+++ b/Documentation/git-rebase.txt
@@ -312,7 +312,7 @@ which makes little sense.
When the commit log message begins with "squash! ..." (or
"fixup! ..."), and there is a commit whose title begins with
the same ..., automatically modify the todo list of rebase -i
- so that the commit marked for quashing come right after the
+ so that the commit marked for squashing comes right after the
commit to be modified, and change the action of the moved
commit from `pick` to `squash` (or `fixup`).
+
--
1.6.6.1.383.g5a9f
^ permalink raw reply related
* Re: Remove diff machinery dependency from read-cache
From: Linus Torvalds @ 2010-01-21 20:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vljfrp6g2.fsf@alter.siamese.dyndns.org>
On Thu, 21 Jan 2010, Junio C Hamano wrote:
>
> The patch itself to move add_files_to_cache() to builtin-add.c (or to its
> own file) makes sense from the code placement POV, but if the goal is to
> shrink the on-disk footprint, isn't an alternative approach be to make
> hash-object built-in? You can lose the whole 1.7M from the filesystem
> footprint that way, no?
Sure. Except, as I mentioned, it's not just git-hash-object. It's _all_ of
them.
The total space savings wasn't 1.7M, it was 12M.
Linus
^ permalink raw reply
* Re: [PATCH] post-receive-email: allow customizing of subject/intro/footer
From: Junio C Hamano @ 2010-01-21 20:09 UTC (permalink / raw)
To: Mike Frysinger; +Cc: Marc Branchaud, git
In-Reply-To: <201001211259.30704.vapier@gentoo.org>
Mike Frysinger <vapier@gentoo.org> writes:
>> So, overall, why not make generate_email_header() be simply:
>>
>> generate_email_header()
>> {
>> # --- Email (all stdout will be the email)
>> # Generate header
>> subst_vars <<-EOF
>> To: $recipients
>> Subject: ${emailprefix}${emailsubject}
>> X-Git-Refname: @refname@
>> X-Git-Reftype: @refname_type@
>> X-Git-Oldrev: @oldrev@
>> X-Git-Newrev: @newrev@
>>
>> ${emailbodyintro}
>>
>> EOF
>> }
>>
>> This would also let you simply subst_vars() so that it needn't support
>> piped invocations, no? (Not a very drastic simplification, but still...)
>
> if emailbodyintro is empty, this adds two useless newlines. otherwise, this
> would be fine i think.
I haven't looked at the original that is being improved upon (because I am
not very interested in this sample script myself), but I have two comments
on the above.
- You can do something like this to fix that "empty line" issue, no?
LF='
' ;# newline
subst_vars <<-EOF
...
${emailbodyintro:+"$emailbodyinto$LF"}
EOF
- If you are using shell variable interpolation anyway, why do you still
need @special_name@ interpolated with perl or sed or whatever you are
using in subst_vars (which I didn't look at)? If you have $refname,
$refname_type and friends, can't the above become "cat <<-EOF"?
^ permalink raw reply
* Re: [PATCH 2/2] rev-parse --branches/--tags/--remotes=pattern
From: Junio C Hamano @ 2010-01-21 20:09 UTC (permalink / raw)
To: Thomas Rast
Cc: Michael J Gruber, Ilari Liusvaara, Johannes Sixt, git,
Junio C Hamano
In-Reply-To: <201001211827.05847.trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
> Maybe the --branches, --tags and --remotes could be consolidated a
> bit, as in the draft patch below.
Looks sensible.
> diff --git i/Documentation/git-rev-parse.txt w/Documentation/git-rev-parse.txt
> index 2bbb566..6fce919 100644
> --- i/Documentation/git-rev-parse.txt
> +++ w/Documentation/git-rev-parse.txt
> @@ -104,29 +104,26 @@ OPTIONS
> Show all refs found in `$GIT_DIR/refs`.
>
> --branches[=pattern]::
> - Show branch refs found in `$GIT_DIR/refs/heads`. If `pattern`
> - is given, only branches matching given shell glob are shown.
> - If pattern lacks '?', '*', or '[', '/*' at the end is impiled.
> -
> --tags[=pattern]::
> - Show tag refs found in `$GIT_DIR/refs/tags`. If `pattern`
> - is given, only tags matching given shell glob are shown.
> - If pattern lacks '?', '*', or '[', '/*' at the end is impiled.
> -
> --remotes[=pattern]::
> - Show tag refs found in `$GIT_DIR/refs/remotes`. If `pattern`
> - is given, only remote tracking branches matching given shell glob
> - are shown. If pattern lacks '?', '*', or '[', '/*' at the end is
> - impiled.
> + Show all branches, tags, or remote-tracking branches,
> + respectively (i.e., refs found in `$GIT_DIR/refs/heads`,
> + `$GIT_DIR/refs/tags`, or `$GIT_DIR/refs/remotes`,
> + respectively).
> ++
> +If a `pattern` is given, only refs matching the given shell glob are
> +shown. If the pattern does not contain a globbing character (`?`,
> +`\*`, or `[`), it is anchored by appending `/\*`.
> +
> +--glob=pattern::
> + Show all refs matching the shell glob pattern `pattern`. If
> + the pattern does not start with `refs/`, this is automatically
> + prepended. If the pattern does not contain a globbing
> + character (`?`, `\*`, or `[`), it is anchored by appending `/\*`.
>
> --show-toplevel::
> Show the absolute path of the top-level directory.
>
> ---glob=glob-pattern::
> - Show refs matching shell glob pattern `glob-pattern`. If pattern
> - specified lacks leading 'refs/', it is automatically prepended.
> - If pattern lacks '?', '*', or '[', '/*' at the end is impiled.
> -
> --show-prefix::
> When the command is invoked from a subdirectory, show the
> path of the current directory relative to the top-level
>
>
> --
> Thomas Rast
> trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: Remove diff machinery dependency from read-cache
From: Junio C Hamano @ 2010-01-21 20:07 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <alpine.LFD.2.00.1001211119130.13231@localhost.localdomain>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> This trivial cleanup results in pretty stunning file size differences.
> The diff machinery really is mostly used by just the builtin programs, and
> you have things like these trivial before-and-after numbers:
>
> -rwxr-xr-x 1 torvalds torvalds 1727420 2010-01-21 10:53 git-hash-object
> -rwxrwxr-x 1 torvalds torvalds 940265 2010-01-21 11:16 git-hash-object
>
> Now, I'm not saying that 940kB is good either, but that's mostly all the
> debug information - you can see the real code with 'size':
>
> text data bss dec hex filename
> 418675 3920 127408 550003 86473 git-hash-object (before)
> 230650 2288 111728 344666 5425a git-hash-object (after)
>
> ie we have a nice 24% size reduction from this trivial cleanup.
The patch itself to move add_files_to_cache() to builtin-add.c (or to its
own file) makes sense from the code placement POV, but if the goal is to
shrink the on-disk footprint, isn't an alternative approach be to make
hash-object built-in? You can lose the whole 1.7M from the filesystem
footprint that way, no?
^ permalink raw reply
* Re: [PATCHv11 20/20] builtin-gc: Teach the new --notes option to garbage-collect notes
From: Junio C Hamano @ 2010-01-21 20:01 UTC (permalink / raw)
To: Johan Herland; +Cc: Stephen Boyd, git
In-Reply-To: <780e0a6b1001211127u6304546ej4e5bffbceca12e0b@mail.gmail.com>
Stephen Boyd <bebarino@gmail.com> writes:
> On Sun, Jan 17, 2010 at 1:04 PM, Johan Herland <johan@herland.net> wrote:
>> The new --notes option triggers a call to gc_notes(), which removes note
>> objects that reference non-existing objects.
>>
>
> Shouldn't notes be unconditionally garbage collected? Or maybe there's
> a reason why notes should be treated differently that isn't written
> here.
A few thoughts, inspired by this patch, but on other things around
"notes":
- This is more about pruning notes regarding objects that are no longer
availabe from _the tip_ of the notes tree. It doesn't run (and I am
not suggesting to make it it to run) filter-branch to eradicate all
such stale notes from the notes commit ancestry, so in that sense this
is not really a garbage collection.
- We would want to have "notes prune" subcommand that lets us do the
pruning without all the other "gc" operation. "git gc" would of course
call the same underlying code "notes prune" would use if we want to
be able to trigger "notes prune" from it.
- Because there is no public interface to list objects that are annotated
with the most recent notes tree, the only thing this pruning affects is
the look-up overhead of "log --show-notes". As such, it might be
better to later add tree rebalancing in "notes prune" and at that
point, it will become even less about garbage collection and more about
performance ("notes optimize?").
- Do we want to have a public interface to list objects that are
annotated with notes? "git notes" probably deserves a bit more
subcommands other than "(edit|show)" to help users, e.g. "list" and
"remove".
- If this were "notes optimize" (this is just me thinking aloud), perhaps
we would want to do this at some key places (e.g. when you
automatically rebalance the tree).
^ permalink raw reply
* Remove diff machinery dependency from read-cache
From: Linus Torvalds @ 2010-01-21 19:37 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List
Exal Sibeaz pointed out that some git files are way too big, and that
add_files_to_cache() brings in all the diff machinery to any git binary
that needs the basic git SHA1 object operations from read-cache.c. Which
is pretty much all of them.
It's doubly silly, since add_files_to_cache() is only used by builtin
programs (add, checkout and commit), so it's fairly easily fixed by just
moving the thing to builtin-add.c, and avoiding the dependency entirely.
I initially argued to Exal that it would probably be best to try to depend
on smart compilers and linkers, but after spending some time trying to
make -ffunction-sections work and giving up, I think Exal was right, and
the fix is to just do some trivial cleanups like this.
This trivial cleanup results in pretty stunning file size differences.
The diff machinery really is mostly used by just the builtin programs, and
you have things like these trivial before-and-after numbers:
-rwxr-xr-x 1 torvalds torvalds 1727420 2010-01-21 10:53 git-hash-object
-rwxrwxr-x 1 torvalds torvalds 940265 2010-01-21 11:16 git-hash-object
Now, I'm not saying that 940kB is good either, but that's mostly all the
debug information - you can see the real code with 'size':
text data bss dec hex filename
418675 3920 127408 550003 86473 git-hash-object (before)
230650 2288 111728 344666 5425a git-hash-object (after)
ie we have a nice 24% size reduction from this trivial cleanup.
It's not just that one file either. I get:
[torvalds@nehalem git]$ du -s /home/torvalds/libexec/git-core
45640 /home/torvalds/libexec/git-core (before)
33508 /home/torvalds/libexec/git-core (after)
so we're talking 12MB of diskspace here.
(Of course, stripping all the binaries brings the 33MB down to 9MB, so the
whole debug information thing is still the bulk of it all, but that's a
separate issue entirely)
Now, I'm sure there are other things we should do, and changing our
compiler flags from -O2 to -Os would bring the text size down by an
additional almost 20%, but this thing Exal pointed out seems to be some
good low-hanging fruit.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
---
builtin-add.c | 76 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
read-cache.c | 78 ---------------------------------------------------------
2 files changed, 76 insertions(+), 78 deletions(-)
diff --git a/builtin-add.c b/builtin-add.c
index cb6e590..2705f8d 100644
--- a/builtin-add.c
+++ b/builtin-add.c
@@ -11,6 +11,7 @@
#include "run-command.h"
#include "parse-options.h"
#include "diff.h"
+#include "diffcore.h"
#include "revision.h"
static const char * const builtin_add_usage[] = {
@@ -20,6 +21,81 @@ static const char * const builtin_add_usage[] = {
static int patch_interactive, add_interactive, edit_interactive;
static int take_worktree_changes;
+struct update_callback_data
+{
+ int flags;
+ int add_errors;
+};
+
+static void update_callback(struct diff_queue_struct *q,
+ struct diff_options *opt, void *cbdata)
+{
+ int i;
+ struct update_callback_data *data = cbdata;
+
+ for (i = 0; i < q->nr; i++) {
+ struct diff_filepair *p = q->queue[i];
+ const char *path = p->one->path;
+ switch (p->status) {
+ default:
+ die("unexpected diff status %c", p->status);
+ case DIFF_STATUS_UNMERGED:
+ /*
+ * ADD_CACHE_IGNORE_REMOVAL is unset if "git
+ * add -u" is calling us, In such a case, a
+ * missing work tree file needs to be removed
+ * if there is an unmerged entry at stage #2,
+ * but such a diff record is followed by
+ * another with DIFF_STATUS_DELETED (and if
+ * there is no stage #2, we won't see DELETED
+ * nor MODIFIED). We can simply continue
+ * either way.
+ */
+ if (!(data->flags & ADD_CACHE_IGNORE_REMOVAL))
+ continue;
+ /*
+ * Otherwise, it is "git add path" is asking
+ * to explicitly add it; we fall through. A
+ * missing work tree file is an error and is
+ * caught by add_file_to_index() in such a
+ * case.
+ */
+ case DIFF_STATUS_MODIFIED:
+ case DIFF_STATUS_TYPE_CHANGED:
+ if (add_file_to_index(&the_index, path, data->flags)) {
+ if (!(data->flags & ADD_CACHE_IGNORE_ERRORS))
+ die("updating files failed");
+ data->add_errors++;
+ }
+ break;
+ case DIFF_STATUS_DELETED:
+ if (data->flags & ADD_CACHE_IGNORE_REMOVAL)
+ break;
+ if (!(data->flags & ADD_CACHE_PRETEND))
+ remove_file_from_index(&the_index, path);
+ if (data->flags & (ADD_CACHE_PRETEND|ADD_CACHE_VERBOSE))
+ printf("remove '%s'\n", path);
+ break;
+ }
+ }
+}
+
+int add_files_to_cache(const char *prefix, const char **pathspec, int flags)
+{
+ struct update_callback_data data;
+ struct rev_info rev;
+ init_revisions(&rev, prefix);
+ setup_revisions(0, NULL, &rev, NULL);
+ rev.prune_data = pathspec;
+ rev.diffopt.output_format = DIFF_FORMAT_CALLBACK;
+ rev.diffopt.format_callback = update_callback;
+ data.flags = flags;
+ data.add_errors = 0;
+ rev.diffopt.format_callback_data = &data;
+ run_diff_files(&rev, DIFF_RACY_IS_MODIFIED);
+ return !!data.add_errors;
+}
+
static void fill_pathspec_matches(const char **pathspec, char *seen, int specs)
{
int num_unmatched = 0, i;
diff --git a/read-cache.c b/read-cache.c
index edd9959..79938bf 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -10,9 +10,6 @@
#include "dir.h"
#include "tree.h"
#include "commit.h"
-#include "diff.h"
-#include "diffcore.h"
-#include "revision.h"
#include "blob.h"
#include "resolve-undo.h"
@@ -1648,81 +1645,6 @@ int read_index_unmerged(struct index_state *istate)
return unmerged;
}
-struct update_callback_data
-{
- int flags;
- int add_errors;
-};
-
-static void update_callback(struct diff_queue_struct *q,
- struct diff_options *opt, void *cbdata)
-{
- int i;
- struct update_callback_data *data = cbdata;
-
- for (i = 0; i < q->nr; i++) {
- struct diff_filepair *p = q->queue[i];
- const char *path = p->one->path;
- switch (p->status) {
- default:
- die("unexpected diff status %c", p->status);
- case DIFF_STATUS_UNMERGED:
- /*
- * ADD_CACHE_IGNORE_REMOVAL is unset if "git
- * add -u" is calling us, In such a case, a
- * missing work tree file needs to be removed
- * if there is an unmerged entry at stage #2,
- * but such a diff record is followed by
- * another with DIFF_STATUS_DELETED (and if
- * there is no stage #2, we won't see DELETED
- * nor MODIFIED). We can simply continue
- * either way.
- */
- if (!(data->flags & ADD_CACHE_IGNORE_REMOVAL))
- continue;
- /*
- * Otherwise, it is "git add path" is asking
- * to explicitly add it; we fall through. A
- * missing work tree file is an error and is
- * caught by add_file_to_index() in such a
- * case.
- */
- case DIFF_STATUS_MODIFIED:
- case DIFF_STATUS_TYPE_CHANGED:
- if (add_file_to_index(&the_index, path, data->flags)) {
- if (!(data->flags & ADD_CACHE_IGNORE_ERRORS))
- die("updating files failed");
- data->add_errors++;
- }
- break;
- case DIFF_STATUS_DELETED:
- if (data->flags & ADD_CACHE_IGNORE_REMOVAL)
- break;
- if (!(data->flags & ADD_CACHE_PRETEND))
- remove_file_from_index(&the_index, path);
- if (data->flags & (ADD_CACHE_PRETEND|ADD_CACHE_VERBOSE))
- printf("remove '%s'\n", path);
- break;
- }
- }
-}
-
-int add_files_to_cache(const char *prefix, const char **pathspec, int flags)
-{
- struct update_callback_data data;
- struct rev_info rev;
- init_revisions(&rev, prefix);
- setup_revisions(0, NULL, &rev, NULL);
- rev.prune_data = pathspec;
- rev.diffopt.output_format = DIFF_FORMAT_CALLBACK;
- rev.diffopt.format_callback = update_callback;
- data.flags = flags;
- data.add_errors = 0;
- rev.diffopt.format_callback_data = &data;
- run_diff_files(&rev, DIFF_RACY_IS_MODIFIED);
- return !!data.add_errors;
-}
-
/*
* Returns 1 if the path is an "other" path with respect to
* the index; that is, the path is not mentioned in the index at all,
^ permalink raw reply related
* Re: [PATCHv11 20/20] builtin-gc: Teach the new --notes option to garbage-collect notes
From: Stephen Boyd @ 2010-01-21 19:27 UTC (permalink / raw)
To: Johan Herland; +Cc: gitster, git
In-Reply-To: <1263762277-31419-21-git-send-email-johan@herland.net>
On Sun, Jan 17, 2010 at 1:04 PM, Johan Herland <johan@herland.net> wrote:
> The new --notes option triggers a call to gc_notes(), which removes note
> objects that reference non-existing objects.
>
Shouldn't notes be unconditionally garbage collected? Or maybe there's
a reason why notes should be treated differently that isn't written
here.
^ permalink raw reply
* Re: [PATCHv2] am: fix patch format detection for Thunderbird "Save As" emails
From: Stephen Boyd @ 2010-01-21 18:51 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Junio C Hamano, git
In-Reply-To: <20100106073822.6117@nanako3.lavabit.com>
On Tue, Jan 5, 2010 at 2:38 PM, Nanako Shiraishi <nanako3@lavabit.com> wrote:
> Junio, could you tell us what happened to this thread?
>
> After a lengthy discussion, nothing happened.
>
Sorry. I lost interest during the holidays and then went on a vacation
after. I've returned and will try and get back to it this weekend.
^ 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