* Re: Git, Builds, and Filesystem Type
From: Martin Fick @ 2012-02-09 23:34 UTC (permalink / raw)
To: Hilco Wijbenga; +Cc: Git Users
In-Reply-To: <CAE1pOi387-bimYEG4bjFOjaCwhPeDyLRj7wOJgyuKSCrZ9kBFg@mail.gmail.com>
On Thursday, February 09, 2012 04:24:47 pm Hilco Wijbenga
wrote:
> On 9 February 2012 13:53, Martin Fick
<mfick@codeaurora.org> wrote:
> > On Thursday, February 09, 2012 02:23:18 pm Hilco
> > Wijbenga
> >
> > wrote:
> >> For the record, our (Java) project is quite small.
> >> It's 43MB (source and images) and the entire
> >> directory tree after building is about 1.6GB (this
> >> includes all JARs downloaded by Maven). So we're not
> >> talking TBs of data.
> >>
> >> Any thoughts on which FSs to include in my tests? Or
> >> simply which FS might be more appropriate?
> >
> > tmpfs is probably fastest hands down if you can use it
> > (even if you have to back it by swap).
>
> I don't have quite that much RAM. :-)
But I am sure that you have that much disk space which you
can allocate to swap, if not you already couldn't build it.
And tmpfs swapping is still likely faster than a persistent
FS (it will not need to block on syncs). If you are
benchmarking, it is likely worth you effort since that will
probably mark the upper performance bound,
-Martin
--
Employee of Qualcomm Innovation Center, Inc. which is a
member of Code Aurora Forum
^ permalink raw reply
* Re: [RFC/PATCHv2 0/2] git-p4: possible RCS keyword fixes
From: Junio C Hamano @ 2012-02-09 23:29 UTC (permalink / raw)
To: Luke Diamand; +Cc: git, Pete Wyckoff, Eric Scouten
In-Reply-To: <1328829442-12550-1-git-send-email-luke@diamand.org>
Luke Diamand <luke@diamand.org> writes:
> I said before I wouldn't try to fix this, but maybe it could be
> made to work after all. If nothing else, the failing test
> case would be useful.
Will queue in 'pu' so that git-p4 folks can more easily try it out. The
variable needs to be added to Documentation/git-p4.txt after people are
satisfied with the resulting code.
Thanks.
^ permalink raw reply
* Re: Git, Builds, and Filesystem Type
From: Hilco Wijbenga @ 2012-02-09 23:24 UTC (permalink / raw)
To: Martin Fick; +Cc: Git Users
In-Reply-To: <201202091453.38564.mfick@codeaurora.org>
On 9 February 2012 13:53, Martin Fick <mfick@codeaurora.org> wrote:
> On Thursday, February 09, 2012 02:23:18 pm Hilco Wijbenga
> wrote:
>> For the record, our (Java) project is quite small. It's
>> 43MB (source and images) and the entire directory tree
>> after building is about 1.6GB (this includes all JARs
>> downloaded by Maven). So we're not talking TBs of data.
>>
>> Any thoughts on which FSs to include in my tests? Or
>> simply which FS might be more appropriate?
>
> tmpfs is probably fastest hands down if you can use it (even
> if you have to back it by swap).
I don't have quite that much RAM. :-)
^ permalink raw reply
* Re: [PATCH 1/5] gitweb: Option for filling only specified info in fill_project_list_info
From: Junio C Hamano @ 2012-02-09 23:18 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <201202092336.48772.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
>> The lack of any real use of @fill_only in this patch also makes it hard to
>> judge if the new API gives a useful semantics. I would, without looking
>> at the real usage in 2/5 patch, naïvely expect that such a lazy filling
>> scheme would say "I am going to use A, B and C; I want to know if any of
>> them is missing, because I need values for all of them and I am going to
>> call a helper function to fill them if any of them is missing. Having A
>> and B is not enough for the purpose of this query, because I still need to
>> know C and I would call the helper function that computes all of them in
>> such a case. Even though it might be wasteful to recompute A and B,
>> computing all three at once is the only helper function available to me".
>>
>> So for a person who does not have access to the real usage of the new API,
>> being able to give only a single $key *appears* make no sense at all, and
>> also the meaning of the @fill_only parameter is unclear, especially the
>> part that checks if that single $key appears in @fill_only.
>
> ...
> information that is not already present. If @fill_only is nonempty, it
> fills only selected information, again only if it is not already present.
> @fill_only empty means no restrictions... which probably is not very obvious,
> but is documented.
>
> project_info_needs_filling() returns true if $key is not filled and is
> interesting.
That still does not answer the fundamental issues I had with the presented
API: why does it take only a single $key (please re-read my "A, B and C"
example), and what does that single $key intersecting with @fill_only have
anything to do with "needs-filling"?
After all, that 'age' check actually wants to fill 'age' and 'age_string'
in the project. Even if some other codepath starts filling 'age' in the
project with a later change, the current callers of fill_project_list_info
expects _both_ to be filled. So "I know the current implementation fills
both at the same time, so checking 'age' alone is sufficient" is not an
answer that shows good taste in the API design.
^ permalink raw reply
* [RFC/PATCHv2 2/2] git-p4: initial demonstration of possible RCS keyword fixup
From: Luke Diamand @ 2012-02-09 23:17 UTC (permalink / raw)
To: git; +Cc: Pete Wyckoff, Eric Scouten, Luke Diamand
In-Reply-To: <1328829442-12550-1-git-send-email-luke@diamand.org>
This change has a go at showing a possible way to fixup RCS
keyword handling in git-p4.
It does not cope with deleted files.
It does not have good test coverage.
It does not solve the problem of the incorrect error messages.
But it does at least work after a fashion, and could provide
a starting point.
Signed-off-by: Luke Diamand <luke@diamand.org>
---
contrib/fast-import/git-p4 | 43 +++++++++++++++++++++++++++++++++++++++++--
t/t9810-git-p4-rcs.sh | 1 +
2 files changed, 42 insertions(+), 2 deletions(-)
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index a78d9c5..205fefd 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -753,6 +753,23 @@ class P4Submit(Command, P4UserMap):
return result
+ def patchRCSKeywords(self, file):
+ # Attempt to zap the RCS keywords in a p4 controlled file
+ p4_edit(file)
+ (handle, outFileName) = tempfile.mkstemp()
+ outFile = os.fdopen(handle, "w+")
+ inFile = open(file, "r")
+ for line in inFile.readlines():
+ line = re.sub(r'\$(Id|Header|Author|Date|DateTime|Change|File|Revision)[^$]*\$',
+ r'$\1$', line)
+ outFile.write(line)
+ inFile.close()
+ outFile.close()
+ # Forcibly overwrite the original file
+ system("cat %s" % outFileName)
+ system(["mv", "-f", outFileName, file])
+ print "Patched up RCS keywords in %s" % file
+
def p4UserForCommit(self,id):
# Return the tuple (perforce user,git email) for a given git commit id
self.getUserMapFromPerforceServer()
@@ -918,6 +935,7 @@ class P4Submit(Command, P4UserMap):
filesToDelete = set()
editedFiles = set()
filesToChangeExecBit = {}
+
for line in diff:
diff = parseDiffTreeEntry(line)
modifier = diff['status']
@@ -964,9 +982,30 @@ class P4Submit(Command, P4UserMap):
patchcmd = diffcmd + " | git apply "
tryPatchCmd = patchcmd + "--check -"
applyPatchCmd = patchcmd + "--check --apply -"
+ patch_succeeded = True
if os.system(tryPatchCmd) != 0:
+ fixed_rcs_keywords = False
+ patch_succeeded = False
print "Unfortunately applying the change failed!"
+
+ # Patch failed, maybe it's just RCS keyword woes. Look through
+ # the patch to see if that's possible.
+ if gitConfig("git-p4.attemptRCSCleanup","--bool") == "true":
+ file = None
+ for line in read_pipe_lines(diffcmd):
+ m = re.match(r'^diff --git a/(.*)\s+b/(.*)', line)
+ if m:
+ file = m.group(1)
+ if re.match(r'.*\$(Id|Header|Author|Date|DateTime|Change|File|Revision)[^$]*\$', line):
+ self.patchRCSKeywords(file)
+ fixed_rcs_keywords = True
+ if fixed_rcs_keywords:
+ print "Retrying the patch with RCS keywords cleaned up"
+ if os.system(tryPatchCmd) == 0:
+ patch_succeeded = True
+
+ if not patch_succeeded:
print "What do you want to do?"
response = "x"
while response != "s" and response != "a" and response != "w":
@@ -1588,11 +1627,11 @@ class P4Sync(Command, P4UserMap):
if type_base in ("text", "unicode", "binary"):
if "ko" in type_mods:
text = ''.join(contents)
- text = re.sub(r'\$(Id|Header):[^$]*\$', r'$\1$', text)
+ text = re.sub(r'\$(Id|Header)[^$]*\$', r'$\1$', text)
contents = [ text ]
elif "k" in type_mods:
text = ''.join(contents)
- text = re.sub(r'\$(Id|Header|Author|Date|DateTime|Change|File|Revision):[^$]*\$', r'$\1$', text)
+ text = re.sub(r'\$(Id|Header|Author|Date|DateTime|Change|File|Revision)[^$]*\$', r'$\1$', text)
contents = [ text ]
self.gitStream.write("M %s inline %s\n" % (git_mode, relPath))
diff --git a/t/t9810-git-p4-rcs.sh b/t/t9810-git-p4-rcs.sh
index c09f83d..efe172c 100755
--- a/t/t9810-git-p4-rcs.sh
+++ b/t/t9810-git-p4-rcs.sh
@@ -49,6 +49,7 @@ test_expect_failure 'cope with rcs keyword expansion damage' '
(
cd "$git" &&
git config git-p4.skipSubmitEdit true &&
+ git config git-p4.attemptRCSCleanup true &&
(cd ../cli && p4_append_to_file kwfile1.c) &&
perl -n -i -e "print unless m/Revision:/" kwfile1.c &&
git add kwfile1.c &&
--
1.7.9.rc2.128.gfce41.dirty
^ permalink raw reply related
* [RFC/PATCHv2 1/2] git-p4: add test case for RCS keywords
From: Luke Diamand @ 2012-02-09 23:17 UTC (permalink / raw)
To: git; +Cc: Pete Wyckoff, Eric Scouten, Luke Diamand
In-Reply-To: <1328829442-12550-1-git-send-email-luke@diamand.org>
RCS keywords cause problems for git-p4 as perforce always
expands them (if +k is set) and so when applying the patch,
git reports that the files have been modified by both sides,
when in fact they haven't.
This adds a failing test case to demonstrate the problem.
Signed-off-by: Luke Diamand <luke@diamand.org>
---
t/t9810-git-p4-rcs.sh | 80 +++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 80 insertions(+), 0 deletions(-)
create mode 100755 t/t9810-git-p4-rcs.sh
diff --git a/t/t9810-git-p4-rcs.sh b/t/t9810-git-p4-rcs.sh
new file mode 100755
index 0000000..c09f83d
--- /dev/null
+++ b/t/t9810-git-p4-rcs.sh
@@ -0,0 +1,80 @@
+#!/bin/sh
+
+test_description='git-p4 rcs keywords'
+
+. ./lib-git-p4.sh
+
+test_expect_success 'start p4d' '
+ start_p4d
+'
+
+create_kw_file() {
+ cat <<\EOF >"$1"
+/* A file
+ Id: $Id$
+ Revision: $Revision$
+ File: $File$
+ */
+int main(int argc, const char **argv) {
+ return 0;
+}
+EOF
+}
+
+test_expect_success 'init depot' '
+ (
+ cd "$cli" &&
+ echo file1 >file1 &&
+ p4 add file1 &&
+ p4 submit -d "change 1" &&
+ create_kw_file kwfile1.c &&
+ p4 add kwfile1.c &&
+ p4 submit -d "Add rcw kw file" kwfile1.c
+ )
+'
+
+p4_append_to_file() {
+ f=$1 &&
+ p4 edit -t ktext "$f" &&
+ echo "/* $(date) */" >>"$f" &&
+ p4 submit -d "appending a line in p4"
+}
+
+# Create some files with RCS keywords. If they get modified
+# elsewhere then the version number gets bumped which then
+# results in a merge conflict if we touch the RCS kw lines,
+# even though the change itself would otherwise apply cleanly.
+test_expect_failure 'cope with rcs keyword expansion damage' '
+ "$GITP4" clone --dest="$git" //depot &&
+ (
+ cd "$git" &&
+ git config git-p4.skipSubmitEdit true &&
+ (cd ../cli && p4_append_to_file kwfile1.c) &&
+ perl -n -i -e "print unless m/Revision:/" kwfile1.c &&
+ git add kwfile1.c &&
+ git commit -m "Zap an RCS kw line" &&
+ "$GITP4" submit &&
+ "$GITP4" rebase &&
+ git diff p4/master &&
+ "$GITP4" commit &&
+ echo "try modifying in both" &&
+ cd "$cli" &&
+ p4 edit kwfile1.c &&
+ echo "line from p4" >>kwfile1.c &&
+ p4 submit -d "add a line in p4" kwfile1.c &&
+ cd "$git" &&
+ echo "line from git at the top" | cat - kwfile1.c >kwfile1.c.new &&
+ mv kwfile1.c.new kwfile1.c &&
+ git commit -m "Add line in git at the top" kwfile1.c &&
+ "$GITP4" rebase &&
+ "$GITP4" submit
+ ) &&
+ rm -rf "$git" && mkdir "$git"
+'
+
+
+test_expect_success 'kill p4d' '
+ kill_p4d
+'
+
+test_done
--
1.7.9.rc2.128.gfce41.dirty
^ permalink raw reply related
* [RFC/PATCHv2 0/2] git-p4: possible RCS keyword fixes
From: Luke Diamand @ 2012-02-09 23:17 UTC (permalink / raw)
To: git; +Cc: Pete Wyckoff, Eric Scouten, Luke Diamand
Re-rolled with elementary shell coding errors fixed as per comments
from Junio - thanks!
I said before I wouldn't try to fix this, but maybe it could be
made to work after all. If nothing else, the failing test
case would be useful.
Luke Diamand (2):
git-p4: add test case for RCS keywords
git-p4: initial demonstration of possible RCS keyword fixup
contrib/fast-import/git-p4 | 43 ++++++++++++++++++++++-
t/t9810-git-p4-rcs.sh | 81 ++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 122 insertions(+), 2 deletions(-)
create mode 100755 t/t9810-git-p4-rcs.sh
--
1.7.9.rc2.128.gfce41.dirty
^ permalink raw reply
* Re: [PATCHv4 1/2] git-p4: add test case for RCS keywords
From: Junio C Hamano @ 2012-02-09 22:55 UTC (permalink / raw)
To: Luke Diamand; +Cc: git, Pete Wyckoff, Eric Scouten
In-Reply-To: <1328785409-30936-2-git-send-email-luke@diamand.org>
Luke Diamand <luke@diamand.org> writes:
> +create_kw_file() {
> + cat <<'EOF' > $1
Please start this shell function like this instead:
create_kw_file () {
cat <<\EOF >"$1"
The first line is merely cosmetic but matches the convention used in our
shell scripts better.
As to the second line:
* Quoting "$1" should not be strictly necessary according to POSIX rules,
but we saw reports that some shells "helpfully" give unnecessary
warnings when $1 (or whatever variable that holds the name of the file
the output is redirected into) contains $IFS characters.
* An indent in our shell scripts is a HT, not a SP (or four spaces or
whatever).
* And our convention is not to have an extra SP after redirection '>' (or
'<') operator.
> +test_expect_success 'init depot' '
> + (
> + cd "$cli" &&
> + echo file1 >file1 &&
> + p4 add file1 &&
> + p4 submit -d "change 1" &&
> + create_kw_file kwfile1.c &&
> + p4 add kwfile1.c &&
> + p4 submit -d "Add rcw kw file" kwfile1.c
> + )
> +'
> +
> +p4_append_to_file() {
> + f=$1
> + p4 edit -t ktext $f &&
> + echo "/* $(date) */" >> $f &&
> + p4 submit -d "appending a line in p4" &&
> + cat $f
> +}
Surround all occurrences of '$f' with double-quotes, e.g.
cat "$f"
to avoid unexpected breakage when later somebody tries to use a file whose
name happens to contain a space. The first assignment "f=$1" can stay as-is.
> +
> +# Create some files with RCS keywords. If they get modified
> +# elsewhere then the version number gets bumped which then
> +# results in a merge conflict if we touch the RCS kw lines,
> +# even though the change itself would otherwise apply cleanly.
> +test_expect_failure 'cope with rcs keyword expansion damage' '
> + "$GITP4" clone --dest="$git" //depot &&
> + cd "$git" &&
Please do not cd around in test script outside a subshell. Otherwise, any
failure in a subsequent command in this && chain before you reach the next
"cd" will leave you in an unexpected directory and can break later tests.
The worst example would be
test_expect_something 'one' '
mkdir -p git/play/pen &&
cd git/play/pen &&
do something &&
cd ../../.. &&
do something that potentially can fail &&
cd git/play/pen &&
do something
'
# blindly assuming the above succeeded up to the last 'cd git'
test_expect_something 'two' '
cd ../../.. &&
rm -fr git &&
do something else
'
If the first test fails in the middle before it brings you back down to
'git/play/pen' with the last 'cd git/playpen', then the next test moves
you up three levels and you will be running "rm -fr" on a wrong 'git'!
^ permalink raw reply
* Re: [PATCH 1/5] gitweb: Option for filling only specified info in fill_project_list_info
From: Jakub Narebski @ 2012-02-09 22:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vhayzvf38.fsf@alter.siamese.dyndns.org>
On Thu, 9 Feb 2012, Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
> > This could have been squashed with the next commit, but this way it is
> > pure refactoring that shouldn't change gitweb behavior.
>
> It is not obvious why this shouldn't change gitweb behaviour from the
> patch text.
>
> The old code says "Unconditionally call git_get_last_activity(), and if we
> found nothing, do not do anything extra for this project". The new code
> says "we do that but only if the project does not know its 'age' yet".
Well, till next patch in this series gitweb always filled some parts of
project info by processing $projects_list i.e. reading a file or scanning
a directory. Then fill_project_list_info was called to fill the rest
of projects data.
Which parts were filled in first step depends on whether $projects_list
is a file with list of projects or a directory to scan, but 'age' was
_never_ filled.
But I agree that it is not obvious.
I think that better solution would be to either squash 1/5 and 2/5, or
make 1/5 only about introduction of project_info_needs_filling(), without
@fill_only but with the 'age' check change.
> The lack of any real use of @fill_only in this patch also makes it hard to
> judge if the new API gives a useful semantics. I would, without looking
> at the real usage in 2/5 patch, naïvely expect that such a lazy filling
> scheme would say "I am going to use A, B and C; I want to know if any of
> them is missing, because I need values for all of them and I am going to
> call a helper function to fill them if any of them is missing. Having A
> and B is not enough for the purpose of this query, because I still need to
> know C and I would call the helper function that computes all of them in
> such a case. Even though it might be wasteful to recompute A and B,
> computing all three at once is the only helper function available to me".
>
> So for a person who does not have access to the real usage of the new API,
> being able to give only a single $key *appears* make no sense at all, and
> also the meaning of the @fill_only parameter is unclear, especially the
> part that checks if that single $key appears in @fill_only.
fill_project_list_info() is, at least after a fix with 'age', about filling
information that is not already present. If @fill_only is nonempty, it
fills only selected information, again only if it is not already present.
@fill_only empty means no restrictions... which probably is not very obvious,
but is documented.
project_info_needs_filling() returns true if $key is not filled and is
interesting.
> > Adding project_info_needs_filling() subroutine could have been split
> > into separate commit, but it would be subroutine without use...
> >
> > gitweb/gitweb.perl | 41 +++++++++++++++++++++++++++++++----------
> > 1 files changed, 31 insertions(+), 10 deletions(-)
> >
> > diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> > index 913a463..b7a3752 100755
> > --- a/gitweb/gitweb.perl
> > +++ b/gitweb/gitweb.perl
> > @@ -5185,35 +5185,56 @@ sub git_project_search_form {
> > print "</div>\n";
> > }
> >
> > +# entry for given $key doesn't need filling if either $key already exists
> > +# in $project_info hash, or we are interested only in subset of keys
> > +# and given key is not among @fill_only.
> > +sub project_info_needs_filling {
> > + my ($project_info, $key, @fill_only) = @_;
So in new version @fill_only will be removed...
> > +
> > + if (!@fill_only || # we are interested in everything
> > + grep { $key eq $_ } @fill_only) { # or key is in @fill_only
> > + # check if key is already filled
> > + return !exists $project_info->{$key};
...and this will be the only line of project_info_needs_filling() wrapper.
> > + }
> > + # uninteresting key, outside @fill_only
> > + return 0;
> > +}
> > +
> > # fills project list info (age, description, owner, category, forks)
> > # for each project in the list, removing invalid projects from
> > -# returned list
> > +# returned list, or fill only specified info (removing invalid projects
> > +# only when filling 'age').
> > +#
> > # NOTE: modifies $projlist, but does not remove entries from it
> > sub fill_project_list_info {
> > - my $projlist = shift;
> > + my ($projlist, @fill_only) = @_;
Here also @fill_only would be not present.
> > my @projects;
> >
> > my $show_ctags = gitweb_check_feature('ctags');
> > PROJECT:
> > foreach my $pr (@$projlist) {
> > - my (@activity) = git_get_last_activity($pr->{'path'});
> > - unless (@activity) {
> > - next PROJECT;
> > + if (project_info_needs_filling($pr, 'age', @fill_only)) {
This change makes 'age' not special.
[...]
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH v2] Explicitly set X to avoid potential build breakage
From: Junio C Hamano @ 2012-02-09 22:32 UTC (permalink / raw)
To: Michael Palimaka; +Cc: git
In-Reply-To: <1974397.vopy2n9Vpb@telegraph>
Thanks.
^ permalink raw reply
* Re: [PATCH 1/5] gitweb: Option for filling only specified info in fill_project_list_info
From: Junio C Hamano @ 2012-02-09 22:04 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <1328359648-29511-2-git-send-email-jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> This could have been squashed with the next commit, but this way it is
> pure refactoring that shouldn't change gitweb behavior.
It is not obvious why this shouldn't change gitweb behaviour from the
patch text.
The old code says "Unconditionally call git_get_last_activity(), and if we
found nothing, do not do anything extra for this project". The new code
says "we do that but only if the project does not know its 'age' yet".
The lack of any real use of @fill_only in this patch also makes it hard to
judge if the new API gives a useful semantics. I would, without looking
at the real usage in 2/5 patch, naïvely expect that such a lazy filling
scheme would say "I am going to use A, B and C; I want to know if any of
them is missing, because I need values for all of them and I am going to
call a helper function to fill them if any of them is missing. Having A
and B is not enough for the purpose of this query, because I still need to
know C and I would call the helper function that computes all of them in
such a case. Even though it might be wasteful to recompute A and B,
computing all three at once is the only helper function available to me".
So for a person who does not have access to the real usage of the new API,
being able to give only a single $key *appears* make no sense at all, and
also the meaning of the @fill_only parameter is unclear, especially the
part that checks if that single $key appears in @fill_only.
> Adding project_info_needs_filling() subroutine could have been split
> into separate commit, but it would be subroutine without use...
>
> gitweb/gitweb.perl | 41 +++++++++++++++++++++++++++++++----------
> 1 files changed, 31 insertions(+), 10 deletions(-)
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index 913a463..b7a3752 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -5185,35 +5185,56 @@ sub git_project_search_form {
> print "</div>\n";
> }
>
> +# entry for given $key doesn't need filling if either $key already exists
> +# in $project_info hash, or we are interested only in subset of keys
> +# and given key is not among @fill_only.
> +sub project_info_needs_filling {
> + my ($project_info, $key, @fill_only) = @_;
> +
> + if (!@fill_only || # we are interested in everything
> + grep { $key eq $_ } @fill_only) { # or key is in @fill_only
> + # check if key is already filled
> + return !exists $project_info->{$key};
> + }
> + # uninteresting key, outside @fill_only
> + return 0;
> +}
> +
> # fills project list info (age, description, owner, category, forks)
> # for each project in the list, removing invalid projects from
> -# returned list
> +# returned list, or fill only specified info (removing invalid projects
> +# only when filling 'age').
> +#
> # NOTE: modifies $projlist, but does not remove entries from it
> sub fill_project_list_info {
> - my $projlist = shift;
> + my ($projlist, @fill_only) = @_;
> my @projects;
>
> my $show_ctags = gitweb_check_feature('ctags');
> PROJECT:
> foreach my $pr (@$projlist) {
> - my (@activity) = git_get_last_activity($pr->{'path'});
> - unless (@activity) {
> - next PROJECT;
> + if (project_info_needs_filling($pr, 'age', @fill_only)) {
> + my (@activity) = git_get_last_activity($pr->{'path'});
> + unless (@activity) {
> + next PROJECT;
> + }
> + ($pr->{'age'}, $pr->{'age_string'}) = @activity;
> }
> - ($pr->{'age'}, $pr->{'age_string'}) = @activity;
> - if (!defined $pr->{'descr'}) {
> + if (project_info_needs_filling($pr, 'descr', @fill_only)) {
> my $descr = git_get_project_description($pr->{'path'}) || "";
> $descr = to_utf8($descr);
> $pr->{'descr_long'} = $descr;
> $pr->{'descr'} = chop_str($descr, $projects_list_description_width, 5);
> }
> - if (!defined $pr->{'owner'}) {
> + if (project_info_needs_filling($pr, 'owner', @fill_only)) {
> $pr->{'owner'} = git_get_project_owner("$pr->{'path'}") || "";
> }
> - if ($show_ctags) {
> + if ($show_ctags &&
> + project_info_needs_filling($pr, 'ctags', @fill_only)) {
> $pr->{'ctags'} = git_get_project_ctags($pr->{'path'});
> }
> - if ($projects_list_group_categories && !defined $pr->{'category'}) {
> + if ($projects_list_group_categories &&
> + project_info_needs_filling($pr, 'category', @fill_only)) {
> my $cat = git_get_project_category($pr->{'path'}) ||
> $project_list_default_category;
> $pr->{'category'} = to_utf8($cat);
^ permalink raw reply
* fatal: Unable to find remote helper for 'https'
From: Nickolai Leschov @ 2012-02-09 21:51 UTC (permalink / raw)
To: git
Hello,
I have compiled git 1.7.9 from source on Ubuntu 9.04 and I get the following
message when cloning a git repo:
fatal: Unable to find remote helper for 'https'
I get this message when I try to use https; or similar one for http. Only
cloning via git:// protocol works. My system is Ubuntu 9.04 i386. git 1.7.9 and
two previous versions I tried all exhibit this problem. I have uninstalled the
git that comes in Ubuntu repositories and build from source instead because I
need a newer version.
How can I make git work on that system?
I have another system with Ubuntu 11.04 i386 and it there git 1.7.4.1 (from
repositories) doesn't exhibit such problem.
Best regards,
Nickolai Leschov
^ permalink raw reply
* Re: Silly Question About Timing
From: Frans Klaver @ 2012-02-09 21:54 UTC (permalink / raw)
To: Seth Robertson, Hilco Wijbenga; +Cc: Git Users
In-Reply-To: <CAE1pOi14LW6ayNiRd2KogKZn2zLMbRsTS1kkMFgFBtx5J=yFNA@mail.gmail.com>
On Thu, 09 Feb 2012 22:48:25 +0100, Hilco Wijbenga
<hilco.wijbenga@gmail.com> wrote:
> ... and I have been unable to get the __git_ps1 part to do anything.
I get the following on msysgit:
/c/msysgit (devel) $ time __git_ps1
(devel)
real 0m0.406s
user 0m0.136s
sys 0m0.107s
Would be odd if that doesn't work on Linux.
^ permalink raw reply
* Re: Git, Builds, and Filesystem Type
From: Martin Fick @ 2012-02-09 21:53 UTC (permalink / raw)
To: Hilco Wijbenga; +Cc: Git Users
In-Reply-To: <CAE1pOi1of-hj+87M7RqhFUWA8an14bPG88dAOwhNogmfFvJ=tA@mail.gmail.com>
On Thursday, February 09, 2012 02:23:18 pm Hilco Wijbenga
wrote:
> For the record, our (Java) project is quite small. It's
> 43MB (source and images) and the entire directory tree
> after building is about 1.6GB (this includes all JARs
> downloaded by Maven). So we're not talking TBs of data.
>
> Any thoughts on which FSs to include in my tests? Or
> simply which FS might be more appropriate?
tmpfs is probably fastest hands down if you can use it (even
if you have to back it by swap).
-Martin
--
Employee of Qualcomm Innovation Center, Inc. which is a
member of Code Aurora Forum
^ permalink raw reply
* Re: git-subtree Ready for Inspection
From: David A. Greene @ 2012-02-09 21:52 UTC (permalink / raw)
To: Nazri Ramliy; +Cc: David A. Greene, Jan, git
In-Reply-To: <CAEY4ZpPs_3Ym=3gsVzwwXFAmk1DbgvvcdnK3p0WUaCOWg9TpMQ@mail.gmail.com>
Nazri Ramliy <ayiehere@gmail.com> writes:
> On Thu, Feb 9, 2012 at 1:02 PM, David A. Greene <greened@obbligato.org> wrote:
>> Do you mean running gitweb? Are you not able to access the above
>> repository? I can do that if it makes things easier but it will take a
>> bit of time.
>
> It asks for password:
>
> $ git clone gitolite@sources.obbligato.org:git.git
> Cloning into 'git'...
> gitolite@sources.obbligato.org's password:
Grr...Ok, I'll see if I can fix it or I will put up a gitweb fork.
-Dave
^ permalink raw reply
* Re: Silly Question About Timing
From: Hilco Wijbenga @ 2012-02-09 21:48 UTC (permalink / raw)
To: Seth Robertson; +Cc: Git Users
In-Reply-To: <201202092116.q19LGnTY024797@no.baka.org>
On 9 February 2012 13:16, Seth Robertson <in-gitvger@baka.org> wrote:
>
> In message <CAE1pOi1+FQNoPZ_P-fmFx-YhnUYzMQT=6zh3s-OyT71vcDm=wQ@mail.gmail.com>, Hilco Wijbenga writes:
>
> I've noticed that entering a Git controlled project directory takes
> quite some time so I wanted to measure exactly how much (it's the
> prompt I'm using that's taking the time, I suspect). I first tried (a
> bit naive, I admit :-) )
>
> time cd my-project
>
> Your confusion is because you are measuring the wrong thing. I'm
> assuming, here, that you have a shell prompt which is giving you all
> sorts of status about the git repository. The "cd" operation is
> instantaneous, it is the shell attempting to compute the new prompt
> which is slow.
Yes, exactly.
> Exactly how your shell does this is shell dependent, but you might
> want to look at your setting of $PROMPT_COMMAND. Then you can test it
> by running something like:
>
> time sh -c "cd git-directory; $PROMPT_COMMAND"
I tried that and it's still instantaneous.
The culprit is
export PS1='\[\033[01;32m\]\u@\h\[\033[01;34m\] \w \W$(__git_ps1 "
(%s)")\$\[\033[00m\] '
but I can't get that to run. Simply running
echo $PS1
doesn't work and I have been unable to get the __git_ps1 part to do anything.
^ permalink raw reply
* Re: git merge <tag>: Spawning an editor can't be disabled
From: Junio C Hamano @ 2012-02-09 21:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jonathan Nieder, Guido Günther, git
In-Reply-To: <7vpqdnvh3b.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Your approach is the right one, though. A patch for 1.7.9.1, on top of
> b5c9f1c (merge: do not create a signed tag merge under --ff-only option,
> 2012-02-05), would look like this, I think.
> ...
I tweaked the message to credit your initial analysis and added the
following test (again on top of b5c9f1c).
Thanks.
diff --git a/t/t7600-merge.sh b/t/t7600-merge.sh
index a598dfa..9e27bbf 100755
--- a/t/t7600-merge.sh
+++ b/t/t7600-merge.sh
@@ -683,4 +683,16 @@ test_expect_success GPG 'merge --ff-only tag' '
test_cmp actual expect
'
+test_expect_success GPG 'merge --no-edit tag should skip editor' '
+ git reset --hard c0 &&
+ git commit --allow-empty -m "A newer commit" &&
+ git tag -f -s -m "A newer commit" signed &&
+ git reset --hard c0 &&
+
+ EDITOR=false git merge --no-edit signed &&
+ git rev-parse signed^0 >expect &&
+ git rev-parse HEAD^2 >actual &&
+ test_cmp actual expect
+'
+
test_done
^ permalink raw reply related
* Git, Builds, and Filesystem Type
From: Hilco Wijbenga @ 2012-02-09 21:23 UTC (permalink / raw)
To: Git Users
Hi all,
I'm thinking about trying out different filesystems over the weekend
to see if, say, BTRFS or XFS is faster when using Git and running our
build.
Currently, I'm using ReiserFS and it's not like it's not working. I'm
very pleased with ReiserFS but after seeing talks about BTRFS and XFS
I'm curious if another (newer) FS is better suited to our specific
environment. Anything to make the build a little faster. :-)
For the record, our (Java) project is quite small. It's 43MB (source
and images) and the entire directory tree after building is about
1.6GB (this includes all JARs downloaded by Maven). So we're not
talking TBs of data.
Any thoughts on which FSs to include in my tests? Or simply which FS
might be more appropriate?
Cheers,
Hilco
^ permalink raw reply
* Re: git merge <tag>: Spawning an editor can't be disabled
From: Junio C Hamano @ 2012-02-09 21:20 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Guido Günther, git
In-Reply-To: <20120209160803.GA5742@burratino>
Jonathan Nieder <jrnieder@gmail.com> writes:
> Patch relies on "merge: use editor by default in interactive sessions"
> from master. If this looks like a sane approach, I can resend with a
> proposed log message and a test for t/t7600-merge.sh. (Or if someone
> else wants to do it first, even better.)
Please do not depend on that one that will never be merged to 1.7.9.x
maintenance track.
Your approach is the right one, though. A patch for 1.7.9.1, on top of
b5c9f1c (merge: do not create a signed tag merge under --ff-only option,
2012-02-05), would look like this, I think.
I think various "0 < option_edit" we can find in f824628 (merge: use
editor by default in interactive sessions, 2012-01-10) and f26af3f (merge:
add instructions to the commit message when editing, 2012-01-30) can and
should be reverted back to just "option_edit", as nobody should be looking
at option_edit before the "if edit is negative, set it to the default" we
can see in the last hunk of this patch (except for the "merging tag? turn
editing on by default unless --no-edit is given" that is the topic of this
thread).
Thanks.
-- >8 --
Subject: merge: do not launch an editor on "--no-edit $tag"
When the user explicitly asked us not to, don't launch an editor.
But do everything else the same way as the "edit" case, i.e. leave the
comment with verification result in the log template and record the
mergesig in the resulting merge commit for later inspection.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin/merge.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/builtin/merge.c b/builtin/merge.c
index b4fbc60..f385b8a 100644
--- a/builtin/merge.c
+++ b/builtin/merge.c
@@ -48,7 +48,7 @@ static const char * const builtin_merge_usage[] = {
static int show_diffstat = 1, shortlog_len = -1, squash;
static int option_commit = 1, allow_fast_forward = 1;
-static int fast_forward_only, option_edit;
+static int fast_forward_only, option_edit = -1;
static int allow_trivial = 1, have_message;
static int overwrite_ignore = 1;
static struct strbuf merge_msg = STRBUF_INIT;
@@ -193,7 +193,7 @@ static struct option builtin_merge_options[] = {
"create a single commit instead of doing a merge"),
OPT_BOOLEAN(0, "commit", &option_commit,
"perform a commit if the merge succeeds (default)"),
- OPT_BOOLEAN('e', "edit", &option_edit,
+ OPT_BOOL('e', "edit", &option_edit,
"edit message before committing"),
OPT_BOOLEAN(0, "ff", &allow_fast_forward,
"allow fast-forward (default)"),
@@ -1287,11 +1287,15 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
merge_remote_util(commit) &&
merge_remote_util(commit)->obj &&
merge_remote_util(commit)->obj->type == OBJ_TAG) {
- option_edit = 1;
+ if (option_edit < 0)
+ option_edit = 1;
allow_fast_forward = 0;
}
}
+ if (option_edit < 0)
+ option_edit = 0;
+
if (!use_strategies) {
if (!remoteheads->next)
add_strategies(pull_twohead, DEFAULT_TWOHEAD);
^ permalink raw reply related
* Re: Silly Question About Timing
From: Seth Robertson @ 2012-02-09 21:16 UTC (permalink / raw)
To: Hilco Wijbenga; +Cc: Git Users
In-Reply-To: <CAE1pOi1+FQNoPZ_P-fmFx-YhnUYzMQT=6zh3s-OyT71vcDm=wQ@mail.gmail.com>
In message <CAE1pOi1+FQNoPZ_P-fmFx-YhnUYzMQT=6zh3s-OyT71vcDm=wQ@mail.gmail.com>, Hilco Wijbenga writes:
I've noticed that entering a Git controlled project directory takes
quite some time so I wanted to measure exactly how much (it's the
prompt I'm using that's taking the time, I suspect). I first tried (a
bit naive, I admit :-) )
time cd my-project
Your confusion is because you are measuring the wrong thing. I'm
assuming, here, that you have a shell prompt which is giving you all
sorts of status about the git repository. The "cd" operation is
instantaneous, it is the shell attempting to compute the new prompt
which is slow.
Exactly how your shell does this is shell dependent, but you might
want to look at your setting of $PROMPT_COMMAND. Then you can test it
by running something like:
time sh -c "cd git-directory; $PROMPT_COMMAND"
-Seth Robertson
^ permalink raw reply
* Silly Question About Timing
From: Hilco Wijbenga @ 2012-02-09 21:10 UTC (permalink / raw)
To: Git Users
Hi all,
This is a bit silly but I'm trying to time how long it takes to enter
a Git controlled directory. I guess this is more of a GNU/Linux
question then anything else.
I've noticed that entering a Git controlled project directory takes
quite some time so I wanted to measure exactly how much (it's the
prompt I'm using that's taking the time, I suspect). I first tried (a
bit naive, I admit :-) )
time cd my-project
This doesn't work of course. Obviously, writing a script doesn't work
either because then the prompt isn't calculated. Next I tried
date +%H:%M:%S.%N ; cd my-project-abc ; date +%H:%M:%S.%N
but, surprisingly (to me), that doesn't work either. It simply prints
the two timestamps and *then* does the cd (or, at least, that's how it
seems to behave).
So how would one do this? :-)
Cheers,
Hilco
P.S. This slow cd is only the first time, afterwards things have been cached.
^ permalink raw reply
* Re: Git performance results on a large repository
From: Joshua Redstone @ 2012-02-09 21:06 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git@vger.kernel.org
In-Reply-To: <CACsJy8AxOZQ7S42V1g-b0vdBxPpjhFZe6qDkGaALnxQ6LiUssw@mail.gmail.com>
Hi Nguyen,
I like the notion of using --assume-unchanged to cut down the set of
things that git considers may have changed.
It seems to me that there may still be situations that require operations
on the order of the # of files in the repo and hence may still be slow.
Following is a list of potential candidates that occur to me.
1. Switching branches, especially if you switch to an old branch.
Sometimes I've seen branch switching taking a long time for what I thought
was close to where HEAD was.
2. Interactive rebase in which you reorder a few commits close to the tip
of the branch (I observed this taking a long time, but haven't profiled it
yet). I include here other types of cherry-picking of commits.
3. Any working directory operations that fail part-way through and make
you want to do a 'git reset --hard' or at least a full 'git-status'. That
is, when you have reason to believe that files with 'assume-unchange' may
have accidentally changed.
4. Operations that require rewriting the index - I think git-add is one?
If the working-tree representation is the full set of all files
materialized on disk and it's the same as the representation of files
changed, then I'm not sure how to avoid some of these without playing file
system games or using wrapper scripts.
What do you (or others) think?
Josh
On 2/7/12 8:43 AM, "Nguyen Thai Ngoc Duy" <pclouds@gmail.com> wrote:
>On Mon, Feb 6, 2012 at 10:40 PM, Joey Hess <joey@kitenet.net> wrote:
>>> Someone on HN suggested making assume-unchanged files read-only to
>>> avoid 90% accidentally changing a file without telling git. When
>>> assume-unchanged bit is cleared, the file is made read-write again.
>>
>> That made me think about using assume-unchanged with git-annex since it
>> already has read-only files.
>>
>> But, here's what seems a misfeature...
>
>because, well.. assume-unchanged was designed to avoid stat() and
>nothing else. We are basing a new feature on top of it.
>
>> If an assume-unstaged file has
>> modifications and I git add it, nothing happens. To stage a change, I
>> have to explicitly git update-index --no-assume-unchanged and only then
>> git add, and then I need to remember to reset the assume-unstaged bit
>> when I'm done working on that file for now. Compare with running git mv
>> on the same file, which does stage the move despite assume-unstaged. (So
>> does git rm.)
>
>This is normal in the lock-based "checkout/edit/checkin" model. mv/rm
>operates on directory content, which is not "locked - no edit allowed"
>(in our case --assume-unchanged) in git. But lock-based model does not
>map really well to git anyway. It does not have the index (which may
>make things more complicated). Also at index level, git does not
>really understand directories.
>
>I think we could add a protection layer to index, where any changes
>(including removal) to an index entry are only allowed if the entry is
>"unlocked" (i.e no assume-unchanged bit). Locked entries are read-only
>and have assume-unchanged bit set. "git (un)lock" are introduced as
>new UI. Does that make assume-unchanged friendlier?
>--
>Duy
>--
>To unsubscribe from this list: send the line "unsubscribe git" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/2] git-svn.perl: perform deletions before anything else
From: Thomas Rast @ 2012-02-09 20:55 UTC (permalink / raw)
To: Steven Walter; +Cc: normalperson, git
In-Reply-To: <CAK8d-aJ3wi0e_NPunow-aBnhs1=o5K25r3e-Ha0m1U0ujTv7OA@mail.gmail.com>
Oops, as Steven noticed I accidentally hit the wrong reply button. So
here's my earlier reply and his answer.
Steven Walter <stevenrwalter@gmail.com> writes:
> On Thu, Feb 9, 2012 at 2:16 PM, Thomas Rast <trast@inf.ethz.ch> wrote:
>> Steven Walter <stevenrwalter@gmail.com> writes:
>>
>>> If we delete a file and recreate it as a directory in a single commit,
>>> we have to tell the server about the deletion first or else we'll get
>>> "RA layer request failed: Server sent unexpected return value (405
>>> Method Not Allowed) in response to MKCOL request"
>> [...]
>>> - my %o = ( D => 1, R => 0, C => -1, A => 3, M => 3, T => 3 );
>>> + my %o = ( D => -2, R => 0, C => -1, A => 3, M => 3, T => 3 );
>>
>> You are making it delete first, but the original code seems to quite
>> deliberately put deletion after R (rename?). Are you sure you're not
>> breaking anything else?
>
> No, I'm not 100% sure of that.
>
> In fact, looking at cf52b8f063 where this code seems to have started,
> it lists my case explicitly as one that subversion does not support:
>
> "a file is removed and a directory of the same name of the removed
> file is created."
>
> One thing that might make a difference is that the "file" that removed
> was actually a symlink. So either svn treats symlinks as a special
> case to that rule, or else the limitation the commit was meant to
> address is not present on recent versions of svn. I can run some
> checks to see if that is the case.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: [PATCH 1/2] git-svn.perl: perform deletions before anything else
From: Steven Walter @ 2012-02-09 20:52 UTC (permalink / raw)
To: gitster, normalperson, git
In-Reply-To: <7vzkcrvkfa.fsf@alter.siamese.dyndns.org>
> I suspect that writing it this way [...] would make it much easier to
> follow.
Agreed. New patch to follow, this time with sign-off.
^ permalink raw reply
* [PATCH 1/2] git-svn.perl: perform deletions before anything else
From: Steven Walter @ 2012-02-09 20:52 UTC (permalink / raw)
To: gitster, normalperson, git; +Cc: Steven Walter, Steven Walter
In-Reply-To: <1328820742-4795-1-git-send-email-stevenrwalter@gmail.com>
From: Steven Walter <swalter@lexmark.com>
If we delete a file and recreate it as a directory in a single commit,
we have to tell the server about the deletion first or else we'll get
"RA layer request failed: Server sent unexpected return value (405
Method Not Allowed) in response to MKCOL request"
Signed-off-by: Steven Walter <stevenrwalter@gmail.com>
---
git-svn.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index eeb83d3..06c9322 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -5374,7 +5374,7 @@ sub DESTROY {
sub apply_diff {
my ($self) = @_;
my $mods = $self->{mods};
- my %o = ( D => 1, R => 0, C => -1, A => 3, M => 3, T => 3 );
+ my %o = ( D => 0, C => 1, R => 2, A => 3, M => 4, T => 5 );
foreach my $m (sort { $o{$a->{chg}} <=> $o{$b->{chg}} } @$mods) {
my $f = $m->{chg};
if (defined $o{$f}) {
--
1.7.5.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox