* Re: Dealing with many many git repos in a /home directory
From: Alex Riesen @ 2010-02-04 9:57 UTC (permalink / raw)
To: demerphq; +Cc: Git
In-Reply-To: <9b18b3111002040029x1c7de0afw4a5ef883588f7a18@mail.gmail.com>
On Thu, Feb 4, 2010 at 09:29, demerphq <demerphq@gmail.com> wrote:
> Would i be correct in thinking that if i have to repos with an
> equivalent .git/objects/../..... file in them that the files are
> necessarily identical and one can be replaced by a hardlink to the
> other?
Yes, but you probably wont save as much as you'd like: think about the users
who *do* repack their repositories. The .pack files will be all different.
^ permalink raw reply
* Re: [PATCH] Typofixes outside documentation area
From: Thomas Rast @ 2010-02-04 10:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v636dr2hy.fsf@alter.siamese.dyndns.org>
On Thursday 04 February 2010 06:31:05 Junio C Hamano wrote:
> diff --git a/levenshtein.h b/levenshtein.h
> index 0173abe..4105bf3 100644
> --- a/levenshtein.h
> +++ b/levenshtein.h
> @@ -2,7 +2,7 @@
> #define LEVENSHTEIN_H
>
> int levenshtein(const char *string1, const char *string2,
> - int swap_penalty, int substition_penalty,
> + int swap_penalty, int substitution_penalty,
> int insertion_penalty, int deletion_penalty);
>
> #endif
To save others the trouble of looking it up, too:
This does change the name of the parameter, but it's only the
declaration. The actual definition of the function starts with
int levenshtein(const char *string1, const char *string2,
int w, int s, int a, int d)
{
so it doesn't need a similar rename, and no uses of the parameter are
affected.
AFAICS all other changes are only in comments or strings and should be
safe.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: "secret key not available". "unable to sign the tag".
From: SASh-4 @ 2010-02-04 11:44 UTC (permalink / raw)
To: git
In-Reply-To: <86367.3986.qm@web37907.mail.mud.yahoo.com>
I had the same problem. Turned out that the user.name must also match the one
in the gpg! Hope this helps!
--
View this message in context: http://n2.nabble.com/secret-key-not-available-unable-to-sign-the-tag-tp1500685p4512970.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: rebase vs rebase -i
From: Johannes Schindelin @ 2010-02-04 13:27 UTC (permalink / raw)
To: Jay Soffian; +Cc: git
In-Reply-To: <76718491002032019i5f8ea947paa527988ddb7a378@mail.gmail.com>
Hi,
On Wed, 3 Feb 2010, Jay Soffian wrote:
> Why does git rebase use format-patch + am, while rebase -i uses
> cherry-pick?
Hysterical raisins. 'rebase -i' started out as 'edit-patch-series.sh',
hacked together in 4 hours on a lazy Saturday afternoon:
http://colabti.org/irclogger/irclogger_log/git?date=2007-02-27#l97
Ah, the old days. Back when I had enough time to read through Peff's
mails. And back when I had enough time to cobble together fun Git scripts.
> Just curious. In particular though, it seems especially odd in this
> case:
>
> $ git rebase --onto <newbase> <upstream>
>
> vs
>
> $ env GIT_EDITOR=true git rebase -i --onto <newbase> <upstream>
>
> Both in theory produce an identical end-result, while using two
> different implementations.
>
> (Here I'm setting GIT_EDITOR=true just to demonstrate that I didn't
> change the list of commits in the latter case.)
You can get _exactly_ the same behavior if you use -m.
Ciao,
Dscho
^ permalink raw reply
* Re: Dealing with many many git repos in a /home directory
From: Martin Langhoff @ 2010-02-04 15:00 UTC (permalink / raw)
To: demerphq; +Cc: Git
In-Reply-To: <9b18b3111002040029x1c7de0afw4a5ef883588f7a18@mail.gmail.com>
On Thu, Feb 4, 2010 at 3:29 AM, demerphq <demerphq@gmail.com> wrote:
> This is starting to take a lot of space.
What I used to do was to
- have a "canonical" local bare repo for each major project, fetching
and repacking nightly
- a script that "injects" an "alternates" entry to matching user
repos -- logic to look at a repo and decide which alternate to hook it
to is left to the reader.
- optional: automating repacks on users repos
As users repack, their "local" packs will only have the objects that
are not shared with the canonical repos. With Moodle repos, this was a
200MB savings per repo.
And the kernel keeps one set of packfiles in buffers, so everyone gets
much faster gitk / gitlog / blame...
m
--
martin.langhoff@gmail.com
martin@laptop.org -- School Server Architect
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
^ permalink raw reply
* Re: Dealing with many many git repos in a /home directory
From: Sergio @ 2010-02-04 15:20 UTC (permalink / raw)
To: git
In-Reply-To: <81b0412b1002040157r7af2a587y9cfc7189fc8ad632@mail.gmail.com>
Alex Riesen <raa.lkml <at> gmail.com> writes:
>
> On Thu, Feb 4, 2010 at 09:29, demerphq <demerphq <at> gmail.com> wrote:
> > Would i be correct in thinking that if i have to repos with an
> > equivalent .git/objects/../..... file in them that the files are
> > necessarily identical and one can be replaced by a hardlink to the
> > other?
>
> Yes, but you probably wont save as much as you'd like: think about the
> users
> who *do* repack their repositories. The .pack files will be all
> different.
>
Maybe you can:
for each repo
clone it to some place
pack it with gc --aggressive
take the resulting pack and move it (and the associated index) somewhere
make in the same place a file with the same hash as the pack and extension
keep and possibly, inside, some note about its content (e.q. what repo
was cloned and at what state/time it was so frozen).
ask the users to go in the .git/objects/packs dir of their private copy
of the corresponding repo and hardlink there the .pack, .idx, .keep
file that you have prepared
ask the users to invoke git gc
Before actually doing that on something important, maybe wait have the
confirmation from some developer that there is not something flawed in the
approach.
Personally, I tend to use keep files a lot because I need to keep two
machines synchronized using "unison". Without keep files, large packs are
changed at every gc and the synchronization takes ages. By "freezing" a
stable subset of my objects I maintain the changing packs much smaller and
reduce the amount of data that needs to be carried over by unison to keep
the two machines in sync.
^ permalink raw reply
* Re: Dealing with many many git repos in a /home directory
From: Andreas Schwab @ 2010-02-04 15:32 UTC (permalink / raw)
To: demerphq; +Cc: Git
In-Reply-To: <9b18b3111002040029x1c7de0afw4a5ef883588f7a18@mail.gmail.com>
demerphq <demerphq@gmail.com> writes:
> At $work we have a host where we have about 50-100 users each with
> their own private copies of the same repos. These are cloned froma
> remote via git/ssh and are not thus automatically hardlinking their
> object stores.
>
> This is starting to take a lot of space.
Create local mirrors of the remote repos (and update them regularily)
and ask the users to borrow from them.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* [PATCH] git-clean: fix the description of the default behavior
From: Michael J Gruber @ 2010-02-04 16:01 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
Currently, when called without -n and -f, git clean issues
fatal: clean.requireForce not set and -n or -f not given; refusing to clean
which leaves the user wondering why force is required when requireForce
is not set. Looking up in git-clean(1) does not help because its
description is wrong.
Change it so that git clean issues
fatal: clean.requireForce defaults to true and -n or -f not given; refusing to clean
in this situation (and "...set to true..." when it is set) which makes
it clearer that an unset config means true here, and adjust the
documentation.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
---
I'd actually suggest changing "and -n or -f not given" to "and neither -n nor -f given"
in addition to the above, but the above is a real fix, whereas the latter is a style
issue, and we're close to release.
In fact, having a variable where unset means true is rather unfortunate,
but I don't expect that to be changing.
Documentation/git-clean.txt | 4 ++--
builtin-clean.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-clean.txt b/Documentation/git-clean.txt
index 335c885..a81cb6c 100644
--- a/Documentation/git-clean.txt
+++ b/Documentation/git-clean.txt
@@ -33,8 +33,8 @@ OPTIONS
-f::
--force::
- If the git configuration specifies clean.requireForce as true,
- 'git clean' will refuse to run unless given -f or -n.
+ If the git configuration variable clean.requireForce is not set
+ to false, 'git clean' will refuse to run unless given -f or -n.
-n::
--dry-run::
diff --git a/builtin-clean.c b/builtin-clean.c
index 3a70fa8..6ad5892 100644
--- a/builtin-clean.c
+++ b/builtin-clean.c
@@ -67,8 +67,8 @@ int cmd_clean(int argc, const char **argv, const char *prefix)
die("-x and -X cannot be used together");
if (!show_only && !force)
- die("clean.requireForce%s set and -n or -f not given; "
- "refusing to clean", config_set ? "" : " not");
+ die("clean.requireForce %s to true and -n or -f not given; "
+ "refusing to clean", config_set ? "set" : "defaults");
if (force > 1)
rm_flags = 0;
--
1.7.0.rc1.199.g9253ab
^ permalink raw reply related
* [PATCH 0/4] gitweb: preliminary notes support
From: Giuseppe Bilotta @ 2010-02-04 16:18 UTC (permalink / raw)
To: git
Cc: Jakub Narebski, Johannes Schindelin, Johan Herland,
Junio C Hamano, Giuseppe Bilotta
This small patchset introduces notes support in gitweb.
The feature is designed to be powerful and flexible: any amount of notes
ref spaces can be used, and per-namespace styling is possible.
The implementation is not exactly high-performance, needing no less than
one extra git call per commit per notes ref space (two if a note exist),
and is thus disabled by default.
It's quite likely that appropriate C plumbing in git could speed this
considerably; the current implementation, OTOH, has the advantage of
working even when the git core does not support notes itself.
Giuseppe Bilotta (4):
gitweb: notes feature
gitweb: show notes in shortlog view
gitweb: show notes in log
gitweb: show notes in commit(diff) view
gitweb/gitweb.css | 51 +++++++++++++++++++++++
gitweb/gitweb.perl | 116 +++++++++++++++++++++++++++++++++++++++++++++++++++-
2 files changed, 166 insertions(+), 1 deletions(-)
^ permalink raw reply
* [PATCH 1/4] gitweb: notes feature
From: Giuseppe Bilotta @ 2010-02-04 16:18 UTC (permalink / raw)
To: git
Cc: Jakub Narebski, Johannes Schindelin, Johan Herland,
Junio C Hamano, Giuseppe Bilotta
In-Reply-To: <1265300338-25021-1-git-send-email-giuseppe.bilotta@gmail.com>
Introduce support for notes by collecting them when creating commit
lists. The list of noterefs to look into is configurable, and can be a(n
array of) refspec(s), which will be looked for in the refs/notes
namespace.
The feature is disabled by default because it's presently not very
efficient (one extra git call per configured refspec, plus two extra git
calls per commit per noteref).
---
gitweb/gitweb.perl | 62 ++++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 62 insertions(+), 0 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index d0c3ff2..9ba5815 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -411,6 +411,22 @@ our %feature = (
'override' => 0,
'default' => [16]},
+ # Notes support. When this feature is enabled, the presence of notes
+ # for any commit is signaled, and the note content is made available
+ # in a way appropriate for the current view.
+ # Set this to '*' to enable all notes namespace, or to a shell-glob
+ # specification to enable specific namespaces only.
+
+ # To enable system wide have in $GITWEB_CONFIG
+ # $feature{'notes'}{'default'} = ['*'];
+ # To have project specific config enable override in $GITWEB_CONFIG
+ # $feature{'notes'}{'override'} = 1;
+ # and in project config gitweb.notes = namespace;
+ 'notes' => {
+ 'sub' => \&feature_notes,
+ 'override' => 0,
+ 'default' => []},
+
# Avatar support. When this feature is enabled, views such as
# shortlog or commit will display an avatar associated with
# the email of the committer(s) and/or author(s).
@@ -513,6 +529,16 @@ sub feature_patches {
return ($_[0]);
}
+sub feature_notes {
+ my @val = (git_get_project_config('notes'));
+
+ if (@val) {
+ return @val;
+ }
+
+ return @_;
+}
+
sub feature_avatar {
my @val = (git_get_project_config('avatar'));
@@ -2786,10 +2812,30 @@ sub parse_commit {
return %co;
}
+# return all refs matching refs/notes/<globspecs> where the globspecs
+# are taken from the notes feature content.
+sub get_note_refs {
+ my @globs = gitweb_get_feature('notes');
+ my @note_refs = ();
+ foreach my $glob (@globs) {
+ if (open my $fd, '-|', git_cmd(), 'for-each-ref',
+ '--format=%(refname)', "refs/notes/$glob") {
+ while (<$fd>) {
+ chomp;
+ push @note_refs, $_ if $_;
+ }
+ close $fd;
+ }
+ }
+ return @note_refs;
+}
+
sub parse_commits {
my ($commit_id, $maxcount, $skip, $filename, @args) = @_;
my @cos;
+ my @note_refs = get_note_refs();
+
$maxcount ||= 1;
$skip ||= 0;
@@ -2807,6 +2853,22 @@ sub parse_commits {
or die_error(500, "Open git-rev-list failed");
while (my $line = <$fd>) {
my %co = parse_commit_text($line);
+ my %notes = () ;
+ foreach my $note_ref (@note_refs) {
+ my $obj = "$note_ref:$co{'id'}";
+ if (open my $fd, '-|', git_cmd(), 'rev-parse',
+ '--verify', '-q', $obj) {
+ my $exists = <$fd>;
+ close $fd;
+ if (defined $exists) {
+ if (open $fd, '-|', git_cmd(), 'show', $obj) {
+ $notes{$note_ref} = scalar <$fd>;
+ close $fd;
+ }
+ }
+ }
+ }
+ $co{'notes'} = \%notes;
push @cos, \%co;
}
close $fd;
--
1.7.0.rc1.193.ge8618
^ permalink raw reply related
* [PATCH 2/4] gitweb: show notes in shortlog view
From: Giuseppe Bilotta @ 2010-02-04 16:18 UTC (permalink / raw)
To: git
Cc: Jakub Narebski, Johannes Schindelin, Johan Herland,
Junio C Hamano, Giuseppe Bilotta
In-Reply-To: <1265300338-25021-1-git-send-email-giuseppe.bilotta@gmail.com>
The presence of the note is shown by a small icon, hovering on which
reveals the actual note content.
---
gitweb/gitweb.css | 29 +++++++++++++++++++++++++++++
gitweb/gitweb.perl | 30 +++++++++++++++++++++++++++++-
2 files changed, 58 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.css b/gitweb/gitweb.css
index 50067f2..7d1836b 100644
--- a/gitweb/gitweb.css
+++ b/gitweb/gitweb.css
@@ -572,3 +572,32 @@ span.match {
div.binary {
font-style: italic;
}
+
+span.notes {
+ float:right;
+ position:relative;
+}
+
+span.notes span.note-container:before {
+ content: url('data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAgAAAAIAgMAAAC5YVYYAAAAAXNSR0IArs4c6QAAAAlQTFRFAABnybuD//+t5rXizQAAAAF0Uk5TAEDm2GYAAAABYktHRACIBR1IAAAAGElEQVQI12MIDWXIWglDQHYIQ1YAQ6gDAFWPBrAKFe0fAAAAAElFTkSuQmCC');
+}
+
+span.notes span.note {
+ display:none;
+}
+
+span.notes span.note-container img {
+ content: normal;
+}
+
+span.notes span.note-container:hover span.note {
+ display:block;
+ content:normal;
+ background-color:#ffffad;
+ border:1px solid #c9bb83;
+ padding:4px;margin:0;
+ position:absolute;
+ top:0;right:0;
+ z-index:10;
+ overflow:visible;
+}
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 9ba5815..1701ed1 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1628,6 +1628,33 @@ sub format_subject_html {
}
}
+# display notes next to a commit
+sub format_notes_html {
+ my %notes = %{$_[0]};
+ my $ret = "";
+ while (my ($ref, $text) = each %notes) {
+ # remove 'refs/notes/' and an optional final s
+ $ref =~ s/^refs\/notes\///;
+ $ref =~ s/s$//;
+
+ # double markup is needed to allow pure CSS cross-browser 'popup'
+ # of the note
+ $ret .= "<span title='$ref' class='note-container $ref'>";
+ $ret .= "<span title='$ref' class='note $ref'>";
+ foreach my $line (split /\n/, $text) {
+ $ret .= esc_html($line) . "<br/>";
+ }
+ $ret .= "</span></span>";
+ }
+ if ($ret) {
+ return "<span class='notes'>$ret</span>";
+ } else {
+ return $ret;
+ }
+
+
+}
+
# Rather than recomputing the url for an email multiple times, we cache it
# after the first hit. This gives a visible benefit in views where the avatar
# for the same email is used repeatedly (e.g. shortlog).
@@ -4595,6 +4622,7 @@ sub git_shortlog_body {
my %co = %{$commitlist->[$i]};
my $commit = $co{'id'};
my $ref = format_ref_marker($refs, $commit);
+ my $notes = format_notes_html($co{'notes'});
if ($alternate) {
print "<tr class=\"dark\">\n";
} else {
@@ -4605,7 +4633,7 @@ sub git_shortlog_body {
print "<td title=\"$co{'age_string_age'}\"><i>$co{'age_string_date'}</i></td>\n" .
format_author_html('td', \%co, 10) . "<td>";
print format_subject_html($co{'title'}, $co{'title_short'},
- href(action=>"commit", hash=>$commit), $ref);
+ href(action=>"commit", hash=>$commit), $ref . $notes);
print "</td>\n" .
"<td class=\"link\">" .
$cgi->a({-href => href(action=>"commit", hash=>$commit)}, "commit") . " | " .
--
1.7.0.rc1.193.ge8618
^ permalink raw reply related
* [PATCH 3/4] gitweb: show notes in log
From: Giuseppe Bilotta @ 2010-02-04 16:18 UTC (permalink / raw)
To: git
Cc: Jakub Narebski, Johannes Schindelin, Johan Herland,
Junio C Hamano, Giuseppe Bilotta
In-Reply-To: <1265300338-25021-1-git-send-email-giuseppe.bilotta@gmail.com>
The notes are shown in full to the left of the log message.
---
gitweb/gitweb.css | 11 +++++++++++
gitweb/gitweb.perl | 11 +++++++----
2 files changed, 18 insertions(+), 4 deletions(-)
diff --git a/gitweb/gitweb.css b/gitweb/gitweb.css
index 7d1836b..81d66d3 100644
--- a/gitweb/gitweb.css
+++ b/gitweb/gitweb.css
@@ -601,3 +601,14 @@ span.notes span.note-container:hover span.note {
z-index:10;
overflow:visible;
}
+
+div.notes {
+ max-width:150px;
+ float:left;
+}
+
+div.notes div.note {
+ background-color:#ffffad;
+ border:1px solid #c9bb83;
+ padding:4px;margin:0;
+}
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 1701ed1..0d0877e 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1631,6 +1631,7 @@ sub format_subject_html {
# display notes next to a commit
sub format_notes_html {
my %notes = %{$_[0]};
+ my $tag = $_[1] || 'span' ;
my $ret = "";
while (my ($ref, $text) = each %notes) {
# remove 'refs/notes/' and an optional final s
@@ -1639,15 +1640,15 @@ sub format_notes_html {
# double markup is needed to allow pure CSS cross-browser 'popup'
# of the note
- $ret .= "<span title='$ref' class='note-container $ref'>";
- $ret .= "<span title='$ref' class='note $ref'>";
+ $ret .= "<$tag title='$ref' class='note-container $ref'>";
+ $ret .= "<$tag title='$ref' class='note $ref'>";
foreach my $line (split /\n/, $text) {
$ret .= esc_html($line) . "<br/>";
}
- $ret .= "</span></span>";
+ $ret .= "</$tag></$tag>";
}
if ($ret) {
- return "<span class='notes'>$ret</span>";
+ return "<$tag class='notes'>$ret</$tag>";
} else {
return $ret;
}
@@ -4581,6 +4582,7 @@ sub git_log_body {
next if !%co;
my $commit = $co{'id'};
my $ref = format_ref_marker($refs, $commit);
+ my $notes = format_notes_html($co{'notes'}, 'div');
my %ad = parse_date($co{'author_epoch'});
git_print_header_div('commit',
"<span class=\"age\">$co{'age_string'}</span>" .
@@ -4598,6 +4600,7 @@ sub git_log_body {
git_print_authorship(\%co, -tag => 'span');
print "<br/>\n</div>\n";
+ print "$notes\n";
print "<div class=\"log_body\">\n";
git_print_log($co{'comment'}, -final_empty_line=> 1);
print "</div>\n";
--
1.7.0.rc1.193.ge8618
^ permalink raw reply related
* [PATCH 4/4] gitweb: show notes in commit(diff) view
From: Giuseppe Bilotta @ 2010-02-04 16:18 UTC (permalink / raw)
To: git
Cc: Jakub Narebski, Johannes Schindelin, Johan Herland,
Junio C Hamano, Giuseppe Bilotta
In-Reply-To: <1265300338-25021-1-git-send-email-giuseppe.bilotta@gmail.com>
The notes are shown side-by-side along the bottom of the commit message.
---
gitweb/gitweb.css | 11 +++++++++++
gitweb/gitweb.perl | 21 +++++++++++++++++++++
2 files changed, 32 insertions(+), 0 deletions(-)
diff --git a/gitweb/gitweb.css b/gitweb/gitweb.css
index 81d66d3..10acab4 100644
--- a/gitweb/gitweb.css
+++ b/gitweb/gitweb.css
@@ -145,6 +145,7 @@ div.list_head {
border: solid #d9d8d1;
border-width: 1px 0px 0px;
font-style: italic;
+ clear: both;
}
.author_date, .author {
@@ -612,3 +613,13 @@ div.notes div.note {
border:1px solid #c9bb83;
padding:4px;margin:0;
}
+
+
+div.page_body div.notes {
+ max-width:100%;
+ float:none;
+}
+
+div.page_body div.notes div.note {
+ float:left;
+}
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 0d0877e..0d03026 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -2837,12 +2837,31 @@ sub parse_commit {
%co = parse_commit_text(<$fd>, 1);
close $fd;
+ my %notes = ();
+ foreach my $note_ref (get_note_refs()) {
+ my $obj = "$note_ref:$co{'id'}";
+ if (open my $fd, '-|', git_cmd(), 'rev-parse',
+ '--verify', '-q', $obj) {
+ my $exists = <$fd>;
+ close $fd;
+ if (defined $exists) {
+ if (open $fd, '-|', git_cmd(), 'show', $obj) {
+ $notes{$note_ref} = scalar <$fd>;
+ close $fd;
+ }
+ }
+ }
+ }
+ $co{'notes'} = \%notes;
+
return %co;
}
# return all refs matching refs/notes/<globspecs> where the globspecs
# are taken from the notes feature content.
sub get_note_refs {
+ local $/ = "";
+
my @globs = gitweb_get_feature('notes');
my @note_refs = ();
foreach my $glob (@globs) {
@@ -5875,6 +5894,7 @@ sub git_commit {
print "<div class=\"page_body\">\n";
git_print_log($co{'comment'});
+ print format_notes_html($co{'notes'}, 'div');
print "</div>\n";
git_difftree_body(\@difftree, $hash, @$parents);
@@ -6230,6 +6250,7 @@ sub git_commitdiff {
git_print_log($co{'comment'}, -final_empty_line=> 1, -remove_title => 1);
print "</div>\n"; # class="log"
}
+ print format_notes_html($co{'notes'}, 'div');
} elsif ($format eq 'plain') {
my $refs = git_get_references("tags");
--
1.7.0.rc1.193.ge8618
^ permalink raw reply related
* Re: Making custom git-remove-tree command
From: Teemu Likonen @ 2010-02-04 16:32 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <4B6A9985.4050909@viscovery.net>
* 2010-02-04 10:55 (+0100), Johannes Sixt wrote:
> I think you should be able to reduce all of this to just
>
> git read-tree --index-output=/tmp/empty.index -m -u \
> 4b825dc642cb6eb9a060e54bf8d69288fbee4904 # empty tree
> rm -f /tmp/empty.index
>
> (with the usual caveats about temporary files).
Thanks, it works. It's also _much_ faster than my "git ls-tree" with
shell loop thing. It prints ugly error, though:
fatal: unable to write new index file
Also, it doesn't leave any index output files around.
^ permalink raw reply
* Re: [PATCH 1/4] gitweb: notes feature
From: Junio C Hamano @ 2010-02-04 16:33 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Jakub Narebski, Johannes Schindelin, Johan Herland
In-Reply-To: <1265300338-25021-2-git-send-email-giuseppe.bilotta@gmail.com>
Giuseppe Bilotta <giuseppe.bilotta@gmail.com> writes:
> + my %notes = () ;
> + foreach my $note_ref (@note_refs) {
> + my $obj = "$note_ref:$co{'id'}";
I think this look-up is wrong (meaning: will stop working anytime in the
future, and needs to be rewritten).
Other parts of this patch looked Ok from a cursory reading, though.
^ permalink raw reply
* Re: Making custom git-remove-tree command
From: Johannes Sixt @ 2010-02-04 16:43 UTC (permalink / raw)
To: Teemu Likonen; +Cc: git
In-Reply-To: <87tytxhsgc.fsf@mithlond.arda>
Teemu Likonen schrieb:
> * 2010-02-04 10:55 (+0100), Johannes Sixt wrote:
>
>> I think you should be able to reduce all of this to just
>>
>> git read-tree --index-output=/tmp/empty.index -m -u \
>> 4b825dc642cb6eb9a060e54bf8d69288fbee4904 # empty tree
>> rm -f /tmp/empty.index
>>
>> (with the usual caveats about temporary files).
>
> Thanks, it works. It's also _much_ faster than my "git ls-tree" with
> shell loop thing. It prints ugly error, though:
>
> fatal: unable to write new index file
Then put the temporary index into your git-dir:
gitdir=$(git rev-parse --git-dir)
git read-tree --index-ouput="$gitdir/tmpindex" ...
rm -f "$gitdir/tmpindex"
The purpose of this temporary index is only that your real index is not
cleared. If you don't mind that your index is purged as well, then you can
just drop the --index-output parameter.
-- Hannes
^ permalink raw reply
* Re: Question about git rebase --onto
From: Pascal Obry @ 2010-02-04 16:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git list
In-Reply-To: <7vhbpx3it2.fsf@alter.siamese.dyndns.org>
Junio,
> Writing reproducible test case would be a great way to diagnose this.
I just can't reproduce now! I've tried on a second machine starting from
the same repository state and still can't reproduce! So either I was in
really bad shape last night or it was some kind of transient problem on
my Cygwin/Git system.
Sorry for the noise.
Pascal.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net - http://v2p.fr.eu.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B
^ permalink raw reply
* Re: [PATCH 1/4] gitweb: notes feature
From: Junio C Hamano @ 2010-02-04 16:46 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Jakub Narebski, Johannes Schindelin, Johan Herland
In-Reply-To: <7vpr4lhsfu.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Giuseppe Bilotta <giuseppe.bilotta@gmail.com> writes:
>
>> + my %notes = () ;
>> + foreach my $note_ref (@note_refs) {
>> + my $obj = "$note_ref:$co{'id'}";
>
> I think this look-up is wrong (meaning: will stop working anytime in the
> future, and needs to be rewritten).
IOW, the code should be reading output from:
GIT_NOTES_REF=$note_ref git show -s --format=%N $co{'id'}
as the notes tree may not be storing notes in a flat one-level namespace
like you are assuming.
^ permalink raw reply
* Re: Question about git rebase --onto
From: Junio C Hamano @ 2010-02-04 16:50 UTC (permalink / raw)
To: pascal; +Cc: git list
In-Reply-To: <4B6AF9EE.3000205@obry.net>
Pascal Obry <pascal@obry.net> writes:
>> Writing reproducible test case would be a great way to diagnose this.
>
> I just can't reproduce now! I've tried on a second machine starting from
> the same repository state and still can't reproduce! So either I was in
> really bad shape last night or it was some kind of transient problem on
> my Cygwin/Git system.
>
> Sorry for the noise.
Don't be sorry. We need to know about issues, and sporadic failures, if
they are real, are the ones that affects people the worst way.
Thanks for spending time to reproduce---and please do report (and preserve
the reproducible state if possible) when you see a breakage (like this
one, or some other form) next time.
^ permalink raw reply
* Re: [PATCH 3/3] make --max-pack-size argument to 'git pack-object' count in bytes
From: Junio C Hamano @ 2010-02-04 17:11 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Nicolas Pitre, git
In-Reply-To: <7v7hqtty38.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
> ...
>> Shouldn't we also change fast-import.c ?
>
> Surely; could you do the honors? I cannot really decide how big the deal
> would be to break backward compatibility for max-pack-size myself.
I'll queue the "fix mismerge" one I got "Yup, looks good to me." from you,
with this:
commit 76ea93ccb5df138eb57b2e8f2aee61dd1ca666ea
Author: Junio C Hamano <gitster@pobox.com>
Date: Wed Feb 3 18:27:08 2010 -0800
fast-import.c: Fix big-file-threshold parsing bug
Manual merge made at 844ad3d (Merge branch 'sp/maint-fast-import-large-blob'
into sp/fast-import-large-blob, 2010-02-01) did not correctly reflect the change
of unit in which this variable's value is counted from its previous version.
Now it counts in bytes, not in megabytes.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
I am debating myself if we want to have another one (see below) on top; I
am not a heavy user of fast-import and I don't know if existing users will
be hurt by such a change and if so how much.
-- >8 --
Subject: [PATCH] fast-import: count --max-pack-size in bytes
Similar in spirit to 07cf0f2 (make --max-pack-size argument to 'git
pack-object' count in bytes, 2010-02-03) which made the option by the same
name to pack-objects, this counts the pack size limit in bytes.
In order not to cause havoc with people used to the previous megabyte
scale, and because this is a sane thing to do anyway, a minimum size of 1
MiB is enforced to avoid an explosion of pack files.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Documentation/RelNotes-1.7.0.txt | 8 ++++----
Documentation/git-fast-import.txt | 4 ++--
fast-import.c | 14 ++++++++------
3 files changed, 14 insertions(+), 12 deletions(-)
diff --git a/Documentation/RelNotes-1.7.0.txt b/Documentation/RelNotes-1.7.0.txt
index e66945c..255666f 100644
--- a/Documentation/RelNotes-1.7.0.txt
+++ b/Documentation/RelNotes-1.7.0.txt
@@ -46,10 +46,10 @@ Notes on behaviour change
environment, and diff.*.command and diff.*.textconv in the config
file.
- * The --max-pack-size argument to 'git repack' and 'git pack-objects' was
- assuming the provided size to be expressed in MiB, unlike the
- corresponding config variable and other similar options accepting a size
- value. It is now expecting a size expressed in bytes, with a possible
+ * The --max-pack-size argument to 'git repack', 'git pack-objects', and
+ 'git fast-import' was assuming the provided size to be expressed in MiB,
+ unlike the corresponding config variable and other similar options accepting
+ a size value. It is now expecting a size expressed in bytes, with a possible
unit suffix of 'k', 'm', or 'g'.
Updates since v1.6.6
diff --git a/Documentation/git-fast-import.txt b/Documentation/git-fast-import.txt
index 2691114..6764ff1 100644
--- a/Documentation/git-fast-import.txt
+++ b/Documentation/git-fast-import.txt
@@ -44,8 +44,8 @@ OPTIONS
not contain the old commit).
--max-pack-size=<n>::
- Maximum size of each output packfile, expressed in MiB.
- The default is 4096 (4 GiB) as that is the maximum allowed
+ Maximum size of each output packfile.
+ The default is 4 GiB as that is the maximum allowed
packfile size (due to file format limitations). Some
importers may wish to lower this, such as to ensure the
resulting packfiles fit on CDs.
diff --git a/fast-import.c b/fast-import.c
index a6730d0..09c0817 100644
--- a/fast-import.c
+++ b/fast-import.c
@@ -2764,11 +2764,6 @@ static void option_date_format(const char *fmt)
die("unknown --date-format argument %s", fmt);
}
-static void option_max_pack_size(const char *packsize)
-{
- max_packsize = strtoumax(packsize, NULL, 0) * 1024 * 1024;
-}
-
static void option_depth(const char *depth)
{
max_depth = strtoul(depth, NULL, 0);
@@ -2798,7 +2793,14 @@ static void option_export_pack_edges(const char *edges)
static int parse_one_option(const char *option)
{
if (!prefixcmp(option, "max-pack-size=")) {
- option_max_pack_size(option + 14);
+ unsigned long v;
+ if (!git_parse_ulong(option + 14, &v))
+ return 0;
+ if (v < 1024 * 1024) {
+ warning("minimum max-pack-size is 1 MiB");
+ v = 1024 * 1024;
+ }
+ max_packsize = v;
} else if (!prefixcmp(option, "big-file-threshold=")) {
unsigned long v;
if (!git_parse_ulong(option + 19, &v))
--
1.7.0.rc1.199.g9253ab
^ permalink raw reply related
* Re: rebase vs rebase -i
From: Jay Soffian @ 2010-02-04 17:14 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.1002041414530.4505@intel-tinevez-2-302>
On Thu, Feb 4, 2010 at 8:27 AM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
>> (Here I'm setting GIT_EDITOR=true just to demonstrate that I didn't
>> change the list of commits in the latter case.)
>
> You can get _exactly_ the same behavior if you use -m.
Or rather, -p. ;-)
j.
^ permalink raw reply
* Re: [PATCH] git-clean: fix the description of the default behavior
From: Junio C Hamano @ 2010-02-04 17:15 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git, Junio C Hamano
In-Reply-To: <dafb1423c81bc2207d06cf2a97205bcbd9a4968e.1265299086.git.git@drmicha.warpmail.net>
looks sane; thanks.
^ permalink raw reply
* Re: [PATCH v6] add --summary option to git-push and git-fetch
From: Larry D'Anna @ 2010-02-04 17:16 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <20100201005751.GA8322@cthulhu>
* Larry D'Anna (larry@elder-gods.org) [100131 19:57]:
> So i guess you're saying that it would be better for update_local_ref and
> print_summary_for_push_or_fetch to clear the flags, and just pass a rev_info for
> print_summary_for_push_or_fetch instead of quickref?
So, should I submit a version of the patch that does it this way? Should it use
a subprocess? Should the option be called something other than --summary?
Should I just forget about it?
--larry
^ permalink raw reply
* Re: [PATCH 1/4] gitweb: notes feature
From: Jakub Narebski @ 2010-02-04 17:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Giuseppe Bilotta, git, Johannes Schindelin, Johan Herland
In-Reply-To: <7v4olxhrti.fsf@alter.siamese.dyndns.org>
On Thu, 4 Feb 2010, Junio C Hamano wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> Giuseppe Bilotta <giuseppe.bilotta@gmail.com> writes:
>>
>>> + my %notes = () ;
>>> + foreach my $note_ref (@note_refs) {
>>> + my $obj = "$note_ref:$co{'id'}";
>>
>> I think this look-up is wrong (meaning: will stop working anytime in the
>> future, and needs to be rewritten).
>
> IOW, the code should be reading output from:
>
> GIT_NOTES_REF=$note_ref git show -s --format=%N $co{'id'}
>
> as the notes tree may not be storing notes in a flat one-level namespace
> like you are assuming.
First, for some mechanism of deployment (IIRC Apache's mod_perl) changes
to environment variables from CGI script are not passed to invoked
commands (I guess for security reasons). That is why gitweb uses --git-dir
parameter to git wrapper, and not GIT_DIR environment variable since
25691fb (gitweb: Use --git-dir parameter instead of setting $ENV{'GIT_DIR'},
2006-08-28). So for proper support we would need --notes-ref (or similar)
option to git wrapper
git --notes-ref=$note_ref show -s --format=%N $co{'id'}
Second, parse_commit / parse_commits use
git rev-list -z --parents --header --max-count-X
If this command automatically shows notes (or it can be modified to
automatically show notes) after unindented "Notes:" line (as per
git-notes documentation), then the only thing that needs to be
changed to fill %commit{'notes'} is parse_commit_text subroutine.
There would be no need for extra subroutine (and extra command, or
even up to two extra commands per note) to get notes data.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH 3/3] make --max-pack-size argument to 'git pack-object' count in bytes
From: Shawn O. Pearce @ 2010-02-04 17:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nicolas Pitre, git
In-Reply-To: <7vtytxexjl.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> Subject: [PATCH] fast-import: count --max-pack-size in bytes
> if (!prefixcmp(option, "max-pack-size=")) {
> - option_max_pack_size(option + 14);
> + unsigned long v;
> + if (!git_parse_ulong(option + 14, &v))
> + return 0;
> + if (v < 1024 * 1024) {
> + warning("minimum max-pack-size is 1 MiB");
> + v = 1024 * 1024;
> + }
> + max_packsize = v;
How about for a transition period we do:
if (v < 8192) {
warning("max-pack-size is now in bytes, assuming %dm", v);
v *= 1024 * 1024;
}
So that existing users won't be completely broken if they are
relying on this flag, and have some time to adjust.
Given the huge magnitude between the old sane value range, and the
new sane value range, we can safely assume anything below a small
number like 8192 is an old user, warn them, and assume old behavior.
A local pack smaller than 1 MiB is mostly pointless coming out of
a tool like git repack or git fast-import, unless its a complete
copy of the repository. So the old style calling convention of
4096 for 4 GiB would now imply a pack so small, we probably can't
get more than 1 object per pack.
--
Shawn.
^ 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