* [PATCH] Documentation: git-archive: mark --format as optional in summary
From: Wesley J. Landaker @ 2009-08-28 2:55 UTC (permalink / raw)
To: git, Junio C Hamano; +Cc: Wesley J. Landaker
In-Reply-To: <1251414520-28519-1-git-send-email-wjl@icecavern.net>
The --format option was made optional in v1.5.1-105-g8ff21b1, but it was
not marked as optional in the summary. This trival patch just changes
the summary to match the rest of the documentation.
Signed-off-by: Wesley J. Landaker <wjl@icecavern.net>
---
Junio pointed out that I missed the Signed-off-by in my previous patch. So
here it is again with that fixed.
Documentation/git-archive.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-archive.txt b/Documentation/git-archive.txt
index bc132c8..92444dd 100644
--- a/Documentation/git-archive.txt
+++ b/Documentation/git-archive.txt
@@ -9,7 +9,7 @@ git-archive - Create an archive of files from a named tree
SYNOPSIS
--------
[verse]
-'git archive' --format=<fmt> [--list] [--prefix=<prefix>/] [<extra>]
+'git archive' [--format=<fmt>] [--list] [--prefix=<prefix>/] [<extra>]
[--output=<file>] [--worktree-attributes]
[--remote=<repo> [--exec=<git-upload-archive>]] <tree-ish>
[path...]
--
1.6.3.3
^ permalink raw reply related
* Re: [PATCHv4 08/12] Teach the notes lookup code to parse notes trees with various fanout schemes
From: Sverre Rabbelier @ 2009-08-28 2:51 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jeff King, Johan Herland, git, Shawn O. Pearce,
Johannes.Schindelin, trast, tavestbo, git, chriscool
In-Reply-To: <7vocq0d86p.fsf@alter.siamese.dyndns.org>
Heya,
On Thu, Aug 27, 2009 at 18:43, Junio C Hamano<gitster@pobox.com> wrote:
> Did you mean "a commit in branch bar referred to a commit in branch foo",
> similar to the way the "cherry-picked from X" comment can refer to a
> missing commit?
Yes, sorry, I meant referred to in the commit message.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: finding unmerged branches
From: Joey Hess @ 2009-08-28 2:08 UTC (permalink / raw)
To: git
In-Reply-To: <20090827220241.GA1413@gnu.kitenet.net>
[-- Attachment #1: Type: text/plain, Size: 343 bytes --]
Joey Hess wrote:
> * Is this situation somewhat common, or an I doing something wrong?
> (Assuming that I have a good reason to want to look at remote
> branches rather than waiting to get merge requests.)
Come to think, the github fork queue serves basically the same purpose,
but only for branches in github.
--
see shy jo
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH v3 2/3] gitweb: split test suite into library and tests
From: Mark Rada @ 2009-08-28 2:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
I just fixed a typo in the commit message, a really obvious typo
that had to be pointed out to me...
I hope this is not too late.
--
Mark A Rada (ferrous26)
marada@uwaterloo.ca
--->8---
To accommodate additions to the test cases for gitweb, the preamble
from t9500 is now in its own library so that new sets of tests for
gitweb can use the same setup without copying the code.
Signed-off-by: Mark Rada <marada@uwaterloo.ca>
---
t/gitweb-lib.sh | 73 ++++++++++++++++++++++++++++++++
t/t9500-gitweb-standalone-no-errors.sh | 67 +----------------------------
2 files changed, 74 insertions(+), 66 deletions(-)
create mode 100644 t/gitweb-lib.sh
diff --git a/t/gitweb-lib.sh b/t/gitweb-lib.sh
new file mode 100644
index 0000000..8452532
--- /dev/null
+++ b/t/gitweb-lib.sh
@@ -0,0 +1,73 @@
+#!/bin/sh
+#
+# Copyright (c) 2007 Jakub Narebski
+#
+
+gitweb_init () {
+ safe_pwd="$(perl -MPOSIX=getcwd -e 'print quotemeta(getcwd)')"
+ cat >gitweb_config.perl <<EOF
+#!/usr/bin/perl
+
+# gitweb configuration for tests
+
+our \$version = 'current';
+our \$GIT = 'git';
+our \$projectroot = "$safe_pwd";
+our \$project_maxdepth = 8;
+our \$home_link_str = 'projects';
+our \$site_name = '[localhost]';
+our \$site_header = '';
+our \$site_footer = '';
+our \$home_text = 'indextext.html';
+our @stylesheets = ('file:///$TEST_DIRECTORY/../gitweb/gitweb.css');
+our \$logo = 'file:///$TEST_DIRECTORY/../gitweb/git-logo.png';
+our \$favicon = 'file:///$TEST_DIRECTORY/../gitweb/git-favicon.png';
+our \$projects_list = '';
+our \$export_ok = '';
+our \$strict_export = '';
+
+EOF
+
+ cat >.git/description <<EOF
+$0 test repository
+EOF
+}
+
+gitweb_run () {
+ GATEWAY_INTERFACE='CGI/1.1'
+ HTTP_ACCEPT='*/*'
+ REQUEST_METHOD='GET'
+ SCRIPT_NAME="$TEST_DIRECTORY/../gitweb/gitweb.perl"
+ QUERY_STRING=""$1""
+ PATH_INFO=""$2""
+ export GATEWAY_INTERFACE HTTP_ACCEPT REQUEST_METHOD \
+ SCRIPT_NAME QUERY_STRING PATH_INFO
+
+ GITWEB_CONFIG=$(pwd)/gitweb_config.perl
+ export GITWEB_CONFIG
+
+ # some of git commands write to STDERR on error, but this is not
+ # written to web server logs, so we are not interested in that:
+ # we are interested only in properly formatted errors/warnings
+ rm -f gitweb.log &&
+ perl -- "$SCRIPT_NAME" \
+ >gitweb.output 2>gitweb.log &&
+ if grep '^[[]' gitweb.log >/dev/null 2>&1; then false; else true; fi
+
+ # gitweb.log is left for debugging
+ # gitweb.output is used to parse http output
+}
+
+. ./test-lib.sh
+
+if ! test_have_prereq PERL; then
+ say 'skipping gitweb tests, perl not available'
+ test_done
+fi
+
+perl -MEncode -e 'decode_utf8("", Encode::FB_CROAK)' >/dev/null 2>&1 || {
+ say 'skipping gitweb tests, perl version is too old'
+ test_done
+}
+
+gitweb_init
diff --git a/t/t9500-gitweb-standalone-no-errors.sh b/t/t9500-gitweb-standalone-no-errors.sh
index 6275181..2fc7fdb 100755
--- a/t/t9500-gitweb-standalone-no-errors.sh
+++ b/t/t9500-gitweb-standalone-no-errors.sh
@@ -9,73 +9,8 @@ This test runs gitweb (git web interface) as CGI script from
commandline, and checks that it would not write any errors
or warnings to log.'
-gitweb_init () {
- safe_pwd="$(perl -MPOSIX=getcwd -e 'print quotemeta(getcwd)')"
- cat >gitweb_config.perl <<EOF
-#!/usr/bin/perl
-
-# gitweb configuration for tests
-
-our \$version = "current";
-our \$GIT = "git";
-our \$projectroot = "$safe_pwd";
-our \$project_maxdepth = 8;
-our \$home_link_str = "projects";
-our \$site_name = "[localhost]";
-our \$site_header = "";
-our \$site_footer = "";
-our \$home_text = "indextext.html";
-our @stylesheets = ("file:///$TEST_DIRECTORY/../gitweb/gitweb.css");
-our \$logo = "file:///$TEST_DIRECTORY/../gitweb/git-logo.png";
-our \$favicon = "file:///$TEST_DIRECTORY/../gitweb/git-favicon.png";
-our \$projects_list = "";
-our \$export_ok = "";
-our \$strict_export = "";
-EOF
-
- cat >.git/description <<EOF
-$0 test repository
-EOF
-}
-
-gitweb_run () {
- GATEWAY_INTERFACE="CGI/1.1"
- HTTP_ACCEPT="*/*"
- REQUEST_METHOD="GET"
- SCRIPT_NAME="$TEST_DIRECTORY/../gitweb/gitweb.perl"
- QUERY_STRING=""$1""
- PATH_INFO=""$2""
- export GATEWAY_INTERFACE HTTP_ACCEPT REQUEST_METHOD \
- SCRIPT_NAME QUERY_STRING PATH_INFO
-
- GITWEB_CONFIG=$(pwd)/gitweb_config.perl
- export GITWEB_CONFIG
-
- # some of git commands write to STDERR on error, but this is not
- # written to web server logs, so we are not interested in that:
- # we are interested only in properly formatted errors/warnings
- rm -f gitweb.log &&
- perl -- "$SCRIPT_NAME" \
- >/dev/null 2>gitweb.log &&
- if grep "^[[]" gitweb.log >/dev/null 2>&1; then false; else true; fi
-
- # gitweb.log is left for debugging
-}
-
-. ./test-lib.sh
-
-if ! test_have_prereq PERL; then
- say 'skipping gitweb tests, perl not available'
- test_done
-fi
-
-perl -MEncode -e 'decode_utf8("", Encode::FB_CROAK)' >/dev/null 2>&1 || {
- say 'skipping gitweb tests, perl version is too old'
- test_done
-}
-
-gitweb_init
+. ./gitweb-lib.sh
# ----------------------------------------------------------------------
# no commits (empty, just initialized repository)
--
1.6.4.1
^ permalink raw reply related
* [PATCH] Round-down years in "years+months" relative date view
From: David Reiss @ 2009-08-27 23:39 UTC (permalink / raw)
To: git
Previously, a commit from 1 year and 7 months ago would display as
"2 years, 7 months ago".
Signed-off-by: David Reiss <dreiss@facebook.com>
---
Here's my test script. Let me know if you'd rather have it as part
of the test suite.
#!/bin/sh
set -e
REPO="git-relative-dates-test"
rm -rf "$REPO"
mkdir "$REPO"
cd "$REPO"
git init
NOW=`date +%s`
env GIT_AUTHOR_DATE=`expr $NOW - \( 365 + 220 \) \* 24 \* 60 \* 60` git commit --allow-empty -m old-commit
git log --date=relative
date.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/date.c b/date.c
index 1de1845..e848d96 100644
--- a/date.c
+++ b/date.c
@@ -137,7 +137,7 @@ const char *show_date(unsigned long time, int tz, enum date_mode mode)
}
/* Give years and months for 5 years or so */
if (diff < 1825) {
- unsigned long years = (diff + 183) / 365;
+ unsigned long years = diff / 365;
unsigned long months = (diff % 365 + 15) / 30;
int n;
n = snprintf(timebuf, sizeof(timebuf), "%lu year%s",
--
1.6.0.4
^ permalink raw reply related
* Re: [PATCHv4 08/12] Teach the notes lookup code to parse notes trees with various fanout schemes
From: Junio C Hamano @ 2009-08-28 1:43 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: Jeff King, Johan Herland, git, Shawn O. Pearce,
Johannes.Schindelin, trast, tavestbo, git, chriscool
In-Reply-To: <fabb9a1e0908271740i53ec7d69td696d955366ad23c@mail.gmail.com>
Sverre Rabbelier <srabbelier@gmail.com> writes:
> Heya,
>
> On Thu, Aug 27, 2009 at 17:30, Junio C Hamano<gitster@pobox.com> wrote:
>> So, how?
>
> A note in branch foo (which you do not follow) was referenced by a
> commit in branch bar (which you do follow)?
Sorry, I do not follow. How does a note be _in_ branch foo, and how does
a commit _reference_ a note?
Did you mean "a commit in branch bar referred to a commit in branch foo",
similar to the way the "cherry-picked from X" comment can refer to a
missing commit?
^ permalink raw reply
* Re: [PATCH v3] import-tars: Allow per-tar author and commit message.
From: Junio C Hamano @ 2009-08-28 1:38 UTC (permalink / raw)
To: Peter Krefting; +Cc: git
In-Reply-To: <alpine.DEB.2.00.0908270741170.6459@perkele.intern.softwolves.pp.se>
Peter Krefting <peter@softwolves.pp.se> writes:
> Junio C Hamano:
>
>> Do you really want to slurp Committer:/Author: lines from _anywhere_
>> in the file? Wouldn't it make more sense to vaguely emulate e-mail
>> message format with headers, empty-line and then body that is free
>> form?
>
> I just tried not to overdo it, and keep the parsing code as simple as
> possible. I wasn't trying to implement an RFC 5322 compliant parser...
It is not about overdoing, but about not glossly underdoing.
Don't you at least want to avoid misparsing a msg file that looks like
this?
Author: Peter Krefting <peter@softwolves.pp.se>
import-tars: Allow per-tar author and commit message
This version updates the import-tars program so that another
file next to the archive can be read for the log message and
other meta information. A line that begins with Committer: or
Author: is used as long as it consists of name and <email>
to override the corresponding metainformation. Remaining lines
are used as the commit log message.
And I do not think you need a complex parser. Stop paying attention to a
line that begins with Author:/Committer:, once you see a line that does
not match the pattern; and you would be Ok.
IOW, something like...
my $reading_metainfo = 1;
my $squashing_empty = 0;
while (<>) {
if ($reading_metainfo) {
if (/^Committer:.../) {
...
next;
} elsif (/^Author:.../) {
...
next;
} else {
$reading_metainfo = 0;
}
}
if (/^$/) {
$squashing_empty = 1;
next;
}
if ($squashing_empty && $commit_msg ne '') {
$commit_msg .= "\n";
}
$commit_msg .= $_;
$squashing_empty = 0;
}
^ permalink raw reply
* Re: finding unmerged branches
From: Joey Hess @ 2009-08-28 0:54 UTC (permalink / raw)
To: git
In-Reply-To: <32541b130908271522u1048dcb1h67b79049e46df1ac@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 580 bytes --]
Avery Pennarun wrote:
> How about:
>
> gitk $(git for-each-ref --format='%(refname)' 'refs/remotes/'; git
> for-each-ref --format='^%(refname)' 'refs/heads/')
>
> You could also replace 'gitk' with 'git log', and mess with the
> --pretty=format:whatever parameter.
I added 'refs/remotes/origin/' 'refs/tags/' to the list, and that's
almost perfect, thanks.
Though there was one remote branch where gitk showed a lot of commits
from origin/master before the unmerged changes in the branch. Could not
figure out why, git log doesn't show them.
--
see shy jo
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: finding unmerged branches
From: Joey Hess @ 2009-08-28 0:44 UTC (permalink / raw)
To: git
In-Reply-To: <20090827223504.GA18307@atjola.homenet>
[-- Attachment #1: Type: text/plain, Size: 482 bytes --]
Björn Steinbrink wrote:
> Hm, not sure if I'd call it "better", but probably at least a bit
> faster. You could create a "fake" merge to combine all the branches.
>
> git branch -r --no-merged $(
> : | git commit-tree HEAD^{tree} $(
> git for-each-ref --format='-p %(refname)' \
> refs/heads/ \
> refs/remotes/origin
> )
> )
That does run fast. Has some warnings about duplicate parents. The gitk
method seems more useful.
--
see shy jo
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCHv4 08/12] Teach the notes lookup code to parse notes trees with various fanout schemes
From: Sverre Rabbelier @ 2009-08-28 0:40 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jeff King, Johan Herland, git, Shawn O. Pearce,
Johannes.Schindelin, trast, tavestbo, git, chriscool
In-Reply-To: <7viqg8hj98.fsf@alter.siamese.dyndns.org>
Heya,
On Thu, Aug 27, 2009 at 17:30, Junio C Hamano<gitster@pobox.com> wrote:
> So, how?
A note in branch foo (which you do not follow) was referenced by a
commit in branch bar (which you do follow)?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCHv4 08/12] Teach the notes lookup code to parse notes trees with various fanout schemes
From: Junio C Hamano @ 2009-08-28 0:30 UTC (permalink / raw)
To: Jeff King
Cc: Johan Herland, git, Shawn O. Pearce, Johannes.Schindelin, trast,
tavestbo, git, chriscool
In-Reply-To: <20090827233900.GA7347@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Fri, Aug 28, 2009 at 01:03:05AM +0200, Johan Herland wrote:
>
>> Agreed. I'm starting to come around to the idea of storing them in subtrees
>> based on commit dates. For one, you don't have multiple notes for one commit
>> in the same notes tree. Also, the common-case access pattern seems tempting.
>>
>> Dscho: Were there other problems with the date-based approach other than not
>> supporting notes on trees and blobs?
>>
>> If not, I'll start preparing another series with the date-based approach.
>
> Would you ever want to load a note for a commit when you did not have
> that commit present (in which case you would not know its date)?
You cannot "git show" nor "git checkout" it, nor have reached it via "git
bisect". How did you get interested in the commit in the first place?
What is the reason you are not fetching the commit after you somehow got
interested in the commit?
Here is one possible scenario I can think of. The notes tree is published
and distributed more widely than the project's main source. You fetch and
usually follow notes tree (which would probably be more lightweight) but
not the source. Perhaps your bug tracking system is based on notes, and
the project is throwing all the bugs in one such notes tree. You are a
bug tracking person, and you are following the notes tree closely, but are
only following the 'master' branch but not 'next' nor 'pu'.
And you somehow browse through the 'notes' tree, and learn that a note
refers to an interesting commit. But the commit the note applies to is
not yet in 'master' so you do not have it. Even though you would want to
fetch 'next' and 'pu', you are having connection problem and you cannot
fetch the source until your ISP gets back online tomorrow morning.
Nah, that's not a plausible scenario---at that point you already have read
the note.
So, how?
^ permalink raw reply
* Re: [PATCHv4 08/12] Teach the notes lookup code to parse notes trees with various fanout schemes
From: Jeff King @ 2009-08-27 23:39 UTC (permalink / raw)
To: Johan Herland
Cc: git, Junio C Hamano, Shawn O. Pearce, Johannes.Schindelin, trast,
tavestbo, git, chriscool
In-Reply-To: <200908280103.06015.johan@herland.net>
On Fri, Aug 28, 2009 at 01:03:05AM +0200, Johan Herland wrote:
> Agreed. I'm starting to come around to the idea of storing them in subtrees
> based on commit dates. For one, you don't have multiple notes for one commit
> in the same notes tree. Also, the common-case access pattern seems tempting.
>
> Dscho: Were there other problems with the date-based approach other than not
> supporting notes on trees and blobs?
>
> If not, I'll start preparing another series with the date-based approach.
Would you ever want to load a note for a commit when you did not have
that commit present (in which case you would not know its date)?
-Peff
^ permalink raw reply
* Re: finding unmerged branches
From: Junio C Hamano @ 2009-08-27 23:25 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: Joey Hess, git
In-Reply-To: <20090827223504.GA18307@atjola.homenet>
Björn Steinbrink <B.Steinbrink@gmx.de> writes:
> Hm, not sure if I'd call it "better", but probably at least a bit
> faster. You could create a "fake" merge to combine all the branches.
>
> git branch -r --no-merged $(
> : | git commit-tree HEAD^{tree} $(
> git for-each-ref --format='-p %(refname)' \
> refs/heads/ \
> refs/remotes/origin
> )
> )
Heh, that is certainly a cute hack ;-)
^ permalink raw reply
* [PATCH] Documentation: git-archive: mark --format as optional in summary
From: Wesley J. Landaker @ 2009-08-27 23:08 UTC (permalink / raw)
To: git, Junio C Hamano; +Cc: Wesley J. Landaker
The --format option was made optional in v1.5.1-105-g8ff21b1, but it was
not marked as optional in the summary. This trival patch just changes
the summary to match the rest of the documentation.
---
Documentation/git-archive.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-archive.txt b/Documentation/git-archive.txt
index bc132c8..92444dd 100644
--- a/Documentation/git-archive.txt
+++ b/Documentation/git-archive.txt
@@ -9,7 +9,7 @@ git-archive - Create an archive of files from a named tree
SYNOPSIS
--------
[verse]
-'git archive' --format=<fmt> [--list] [--prefix=<prefix>/] [<extra>]
+'git archive' [--format=<fmt>] [--list] [--prefix=<prefix>/] [<extra>]
[--output=<file>] [--worktree-attributes]
[--remote=<repo> [--exec=<git-upload-archive>]] <tree-ish>
[path...]
--
1.6.3.3
^ permalink raw reply related
* Re: [PATCHv4 08/12] Teach the notes lookup code to parse notes trees with various fanout schemes
From: Johan Herland @ 2009-08-27 23:03 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Shawn O. Pearce, Johannes.Schindelin, trast,
tavestbo, git, chriscool
In-Reply-To: <7vy6p5ncz0.fsf@alter.siamese.dyndns.org>
On Thursday 27 August 2009, Junio C Hamano wrote:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
> > Yea, it was me. I still think it might be a useful idea, since
> > it allows you better density of loading notes when parsing the
> > recent commits. In theory the last 256 commits can easly be in
> > each of the 2/ fanout buckets, making 2/38 pointless for reducing
> > the search space. Commit date on the other hand can probably force
> > all of them into the same bucket, making it easy to have the last
> > 256 commits in cache, from a single bucket.
> >
> > But I thought you shot it down, by saying that we also wanted to
> > support notes on blobs. I happen to see no value in a note on
> > a blob, a blob alone doesn't make much sense without at least an
> > annotated tag or commit to provide it some named context, and the
> > latter two have dates.
>
> Yeah, and in this thread everybody seems to be talking about commits so I
> think it is fine to limit notes only to commits.
Agreed. I'm starting to come around to the idea of storing them in subtrees
based on commit dates. For one, you don't have multiple notes for one commit
in the same notes tree. Also, the common-case access pattern seems tempting.
Dscho: Were there other problems with the date-based approach other than not
supporting notes on trees and blobs?
If not, I'll start preparing another series with the date-based approach.
Thanks for the input, guys. :)
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: [PATCH] upload-pack: add a trigger for post-upload-pack hook
From: Robin H. Johnson @ 2009-08-27 22:56 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List
In-Reply-To: <7vy6p69j6a.fsf@alter.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 547 bytes --]
On Wed, Aug 26, 2009 at 05:47:41PM -0700, Junio C Hamano wrote:
> After upload-pack successfully finishes its operation, post-upload-pack
> hook can be called for logging purposes.
+1 from me.
I'm actually going to scrap my previous pre-upload-pack hook and rebase
it off this, because I see a lot of commonality (I was passing in
have/want via stdin too).
--
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail : robbat2@gentoo.org
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
[-- Attachment #2: Type: application/pgp-signature, Size: 330 bytes --]
^ permalink raw reply
* Re: [PATCHv4 10/12] notes.c: Implement simple memory pooling of leaf nodes
From: Johan Herland @ 2009-08-27 22:43 UTC (permalink / raw)
To: Alex Riesen
Cc: git, gitster, Johannes.Schindelin, trast, tavestbo, git,
chriscool, spearce
In-Reply-To: <200908271149.11003.johan@herland.net>
On Thursday 27 August 2009, Johan Herland wrote:
> On Thursday 27 August 2009, Alex Riesen wrote:
> > On Thu, Aug 27, 2009 at 03:43, Johan Herland<johan@herland.net> wrote:
> > > When allocating a new memory pool, the older pool is leaked, but this
> > > is no worse than the current situation, where (pretty much) all
> > > leaf_nodes are leaked anyway.
> >
> > Could you return the unused nodes back into the mempool?
> > By making the pool a preallocated list, perhaps?
>
> Yes, maintaining a free-list is certainly possible. However, the number
> of free()d leaf_nodes is relatively small (only subtree entries are
> free()d after unpacking them into the tree structure), so I'm not sure it
> pays off, runtime-wise.
I played around with the free-list idea, but it cost more than the memory
pooling code saved in the first place. I'm leaning towards dropping the
whole memory pooling idea, as the small run-time improvement is probably not
worth the added complexity. We'll see. I'll re-evaluate once I've refactored
the code according to the other threads of this discussion.
> > And then it is trivial to provide a deallocation function for the
> > mempool, which something really concerned about the memleak can call
> > (like when or if libgit get more usable in an application context).
>
> Yes, I plan to provide a free_notes() function that free()s all the
> memory associated with the notes data structure. This would of course
> keep references to all the mempools, and deallocate them (along with all
> the int_nodes).
This still stands, of course. Should be part of the next iteration.
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: finding unmerged branches
From: Björn Steinbrink @ 2009-08-27 22:35 UTC (permalink / raw)
To: Joey Hess; +Cc: git
In-Reply-To: <20090827220241.GA1413@gnu.kitenet.net>
On 2009.08.27 18:02:41 -0400, Joey Hess wrote:
> My situation is this: My project has a lot of remotes with
> lots of branches; about 250 branches in total. I want to
> figure out which of these branches to look at to consider
> merging.
>
> So, I reach for git branch -a --no-merged master; that's what
> its man page says its for. But this still finds 120 branches,
> and a lot of them are not things I want to look at. Many of
> them are copies of some of my own branches.
>
> What I really want is a way to find remote branches that
> are not merged with any of my local branches (or any origin
> branches). A slow and stupid implementation of that is in the
> attached git-unmerged script, and it weeds the branch list
> down to 68 branches, which are mostly really ones I might
> want to look at.
>
> So, three questions:
>
> * Is this situation somewhat common, or an I doing something wrong?
> (Assuming that I have a good reason to want to look at remote
> branches rather than waiting to get merge requests.)
> * Is there a better way to accomplish this than a slow perl script that
> runs git branch -r --merged foreach of my branches?
Hm, not sure if I'd call it "better", but probably at least a bit
faster. You could create a "fake" merge to combine all the branches.
git branch -r --no-merged $(
: | git commit-tree HEAD^{tree} $(
git for-each-ref --format='-p %(refname)' \
refs/heads/ \
refs/remotes/origin
)
)
Björn
^ permalink raw reply
* Re: Question regarding git fetch
From: Avery Pennarun @ 2009-08-27 22:24 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Björn Steinbrink, Tom Lambda, git
In-Reply-To: <20090827221631.GA7058@coredump.intra.peff.net>
On Thu, Aug 27, 2009 at 10:16 PM, Jeff King<peff@peff.net> wrote:
> On Thu, Aug 27, 2009 at 10:12:50PM +0000, Avery Pennarun wrote:
>> After all, if I *really* care about the prior state of the remote, I
>> can just make it a remote branch. And if (as often happens) I just
>
> Do you mean "local branch" here?
Yes.
>> want to know what's new in that ref since last time I merged, it's
>> simply
>>
>> git log master..origin/master
>>
>> This works even if master has extra commits vs. origin/master, since
>> the double-dot invokes git-merge-base.
>
> Well, ".." doesn't use git-merge-base. But yes, I actually do this,
> except I do:
>
> gitk master...origin/master
Sorry, not my day for accuracy, it seems. I use both, and I should
have remembered that the triple-dot is the one that worries about the
merge-base.
Have fun,
Avery
^ permalink raw reply
* Re: finding unmerged branches
From: Avery Pennarun @ 2009-08-27 22:22 UTC (permalink / raw)
To: Joey Hess; +Cc: git
In-Reply-To: <20090827220241.GA1413@gnu.kitenet.net>
On Thu, Aug 27, 2009 at 10:02 PM, Joey Hess<joey@kitenet.net> wrote:
> What I really want is a way to find remote branches that
> are not merged with any of my local branches (or any origin
> branches). A slow and stupid implementation of that is in the
> attached git-unmerged script, and it weeds the branch list
> down to 68 branches, which are mostly really ones I might
> want to look at.
How about:
gitk $(git for-each-ref --format='%(refname)' 'refs/remotes/'; git
for-each-ref --format='^%(refname)' 'refs/heads/')
You could also replace 'gitk' with 'git log', and mess with the
--pretty=format:whatever parameter.
Have fun,
Avery
^ permalink raw reply
* Re: Using git to track my PhD thesis, couple of questions
From: demerphq @ 2009-08-27 22:21 UTC (permalink / raw)
To: seanh; +Cc: git
In-Reply-To: <20090827203402.GC7168@kisimul>
2009/8/27 seanh <seanh.nospam@gmail.com>:
> 2. They don't want to look at the latex source but the PDFs built from
> it, which they're going to annotate with their comments. So I need an
> easy way for them to get the PDF of each commit from gitweb without
> having to checkout the repo and build it themselves. Normally I
> wouldn't commit the PDF files into the repo because they're compiled
> files not source files, but it seems that just building a PDF and
> committing it along with each commit to trunk would be by far the
> easiest way to achieve this. But will git store the PDFs efficiently, or
> will the repo start to get really big?
As you can generate the PDF's from the latex then just hack gitweb to
let them download it from there.
Yves
--
perl -Mre=debug -e "/just|another|perl|hacker/"
^ permalink raw reply
* Re: Question regarding git fetch
From: Jeff King @ 2009-08-27 22:16 UTC (permalink / raw)
To: Avery Pennarun; +Cc: Junio C Hamano, Björn Steinbrink, Tom Lambda, git
In-Reply-To: <32541b130908271512h255834adl5a606054f6ab20e4@mail.gmail.com>
On Thu, Aug 27, 2009 at 10:12:50PM +0000, Avery Pennarun wrote:
> > I'm still screwed. The issue is that you consider your configured
> > refspec destinations to be precious, and not merely a cache for what's
> > happening on the remote side.
>
> Is the "precious remote ref" concept perhaps an imaginary one?
Maybe. I certainly don't use it. But I am trying to consider corner
cases where somebody who _isn't_ me is going to get screwed by a
change we make.
> After all, if I *really* care about the prior state of the remote, I
> can just make it a remote branch. And if (as often happens) I just
Do you mean "local branch" here?
> want to know what's new in that ref since last time I merged, it's
> simply
>
> git log master..origin/master
>
> This works even if master has extra commits vs. origin/master, since
> the double-dot invokes git-merge-base.
Well, ".." doesn't use git-merge-base. But yes, I actually do this,
except I do:
gitk master...origin/master
-Peff
^ permalink raw reply
* Re: Question regarding git fetch
From: Avery Pennarun @ 2009-08-27 22:12 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Björn Steinbrink, Tom Lambda, git
In-Reply-To: <20090827215007.GA6231@coredump.intra.peff.net>
On Thu, Aug 27, 2009 at 9:50 PM, Jeff King<peff@peff.net> wrote:
> I don't think the colon is the issue. Consider the same situation, but I
> say:
>
> # but today let's demo it first
> $ git fetch origin master
> $ git checkout -b demo FETCH_HEAD
>
> I'm still screwed. The issue is that you consider your configured
> refspec destinations to be precious, and not merely a cache for what's
> happening on the remote side.
Is the "precious remote ref" concept perhaps an imaginary one?
After all, if I *really* care about the prior state of the remote, I
can just make it a remote branch. And if (as often happens) I just
want to know what's new in that ref since last time I merged, it's
simply
git log master..origin/master
This works even if master has extra commits vs. origin/master, since
the double-dot invokes git-merge-base.
I think this might be a much more common than the case where people
actually want to see "what's changed since last time I checked what's
changed." At least, the latter question has never been very
interesting to me, or if it is, it's easy for me to tell by eye.
Avery
^ permalink raw reply
* finding unmerged branches
From: Joey Hess @ 2009-08-27 22:02 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 1143 bytes --]
My situation is this: My project has a lot of remotes with
lots of branches; about 250 branches in total. I want to
figure out which of these branches to look at to consider
merging.
So, I reach for git branch -a --no-merged master; that's what
its man page says its for. But this still finds 120 branches,
and a lot of them are not things I want to look at. Many of
them are copies of some of my own branches.
What I really want is a way to find remote branches that
are not merged with any of my local branches (or any origin
branches). A slow and stupid implementation of that is in the
attached git-unmerged script, and it weeds the branch list
down to 68 branches, which are mostly really ones I might
want to look at.
So, three questions:
* Is this situation somewhat common, or an I doing something wrong?
(Assuming that I have a good reason to want to look at remote
branches rather than waiting to get merge requests.)
* Is there a better way to accomplish this than a slow perl script that
runs git branch -r --merged foreach of my branches?
* Should git have something builtin to handle this case better?
--
see shy jo
[-- Attachment #2: git-unmerged --]
[-- Type: text/plain, Size: 582 bytes --]
#!/usr/bin/perl
my @remote_branches = split ' ', `git branch -r | awk '{print $1}'`;
# have to filter out the "* "
my @local_branches = split ' ', `git branch | sed 's/^..//'`;
my @origin_branches = grep /^origin\//, @remote_branches;
my %unmerged = (map { $_ => 1 } @remote_branches),
(map { $_ => 0 } @local_branches, @origin_branches);
foreach my $branch (@local_branches, @origin_branches) {
map { $unmerged{$_}=0 } split ' ', `git branch -r --merged "$branch" | awk '{print $1}'`
}
foreach my $branch (sort keys %unmerged) {
print "$branch\n" if $unmerged{$branch};
}
^ permalink raw reply
* Re: Question regarding git fetch
From: Jeff King @ 2009-08-27 21:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Avery Pennarun, Björn Steinbrink, Tom Lambda, git
In-Reply-To: <20090827215007.GA6231@coredump.intra.peff.net>
On Thu, Aug 27, 2009 at 05:50:07PM -0400, Jeff King wrote:
> > I think this is a good example that any change results from this
> > discussion should apply _only_ to cases where command line refspecs lack
> > colon (i.e. used to mean "do not store this anywhere but in FETCH_HEAD").
>
> I don't think the colon is the issue. Consider the same situation, but I
> say:
>
> # but today let's demo it first
> $ git fetch origin master
> $ git checkout -b demo FETCH_HEAD
>
> I'm still screwed. The issue is that you consider your configured
> refspec destinations to be precious, and not merely a cache for what's
> happening on the remote side.
Which, btw, led me to consider whether there are heuristics for deciding
when a fetch refspec means one thing and not the other. I don't think
there are reliable ones (probably the default configured
refs/remotes/$remotename/* would not yield false positives, but I think
limiting to that would yield false negatives). So maybe this is
something that should be configurable, disabled by default for now, and
maybe enabled by default in the future (v1.7.0?).
-Peff
^ 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