* Help with setting up git server
From: git815 @ 2011-12-04 13:22 UTC (permalink / raw)
To: git
After what I thought I have set up a git server under http, I'm getting this
error on client site whenever I issue a git command: "fatal: Not a git
repository (or any of the parent directories): .git".
Here is what I did:
(1) In project directory, clone a git project: "git clone --bare proj.git"
( I noticed no .git subdirectory exists in the cloned directory).
(2) Move the cloned directory proj.git under web server path.
(3) On a separate client machine, clone a local copy of the project: "git
clone http://git-server/proj.git" (This command runs and gives me the actual
source code files and nothing else. The cloned proj.git directories
contains git files and directories).
I'm new and I must have missed something. Can anyone help? Thanks.
--
View this message in context: http://git.661346.n2.nabble.com/Help-with-setting-up-git-server-tp7060154p7060154.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH 2/2] builtin/apply.c: report error on failure to recognize input
From: Artem Bityutskiy @ 2011-12-04 13:30 UTC (permalink / raw)
To: Brandon Casey; +Cc: git
In-Reply-To: <1322944550-27344-2-git-send-email-drafnel@gmail.com>
On Sat, 2011-12-03 at 14:35 -0600, Brandon Casey wrote:
> When git apply is passed something that is not a patch, it does not produce
> an error message or exit with a non-zero status if it was not actually
> "applying" the patch i.e. --check or --numstat etc were supplied on the
> command line.
>
> Fix this by producing an error when apply fails to find any hunks whatsoever
> while parsing the patch.
>
> This will cause some of the output formats (--numstat, --diffstat, etc) to
> produce an error when they formerly would have reported zero changes and
> exited successfully. That seems like the correct behavior though. Failure
> to recognize the input as a patch should be an error.
>
> Plus, add a test.
>
> Reported-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
> Signed-off-by: Brandon Casey <drafnel@gmail.com>
Brandon, Thanks a lot for picking this. I did not reply because I did
not have time to look at this after your review yet, it was in my TODO
list. But I am happy you picked this and fixed the issue.
Tested-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
--
Best Regards,
Artem Bityutskiy
^ permalink raw reply
* Re: Debugging git-commit slowness on a large repo
From: Tomas Carnecky @ 2011-12-04 13:54 UTC (permalink / raw)
To: Joshua Redstone; +Cc: git@vger.kernel.org
In-Reply-To: <CAFE9C7B.2BFEC%joshua.redstone@fb.com>
On 12/3/11 12:17 AM, Joshua Redstone wrote:
> Hi,
> I have a git repo with about 300k commits, 150k files totaling maybe 7GB.
> Locally committing a small change - say touching fewer than 300 bytes
> across 4 files - consistently takes over one second, which seems kinda
> slow. This is using git 1.7.7.4 on a linux 2.6 box. The time does not
> improve after doing a git-gc (my .git dir has maybe 250 files after a git
> gc). The same size commit on a brand new repo takes< 10ms. Any thoughts
> on why committing a small change seems to take a long time on larger repos?
>
> Fwiw, I also tried doing the same test using libgit2 (via the pygit2
> wrapper), and it was ever slower (about 6 seconds to commit the same small
> change).
try git commit --no-status
^ permalink raw reply
* Re: [PATCH 2/2] builtin/apply.c: report error on failure to recognize input
From: Brandon Casey @ 2011-12-04 15:39 UTC (permalink / raw)
To: artem.bityutskiy; +Cc: git
In-Reply-To: <1323005418.9400.49.camel@sauron.fi.intel.com>
Artem Bityutskiy <artem.bityutskiy@linux.intel.com> wrote:
>Brandon, Thanks a lot for picking this. I did not reply because I did
>not have time to look at this after your review yet, it was in my TODO
>list. But I am happy you picked this and fixed the issue.
No problem.
>Tested-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Thanks.
-Brandon
^ permalink raw reply
* Re: [PATCHv2 0/4] git-p4: small fixes to branches and labels; tests
From: Pete Wyckoff @ 2011-12-04 16:07 UTC (permalink / raw)
To: Vitor Antunes; +Cc: Luke Diamand, git
In-Reply-To: <CAOpHH-U6NxRSioRZg9_+f146vVR+S1hWsVbRmHz+vsqtz+vXiA@mail.gmail.com>
vitor.hda@gmail.com wrote on Thu, 01 Dec 2011 00:37 +0000:
> On Wed, Nov 30, 2011 at 11:00 PM, Pete Wyckoff <pw@padd.com> wrote:
> > And avoids collision with some Vitor code that will get
> > added eventually.
>
> I'm starting to doubt I will ever be able to overcome the fast-import
> limitation on not allowing branch delesetion. Sure, the code I wrote was
> garbage! But they seem to be very relunctant on the concept of deleting
> branches on the fly.
> Did you ever take a look at the patch I sent? Maybe you could help me
> shape it up a bit.
I don't think we necessarily need branch deletion inside the
fast-import. Can you go back and look at my mail from August and
see if that approach is doable? Just make a single commit on a
throwaway branch with no parent, checkpoint, then do diff-tree
for each potential parent until you find a match. Do the commit
for real where it goes. As git-p4 exits, we'll delete the branch
ref of the test commit.
If this works, we can see if fast-import can be taught to
generate a tree object without a commit to save the need for a
temporary branch.
-- Pete
^ permalink raw reply
* [RFD] Handling of non-UTF8 data in gitweb
From: Jakub Narebski @ 2011-12-04 16:09 UTC (permalink / raw)
To: git; +Cc: Jürgen Kreileder, John Hawley
Hello!
Currently gitweb converts data it receives from git commands to Perl
internal utf8 representation via to_utf8() subroutine
# decode sequences of octets in utf8 into Perl's internal form,
# which is utf-8 with utf8 flag set if needed. gitweb writes out
# in utf-8 thanks to "binmode STDOUT, ':utf8'" at beginning
sub to_utf8 {
my $str = shift;
return undef unless defined $str;
if (utf8::valid($str)) {
utf8::decode($str);
return $str;
} else {
return decode($fallback_encoding, $str, Encode::FB_DEFAULT);
}
}
Each part of data must be handled separately. It is quite error prone
process, as can be seen from quite a number of patches that fix handling
of UTF-8 data (latest from Jürgen).
Much, much simpler would be to force opening of all files (including
output pipes from git commands) in ':utf8' mode:
use open qw(:std :utf8);
[Note: perhaps instead of ':utf8' it should be ':encoding(UTF-8)'
there...]
But doing this would change gitweb behavior. Currently when
encountering something (usually line of output) that is not valid
UTF-8, we decode it (to UTF-8) using $fallback_encoding, by default
'latin1'. Note however that this value is per gitweb installation,
not per repository.
Using "use open qw(:std :utf8);" would be like changing the value of
$fallback_encoding to 'utf8' -- errors would be ignored, and characters
which are invalid in UTF-8 encoding would get replaced[1] with
substitution character '�' U+FFFD.
Though at least for HTML output we could use Encode::FB_HTMLCREF
handling (which would produce &#NNN;) or Encode::FB_XMLCREF (which
would produce &#xHHHH;), though this must be done after HTML escaping...
and is probaby not worth it (FYI this can be done by setting
$PerlIO::encoding::fallback to either of those values[2])
[1] http://perldoc.perl.org/Encode.html#Handling-Malformed-Data
http://p3rl.org/Encode
[2] http://perldoc.perl.org/PerlIO/encoding.html
http://p3rl.org/PerlIO::encoding
I don't know if people are relying on the old behavior. I guess
it could be emulated by defining our own 'utf-8-with-fallback'
encoding, or by defining our own PerlIO layer with PerlIO::via.
But it no longer be simple solution (though still automatic).
Alternate approach would be to audit gitweb code, and call to_utf8
before storing extracted output of git command in variable (excluding
save types like SHA-1, filemode, timestamp and timezone). The fact
that to_utf8 is idempotent and can be called multiple times would
help here, I think.
The correct solution would be of course to respect `gui.encoding`
per-repository config variable, and `encoding` gitattribute...
though the latter is hampered by the fact that there is currently
no way to read attribute with "git check-attr" from a given tree:
think of a diff of change of encoding of a file!
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [RFC PATCH] git-p4: introduce asciidoc documentation
From: Frans Klaver @ 2011-12-04 21:33 UTC (permalink / raw)
To: git, Pete Wyckoff
In-Reply-To: <20111203235328.GA3866@arf.padd.com>
> +Clone options
> +~~~~~~~~~~~~~
> +These options can used in an initial 'clone', along with the 'sync
s/can used/can be used/
Cheers,
Frans
^ permalink raw reply
* Re: [RFC PATCH] git-p4: introduce asciidoc documentation
From: Pete Wyckoff @ 2011-12-04 21:49 UTC (permalink / raw)
To: Frans Klaver; +Cc: git
In-Reply-To: <op.v5zh6udk0aolir@keputer>
fransklaver@gmail.com wrote on Sun, 04 Dec 2011 22:33 +0100:
> >+Clone options
> >+~~~~~~~~~~~~~
> >+These options can used in an initial 'clone', along with the 'sync
>
> s/can used/can be used/
Thanks for checking. I'll roll it in with the next submission.
-- Pete
^ permalink raw reply
* [bug?] checkout -m doesn't work without a base version
From: Pete Harlan @ 2011-12-04 22:31 UTC (permalink / raw)
To: git
Hi,
If during a merge I've resolved conflicts in foo.c but want to start
over with foo.c to resolve them differently, I can say "git checkout
-m foo.c" to restore it to its un-resolved state.
But this only works if there's a base version; if foo.c was added in
each branch, we get:
error: path 'foo.c' does not have all three versions
Git didn't need all three versions to create the original conflicted
file, so why would it need them to recreate it?
(The message is the same if I explicitly tell Git I don't want diff3
via "git checkout --conflict=merge foo.c".)
If this is considered a bug worth fixing I'll write a test that it
fails; if it's expected behavior I think the docs should mention
that.
Thanks,
Pete Harlan
pgit@pcharlan.com
^ permalink raw reply
* Bug: git bus error (stack blowout)
From: Venkatesh Srinivas @ 2011-12-04 22:50 UTC (permalink / raw)
To: git
Hi,
When using git 1.7.6.3 from NetBSD's pkgsrc, on this git tree:
http://gitweb.dragonflybsd.org/pkgsrcv2.git, I got a bus error when
switching from the pkgsrc-2011q3 branch to the master branch. I have a
core file and the git binary if it'd be helpful; it looks like
mark_parents_uninteresting() was called recursively entirely too many
times (>60,000), originally from prepare_revision_walk(), from
stat_tracking_info(), from format_tracking_info(),
update_revs_for_switch(), from cmd_checkout().
Thanks,
-- vs;
^ permalink raw reply
* [PATCH v2] git-p4: introduce skipSubmitEdit
From: Pete Wyckoff @ 2011-12-05 0:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Loren A. Linden Levy, Luke Diamand
Add a configuration variable to skip invoking the editor in the
submit path.
The existing variable skipSubmitEditCheck continues to make sure
that the submit template was indeed modified by the editor; but,
it is not considered if skipSubmitEdit is true.
Reported-by: Loren A. Linden Levy <lindenle@gmail.com>
Acked-by: Luke Diamand <luke@diamand.org>
Signed-off-by: Pete Wyckoff <pw@padd.com>
---
This was talked about and reviewed back in September 2011.
I think it's ready to include in the next release.
Thanks,
-- Pete
contrib/fast-import/git-p4 | 59 ++++++++++++++++++----------
contrib/fast-import/git-p4.txt | 19 ++++++++-
t/t9805-skip-submit-edit.sh | 82 ++++++++++++++++++++++++++++++++++++++++
3 files changed, 136 insertions(+), 24 deletions(-)
create mode 100755 t/t9805-skip-submit-edit.sh
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index b975d67..7fd8bf0 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -847,6 +847,38 @@ class P4Submit(Command, P4UserMap):
return template
+ def edit_template(self, template_file):
+ """Invoke the editor to let the user change the submission
+ message. Return true if okay to continue with the submit."""
+
+ # if configured to skip the editing part, just submit
+ if gitConfig("git-p4.skipSubmitEdit") == "true":
+ return True
+
+ # look at the modification time, to check later if the user saved
+ # the file
+ mtime = os.stat(template_file).st_mtime
+
+ # invoke the editor
+ if os.environ.has_key("P4EDITOR"):
+ editor = os.environ.get("P4EDITOR")
+ else:
+ editor = read_pipe("git var GIT_EDITOR").strip()
+ system(editor + " " + template_file)
+
+ # If the file was not saved, prompt to see if this patch should
+ # be skipped. But skip this verification step if configured so.
+ if gitConfig("git-p4.skipSubmitEditCheck") == "true":
+ return True
+
+ if os.stat(template_file).st_mtime <= mtime:
+ while True:
+ response = raw_input("Submit template unchanged. Submit anyway? [y]es, [n]o (skip this patch) ")
+ if response == 'y':
+ return True
+ if response == 'n':
+ return False
+
def applyCommit(self, id):
print "Applying %s" % (read_pipe("git log --max-count=1 --pretty=oneline %s" % id))
@@ -1001,7 +1033,7 @@ class P4Submit(Command, P4UserMap):
separatorLine = "######## everything below this line is just the diff #######\n"
- [handle, fileName] = tempfile.mkstemp()
+ (handle, fileName) = tempfile.mkstemp()
tmpFile = os.fdopen(handle, "w+")
if self.isWindows:
submitTemplate = submitTemplate.replace("\n", "\r\n")
@@ -1009,25 +1041,9 @@ class P4Submit(Command, P4UserMap):
newdiff = newdiff.replace("\n", "\r\n")
tmpFile.write(submitTemplate + separatorLine + diff + newdiff)
tmpFile.close()
- mtime = os.stat(fileName).st_mtime
- if os.environ.has_key("P4EDITOR"):
- editor = os.environ.get("P4EDITOR")
- else:
- editor = read_pipe("git var GIT_EDITOR").strip()
- system(editor + " " + fileName)
- if gitConfig("git-p4.skipSubmitEditCheck") == "true":
- checkModTime = False
- else:
- checkModTime = True
-
- response = "y"
- if checkModTime and (os.stat(fileName).st_mtime <= mtime):
- response = "x"
- while response != "y" and response != "n":
- response = raw_input("Submit template unchanged. Submit anyway? [y]es, [n]o (skip this patch) ")
-
- if response == "y":
+ if self.edit_template(fileName):
+ # read the edited message and submit
tmpFile = open(fileName, "rb")
message = tmpFile.read()
tmpFile.close()
@@ -1039,11 +1055,12 @@ class P4Submit(Command, P4UserMap):
if self.preserveUser:
if p4User:
# Get last changelist number. Cannot easily get it from
- # the submit command output as the output is unmarshalled.
+ # the submit command output as the output is
+ # unmarshalled.
changelist = self.lastP4Changelist()
self.modifyChangelistUser(changelist, p4User)
-
else:
+ # skip this patch
for f in editedFiles:
p4_revert(f)
for f in filesToAdd:
diff --git a/contrib/fast-import/git-p4.txt b/contrib/fast-import/git-p4.txt
index 52003ae..5044a12 100644
--- a/contrib/fast-import/git-p4.txt
+++ b/contrib/fast-import/git-p4.txt
@@ -202,11 +202,24 @@ able to find the relevant client. This client spec will be used to
both filter the files cloned by git and set the directory layout as
specified in the client (this implies --keep-path style semantics).
-git-p4.skipSubmitModTimeCheck
+git-p4.skipSubmitEdit
- git config [--global] git-p4.skipSubmitModTimeCheck false
+ git config [--global] git-p4.skipSubmitEdit false
-If true, submit will not check if the p4 change template has been modified.
+Normally, git-p4 invokes an editor after each commit is applied so
+that you can make changes to the submit message. Setting this
+variable to true will skip the editing step, submitting the change as is.
+
+git-p4.skipSubmitEditCheck
+
+ git config [--global] git-p4.skipSubmitEditCheck false
+
+After the editor is invoked, git-p4 normally makes sure you saved the
+change description, as an indication that you did indeed read it over
+and edit it. You can quit without saving to abort the submit (or skip
+this change and continue). Setting this variable to true will cause
+git-p4 not to check if you saved the change description. This variable
+only matters if git-p4.skipSubmitEdit has not been set to true.
git-p4.preserveUser
diff --git a/t/t9805-skip-submit-edit.sh b/t/t9805-skip-submit-edit.sh
new file mode 100755
index 0000000..734ccf2
--- /dev/null
+++ b/t/t9805-skip-submit-edit.sh
@@ -0,0 +1,82 @@
+#!/bin/sh
+
+test_description='git-p4 skipSubmitEdit config variables'
+
+. ./lib-git-p4.sh
+
+test_expect_success 'start p4d' '
+ start_p4d
+'
+
+test_expect_success 'init depot' '
+ (
+ cd "$cli" &&
+ echo file1 >file1 &&
+ p4 add file1 &&
+ p4 submit -d "change 1"
+ )
+'
+
+# this works because EDITOR is set to :
+test_expect_success 'no config, unedited, say yes' '
+ "$GITP4" clone --dest="$git" //depot &&
+ test_when_finished cleanup_git &&
+ (
+ cd "$git" &&
+ echo line >>file1 &&
+ git commit -a -m "change 2" &&
+ echo y | "$GITP4" submit &&
+ p4 changes //depot/... >wc &&
+ test_line_count = 2 wc
+ )
+'
+
+test_expect_success 'no config, unedited, say no' '
+ "$GITP4" clone --dest="$git" //depot &&
+ test_when_finished cleanup_git &&
+ (
+ cd "$git" &&
+ echo line >>file1 &&
+ git commit -a -m "change 3 (not really)" &&
+ printf "bad response\nn\n" | "$GITP4" submit
+ p4 changes //depot/... >wc &&
+ test_line_count = 2 wc
+ )
+'
+
+test_expect_success 'skipSubmitEdit' '
+ "$GITP4" clone --dest="$git" //depot &&
+ test_when_finished cleanup_git &&
+ (
+ cd "$git" &&
+ git config git-p4.skipSubmitEdit true &&
+ # will fail if editor is even invoked
+ git config core.editor /bin/false &&
+ echo line >>file1 &&
+ git commit -a -m "change 3" &&
+ "$GITP4" submit &&
+ p4 changes //depot/... >wc &&
+ test_line_count = 3 wc
+ )
+'
+
+test_expect_success 'skipSubmitEditCheck' '
+ "$GITP4" clone --dest="$git" //depot &&
+ test_when_finished cleanup_git &&
+ (
+ cd "$git" &&
+ git config git-p4.skipSubmitEditCheck true &&
+ echo line >>file1 &&
+ git commit -a -m "change 4" &&
+ "$GITP4" submit &&
+ p4 changes //depot/... >wc &&
+ test_line_count = 4 wc
+ )
+'
+
+
+test_expect_success 'kill p4d' '
+ kill_p4d
+'
+
+test_done
--
1.7.8.rc4.30.g3c9dc
^ permalink raw reply related
* Re: Bug: git bus error (stack blowout)
From: Nguyen Thai Ngoc Duy @ 2011-12-05 4:58 UTC (permalink / raw)
To: vsrinivas; +Cc: git
In-Reply-To: <CAAcG=3NfvYSjhHDNb8aZ=_O4661bV7jkZBpmc77ZVCFDQQdHJw@mail.gmail.com>
On Sun, Dec 04, 2011 at 05:50:19PM -0500, Venkatesh Srinivas wrote:
> Hi,
>
> When using git 1.7.6.3 from NetBSD's pkgsrc, on this git tree:
> http://gitweb.dragonflybsd.org/pkgsrcv2.git, I got a bus error when
> switching from the pkgsrc-2011q3 branch to the master branch. I have a
> core file and the git binary if it'd be helpful; it looks like
> mark_parents_uninteresting() was called recursively entirely too many
> times (>60,000), originally from prepare_revision_walk(), from
> stat_tracking_info(), from format_tracking_info(),
> update_revs_for_switch(), from cmd_checkout().
This patch may fix it for you, although it'd be interesting to
understand how you get into this (I'm still cloning pkgsrcv2.git).
-- 8< --
Subject: [PATCH] Eliminate recursion in setting/clearing marks in commit list
Recursion in a DAG is generally a bad idea because it could be very
deep. Be defensive and avoid recursion in mark_parents_uninteresting()
and clear_commit_marks().
mark_parents_uninteresting() learns a trick from clear_commit_marks()
to avoid malloc() in (dorminant) single-parent case.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
commit.c | 31 ++++++++++++++++++++-----------
revision.c | 45 +++++++++++++++++++++++++++++----------------
2 files changed, 49 insertions(+), 27 deletions(-)
diff --git a/commit.c b/commit.c
index 0775eec..cd19a69 100644
--- a/commit.c
+++ b/commit.c
@@ -423,22 +423,31 @@ struct commit *pop_most_recent_commit(struct commit_list **list,
void clear_commit_marks(struct commit *commit, unsigned int mark)
{
- while (commit) {
- struct commit_list *parents;
+ struct commit_list *list = NULL, *l;
+ commit_list_insert(commit, &list);
+ while (list) {
+ commit = list->item;
+ l = list;
+ list = list->next;
+ free(l);
- if (!(mark & commit->object.flags))
- return;
+ while (commit) {
+ struct commit_list *parents;
- commit->object.flags &= ~mark;
+ if (!(mark & commit->object.flags))
+ break;
- parents = commit->parents;
- if (!parents)
- return;
+ commit->object.flags &= ~mark;
+
+ parents = commit->parents;
+ if (!parents)
+ break;
- while ((parents = parents->next))
- clear_commit_marks(parents->item, mark);
+ while ((parents = parents->next))
+ commit_list_insert(parents->item, &list);
- commit = commit->parents->item;
+ commit = commit->parents->item;
+ }
}
}
diff --git a/revision.c b/revision.c
index 0aa3638..8d4069e 100644
--- a/revision.c
+++ b/revision.c
@@ -139,11 +139,32 @@ void mark_tree_uninteresting(struct tree *tree)
void mark_parents_uninteresting(struct commit *commit)
{
- struct commit_list *parents = commit->parents;
+ struct commit_list *parents = NULL, *l;
+
+ for (l = commit->parents; l; l = l->next)
+ commit_list_insert(l->item, &parents);
while (parents) {
struct commit *commit = parents->item;
- if (!(commit->object.flags & UNINTERESTING)) {
+ l = parents;
+ parents = parents->next;
+ free(l);
+
+ while (commit) {
+ /*
+ * A missing commit is ok iff its parent is marked
+ * uninteresting.
+ *
+ * We just mark such a thing parsed, so that when
+ * it is popped next time around, we won't be trying
+ * to parse it and get an error.
+ */
+ if (!has_sha1_file(commit->object.sha1))
+ commit->object.parsed = 1;
+
+ if (commit->object.flags & UNINTERESTING)
+ break;
+
commit->object.flags |= UNINTERESTING;
/*
@@ -154,21 +175,13 @@ void mark_parents_uninteresting(struct commit *commit)
* wasn't uninteresting), in which case we need
* to mark its parents recursively too..
*/
- if (commit->parents)
- mark_parents_uninteresting(commit);
- }
+ if (!commit->parents)
+ break;
- /*
- * A missing commit is ok iff its parent is marked
- * uninteresting.
- *
- * We just mark such a thing parsed, so that when
- * it is popped next time around, we won't be trying
- * to parse it and get an error.
- */
- if (!has_sha1_file(commit->object.sha1))
- commit->object.parsed = 1;
- parents = parents->next;
+ for (l = commit->parents->next; l; l = l->next)
+ commit_list_insert(l->item, &parents);
+ commit = commit->parents->item;
+ }
}
}
--
1.7.8.36.g69ee2
-- 8< --
--
Duy
^ permalink raw reply related
* [PATCH] Set hard limit on delta chain depth
From: Nguyễn Thái Ngọc Duy @ 2011-12-05 7:04 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Nguyễn Thái Ngọc Duy
Too deep delta chains can cause stack overflow in get_base_data(). Set
a hard limit so that index-pack does not run out of stack. Also stop
people from producing such a long delta chains using "pack-object
--depth=<too large>"
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
I used to make very long delta chains and triggered this in index-pack.
I did not care reporting because it's my fault anyway. Think again,
index-pack is called at server side and a malicious client can
trigger this. This patch does not improve the situation much, but at
least we won't get sigsegv at server side.
builtin/index-pack.c | 12 ++++++++++--
builtin/pack-objects.c | 3 +++
pack.h | 2 ++
3 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/builtin/index-pack.c b/builtin/index-pack.c
index 0945adb..cfb8cb2 100644
--- a/builtin/index-pack.c
+++ b/builtin/index-pack.c
@@ -504,13 +504,16 @@ static int is_delta_type(enum object_type type)
return (type == OBJ_REF_DELTA || type == OBJ_OFS_DELTA);
}
-static void *get_base_data(struct base_data *c)
+static void *get_base_data_1(struct base_data *c, int depth)
{
+ if (depth > MAX_DELTA_DEPTH)
+ die("index-pack: too long delta chain");
+
if (!c->data) {
struct object_entry *obj = c->obj;
if (is_delta_type(obj->type)) {
- void *base = get_base_data(c->base);
+ void *base = get_base_data_1(c->base, depth + 1);
void *raw = get_data_from_pack(obj);
c->data = patch_delta(
base, c->base->size,
@@ -530,6 +533,11 @@ static void *get_base_data(struct base_data *c)
return c->data;
}
+static void *get_base_data(struct base_data *c)
+{
+ return get_base_data_1(c, 0);
+}
+
static void resolve_delta(struct object_entry *delta_obj,
struct base_data *base, struct base_data *result)
{
diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c
index 824ecee..85ee04b 100644
--- a/builtin/pack-objects.c
+++ b/builtin/pack-objects.c
@@ -2508,6 +2508,9 @@ int cmd_pack_objects(int argc, const char **argv, const char *prefix)
if (keep_unreachable && unpack_unreachable)
die("--keep-unreachable and --unpack-unreachable are incompatible.");
+ if (depth > MAX_DELTA_DEPTH)
+ die("--depth exceeds %d", MAX_DELTA_DEPTH);
+
if (progress && all_progress_implied)
progress = 2;
diff --git a/pack.h b/pack.h
index 722a54e..b8f60c3 100644
--- a/pack.h
+++ b/pack.h
@@ -3,6 +3,8 @@
#include "object.h"
+#define MAX_DELTA_DEPTH 128
+
/*
* Packed object header
*/
--
1.7.8.36.g69ee2
^ permalink raw reply related
* [PATCH] Documentation: fix formatting error in merge-options.txt
From: Jack Nagel @ 2011-12-05 7:53 UTC (permalink / raw)
To: git, gitster; +Cc: jacknagel
The first paragraph inside of a list item does not need a preceding line
consisting of a single '+', and in fact this causes the text to be
misrendered. Fix it.
Signed-off-by: Jack Nagel <jacknagel@gmail.com>
---
Documentation/merge-options.txt | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/Documentation/merge-options.txt b/Documentation/merge-options.txt
index 6bd0b04..1a5c12e 100644
--- a/Documentation/merge-options.txt
+++ b/Documentation/merge-options.txt
@@ -9,7 +9,6 @@ inspect and further tweak the merge result before committing.
--edit::
-e::
-+
Invoke editor before committing successful merge to further
edit the default merge message.
--
1.7.8
^ permalink raw reply related
* Re: [PATCH v2 3/3] grep: disable threading in all but worktree case
From: Thomas Rast @ 2011-12-05 9:02 UTC (permalink / raw)
To: René Scharfe; +Cc: Eric Herman, git, Junio C Hamano
In-Reply-To: <4ED8F9AE.8030605@lsrfire.ath.cx>
René Scharfe wrote:
> Am 02.12.2011 14:07, schrieb Thomas Rast:
> > Measuring grep performance showed that in all but the worktree case
> > (as opposed to --cached,<committish> or<treeish>), threading
> > actually slows things down. For example, on my dual-core
> > hyperthreaded i7 in a linux-2.6.git at v2.6.37-rc2, I got:
> >
> > Threads worktree case | --cached case
> > --------------------------------------------------------------------------
> > 8 (default) | 2.17user 0.15sys 0:02.20real | 0.11user 0.26sys 0:00.11real
> > 4 | 2.06user 0.17sys 0:02.08real | 0.11user 0.26sys 0:00.12real
> > 2 | 2.02user 0.25sys 0:02.08real | 0.15user 0.37sys 0:00.28real
> > NO_PTHREADS | 1.57user 0.05sys 0:01.64real | 0.09user 0.12sys 0:00.22real
>
> Are the columns mixed up?
Indeed, sorry.
In case you were wondering why this table is different from the
numbers given in the cover letter: I noticed at some point that I had
an incomplete checkout (apparently 'git checkout -- .' is really not
the same as 'git reset --hard'... sigh). Then I saw that while the
numbers were different, the conclusion was not, so I forgot to update
it.
> This is a bit radical. I think the underlying issue that
> read_sha1_file() is not thread-safe can be solved eventually and then
> we'd need to readd that code.
I'm also scared of sha1_file.c, especially when it gets down to
packfiles. But perhaps it wouldn't be *too* hard to do it in parallel
iff the object can be read from the loose object store.
> PS: Patches one and three missed a signoff.
Oops, thanks, turns out I had a misconfigured alias ...
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: [PATCH v2 0/3] grep multithreading and scaling
From: Thomas Rast @ 2011-12-05 9:38 UTC (permalink / raw)
To: Jeff King; +Cc: René Scharfe, Eric Herman, git, Junio C Hamano
In-Reply-To: <20111202173400.GC23447@sigill.intra.peff.net>
Jeff King wrote:
>
> A quick perf run shows most of the time is spent inflating objects. The
> diff code has a sneaky trick to re-use worktree files when we know they
> are stat-clean (in diff's case it is to avoid writing a tempfile). I
> wonder if we should use the same trick here.
>
> It would hurt the cold cache case, though, as the compressed versions
> require fewer disk accesses, of course.
I just found out that on Linux, there's mincore() that can tell us
(racily, but who cares) whether a given file mapping is in memory. If
you would like to try it, see the source at the end, but I'm getting
things such as
# in a random collection of files, none of which I have accessed lately
$ ls -l
-rw-r--r-- 1 thomas users 116534 Jul 4 2010 IMG_4884.JPG
-rw-r--r-- 1 thomas users 7278081 Aug 25 2010 remoteserverrepo.zip
$ ./mincore IMG_4884.JPG
00000000000000000000000000000
$ cat IMG_4884.JPG > /dev/null
$ ./mincore IMG_4884.JPG
11111111111111111111111111111
$ ./mincore remoteserverrepo.zip
0000000000000000000000[...]
$ head -10 remoteserverrepo.zip >/dev/null
$ ./mincore remoteserverrepo.zip
1111000000000000000000[...]
So that looks fairly promising, and the order would then be:
- if stat-clean, and we have mincore(), and it tells us we can do it
cheaply: grab file from tree
- if it's a loose object: decompress it
- if stat-clean: grab file from tree
- access packs as usual
> PS I suspect your timings are somewhat affected by the simplicity of the
> regex you are asking for. The time to inflate the blobs dominates,
> because the search is just a memmem(). On my quad-core w/
> hyperthreading (i.e., 8 apparent cores):
>
> $ /usr/bin/time git grep INITRAMFS_ROOT_UID >/dev/null
> 0.42user 0.45system 0:00.15elapsed 578%CPU
> $ /usr/bin/time git grep 'a.*b' >/dev/null
> 14.68user 0.50system 0:02.00elapsed 758%CPU
> $ /usr/bin/time git grep --cached INITRAMFS_ROOT_UID >/dev/null
> 7.64user 0.41system 0:07.61elapsed 105%CPU
> $ /usr/bin/time git grep --cached 'a.*b' >/dev/null
> 23.46user 0.47system 0:08.42elapsed 284%CPU
>
> So I think there is value in parallelizing even --cached greps. But
> we could do so much better if blob inflation could be done in
> parallel.
Ok, I see, I missed that part. Perhaps the heuristic should then be
"if the regex boils down to memmem, disable threading", but let's see
what loose object decompression in parallel can give us.
---- 8< ---- mincore.c ---- 8< ----
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <sys/mman.h>
#include <fcntl.h>
void die(const char *s)
{
perror(s);
exit(1);
}
int main (int argc, char *argv[])
{
void *mem;
size_t len;
struct stat st;
int fd;
unsigned char *vec;
int vsize;
int i;
size_t page = sysconf(_SC_PAGESIZE);
if (argc != 2) {
fprintf(stderr, "usage: %s <file>\n", argv[0]);
exit(2);
}
fd = open(argv[1], O_RDONLY);
if (fd == -1)
die("open failed");
if (fstat(fd, &st) == -1)
die("fstat failed");
mem = mmap(NULL, st.st_size, PROT_READ, MAP_SHARED, fd, 0);
if (mem == (void*) -1)
die("mmap failed");
vsize = (st.st_size+page-1)/page;
vec = malloc(vsize);
if (!vec)
die("malloc failed");
if (mincore(mem, st.st_size, vec) == -1)
die("mincore failed");
for (i = 0; i < vsize; i++)
printf("%d", (int) vec[i]);
printf("\n");
return 0;
}
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: Debugging git-commit slowness on a large repo
From: Junio C Hamano @ 2011-12-05 17:38 UTC (permalink / raw)
To: Carlos Martín Nieto, Thomas Rast
Cc: Joshua Redstone, git@vger.kernel.org
In-Reply-To: <20111203002347.GB2950@centaur.lab.cmartin.tk>
Carlos Martín Nieto <cmn@elego.de> writes:
> ... At one
> point, commit forgot how to write the tree cache to the index (a
> performance optimisation). Do the times improve if you run 'git
> read-tree HEAD' between one commit and another? Note that this will
> reset the index to the last commit, though for the tests I image you
> use some variation of 'git commit -a'.
>
> Thomas Rast wrote a patch to re-teach commit to store the tree cache,
> but there were some issues and never got applied.
Ahh, I forgot all about that exchange.
http://thread.gmane.org/gmane.comp.version-control.git/178480/focus=178515
The cache-tree mechanism has traditionally been one of the more important
optimizations and it would be very nice if we can resurrect the behaviour
for "git commit" too.
^ permalink raw reply
* Re: Evaluation of ref-api branch status
From: Junio C Hamano @ 2011-12-05 18:26 UTC (permalink / raw)
To: Michael Haggerty; +Cc: git discussion list
In-Reply-To: <4EDAB62E.5070204@alum.mit.edu>
Michael Haggerty <mhagger@alum.mit.edu> writes:
> Now that 1.7.8 is out, I wanted to figure out the status of the
> remaining ref-api changes that are in flight, including the differences
> between between my tree and yours.
I understand that the ultimate and largest objective of these series is to
make sure that the performance does not suffer from very many negative
lookups on the refs/replace hierarchy (which almost always is empty in a
sane repository), and I do want to see that happen. I also think it is
good that the series tries to make sure that the various codepaths we
create new refs do not let the user accidentally create refs with bad
names and/or contents.
When we see a questionable ref that is _already_ in the respository,
however, we may warn but it is wrong to declare the repository to be
broken and refuse to work. That would make it cumbersome or impossible to
even _fix_ such breakage. Regressions of that kind wer in the earlier part
of the series already in 1.7.8 and it was rather unpleasant having to
hotfix them. As our test suite does not deliberately create these
questionable refs and/or try to use them (and I personally do not in my
regular workflow either), I am afraid that it is rather hard to realize
what kind of refnames are what we intended to forbid even from earlier
days but did not _bother_ to check and enforce the rule against so far,
but are forbidden by the updated code, until we unleash the new logic to
the end users with various third party tools that created them [*1*]. I
would want to see us get this part right and solid, and include it in
1.7.9.
It would be nice if we can include also the bits to read hierarchies
lazily, but as they come on top of your B & C, it may end up in 1.7.10 and
I do not mind it at all. Reference resolution is one of the central things
in the user experience, and we cannot afford to ship anything that is
half-done-and-mostly-works over slow-but-correct.
Alternatively you _could_ swap the order of your B & C and D and try to
have your D early while giving B & C more time to cook, but I suspect the
order you chose would be better in the longer term.
> I understand that "next" will soon be re-rolled. Will the re-roll be
> based on the current "pu", or will you start from scratch?
As to the two quickfix patches that are on two remaining topics from you
in my tree, I did them merely as a short-term band-aid. I was expecting,
after 1.7.8 when we eject the topics out of 'next', that they will be
rebased on top of 'master' that already contains a proper fix before these
topics started touching the same codepath.
My reading of your summary suggests that it would be easiest to drop the
three mh/ref-api* topics from my tree, especially the 'refs: loosen
over-strict "format" check' band-aid patches, and re-queue a re-roll from
you.
Thanks.
[Footnote]
*1* Trying to be lenient when reading and being strict when writing as the
general principle would be the safe and sane way forward, and making sure
that we warn *loudly* when we think we are merely being lenient (i.e. we
think we found a bad ref with questionable name and/or contents) would be
a good way to catch our mistakes early. E.g. ".git/config does not record
a correct object name" glitch was caught only because you added the
warning so while it was painful to hotfix that late in the cycle, the
warning was worth it.
^ permalink raw reply
* Re: [bug?] checkout -m doesn't work without a base version
From: Junio C Hamano @ 2011-12-05 18:58 UTC (permalink / raw)
To: Pete Harlan; +Cc: git
In-Reply-To: <4EDBF4D5.6030908@pcharlan.com>
Pete Harlan <pgit@pcharlan.com> writes:
> But this only works if there's a base version; if foo.c was added in
> each branch, we get:
>
> error: path 'foo.c' does not have all three versions
>
> Git didn't need all three versions to create the original conflicted
> file, so why would it need them to recreate it?
Because the original "merge" was a bit more carefully written but
"checkout -m" was written without worrying too much about "both sides
added differently" corner case and still being defensive about not doing
random thing upon getting an unexpected input state.
IOW, being lazy ;-)
How does this look?
-- >8 --
checkout -m: no need to insist on having all 3 stages
The content level merge machinery ll_merge() is prepared to merge
correctly in "both sides added differently" case by using an empty blob as
if it were the common ancestor. "checkout -m" could do the same, but didn't
bother supporting it and instead insisted on having all three stages.
Reported-by: Pete Harlan
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin/checkout.c | 60 +++++++++++++++++++++++++++++++--------------------
1 files changed, 36 insertions(+), 24 deletions(-)
diff --git a/builtin/checkout.c b/builtin/checkout.c
index 2a80772..923d040 100644
--- a/builtin/checkout.c
+++ b/builtin/checkout.c
@@ -114,16 +114,21 @@ static int check_stage(int stage, struct cache_entry *ce, int pos)
return error(_("path '%s' does not have their version"), ce->name);
}
-static int check_all_stages(struct cache_entry *ce, int pos)
+static int check_stages(unsigned stages, struct cache_entry *ce, int pos)
{
- if (ce_stage(ce) != 1 ||
- active_nr <= pos + 2 ||
- strcmp(active_cache[pos+1]->name, ce->name) ||
- ce_stage(active_cache[pos+1]) != 2 ||
- strcmp(active_cache[pos+2]->name, ce->name) ||
- ce_stage(active_cache[pos+2]) != 3)
- return error(_("path '%s' does not have all three versions"),
- ce->name);
+ unsigned seen = 0;
+ const char *name = ce->name;
+
+ while (pos < active_nr) {
+ ce = active_cache[pos];
+ if (strcmp(name, ce->name))
+ break;
+ seen |= (1 << ce_stage(ce));
+ pos++;
+ }
+ if ((stages & seen) != stages)
+ return error(_("path '%s' does not have all necessary versions"),
+ name);
return 0;
}
@@ -150,18 +155,27 @@ static int checkout_merged(int pos, struct checkout *state)
int status;
unsigned char sha1[20];
mmbuffer_t result_buf;
+ unsigned char threeway[3][20];
+ unsigned mode;
+
+ memset(threeway, 0, sizeof(threeway));
+ while (pos < active_nr) {
+ int stage;
+ stage = ce_stage(ce);
+ if (!stage || strcmp(path, ce->name))
+ break;
+ hashcpy(threeway[stage - 1], ce->sha1);
+ if (stage == 2)
+ mode = create_ce_mode(ce->ce_mode);
+ pos++;
+ ce = active_cache[pos];
+ }
+ if (is_null_sha1(threeway[1]) || is_null_sha1(threeway[2]))
+ return error(_("path '%s' does not have necessary versions"), path);
- if (ce_stage(ce) != 1 ||
- active_nr <= pos + 2 ||
- strcmp(active_cache[pos+1]->name, path) ||
- ce_stage(active_cache[pos+1]) != 2 ||
- strcmp(active_cache[pos+2]->name, path) ||
- ce_stage(active_cache[pos+2]) != 3)
- return error(_("path '%s' does not have all 3 versions"), path);
-
- read_mmblob(&ancestor, active_cache[pos]->sha1);
- read_mmblob(&ours, active_cache[pos+1]->sha1);
- read_mmblob(&theirs, active_cache[pos+2]->sha1);
+ read_mmblob(&ancestor, threeway[0]);
+ read_mmblob(&ours, threeway[1]);
+ read_mmblob(&theirs, threeway[2]);
/*
* NEEDSWORK: re-create conflicts from merges with
@@ -192,9 +206,7 @@ static int checkout_merged(int pos, struct checkout *state)
if (write_sha1_file(result_buf.ptr, result_buf.size,
blob_type, sha1))
die(_("Unable to add merge result for '%s'"), path);
- ce = make_cache_entry(create_ce_mode(active_cache[pos+1]->ce_mode),
- sha1,
- path, 2, 0);
+ ce = make_cache_entry(mode, sha1, path, 2, 0);
if (!ce)
die(_("make_cache_entry failed for path '%s'"), path);
status = checkout_entry(ce, state, NULL);
@@ -252,7 +264,7 @@ static int checkout_paths(struct tree *source_tree, const char **pathspec,
} else if (stage) {
errs |= check_stage(stage, ce, pos);
} else if (opts->merge) {
- errs |= check_all_stages(ce, pos);
+ errs |= check_stages((1<<2) | (1<<3), ce, pos);
} else {
errs = 1;
error(_("path '%s' is unmerged"), ce->name);
^ permalink raw reply related
* Re: [PATCH] Documentation: fix formatting error in merge-options.txt
From: Junio C Hamano @ 2011-12-05 19:16 UTC (permalink / raw)
To: Jack Nagel; +Cc: git, Jay Soffian
In-Reply-To: <1323071607-29213-1-git-send-email-jacknagel@gmail.com>
Jack Nagel <jacknagel@gmail.com> writes:
> The first paragraph inside of a list item does not need a preceding line
> consisting of a single '+', and in fact this causes the text to be
> misrendered. Fix it.
Thanks.
>
> Signed-off-by: Jack Nagel <jacknagel@gmail.com>
> ---
> Documentation/merge-options.txt | 1 -
> 1 files changed, 0 insertions(+), 1 deletions(-)
>
> diff --git a/Documentation/merge-options.txt b/Documentation/merge-options.txt
> index 6bd0b04..1a5c12e 100644
> --- a/Documentation/merge-options.txt
> +++ b/Documentation/merge-options.txt
> @@ -9,7 +9,6 @@ inspect and further tweak the merge result before committing.
>
> --edit::
> -e::
> -+
> Invoke editor before committing successful merge to further
> edit the default merge message.
^ permalink raw reply
* Re: [PATCH 2/2] builtin/apply.c: report error on failure to recognize input
From: Junio C Hamano @ 2011-12-05 19:27 UTC (permalink / raw)
To: Brandon Casey; +Cc: git, artem.bityutskiy
In-Reply-To: <1322944550-27344-2-git-send-email-drafnel@gmail.com>
Brandon Casey <drafnel@gmail.com> writes:
> When git apply is passed something that is not a patch, it does not produce
> an error message or exit with a non-zero status if it was not actually
> "applying" the patch i.e. --check or --numstat etc were supplied on the
> command line.
>
> Fix this by producing an error when apply fails to find any hunks whatsoever
> while parsing the patch.
>
> This will cause some of the output formats (--numstat, --diffstat, etc) to
> produce an error when they formerly would have reported zero changes and
> exited successfully. That seems like the correct behavior though. Failure
> to recognize the input as a patch should be an error.
>
> Plus, add a test.
>
> Reported-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
> Signed-off-by: Brandon Casey <drafnel@gmail.com>
> ---
>
> Initially, I was reluctant to change the error message, thinking that
> error messages for plumbing commands were not supposed to change. But I
> think I was wrong in that thought, so I changed the error message so it
> was a more descriptive "unrecognized input".
I am still reluctant to see
$ git apply </dev/null
error: unrecognized input
instead of "error: No changes", though.
"git apply --check" is about asking "do you see anything offending in the
diff?" and it is not "git apply --dry-run" that asks "do you promise if I
feed this for real to you you will apply it without complaint?".
I am slightly in favor of answering "well you do not have a diff to begin
with, which in itself is suspicious" to "do you see anything offending?"
question, but I have to admit that it is an equally valid answer to say
"no, there is nothing offending in the diff.", which is what we do with
the current code.
So, I dunno.
^ permalink raw reply
* hooks that do not consume stdin sometimes crash git with SIGPIPE
From: Joey Hess @ 2011-12-05 19:29 UTC (permalink / raw)
To: git; +Cc: Lars Wirzenius
In-Reply-To: <20110829203107.GA4946@gnu.kitenet.net>
[-- Attachment #1: Type: text/plain, Size: 1638 bytes --]
We had a weird problem where, after moving to a new, faster server,
"git push" would sometimes fail like this:
Unpacking objects: 100% (3/3), done.
fatal: The remote end hung up unexpectedly
fatal: The remote end hung up unexpectedly
Turns out that git-receive-pack was dying due to an uncaught SIGPIPE.
The SIGPIPE occurred when it tried to write to the pre-receive hook's
stdin. The pre-receive hook, in this case, was able to do all the checks
it needed to do[1] without the input, and so did exit(0) without
consuming it.
Apparently that causes a race. Most of the time, git forks the hook,
writes output to the hook, and then the hook runs, ignores it, and exits.
But sometimes, on our new faster (and SMP) server, git forked the hook, and
it ran, and exited, before git got around to writing to it, resulting in
the SIGPIPE.
write(7, "c9f98c67d70a1cfeba382ec27d87644a"..., 100) = -1 EPIPE (Broken pipe)
--- SIGPIPE (Broken pipe) @ 0 (0) ---
I think git should ignore SIGPIPE when writing to hooks. Otherwise,
hooks may have to go out of their way to consume all input, and as I've
seen, the races when they fail to do this can lurk undiscovered.
Note that I encountered this same sort of problem from another direction
(involving smudge filters) not long ago, and sent a patch, in
<20110829203107.GA4946@gnu.kitenet.net>. That wasn't applied, and is
in different code than the case I outlined above.
--
see shy jo
[1] If you're wondering, it only needed to check that the push was
coming from a trusted UID. With an untrusted UID, it did further
checks that consumed the stdin.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Roadmap for 1.7.9
From: Junio C Hamano @ 2011-12-05 20:07 UTC (permalink / raw)
To: git
I do not do roadmaps, so the title of this message is not quite correct,
but I think I should post my current thinking on what have been cooking so
far that deserve to be polished further to be in the next release.
I've been aiming for a release cycle that lasts for 8 to 10 weeks, and the
last 2 or 3 weeks of a cycle is meant for release candidate testing that
we fix only regressions, which means we need to see how much we can do
within 5 to 8 weeks. The current cycle is expected to end at the end of
January next month [*1*].
I am not so worried about small and obvious fixes and enhancements, and
changes in the periphery areas. They can and will be merged as they come
and cook long enough in 'next' without issues reported by their users. I
expect what have been cooking in 'next' during the feature-freeze before
the 1.7.8 release, other than the ones listed below, to be more or less
ready already and they should be in 'master' shortly.
Now, here are the biggies that we would want to try to have in reasonable
shape before the next release. The list may be a bit too ambitious, given
that this cycle overlaps with end-of-this-year/beginning-of-new-year
holiday season in various cultures.
* Credentials and keychain (Peff)
* Pulling signed tag (me, Linus)
* Update "request-pull" script with information that matters (me)
* Revisiting threading of grep (Rene, Thomas Rast)
* Optimization of reading hierarchical refspace lazily (Michael Haggerty)
I expect the following will not make much progress without further
discussion:
* Signed commit (me)
* Ignored vs Precious (Nguyen Thai Ngoc Duy)
* Sequencer (Ram, Jonathan Nieder)
I think the following are too big to be ready by the end of this cycle
(polishing could and will continue as time permits).
* Large-files
- bulk check-in (me)
- "Chunked" encoding of large files (me)
[Reference]
*1* https://www.google.com/calendar/embed?src=jfgbl2mrlipp4pb6ieih0qr3so%40group.calendar.google.com&ctz=America/Los_Angeles
^ permalink raw reply
* Re: [PATCH v2 0/3] grep multithreading and scaling
From: Thomas Rast @ 2011-12-05 20:16 UTC (permalink / raw)
To: Jeff King; +Cc: René Scharfe, Eric Herman, git, Junio C Hamano
In-Reply-To: <201112051038.16423.trast@student.ethz.ch>
Thomas Rast wrote:
>
> I just found out that on Linux, there's mincore() that can tell us
> (racily, but who cares) whether a given file mapping is in memory.
[...]
> So that looks fairly promising, and the order would then be:
>
> - if stat-clean, and we have mincore(), and it tells us we can do it
> cheaply: grab file from tree
>
> - if it's a loose object: decompress it
>
> - if stat-clean: grab file from tree
>
> - access packs as usual
Just a small note, I tried two things:
* the simpler option of grabbing a loose object if it exists and is
mincore() turns out to massively slow down 'git log HEAD', probably
because only very few of these objects are loose in the first place
* doing this only under grep's use_threads, and dropping the lock
around unpack_sha1_file() [i.e., zlib decompression] still results
in a git-grep that is slower than without this, though not much
So no improvement here. Will have to look into the worktree trick
though.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: Roadmap for 1.7.9
From: Ævar Arnfjörð Bjarmason @ 2011-12-05 21:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vd3c2lr36.fsf@alter.siamese.dyndns.org>
On Mon, Dec 5, 2011 at 21:07, Junio C Hamano <gitster@pobox.com> wrote:
> Now, here are the biggies that we would want to try to have in reasonable
> shape before the next release.
I'd like to get the i18n series into 1.7.9 as well. I think it's ready
as-is but some minor issues are sure to arise.
If time permits I'd also like to have a series of po/*.po files in as
well once it's in "master". Maybe as a submodule, which would be neat
in itself as we'd start dogfooding submodules.
^ 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