* Re: [PATCH] remote-curl: don't pass back fake refs
From: Junio C Hamano @ 2011-12-19 19:28 UTC (permalink / raw)
To: Jeff King; +Cc: git, Shawn O. Pearce, Junio C Hamano
In-Reply-To: <20111219171055.GA21227@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Perhaps we should squash in the test below, which demonstrates the
> breakage. I also wonder if this is maint-worthy.
Thanks for a thorough analysis. I agree that this should go to maint even
more so, as it fixes a case to push to a non-empty repository.
^ permalink raw reply
* Re: Re* How to generate pull-request with info of signed tag
From: Junio C Hamano @ 2011-12-19 19:55 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: Git Mailing List
In-Reply-To: <87iplch79e.fsf@linux.vnet.ibm.com>
"Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com> writes:
> It would be nice to get the below working
>
> git fetch git-url tag remote-tag-name:local-namespace/tag-name
AFAIR "fetch tag $v" is a shorthand for "fetch refs/tags/$v:refs/tags/$"
invented back when Linus was the maintainer of Git. You can say
$ git fetch $url refs/tags/remote-tag-name:refs/tags/whatever-tag-name-you-want
to rename their tag to whatever name in your local repository.
Come to think of it, the last patch I sent out on request pull was very
wrong. The point of the recent change to allow you to pull this way
(notice the lack of "tag")
$ git pull $url $signed_tag_name
is so that you do not have to contaminate your own ref namespace with tags
that are used to leave audit trails in the history graph.
> That way we can make sure before merging i can cut-paste that url and
> the local tag name i wish to store this to. And then do a git-merge.
^ permalink raw reply
* Re: Re* How to generate pull-request with info of signed tag
From: Junio C Hamano @ 2011-12-19 20:06 UTC (permalink / raw)
To: Git Mailing List; +Cc: Aneesh Kumar K.V
In-Reply-To: <7vobv4mj4r.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Come to think of it, the last patch I sent out on request pull was very
> wrong....
And this should fix it.
-- >8 --
Subject: [PATCH] request-pull: do not emit "tag" before the tagname
The whole point of the recent update to allow "git pull $url $tagname" is
so that the integrator does not have to store the (signed) tag that is
used to convey authenticity to be recorded in the resulting merge in the
local repository's tag namespace. Asking for a merge be made with "git
pull $url tag $tagname" defeats it.
Note that the request can become ambiguous if the requestor has a branch
with the same name as the tag, but that is not a new problem limited to
pulling. I wouldn't mind if somebody wants to add disambiguation to the
find_matching_ref logic in the script as a separate patch, though.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
git-request-pull.sh | 4 +---
t/t5150-request-pull.sh | 2 +-
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/git-request-pull.sh b/git-request-pull.sh
index 7b5c777..d7ba117 100755
--- a/git-request-pull.sh
+++ b/git-request-pull.sh
@@ -63,10 +63,8 @@ die "fatal: No commits in common between $base and $head"
find_matching_ref='
sub abbr {
my $ref = shift;
- if ($ref =~ s|refs/heads/||) {
+ if ($ref =~ s|refs/heads/|| || $ref =~ s|refs/tags/||) {
return $ref;
- } elsif ($ref =~ s|refs/tags/||) {
- return "tag $ref";
} else {
return $ref;
}
diff --git a/t/t5150-request-pull.sh b/t/t5150-request-pull.sh
index aec842f..da25bc2 100755
--- a/t/t5150-request-pull.sh
+++ b/t/t5150-request-pull.sh
@@ -180,7 +180,7 @@ test_expect_success 'request names an appropriate branch' '
read branch
} <digest &&
{
- test "$branch" = tag--full ||
+ test "$branch" = full ||
test "$branch" = master ||
test "$branch" = for-upstream
}
--
1.7.8.370.gb3269
^ permalink raw reply related
* Re: [PATCH 2/2] push: hint to use push.default=upstream when appropriate
From: Junio C Hamano @ 2011-12-19 20:16 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20111219103746.GB1736@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> It seems like the real problem is that they are on branch "foo", but the
> matching behavior tried to push "bar", which didn't work. And we are
> worried that they may be surprised that we even attempted to push "bar"
> at all.
Of we may be seeing a non-fast-forward on 'foo' itself, which is your
1. below.
> And that probably happened because of the situation you describe, but we
> (and the user) don't have to think about that. We can just think about
> the more immediate mistake of "oops, I didn't want to push 'bar'".
>
> Which leads me to two ideas:
>
> 1. This is not good advice to give when pushing the _current_ branch
> failed due to non-ff. Setting push.default to "upstream" would
> probably yield the same error. We should probably tighten the
> condition for showing this message to when a non-HEAD branch failed
> to fast-forward.
>
> 2. The text should focus on the (possible) local misconfiguration, not
> the repo setup.
OK, I think we are in agreement.
> So maybe something like:
>
> By default, git pushes all branches that have a matching counterpart
> on the remote. In this case, some of your local branches were stale
> with respect to their remote counterparts. If you did not intend to
> push these branches, you may want to set the 'push.default'
> configuration variable to 'upstream' to push only the current branch.
>
> I'm not 100% happy with that text, but I think you can see the direction
> I am talking about.
As long as we can tighten the condition further to ensure that the advice
above is triggered only when appropriate, I actually am 100% happy with
that text. Seeing others do the real work for me always makes me happy ;-)
In addition to "did we use default-matching?", we should use "did we get
non-fast-forward error on a branch that is _not_ the current one?" instead
of the "did we get any non-fast-forward error?" in my patch, and the text
should match the situation more-or-less exactly.
> ... If we follow my suggestion above and
> only print this message for non-HEAD refs, then these two messages
> become an either/or situation, I think. If the HEAD failed to
> fast-forward, then the right advice is probably "git pull && git push".
> If a non-HEAD failed, then the right advice is either "git checkout $X
> && git pull && git push" or "here's how to avoid accidentally pushing
> $X".
>
> So the logic would be something like:
>
> if (nonfastforward == NONFASTFORWARD_HEAD)
> advise_pull_before_push();
> else if (nonfastforward == NONFASTFORWAD_OTHER) {
> if (default_matching_used)
> advise_use_upstream();
> else
> advise_checkout_pull_push();
> }
Sounds good. Spelling things out at this detail would let others who may
be interested in getting their hands dirty try to come up with an updated
patch ;-).
Thanks.
^ permalink raw reply
* Re: git 1.7.7.5
From: Junio C Hamano @ 2011-12-19 20:22 UTC (permalink / raw)
To: Thomas Jarosch; +Cc: Jonathan Nieder, git
In-Reply-To: <201112191041.07629.thomas.jarosch@intra2net.com>
Thomas Jarosch <thomas.jarosch@intra2net.com> writes:
> On Friday, 16. December 2011 11:57:58 Jonathan Nieder wrote:
>> I noticed that v1.7.7.5 was tagged a few days ago (b36dcd72), but
>> there is no corresponding tarball at
>>
>> http://code.google.com/p/git-core/downloads/list
>>
>> Will there be an official tarball?
>>
>> I don't mind either way, but it would be useful to know whether
>> distributors should make their own or just wait.
>
> Looks like a bug, the front page of "git-scm.com" also shows 1.7.7.5
> as latest stable release and leads to a dead link.
There actually is no bug; I just haven't got around to generating signed
tarballs yet.
I tend to agree that after 1.7.8 was released, showing 1.7.7.5 as the
latest stable indeed a bug (1.7.8 is still the latest stable and the next
latest stable will be 1.7.8.1), but that site is not under my direct
control, so...
^ permalink raw reply
* Re: [PATCH] lf_to_crlf_filter(): tell the caller we added "\n" when draining
From: Junio C Hamano @ 2011-12-19 20:23 UTC (permalink / raw)
To: Henrik Grubbström; +Cc: Git Mailing list, Carlos Martín Nieto
In-Reply-To: <Pine.GSO.4.63.1112191114010.4136@shipon.roxen.com>
Henrik Grubbström <grubba@roxen.com> writes:
> We probably ought to have a corresponding test in the testsuite.
> A blob consisting of a singe 'A' followed by 8192 linefeeds should
> be sufficient to trigger the problems.
Sounds good. Please make it so.
^ permalink raw reply
* Re: [PATCHv2 2/2] attr: drop C/C++ default extension mapping
From: Thomas Rast @ 2011-12-19 20:51 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Jeff King, git, Johannes Sixt, Junio C Hamano, Brandon Casey,
Philip Oakley
In-Reply-To: <20111219181003.GB12200@elie.hsd1.il.comcast.net>
Jonathan Nieder <jrnieder@gmail.com> writes:
> Jeff King wrote:
>
>> But when you think about it, if our funcname pattern is bad, shouldn't
>> preventing (2) be the right thing? That is, if our funcname pattern is
>> really worse than the default language-agnostic match, wouldn't we be
>> doing everybody a service to simply remove the builtin
>> diff.cpp.xfuncname pattern?
>
> I don't see why. Anyone who has set "diff=cpp" either likes suffering
> (maybe they are hoping to improve the pattern) or is working with a
> codebase for which the current pattern works better than the default
> behavior (maybe their codebase has a lot of goto labels aligned at
> column zero). So removing the funcname pattern can only hurt them.
FWIW, the funcname pattern is not the only feature of the diff
attributes. I set it mainly to get the built-in --word-diff split
regexes.
I agree with Peff's patches though, until the cpp pattern improves, we
should not turn them on by default.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* [PATCH] t4018: introduce test cases for the internal hunk header patterns
From: Brandon Casey @ 2011-12-19 20:52 UTC (permalink / raw)
To: peff; +Cc: git, j6t, gitster, jrnieder, Brandon Casey
In-Reply-To: <20111217012118.GB20225@sigill.intra.peff.net>
From: Brandon Casey <drafnel@gmail.com>
Recently it has been pointed out that one or more of the internal hunk
header patterns are sub-optimal. Specifically, the C/C++ "cpp" pattern was
called out.
Let's introduce some infrastructure to make it easy to create test cases
for the hunk header patterns and provide a few cases for the cpp pattern.
* new test cases can be dropped into the t4018 directory
* filenames end with the pattern name e.g. .cpp .objc .matlab etc.
* filenames should be descriptive since it will be used in the test
suite output
* broken test cases should be given a filename prefixed with "broken_"
* test cases must provide a function named "RIGHT_function_hunk_header"
- this is the function name that should appear on the hunk header line
- the body of this function should have an assignment like
answer = 0
The test suite will modify the above line to produce a difference
from the original. Additionally, this should be far enough within
the body of the function so that the function name is not part of
the lines of context.
Example test case:
int WRONG_function_hunk_header (void)
{
return 0;
}
int RIGHT_function_hunk_header (void)
{
/*
* Filler
* Filler
* Filler
*/
int answer = 0;
return 0;
}
Signed-off-by: Brandon Casey <drafnel@gmail.com>
---
On Fri, Dec 16, 2011 at 7:21 PM, Jeff King <peff@peff.net> wrote:
> On Fri, Dec 16, 2011 at 11:05:27PM +0100, Johannes Sixt wrote:
>
<snip>
>> ... in order to ultimately
>> improve the built-in pattern. The topic came up just the other day, and
>> I took Thomas Rast's suggestion to experiment with a simplified pattern:
>>
>> http://thread.gmane.org/gmane.comp.version-control.git/186355/focus=186439
>>
>> But as is, the built-in pattern misses way too many anchor points in C++
>> code.
>
> Yeah, I can certainly agree that the patterns could be better.
>
> Maybe we should just table the extension mapping for now, then, and see
> if the patterns improve? Or maybe just drop the C ones (and probably the
> objc one based on other parts of the thread) and do the rest?
/methinks t4018 needs to be greatly expanded. There is no way to tell what
is currently broken by the current pattern, or what is newly broken by a
new pattern.
How about this for a start?
-Brandon
t/t4018-diff-funcname.sh | 18 ++++++++++++
t/t4018/broken_class_constructor.cpp | 34 +++++++++++++++++++++++
t/t4018/broken_class_destructor.cpp | 34 +++++++++++++++++++++++
t/t4018/broken_gnu_style.cpp | 35 +++++++++++++++++++++++
t/t4018/broken_reference.cpp | 34 +++++++++++++++++++++++
t/t4018/broken_template.cpp | 34 +++++++++++++++++++++++
t/t4018/class_method.cpp | 34 +++++++++++++++++++++++
t/t4018/simple.cpp | 50 ++++++++++++++++++++++++++++++++++
t/t4018/static.cpp | 34 +++++++++++++++++++++++
9 files changed, 307 insertions(+), 0 deletions(-)
create mode 100644 t/t4018/broken_class_constructor.cpp
create mode 100644 t/t4018/broken_class_destructor.cpp
create mode 100644 t/t4018/broken_gnu_style.cpp
create mode 100644 t/t4018/broken_reference.cpp
create mode 100644 t/t4018/broken_template.cpp
create mode 100644 t/t4018/class_method.cpp
create mode 100644 t/t4018/simple.cpp
create mode 100644 t/t4018/static.cpp
diff --git a/t/t4018-diff-funcname.sh b/t/t4018-diff-funcname.sh
index 4bd2a1c..5a1f7b7 100755
--- a/t/t4018-diff-funcname.sh
+++ b/t/t4018-diff-funcname.sh
@@ -121,6 +121,24 @@ do
! grep fatal msg &&
! grep error msg
'
+
+ for f in "$TEST_DIRECTORY"/t4018/*.$p; do
+ test -f "$f" || continue
+ name=`basename "$f" .$p`
+ test_expect_which=test_expect_success
+ if test "$name" != "${name#broken_}"; then
+ name=${name#broken_}
+ test_expect_which=test_expect_failure
+ fi
+ $test_expect_which \
+ "builtin $p pattern works correctly for $name case" "
+ echo \"*.$p diff=$p\" >.gitattributes &&
+ sed -e 's/answer = 0/answer = 42/' < \"$f\" > \"$name.$p\" &&
+ test_expect_code 1 git diff --no-index \"$f\" \
+ \"$name.$p\" >actual &&
+ egrep '^@@ .* @@ .*RIGHT_function_hunk_header' actual
+ "
+ done
done
test_expect_success 'default behaviour' '
diff --git a/t/t4018/broken_class_constructor.cpp b/t/t4018/broken_class_constructor.cpp
new file mode 100644
index 0000000..1e4cb9c
--- /dev/null
+++ b/t/t4018/broken_class_constructor.cpp
@@ -0,0 +1,34 @@
+int WRONG_function_hunk_header_preceding_the_right_one (void)
+{
+ return 0;
+}
+
+RIGHT_function_hunk_header::RIGHT_function_hunk_header (void)
+{
+ /*
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ */
+
+ int answer = 0;
+
+ /*
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ */
+
+ return answer;
+}
+
+int WRONG_function_hunk_header_following_the_right_one (void)
+{
+ return 0;
+}
diff --git a/t/t4018/broken_class_destructor.cpp b/t/t4018/broken_class_destructor.cpp
new file mode 100644
index 0000000..84d9506
--- /dev/null
+++ b/t/t4018/broken_class_destructor.cpp
@@ -0,0 +1,34 @@
+int WRONG_function_hunk_header_preceding_the_right_one (void)
+{
+ return 0;
+}
+
+RIGHT_function_hunk_header::~RIGHT_function_hunk_header (void)
+{
+ /*
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ */
+
+ int answer = 0;
+
+ /*
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ */
+
+ return answer;
+}
+
+int WRONG_function_hunk_header_following_the_right_one (void)
+{
+ return 0;
+}
diff --git a/t/t4018/broken_gnu_style.cpp b/t/t4018/broken_gnu_style.cpp
new file mode 100644
index 0000000..ffba9b9
--- /dev/null
+++ b/t/t4018/broken_gnu_style.cpp
@@ -0,0 +1,35 @@
+int WRONG_function_hunk_header_preceding_the_right_one (void)
+{
+ return 0;
+}
+
+int
+RIGHT_function_hunk_header (void)
+{
+ /*
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ */
+
+ int answer = 0;
+
+ /*
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ */
+
+ return answer;
+}
+
+int WRONG_function_hunk_header_following_the_right_one (void)
+{
+ return 0;
+}
diff --git a/t/t4018/broken_reference.cpp b/t/t4018/broken_reference.cpp
new file mode 100644
index 0000000..ea90b82
--- /dev/null
+++ b/t/t4018/broken_reference.cpp
@@ -0,0 +1,34 @@
+int WRONG_function_hunk_header_preceding_the_right_one (void)
+{
+ return 0;
+}
+
+int& RIGHT_function_hunk_header (void)
+{
+ /*
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ */
+
+ int answer = 0;
+
+ /*
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ */
+
+ return answer;
+}
+
+int WRONG_function_hunk_header_following_the_right_one (void)
+{
+ return 0;
+}
diff --git a/t/t4018/broken_template.cpp b/t/t4018/broken_template.cpp
new file mode 100644
index 0000000..95a6dd5
--- /dev/null
+++ b/t/t4018/broken_template.cpp
@@ -0,0 +1,34 @@
+int WRONG_function_hunk_header_preceding_the_right_one (void)
+{
+ return 0;
+}
+
+template <class T> int RIGHT_function_hunk_header (T unused)
+{
+ /*
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ */
+
+ int answer = 0;
+
+ /*
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ */
+
+ return answer;
+}
+
+int WRONG_function_hunk_header_following_the_right_one (void)
+{
+ return 0;
+}
diff --git a/t/t4018/class_method.cpp b/t/t4018/class_method.cpp
new file mode 100644
index 0000000..2e51853
--- /dev/null
+++ b/t/t4018/class_method.cpp
@@ -0,0 +1,34 @@
+int WRONG_function_hunk_header_preceding_the_right_one (void)
+{
+ return 0;
+}
+
+int test_class::RIGHT_function_hunk_header (void)
+{
+ /*
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ */
+
+ int answer = 0;
+
+ /*
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ */
+
+ return answer;
+}
+
+int WRONG_function_hunk_header_following_the_right_one (void)
+{
+ return 0;
+}
diff --git a/t/t4018/simple.cpp b/t/t4018/simple.cpp
new file mode 100644
index 0000000..b8fca06
--- /dev/null
+++ b/t/t4018/simple.cpp
@@ -0,0 +1,50 @@
+/*
+ * Test file for testing the internal hunk header patterns
+ *
+ * The "RIGHT" hunk header function, the one that should appear on the
+ * hunk header line, should be named "RIGHT_function_hunk_header" and
+ * the body of this function should have an assignment that looks like
+ *
+ * answer = 0
+ *
+ * within it, deep enough so the lines of context do not include the
+ * function name.
+ *
+ * If the name of this file begins with "broken_", then it will be
+ * interpreted as a pattern which does not work, but which should.
+ */
+
+int WRONG_function_hunk_header_preceding_the_right_one (void)
+{
+ return 0;
+}
+
+int RIGHT_function_hunk_header (void)
+{
+ /*
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ */
+
+ int answer = 0;
+
+ /*
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ */
+
+ return answer;
+}
+
+int WRONG_function_hunk_header_following_the_right_one (void)
+{
+ return 0;
+}
diff --git a/t/t4018/static.cpp b/t/t4018/static.cpp
new file mode 100644
index 0000000..fcc48f2
--- /dev/null
+++ b/t/t4018/static.cpp
@@ -0,0 +1,34 @@
+int WRONG_function_hunk_header_preceding_the_right_one (void)
+{
+ return 0;
+}
+
+static int RIGHT_function_hunk_header (void)
+{
+ /*
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ */
+
+ int answer = 0;
+
+ /*
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ */
+
+ return answer;
+}
+
+int WRONG_function_hunk_header_following_the_right_one (void)
+{
+ return 0;
+}
--
1.7.7.4
^ permalink raw reply related
* Re: [PATCH] remote-curl: don't pass back fake refs
From: Jeff King @ 2011-12-19 21:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Shawn O. Pearce
In-Reply-To: <7vty4wmkdt.fsf@alter.siamese.dyndns.org>
On Mon, Dec 19, 2011 at 11:28:14AM -0800, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > Perhaps we should squash in the test below, which demonstrates the
> > breakage. I also wonder if this is maint-worthy.
>
> Thanks for a thorough analysis. I agree that this should go to maint even
> more so, as it fixes a case to push to a non-empty repository.
Do you want to squash in those tests, or should I re-send with a commit
message more fully explaining the situation?
-Peff
^ permalink raw reply
* Re: [PATCH] remote-curl: don't pass back fake refs
From: Junio C Hamano @ 2011-12-19 21:28 UTC (permalink / raw)
To: Jeff King; +Cc: git, Shawn O. Pearce
In-Reply-To: <20111219211203.GA18396@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Mon, Dec 19, 2011 at 11:28:14AM -0800, Junio C Hamano wrote:
>
>> Jeff King <peff@peff.net> writes:
>>
>> > Perhaps we should squash in the test below, which demonstrates the
>> > breakage. I also wonder if this is maint-worthy.
>>
>> Thanks for a thorough analysis. I agree that this should go to maint even
>> more so, as it fixes a case to push to a non-empty repository.
>
> Do you want to squash in those tests, or should I re-send with a commit
> message more fully explaining the situation?
I was lazy and added these three lines at the end:
This also fixes pushing with --mirror to a smart-http remote that uses
alternates. The fake ".have" refs the server gives to avoid unnecessary
network transfer has a similar bad interactions with the machinery.
but it may warrant a more thorough write-up there.
^ permalink raw reply
* Re: [PATCH] remote-curl: don't pass back fake refs
From: Jeff King @ 2011-12-19 21:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Shawn O. Pearce
In-Reply-To: <7v39cgmety.fsf@alter.siamese.dyndns.org>
On Mon, Dec 19, 2011 at 01:28:09PM -0800, Junio C Hamano wrote:
> > Do you want to squash in those tests, or should I re-send with a commit
> > message more fully explaining the situation?
>
> I was lazy and added these three lines at the end:
>
> This also fixes pushing with --mirror to a smart-http remote that uses
> alternates. The fake ".have" refs the server gives to avoid unnecessary
> network transfer has a similar bad interactions with the machinery.
>
> but it may warrant a more thorough write-up there.
I think that's probably enough. I could restructure the whole text to
talk less about capabilities^{} and more about generically preventing
fake refs, but I really don't think there's much point.
-Peff
^ permalink raw reply
* Re: git-svn: multiple fetch lines
From: Nathan Gray @ 2011-12-19 21:40 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git, Eric Wong
In-Reply-To: <20111217100521.GA12610@elie.hsd1.il.comcast.net>
Hi,
On Sat, Dec 17, 2011 at 2:05 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Hi Nathan,
>
> Nathan Gray wrote:
>
>> I'm in a conversation with the support fellow of the very nice Tower
>> git interface for OS X and we need clarification on a point. Does
>> git-svn explicitly support multiple "fetch =" lines in an svn-remote
>> section or is it just an accident that it works? My belief is that
>> such support is intended and his is that it is accidental.
>
> It's true that the documentation is not as clear about this as one
> might like. Documentation/git-svn.txt leaves it to the reader to
> infer that this is supported by analogy with "fetch =" lines in native
> git [remote] sections:
Thanks Jonathan, that's just what I suspected.
[snip]
> Perhaps such an example would be useful for the git-svn(1) manpage,
> too. Any ideas for where to add such a note, and how it should be
> worded? (Of course, if you can phrase such an idea in patch form,
> that would be the most convenient.)
The existing CONFIGURATION section of the man page seems like a
sensible place to mention multiple fetch entries. I've also found the
documentation on creating branches in the presence of multiple branch
keys to be confusing and in need of an example, so maybe that could go
in as well. How about something along these lines:
"""
In order to simplify working with messy subversion repositories you
can configure multiple fetch, branches, and tags keys. For example:
[svn-remote "messy-repo"]
url = http://server.org/svn
fetch = trunk/project-a:refs/remotes/project-a/trunk
fetch = branches/demos/june-project-a-demo:refs/remotes/project-a/demos/june-demo
branches = branches/server/*:refs/remotes/project-a/branches/*
branches = branches/demos/2011/*:refs/remotes/project-a/2011-demos/*
tags = tags/server/*:refs/remotes/project-a/tags/*
To create a branch in this configuration you need to specify the
location for the new branch using the -d or --destination flag. For
example:
git svn branch -d wtf-goes-here-anyway?? release-2-3-0
"""
The thing about the -d option that confuses me is that I'm not sure if
I'm supposed to be supplying a full svn path, a partial svn path, the
glob from the config file, etc. An example would make it obvious.
Personally, I always take the coward's way out and comment out the
extra branches keys, make the branch without -d, then restore them in
order to avoid any potential problems. :^)
Thanks,
-Nathan
--
HexaLex: A New Angle on Crossword Games for iPhone and iPod Touch
http://hexalex.com
On The App Store: http://bit.ly/8Mj1CU
On Facebook: http://bit.ly/9MIJiV
On Twitter: http://twitter.com/hexalexgame
http://n8gray.org
^ permalink raw reply
* Re: How can I do an automatic stash when doing a checkout?
From: DeMarcus @ 2011-12-19 21:43 UTC (permalink / raw)
To: git
In-Reply-To: <4EEF63CA.4030201@dirk.my1.cc>
On 2011-12-19 17:18, Dirk Süsserott wrote:
> Am 18.12.2011 16:10 schrieb DeMarcus:
> [...]
>
>>>> With the git stash command I can clean the directory the way I want
>>>> but the stash command is not connected to a particular branch.
>>>>
>>>> Is there a way to have git checkout do an automatic stash when doing a
>>>> checkout to another branch, and then do an automatic git stash apply
>>>> with the correct stash when changing back to the previous branch
>>>> again?
>>>
>>> You probably don't want to use stash. Just commit whatever partial work
>>> you've done.
>>>
>>
>> It feels strange doing a commit of partial work. Some of the files may
>> not even be supposed to be checked in.
>>
>>> You could also just checkout different branches in different
>>> directories. Nothing wrong with doing that in git.
>>>
>>
>> Ok thanks, that would give me the same behavior as I have today.
>>
>> However, I can see some benefits with have everything in the same
>> directory as git allows compared to other VCSs. And since the stashing
>> feature is already there in git, it would be nice if the git checkout
>> with some flag could use stashing automatically.
>>
>>
>
> DeMarcus,
>
> probably a post-checkout hook could help you with autostashing, but that
> would need some scripting. Have a look at "git hooks --help".
> I sometimes use such a hook to auto-update submodules when checking out
> a branch. To be fair: I don't know how to identify the "right" stash then.
>
Thanks! I'll check that out. Maybe the right stash could be checked-in
itself somehow.
^ permalink raw reply
* Re: How can I do an automatic stash when doing a checkout?
From: DeMarcus @ 2011-12-19 21:46 UTC (permalink / raw)
To: git
In-Reply-To: <4EEF736A.4070802@ira.uka.de>
On 2011-12-19 18:24, Holger Hellmuth wrote:
> On 18.12.2011 16:10, DeMarcus wrote:
>>> You probably don't want to use stash. Just commit whatever partial work
>>> you've done.
>>>
>>
>> It feels strange doing a commit of partial work. Some of the files may
>> not even be supposed to be checked in.
>
> You have heard of "git commit --amend" ? Makes partial commits really
> easy to work with.
>
>
Yes, I know that one. It's just that I know myself, I don't really like
to go back rearranging. I prefer to keep things spread out at first and
then inserted properly when it's time. But maybe I'm just unused to the
git workflow.
^ permalink raw reply
* [PATCH] t4018: add a few more test cases for cpp hunk header matching
From: Brandon Casey @ 2011-12-19 21:53 UTC (permalink / raw)
To: peff; +Cc: git, j6t, gitster, jrnieder, trast, Brandon Casey
In-Reply-To: <31E9klcRboMV0wSJY5WO-N7nIBOUOa_wr6MVfWY9AInImxJIqC0flahvpDrVGMIuZ9e7Ouha1HDuesbwTGaNQA4dgN-FShNJKkfMG_cHLUJAT2rE539shnQxzM0dQyZIb5661As6Tvs@cipher.nrlssc.navy.mil>
From: Brandon Casey <drafnel@gmail.com>
Add one case for matching a function returning a pointer.
Plus add examples of things we explicitly do not match:
labels
function declarations
global variable declarations
Signed-off-by: Brandon Casey <drafnel@gmail.com>
---
This can be squashed into the original patch with the other test cases.
This just introduces a few more cases pointed out by Thomas Rast in the
email Johannes referenced.
http://thread.gmane.org/gmane.comp.version-control.git/186355/focus=186439
Also, note that all of the tests pass except for ignore_global.cpp with
Johannes's pattern:
"!^[ \\t]*[a-zA-Z_][a-zA-Z_0-9]*[^()]*:[[:space:]]*$\n^[a-zA-Z_][a-zA-Z_0-9]*.*"
-Brandon
t/t4018/ignore_declaration.cpp | 35 +++++++++++++++++++++++++++++++++++
t/t4018/ignore_global.cpp | 36 ++++++++++++++++++++++++++++++++++++
t/t4018/ignore_label.cpp | 35 +++++++++++++++++++++++++++++++++++
t/t4018/pointer_return.cpp | 34 ++++++++++++++++++++++++++++++++++
4 files changed, 140 insertions(+), 0 deletions(-)
create mode 100644 t/t4018/ignore_declaration.cpp
create mode 100644 t/t4018/ignore_global.cpp
create mode 100644 t/t4018/ignore_label.cpp
create mode 100644 t/t4018/pointer_return.cpp
diff --git a/t/t4018/ignore_declaration.cpp b/t/t4018/ignore_declaration.cpp
new file mode 100644
index 0000000..615aea0
--- /dev/null
+++ b/t/t4018/ignore_declaration.cpp
@@ -0,0 +1,35 @@
+int WRONG_function_hunk_header_preceding_the_right_one (void)
+{
+ return 0;
+}
+
+int RIGHT_function_hunk_header (void)
+{
+ void WRONG_function_declaration_within_body (void);
+ /*
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ */
+
+ int answer = 0;
+
+ /*
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ */
+
+ return answer;
+}
+
+int WRONG_function_hunk_header_following_the_right_one (void)
+{
+ return 0;
+}
diff --git a/t/t4018/ignore_global.cpp b/t/t4018/ignore_global.cpp
new file mode 100644
index 0000000..df6b8aa
--- /dev/null
+++ b/t/t4018/ignore_global.cpp
@@ -0,0 +1,36 @@
+int WRONG_function_hunk_header_preceding_the_right_one (void)
+{
+ return 0;
+}
+
+int RIGHT_function_hunk_header (void)
+{
+ /*
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ */
+
+ return answer;
+}
+
+int WRONG_global_variable;
+
+/*
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ */
+
+int answer = 0;
+
+int WRONG_function_hunk_header_following_the_right_one (void)
+{
+ return 0;
+}
diff --git a/t/t4018/ignore_label.cpp b/t/t4018/ignore_label.cpp
new file mode 100644
index 0000000..2e3ce10
--- /dev/null
+++ b/t/t4018/ignore_label.cpp
@@ -0,0 +1,35 @@
+int WRONG_function_hunk_header_preceding_the_right_one (void)
+{
+ return 0;
+}
+
+int RIGHT_function_hunk_header (void)
+{
+WRONG_should_not_match_label:
+ /*
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ */
+
+ int answer = 0;
+
+ /*
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ */
+
+ return answer;
+}
+
+int WRONG_function_hunk_header_following_the_right_one (void)
+{
+ return 0;
+}
diff --git a/t/t4018/pointer_return.cpp b/t/t4018/pointer_return.cpp
new file mode 100644
index 0000000..fd85545
--- /dev/null
+++ b/t/t4018/pointer_return.cpp
@@ -0,0 +1,34 @@
+int WRONG_function_hunk_header_preceding_the_right_one (void)
+{
+ return 0;
+}
+
+static int *RIGHT_function_hunk_header (void)
+{
+ /*
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ */
+
+ int answer = 0;
+
+ /*
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ * Filler
+ */
+
+ return answer;
+}
+
+int WRONG_function_hunk_header_following_the_right_one (void)
+{
+ return 0;
+}
--
1.7.7.4
^ permalink raw reply related
* Re: How can I do an automatic stash when doing a checkout?
From: Junio C Hamano @ 2011-12-19 22:24 UTC (permalink / raw)
To: DeMarcus; +Cc: git
In-Reply-To: <jcobbo$jab$1@dough.gmane.org>
DeMarcus <demarcus@hotmail.com> writes:
> ... I don't really like to go back rearranging. I prefer to keep things
> spread out at first and then inserted properly when it's time. But maybe
> I'm just unused to the git workflow.
That does not have to do much with "the" git workflow.
If you are a kind of person who likes to work on N things concurrently
without ever making and recording mistakes but would rather keep
unfinished work without committing until done, you would need to have them
in your working trees. By definition you would need to use N working
trees, each of which permanently checks out its own branch, instead of a
single working tree where you checkout one of N branches at a time to work
on.
That is also a perfectly fine git workflow that we support with the
contributed script git-new-workdir.
^ permalink raw reply
* Re: [PATCH] t4018: introduce test cases for the internal hunk header patterns
From: Junio C Hamano @ 2011-12-19 22:37 UTC (permalink / raw)
To: Brandon Casey; +Cc: peff, git, j6t, jrnieder, Brandon Casey
In-Reply-To: <31E9klcRboMV0wSJY5WO-N7nIBOUOa_wr6MVfWY9AInImxJIqC0flahvpDrVGMIuZ9e7Ouha1HDuesbwTGaNQA4dgN-FShNJKkfMG_cHLUJAT2rE539shnQxzM0dQyZIb5661As6Tvs@cipher.nrlssc.navy.mil>
Brandon Casey <casey@nrlssc.navy.mil> writes:
> * new test cases can be dropped into the t4018 directory
> * filenames end with the pattern name e.g. .cpp .objc .matlab etc.
> * filenames should be descriptive since it will be used in the test
> suite output
> * broken test cases should be given a filename prefixed with "broken_"
Cute. I like the general idea.
> * test cases must provide a function named "RIGHT_function_hunk_header"
> - this is the function name that should appear on the hunk header line
> - the body of this function should have an assignment like
>
> answer = 0
>
> The test suite will modify the above line to produce a difference
> from the original. Additionally, this should be far enough within
> the body of the function so that the function name is not part of
> the lines of context.
Although I do not think of any language with a syntax rule where that the
overlong RIGHT_func... token is an illegal symbol offhand, this feels a
bit _too_ specific to the C language. I would prefer something like this
instead:
* a test case must have one (and only one) line that contains "RIGHT"
(all uppercase) and that line should become the hunk header for the
test to succeed.
* after the line that contains "RIGHT" token, there should be one (and
only one) line that contains "ChangeMe". The test modifies this
token to "IWasChanged", compares the original with the modified
result, and expects the "RIGHT" token above appears on the hunk
header.
Also I would prefer not to require "enough filler", as we might want to
enhance the logic to consider using a line in the pre-context as the hunk
header in some cases, e.g.
@@ ... @@ int RIGHT_function_hunk_header(void)
int RIGHT_function_hunk_header(void)
{
- int ChangeME;
+ int IWasChanged;
printf("Hello, world\n");
return 0;
}
@@ ...
^ permalink raw reply
* Re: [PATCH] t4018: introduce test cases for the internal hunk header patterns
From: Brandon Casey @ 2011-12-19 22:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Brandon Casey, peff, git, j6t, jrnieder
In-Reply-To: <7vty4wkx19.fsf@alter.siamese.dyndns.org>
On Mon, Dec 19, 2011 at 4:37 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Brandon Casey <casey@nrlssc.navy.mil> writes:
>> * test cases must provide a function named "RIGHT_function_hunk_header"
>> - this is the function name that should appear on the hunk header line
>> - the body of this function should have an assignment like
>>
>> answer = 0
>>
>> The test suite will modify the above line to produce a difference
>> from the original. Additionally, this should be far enough within
>> the body of the function so that the function name is not part of
>> the lines of context.
>
> Although I do not think of any language with a syntax rule where that the
> overlong RIGHT_func... token is an illegal symbol offhand, this feels a
> bit _too_ specific to the C language.
Good point. "RIGHT_function_hunk_header" doesn't really have much
meaning for non-programming language patterns like tex and html.
> I would prefer something like this
> instead:
>
> * a test case must have one (and only one) line that contains "RIGHT"
> (all uppercase) and that line should become the hunk header for the
> test to succeed.
>
> * after the line that contains "RIGHT" token, there should be one (and
> only one) line that contains "ChangeMe". The test modifies this
> token to "IWasChanged", compares the original with the modified
> result, and expects the "RIGHT" token above appears on the hunk
> header.
Both good improvements.
> Also I would prefer not to require "enough filler", as we might want to
> enhance the logic to consider using a line in the pre-context as the hunk
> header in some cases, e.g.
>
> @@ ... @@ int RIGHT_function_hunk_header(void)
>
> int RIGHT_function_hunk_header(void)
> {
> - int ChangeME;
> + int IWasChanged;
> printf("Hello, world\n");
> return 0;
> }
> @@ ...
Yeah, I didn't mean to imply that "enough filler" was a requirement of
the test, just trying to point out the requirement imposed by the hunk
header logic. I'll remove this statement.
Will reroll.
-Brandon
^ permalink raw reply
* Re: [PATCH] t4018: introduce test cases for the internal hunk header patterns
From: Junio C Hamano @ 2011-12-19 23:17 UTC (permalink / raw)
To: Brandon Casey; +Cc: Brandon Casey, peff, git, j6t, jrnieder
In-Reply-To: <CA+sFfMeogJ==ud6NdPj_KZFUKFeB--RBmPkLndjrQwhg15V5ig@mail.gmail.com>
Brandon Casey <drafnel@gmail.com> writes:
>> * after the line that contains "RIGHT" token, there should be one (and
>> only one) line that contains "ChangeMe". The test modifies this
>> token to "IWasChanged", compares the original with the modified
>> result, and expects the "RIGHT" token above appears on the hunk
>> header.
>
> Both good improvements.
Let's not call "ChangeMe" a *token*, as I think the easiest example would
look like the following and it would not use it as such. Rephrasing it as
a "string" would be better.
@@ ... @@ int RIGHT_function_hunk_header(void)
int RIGHT_function_hunk_header(void)
{
- const char *msg = "ChangeME";
+ const char *msg = "IWasChanged";
printf("Hello, world, %s\n", msg);
return 0;
}
@@ ...
^ permalink raw reply
* Re: git 1.7.7.5
From: Junio C Hamano @ 2011-12-20 0:03 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git
In-Reply-To: <20111216105757.GA11174@elie.hsd1.il.comcast.net>
Jonathan Nieder <jrnieder@gmail.com> writes:
> I noticed that v1.7.7.5 was tagged a few days ago (b36dcd72), but
> there is no corresponding tarball at
>
> http://code.google.com/p/git-core/downloads/list
>
> Will there be an official tarball?
>
> I don't mind either way, but it would be useful to know whether
> distributors should make their own or just wait.
I personally would prefer distros to get stuff from the tagged release
point directly from SCM themselves, instead of using tarballs, but anyway
I've uploaded both 1.7.7.5 and 1.7.6.5 tarballs.
Thanks.
^ permalink raw reply
* Introducing vcsh - manage config files in $HOME via fake bare git repositories
From: Richard Hartmann @ 2011-12-20 0:17 UTC (permalink / raw)
To: Git List
Hi all,
some of you may be familiar with fake bare git repositories[1].
Basically, they allow you to keep the git directory and its working
directory separate from each other. This allows you to have an
arbitrary number of repositories with working trees in $HOME. That, in
turn, allows you to have one repo for zsh, one for vim, one for git,
etc pp.
vcsh[2] is a front-end for dealing with fake bare git repos, i.e. it
saves you a lot of typing and automates many things. It's written in
pure POSIX shell.
vcsh's userbase is slowly expanding and as it's feature set and syntax
are stable and there are no known bugs I think this is a good time to
try to increase adoption rate. I strongly believe that a lot of people
on this list could benefit from using it; hopefully you agree.
Publishing it here makes sense as if you are reading this, you are
obviously familiar with and using git already, anyway.
Feedback is very welcome. Good, bad or indifference, I will take it all.
Two notes:
* There is no test suite, yet. If anyone has a suggestion as to which
test suite has a reasonable feature set while having a syntax that
does not make you violently sick, or is even interested in helping to
write said test suite, do let me know.
* I am pondering renaming/aliasing vcsh to git-fbare.sh or similar.
That has a few issues, though..
** extra typing involved
** adds another command level of to otherwise standard git commands,
for example `git fbare zsh commit -a -m 'new feature'`
** forces everyone to have a default location for vcsh repos
Regards,
Richard
[1] http://lists.madduck.net/pipermail/vcs-home/2011-April/000378.html
[2] https://github.com/RichiH/vcsh
^ permalink raw reply
* Re: Debugging git-commit slowness on a large repo
From: Joshua Redstone @ 2011-12-20 0:51 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy, Carlos Martín Nieto, Tomas Carnecky,
Junio C Hamano
Cc: git@vger.kernel.org
In-Reply-To: <CB0BCE02.2CD42%joshua.redstone@fb.com>
I've managed to speed up git-commit on large repos by 4x by removing some
safeguards that caused git to stat every file in the repo on commits that
touch a small number of files. The diff, for illustrative purposes only,
is at:
https://gist.github.com/1499621
With a repo with 1 million files (but few commits), the diff drops the
commit time down from 7.3 seconds to 1.8 seconds, a 75% decrease. The
optimizations are:
1. Remove call to refresh_cache_or_die that stats every file in the repo,
i think the purpose is to detect any changes between git-add and
git-commit.
2. Pass missing_ok=true to cache_tree_update. This causes the tree
generation code to not stat every file in the repo to verify it still
exists as a git object.
3. Remove pair discard_cache/read_cache_from, which rereads the index
file. I think this was in case a pre-commit hook changed the set of things
being committed.
It may be worth making some of these flag-enabled.
Josh
On 12/12/11 4:15 PM, "Joshua Redstone" <joshua.redstone@fb.com> wrote:
>Sorry for the poor formatting of the stack trace.
>
>I've written two scripts to reproduce the slow commit behavior that I see.
> I've posted both to:
> https://gist.github.com/1469760
>
>To repro, first create a dir with lots of files (it defaults to creating 1
>million files in 1000 dirs):
>
>$ loadGen.py --baseDir=./bigdir
>
>then, run the simulator scripts to generate and commit a series of small
>changes to the repo:
>
>$ git reset --hard HEAD && simulate.py ./bigdir git
>
>The git reset is to clean up any cruft left over from a previous partial
>invocation of simulate.py
>
>Note that loadGen.py defaults to creating 1 million files and committing
>them in one commit. With a flash drive this took < 30 min, and subsequent
>small commits in simulate.py took about 6 seconds. With a hard-drive,
>it's taking > 1hr (still waiting for it to finish).
>
>Cheers,
>Josh
>
>
>On 12/8/11 4:17 PM, "Joshua Redstone" <joshua.redstone@fb.com> wrote:
>
>>Btw, I also tried doing some very poor-man's profiling on "git commit"
>>without any of the readtree/writetree/updateindex commands.
>>
>>Around 50% of the time was in (bottom few frames may have varied)
>>
>>#1 0x00000000004c467e in find_pack_entry (sha1=0x1475a44 ,
>>e=0x7fff2621f070) at sha1_file.c:2027
>>#2 0x00000000004c57b0 in has_sha1_file (sha1=0x7fe2cd9c7900 "00") at
>>sha1_file.c:2567
>>
>>
>>#3 0x000000000046e4af in update_one (it=<value optimized out>,
>>cache=<value optimized out>, entries=<value optimized out>, base=<value
>>optimized out>, baselen=<value optimized out>, missing_ok=<value
>>optimized
>>out>, dryrun=0) at cache-\
>>tree.c:333
>>
>>
>>
>>#4 0x000000000046e278 in update_one (it=<value optimized out>,
>>cache=<value optimized out>, entries=<value optimized out>, base=<value
>>optimized out>, baselen=<value optimized out>, missing_ok=<value
>>optimized
>>out>, dryrun=0) at cache-\
>>tree.c:285
>>
>>
>>
>>#5 0x000000000046e278 in update_one (it=<value optimized out>,
>>cache=<value optimized out>, entries=<value optimized out>, base=<value
>>optimized out>, baselen=<value optimized out>, missing_ok=<value
>>optimized
>>out>, dryrun=0) at cache-\
>>tree.c:285
>>
>>
>>
>>#6 0x000000000046e278 in update_one (it=<value optimized out>,
>>cache=<value optimized out>, entries=<value optimized out>, base=<value
>>optimized out>, baselen=<value optimized out>, missing_ok=<value
>>optimized
>>out>, dryrun=0) at cache-\
>>tree.c:285
>>
>>
>>
>>#7 0x000000000046e278 in update_one (it=<value optimized out>,
>>cache=<value optimized out>, entries=<value optimized out>, base=<value
>>optimized out>, baselen=<value optimized out>, missing_ok=<value
>>optimized
>>out>, dryrun=0) at cache-\
>>tree.c:285
>>
>>
>>
>>#8 0x000000000046e278 in update_one (it=<value optimized out>,
>>cache=<value optimized out>, entries=<value optimized out>, base=<value
>>optimized out>, baselen=<value optimized out>, missing_ok=<value
>>optimized
>>out>, dryrun=0) at cache-\
>>tree.c:285
>>
>>
>>
>>#9 0x000000000046e869 in cache_tree_update (it=<value optimized out>,
>>cache=<value optimized out>, entries=dwarf2_read_address: Corrupted DWARF
>>expression.
>>
>>) at cache-tree.c:379
>>
>>
>>
>>#10 0x000000000041cade in prepare_to_commit (index_file=0x781740
>>".git/index", prefix=<value optimized out>, current_head=<value optimized
>>out>, s=0x7fff26220d00, author_ident=<value optimized out>) at
>>builtin/commit.c:866
>>#11 0x000000000041d891 in cmd_commit (argc=0, argv=0x7fff262213a0,
>>prefix=0x0) at builtin/commit.c:1407
>>
>>
>>#12 0x0000000000404bf7 in handle_internal_command (argc=4,
>>argv=0x7fff262213a0) at git.c:308
>>
>>
>>#13 0x0000000000404e2f in main (argc=4, argv=0x7fff262213a0) at git.c:512
>>
>>
>>
>>
>>
>>
>>And 30% of the time was in:
>>
>>#0 0x00000034af2c34a5 in _lxstat () from /lib64/libc.so.6
>>
>>
>>
>>#1 0x00000000004abe0f in refresh_cache_ent (istate=0x780940,
>>ce=0x7f8462a34e40, options=0, err=0x7fff6dd9f588) at
>>/usr/include/sys/stat.h:443
>>
>>#2 0x00000000004ac1a0 in refresh_index (istate=0x780940, flags=<value
>>optimized out>, pathspec=<value optimized out>, seen=<value optimized
>>out>, header_msg=0x0) at read-cache.c:1133
>>
>>#3 0x000000000041b60a in refresh_cache_or_die (refresh_flags=<value
>>optimized out>) at builtin/commit.c:331
>>
>>
>>#4 0x000000000041bc39 in prepare_index (argc=0, argv=0x7fff6dda0310,
>>prefix=0x0, current_head=<value optimized out>, is_status=<value
>>optimized
>>out>) at builtin/commit.c:414
>>
>>#5 0x000000000041d878 in cmd_commit (argc=0, argv=0x7fff6dda0310,
>>prefix=0x0) at builtin/commit.c:1403
>>
>>
>>
>>
>>
>>Josh
>>
>>
>>On 12/8/11 4:09 PM, "Joshua Redstone" <joshua.redstone@fb.com> wrote:
>>
>>>On 12/7/11 5:39 PM, "Nguyen Thai Ngoc Duy" <pclouds@gmail.com> wrote:
>>>
>>>>On Thu, Dec 8, 2011 at 5:48 AM, Joshua Redstone
>>>><joshua.redstone@fb.com>
>>>>wrote:
>>>>> Hi Duy,
>>>>> Thanks for the documentation link.
>>>>>
>>>>> git ls-files shows 100k files, which matches # of files in the
>>>>>working
>>>>> tree ('find . -type f -print | wc -l').
>>>>
>>>>Any chance you can split it into smaller repositories, or remove files
>>>>from working directory (e.g. if you store logs, you don't have to keep
>>>>logs from all time in working directory, they can be retrieved from
>>>>history).
>>>
>>>It's not really feasible to split it into smaller repositories. In
>>>fact,
>>>we're expecting it to grow between 3x and 5x in number of files and
>>>number
>>>of commits.
>>>
>>>>
>>>>> I added a 'git read-tree HEAD' before the git-add, and a 'git
>>>>>write-tree'
>>>>> after the add. With that, the commit time slowed down to 8 seconds
>>>>>per
>>>>> commit, plus 4 more seconds for the read-tree/add/write-tree ops.
>>>>>The
>>>>> read-tree/add/write-tree each took about a second.
>>>>
>>>>read-tree destroys stat info in index, refreshing 100k entries in
>>>>index in this case may take some time. Try this to see if commit time
>>>>reduces and how much time update-index takes
>>>>
>>>>read-tree HEAD
>>>>update-index --refresh
>>>>add ....
>>>>write-tree
>>>>commit -q
>>>
>>>I added the "update-index --refresh" and the time for commit became more
>>>like 0.6 seconds.
>>>In this setup: read-tree takes ~2 seconds, update-index takes ~8
>>>seconds,
>>>git-add takes 1 to 4 seconds, and write-tree takes less than 1 second.
>>>
>>>>
>>>>> As an experiment, I also tried removing the 'git read-tree' and just
>>>>> having the git-write-tree. That sped up commits to 0.6 seconds, but
>>>>>the
>>>>> overall time for add/write-tree/commit was still 3 to 6 seconds.
>>>>
>>>>overall time is not really important because we duplicate work here
>>>>(write-tree is done as part of commit again). What I'm trying to do is
>>>>to determine how much time each operation in commit may take.
>>>>--
>>>>Duy
>>>
>>
>
^ permalink raw reply
* Re: Tracking file metadata in git -- fix metastore or enhance git?
From: Richard Hartmann @ 2011-12-20 0:55 UTC (permalink / raw)
To: johnnyutahh; +Cc: git
In-Reply-To: <1323838492627-7092383.post@n2.nabble.com>
On Wed, Dec 14, 2011 at 05:54, johnnyutahh
<git.nabble.com@johnnyutahh.com> wrote:
> Any further movement on this topic?
Not really. ATM, our best bet is to agree on a language and just implement it.
Richard
^ permalink raw reply
* Re: Debugging git-commit slowness on a large repo
From: Junio C Hamano @ 2011-12-20 1:21 UTC (permalink / raw)
To: Joshua Redstone
Cc: Nguyen Thai Ngoc Duy, Carlos Martín Nieto, Tomas Carnecky,
git@vger.kernel.org
In-Reply-To: <CB1518AB.2D649%joshua.redstone@fb.com>
Joshua Redstone <joshua.redstone@fb.com> writes:
> I've managed to speed up git-commit on large repos by 4x by removing some
> safeguards that caused git to stat every file in the repo on commits that
> touch a small number of files. The diff, for illustrative purposes only,
> is at:
>
> https://gist.github.com/1499621
>
>
> With a repo with 1 million files (but few commits), the diff drops the
> commit time down from 7.3 seconds to 1.8 seconds, a 75% decrease. The
> optimizations are:
I do not know if these kind of changes are called "optimizations" or
merely making the command record a random tree object that may have some
resemblance to what you wanted to commit but is subtly incorrect. I didn't
fetch your safety removal, though.
Wouldn't you get a similar speed-up without being unsafe if you simply ran
"git commit" without any parameter (i.e. write out the current index as a
tree and make a commit), combined with "--no-status" and perhaps "-q" to
avoid running the comparison between the resulting commit and the working
tree state after the commit?
^ permalink raw reply
* [RFC/PATCH 0/2] Re: git-svn: multiple fetch lines
From: Jonathan Nieder @ 2011-12-20 1:22 UTC (permalink / raw)
To: Nathan Gray; +Cc: git, Eric Wong
In-Reply-To: <CA+7g9JzatFYViMk302uU-X=YQGF2wEsmASkLPm0tDfQvpL_-vQ@mail.gmail.com>
Nathan Gray wrote:
> How about something along these lines:
Sounds sensible. Here's a patch series along those lines to get
things started. Please feel free to try them (use "make -C
Documentation git-svn.1" to test), tweak to taste, and resend when
ready for Eric to pick up.
Thanks,
Jonathan Nieder (1):
git-svn: clarify explanation of --destination argument
Nathan Gray (1):
git-svn: multiple fetch/branches/tags keys are supported
Documentation/git-svn.txt | 31 ++++++++++++++++++++++++++-----
1 files changed, 26 insertions(+), 5 deletions(-)
^ 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