* 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: 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: 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
* 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: [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
* 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: 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: [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
* [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
* [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 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
* 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
* 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: [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: 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: [PATCH 1/5] gitweb: Option for filling only specified info in fill_project_list_info
From: Jakub Narebski @ 2012-02-09 23:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v4nuzvbnr.fsf@alter.siamese.dyndns.org>
On Fri, 10 Feb 2012, Junio C Hamano wrote:
> 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"?
project_info_needs_filling() in absence of @fill_only is just a thin
wrapper around "!defined $pr->{$key}", it checks for each key if it needs
to be filled.
It is used like this
if (project_info_needs_filled("A", "A, B, C")) {
fill A
}
if (project_info_needs_filled("B", "A, B, C")) {
fill B
}
...
> 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.
It is not as much matter of API, as the use of checks in loop in
fill_project_list_info().
What is now
my (@activity) = git_get_last_activity($pr->{'path'});
unless (@activity) {
next PROJECT;
}
($pr->{'age'}, $pr->{'age_string'}) = @activity;
should be
if (!defined $pr->{'age'} ||
!defined $pr->{'age_string'}) {
my (@activity) = git_get_last_activity($pr->{'path'});
unless (@activity) {
next PROJECT;
}
($pr->{'age'}, $pr->{'age_string'}) = @activity;
}
which would translate to
if (project_info_needs_filled($pr, 'age') ||
project_info_needs_filled($pr, 'age_string') {
my (@activity) = git_get_last_activity($pr->{'path'});
unless (@activity) {
next PROJECT;
}
($pr->{'age'}, $pr->{'age_string'}) = @activity;
}
and then with @fill_only
if (project_info_needs_filled($pr, 'age', @fill_only) ||
project_info_needs_filled($pr, 'age_string', @fill_only) {
my (@activity) = git_get_last_activity($pr->{'path'});
unless (@activity) {
next PROJECT;
}
($pr->{'age'}, $pr->{'age_string'}) = @activity;
}
The same should be done for 'descr_long' and 'descr' which are also
always filled together.
--
Jakub Narebski
Poland
^ 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:56 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <201202100052.26399.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> On Fri, 10 Feb 2012, Junio C Hamano wrote:
> ...
>> 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"?
>
> project_info_needs_filling() in absence of @fill_only is just a thin
> wrapper around "!defined $pr->{$key}", it checks for each key if it needs
> to be filled.
>
> It is used like this
>
> if (project_info_needs_filled("A", "A, B, C")) {
> fill A
> }
> if (project_info_needs_filled("B", "A, B, C")) {
> fill B
> }
> ...
>
>> 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.
>
> It is not as much matter of API, as the use of checks in loop in
> fill_project_list_info().
>
> What is now
>
> my (@activity) = git_get_last_activity($pr->{'path'});
> unless (@activity) {
> next PROJECT;
> }
> ($pr->{'age'}, $pr->{'age_string'}) = @activity;
>
> should be
>
> if (!defined $pr->{'age'} ||
> !defined $pr->{'age_string'}) {
> my (@activity) = git_get_last_activity($pr->{'path'});
> unless (@activity) {
> next PROJECT;
> }
> ($pr->{'age'}, $pr->{'age_string'}) = @activity;
> }
Huh? Compare that with what you wrote above "It is used like this". This
is *NOT* using the API like that. The caller knows it wants both age and
age-string, and if even one of them is missing, do the work to fill both.
So why isn't the info-needs-filled API not checking _both_ with a single
call? It is only because you designed the API to accept only a single $key
instead of list of "here are what I care about".
^ permalink raw reply
* Re: [RFC/PATCH] tag: make list exclude !<pattern>
From: Tom Grennan @ 2012-02-10 0:00 UTC (permalink / raw)
To: git; +Cc: gitster, peff
In-Reply-To: <1328816616-18124-2-git-send-email-tmgrennan@gmail.com>
On Thu, Feb 09, 2012 at 11:43:36AM -0800, Tom Grennan wrote:
>Use the "!" prefix to ignore tags of the given pattern.
>This has precedence over other matching patterns.
>For example,
...
> static int match_pattern(const char **patterns, const char *ref)
> {
>+ int ret;
>+
> /* no pattern means match everything */
> if (!*patterns)
> return 1;
>- for (; *patterns; patterns++)
>- if (!fnmatch(*patterns, ref, 0))
>- return 1;
>- return 0;
>+ for (ret = 0; *patterns; patterns++)
>+ if (**patterns == '!') {
>+ if (!fnmatch(*patterns+1, ref, 0))
>+ return 0;
>+ } else if (!fnmatch(*patterns, ref, 0))
>+ ret = 1;
>+ return ret;
> }
Correction, match_pattern() needs to be as follows to support all these cases,
$ git tag -l
$ git tag -l \!*-rc?
$ git tag -l \!*-rc? v1.7.8*
$ git tag -l v1.7.8* \!*-rc?
$ git tag -l v1.7.8*
--
TomG
diff --git a/builtin/tag.c b/builtin/tag.c
index 31f02e8..e99be5c 100644
--- a/builtin/tag.c
+++ b/builtin/tag.c
@@ -32,13 +32,16 @@ struct tag_filter {
static int match_pattern(const char **patterns, const char *ref)
{
- /* no pattern means match everything */
- if (!*patterns)
- return 1;
+ int had_match_pattern = 0, had_match = 0;
+
for (; *patterns; patterns++)
- if (!fnmatch(*patterns, ref, 0))
- return 1;
- return 0;
+ if (**patterns != '!') {
+ had_match_pattern = 1;
+ if (!fnmatch(*patterns, ref, 0))
+ had_match = 1;
+ } else if (!fnmatch(*patterns+1, ref, 0))
+ return 0;
+ return had_match_pattern ? had_match : 1;
}
static int in_commit_list(const struct commit_list *want, struct commit *c)
^ permalink raw reply related
* What's cooking in git.git (Feb 2012, #03; Thu, 9)
From: Junio C Hamano @ 2012-02-10 0:15 UTC (permalink / raw)
To: git
What's cooking in git.git (Feb 2012, #03; Thu, 9)
--------------------------------------------------
Here are the topics that have been cooking. Commits prefixed with '-' are
only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'.
Compared to the recent activity level on discussions of new features on
the list, some people may be wondering if the rate of advancement of the
'master' and 'next' branches is getting throttled.
That is because it is.
Now the obviously good bits that have been cooking during the feature
freeze are pushed out to 'master', I'd want to make sure we can have a
timely release of v1.7.9.1 so that people can start benefiting from the
features and fixes introduced in v1.7.9 more smoothly and sooner, and that
is where my focus lies at this moment. I've been picking up new topics and
adding them to 'pu' only "as time and attention permit" basis, and this
mode of operation probably will continue throughout the second week of the
post v1.7.9 cycle (cf. http://tinyurl.com/gitcal).
I would like to see more people test the tip of 'pu' as soon as possible
to make sure the fixes to 'git merge' give more pleasant user experience
than stock 1.7.9 release. Things to expect are:
* "git merge --ff-only v3.2" that should fast-forward to the commit that
is tagged should fast-forward, without creating the merge commit that
records the contents taken from v3.2 tag (the topic
jc/merge-ff-only-stronger-than-signed-merge in 'next' should take care
of this issue);
* "git merge --no-edit v3.2" does not spawn an editor, but does create
the merge commit to record the contents taken from v3.2 tag (the topic
jn/merge-no-edit-fix in 'pu' should take care of this issue).
You can find the changes described here in the integration branches of the
repositories listed at
http://git-blame.blogspot.com/p/git-public-repositories.html
--------------------------------------------------
[Graduated to "master"]
* bl/gitweb-project-filter (2012-02-01) 8 commits
(merged to 'next' on 2012-02-01 at 2c96ce7)
+ gitweb: Make project search respect project_filter
+ gitweb: improve usability of projects search form
+ gitweb: place links to parent directories in page header
+ gitweb: show active project_filter in project_list page header
+ gitweb: limit links to alternate forms of project_list to active project_filter
+ gitweb: add project_filter to limit project list to a subdirectory
+ gitweb: prepare git_get_projects_list for use outside 'forks'.
+ gitweb: move hard coded .git suffix out of git_get_projects_list
"gitweb" allows intermediate entries in the directory hierarchy that leads
to a projects to be clicked, which in turn shows the list of projects
inside that directory.
* jc/maint-request-pull-for-tag (2012-01-31) 1 commit
(merged to 'next' on 2012-02-01 at 7649f18)
+ request-pull: explicitly ask tags/$name to be pulled
When asking for a tag to be pulled, "request-pull" shows the name of the
tag prefixed with "tags/"
* jn/svn-fe (2012-02-02) 47 commits
(merged to 'next' on 2012-02-05 at e9d3917)
+ vcs-svn: suppress a -Wtype-limits warning
+ vcs-svn: allow import of > 4GiB files
+ vcs-svn: rename check_overflow arguments for clarity
(merged to 'next' on 2012-02-01 at 9288c95)
+ vcs-svn/svndiff.c: squelch false "unused" warning from gcc
+ Merge branch 'svn-fe' of git://repo.or.cz/git/jrn into jn/svn-fe
+ vcs-svn: reset first_commit_done in fast_export_init
+ Merge branch 'db/text-delta' into svn-fe
+ vcs-svn: do not initialize report_buffer twice
+ Merge branch 'db/text-delta' into svn-fe
+ vcs-svn: avoid hangs from corrupt deltas
+ vcs-svn: guard against overflow when computing preimage length
+ Merge branch 'db/delta-applier' into db/text-delta
+ vcs-svn: implement text-delta handling
+ Merge branch 'db/delta-applier' into db/text-delta
+ Merge branch 'db/delta-applier' into svn-fe
+ vcs-svn: cap number of bytes read from sliding view
+ test-svn-fe: split off "test-svn-fe -d" into a separate function
+ vcs-svn: let deltas use data from preimage
+ vcs-svn: let deltas use data from postimage
+ vcs-svn: verify that deltas consume all inline data
+ vcs-svn: implement copyfrom_data delta instruction
+ vcs-svn: read instructions from deltas
+ vcs-svn: read inline data from deltas
+ vcs-svn: read the preimage when applying deltas
+ vcs-svn: parse svndiff0 window header
+ vcs-svn: skeleton of an svn delta parser
+ vcs-svn: make buffer_read_binary API more convenient
+ vcs-svn: learn to maintain a sliding view of a file
+ Makefile: list one vcs-svn/xdiff object or header per line
+ Merge branch 'db/svn-fe-code-purge' into svn-fe
+ vcs-svn: drop obj_pool
+ vcs-svn: drop treap
+ vcs-svn: drop string_pool
+ vcs-svn: pass paths through to fast-import
+ Merge branch 'db/strbufs-for-metadata' into db/svn-fe-code-purge
+ Merge branch 'db/length-as-hash' (early part) into db/svn-fe-code-purge
+ Merge branch 'db/vcs-svn-incremental' into svn-fe
+ vcs-svn: avoid using ls command twice
+ vcs-svn: use mark from previous import for parent commit
+ vcs-svn: handle filenames with dq correctly
+ vcs-svn: quote paths correctly for ls command
+ vcs-svn: eliminate repo_tree structure
+ vcs-svn: add a comment before each commit
+ vcs-svn: save marks for imported commits
+ vcs-svn: use higher mark numbers for blobs
+ vcs-svn: set up channel to read fast-import cat-blob response
+ Merge commit 'v1.7.5' into svn-fe
Originally merged to 'next' on 2012-01-29.
"vcs-svn"/"svn-fe" learned to read dumps with svn-deltas and support
incremental imports.
* jx/i18n-more-marking (2012-02-01) 2 commits
(merged to 'next' on 2012-02-05 at 44e8cf6)
+ i18n: format_tracking_info "Your branch is behind" message
+ i18n: git-commit whence_s "merge/cherry-pick" message
Marks a few more messages we forgot to mark for i18n.
* rt/completion-branch-edit-desc (2012-01-29) 1 commit
(merged to 'next' on 2012-02-01 at 0627ebf)
+ completion: --edit-description option for git-branch
Originally merged to 'next' on 2012-01-31.
--------------------------------------------------
[New Topics]
* jk/config-include (2012-02-06) 2 commits
- config: add include directive
- docs: add a basic description of the config API
An assignment to the include.path pseudo-variable causes the named file
to be included in-place when Git looks up configuration variables.
* jk/maint-tag-show-fixes (2012-02-08) 3 commits
(merged to 'next' on 2012-02-08 at 18459c4)
+ tag: do not show non-tag contents with "-n"
+ tag: die when listing missing or corrupt objects
+ tag: fix output of "tag -n" when errors occur
Bugfixes to "git tag -n" that lacked much error checking.
* mm/empty-loose-error-message (2012-02-06) 1 commit
(merged to 'next' on 2012-02-07 at f119cac)
+ fsck: give accurate error message on empty loose object files
Updates the error message emitted when we see an empty loose object.
* nd/columns (2012-02-08) 15 commits
- column: Fix some compiler and sparse warnings
- column: add a corner-case test to t3200
- columns: minimum coding style fixes
- tag: add --column
- column: support piping stdout to external git-column process
- status: add --column
- branch: add --column
- help: reuse print_columns() for help -a
- column: add column.ui for default column output settings
- column: support columns with different widths
- column: add columnar layout
- Stop starting pager recursively
- Add git-column and column mode parsing
- column: add API to print items in columns
- Save terminal width before setting up pager
The "show list of ..." mode of a handful of commands learn to produce
column-oriented output.
Expecting a reroll.
* jc/maint-commit-ignore-i-t-a (2012-02-07) 1 commit
- commit: ignore intent-to-add entries instead of refusing
Replaces the nd/commit-ignore-i-t-a series that was made unnecessary
complicated by bad suggestions I made earlier.
* jk/userdiff-config-simplify (2012-02-07) 1 commit
- drop odd return value semantics from userdiff_config
Code cleanup.
* js/add-e-submodule-fix (2012-02-07) 1 commit
(merged to 'next' on 2012-02-08 at c8e2d28)
+ add -e: do not show difference in a submodule that is merely dirty
"add -e" learned not to show a diff for an otherwise unmodified submodule
that only has uncommitted local changes in the patch prepared by for the
user to edit.
* nd/cache-tree-api-refactor (2012-02-07) 1 commit
(merged to 'next' on 2012-02-08 at a9abbca)
+ cache-tree: update API to take abitrary flags
Code cleanup.
* tg/tag-points-at (2012-02-08) 1 commit
- tag: add --points-at list option
Will merge to 'next'.
* jl/maint-submodule-relative (2012-02-09) 2 commits
- submodules: always use a relative path from gitdir to work tree
- submodules: always use a relative path to gitdir
* jn/merge-no-edit-fix (2012-02-09) 1 commit
- merge: do not launch an editor on "--no-edit $tag"
(this branch uses jc/merge-ff-only-stronger-than-signed-merge.)
* ld/git-p4-expanded-keywords (2012-02-09) 2 commits
- git-p4: initial demonstration of possible RCS keyword fixup
- git-p4: add test case for RCS keywords
* mp/make-cleanse-x-for-exe (2012-02-09) 1 commit
(merged to 'next' on 2012-02-09 at 35cc89d)
+ Explicitly set X to avoid potential build breakage
--------------------------------------------------
[Stalled]
* jc/advise-push-default (2011-12-18) 1 commit
- push: hint to use push.default=upstream when appropriate
Peff had a good suggestion outlining an updated code structure so that
somebody new can try to dip his or her toes in the development. Any
takers?
* ss/git-svn-prompt-sans-terminal (2012-01-04) 3 commits
- fixup! 15eaaf4
- git-svn, perl/Git.pm: extend Git::prompt helper for querying users
- perl/Git.pm: "prompt" helper to honor GIT_ASKPASS and SSH_ASKPASS
The bottom one has been replaced with a rewrite based on comments from
Ævar. The second one needs more work, both in perl/Git.pm and prompt.c, to
give precedence to tty over SSH_ASKPASS when terminal is available.
* jc/split-blob (2012-01-24) 6 commits
- chunked-object: streaming checkout
- chunked-object: fallback checkout codepaths
- bulk-checkin: support chunked-object encoding
- bulk-checkin: allow the same data to be multiply hashed
- new representation types in the packstream
- varint-in-pack: refactor varint encoding/decoding
Not ready.
I finished the streaming checkout codepath, but as explained in 127b177
(bulk-checkin: support chunked-object encoding, 2011-11-30), these are
still early steps of a long and painful journey. At least pack-objects and
fsck need to learn the new encoding for the series to be usable locally,
and then index-pack/unpack-objects needs to learn it to be used remotely.
Given that I heard a lot of noise that people want large files, and that I
was asked by somebody at GitTogether'11 privately for an advice on how to
pay developers (not me) to help adding necessary support, I am somewhat
dissapointed that the original patch series that was sent almost two
months ago still remains here without much comments and updates from the
developer community. I even made the interface to the logic that decides
where to split chunks easily replaceable, and I deliberately made the
logic in the original patch extremely stupid to entice others, especially
the "bup" fanboys, to come up with a better logic, thinking that giving
people an easy target to shoot for, they may be encouraged to help
out. The plan is not working :-(.
--------------------------------------------------
[Cooking]
* bw/inet-pton-ntop-compat (2012-02-05) 1 commit
(merged to 'next' on 2012-02-06 at 61303e6)
+ Drop system includes from inet_pton/inet_ntop compatibility wrappers
The inclusion order of header files bites Solaris again and this fixes it.
* jc/branch-desc-typoavoidance (2012-02-05) 2 commits
(merged to 'next' on 2012-02-06 at 9fb0568)
+ branch --edit-description: protect against mistyped branch name
+ tests: add write_script helper function
(this branch is tangled with jk/tests-write-script.)
Typo in "git branch --edit-description my-tpoic" was not diagnosed.
* jc/checkout-out-of-unborn (2012-02-06) 1 commit
(merged to 'next' on 2012-02-07 at 60eb328)
+ git checkout -b: allow switching out of an unborn branch
I was fairly negative on this one, but Michael Haggerty and Peff convinced
me that selling this as "'checkout -b' that lack the <start point> is
about creating a new branch from my current state" is perfectly fine.
* jc/maint-mailmap-output (2012-02-06) 1 commit
(merged to 'next' on 2012-02-06 at 0a21425)
+ mailmap: always return a plain mail address from map_user()
map_user() was not rewriting its output correctly, which resulted in the
user visible symptom that "git blame -e" sometimes showed excess '>' at
the end of email addresses.
* jc/merge-ff-only-stronger-than-signed-merge (2012-02-05) 1 commit
(merged to 'next' on 2012-02-06 at 0fabf12)
+ merge: do not create a signed tag merge under --ff-only option
(this branch is used by jn/merge-no-edit-fix.)
"git merge --ff-only $tag" failed because it cannot record the required
mergetag without creating a merge, but this is so common operation for
branch that is used _only_ to follow the upstream, so it is allowed to
fast-forward without recording the mergetag.
* tt/profile-build-fix (2012-02-09) 2 commits
(merged to 'next' on 2012-02-09 at 1c183af)
+ Makefile: fix syntax for older make
(merged to 'next' on 2012-02-07 at c8c5f3f)
+ Fix build problems related to profile-directed optimization
* nd/diffstat-gramnum (2012-02-03) 1 commit
(merged to 'next' on 2012-02-05 at 7335ecc)
+ Use correct grammar in diffstat summary line
The commands in the "git diff" family and "git apply --stat" that count
the number of files changed and the number of lines inserted/deleted have
been updated to match the output from "diffstat". This also opens the
door to i18n this line.
* jk/grep-binary-attribute (2012-02-02) 9 commits
(merged to 'next' on 2012-02-05 at 9dffa7e)
+ grep: pre-load userdiff drivers when threaded
+ grep: load file data after checking binary-ness
+ grep: respect diff attributes for binary-ness
+ grep: cache userdiff_driver in grep_source
+ grep: drop grep_buffer's "name" parameter
+ convert git-grep to use grep_source interface
+ grep: refactor the concept of "grep source" into an object
+ grep: move sha1-reading mutex into low-level code
+ grep: make locking flag global
Fixes a longstanding bug that there was no way to tell "git grep" that a
path may look like text but it is not, which "git diff" can do using the
attributes system. Now "git grep" honors the same "binary" (or "-diff")
attribute.
* jc/parse-date-raw (2012-02-03) 2 commits
(merged to 'next' on 2012-02-07 at 486ae6e)
+ parse_date(): '@' prefix forces git-timestamp
+ parse_date(): allow ancient git-timestamp
"rebase" and "commit --amend" failed to work on commits with ancient
timestamps near year 1970.
* jk/git-dir-lookup (2012-02-02) 1 commit
(merged to 'next' on 2012-02-05 at 1856d74)
+ standardize and improve lookup rules for external local repos
When you have both .../foo and .../foo.git, "git clone .../foo" did not
favor the former but the latter.
* jk/prompt-fallback-to-tty (2012-02-03) 2 commits
(merged to 'next' on 2012-02-06 at c0c995a)
+ prompt: fall back to terminal if askpass fails
+ prompt: clean up strbuf usage
The code to ask for password did not fall back to the terminal input when
GIT_ASKPASS is set but does not work (e.g. lack of X with GUI askpass
helper).
* jk/tests-write-script (2012-02-03) 2 commits
(merged to 'next' on 2012-02-05 at 4264ffa)
+ t0300: use write_script helper
+ tests: add write_script helper function
(this branch is tangled with jc/branch-desc-typoavoidance.)
* jn/gitweb-search-utf-8 (2012-02-03) 1 commit
(merged to 'next' on 2012-02-05 at 055e446)
+ gitweb: Allow UTF-8 encoded CGI query parameters and path_info
Search box in "gitweb" did not accept non-ASCII characters correctly.
* jn/rpm-spec (2012-02-03) 1 commit
(merged to 'next' on 2012-02-05 at dba940b)
+ git.spec: Workaround localized messages not put in any RPM
Fix breakage in v1.7.9 Makefile; rpmbuild notices an unpackaged but
installed *.mo file and fails.
* fc/zsh-completion (2012-02-06) 3 commits
(merged to 'next' on 2012-02-06 at c94dd12)
+ completion: simplify __gitcomp and __gitcomp_nl implementations
+ completion: use ls -1 instead of rolling a loop to do that ourselves
+ completion: work around zsh option propagation bug
Fix git subcommand completion for zsh (in contrib/completion).
* nd/find-pack-entry-recent-cache-invalidation (2012-02-01) 2 commits
(merged to 'next' on 2012-02-01 at e26aed0)
+ find_pack_entry(): do not keep packed_git pointer locally
+ sha1_file.c: move the core logic of find_pack_entry() into fill_pack_entry()
* nd/pack-objects-parseopt (2012-02-01) 3 commits
(merged to 'next' on 2012-02-05 at d0dc25d)
+ pack-objects: convert to use parse_options()
+ pack-objects: remove bogus comment
+ pack-objects: do not accept "--index-version=version,"
"pack-objects" learned use parse-options, losing custom command line
parsing code.
--------------------------------------------------
[Discarded]
* nd/commit-ignore-i-t-a (2012-02-06) 4 commits
. commit: remove commit.ignoreIntentToAdd, assume it's always true
. commit: turn commit.ignoreIntentToAdd to true by default
. commit: introduce a config key to allow as-is commit with i-t-a entries
. cache-tree: update API to take abitrary flags
Instead of using configuration to selectively delay bugfixes like this
series does, let's sell it as a pure bugfix.
^ permalink raw reply
* Re: Git documentation at kernel.org
From: Junio C Hamano @ 2012-02-10 0:23 UTC (permalink / raw)
To: Clemens Buchacher; +Cc: ftpadmin, Petr Onderka, git
In-Reply-To: <20120208213410.GA5768@ecki>
Clemens Buchacher <drizzd@aon.at> writes:
> Please restore access to the following files when possible. Some sites
> are referencing those, including kernel.org itself:
>
> http://www.kernel.org/pub/software/scm/git/docs/git.html
The pages reachable from this used to be living documents in that every
time the 'master' branch was updated at k.org, automatically a server side
hook script generated a new set of HTML pages and updated them.
My understanding is that we do not want to run such random server side
hooks at k.org, so it no longer can be a living document anymore.
It might be a workable short term workaround to redirect
http://www.kernel.org/pub/software/scm/git/docs/$anything
to
http://schacon.github.com/git/$anything
although that would not give you an access to the list of documentations
for older releases, e.g.
http://www.kernel.org/pub/software/scm/git/docs/v1.6.0/git.html
> Also, it would be great if the git wiki could be made editable again.
Amen.
^ permalink raw reply
* [PATCH 3/4] diff --stat: use the real terminal width
From: Zbigniew Jędrzejewski-Szmek @ 2012-02-09 23:58 UTC (permalink / raw)
To: git; +Cc: gitster, Michael J Gruber, Zbigniew Jędrzejewski-Szmek
In-Reply-To: <1328831921-27272-1-git-send-email-zbyszek@in.waw.pl>
Some projects (especially in Java), have long filename paths, with
nested directories or long individual filenames. When files are
renamed, the stat output can be almost useless. If the middle part
between { and } is long (because the file was moved to a completely
different directory), then most of the path would be truncated.
It makes sense to use the full terminal width.
The output is still not optimal, because too many columns are devoted
to +- output, and not enough to filenames, but this is a policy
question, changed in next commit.
Signed-off-by: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
---
diff.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/diff.c b/diff.c
index 7e15426..8406a0d 100644
--- a/diff.c
+++ b/diff.c
@@ -7,6 +7,7 @@
#include "diffcore.h"
#include "delta.h"
#include "xdiff-interface.h"
+#include "help.h"
#include "color.h"
#include "attr.h"
#include "run-command.h"
@@ -1341,7 +1342,7 @@ static void show_stats(struct diffstat_t *data, struct diff_options *options)
line_prefix = msg->buf;
}
- width = options->stat_width ? options->stat_width : 80;
+ width = options->stat_width ? options->stat_width : term_columns();
name_width = options->stat_name_width ? options->stat_name_width : 50;
count = options->stat_count ? options->stat_count : data->nr;
--
1.7.9.rc2.127.gcb239
^ permalink raw reply related
* [PATCH 2/4] help.c: make term_columns() cached and export it
From: Zbigniew Jędrzejewski-Szmek @ 2012-02-09 23:58 UTC (permalink / raw)
To: git; +Cc: gitster, Michael J Gruber, Zbigniew Jędrzejewski-Szmek
In-Reply-To: <1328831921-27272-1-git-send-email-zbyszek@in.waw.pl>
Since term_columns() will usually fail, when a pager is installed,
the cache is primed before the pager is installed. If a pager is not
installed, then the cache will be set on first use.
Conforms to The Single UNIX Specification, Version 2
(http://pubs.opengroup.org/onlinepubs/7908799/xbd/envvar.html#tag_002_003).
Signed-off-by: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
---
help.c | 31 +++++++++++++++++++++++--------
help.h | 2 ++
| 5 +++++
3 files changed, 30 insertions(+), 8 deletions(-)
diff --git a/help.c b/help.c
index bc15066..75b8d4b 100644
--- a/help.c
+++ b/help.c
@@ -5,26 +5,41 @@
#include "help.h"
#include "common-cmds.h"
-/* most GUI terminals set COLUMNS (although some don't export it) */
-static int term_columns(void)
+/* cache for term_columns() value. Set on first use or when
+ * installing a pager and replacing stdout.
+ */
+static int term_columns_cache;
+
+/* Return cached value (iff set) or $COLUMNS (iff set and positive) or
+ * ioctl(1, TIOCGWINSZ).ws_col (if positive) or 80.
+ *
+ * $COLUMNS even if set, is usually not exported, so
+ * the variable can be used to override autodection.
+ */
+int term_columns(void)
{
- char *col_string = getenv("COLUMNS");
- int n_cols;
+ if (term_columns_cache)
+ return term_columns_cache;
- if (col_string && (n_cols = atoi(col_string)) > 0)
- return n_cols;
+ {
+ char *col_string = getenv("COLUMNS");
+ int n_cols;
+
+ if (col_string && (n_cols = atoi(col_string)) > 0)
+ return (term_columns_cache = n_cols);
+ }
#ifdef TIOCGWINSZ
{
struct winsize ws;
if (!ioctl(1, TIOCGWINSZ, &ws)) {
if (ws.ws_col)
- return ws.ws_col;
+ return (term_columns_cache = ws.ws_col);
}
}
#endif
- return 80;
+ return (term_columns_cache = 80);
}
void add_cmdname(struct cmdnames *cmds, const char *name, int len)
diff --git a/help.h b/help.h
index b6b12d5..880a4b4 100644
--- a/help.h
+++ b/help.h
@@ -29,4 +29,6 @@ extern void list_commands(const char *title,
struct cmdnames *main_cmds,
struct cmdnames *other_cmds);
+extern int term_columns(void);
+
#endif /* HELP_H */
--git a/pager.c b/pager.c
index 975955b..e7032de 100644
--- a/pager.c
+++ b/pager.c
@@ -1,6 +1,7 @@
#include "cache.h"
#include "run-command.h"
#include "sigchain.h"
+#include "help.h"
#ifndef DEFAULT_PAGER
#define DEFAULT_PAGER "less"
@@ -76,6 +77,10 @@ void setup_pager(void)
if (!pager)
return;
+ /* prime the term_columns() cache before it is too
+ * late and stdout is replaced */
+ (void) term_columns();
+
setenv("GIT_PAGER_IN_USE", "true", 1);
/* spawn the pager */
--
1.7.9.rc2.127.gcb239
^ permalink raw reply related
* [PATCH 4/4] diff --stat: use most of the space for file names
From: Zbigniew Jędrzejewski-Szmek @ 2012-02-09 23:58 UTC (permalink / raw)
To: git; +Cc: gitster, Michael J Gruber, Zbigniew Jędrzejewski-Szmek
In-Reply-To: <1328831921-27272-1-git-send-email-zbyszek@in.waw.pl>
Signed-off-by: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
---
diff.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/diff.c b/diff.c
index 8406a0d..6220190 100644
--- a/diff.c
+++ b/diff.c
@@ -1343,7 +1343,8 @@ static void show_stats(struct diffstat_t *data, struct diff_options *options)
}
width = options->stat_width ? options->stat_width : term_columns();
- name_width = options->stat_name_width ? options->stat_name_width : 50;
+ name_width = options->stat_name_width ? options->stat_name_width
+ : term_columns() - 20; /* the graph defaults to 20 columns */
count = options->stat_count ? options->stat_count : data->nr;
/* Sanity: give at least 5 columns to the graph,
--
1.7.9.rc2.127.gcb239
^ permalink raw reply related
* [PATCH 1/4] Move git_version_string to help.c in preparation for diff changes
From: Zbigniew Jędrzejewski-Szmek @ 2012-02-09 23:58 UTC (permalink / raw)
To: git; +Cc: gitster, Michael J Gruber, Zbigniew Jędrzejewski-Szmek
In-Reply-To: <1328831921-27272-1-git-send-email-zbyszek@in.waw.pl>
git_version_string is declared in builtins.h, but lived in git.c.
When diff.c starts to use functions from help.c, linking against
libgit.a will fail, unless git.o containing git_version_string is
linked too. This variable is only used in a couple of places, help.c
being one of them. git.o is biggish, so it let's move
git_version_string to help.c.
Signed-off-by: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
---
Makefile | 5 +++--
git.c | 2 --
help.c | 2 ++
3 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/Makefile b/Makefile
index a782409..264fe4f 100644
--- a/Makefile
+++ b/Makefile
@@ -1851,7 +1851,7 @@ strip: $(PROGRAMS) git$X
$(STRIP) $(STRIP_OPTS) $(PROGRAMS) git$X
git.o: common-cmds.h
-git.sp git.s git.o: EXTRA_CPPFLAGS = -DGIT_VERSION='"$(GIT_VERSION)"' \
+git.sp git.s git.o: EXTRA_CPPFLAGS = \
'-DGIT_HTML_PATH="$(htmldir_SQ)"' \
'-DGIT_MAN_PATH="$(mandir_SQ)"' \
'-DGIT_INFO_PATH="$(infodir_SQ)"'
@@ -1860,7 +1860,8 @@ git$X: git.o GIT-LDFLAGS $(BUILTIN_OBJS) $(GITLIBS)
$(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ git.o \
$(BUILTIN_OBJS) $(ALL_LDFLAGS) $(LIBS)
-help.sp help.o: common-cmds.h
+help.o: common-cmds.h
+help.sp help.o: EXTRA_CPPFLAGS = -DGIT_VERSION='"$(GIT_VERSION)"'
builtin/help.sp builtin/help.o: common-cmds.h
builtin/help.sp builtin/help.s builtin/help.o: EXTRA_CPPFLAGS = \
diff --git a/git.c b/git.c
index 3805616..a24a0fd 100644
--- a/git.c
+++ b/git.c
@@ -256,8 +256,6 @@ static int handle_alias(int *argcp, const char ***argv)
return ret;
}
-const char git_version_string[] = GIT_VERSION;
-
#define RUN_SETUP (1<<0)
#define RUN_SETUP_GENTLY (1<<1)
#define USE_PAGER (1<<2)
diff --git a/help.c b/help.c
index cbbe966..bc15066 100644
--- a/help.c
+++ b/help.c
@@ -409,6 +409,8 @@ const char *help_unknown_cmd(const char *cmd)
exit(1);
}
+const char git_version_string[] = GIT_VERSION;
+
int cmd_version(int argc, const char **argv, const char *prefix)
{
printf("git version %s\n", git_version_string);
--
1.7.9.rc2.127.gcb239
^ permalink raw reply related
* (unknown),
From: Zbigniew Jędrzejewski-Szmek @ 2012-02-09 23:58 UTC (permalink / raw)
To: git; +Cc: gitster, Michael J Gruber
Hi,
this is a patch series to make 'git diff --stat' use full terminal
width instead of hard-coded 80 columns.
This is quite useful when working on projects with nested directory
structure, e.g. Java:
.../{ => workspace/tasks}/GetTaskResultAction.java | 10 +-
.../tasks}/RemoveAllAbortedTasksAction.java | 7 +-
.../tasks}/RemoveAllFailedTasksAction.java | 7 +-
is changed to display full paths if the terminal window is wide
enough.
Git usually uses the full terminal width automatically, so it should
do so with --stat too.
The "big" functional change in the patch series is s/80/term_columns()/
in show_stats(). The fourth patch also changes the partitioning of
available columns to dedicate more space to file names.
^ 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